ICMP Ping Doesn't Work when Specifying the -I Option
When I run
ping -I and specify an interface I don’t get an echo-reply. However, when I run
ping without the
-I option everything works as expected. What is going on?
Specific Example for Issue
This example does not work:
cumulus@switch:default:~:# ping -I swp2 220.127.116.11 PING 18.104.22.168 (22.214.171.124) from 126.96.36.199 swp1.5: 56(84) bytes of data.
Whereas this example does work:
cumulus@switch:default:~:# ping 188.8.131.52 PING 184.108.40.206 (220.127.116.11) 56(84) bytes of data. 64 bytes from 18.104.22.168: icmp_req=1 ttl=63 time=4.00 ms 64 bytes from 22.214.171.124: icmp_req=2 ttl=63 time=0.000 ms 64 bytes from 126.96.36.199: icmp_req=3 ttl=63 time=0.000 ms 64 bytes from 188.8.131.52: icmp_req=4 ttl=63 time=0.000 ms ^C --- 184.108.40.206 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 0.000/1.000/4.001/1.732 ms cumulus@switch:default:~:#
auto swp1 iface swp1 address 220.127.116.11/24 up ip route add 0.0.0.0/0 via 18.104.22.168 auto swp2 iface swp2 address 22.214.171.124/24
Cumulus Linux Switch
auto swp1 iface swp1 auto swp2 iface swp2 auto swp17 iface swp17 auto bridge_2 iface bridge_2 address 126.96.36.199/24 bridge-ports swp1 swp17 up ip route add 0.0.0.0/0 via 188.8.131.52 auto bridge_5 iface bridge_5 address 184.108.40.206/24 bridge-ports swp2
auto swp30 iface swp30 address 220.127.116.11/24 auto swp17 iface swp17 address 18.104.22.168/24 up ip route add 22.214.171.124/24 via 126.96.36.199
auto swp1 iface swp1 address 188.8.131.52/24 up route add -net 184.108.40.206/24 gw 220.127.116.11 up route add -net 18.104.22.168/24 gw 22.214.171.124
What is happening here? This behavior is actually as expected. There is actually no need to have an SVI (switch VLAN interface) on the Cumulus Linux switch (in this particular example) for a host on the hypervisor to reach the “internet” (which was simulated here by another Cumulus Linux switch). The host has one default route (0.0.0.0/0) to 126.96.36.199, so when you specify the -I (interface) option, Cumulus Linux forces traffic to ARP for the destination (188.8.131.52) on the swp2 link between the Cumulus Linux switch and the hypervisor. There is no route on that interface (for that subnet) which forces the ARP on that link.
When you ping from the Internet router down to each SVI, both of them are reachable. If there were hosts on the hypervisor, both of them would be reachable as well since they would have a gateway configured on the Cumulus Linux switch. The -I option forces the ARP and there is no route. If the hypervisor utilized namespaces to split the route table (allowing for dual default routes), you could ping from the hypervisor using the -I option. There are also various ways not tested here to solve the dual routing issue, depending on what your hypervisor or host is doing in the situation (such as IP rules or containers).
- [Routing on Cumulus Linux](https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-43/Layer-3/Routing/
- [Network Troubleshooting](https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-43/Monitoring-and-Troubleshooting/Network-Troubleshooting/
- ip-sysctl on kernel.org, which covers