Sollte eine ping6-Sitzung weiter funktionieren, nachdem das Ethernet-Kabel des Zielgeräts an einen anderen Port am Switch angeschlossen wurde?

Dies ist eine wirklich grundlegende Frage, aber ich brauche eine Plausibilitätsprüfung, um sicherzustellen, dass meine Erwartungen nicht falsch sind und dass das, was ich sehe, nicht das erwartete Verhalten ist.

Die Situation ist: Ich habe einen Mac Pro mit MacOS / X und eine ARM-basierte Linux-Box. Beide sind mit einem 8-Port-Gigabit-Switch von Extreme Networks verbunden (ohne Internet-Uplink ist dies nur ein lokales LAN).

Auf meinem Mac starte ich eine Ping6-Sitzung und pinge die Linux-Box an:

$ ping6 fe80::21c:abff:fe00:55e5%en1

... und wie erwartet Pong-Antworten zurückbekommen.

Dann gehe ich zum Ethernet-Switch, trenne das Kabel, das zur Linux-Box führt, vom Ethernet-Switch und schließe das Kabel wieder an einen anderen offenen Port am Ethernet-Switch an.

Zu diesem Zeitpunkt gehe ich davon aus, dass die ping6-Sitzung auf meinem Mac (nach einer Pause von einigen Sekunden) wieder Antworten anzeigt.

Ich beobachte jedoch, dass die ping6-Sitzung manchmal auf unbestimmte Zeit keine Antworten mehr empfängt - oder zumindest, bis ich die Ethernet-Verbindung der Linux-Box wieder zu dem Switch-Port zurückbringe, mit dem sie ursprünglich verbunden war. (Stoppen und Neustarten des ping6-Prozesses hilft nicht; längeres Warten hilft nicht)

Meine Hauptfrage lautet also: Beobachte ich das erwartete Verhalten? Und wenn ja, kann ich (in der Software) irgendetwas tun, um mich von dieser Portänderung zu erholen? Oder wenn nicht, haben Sie eine Ahnung, was schief gehen könnte? (Mein Verdacht ist, dass es ein NDP-Problem sein könnte)

— Jeremy Friesner
quelle

Nicht AFAICT (Ich habe ein "arp -a -d" ausgeführt, das keine Auswirkungen zu haben schien. AFAICT arp ist eine IPv4-spezifische Sache und hat keine Auswirkungen auf IPv6-Lookups. Auf der Suche nach einer IPv6-äquivalenten Aktion habe ich es versucht. " npd -c "aber das schien auch nicht zu helfen)

— Jeremy Friesner

Erhalten Sie eine Antwort, wenn Sie die Adresse aller Knoten verwenden ff02::1 eher, als fe80::21c:abff:fe00:55e5? Funktioniert es, wenn Sie dann zur Unicast-Adresse zurückkehren?

— kasperd

Antworten:

Sie haben Recht, dass Sie nach dem erneuten Verbinden des Zielgeräts weiterhin Ping-Antworten erhalten sollten, auch nachdem Sie es auf einen anderen Switch-Port verschoben haben.

Das Stoppen und Neustarten des Ping6-Prozesses hilft nicht. längeres Warten hilft nicht

Das ist nicht normal. Etwas hindert entweder die Ping-Anforderungen oder die Antworten daran, zwischen den beiden Geräten nach dem Portwechsel übertragen zu werden. Ich kenne die spezifischen Firewall-Konfigurationsmöglichkeiten unter Linux nicht, aber auf einem Windows-Computer kann eine Änderung der Netzwerkschnittstelle dazu führen, dass unterschiedliche Firewall-Regeln angewendet werden.

Es besteht auch die Möglichkeit, dass etwas mit dem Switch selbst nicht stimmt. Dies lässt sich jedoch leicht ausschließen, indem sichergestellt wird, dass die Linux-Box mit dem Netzwerk normal kommunizieren kann, während sie mit dem neuen Switch-Port verbunden ist.

— Twisty Impersonator
quelle

Es scheint, dass die "äußere Chance" bestätigt ist: Das Fehlverhalten scheint spezifisch für den von mir verwendeten Ethernet-Switch zu sein (ein Extreme Networks Summit X440-8t). Wenn ich stattdessen alles wieder mit einem anderen Switch (einem Extreme Networks Summit X440-24p) verbinde, erhalte ich das erwartete Verhalten.

— Jeremy Friesner

@JeremyFriesner, vielen Dank für die Rückmeldung der konkreten Ursache. Froh zu wissen, dass unser Verstand nicht in Frage gestellt werden muss!

— Twisty Impersonator

@ Jeremy Friesner Vielleicht ist einer der Ports am Switch einfach defekt.

— kasperd

@kasperd Ich habe das Problem an den meisten (wenn nicht allen) Ports des Switches gesehen, daher glaube ich, dass der Fehler eher am Switch selbst liegt. vielleicht in seiner Firmware.

— Jeremy Friesner

@JeremyFriesner Es ist durchaus plausibel, dass es Switches gibt, bei denen die Firmware das Löschen von CAM-Tabelleneinträgen übernimmt, die mit Ports verbunden sind, die die Verbindung verloren haben. Und es ist auch plausibel, dass es Schalter gibt, die das nicht tun. Der Unterschied in der Firmware kann sich also auf das auswirken, was Sie beobachtet haben.

— kasperd

Der Switch kann erst dann erkennen, dass der Port geändert wurde, wenn der Computer, dessen Port geändert wurde, Datenverkehr sendet. Wenn Ihr Linux-Computer leise ist und keine Netzwerkaktivität ausführt, wenn Sie das Ethernet-Kabel an einen anderen Port anschließen, müssen Sie warten, bis Datenverkehr gesendet wird.

Sobald der Datenverkehr gesendet wurde, erkennt der Switch die Tatsache, dass er verschoben wurde, und aktualisiert seine internen Tabellen entsprechend.

— Michael Hampton
quelle

Sollte unter normalen Umständen nicht der einfache Vorgang des Trennens / erneuten Verbindens der Netzwerkverbindung der Linux-Box mindestens auslösen etwas der Verkehr? Die Erneuerung der DHCP-Lizenz fällt mir ein ...

— Twisty Impersonator

@TwistyImpersonator Nur wenn der Computer seine IP-Adresse über DHCP erhält.

— Michael Hampton

@MichaelHampton Es ist nicht ganz richtig, dass der Schalter keine Möglichkeit zum Wissen hat. Der Switch weiß, dass die Verbindung zum Port unterbrochen wurde, und es ist sinnvoll, alle CAM-Tabelleneinträge zu löschen, die sich auf einen Port beziehen, wenn die Verbindung zum Port unterbrochen wird. Ich habe aber noch nie getestet, ob Schalter das tun.

— kasperd

@kasperd Anscheinend machen das einige Schalter und andere nicht.

— Michael Hampton