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
