HI Sergio,
I see new document as updated in latest clone is as below:
dpdk {
dev 0000:81:00.0
dev 0000:81:00.1
dev 0000:85:01.0
dev 0000:85:01.1
vdev crypto_aesni_mb0,socket_id=1
vdev crypto_aesni_mb1,socket_id=1
}
I think it shall be “vdev crypto_aesni_mb0” instead as you mentioned earlier in
one of mail.
With “vdev crypto_aesni_mb0,socket_id=1”, I get error.
CRYPTODEV: [crypto_aesni_mb] cryptodev_aesni_mb_create() line 727: failed to
create cryptodev vdev
CRYPTODEV: [crypto_aesni_mb] cryptodev_aesni_mb_create() line 769: driver
crypto_aesni_mb0: cryptodev_aesni_create failed
EAL: failed to initialize crypto_aesni_mb0 device
When I am trying “vdev crypto_aesni_mb0”, it seems it works fine and get no
error. Log is as below.
DPDK physical memory layout:
Segment 0: phys:0x6f400000, len:1073741824, virt:0x7f5265200000, socket_id:0,
hugepage_sz:2097152, nchannel:0, nrank:0
DPDK Cryptodevs info:
dev_id n_qp nb_obj cache_size
1 8 20000 512
Still when I am sending ESP packet to VPP, it is getting silently dropped.
Note: Same config is working when it is non-dpdk i.e VPP core IPsec core.
Trace:
vpp# show trace
------------------- Start of thread 0 vpp_main -------------------
Packet 1
00:02:14:020870: dpdk-input
GigabitEthernet0/8/0 rx queue 0
buffer 0x4cf2: 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 0x9b9cf140
packet_type 0x0
IP4: 08:00:27:f5:2b:b9 -> 08:00:27:a9:8e:d4
IPSEC_ESP: 172.28.128.4 -> 172.28.128.5
tos 0x00, ttl 64, length 136, checksum 0x7fa7
fragment id 0x625a, flags DONT_FRAGMENT
00:02:14:020903: ip4-input
IPSEC_ESP: 172.28.128.4 -> 172.28.128.5
tos 0x00, ttl 64, length 136, checksum 0x7fa7
fragment id 0x625a, flags DONT_FRAGMENT
00:02:14:020909: ipsec-input-ip4
esp: sa_id 20 spi 1000 seq 3
00:02:14:020910: dpdk-esp-decrypt
esp: crypto aes-cbc-128 integrity sha1-96
vpp# q
vagrant@localhost:~$ sudo vppctl show errors
_______ _ _ _____ ___
__/ __/ _ \ (_)__ | | / / _ \/ _ \
_/ _// // / / / _ \ | |/ / ___/ ___/
/_/ /____(_)_/\___/ |___/_/ /_/
vpp# show errors
Count Node Reason
1 dpdk-esp-decrypt ESP pkts received
1 ipsec-input-ip4 IPSEC pkts received
vpp# q
Config done on VPP:
vpp# ipsec sa add 10 spi 1001 esp crypto-alg aes-cbc-128 crypto-key
4a506a794f574265564551694d653768 integ-alg sha1-96 integ-key
4339314b55523947594d6d3547666b45764e6a58
vpp# ipsec sa add 20 spi 1000 esp crypto-alg aes-cbc-128 crypto-key
4a506a794f574265564551694d653768 integ-alg sha1-96 integ-key
4339314b55523947594d6d3547666b45764e6a58
vpp# ipsec spd add 1
vpp# set interface ipsec spd GigabitEthernet0/8/0 1
vpp# ipsec policy add spd 1 priority 100 inbound action bypass protocol 50
vpp# ipsec policy add spd 1 priority 100 outbound action bypass protocol 50
vpp# ipsec policy add spd 1 priority 10 inbound action protect sa 20
local-ip-range 172.28.128.5 - 172.28.128.5 remote-ip-range 172.28.128.4 -
172.28.128.4
vpp# ipsec policy add spd 1 priority 10 outbound action protect sa 10
local-ip-range 172.28.128.5 - 172.28.128.5 remote-ip-range 172.28.128.4 -
172.28.128.4
vpp#
Do you think, it is unresolved issue. Because I think same config unchanged at
both IPsec end-point i.e VPP and host Ubuntu, it works fine.
Just when I start VPP with below config, it shows above errors.
dpdk {
socket-mem 1024,1024
num-mbufs 131072
dev 0000:00:08.0
vdev crypto_aesni_mb0
vdev crypto_aesni_mb1
}
If I remove above config and all setup same at Ubunto and vpp, things works
fine.
Thanks
Mukesh
On 01/09/17, 1:52 PM, "Sergio Gonzalez Monroy"
<sergio.gonzalez.mon...@intel.com> wrote:
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
