Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
Hi Mechthild. From: Mechthild Buescher Date: Monday, 5 July 2021 at 16:25 To: Neale Ranns , Benoit Ganne (bganne) , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' Hi Neale, I tried different configs in several tables – sorry for confusion Your suggestion to use ‘via host-Vpp2Host.4093’ doesn’t work properly. Only if I ping via table 4093 before I do the ping via table 1, it is working as expected. Else, if I ping via table 1 on a freshly configured VPP, it’s failing. I do have the following config: set interface state NCIC-1-v1 up create host-interface name Vpp2Host set interface state host-Vpp2Host up ip table add 4093 create sub-interfaces host-Vpp2Host 4093 set interface state host-Vpp2Host.4093 up set interface ip table host-Vpp2Host.4093 4093 set interface ip address host-Vpp2Host.4093 198.19.255.249/29 ip table add 1 create sub-interfaces NCIC-1-v1 1 set interface state NCIC-1-v1.1 up set interface ip table NCIC-1-v1.1 1 set interface ip address NCIC-1-v1.1 10.10.203.3/29 ip route add 198.19.255.248/29 table 1 via host-Vpp2Host.4093 Right after configuring VPP, I see the following : # vppctl show ip fib 198.19.255.253 table 4093 ipv4-VRF:4093, fib_index:1, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, ] 198.19.255.248/29 fib:1 index:12 locks:2 interface refs:1 entry-flags:connected,attached, src-flags:added,contributing,active, cover:-1 path-list:[21] locks:2 uPRF-list:13 len:1 itfs:[3, ] path:[23] pl-index:21 ip4 weight=1 pref=0 attached: oper-flags:resolved, cfg-flags:glean, host-Vpp2Host.4093 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:13 to:[0:0]] [0] [@4]: ipv4-glean: [src:198.19.255.248/29] host-Vpp2Host.4093: mtu:9000 next:1 flags:[] 02fe67f3126c81000ffd0806 Comparing this … # vppctl show ip fib 198.19.255.253 table 1 ipv4-VRF:1, fib_index:2, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, adjacency:1, ] 198.19.255.248/29 fib:2 index:25 locks:2 CLI refs:1 entry-flags:attached,import, src-flags:added,contributing,active, path-list:[34] locks:2 flags:shared, uPRF-list:28 len:1 itfs:[3, ] path:[38] pl-index:34 ip4 weight=1 pref=0 attached: oper-flags:resolved, host-Vpp2Host.4093 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:26 buckets:1 uRPF:28 to:[0:0]] [0] [@4]: ipv4-glean: [src:0.0.0.0/0] host-Vpp2Host.4093: mtu:9000 next:1 flags:[] 02fe67f3126c81000ffd0806 With this … Tells me source address selection (SAS) is broken. This is confirmed with a trace (from the other end of a veth) 15:05:40.111878 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 198.19.255.253 tell 0.0.0.0, length 28 I’ll need to fix that. /neale At this point ‘vppctl ping 198.19.255.253 table-id 1’ doesn’t work. If I run ‘vppctl ping 198.19.255.253 table-id 4093’, the FIBs look differently: # vppctl show ip fib 198.19.255.253 table 4093 ipv4-VRF:4093, fib_index:1, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, adjacency:1, ] 198.19.255.253/32 fib:1 index:29 locks:3 adjacency refs:1 entry-flags:attached, src-flags:added,contributing,active, cover:12 path-list:[39] locks:2 uPRF-list:33 len:1 itfs:[3, ] path:[43] pl-index:39 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved, 198.19.255.253 host-Vpp2Host.4093 [@0]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] 2aa47cd24fb802fe67f3126c81000ffd0800 Extensions: path:43 adj-flags:[refines-cover] forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:30 buckets:1 uRPF:33 to:[4:384]] [0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] 2aa47cd24fb802fe67f3126c81000ffd0800 # vppctl show ip fib 198.19.255.253 table 1 ipv4-VRF:1, fib_index:2, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, adjacency:1, ] 198.19.255.253/32 fib:2 index:30 locks:2 attached_export refs:1 entry-flags:attached,exclusive, src-flags:added,contributing,active, path-list:[40] locks:2 flags:exclusive, uPRF-list:34 len:1 itfs:[3, ] path:[44] pl-index:40 ip4 weight=1 pref=0 exclusive: oper-flags:resolved, cfg-flags:exclusive, [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] 2aa47cd24fb802fe67f3126c81000ffd0800 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:31 buckets:1 uRPF:34 to:[5:480]] [0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] 2aa47cd24fb802fe67f3126c81000ffd0800 Now the ‘vppctl ping 198.19.255.253 table-id 1’ is working fine. I guess, that ARP handling is not working correctly. Any suggestions on what to do next? BR/Mechthild From: vpp-dev@lists.fd.io On Behalf
Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
Hi Neale, I tried different configs in several tables – sorry for confusion Your suggestion to use ‘via host-Vpp2Host.4093’ doesn’t work properly. Only if I ping via table 4093 before I do the ping via table 1, it is working as expected. Else, if I ping via table 1 on a freshly configured VPP, it’s failing. I do have the following config: set interface state NCIC-1-v1 up create host-interface name Vpp2Host set interface state host-Vpp2Host up ip table add 4093 create sub-interfaces host-Vpp2Host 4093 set interface state host-Vpp2Host.4093 up set interface ip table host-Vpp2Host.4093 4093 set interface ip address host-Vpp2Host.4093 198.19.255.249/29 ip table add 1 create sub-interfaces NCIC-1-v1 1 set interface state NCIC-1-v1.1 up set interface ip table NCIC-1-v1.1 1 set interface ip address NCIC-1-v1.1 10.10.203.3/29 ip route add 198.19.255.248/29 table 1 via host-Vpp2Host.4093 Right after configuring VPP, I see the following : # vppctl show ip fib 198.19.255.253 table 4093 ipv4-VRF:4093, fib_index:1, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, ] 198.19.255.248/29 fib:1 index:12 locks:2 interface refs:1 entry-flags:connected,attached, src-flags:added,contributing,active, cover:-1 path-list:[21] locks:2 uPRF-list:13 len:1 itfs:[3, ] path:[23] pl-index:21 ip4 weight=1 pref=0 attached: oper-flags:resolved, cfg-flags:glean, host-Vpp2Host.4093 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:13 to:[0:0]] [0] [@4]: ipv4-glean: [src:198.19.255.248/29] host-Vpp2Host.4093: mtu:9000 next:1 flags:[] 02fe67f3126c81000ffd0806 # vppctl show ip fib 198.19.255.253 table 1 ipv4-VRF:1, fib_index:2, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, adjacency:1, ] 198.19.255.248/29 fib:2 index:25 locks:2 CLI refs:1 entry-flags:attached,import, src-flags:added,contributing,active, path-list:[34] locks:2 flags:shared, uPRF-list:28 len:1 itfs:[3, ] path:[38] pl-index:34 ip4 weight=1 pref=0 attached: oper-flags:resolved, host-Vpp2Host.4093 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:26 buckets:1 uRPF:28 to:[0:0]] [0] [@4]: ipv4-glean: [src:0.0.0.0/0] host-Vpp2Host.4093: mtu:9000 next:1 flags:[] 02fe67f3126c81000ffd0806 At this point ‘vppctl ping 198.19.255.253 table-id 1’ doesn’t work. If I run ‘vppctl ping 198.19.255.253 table-id 4093’, the FIBs look differently: # vppctl show ip fib 198.19.255.253 table 4093 ipv4-VRF:4093, fib_index:1, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, adjacency:1, ] 198.19.255.253/32 fib:1 index:29 locks:3 adjacency refs:1 entry-flags:attached, src-flags:added,contributing,active, cover:12 path-list:[39] locks:2 uPRF-list:33 len:1 itfs:[3, ] path:[43] pl-index:39 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved, 198.19.255.253 host-Vpp2Host.4093 [@0]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] 2aa47cd24fb802fe67f3126c81000ffd0800 Extensions: path:43 adj-flags:[refines-cover] forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:30 buckets:1 uRPF:33 to:[4:384]] [0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] 2aa47cd24fb802fe67f3126c81000ffd0800 # vppctl show ip fib 198.19.255.253 table 1 ipv4-VRF:1, fib_index:2, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, adjacency:1, ] 198.19.255.253/32 fib:2 index:30 locks:2 attached_export refs:1 entry-flags:attached,exclusive, src-flags:added,contributing,active, path-list:[40] locks:2 flags:exclusive, uPRF-list:34 len:1 itfs:[3, ] path:[44] pl-index:40 ip4 weight=1 pref=0 exclusive: oper-flags:resolved, cfg-flags:exclusive, [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] 2aa47cd24fb802fe67f3126c81000ffd0800 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:31 buckets:1 uRPF:34 to:[5:480]] [0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] 2aa47cd24fb802fe67f3126c81000ffd0800 Now the ‘vppctl ping 198.19.255.253 table-id 1’ is working fine. I guess, that ARP handling is not working correctly. Any suggestions on what to do next? BR/Mechthild From: vpp-dev@lists.fd.io On Behalf Of Neale Ranns via lists.fd.io Sent: Friday, 2 July 2021 11:18 To: Mechthild Buescher ; Benoit Ganne (bganne) ; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' From: Mechthild Buescher mailto:mechthild.buesc...@ericsson.com>> Date: Thursday, 1 July 2021 at 14:51 To: Neale Ranns mailto:ne...@graphiant.com>>, Benoit Ganne (bganne) mailto:bga...@cisco.com>>, vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> mailto:vpp-dev@lists.f
Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
From: Mechthild Buescher Date: Thursday, 1 July 2021 at 14:51 To: Neale Ranns , Benoit Ganne (bganne) , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' Hi all, I still don’t have success. This is the configuration I tried: set interface state NCIC-1-v1 up create host-interface name Vpp2Host set interface state host-Vpp2Host up ip table add 4093 create sub-interfaces host-Vpp2Host 4093 set interface state host-Vpp2Host.4093 up set interface ip table host-Vpp2Host.4093 4093 set interface ip address host-Vpp2Host.4093 198.19.255.249/29 ip table add 1 create sub-interfaces NCIC-1-v1 1 set interface state NCIC-1-v1.1 up set interface ip table NCIC-1-v1.1 1 did you miss giving the interface an address here… ip route add 198.19.255.248/29 table 1 via 0.0.0.0 next-hop-table 4093 this … ip table add 2 create sub-interfaces NCIC-1-v1 2 set interface state NCIC-1-v1.2 up set interface ip table NCIC-1-v1.2 2 set interface ip address NCIC-1-v1.2 10.10.203.19/29 ip route add 198.19.255.248/29 table 2 via 198.19.255.249 next-hop-table 4093 this … ip table add 3 create sub-interfaces NCIC-1-v1 3 set interface state NCIC-1-v1.3 up set interface ip table NCIC-1-v1.3 3 set interface ip address NCIC-1-v1.3 10.10.203.19/29 ip route add 198.19.255.248/29 table 3 via 198.19.255.249 ip4-look-in-table 4093 and this are all different. Are you hedging your bets This is how I tried the config: vppctl ping 198.19.255.253 table-id 4093 116 bytes from 198.19.255.253: icmp_seq=2 ttl=64 time=9.2805 ms vppctl ping 198.19.255.253 table-id 1 Failed: no egress interface vppctl ping vppctl sh int addr Ext-0 (dn): NCIC-1-v1 (up): NCIC-1-v1.1 (up): NCIC-1-v1.2 (up): L3 10.10.203.19/29 ip4 table-id 2 fib-idx 3 NCIC-1-v1.3 (up): L3 10.10.203.19/29 ip4 table-id 3 fib-idx 4 NCIC-1-v2 (dn): Radio-0 (dn): host-Vpp2Host (up): host-Vpp2Host.4093 (up): L3 198.19.255.249/29 ip4 table-id 4093 fib-idx 1 local0 (dn):table-id 2 Statistics: 5 sent, 0 received, 100% packet loss vppctl ping 198.19.255.253 table-id 3 Failed: no egress interface The ping code uses the FIB to find egress interface. To do this it does a lookup on the destination address and then asks of the resulting FIB entry to get a resolving interface. A FIB entry that requires a second lookup cannot return a resolving interface. Two options, try ‘ping X source ’ to give ping the interface you want used, or add the routes the right way. ip route add 198.19.255.248/29 table 3 via host-Vpp2Host.4093 /neale This is what I see in vpp: vppctl sh int addr Ext-0 (dn): NCIC-1-v1 (up): NCIC-1-v1.1 (up): NCIC-1-v1.2 (up): L3 10.10.203.19/29 ip4 table-id 2 fib-idx 3 NCIC-1-v1.3 (up): L3 10.10.203.19/29 ip4 table-id 3 fib-idx 4 NCIC-1-v2 (dn): Radio-0 (dn): host-Vpp2Host (up): host-Vpp2Host.4093 (up): L3 198.19.255.249/29 ip4 table-id 4093 fib-idx 1 local0 (dn): vppctl sh ip fib 198.19.255.253 ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[default-route:1, ] 0.0.0.0/0 fib:0 index:0 locks:2 default-route refs:1 entry-flags:drop, src-flags:added,contributing,active, path-list:[0] locks:2 flags:drop, uPRF-list:0 len:0 itfs:[] path:[0] pl-index:0 ip4 weight=1 pref=0 special: cfg-flags:drop, [@0]: dpo-drop ip4 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:0 to:[0:0]] [0] [@0]: dpo-drop ip4 ipv4-VRF:4093, fib_index:1, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, adjacency:1, recursive-resolution:2, ] 198.19.255.253/32 fib:1 index:41 locks:2 adjacency refs:1 entry-flags:attached, src-flags:added,contributing,active, cover:12 path-list:[54] locks:2 uPRF-list:46 len:1 itfs:[6, ] path:[60] pl-index:54 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved, 198.19.255.253 host-Vpp2Host.4093 [@0]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:3 flags:[] a215f39524f302fe349f8c8a81000ffd0800 Extensions: path:60 adj-flags:[refines-cover] forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:42 buckets:1 uRPF:46 to:[6:576]] [0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:3 flags:[] a215f39524f302fe349f8c8a81000ffd0800 ipv4-VRF:1, fib_index:2, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, ] 198.19.255.248/29 fib:2 index:21 locks:2 CLI refs:1 src-flags:added,contributing,active, path-list:[31] locks:2 flags:shared, uPRF-list:23 len:0 itfs:[] path:[33] pl-index:31 ip4 weight=1 pref=0 deag: oper-flags:resolved, fib-index:1 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:22 buckets:1 uRPF:23 to:[0:0]] [0] [@11]: dst-address,unicast lookup in ipv4-VRF:4093 ipv4-VRF:2, fib_index:3, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2
Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
,contributing,active, path-list:[44] locks:2 flags:drop, uPRF-list:36 len:0 itfs:[] path:[48] pl-index:44 ip4 weight=1 pref=0 special: cfg-flags:drop, [@0]: dpo-drop ip4 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:33 buckets:1 uRPF:36 to:[0:0]] [0] [@0]: dpo-drop ip4 Do you have any ideas? BR/Mechthild From: Neale Ranns Sent: Thursday, 1 July 2021 11:42 To: Benoit Ganne (bganne) ; Mechthild Buescher ; vpp-dev@lists.fd.io Subject: Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' From: Benoit Ganne (bganne) mailto:bga...@cisco.com>> Date: Thursday, 1 July 2021 at 11:35 To: Neale Ranns mailto:ne...@graphiant.com>>, Mechthild Buescher mailto:mechthild.buesc...@ericsson.com>>, vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> mailto:vpp-dev@lists.fd.io>> Subject: RE: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' >> As 198.19.255.249 is the IP of host-Vpp2Host.4093, VPP interprets it as >> you want to deliver the packet locally instead of forwarding it. Try >> changing it to: >> ip route add 198.19.255.248/29 table 1 via 0.0.0.0 next-hop-table 4093 > 0.0.0.0/32 in any table is a drop. One cannot specify a route to be > recursive via another network, i.e. via 0.0.0.0/0, VPP doesn't support > that. I do not disagree with the rest of your comment, however this worked for me though - maybe because of some odd cli behavior? probably vpp# create packet-generator interface pg0 vpp# create packet-generator interface pg1 vpp# set int ip addr pg0 192.168.1.1/24 vpp# set int st pg0 up vpp# ip table add 4093 vpp# set int st pg1 up vpp# set int ip table pg1 4093 vpp# set int ip address pg1 198.19.255.249/29 vpp# ip neigh pg1 198.19.255.253 1.2.3 static vpp# ip route add 198.19.255.248/29 via 0.0.0.0 next-hop-table 4093 vpp# sh ip fib 198.19.255.253 table 0 ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[default-route:1, ] 198.19.255.248/29 fib:0 index:21 locks:2 CLI refs:1 src-flags:added,contributing,active, path-list:[29] locks:2 flags:shared, uPRF-list:27 len:0 itfs:[] path:[33] pl-index:29 ip4 weight=1 pref=0 deag: oper-flags:resolved, fib-index:1 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:23 buckets:1 uRPF:27 to:[1:100]] [0] [@12]: dst-address,unicast lookup in ipv4-VRF:4093 this is a lookup-DPO. Looks like the CLI interprets ‘via 0.0.0.0 next-hop-table 4093’ and ‘via ip4-look-in-table 4093’ as the same thing. /neale And tracing seems to give the expected result: 00:00:02:247022: pg-input stream x, 100 bytes, sw_if_index 1 current data 0, length 100, buffer-pool 0, ref-count 1, trace handle 0x0 UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 64, length 100, checksum 0xf2cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247055: ip4-input UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 64, length 100, checksum 0xf2cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247079: ip4-lookup fib 0 dpo-idx 0 flow hash: 0x UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 64, length 100, checksum 0xf2cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247088: lookup-ip4-dst fib-index:1 addr:198.19.255.253 load-balance:22 00:00:02:247092: ip4-rewrite tx_sw_if_index 2 dpo-idx 4 : ipv4 via 198.19.255.253 pg1: mtu:9000 next:3 flags:[] 00010002000302fe257345030800 flow hash: 0x : 00010002000302fe25734503080045643f11f3cdc0a80102c613 0020: fffd10e104d200487deb000102030405060708090a0b0c0d0e0f1011 00:00:02:247099: pg1-output pg1 IP4: 02:fe:25:73:45:03 -> 00:01:00:02:00:03 UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 63, length 100, checksum 0xf3cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247106: pg1-tx buffer 0x9ffd4: current data -14, length 114, buffer-pool 0, ref-count 1, trace handle 0x0 loop-counter 1 IP4: 02:fe:25:73:45:03 -> 00:01:00:02:00:03 UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 63, length 100, checksum 0xf3cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19684): https://lists.fd.io/g/vpp-dev/message/19684 Mute This Topic: https://lists.fd.io/mt/83895986/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
From: Benoit Ganne (bganne) Date: Thursday, 1 July 2021 at 11:35 To: Neale Ranns , Mechthild Buescher , vpp-dev@lists.fd.io Subject: RE: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' >> As 198.19.255.249 is the IP of host-Vpp2Host.4093, VPP interprets it as >> you want to deliver the packet locally instead of forwarding it. Try >> changing it to: >> ip route add 198.19.255.248/29 table 1 via 0.0.0.0 next-hop-table 4093 > 0.0.0.0/32 in any table is a drop. One cannot specify a route to be > recursive via another network, i.e. via 0.0.0.0/0, VPP doesn't support > that. I do not disagree with the rest of your comment, however this worked for me though - maybe because of some odd cli behavior? probably vpp# create packet-generator interface pg0 vpp# create packet-generator interface pg1 vpp# set int ip addr pg0 192.168.1.1/24 vpp# set int st pg0 up vpp# ip table add 4093 vpp# set int st pg1 up vpp# set int ip table pg1 4093 vpp# set int ip address pg1 198.19.255.249/29 vpp# ip neigh pg1 198.19.255.253 1.2.3 static vpp# ip route add 198.19.255.248/29 via 0.0.0.0 next-hop-table 4093 vpp# sh ip fib 198.19.255.253 table 0 ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[default-route:1, ] 198.19.255.248/29 fib:0 index:21 locks:2 CLI refs:1 src-flags:added,contributing,active, path-list:[29] locks:2 flags:shared, uPRF-list:27 len:0 itfs:[] path:[33] pl-index:29 ip4 weight=1 pref=0 deag: oper-flags:resolved, fib-index:1 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:23 buckets:1 uRPF:27 to:[1:100]] [0] [@12]: dst-address,unicast lookup in ipv4-VRF:4093 this is a lookup-DPO. Looks like the CLI interprets ‘via 0.0.0.0 next-hop-table 4093’ and ‘via ip4-look-in-table 4093’ as the same thing. /neale And tracing seems to give the expected result: 00:00:02:247022: pg-input stream x, 100 bytes, sw_if_index 1 current data 0, length 100, buffer-pool 0, ref-count 1, trace handle 0x0 UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 64, length 100, checksum 0xf2cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247055: ip4-input UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 64, length 100, checksum 0xf2cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247079: ip4-lookup fib 0 dpo-idx 0 flow hash: 0x UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 64, length 100, checksum 0xf2cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247088: lookup-ip4-dst fib-index:1 addr:198.19.255.253 load-balance:22 00:00:02:247092: ip4-rewrite tx_sw_if_index 2 dpo-idx 4 : ipv4 via 198.19.255.253 pg1: mtu:9000 next:3 flags:[] 00010002000302fe257345030800 flow hash: 0x : 00010002000302fe25734503080045643f11f3cdc0a80102c613 0020: fffd10e104d200487deb000102030405060708090a0b0c0d0e0f1011 00:00:02:247099: pg1-output pg1 IP4: 02:fe:25:73:45:03 -> 00:01:00:02:00:03 UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 63, length 100, checksum 0xf3cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247106: pg1-tx buffer 0x9ffd4: current data -14, length 114, buffer-pool 0, ref-count 1, trace handle 0x0 loop-counter 1 IP4: 02:fe:25:73:45:03 -> 00:01:00:02:00:03 UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 63, length 100, checksum 0xf3cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19679): https://lists.fd.io/g/vpp-dev/message/19679 Mute This Topic: https://lists.fd.io/mt/83895986/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
>> As 198.19.255.249 is the IP of host-Vpp2Host.4093, VPP interprets it as >> you want to deliver the packet locally instead of forwarding it. Try >> changing it to: >> ip route add 198.19.255.248/29 table 1 via 0.0.0.0 next-hop-table 4093 > 0.0.0.0/32 in any table is a drop. One cannot specify a route to be > recursive via another network, i.e. via 0.0.0.0/0, VPP doesn't support > that. I do not disagree with the rest of your comment, however this worked for me though - maybe because of some odd cli behavior? vpp# create packet-generator interface pg0 vpp# create packet-generator interface pg1 vpp# set int ip addr pg0 192.168.1.1/24 vpp# set int st pg0 up vpp# ip table add 4093 vpp# set int st pg1 up vpp# set int ip table pg1 4093 vpp# set int ip address pg1 198.19.255.249/29 vpp# ip neigh pg1 198.19.255.253 1.2.3 static vpp# ip route add 198.19.255.248/29 via 0.0.0.0 next-hop-table 4093 vpp# sh ip fib 198.19.255.253 table 0 ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[default-route:1, ] 198.19.255.248/29 fib:0 index:21 locks:2 CLI refs:1 src-flags:added,contributing,active, path-list:[29] locks:2 flags:shared, uPRF-list:27 len:0 itfs:[] path:[33] pl-index:29 ip4 weight=1 pref=0 deag: oper-flags:resolved, fib-index:1 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:23 buckets:1 uRPF:27 to:[1:100]] [0] [@12]: dst-address,unicast lookup in ipv4-VRF:4093 And tracing seems to give the expected result: 00:00:02:247022: pg-input stream x, 100 bytes, sw_if_index 1 current data 0, length 100, buffer-pool 0, ref-count 1, trace handle 0x0 UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 64, length 100, checksum 0xf2cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247055: ip4-input UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 64, length 100, checksum 0xf2cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247079: ip4-lookup fib 0 dpo-idx 0 flow hash: 0x UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 64, length 100, checksum 0xf2cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247088: lookup-ip4-dst fib-index:1 addr:198.19.255.253 load-balance:22 00:00:02:247092: ip4-rewrite tx_sw_if_index 2 dpo-idx 4 : ipv4 via 198.19.255.253 pg1: mtu:9000 next:3 flags:[] 00010002000302fe257345030800 flow hash: 0x : 00010002000302fe25734503080045643f11f3cdc0a80102c613 0020: fffd10e104d200487deb000102030405060708090a0b0c0d0e0f1011 00:00:02:247099: pg1-output pg1 IP4: 02:fe:25:73:45:03 -> 00:01:00:02:00:03 UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 63, length 100, checksum 0xf3cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb 00:00:02:247106: pg1-tx buffer 0x9ffd4: current data -14, length 114, buffer-pool 0, ref-count 1, trace handle 0x0 loop-counter 1 IP4: 02:fe:25:73:45:03 -> 00:01:00:02:00:03 UDP: 192.168.1.2 -> 198.19.255.253 tos 0x00, ttl 63, length 100, checksum 0xf3cd dscp CS0 ecn NON_ECN fragment id 0x UDP: 4321 -> 1234 length 72, checksum 0x7deb ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19677): https://lists.fd.io/g/vpp-dev/message/19677 Mute This Topic: https://lists.fd.io/mt/83895986/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
From: vpp-dev@lists.fd.io on behalf of Benoit Ganne (bganne) via lists.fd.io Date: Thursday, 1 July 2021 at 10:38 To: Mechthild Buescher , vpp-dev@lists.fd.io Subject: Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' I think the issue is the way you populate the route: ip route add 198.19.255.248/29 table 1 via 198.19.255.249 next-hop-table 4093 As 198.19.255.249 is the IP of host-Vpp2Host.4093, VPP interprets it as you want to deliver the packet locally instead of forwarding it. Try changing it to: ip route add 198.19.255.248/29 table 1 via 0.0.0.0 next-hop-table 4093 0.0.0.0/32 in any table is a drop. One cannot specify a route to be recursive via another network, i.e. via 0.0.0.0/0, VPP doesn’t support that. If the semantics you’re after is ‘do a second lookup in table 4093’ then you want ‘via ip4-lookup-in-table 4093’. But as Neale pointed out, if you only have a few routes in 4093, it would be even better to just do: ip route add 198.19.255.248/29 table 1 via host-Vpp2Host.4093 I suspect if you don’t do it this way, then a ping from another device in the 198.19.255.248/29 subnet won’t work, because the return path is not in table 1. /neale That would save you 1 additional fib lookup. Best ben > -Original Message- > From: Mechthild Buescher > Sent: jeudi 1 juillet 2021 09:39 > To: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io > Subject: RE: next-hop-table between two FIB tables results in punt and > 'unknown ip protocol' > > Hi Ben, > > Sorry, I sent the wrong output for the fib table - with the 'next-hop- > table' configuration it looks as follows: > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[default-route:1, ] > 0.0.0.0/0 fib:0 index:0 locks:2 > default-route refs:1 entry-flags:drop, src- > flags:added,contributing,active, > path-list:[0] locks:2 flags:drop, uPRF-list:0 len:0 itfs:[] > path:[0] pl-index:0 ip4 weight=1 pref=0 special: cfg-flags:drop, > [@0]: dpo-drop ip4 > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:0 to:[0:0]] > [0] [@0]: dpo-drop ip4 > : > ipv4-VRF:4093, fib_index:3, flow hash:[src dst sport dport proto flowlabel > ] epoch:0 flags:none locks:[CLI:2, adjacency:1, recursive-resolution:1, ] > 198.19.255.253/32 fib:3 index:170 locks:2 > adjacency refs:1 entry-flags:attached, src- > flags:added,contributing,active, cover:53 > path-list:[188] locks:2 uPRF-list:191 len:1 itfs:[14, ] > path:[224] pl-index:188 ip4 weight=1 pref=0 attached-nexthop: oper- > flags:resolved, > 198.19.255.253 host-Vpp2Host.4093 > [@0]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 > flags:[] a215f39524f302fee89a0ec381000ffd0800 > Extensions: > path:224 adj-flags:[refines-cover] > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:171 buckets:1 uRPF:191 > to:[4:384]] > [0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 > flags:[] a215f39524f302fee89a0ec381000ffd0800 > ipv4-VRF:1, fib_index:4, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[API:1, CLI:2, adjacency:1, recursive- > resolution:1, ] > 198.19.255.248/29 fib:4 index:66 locks:2 > CLI refs:1 src-flags:added,contributing,active, > path-list:[75] locks:20 flags:shared, uPRF-list:75 len:0 itfs:[] > path:[89] pl-index:75 ip4 weight=1 pref=0 recursive: oper- > flags:resolved, > via 198.19.255.249 in fib:3 via-fib:56 via-dpo:[dpo-load- > balance:57] > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:67 buckets:1 uRPF:75 to:[0:0]] > [0] [@11]: dpo-load-balance: [proto:ip4 index:57 buckets:1 uRPF:65 > to:[4:384]] > [0] [@2]: dpo-receive: 198.19.255.249 on host-Vpp2Host.4093 > ipv4-VRF:10, fib_index:5, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[CLI:2, ] > > > The output below is when we replaced the 'next-hop table' routing with > direct routing to /32 Ips. That direct routing is working but is regarded > as work-around as long as we don't find a better solution. > > BR/Mechthild > > -Original Message- > From: Mechthild Buescher > Sent: Wednesday, 30 June 2021 18:32 > To: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io > Subject: RE: next-hop-table between two FIB tables results in punt and > 'unknown ip protocol' > > Hi Ben, > > Thanks for your fast reply. Here is the requested output (I skipped config > for other interfaces and VLANs) > > vppctl show int addr > NCIC-1-v1 (up): > NCIC-1-v1.1 (up): > L3 10.10.203.1/29 ip4 table-id 1 fib-idx 4 host-Vpp2Host (up): > host-Vpp2Hos
Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
I think the issue is the way you populate the route: ip route add 198.19.255.248/29 table 1 via 198.19.255.249 next-hop-table 4093 As 198.19.255.249 is the IP of host-Vpp2Host.4093, VPP interprets it as you want to deliver the packet locally instead of forwarding it. Try changing it to: ip route add 198.19.255.248/29 table 1 via 0.0.0.0 next-hop-table 4093 But as Neale pointed out, if you only have a few routes in 4093, it would be even better to just do: ip route add 198.19.255.248/29 table 1 via host-Vpp2Host.4093 That would save you 1 additional fib lookup. Best ben > -Original Message- > From: Mechthild Buescher > Sent: jeudi 1 juillet 2021 09:39 > To: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io > Subject: RE: next-hop-table between two FIB tables results in punt and > 'unknown ip protocol' > > Hi Ben, > > Sorry, I sent the wrong output for the fib table - with the 'next-hop- > table' configuration it looks as follows: > ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[default-route:1, ] > 0.0.0.0/0 fib:0 index:0 locks:2 > default-route refs:1 entry-flags:drop, src- > flags:added,contributing,active, > path-list:[0] locks:2 flags:drop, uPRF-list:0 len:0 itfs:[] > path:[0] pl-index:0 ip4 weight=1 pref=0 special: cfg-flags:drop, > [@0]: dpo-drop ip4 > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:0 to:[0:0]] > [0] [@0]: dpo-drop ip4 > : > ipv4-VRF:4093, fib_index:3, flow hash:[src dst sport dport proto flowlabel > ] epoch:0 flags:none locks:[CLI:2, adjacency:1, recursive-resolution:1, ] > 198.19.255.253/32 fib:3 index:170 locks:2 > adjacency refs:1 entry-flags:attached, src- > flags:added,contributing,active, cover:53 > path-list:[188] locks:2 uPRF-list:191 len:1 itfs:[14, ] > path:[224] pl-index:188 ip4 weight=1 pref=0 attached-nexthop: oper- > flags:resolved, > 198.19.255.253 host-Vpp2Host.4093 > [@0]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 > flags:[] a215f39524f302fee89a0ec381000ffd0800 > Extensions: > path:224 adj-flags:[refines-cover] > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:171 buckets:1 uRPF:191 > to:[4:384]] > [0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 > flags:[] a215f39524f302fee89a0ec381000ffd0800 > ipv4-VRF:1, fib_index:4, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[API:1, CLI:2, adjacency:1, recursive- > resolution:1, ] > 198.19.255.248/29 fib:4 index:66 locks:2 > CLI refs:1 src-flags:added,contributing,active, > path-list:[75] locks:20 flags:shared, uPRF-list:75 len:0 itfs:[] > path:[89] pl-index:75 ip4 weight=1 pref=0 recursive: oper- > flags:resolved, > via 198.19.255.249 in fib:3 via-fib:56 via-dpo:[dpo-load- > balance:57] > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:67 buckets:1 uRPF:75 to:[0:0]] > [0] [@11]: dpo-load-balance: [proto:ip4 index:57 buckets:1 uRPF:65 > to:[4:384]] > [0] [@2]: dpo-receive: 198.19.255.249 on host-Vpp2Host.4093 > ipv4-VRF:10, fib_index:5, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[CLI:2, ] > > > The output below is when we replaced the 'next-hop table' routing with > direct routing to /32 Ips. That direct routing is working but is regarded > as work-around as long as we don't find a better solution. > > BR/Mechthild > > -Original Message- > From: Mechthild Buescher > Sent: Wednesday, 30 June 2021 18:32 > To: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io > Subject: RE: next-hop-table between two FIB tables results in punt and > 'unknown ip protocol' > > Hi Ben, > > Thanks for your fast reply. Here is the requested output (I skipped config > for other interfaces and VLANs) > > vppctl show int addr > NCIC-1-v1 (up): > NCIC-1-v1.1 (up): > L3 10.10.203.1/29 ip4 table-id 1 fib-idx 4 host-Vpp2Host (up): > host-Vpp2Host.4093 (up): > L3 198.19.255.249/29 ip4 table-id 4093 fib-idx 3 > local0 (dn): > > and: > vppctl sh ip fib 198.19.255.253 > pv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] > epoch:0 flags:none locks:[default-route:1, ] > 0.0.0.0/0 fib:0 index:0 locks:2 > default-route refs:1 entry-flags:drop, src- > flags:added,contributing,active, > path-list:[0] locks:2 flags:drop, uPRF-list:0 len:0 itfs:[] > path:[0] pl-index:0 ip4 weight=1 pref=0 special: cfg-flags:drop, > [@0]: dpo-drop ip4 > > forwarding: unicast-ip4-chain > [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:0 to:[0:0]] > [0] [@0]: dpo-drop ip4 > ipv4-VRF:4093, fib_index:3, flow hash:[src dst sport dport proto flowlabel > ] epoch:0 flags:none locks:[CLI:2, adjacency:1, recursive-resolution:1, ] > 198.19.255.253/32 fib:3 index:189 locks:2 > adjacency refs:1 entry-flags:attached, src- >
Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
Hi Ben, Sorry, I sent the wrong output for the fib table - with the 'next-hop-table' configuration it looks as follows: ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[default-route:1, ] 0.0.0.0/0 fib:0 index:0 locks:2 default-route refs:1 entry-flags:drop, src-flags:added,contributing,active, path-list:[0] locks:2 flags:drop, uPRF-list:0 len:0 itfs:[] path:[0] pl-index:0 ip4 weight=1 pref=0 special: cfg-flags:drop, [@0]: dpo-drop ip4 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:0 to:[0:0]] [0] [@0]: dpo-drop ip4 : ipv4-VRF:4093, fib_index:3, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, adjacency:1, recursive-resolution:1, ] 198.19.255.253/32 fib:3 index:170 locks:2 adjacency refs:1 entry-flags:attached, src-flags:added,contributing,active, cover:53 path-list:[188] locks:2 uPRF-list:191 len:1 itfs:[14, ] path:[224] pl-index:188 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved, 198.19.255.253 host-Vpp2Host.4093 [@0]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] a215f39524f302fee89a0ec381000ffd0800 Extensions: path:224 adj-flags:[refines-cover] forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:171 buckets:1 uRPF:191 to:[4:384]] [0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] a215f39524f302fee89a0ec381000ffd0800 ipv4-VRF:1, fib_index:4, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[API:1, CLI:2, adjacency:1, recursive-resolution:1, ] 198.19.255.248/29 fib:4 index:66 locks:2 CLI refs:1 src-flags:added,contributing,active, path-list:[75] locks:20 flags:shared, uPRF-list:75 len:0 itfs:[] path:[89] pl-index:75 ip4 weight=1 pref=0 recursive: oper-flags:resolved, via 198.19.255.249 in fib:3 via-fib:56 via-dpo:[dpo-load-balance:57] forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:67 buckets:1 uRPF:75 to:[0:0]] [0] [@11]: dpo-load-balance: [proto:ip4 index:57 buckets:1 uRPF:65 to:[4:384]] [0] [@2]: dpo-receive: 198.19.255.249 on host-Vpp2Host.4093 ipv4-VRF:10, fib_index:5, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, ] The output below is when we replaced the 'next-hop table' routing with direct routing to /32 Ips. That direct routing is working but is regarded as work-around as long as we don't find a better solution. BR/Mechthild -Original Message- From: Mechthild Buescher Sent: Wednesday, 30 June 2021 18:32 To: Benoit Ganne (bganne) ; vpp-dev@lists.fd.io Subject: RE: next-hop-table between two FIB tables results in punt and 'unknown ip protocol' Hi Ben, Thanks for your fast reply. Here is the requested output (I skipped config for other interfaces and VLANs) vppctl show int addr NCIC-1-v1 (up): NCIC-1-v1.1 (up): L3 10.10.203.1/29 ip4 table-id 1 fib-idx 4 host-Vpp2Host (up): host-Vpp2Host.4093 (up): L3 198.19.255.249/29 ip4 table-id 4093 fib-idx 3 local0 (dn): and: vppctl sh ip fib 198.19.255.253 pv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[default-route:1, ] 0.0.0.0/0 fib:0 index:0 locks:2 default-route refs:1 entry-flags:drop, src-flags:added,contributing,active, path-list:[0] locks:2 flags:drop, uPRF-list:0 len:0 itfs:[] path:[0] pl-index:0 ip4 weight=1 pref=0 special: cfg-flags:drop, [@0]: dpo-drop ip4 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:0 to:[0:0]] [0] [@0]: dpo-drop ip4 ipv4-VRF:4093, fib_index:3, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, adjacency:1, recursive-resolution:1, ] 198.19.255.253/32 fib:3 index:189 locks:2 adjacency refs:1 entry-flags:attached, src-flags:added,contributing,active, cover:53 path-list:[206] locks:2 uPRF-list:210 len:1 itfs:[14, ] path:[241] pl-index:206 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved, 198.19.255.253 host-Vpp2Host.4093 [@0]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] e2de891fcccb02fe33d4dc0d81000ffd0800 Extensions: path:241 adj-flags:[refines-cover] forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:190 buckets:1 uRPF:210 to:[2:192] via:[6:504]] [0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] e2de891fcccb02fe33d4dc0d81000ffd0800 ipv4-VRF:1, fib_index:4, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[API:1, CLI:2, adjacency:1, recursive-resolution:1, ] 198.19.255.253/32 fib:4 index:190 locks:2 CLI refs:1 entry-flags:attached, src-flags:added,contributing,active, path-list:[207] locks:2 flags:shared, uPRF-list:211 len:1 itfs:[14, ] path:[243] pl-index:207 ip4 weight=1
Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
Hi Ben, Thanks for your fast reply. Here is the requested output (I skipped config for other interfaces and VLANs) vppctl show int addr NCIC-1-v1 (up): NCIC-1-v1.1 (up): L3 10.10.203.1/29 ip4 table-id 1 fib-idx 4 host-Vpp2Host (up): host-Vpp2Host.4093 (up): L3 198.19.255.249/29 ip4 table-id 4093 fib-idx 3 local0 (dn): and: vppctl sh ip fib 198.19.255.253 pv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[default-route:1, ] 0.0.0.0/0 fib:0 index:0 locks:2 default-route refs:1 entry-flags:drop, src-flags:added,contributing,active, path-list:[0] locks:2 flags:drop, uPRF-list:0 len:0 itfs:[] path:[0] pl-index:0 ip4 weight=1 pref=0 special: cfg-flags:drop, [@0]: dpo-drop ip4 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:0 to:[0:0]] [0] [@0]: dpo-drop ip4 ipv4-VRF:4093, fib_index:3, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[CLI:2, adjacency:1, recursive-resolution:1, ] 198.19.255.253/32 fib:3 index:189 locks:2 adjacency refs:1 entry-flags:attached, src-flags:added,contributing,active, cover:53 path-list:[206] locks:2 uPRF-list:210 len:1 itfs:[14, ] path:[241] pl-index:206 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved, 198.19.255.253 host-Vpp2Host.4093 [@0]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] e2de891fcccb02fe33d4dc0d81000ffd0800 Extensions: path:241 adj-flags:[refines-cover] forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:190 buckets:1 uRPF:210 to:[2:192] via:[6:504]] [0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] e2de891fcccb02fe33d4dc0d81000ffd0800 ipv4-VRF:1, fib_index:4, flow hash:[src dst sport dport proto flowlabel ] epoch:0 flags:none locks:[API:1, CLI:2, adjacency:1, recursive-resolution:1, ] 198.19.255.253/32 fib:4 index:190 locks:2 CLI refs:1 entry-flags:attached, src-flags:added,contributing,active, path-list:[207] locks:2 flags:shared, uPRF-list:211 len:1 itfs:[14, ] path:[243] pl-index:207 ip4 weight=1 pref=0 attached-nexthop: oper-flags:resolved, cfg-flags:attached, 198.19.255.253 host-Vpp2Host.4093 [@0]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] e2de891fcccb02fe33d4dc0d81000ffd0800 forwarding: unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:191 buckets:1 uRPF:211 to:[5:480]] [0] [@5]: ipv4 via 198.19.255.253 host-Vpp2Host.4093: mtu:9000 next:4 flags:[] e2de891fcccb02fe33d4dc0d81000ffd0800 BR/Mechthild -Original Message- From: Benoit Ganne (bganne) Sent: Wednesday, 30 June 2021 18:16 To: Mechthild Buescher ; vpp-dev@lists.fd.io Subject: RE: next-hop-table between two FIB tables results in punt and 'unknown ip protocol' >From the trace output, it looks like VPP thinks 198.19.255.253 is one of its >interface address, and hence try to deliver it locally. As there is no >configured listener for TCP packets, it default to punting, and as there is no >punt rule it drops. Can you share the output of 'show int addr' and 'sh ip fib 198.19.255.253'? Best ben > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of Mechthild > Buescher via lists.fd.io > Sent: mercredi 30 juin 2021 18:06 > To: vpp-dev@lists.fd.io > Subject: [vpp-dev] next-hop-table between two FIB tables results in > punt and 'unknown ip protocol' > > Hi all, > > > > we are using VPP with several FIB tables and when we use 'next-hop-table' > the ip4-lookup results somehow in 'unknown ip protocol'. Can you > please help? > > > > Our setup: > > * 1 (out of 2) with VPP and a DPDK interface > > > > The VPP version is (both nodes): > > > vpp# show version verbose > > Version: v21.06-rc2~6-gf377e9545 > > Compiled by: suse > > Compile host: SUSE > > Compile date: 2021-06-24T14:02:01 > > Compile location: /root/vpp-32298/vpp > > Compiler: GCC 7.5.0 > > Current PID: 22527 > > > > The VPP config uses the DPDK interface (both nodes): > > > vpp# show hardware-interfaces NCIC-1-v1 > > NameIdx Link Hardware > > NCIC-1-v1 3 up NCIC-1-v1 > > Link speed: 40 Gbps > > RX Queues: > > queue thread mode > > 0 vpp_wk_0 (1) polling > > Ethernet address 72:a6:1e:ae:cd:f1 > > Intel iAVF > > carrier up full duplex mtu 9206 > > flags: admin-up pmd maybe-multiseg subif tx-offload > intel-phdr-cksum rx-ip4-cksum int-unmaskable > > Devargs: > > rx: queues 1 (max 256), desc 1024 (min 64 max 4096 align 32) > > tx: queues 3 (max 256), desc 1024 (min 64 max 4096 align 32) > > pci: device 8086:154c subsystem 1028: address :17:0e.01 > numa 0 > > max rx packet len: 9728 > > promiscuous:
Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
Hi Mechthild, What Benoit said about punting. You might also find this useful: https://github.com/FDio/vpp/blob/master/src/plugins/linux-cp/FEATURE.yaml plus inline … From: vpp-dev@lists.fd.io on behalf of Mechthild Buescher via lists.fd.io Date: Wednesday, 30 June 2021 at 18:06 To: vpp-dev@lists.fd.io Subject: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol' Hi all, we are using VPP with several FIB tables and when we use ‘next-hop-table’ the ip4-lookup results somehow in ‘unknown ip protocol’. Can you please help? Our setup: · 1 (out of 2) with VPP and a DPDK interface The VPP version is (both nodes): vpp# show version verbose Version: v21.06-rc2~6-gf377e9545 Compiled by: suse Compile host: SUSE Compile date: 2021-06-24T14:02:01 Compile location: /root/vpp-32298/vpp Compiler: GCC 7.5.0 Current PID: 22527 The VPP config uses the DPDK interface (both nodes): vpp# show hardware-interfaces NCIC-1-v1 NameIdx Link Hardware NCIC-1-v1 3 up NCIC-1-v1 Link speed: 40 Gbps RX Queues: queue thread mode 0 vpp_wk_0 (1) polling Ethernet address 72:a6:1e:ae:cd:f1 Intel iAVF carrier up full duplex mtu 9206 flags: admin-up pmd maybe-multiseg subif tx-offload intel-phdr-cksum rx-ip4-cksum int-unmaskable Devargs: rx: queues 1 (max 256), desc 1024 (min 64 max 4096 align 32) tx: queues 3 (max 256), desc 1024 (min 64 max 4096 align 32) pci: device 8086:154c subsystem 1028: address :17:0e.01 numa 0 max rx packet len: 9728 promiscuous: unicast off all-multicast on vlan offload: strip off filter off qinq off rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum qinq-strip outer-ipv4-cksum vlan-filter jumbo-frame scatter rss-hash rx offload active: ipv4-cksum jumbo-frame scatter tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum tcp-tso outer-ipv4-cksum qinq-insert vxlan-tnl-tso gre-tnl-tso ipip-tnl-tso geneve-tnl-tso multi-segs mbuf-fast-free tx offload active: udp-cksum tcp-cksum multi-segs rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other ipv4 ipv6-frag ipv6-tcp ipv6-udp ipv6-sctp ipv6-other ipv6 rss active:none tx burst function: iavf_xmit_pkts rx burst function: iavf_recv_scattered_pkts_vec_avx2 The VPP config is (there is a veth-pair configured on the host): create host-interface name Vpp2Host set interface state host-Vpp2Host up ip table add 4093 create sub-interfaces host-Vpp2Host 4093 set interface state host-Vpp2Host.4093 up set interface ip table host-Vpp2Host.4093 4093 set interface ip address host-Vpp2Host.4093 198.19.255.249/29 198.19.255.249 is configured on this interface set interface state NCIC-1-v1 up ip table add 1 create sub-interfaces NCIC-1-v1 1 set interface state NCIC-1-v1.1 up set interface ip table NCIC-1-v1.1 1 set interface ip address NCIC-1-v1.1 10.10.203.3/29 ip route add 198.19.255.248/29 table 1 via 198.19.255.249 next-hop-table 4093 but it’s used as a next-hop here. It works, as the trace demonstrates, but it’s not the most efficient way to do things. next-hops are meant to specify the remote host to send to/via. Are you trying to receive packets sent to host-Vpp2Host.4093’s subnet if they are received on NCIC-1v1.1? If so maybe you need an extranet; you leak the routes of one VRF into the other. The interface’s connected prefixes require special attention, see: https://github.com/FDio/vpp/blob/master/docs/gettingstarted/developers/fib20/attachedexport.rst tl;dr. do this: ip route add 198.19.255.248/29 table 1 via host-Vpp2Host.4093 /neale When a packet is received (curl -k -vv https://198.19.255.253:8443/... ) we see the following trace on dpdk-input: NCIC-1-v1 rx queue 0 buffer 0x14296: current data 0, length 78, buffer-pool 0, ref-count 1, totlen-nifb 0, trace handle 0x116 ext-hdr-valid l4-cksum-computed l4-cksum-correct PKT MBUF: port 2, nb_segs 1, pkt_len 78 buf_len 2176, data_len 78, ol_flags 0x180, data_off 128, phys_addr 0x50a600 packet_type 0x191 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 rss 0x0 fdir.hi 0x0 fdir.lo 0x0 Packet Offload Flags PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid Packet Types RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without extension headers RTE_PTYPE_L4_TCP (0x0100) TCP packet IP4: 86:ca:f3:a1:20:fc -> 1e:a0:ab:00:2a:ea 802.1q vlan 1 TCP: 172.17.41.8 -> 198.19.255.253 tos 0x00, ttl 64, length 60, checksum 0x7bc3 dscp
Re: [vpp-dev] next-hop-table between two FIB tables results in punt and 'unknown ip protocol'
>From the trace output, it looks like VPP thinks 198.19.255.253 is one of its >interface address, and hence try to deliver it locally. As there is no >configured listener for TCP packets, it default to punting, and as there is no >punt rule it drops. Can you share the output of 'show int addr' and 'sh ip fib 198.19.255.253'? Best ben > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of Mechthild > Buescher via lists.fd.io > Sent: mercredi 30 juin 2021 18:06 > To: vpp-dev@lists.fd.io > Subject: [vpp-dev] next-hop-table between two FIB tables results in punt > and 'unknown ip protocol' > > Hi all, > > > > we are using VPP with several FIB tables and when we use 'next-hop-table' > the ip4-lookup results somehow in 'unknown ip protocol'. Can you please > help? > > > > Our setup: > > * 1 (out of 2) with VPP and a DPDK interface > > > > The VPP version is (both nodes): > > > vpp# show version verbose > > Version: v21.06-rc2~6-gf377e9545 > > Compiled by: suse > > Compile host: SUSE > > Compile date: 2021-06-24T14:02:01 > > Compile location: /root/vpp-32298/vpp > > Compiler: GCC 7.5.0 > > Current PID: 22527 > > > > The VPP config uses the DPDK interface (both nodes): > > > vpp# show hardware-interfaces NCIC-1-v1 > > NameIdx Link Hardware > > NCIC-1-v1 3 up NCIC-1-v1 > > Link speed: 40 Gbps > > RX Queues: > > queue thread mode > > 0 vpp_wk_0 (1) polling > > Ethernet address 72:a6:1e:ae:cd:f1 > > Intel iAVF > > carrier up full duplex mtu 9206 > > flags: admin-up pmd maybe-multiseg subif tx-offload intel-phdr-cksum > rx-ip4-cksum int-unmaskable > > Devargs: > > rx: queues 1 (max 256), desc 1024 (min 64 max 4096 align 32) > > tx: queues 3 (max 256), desc 1024 (min 64 max 4096 align 32) > > pci: device 8086:154c subsystem 1028: address :17:0e.01 numa 0 > > max rx packet len: 9728 > > promiscuous: unicast off all-multicast on > > vlan offload: strip off filter off qinq off > > rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum qinq- > strip > >outer-ipv4-cksum vlan-filter jumbo-frame scatter > rss-hash > > rx offload active: ipv4-cksum jumbo-frame scatter > > tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp- > cksum > >tcp-tso outer-ipv4-cksum qinq-insert vxlan-tnl-tso > >gre-tnl-tso ipip-tnl-tso geneve-tnl-tso multi-segs > >mbuf-fast-free > > tx offload active: udp-cksum tcp-cksum multi-segs > > rss avail: ipv4-frag ipv4-tcp ipv4-udp ipv4-sctp ipv4-other > ipv4 > >ipv6-frag ipv6-tcp ipv6-udp ipv6-sctp ipv6-other > ipv6 > > rss active:none > > tx burst function: iavf_xmit_pkts > > rx burst function: iavf_recv_scattered_pkts_vec_avx2 > > > > The VPP config is (there is a veth-pair configured on the host): > > > > create host-interface name Vpp2Host > > set interface state host-Vpp2Host up > > > > ip table add 4093 > > create sub-interfaces host-Vpp2Host 4093 > > set interface state host-Vpp2Host.4093 up > > set interface ip table host-Vpp2Host.4093 4093 > > set interface ip address host-Vpp2Host.4093 198.19.255.249/29 > > > > set interface state NCIC-1-v1 up > > ip table add 1 > > create sub-interfaces NCIC-1-v1 1 > > set interface state NCIC-1-v1.1 up > > set interface ip table NCIC-1-v1.1 1 > > set interface ip address NCIC-1-v1.1 10.10.203.3/29 > > ip route add 198.19.255.248/29 table 1 via 198.19.255.249 next-hop-table > 4093 > > > > When a packet is received (curl -k -vv https://198.19.255.253:8443/... ) > we see the following trace on dpdk-input: > > NCIC-1-v1 rx queue 0 > > buffer 0x14296: current data 0, length 78, buffer-pool 0, ref-count 1, > totlen-nifb 0, trace handle 0x116 > > ext-hdr-valid > > l4-cksum-computed l4-cksum-correct > > PKT MBUF: port 2, nb_segs 1, pkt_len 78 > > buf_len 2176, data_len 78, ol_flags 0x180, data_off 128, phys_addr > 0x50a600 > > packet_type 0x191 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > > Packet Offload Flags > > PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid > > PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid > > Packet Types > > RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet > > RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without > extension headers > > RTE_PTYPE_L4_TCP (0x0100) TCP packet > > IP4: 86:ca:f3:a1:20:fc -> 1e:a0:ab:00:2a:ea 802.1q vlan 1 > > TCP: 172.17.41.8 -> 198.19.255.253 > > tos 0x00, ttl 64, length 60, checksum 0x7bc3 dscp CS0 ecn
