Re: [vpp-dev] Query for IPSec support on VPP

Fri, 01 Sep 2017 01:23:20 -0700 

FYI I updated the doc, hopefully everything is correct and up to date now.
https://gerrit.fd.io/r/#/c/8273/

Thanks,
Sergio

On 31/08/2017 10:00, Sergio Gonzalez Monroy wrote:

On 31/08/2017 09:37, Mukesh Yadav (mukyadav) wrote:


Thanks a lot Sergio for lot of patience and help,
No problem at all. I said before, it is great that someone else goes through the docs/wiki to double check everything is working as described. 


With you latest comments, I can see dpdk IPSec is happening.
There are some issues, I am getting where post decryption ip4-input is not called. As such I have kept config of IPSec same as was when working with VPP core IPSec.
I need to dig further, as such it seems packet is getting dropped in *dpdk-esp-decrypt(). 
*Is there some way to find out some errors related.
There are a few reasons why the packet would be drop in that node, but I was expecting the trace to show the drop node for those packets. 
What is the output of 'show error' ?
I see you are setting up IPSec as an interface feature, with SPD and transport mode SA, I will double check that there are no bugs. 

Thanks,
Sergio


**

I am using vpp v17.10 andDPDK 17.05.0

Currently trace is looking like below:
00:01:30:013871: dpdk-input

GigabitEthernet0/8/0 rx queue 0
buffer 0x4d67: current data 14, length 136, free-list 0, clone-count 0, totlen-nifb 0, trace 0x0 

PKT MBUF: port 0, nb_segs 1, pkt_len 150
buf_len 2176, data_len 150, ol_flags 0x0, data_off 128, phys_addr 0x9cd35a00 

packet_type 0x0

IP4: 08:00:27:ba:35:60 -> 08:00:27:67:d4:f0

IPSEC_ESP: 172.28.128.4 -> 172.28.128.5

tos 0x00, ttl 64, length 136, checksum 0x9d0f

fragment id 0x44f2, flags DONT_FRAGMENT

00:01:30:013902: ip4-input

IPSEC_ESP: 172.28.128.4 -> 172.28.128.5

tos 0x00, ttl 64, length 136, checksum 0x9d0f

fragment id 0x44f2, flags DONT_FRAGMENT

00:01:30:013909: ipsec-input-ip4

esp: sa_id 20 spi 1000 seq 7

00:01:30:013911: *dpdk-esp-decrypt*

esp: crypto aes-cbc-128 integrity sha1-96

Earlier when I was using VPP core IPSec, trace was looking like

00:03:41:528507: dpdk-input

GigabitEthernet0/8/0 rx queue 0
buffer 0x4d19: current data 14, length 136, free-list 0, clone-count 0, totlen-nifb 0, trace 0x0 

PKT MBUF: port 0, nb_segs 1, pkt_len 150
buf_len 2176, data_len 150, ol_flags 0x0, data_off 128, phys_addr 0x7de34680 

packet_type 0x0

IP4: 08:00:27:ba:35:60 -> 08:00:27:67:d4:f0

IPSEC_ESP: 172.28.128.4 -> 172.28.128.5

tos 0x00, ttl 64, length 136, checksum 0xc1c0

fragment id 0x2041, flags DONT_FRAGMENT

00:03:41:528548: ip4-input

IPSEC_ESP: 172.28.128.4 -> 172.28.128.5

tos 0x00, ttl 64, length 136, checksum 0xc1c0

fragment id 0x2041, flags DONT_FRAGMENT

00:03:41:528556: ipsec-input-ip4

esp: sa_id 20 spi 1000 seq 1

00:03:41:528559*: esp-decrypt***

esp: crypto aes-cbc-128 integrity sha1-96

00:03:41:528648: ip4-input

ICMP: 172.28.128.4 -> 172.28.128.5

tos 0x00, ttl 64, length 84, checksum 0x2267

fragment id 0x0000

ICMP echo_request checksum 0x4201

00:03:41:528649: ip4-lookup

fib 0 dpo-idx 6 flow hash: 0x00000000

ICMP: 172.28.128.4 -> 172.28.128.5

tos 0x00, ttl 64, length 84, checksum 0x2267

fragment id 0x0000

ICMP echo_request checksum 0x4201

00:03:41:528680: ip4-local

ICMP: 172.28.128.4 -> 172.28.128.5

tos 0x00, ttl 64, length 84, checksum 0x2267

fragment id 0x0000

ICMP echo_request checksum 0x4201

00:03:41:528684: ip4-icmp-input

ICMP: 172.28.128.4 -> 172.28.128.5

tos 0x00, ttl 64, length 84, checksum 0x2267

fragment id 0x0000

ICMP echo_request checksum 0x4201

00:03:41:528685: ip4-icmp-echo-request

ICMP: 172.28.128.4 -> 172.28.128.5

tos 0x00, ttl 64, length 84, checksum 0x2267

fragment id 0x0000

ICMP echo_request checksum 0x4201

00:03:41:528686: ip4-load-balance

fib 0 dpo-idx 13 flow hash: 0x00000000

ICMP: 172.28.128.5 -> 172.28.128.4

tos 0x00, ttl 64, length 84, checksum 0xea0f

fragment id 0x3857

ICMP echo_reply checksum 0x4a01

00:03:41:528688: ip4-rewrite
tx_sw_if_index 1 dpo-idx 1 : ipv4 via 172.28.128.4 GigabitEthernet0/8/0: 080027ba356008002767d4f00800 flow hash: 0x00000000
00000000: 080027ba356008002767d4f0080045000054385700004001ea0fac1c8005ac1c 

00000020: 800400004a0107850001d6be8e5900000000898d0100000000001011

00:03:41:528691: ipsec-output-ip4

spd 1

00:03:41:528697: esp-encrypt

esp: spi 1001 seq 0 crypto aes-cbc-128 integrity sha1-96

My configuration is as below:

sudo ifconfig enp0s8 down

sudo service vpp restart

set int ip address GigabitEthernet0/8/0 172.28.128.5/24

set int state GigabitEthernet0/8/0 up
ipsec sa add 10 spi 1001 esp crypto-alg aes-cbc-128 crypto-key 4a506a794f574265564551694d653768 integ-alg sha1-96 integ-key 4339314b55523947594d6d3547666b45764e6a58
ipsec sa add 20 spi 1000 esp crypto-alg aes-cbc-128 crypto-key 4a506a794f574265564551694d653768 integ-alg sha1-96 integ-key 4339314b55523947594d6d3547666b45764e6a58 

ipsec spd add 1

set interface ipsec spd GigabitEthernet0/8/0 1

ipsec policy add spd 1 priority 100 inbound action bypass protocol 50

ipsec policy add spd 1 priority 100 outbound action bypass protocol 50
ipsec policy add spd 1 priority 10 inbound action protect sa 20 local-ip-range 172.28.128.5 - 172.28.128.5remote-ip-range 172.28.128.4 - 172.28.128.4
ipsec policy add spd 1 priority 10 outbound action protect sa 10 local-ip-range 172.28.128.5 - 172.28.128.5remote-ip-range 172.28.128.4 - 172.28.128.4 

dpdk {

socket-mem 1024,1024

num-mbufs 131072

dev 0000:00:08.0

vdev crypto_aesni_mb0

vdev crypto_aesni_mb1

}
I think there shall be no change in config when using DPDK IPSec vs VPP Core IPSec.
With above config, I was able to ping over ESP properly when not using DPDK IPSec. 

Thanks,

Sergio





_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev



_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Reply via email to