Hi Bin,
That looks like a FIB entry caused by there being an ARP entry for 172.28.128.4
on GigE0/8/0. Is that true?
and it looks like from your trace that 172.28.128.4 is the tunnel endpoint. You
don’t want to route packets to the tunnel’s destination via the tunnel…
thanks,
neale
From: "Bin Zhang (binzhang)" <binzh...@cisco.com>
Date: Tuesday, 19 December 2017 at 02:28
To: "Neale Ranns (nranns)" <nra...@cisco.com>
Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Need Help on an ipsec Problem
Hi Neale,
Many thanks for the help. You are right that I did not enable/configure the
ipsec tunnel. I encountered a new problem after I fixed that. I think I still
miss some config to make this ipsec tunnel to work on both directions. I
received the echo reply from the destination, but vpp did not push the packet
into the tunnel. After the ip4 look up, it went to the rewirte and tx. How do
I configure the tunnel interface (or routing table) to make the packet to go
into the tunnel?
DBGvpp# show ip fib
..
172.28.128.4/32 – all the packet to this interface should be pushed to the
tunnel
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:20 to:[9:1224]
via:[1:84]]
[0] [@5]: ipv4 via 172.28.128.4 GigabitEthernet0/8/0:
08002773718f08002794519e0800
..
DBGvpp# show trace
------------------- Start of thread 0 vpp_main -------------------
Packet 1
06:54:53:849574: af-packet-input
af_packet: hw_if_index 2 next-index 4
tpacket2_hdr:
status 0x1 len 98 snaplen 98 mac 66 net 80
sec 0x5a386454 nsec 0x34d90965 vlan 0 vlan_tpid 0
06:54:53:849585: ethernet-input
IP4: 4e:9a:96:eb:16:33 -> 02:fe:f1:95:12:6c
06:54:53:849593: ip4-input
ICMP: 151.1.1.2 -> 172.28.128.4
tos 0x00, ttl 64, length 84, checksum 0x468d
fragment id 0x6ff8
ICMP echo_reply checksum 0x91d6
06:54:53:849596: ip4-lookup
fib 0 dpo-idx 3 flow hash: 0x00000000
ICMP: 151.1.1.2 -> 172.28.128.4
tos 0x00, ttl 64, length 84, checksum 0x468d
fragment id 0x6ff8
ICMP echo_reply checksum 0x91d6
06:54:53:849600: ip4-rewrite
tx_sw_if_index 1 dpo-idx 3 : ipv4 via 172.28.128.4 GigabitEthernet0/8/0:
08002773718f08002794519e0800 flow hash: 0x00000000
00000000: 08002773718f08002794519e0800450000546ff800003f01478d97010102ac1c
00000020: 8004000091d60d8000015464385a0000000008170d00000000001011
06:54:53:849604: GigabitEthernet0/8/0-output
GigabitEthernet0/8/0
IP4: 08:00:27:94:51:9e -> 08:00:27:73:71:8f
ICMP: 151.1.1.2 -> 172.28.128.4
tos 0x00, ttl 63, length 84, checksum 0x478d
fragment id 0x6ff8
ICMP echo_reply checksum 0x91d6
06:54:53:849609: GigabitEthernet0/8/0-tx
GigabitEthernet0/8/0 tx queue 0
buffer 0xd10f: current data 0, length 98, free-list 0, clone-count 0,
totlen-nifb 0, trace 0x0
IP4: 08:00:27:94:51:9e -> 08:00:27:73:71:8f
ICMP: 151.1.1.2 -> 172.28.128.4
tos 0x00, ttl 63, length 84, checksum 0x478d
fragment id 0x6ff8
ICMP echo_reply checksum 0x91d6
Thanks in advance,
Bin
From: "Neale Ranns (nranns)" <nra...@cisco.com>
Date: Sunday, December 17, 2017 at 8:07 AM
To: "Bin Zhang (binzhang)" <binzh...@cisco.com>, "vpp-dev@lists.fd.io"
<vpp-dev@lists.fd.io>
Subject: Re: [vpp-dev] Need Help on an ipsec Problem
Hi Bin,
I expect your IPsec tunnel is not enabled/configured to accept IPv4 packets.
Do:
sh int featuee <IPSEC-TUNNEL>
and if you see:
ip4-unicast:
ip4-drop
then the tunnel is configured to drop all IPv4 packets.
In order to enable any interface to receive IP it must either have an IP
address applied;
set int ip addr <TUNNEL> p.q.r.s/t
Or be unnumbered to another interface that has one;
set int ip addr <LOOPBACK> p.q.r.s/t
set int unnumbered <TUNNEL> use <LOOPBACK>
/neale
From: <vpp-dev-boun...@lists.fd.io> on behalf of "Bin Zhang (binzhang)"
<binzh...@cisco.com>
Date: Friday, 15 December 2017 at 23:04
To: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>
Subject: [vpp-dev] Need Help on an ipsec Problem
Hi Team,
I am new to VPP and would appreciate your comments and debugging tips on the
following problem.
I have set up an ipsec tunnel between two VMs (as shown in the diagram). The
client side is Strongswan and the server side is VPP. But I can not ping
through the tunnel from the client VM (on the left) to the subnet in the VPP VM
(on the right). In other words, “ping 151.1.1.2” failed. The packet is
dropped by VPP.
I used gdb to track the code execution. The “next index” was changed from 2
(IP4_INPUT_NEXT_LOOKUP) to 5 (IP4_INPUT_N_NEXT) in function
vnet_get_config_data.
/* Last 32 bits are next index. */
*next_index = d[n];
How do I move forward with my investigation?
More info:
[1] Packet trace of the ping packet. As we can see, the de-tunneling worked
and the (inner) ICMP packet was moved to ip4-input. But it was then dropped.
00:12:16:877859: dpdk-input
GigabitEthernet0/8/0 rx queue 0
buffer 0x494a: 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 0x10b25300
packet_type 0x0
IP4: 08:00:27:57:ad:8c -> 08:00:27:94:51:9e
IPSEC_ESP: 172.28.128.4 -> 172.28.128.5
tos 0x00, ttl 64, length 152, checksum 0xe6d7
fragment id 0xfb19, flags DONT_FRAGMENT
00:12:16:877919: ip4-input
IPSEC_ESP: 172.28.128.4 -> 172.28.128.5
tos 0x00, ttl 64, length 152, checksum 0xe6d7
fragment id 0xfb19, flags DONT_FRAGMENT
00:12:16:877924: ip4-lookup
fib 0 dpo-idx 7 flow hash: 0x00000000
IPSEC_ESP: 172.28.128.4 -> 172.28.128.5
tos 0x00, ttl 64, length 152, checksum 0xe6d7
fragment id 0xfb19, flags DONT_FRAGMENT
00:12:16:877926: ip4-local
IPSEC_ESP: 172.28.128.4 -> 172.28.128.5
tos 0x00, ttl 64, length 152, checksum 0xe6d7
fragment id 0xfb19, flags DONT_FRAGMENT
00:12:16:877927: ipsec-if-input
IPSec: spi 945163011 seq 22
00:12:16:877929: esp-decrypt
esp: crypto aes-cbc-192 integrity sha1-96
00:12:16:877956: ip4-input
ICMP: 172.28.128.4 -> 151.1.1.2
tos 0x00, ttl 64, length 84, checksum 0xc378
fragment id 0xb30c, flags DONT_FRAGMENT
ICMP echo_request checksum 0xe0c1
00:12:16:877958: ip4-drop
ICMP: 172.28.128.4 -> 151.1.1.2
tos 0x00, ttl 64, length 84, checksum 0xc378
fragment id 0xb30c, flags DONT_FRAGMENT
ICMP echo_request checksum 0xe0c1
00:12:16:877959: error-drop
ip4-input: valid ip4 packets
[2] Ikev2 profile on VPP
DBGvpp# show ikev2 profile
profile pr1
auth-method shared-key-mic auth data Vpp123
local id-type fqdn data vpp.home
remote id-type fqdn data ss.vpn.example.com
local traffic-selector addr 151.1.1.0 - 151.1.1.255 port 0 - 65535 protocol 0
remote traffic-selector addr 172.28.128.4 - 172.28.128.4 port 0 - 65535
protocol 0
[3] Tunnel info on VPP
DBGvpp# show ikev2 sa
iip 172.28.128.4 ispi e934164d91e57f38 rip 172.28.128.5 rspi d17da080720b0634
encr:aes-cbc-256 prf:hmac-sha1 integ:sha1-96 dh-group:modp-2048
nonce i:62ecfcedebb59e043bc9ccfcbceeb17ab32439f93cb0005bb81633f0a914fa48
r:15ebb5e167b57c0079951a9ea2c77198b08d8398002a82c333ecd92a96e76f12
SK_d 88d1534d0e99c4430059c82c7b6d20b59ef54bbd
SK_a i:4766ba54d3f2d68c3575f0610f14226b7066bf53
r:b27d54dcb76cb7f261a1d9e25e93cb91ec67864c
SK_e i:b0c0719ad7d219a8a2b51f8b45ca4e9af6ab7bf5e4e2e50b3a6b05e8fc4d1095
r:475962cd9e562ee5f7581fecdfe50e12ab56fd946bed64283d19b5799c4edef8
SK_p i:9ca87f1f298ddddb29948878900f0ae4fe3d1cb3
r:aa950829e67985a7395e7c96cb5f1eef4c7c46a4
identifier (i) fqdn ss.vpn.example.com
identifier (r) fqdn vpp.home
child sa 0:
encr:aes-cbc-192 integ:sha1-96 esn:yes
spi(i) c8423981 spi(r) fc77442b
SK_e i:fb2002ca400eda904856a61894bbb445b5df9f5c0b647034
r:54618f411597bb6b92d619b9bd10b2fe86d50530b86b00bd
SK_a i:2ef6391d25c7cc5b32bef76194201abdc80956f6
r:0b211b0a7845b380146595535c7f99aa994cc3c9
traffic selectors (i):
0 type 7 protocol_id 0 addr 172.28.128.4 - 172.28.128.4 port 0 - 65535
traffic selectors (r):
0 type 7 protocol_id 0 addr 151.1.1.0 - 151.1.1.255 port 0 - 65535
iip 172.28.128.4 ispi e934164d91e57f38 rip 172.28.128.5 rspi d17da080720b0634
[4] Tunnel info on Client
vagrant@client1:/etc$ sudo ip xfrm stat
src 172.28.128.4 dst 172.28.128.5
proto esp spi 0xfc77442b reqid 1 mode tunnel
replay-window 0 flag af-unspec esn
auth-trunc hmac(sha1) 0x2ef6391d25c7cc5b32bef76194201abdc80956f6 96
enc cbc(aes) 0xfb2002ca400eda904856a61894bbb445b5df9f5c0b647034
anti-replay esn context:
seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x1
replay_window 32, bitmap-length 1
00000000
src 172.28.128.5 dst 172.28.128.4
proto esp spi 0xc8423981 reqid 1 mode tunnel
replay-window 0 flag af-unspec esn
auth-trunc hmac(sha1) 0x0b211b0a7845b380146595535c7f99aa994cc3c9 96
enc cbc(aes) 0x54618f411597bb6b92d619b9bd10b2fe86d50530b86b00bd
anti-replay esn context:
seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0
replay_window 32, bitmap-length 1
00000000
Thanks,
Bin
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
