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) <bga...@cisco.com>
Sent: Wednesday, 30 June 2021 18:16
To: Mechthild Buescher <mechthild.buesc...@ericsson.com>; 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 <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
>
> Name Idx 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:0000 address 0000: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://protect2.fireeye.com/v1/url?k=00957dfa-5f0e44be-00953d61-861d41abace8-dc5e93fd2e4adcdf&q=1&e=532639d0-8e37-4c7a-83d3-552d3a0d02a9&u=https%3A%2F%2F198.19.255.253%3A8443%2F...
> ) 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 0x1000016
>
> 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 NON_ECN
>
> fragment id 0x23ce, flags DONT_FRAGMENT
>
> TCP: 41834 -> 8443
>
> seq. 0xbd8844b4 ack 0x00000000
>
> flags 0x02 SYN, tcp header: 40 bytes
>
> window 29200, checksum 0xa704
>
> 18:41:55:850222: ethernet-input
>
> frame: flags 0x3, hw-if-index 3, sw-if-index 3
>
> IP4: 86:ca:f3:a1:20:fc -> 1e:a0:ab:00:2a:ea 802.1q vlan 1
>
> 18:41:55:850224: ip4-input
>
> TCP: 172.17.41.8 -> 198.19.255.253
>
> tos 0x00, ttl 64, length 60, checksum 0x7bc3 dscp CS0 ecn NON_ECN
>
> fragment id 0x23ce, flags DONT_FRAGMENT
>
> TCP: 41834 -> 8443
>
> seq. 0xbd8844b4 ack 0x00000000
>
> flags 0x02 SYN, tcp header: 40 bytes
>
> window 29200, checksum 0xa704
>
> 18:41:55:850225: ip4-lookup
>
> fib 4 dpo-idx 57 flow hash: 0x00000000
>
> TCP: 172.17.41.8 -> 198.19.255.253
>
> tos 0x00, ttl 64, length 60, checksum 0x7bc3 dscp CS0 ecn NON_ECN
>
> fragment id 0x23ce, flags DONT_FRAGMENT
>
> TCP: 41834 -> 8443
>
> seq. 0xbd8844b4 ack 0x00000000
>
> flags 0x02 SYN, tcp header: 40 bytes
>
> window 29200, checksum 0xa704
>
> 18:41:55:850226: ip4-load-balance
>
> fib 4 dpo-idx 18 flow hash: 0x00000000
>
> TCP: 172.17.41.8 -> 198.19.255.253
>
> tos 0x00, ttl 64, length 60, checksum 0x7bc3 dscp CS0 ecn NON_ECN
>
> fragment id 0x23ce, flags DONT_FRAGMENT
>
> TCP: 41834 -> 8443
>
> seq. 0xbd8844b4 ack 0x00000000
>
> flags 0x02 SYN, tcp header: 40 bytes
>
> window 29200, checksum 0xa704
>
> 18:41:55:850228: ip4-local
>
> TCP: 172.17.41.8 -> 198.19.255.253
>
> tos 0x00, ttl 64, length 60, checksum 0x7bc3 dscp CS0 ecn
> NON_ECN
>
> fragment id 0x23ce, flags DONT_FRAGMENT
>
> TCP: 41834 -> 8443
>
> seq. 0xbd8844b4 ack 0x00000000
>
> flags 0x02 SYN, tcp header: 40 bytes
>
> window 29200, checksum 0xa704
>
> 18:41:55:850230: ip4-punt
>
> TCP: 172.17.41.8 -> 198.19.255.253
>
> tos 0x00, ttl 64, length 60, checksum 0x7bc3 dscp CS0 ecn
> NON_ECN
>
> fragment id 0x23ce, flags DONT_FRAGMENT
>
> TCP: 41834 -> 8443
>
> seq. 0xbd8844b4 ack 0x00000000
>
> flags 0x02 SYN, tcp header: 40 bytes
>
> window 29200, checksum 0xa704
>
> 18:41:55:850231: error-punt
>
> rx:NCIC-1-v1.1
>
> 18:41:55:850232: punt
>
> ip4-local: unknown ip protocol
>
>
>
> And the following is the relevant part in the FIB table:
> vpp# show ip fib table 1
>
> ipv4-VRF:1, fib_index:4, flow hash:[src dst sport dport proto ]
> epoch:0 flags:none locks:[API:1, CLI:2, adjacency:1,
> recursive-resolution:1, ]
>
> :
>
> 198.19.255.248/29
>
> unicast-ip4-chain
>
> [@0]: dpo-load-balance: [proto:ip4 index:67 buckets:1 uRPF:75
> to:[1447:116264]]
>
> [0] [@11]: dpo-load-balance: [proto:ip4 index:57 buckets:1 uRPF:65
> to:[6:576] via:[1447:116264]]
>
> [0] [@2]: dpo-receive: 198.19.255.249 on host-Vpp2Host.4093
>
>
>
> The uRPF seems to be empty:
> vpp# show fib uRPF
>
> 65@uPRF-list:65 len:0 itfs:[]
>
>
>
> A ping was working fine but the curl command failed. Is there some
> additional configuration needed to allow ports via 'next-hop-table' or
> is this a bug in VPP?
>
>
>
> Any hint on how to solve this is appreciated.
>
>
>
> Thank you and best regards,
>
>
>
> Mechthild Buescher
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#19663): https://lists.fd.io/g/vpp-dev/message/19663
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]
-=-=-=-=-=-=-=-=-=-=-=-
