HI, I haven’t tested tunnel mode w/o DPDK. With transport mode, I see it works fine both with VPP core and DPDK and follows path post decryption dpdk-esp-decrypt -> dpdk-esp-decrypt-post ->ip4-input-> ip4-lookup-> ip4-local and further follow icmp path. I see this problem only with tunnel mode.
I don’t see this problem as in IPsec scope. But something specifc to tunnel mode configuration. May be some forwarding logic. Thanks Mukesh On 07/09/17, 2:12 PM, "Sergio Gonzalez Monroy" <sergio.gonzalez.mon...@intel.com> wrote: Hi Mukesh, On 07/09/2017 08:48, Mukesh Yadav (mukyadav) wrote: > HI Sergio, > > As I mentioned that transport mode is working now. > Next I tried tunnel mode. > Here I can see successfully packet decryption. But later inner packet gets dropped. > > Outer IPSec packet is like 172.28.128.4 -> 172.28.128.5 > Inner packet is 1.1.1.1 -> 2.2.2.2 > I have added 2.2.2.2 on same interface as is Outer IPSec end-point > > vpp# show int address > GigabitEthernet0/8/0 (up): > 172.28.128.5/24 > 2.2.2.2/24 > local0 (dn): > vpp# q > > Above I have configured as below: > set int ip address GigabitEthernet0/8/0 172.28.128.5/24 > set int ip address GigabitEthernet0/8/0 2.2.2.2/24 > set interface state GigabitEthernet0/8/0 up > > > > Trace looks like: > 00:39:17:383051: dpdk-input > GigabitEthernet0/8/0 rx queue 0 > buffer 0x4a5b: current data 14, length 152, free-list 0, clone-count 0, totlen-nifb 0, trace 0x0 > PKT MBUF: port 0, nb_segs 1, pkt_len 166 > buf_len 2176, data_len 166, ol_flags 0x0, data_off 128, phys_addr 0x9cf29700 > 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 152, checksum 0xf9d5 > fragment id 0xe81b, flags DONT_FRAGMENT > 00:39:17:383093: ip4-input > IPSEC_ESP: 172.28.128.4 -> 172.28.128.5 > tos 0x00, ttl 64, length 152, checksum 0xf9d5 > fragment id 0xe81b, flags DONT_FRAGMENT > 00:39:17:383099: ipsec-input-ip4 > esp: sa_id 20 spi 1000 seq 7 > 00:39:17:383101: dpdk-esp-decrypt > esp: crypto aes-cbc-128 integrity sha1-96 > 00:39:17:383105: dpdk-crypto-input > dpdk_crypto: cryptodev-id 1 queue-pair 0 next-index 2 status 1 sa-idx 1 > > 00:39:17:383115: dpdk-esp-decrypt-post > > 00:39:17:383116: ip4-input > ICMP: 1.1.1.1 -> 2.2.2.2 > tos 0x00, ttl 64, length 84, checksum 0x17a6 > fragment id 0x1cfe, flags DONT_FRAGMENT > ICMP echo_request checksum 0x80dc > 00:39:17:383117: ipsec-input-ip4 > esp: no esp packet > 00:39:17:383117: ip4-lookup > fib 0 dpo-idx 7 flow hash: 0x00000000 > ICMP: 1.1.1.1 -> 2.2.2.2 > tos 0x00, ttl 64, length 84, checksum 0x17a6 > fragment id 0x1cfe, flags DONT_FRAGMENT > ICMP echo_request checksum 0x80dc > 00:39:17:383122: ip4-local > ICMP: 1.1.1.1 -> 2.2.2.2 > tos 0x00, ttl 64, length 84, checksum 0x17a6 > fragment id 0x1cfe, flags DONT_FRAGMENT > ICMP echo_request checksum 0x80dc > 00:39:17:383123: error-drop > ip4-input: ip4 source lookup miss > > > Do I have to configure Inner IP in some other way to avoid “ip4 source lookup miss”. I would have thought that it should have worked. I really am not the right person to ask about that stuff :) Do you hit the same problem without DPDK? Thanks, Sergio > > Thanks > Mukesh > > > On 05/09/17, 9:12 PM, "Mukesh Yadav (mukyadav)" <mukya...@cisco.com> wrote: > > Thanks Sergio, > DPDK based IPsec basic tunnel worked with multi-core config. > > cpu { > main-core 0 > corelist-workers 1 > #skip-cores 4 > workers 1 > } > > Now since DPDK basic IPSec is working. I will try to dig in more in detail. > One query I posted in early threads, possibly got missed. > Currently ESP is supported, is there a plan to support AH in future? > > > Thanks > Mukesh > > > On 05/09/17, 7:49 PM, "Sergio Gonzalez Monroy" <sergio.gonzalez.mon...@intel.com> wrote: > > There are a few different ways to set cores/workers, best explained in > the following link: > https://wiki.fd.io/view/VPP/Using_VPP_In_A_Multi-thread_Model > > Thanks, > Sergio > > > > > > _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev