Recently I dealt with a site that appeared to be having an issue with the link between their module and one of their Ethernet switches. As a test the system administrator, call him Fred, pinged the switch and since all pings got a reply Fred concluded the problem was elsewhere.
The problem with this conclusion is that the pings were not going over the module’s link to the switch.
Let me describe the networking configuration, I’ve changed the IP addresses to private networks but the relationship between interfaces and networks is similar.
The module has two interfaces, #enet10 and #enet192. The IP address of #enet10 is 10.1.1.1, this is the interface that is connected to the switch over the problematic link. The IP address of #enet192 is 192.168.1.1, and is connected to a different switch over a different link. The default gateway is 192.168.1.254 and no other routes are configured. The switch’s management IP address is 172.16.100.100.
To reach 172.16.100.100 the module must use the default gateway and to reach the default gateway it must send the packets out of the #enet192 interface. The switch sees the source of the ping packets as #enet192’s address, 192.168.1.1, and so replies to that address. At no time do any of the packets leave from or arrive at #enet10. The fact that #enet10 is directly connected to the switch doesn’t matter; the only thing that matters is the packet’s destination address and the module’s routing table.
So is there any way for Fred to test the link between #enet10 and the switch? No, the best that Fred can do is to ping some other host on the 10 subnet. That would cause the packets to be transmitted from #enet10 and go over the link to the target host and for replies to come back the same way but it would be testing both the link between #enet10 and the switch and any other links between the switch and the target host.
Fred could use the “netstat -interface #enet10” command to see if the hardware or the driver are reporting any low level errors on the link. The switch also has commands that will report error counts on the port connected to the link connected to #enet10. But there is no way to test the link between #enet10 and the switch.