Kürzlich hatte ich mit einem Standort zu tun, der ein Problem mit der Verbindung zwischen seinem Modul und einem seiner Ethernet-Switches zu haben schien. Als Test hat der Systemadministrator, nennen wir ihn Fred, den Switch angefunkt, und da alle Pings eine Antwort erhielten, kam Fred zu dem Schluss, dass das Problem woanders lag.
Das Problem bei dieser Schlussfolgerung ist, dass die Pings nicht über die Verbindung des Moduls zum Switch gingen.
Ich beschreibe die Netzwerkkonfiguration. Ich habe die IP-Adressen in private Netzwerke geändert, aber die Beziehung zwischen Schnittstellen und Netzwerken ist ähnlich.
Das Modul hat zwei Schnittstellen, #enet10 und #enet192. Die IP-Adresse von #enet10 ist 10.1.1.1, das ist die Schnittstelle, die über den problematischen Link mit dem Switch verbunden ist. Die IP-Adresse von #enet192 lautet 192.168.1.1 und ist mit einem anderen Switch über einen anderen Link verbunden. Das Standard-Gateway lautet 192.168.1.254, und es sind keine anderen Routen konfiguriert. Die Management-IP-Adresse des Switches lautet 172.16.100.100.
Um 172.16.100.100 zu erreichen, muss das Modul das Standard-Gateway verwenden, und um das Standard-Gateway zu erreichen, muss es die Pakete über die Schnittstelle #enet192 senden. Der Switch sieht die Quelle der Ping-Pakete als die Adresse von #enet192, 192.168.1.1, und antwortet daher an diese Adresse. Keines der Pakete geht von #enet10 aus oder kommt bei #enet10 an. Die Tatsache, dass #enet10 direkt mit dem Switch verbunden ist, spielt keine Rolle; das einzige, was zählt, ist die Zieladresse des Pakets und die Routing-Tabelle des Moduls.
Gibt es für Fred eine Möglichkeit, die Verbindung zwischen #enet10 und dem Switch zu testen? Nein, das Beste, was Fred tun kann, ist, einen anderen Host im Subnetz 10 anzupingen. Das würde dazu führen, dass die Pakete von #enet10 übertragen werden und über die Verbindung zum Zielhost gehen und dass die Antworten auf dem gleichen Weg zurückkommen, aber es würde sowohl die Verbindung zwischen #enet10 und dem Switch als auch alle anderen Verbindungen zwischen dem Switch und dem Zielhost testen.
Fred könnte den Befehl "netstat -interface #enet10" verwenden, um zu sehen, ob die Hardware oder der Treiber irgendwelche Fehler auf niedriger Ebene auf der Verbindung melden. Der Switch verfügt auch über Befehle, die die Anzahl der Fehler auf dem Port melden, der mit dem an #enet10 angeschlossenen Link verbunden ist. Es gibt jedoch keine Möglichkeit, die Verbindung zwischen #enet10 und dem Switch zu testen.