Hi, all
I met an issue when enable proxy-arp in VPP.
I have two containers, for instance, cont1 and cont2. Then set two VETH pairs
for the two containers, 192.168.1.1 for cont1, 192.168.1.2 for cont2. The
default route is below. The 169.254.1.1 is a dummy address.
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 169.254.1.1 0.0.0.0 UG 0 0
0 eth0
169.254.1.1 0.0.0.0 255.255.255.255 UH 0 0 0
eth0
Then in VPP, I attach to the two veth interface over the linux AF_PACKET
interface.
vpp# show interface
Name Idx State Counter Count
af_packet0 5 up
af_packet1 6 up
Then config the proxy-arp and FIB:
vpp# set ip arp proxy 169.254.1.1 - 169.254.1.1
vpp# set int proxy-arp af_packet0 enable
vpp# set int proxy-arp af_packet1 enable
vpp# ip route add 192.168.1.1/32 via af_packet0
vpp# ip route add 192.168.1.2/32 via af_packet1
After that if I ping from cont1 to cont2, the cont2 will receive the packet and
drop them all right away. I try to tcpdump the packet, get that:
[cid:image001.png@01D29761.C4AFC080]
At the picture above, the left part is the packet that container1 sent to
container2, and the right part is what container2 received.
You can see that the first 14 bytes are dropped by VPP, in which the first 12
bytes is src and dst MAC, and the 13-14 bytes "0800" represents the type is
VETH.
I met this problems in VPP16.06. And in VPP17.01, after my configuring and
trying to ping, the vpp will restart itself and clean all my previous
configuration:(.
I use "vppctl trace add dpdk-input 1" to detect the change of the packet in
VPP. And ping from cont2(192.168.1.2) to cont1(192.168.1.1), get the result as
below.
When the packet is sent out by the node "af_packet0-tx", the length of the
packet is 84 bytes.
I wonder why such operation will cut the first 14 bytes
00:54:30:521206: dpdk-input
af_packet1 rx queue 0
buffer 0x17af304: current data 0, length 98, free-list 0, totlen-nifb 0,
trace 0x9
PKT MBUF: port 1, nb_segs 1, pkt_len 98
buf_len 2176, data_len 98, ol_flags 0x0,
packet_type 0x0
IP4: 3e:ca:93:00:28:bd -> 02:fe:79:66:eb:9a
ICMP: 192.168.1.2 -> 192.168.1.1
tos 0x00, ttl 64, length 84, checksum 0x6b24
fragment id 0x4c31, flags DONT_FRAGMENT
ICMP echo_request checksum 0x29a5
00:54:30:521207: ethernet-input
IP4: 3e:ca:93:00:28:bd -> 02:fe:79:66:eb:9a
00:54:30:521208: ip4-input
ICMP: 192.168.1.2 -> 192.168.1.1
tos 0x00, ttl 64, length 84, checksum 0x6b24
fragment id 0x4c31, flags DONT_FRAGMENT
ICMP echo_request checksum 0x29a5
00:54:30:521208: ip4-lookup
fib 0 adj-idx 5 : af_packet0 flow hash: 0x00000000
ICMP: 192.168.1.2 -> 192.168.1.1
tos 0x00, ttl 64, length 84, checksum 0x6b24
fragment id 0x4c31, flags DONT_FRAGMENT
ICMP echo_request checksum 0x29a5
00:54:30:521209: ip4-rewrite-transit
tx_sw_if_index 5 adj-idx 5 : af_packet0 flow hash: 0x00000000
0xc0a8: 40:00:3f:01:6c:24 -> 45:00:00:54:4c:31
00:54:30:521209: af_packet0-output
af_packet0
0xc0a8: 40:00:3f:01:6c:24 -> 45:00:00:54:4c:31
00:54:30:521210: af_packet0-tx
af_packet0 tx queue 0
buffer 0x17af304: current data 14, length 84, free-list 0, totlen-nifb 0,
trace 0x9
0xc0a8: 40:00:3f:01:6c:24 -> 45:00:00:54:4c:31
Best Regards
Pan, Xiao
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
