Ben, I am still seeing some odd behaviour when trying to route traffic to the Internet though (again from Azure). I've added a default route through FailsafeEthernet2 and this is what I get when trying to connect to www.google.ca on port 80 with netcat on a box on my 10.4.2.0/24 subnet:
vpp# show ip fib ipv4-VRF:0, fib_index:0, flow hash:[src dst sport dport proto ] locks:[src:plugin-hi:2, src:adjacency:2, src:default-route:1, ] 0.0.0.0/0 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:1 buckets:1 uRPF:18 to:[27:1620]] [0] [@4]: ipv4-glean: FailsafeEthernet2: mtu:9000 ffffffffffff000d3af4eb8d0806 0.0.0.0/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:2 buckets:1 uRPF:1 to:[0:0]] [0] [@0]: dpo-drop ip4 10.4.1.0/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:10 buckets:1 uRPF:9 to:[0:0]] [0] [@0]: dpo-drop ip4 10.4.1.4/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:18 buckets:1 uRPF:21 to:[2:168]] [0] [@5]: ipv4 via 10.4.1.4 FailsafeEthernet2: mtu:9000 123456789abc000d3af4eb8d0800 10.4.1.0/24 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:9 buckets:1 uRPF:8 to:[1:84]] [0] [@4]: ipv4-glean: FailsafeEthernet2: mtu:9000 ffffffffffff000d3af4eb8d0806 10.4.1.5/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:12 buckets:1 uRPF:13 to:[0:0]] [0] [@2]: dpo-receive: 10.4.1.5 on FailsafeEthernet2 10.4.1.255/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:11 buckets:1 uRPF:11 to:[0:0]] [0] [@0]: dpo-drop ip4 10.4.2.0/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:14 buckets:1 uRPF:15 to:[0:0]] [0] [@0]: dpo-drop ip4 10.4.2.0/24 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:13 buckets:1 uRPF:14 to:[1:84]] [0] [@4]: ipv4-glean: FailsafeEthernet4: mtu:9000 ffffffffffff000d3af4e08c0806 10.4.2.6/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:16 buckets:1 uRPF:19 to:[0:0]] [0] [@2]: dpo-receive: 10.4.2.6 on FailsafeEthernet4 10.4.2.7/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:17 buckets:1 uRPF:20 to:[3:252]] [0] [@5]: ipv4 via 10.4.2.7 FailsafeEthernet4: mtu:9000 123456789abc000d3af4e08c0800 10.4.2.255/32 unicast-ip4-chain [@0]: dpo-load-balance: [proto:ip4 index:15 buckets:1 uRPF:17 to:[0:0]] [0] [@0]: dpo-drop ip4 vpp# show trace ------------------- Start of thread 0 vpp_main ------------------- Packet 1 00:03:04:853401: dpdk-input FailsafeEthernet4 rx queue 0 buffer 0x74248: current data 0, length 74, buffer-pool 0, ref-count 1, totlen-nifb 0, trace handle 0x0 ext-hdr-valid l4-cksum-computed l4-cksum-correct PKT MBUF: port 4, nb_segs 1, pkt_len 74 buf_len 2176, data_len 74, ol_flags 0x180, data_off 128, phys_addr 0x9e109280 packet_type 0x111 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 (0x0010) IPv4 packet without extension headers RTE_PTYPE_L4_TCP (0x0100) TCP packet IP4: 74:83:ef:6a:c4:a3 -> 00:0d:3a:f4:e0:8c TCP: 10.4.2.7 -> 172.217.13.99 tos 0x00, ttl 64, length 60, checksum 0x7f50 fragment id 0xf524, flags DONT_FRAGMENT TCP: 43530 -> 80 seq. 0x9edf9007 ack 0x00000000 flags 0x02 SYN, tcp header: 40 bytes window 64240, checksum 0xf726 00:03:04:853422: ethernet-input frame: flags 0x3, hw-if-index 2, sw-if-index 2 IP4: 74:83:ef:6a:c4:a3 -> 00:0d:3a:f4:e0:8c 00:03:04:853444: ip4-input-no-checksum TCP: 10.4.2.7 -> 172.217.13.99 tos 0x00, ttl 64, length 60, checksum 0x7f50 fragment id 0xf524, flags DONT_FRAGMENT TCP: 43530 -> 80 seq. 0x9edf9007 ack 0x00000000 flags 0x02 SYN, tcp header: 40 bytes window 64240, checksum 0xf726 00:03:04:853446: ip4-lookup fib 0 dpo-idx 0 flow hash: 0x00000000 TCP: 10.4.2.7 -> 172.217.13.99 tos 0x00, ttl 64, length 60, checksum 0x7f50 fragment id 0xf524, flags DONT_FRAGMENT TCP: 43530 -> 80 seq. 0x9edf9007 ack 0x00000000 flags 0x02 SYN, tcp header: 40 bytes window 64240, checksum 0xf726 00:03:04:853449: ip4-glean TCP: 10.4.2.7 -> 172.217.13.99 tos 0x00, ttl 64, length 60, checksum 0x7f50 fragment id 0xf524, flags DONT_FRAGMENT TCP: 43530 -> 80 seq. 0x9edf9007 ack 0x00000000 flags 0x02 SYN, tcp header: 40 bytes window 64240, checksum 0xf726 00:03:04:853452: FailsafeEthernet2-output FailsafeEthernet2 ARP: 00:0d:3a:f4:eb:8d -> ff:ff:ff:ff:ff:ff request, type ethernet/IP4, address size 6/4 00:0d:3a:f4:eb:8d/10.4.1.5 -> 00:00:00:00:00:00/172.217.13.99 00:03:04:853455: error-drop rx:FailsafeEthernet4 00:03:04:853478: FailsafeEthernet2-tx FailsafeEthernet2 tx queue 0 buffer 0x7426f: current data -14, length 42, buffer-pool 0, ref-count 1, trace handle 0x0 PKT MBUF: port 65535, nb_segs 1, pkt_len 42 buf_len 2176, data_len 42, ol_flags 0x0, data_off 114, phys_addr 0x9e109c40 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 ARP: 00:0d:3a:f4:eb:8d -> ff:ff:ff:ff:ff:ff request, type ethernet/IP4, address size 6/4 00:0d:3a:f4:eb:8d/10.4.1.5 -> 00:00:00:00:00:00/172.217.13.99 00:03:04:853481: drop ip4-glean: ARP requests sent There are 4 SYN packets and the trace results look the same to me for all of them - they all get dropped. They still get dropped even if I add a static ARP entry for the 172.217.13.99 IP address (resolved from www.google.ca ( http://www.google.ca ) ). Perhaps this issue would be better placed in a new thread given that I am now entering the realm of configuring VPP? Thanks, Chris
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#15339): https://lists.fd.io/g/vpp-dev/message/15339 Mute This Topic: https://lists.fd.io/mt/69987045/21656 Mute #vpp: https://lists.fd.io/mk?hashtag=vpp&subid=1480452 Mute #dpdk: https://lists.fd.io/mk?hashtag=dpdk&subid=1480452 Mute #azure: https://lists.fd.io/mk?hashtag=azure&subid=1480452 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
