>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://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 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 (#19661): https://lists.fd.io/g/vpp-dev/message/19661 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] -=-=-=-=-=-=-=-=-=-=-=-
