Now I run into another issue when using linux-cp to create pair for ETH0, VPP0
on both VPP0 and VPP1:
FRR0--------VPP 0(192.168.1.6)------------- (192.168.1.1)R
(192.168.2.1)---------------------VPP1 (192.168.2.6)---------FRR1
VPP0 ETH0
ETH0
VPP0
FRR0 trying to connect to FRR1, the BGP syn packet received in VPP0, but it
can't find adjacency and dropped it. Looks to me linux-cp-xc-ip4 it not using
the FIB table to route the packets. Is there anything I should configure to
make it work?
Here is the packet trace:
Packet 32
02:28:53:416670: virtio-input
virtio: hw_if_index 8 next-index 4 vring 0 len 74
hdr: flags 0x00 gso_type 0x00 hdr_len 0 gso_size 0 csum_start 0 csum_offset
0 num_buffers 1
02:28:53:416678: ethernet-input
IP4: fa:16:3f:30:99:2d -> fa:16:3f:dd:32:d9
02:28:53:416683: ip4-input
TCP: 192.168.1.6 -> 192.168.2.6
tos 0xc0, ttl 64, length 60, checksum 0xaa00 dscp CS6 ecn NON_ECN
fragment id 0x0b9f, flags DONT_FRAGMENT
TCP: 35390 -> 179
seq. 0xc9f0d6b6 ack 0x00000000
flags 0x02 SYN, tcp header: 40 bytes
window 26880, checksum 0x3a9f
02:28:53:416689: linux-cp-xc-ip4
lcp-xc: itf:1 adj:0
02:28:53:416705: ip4-drop
MHRP: 8.0.69.192 -> 0.60.11.159
version 15, header length 40
tos 0x16, ttl 63, length 16349, checksum 0x992d (should be 0xfd08) dscp
unknown ecn ECT_1
fragment id 0x32d9 offset 53424, flags
MORE_FRAGMENTSDONT_FRAGMENTCONGESTION
02:28:53:416708: error-drop
rx:tap1
02:28:53:416710: drop
ethernet-input: no error
vpp# show adj
[@0] ipv4-glean: [src:0.0.0.0/0] tn-eth0: mtu:9000 next:1 flags:[]
fffffffffffffa163f30992d0806
[@1] ipv4-glean: [src:192.168.1.0/24] tn-eth0: mtu:9000 next:1 flags:[]
fffffffffffffa163f30992d0806
[@2] ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:7 flags:[]
fa163fdd32d9fa163f30992d0800
[@3] ipv4-glean: [src:0.0.0.0/0] tn-eth1: mtu:9000 next:2 flags:[]
fffffffffffffa163f93d4ea0806
[@4] ipv4-glean: [src:192.168.10.0/24] tn-eth1: mtu:9000 next:2 flags:[]
fffffffffffffa163f93d4ea0806
[@5] ipv4 via 192.168.10.1 tn-eth1: mtu:9000 next:6 flags:[]
fa163f3186d0fa163f93d4ea0800
[@6] ipv4-glean: [src:0.0.0.0/0] tn-eth2: mtu:9000 next:3 flags:[]
fffffffffffffa163f3e79000806
[@7] ipv4-glean: [src:192.168.100.0/24] tn-eth2: mtu:9000 next:3 flags:[]
fffffffffffffa163f3e79000806
[@8] ipv4-glean: [src:0.0.0.0/0] host-vppeth: mtu:9000 next:4 flags:[]
ffffffffffff02fe6fdf582e0806
[@9] ipv4-glean: [src:192.168.11.0/24] host-vppeth: mtu:9000 next:4 flags:[]
ffffffffffff02fe6fdf582e0806
[@10] ipv4-mcast: tn-eth2: mtu:9000 next:5 flags:[] 01005e000000fa163f3e79000800
[@11] ipv6-mcast: tn-eth2: mtu:9000 next:5 flags:[] 333300000000fa163f3e790086dd
[@12] ipv6-glean: [src:0.0.0.0/0] tn-eth2: mtu:9000 next:2 flags:[]
fffffffffffffa163f3e790086dd
[@13] ipv4 via 0.0.0.0 ipip0: mtu:9000 next:9 flags:[fixup-ip4o4 ]
45000000000000004004f69dc0a80106c0a80206
stacked-on entry:31:
[@3]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:7 flags:[]
fa163fdd32d9fa163f30992d0800
[@14] ipv4 via 192.168.11.2 host-vppeth: mtu:9000 next:10 flags:[]
f2b67ee4bb8e02fe6fdf582e0800
[@15] ipv4 via 192.168.100.20 tn-eth2: mtu:9000 next:5 flags:[]
fa163fa92cccfa163f3e79000800
[@16] ipv6 via fe80::f816:3fff:fea9:2ccc tn-eth2: mtu:9000 next:5 flags:[]
fa163fa92cccfa163f3e790086dd
[@17] ipv4-mcast: tn-eth0: mtu:9000 next:7 flags:[] 01005e000000fa163f30992d0800
[@18] ipv6-mcast: tn-eth0: mtu:9000 next:6 flags:[] 333300000000fa163f30992d86dd
[@19] ipv6-glean: [src:0.0.0.0/0] tn-eth0: mtu:9000 next:3 flags:[]
fffffffffffffa163f30992d86dd
vpp# show ip fib 192.168.2.6
ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ]
epoch:0 flags:none locks:[adjacency:1, recursive-resolution:2, default-route:1,
lcp-rt:1, ]
192.168.2.6/32 fib:0 index:31 locks:3
recursive-resolution refs:1 src-flags:added,contributing,active, cover:11
path-list:[52] locks:4 flags:shared, uPRF-list:47 len:1 itfs:[1, ]
path:[72] pl-index:52 ip4 weight=1 pref=0 attached-nexthop:
oper-flags:resolved,
192.168.1.1 tn-eth0
[@0]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:7 flags:[]
fa163fdd32d9fa163f30992d0800
forwarding: unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:32 buckets:1 uRPF:47 to:[592:61840]]
[0] [@5]: ipv4 via 192.168.1.1 tn-eth0: mtu:9000 next:7 flags:[]
fa163fdd32d9fa163f30992d0800
Thanks in advance for any help,
Wei
________________________________
From: Wei Huang
Sent: Tuesday, November 16, 2021 10:08 PM
To: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io>
Subject: VPP linux-cp plugin with multicast packets
I am using the linux-cp plugin in VPP (v21.06) and run into issues with
multicast packet from OSPF.
I try to make FRR work with VPP. I created a lcp pair (ETH2-VPP2), ETH2
directly connect to router using OSPF.
FRR------VPP (192.168.100.5)----------Router (192.168.100.20)
VPP2 ETH2 ETH1
vppctl lcp create tn-eth2 host-if vpp2 netns t3-tap-ns
ip netns exec t3-tap-ns ip addr add 192.168.100.5/24 dev vpp2
ip netns exec t3-tap-ns ip link set dev vpp2 up
When I do tshark on Router ETH1, I can see hello packets from both sides, i.e.
192.168.100.5->224.0.0.5 and 192.168.100.20->224.0.0.5.
But when do tshark on VPP2, I can only see hello packets from
192.168.100.5->224.0.0.5. Seems VPP didn't forward multicast packets to VPP2.
When I do packet trace, this is what I got:
01:21:34:796763: dpdk-input
tn-eth2 rx queue 0
buffer 0x93b1f: current data 0, length 82, buffer-pool 0, ref-count 1,
totlen-nifb 0, trace handle 0x0
ext-hdr-valid
l4-cksum-computed l4-cksum-correct
PKT MBUF: port 2, nb_segs 1, pkt_len 82
buf_len 2176, data_len 82, ol_flags 0x0, data_off 128, phys_addr 0xb20ec840
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05
OSPF: 192.168.100.20 -> 224.0.0.5
tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
fragment id 0xc2dc
01:21:34:796805: ethernet-input
frame: flags 0x1, hw-if-index 3, sw-if-index 3
IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05
01:21:34:796836: ip4-input
OSPF: 192.168.100.20 -> 224.0.0.5
tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
fragment id 0xc2dc
01:21:34:796842: ip4-mfib-forward-lookup
fib 0 entry 0
01:21:34:796846: ip4-mfib-forward-rpf
entry 0 itf -1 flags
01:21:34:796847: ip4-drop
OSPF: 192.168.100.20 -> 224.0.0.5
tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
fragment id 0xc2dc
01:21:34:796849: error-drop
rx:tn-eth2
01:21:34:796853: drop
ip4-input: Multicast RPF check failed
Do I need to do anything special for multicast packets to be directed to the
TAP interface?
Regards,
Wei
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20524): https://lists.fd.io/g/vpp-dev/message/20524
Mute This Topic: https://lists.fd.io/mt/87112237/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
