Hi Mukesh,

I was able to find the bug. It was not directly related to transport mode but to the setup when using single core (master core) without workers ( https://gerrit.fd.io/r/8302 ).

You can either apply the change or setup VPP to use workers (at the moment you are running with single core, no workers).

Regards,
Sergio

On 05/09/2017 09:28, Sergio Gonzalez Monroy wrote:
On 04/09/2017 17:07, Mukesh Yadav (mukyadav) wrote:
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

The socket_id=1 was just an example of how to place the vdev in socket 1 if you run with cores in that socket.


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.

Agree, same configuration should work, so it is likely that there is a bug for transport mode.
I'll investigate.

Thanks,
Sergio

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


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

Reply via email to