Hi Sergio,
Here is the sending side trace:
Packet 1
10:54:40:291456: dpdk-input
VirtualFunctionEthernet0/6/0 rx queue 0
buffer 0x6e4f: current data 14, length 84, free-list 0, clone-count 0,
totlen-nifb 0, trace 0x0
l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
l3-hdr-offset 14
PKT MBUF: port 0, nb_segs 1, pkt_len 98
buf_len 2176, data_len 98, ol_flags 0x0, data_off 128, phys_addr 0x2c5b9440
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
Packet Offload Flags
IP4: 0e:c6:15:62:1f:9e -> 0e:7e:f2:5d:0d:b6
ICMP: 10.1.3.235 -> 10.0.1.253
tos 0x00, ttl 64, length 84, checksum 0x78df
fragment id 0xa7e1, flags DONT_FRAGMENT
ICMP echo_request checksum 0x5047
10:54:40:291473: ip4-input
ICMP: 10.1.3.235 -> 10.0.1.253
tos 0x00, ttl 64, length 84, checksum 0x78df
fragment id 0xa7e1, flags DONT_FRAGMENT
ICMP echo_request checksum 0x5047
10:54:40:291485: ip4-lookup
fib 0 dpo-idx 2 flow hash: 0x00000000
ICMP: 10.1.3.235 -> 10.0.1.253
tos 0x00, ttl 64, length 84, checksum 0x78df
fragment id 0xa7e1, flags DONT_FRAGMENT
ICMP echo_request checksum 0x5047
10:54:40:291491: ip4-rewrite
tx_sw_if_index 3 dpo-idx 2 : ipv4 via 0.0.0.0 ipsec0: flow hash: 0x00000000
00000000: 45000054a7e140003f0179df0a0103eb0a0001fd08005047549c00013de0335a
00000020: 00000000210e020000000000101112131415161718191a1b1c1d1e1f
10:54:40:291495: ipsec-if-output
IPSec: spi 3181023528 seq 28
10:54:40:291500: dpdk-esp-encrypt
cipher aes-cbc-128 auth sha1-96
IPSEC_ESP: 10.1.2.79 -> 10.0.0.213
tos 0x00, ttl 254, length 152, checksum 0xc0d3
fragment id 0x0000
ESP: spi 3181023528, seq 29
10:54:40:291514: dpdk-crypto-input
status: success
Packet 2
10:54:45:312374: dpdk-input
VirtualFunctionEthernet0/6/0 rx queue 0
buffer 0x6e76: current data 14, length 112, free-list 0, clone-count 0,
totlen-nifb 0, trace 0x1
l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
l3-hdr-offset 14
PKT MBUF: port 0, nb_segs 1, pkt_len 126
buf_len 2176, data_len 126, ol_flags 0x0, data_off 128, phys_addr
0x2c5b9e00
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
Packet Offload Flags
PKT_TX_TCP_CKSUM (0x0000) TCP cksum of TX pkt. computed by NIC
PKT_TX_SCTP_CKSUM (0x0000) SCTP cksum of TX pkt. computed by NIC
IP4: 0e:c6:15:62:1f:9e -> 0e:7e:f2:5d:0d:b6
UDP: 10.1.3.235 -> 10.0.1.253
tos 0x00, ttl 64, length 112, checksum 0x417c
fragment id 0x1f19
UDP: 55980 -> 53
length 92, checksum 0x6c45
10:54:45:312393: ip4-input
UDP: 10.1.3.235 -> 10.0.1.253
tos 0x00, ttl 64, length 112, checksum 0x417c
fragment id 0x1f19
UDP: 55980 -> 53
length 92, checksum 0x6c45
10:54:45:312400: ip4-lookup
fib 0 dpo-idx 2 flow hash: 0x00000000
UDP: 10.1.3.235 -> 10.0.1.253
tos 0x00, ttl 64, length 112, checksum 0x417c
fragment id 0x1f19
UDP: 55980 -> 53
length 92, checksum 0x6c45
10:54:45:312406: ip4-rewrite
tx_sw_if_index 3 dpo-idx 2 : ipv4 via 0.0.0.0 ipsec0: flow hash: 0x00000000
00000000: 450000701f1900003f11427c0a0103eb0a0001fddaac0035005c6c45c0210120
00000020: 0001000000000001337361666b6a687361666b6a6873666b6a686173
10:54:45:312409: ipsec-if-output
IPSec: spi 3181023528 seq 29
10:54:45:312414: dpdk-esp-encrypt
cipher aes-cbc-128 auth sha1-96
IPSEC_ESP: 10.1.2.79 -> 10.0.0.213
tos 0x00, ttl 254, length 184, checksum 0xc0b3
fragment id 0x0000
ESP: spi 3181023528, seq 30
10:54:45:312425: dpdk-crypto-input
status: success
And the receiving side:
Packet 1
10:54:17:240273: dpdk-input
VirtualFunctionEthernet0/7/0 rx queue 0
buffer 0x2925: current data 14, length 152, free-list 0, clone-count 0,
totlen-nifb 0, trace 0x0
l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
l3-hdr-offset 14
PKT MBUF: port 1, nb_segs 1, pkt_len 166
buf_len 2176, data_len 166, ol_flags 0x0, data_off 128, phys_addr
0x2c4a49c0
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
Packet Offload Flags
IP4: 1a:85:68:80:00:01 -> 0e:d2:b9:22:74:fe
IPSEC_ESP: 10.1.2.79 -> 10.0.0.213
tos 0x00, ttl 252, length 152, checksum 0x2ed9
fragment id 0x0000
10:54:17:240290: ip4-input
IPSEC_ESP: 10.1.2.79 -> 10.0.0.213
tos 0x00, ttl 252, length 152, checksum 0x2ed9
fragment id 0x0000
10:54:17:240295: ip4-lookup
fib 0 dpo-idx 7 flow hash: 0x00000000
IPSEC_ESP: 10.1.2.79 -> 10.0.0.213
tos 0x00, ttl 252, length 152, checksum 0x2ed9
fragment id 0x0000
10:54:17:240301: ip4-local
IPSEC_ESP: 10.1.2.79 -> 10.0.0.213
tos 0x00, ttl 252, length 152, checksum 0x2ed9
fragment id 0x0000
10:54:17:240304: ipsec-if-input
IPSec: spi 3181023528 seq 29
10:54:17:240311: dpdk-esp-decrypt
cipher aes-cbc-128 auth sha1-96
ESP: spi 3181023528, seq 29
10:54:17:240323: dpdk-crypto-input
status: success
10:54:17:240335: dpdk-esp-decrypt-post
cipher aes-cbc-128 auth sha1-96
ICMP: 10.1.3.235 -> 10.0.1.253
tos 0x00, ttl 63, length 84, checksum 0x79df
fragment id 0xa7e1, flags DONT_FRAGMENT
ICMP echo_request checksum 0x5047
10:54:17:240338: ip4-input-no-checksum
ICMP: 10.1.3.235 -> 10.0.1.253
tos 0x00, ttl 63, length 84, checksum 0x79df
fragment id 0xa7e1, flags DONT_FRAGMENT
ICMP echo_request checksum 0x5047
10:54:17:240339: ip4-lookup
fib 0 dpo-idx 4 flow hash: 0x00000000
ICMP: 10.1.3.235 -> 10.0.1.253
tos 0x00, ttl 63, length 84, checksum 0x79df
fragment id 0xa7e1, flags DONT_FRAGMENT
ICMP echo_request checksum 0x5047
10:54:17:240341: ip4-rewrite
tx_sw_if_index 1 dpo-idx 4 : ipv4 via 10.0.1.253
VirtualFunctionEthernet0/6/0: 0efe85797fa60e0481cb96080800 flow hash: 0x00000000
00000000: 0efe85797fa60e0481cb9608080045000054a7e140003e017adf0a0103eb0a00
00000020: 01fd08005047549c00013de0335a00000000210e0200000000001011
10:54:17:240344: VirtualFunctionEthernet0/6/0-output
VirtualFunctionEthernet0/6/0
IP4: 0e:04:81:cb:96:08 -> 0e:fe:85:79:7f:a6
ICMP: 10.1.3.235 -> 10.0.1.253
tos 0x00, ttl 62, length 84, checksum 0x7adf
fragment id 0xa7e1, flags DONT_FRAGMENT
ICMP echo_request checksum 0x5047
10:54:17:240353: VirtualFunctionEthernet0/6/0-tx
VirtualFunctionEthernet0/6/0 tx queue 0
buffer 0x2925: current data 44, length 98, free-list 0, clone-count 0,
totlen-
nifb 0, trace 0x0
l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
l3-hdr-offset 14
PKT MBUF: port 1, nb_segs 1, pkt_len 98
buf_len 2176, data_len 98, ol_flags 0x0, data_off 172, phys_addr 0x2c4a49c0
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
Packet Offload Flags
IP4: 0e:04:81:cb:96:08 -> 0e:fe:85:79:7f:a6
ICMP: 10.1.3.235 -> 10.0.1.253
tos 0x00, ttl 62, length 84, checksum 0x7adf
fragment id 0xa7e1, flags DONT_FRAGMENT
ICMP echo_request checksum 0x5047
Packet 2
10:54:22:261159: dpdk-input
VirtualFunctionEthernet0/7/0 rx queue 0
buffer 0xd8d4: current data 14, length 184, free-list 0, clone-count 0,
totlen-nifb 0, trace 0x1
l4-cksum-computed l4-cksum-correct l2-hdr-offset 0
l3-hdr-offset 14
PKT MBUF: port 1, nb_segs 1, pkt_len 198
buf_len 2176, data_len 198, ol_flags 0x0, data_off 128, phys_addr
0x24763580
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
Packet Offload Flags
IP4: 1a:85:68:80:00:01 -> 0e:d2:b9:22:74:fe
IPSEC_ESP: 10.1.2.79 -> 10.0.0.213
tos 0x00, ttl 252, length 184, checksum 0x2eb9
fragment id 0x0000
10:54:22:261177: ip4-input
IPSEC_ESP: 10.1.2.79 -> 10.0.0.213
tos 0x00, ttl 252, length 184, checksum 0x2eb9
fragment id 0x0000
10:54:22:261183: ip4-lookup
fib 0 dpo-idx 7 flow hash: 0x00000000
IPSEC_ESP: 10.1.2.79 -> 10.0.0.213
tos 0x00, ttl 252, length 184, checksum 0x2eb9
fragment id 0x0000
10:54:22:261188: ip4-local
IPSEC_ESP: 10.1.2.79 -> 10.0.0.213
tos 0x00, ttl 252, length 184, checksum 0x2eb9
fragment id 0x0000
10:54:22:261192: ipsec-if-input
IPSec: spi 3181023528 seq 44738
10:54:22:261198: dpdk-esp-decrypt
cipher aes-cbc-128 auth sha1-96
ESP: spi 3181023528, seq 44738
10:54:22:261205: dpdk-crypto-input
status: auth failed
-Matt
On Dec 15, 2017, at 4:46 AM, Gonzalez Monroy, Sergio
<[email protected]> wrote:
Hi,
Could you show a full verbose trace of both packets from both endpoints?
Thanks,
Sergio
On 14/12/2017 21:26, Matthew Smith wrote:
Hi,
I’m experimenting with IPsec using the AES-NI MB cryptodev and seeing some
weird behavior.
I have a tunnel up. Both ends of the tunnel are VPP instances, both configured
to use the AES-NI MB cryptodev. The SAs are established with AES-CBC-128 and
SHA1.
I can ping from a host on one side of the tunnel to a host on the other side.
The packets successfully make it across the tunnel, as do the replies. When I
try to send TCP or UDP packets in either direction, the VPP instance on the
receiving side fails to decrypt the packet. The trace shows that the auth
failed. Of note in the packet traces, when TCP or UDP packets arrive at the
receiving side, the sequence numbers printed in the trace are wrong - i.e. they
are not what the sending side lists as the current sequence number.
If I ping, then try to send a DNS request, then ping again, I see the following:
successful ping:
02:21:37:455916: dpdk-esp-decrypt
cipher aes-cbc-128 auth sha1-96
ESP: spi 1333702992, seq 42
02:21:37:455921: dpdk-crypto-input
status: success
not successful DNS packet:
02:21:40:710125: dpdk-esp-decrypt
cipher aes-cbc-128 auth sha1-96
ESP: spi 1333702992, seq 4641
02:21:40:710129: dpdk-crypto-input
status: auth failed
successful ping:
02:21:43:857313: dpdk-esp-decrypt
cipher aes-cbc-128 auth sha1-96
ESP: spi 1333702992, seq 44
02:21:43:857318: dpdk-crypto-input
status: success
Before I spend several hours figuring out what’s going on, I thought I’d check
whether anyone else has seen this issue before or has any theories on what
might be causing it.
Thanks!
-Matt
_______________________________________________
vpp-dev mailing list
[email protected]
https://lists.fd.io/mailman/listinfo/vpp-dev
