Hub with default route to LAN side dropped traffic destined to VCO.
Article ID: 378647
Updated On:
Products
Issue/Introduction
If a client is trying to reach the VCO from behind a spoke edge using backhaul policy to a hub, the return traffic is dropped by the hub.
-We can see that from the source edge hosting the client that the traffic is being sent to the hub.
-On the Hub we can see that the traffic/flow is dropped with the reason cloud_to_edge_drop.
edge:b2-edge1:~# debug.py --flow_dump all all all all | grep 10.0.5.25
345 1 0 0 5 5 0 169.254.8.2 10.0.5.25 443 49222 6 0 normal APP_TCP(205) APP_CLASS_OTHER_TCP_UDP(21) transactional Internet Backhaul backhaul loadbalance User Default 222715b9- N/A 0x208200802000000 1 peer 0x563e91352b70 0x7f7f3c322950 0x7f7f3c328ce0 40005 24757 0 10 cloud_to_edge_drop 29:pkt_path_ipv4_for_enterprise 2 25 26 29 51 52 59 87 0
344 1 0 5 5 5 0 8.8.8.8 10.0.5.25 7154 0 1 46 normal APP_ICMP(70) APP_CLASS_NETWORK_SERVICE(13) transactional Internet Backhaul backhaul loadbalance User Default 222715b9- N/A 0x208000800000000 1 peer 0x563e8aa1a860 0x7f7f3c322950 0x7f7f3c328ce0 47115 43113 0 0 - - 0-We can confirm that there is 2 way traffic on the hub confirming that the traffic does not drop prior to reaching the hub.
edge:b2-edge1:~# tcpdump -ennr /velocloud/tcpdump_-enni_br-network1000.pcap
reading from file /velocloud/tcpdump_-enni_br-network1000.pcap, link-type EN10MB (Ethernet)
07:57:01.382985 00:50:56:b9:10:98 > 00:50:56:b9:e0:a1, ethertype IPv4 (0x0800), length 74: 10.0.5.25.48808 > 169.254.8.2.443: Flags [S], seq 4051104646, win 64240, options [mss 1252,sackOK,TS val 2210776030 ecr 0,nop,wscale 7], length 0
07:57:01.383969 00:50:56:b9:e0:a1 > 00:50:56:b9:10:98, ethertype IPv4 (0x0800), length 74: 169.254.8.2.443 > 10.0.5.25.48808: Flags [S.], seq 4161118244, ack 4051104647, win 65160, options [mss 1460,sackOK,TS val 1879443197 ecr 2210776030,nop,wscale 7], length 0
07:57:02.398828 00:50:56:b9:e0:a1 > 00:50:56:b9:10:98, ethertype IPv4 (0x0800), length 74: 169.254.8.2.443 > 10.0.5.25.48808: Flags [S.], seq 4161118244, ack 4051104647, win 65160, options [mss 1460,sackOK,TS val 1879444212 ecr 2210776030,nop,wscale 7], length 0
07:57:02.414224 00:50:56:b9:10:98 > 00:50:56:b9:e0:a1, ethertype IPv4 (0x0800), length 74: 10.0.5.25.48808 > 169.254.8.2.443: Flags [S], seq 4051104646, win 64240, options [mss 1252,sackOK,TS val 2210777061 ecr 0,nop,wscale 7], length 0
07:57:02.414678 00:50:56:b9:e0:a1 > 00:50:56:b9:10:98, ethertype IPv4 (0x0800), length 74: 169.254.8.2.443 > 10.0.5.25.48808: Flags [S.], seq 4161118244, ack 4051104647, win 65160, options [mss 1460,sackOK,TS val 1879444228 ecr 2210776030,nop,wscale 7], length 0
07:57:04.414800 00:50:56:b9:e0:a1 > 00:50:56:b9:10:98, ethertype IPv4 (0x0800), length 74: 169.254.8.2.443 > 10.0.5.25.48808: Flags [S.], seq 4161118244, ack 4051104647, win 65160, options [mss 1460,sackOK,TS val 1879446228 ecr 2210776030,nop,wscale 7], length 0
Cause
Issue occurs due to a code inspection of a specific function which reveals that after a certain lookup, there is a code block that specifically checks the source IP of the configured VCO IP, If the conditions are met, the source route found by lookup is overwritten with the value of the cloud route.
Resolution
issue is fixed in "Woodford 5.2.3.3, Woodford 5.2.4.0, Zarza 6.1.0.0".
Feedback
