OK, das ist meine Situation.
Dies ist im Internet. Der 6224 ist der Router in diesem Bild und befindet sich physisch in Kanata.
Sowohl VLAN 1697 als auch 3994 werden von einem Internetdienstanbieter bereitgestellt. Diese VLANs werden über ein einzelnes 1-GB-Ethernet-Kabel bereitgestellt.
Die Kanata-Hosts sind direkt an den 6224 angeschlossen; die anderen beiden Standorte sind remote.
VLAN 3994 ist ein einzelner IP-Adressraum, daher sollte es theoretisch physisch keine Rolle spielen, wo sich die Hosts in diesem Subnetz befinden.
Hier ist das Problem.
Ich habe ein Überwachungssystem, das weiter mit dem Internet verbunden ist, sodass Sonden vom Monitor in dieses Diagramm im 1697-VLAN gelangen würden.
Wenn ich Hosts in Albert oder Bells Corners vom Internet aus anpinge, gibt es 0 Verlust. Die Verbindung sieht perfekt aus.
Wenn ich Hosts in Kanata anpinge, verliere ich zwischen 10 und 40 % der Pings. Der Verlust ist nicht vorhersehbar, aber: Wenn ich sie verliere, verliere ich immer mindestens 3, normalerweise 4, selten mehr, Pings in einem Haufen.
Ich habe einen Monitor direkt an den 6224 in Kanata auf 3994 angeschlossen.
Wenn der Monitor die Routing-Schnittstelle 6224 anpingt, sehe ich genau dasselbe Verlustmuster – aber NICHT gleichzeitig mit dem Verlust vom Remote-System. Die Ping-Zeit beträgt etwa 1 ms.
Wenn der Monitor ein anderes System anpingt, das direkt an den 6224 angeschlossen ist, gibt es keinen Verlust. Die Ping-Zeit beträgt etwa 0,1 ms, ein Zehntel der Zeit zum Pingen des Routers.
Weiß jemand, was hier los ist?
Aktualisieren, um die Dinge möglicherweise weniger klar zu machen
Was anscheinend passiert, ist, dass der eingehende und ausgehende Datenverkehr über die Verbindung des ISPs in Ordnung ist. Das Problem liegt beim Datenverkehr, der vom Router-Gehirn zum Switching-Gehirn (oder vielleicht auch zurück) geht.
Ich kann dem ISP keine Schuld geben, da der Internetzugang zu/von den beiden Remote-Sites stabil ist. Nur Hosts, die direkt an den 6224 angeschlossen sind, haben Probleme.
Aktualisierung 2
OK, nachdem ich lange Zeit die Spuren beobachtet habe, ist mir ein spezifischeres Symptom aufgefallen.
Ich habe einen TCPdump auf VLAN 3994 des ISP-Uplinks ausgeführt, um nach meiner eigenen Adresse zu suchen, in der Annahme, dass ich nur Broadcast-Verkehr zu den Remote-Sites sehen sollte. Stattdessen sah ich die Pakete, die ich auf der Schnittstelle meines Systems erwartet hätte und die über TLS auf diesem VLAN gingen.
Also:
Aus irgendeinem Grund denkt der 6224 häufig, dass sich mein System am anderen Ende des TLS befindet.
Wenn ich die Switching-Tabelle im laufenden Betrieb untersuche, sieht mein Eintrag folgendermaßen aus:
3994 0007.E924.F714 2/g16 Dynamic
…was Sinn macht, da es an Port 16 angeschlossen ist. Wenn es jedoch defekt ist, sieht es folgendermaßen aus:
3994 0007.E924.F714 2/g22 Dynamic
Ströme fehlgeleiteter Pakete scheinen von einem Broadcast von meinem System geleitet zu werden. Ich sehe jedoch, dass ein Broadcast mein System verlässt und zwei über das 3994-VLAN zum TLS. Normalerweise handelt es sich um einen IGMP V2-Mitgliedschaftsbericht/Join-Gruppe 224.0.0.251, aber manchmal ist es der Management-Chip auf meinem System, der für sich selbst einen Arp ausführt (er tut dies etwa alle 2 Sekunden aus dummen Gründen).
Dies impliziert, dass es in Bells Corners oder Albert ein System gibt, das meine Übertragung hört und sie aus irgendeinem Grund zurücksendet. Der 6224 sagt also: „Ah, dieser Mac muss wirklich über die TLS-Verbindung ausgefallen sein“ und passt seine Switching-Tabelle entsprechend an.
Kommt Ihnen diese Problembeschreibung bekannt vor?
Antwort1
OK, ich habe das herausgefunden und werde es hier aufschreiben. Diese spezielle Lösung wird wahrscheinlich niemandem helfen, da es sich um einen Sonderfall handelt.
In der alten Geschichte der Verbindung mit diesem Anbieter haben wir dem primären VLAN ein zweites hinzugefügt. Damals hat der Anbieter dieses VLAN verbunden, da beide markiert waren.Undauf ihrer Seite der Verbindung unmarkiert. Ihr Switch behandelt die markierten und unmarkierten Verbindungen als separate Verbindungen.
Was also passiert, ist, dass mein mit dem Dell verbundenes System einen ARP-Broadcast aussendet (die Verwaltungsschnittstelle auf diesem Computer sendet aus dummen Gründen jede halbe Sekunde ARP-Pakete), die der Switch über die Verbindung an die Remote-Site weiterleitet. Der Switch beim Provider hört den Broadcast auf der ungetaggten Schnittstelle --und sendet es mir über die getaggte Schnittstelle zurück. Der Switch hört dies und schlussfolgert daraus, dass die MAC-Adresse, von der der Broadcast ausgeht, tatsächlich über die Verbindung des Providers erreichbar ist. Nachfolgende Pakete werden daher fehlgeleitet.
Die Lösung bestand darin, dass der Anbieter seine Konfiguration so änderte, dass sie mit der des Dell übereinstimmte. Alle allgemeinen Verbindungsprobleme sind verschwunden.