aus dem Netzwerk Insider August 2023
Als ich vor 30 Jahren bei der ComConsult anfing waren die beiden bestimmenden Netzwerke der Token Ring und das Ethernet. Ersterer ist schon lange verschwunden („Toter Ring“). Mit dem zweiten leben wir noch immer. Nur damals war Ethernet gleich Koaxialkabel. Ein Kabel mit etwa 10 mm Durchmesser (RG-213) und bis zu 500 m lang wurde an passenden Orten mit einer Klammer (Tap) versehen, die sich bis zum Innenleiter durchbohrte, um die Daten abzugreifen. An beiden Enden musste das Kabel mit einem Widerstand von 50 Ω abgeschlossen werden. Alles in allem war das eine fehlerträchtige Angelegenheit. Noch schlimmer war es mit der Variante, die dünneres Kabel (RG-58) und BNC-Stecker verwendete, welche über T-Stücke von Computer zu Computer geführt wurde.
Ich erinnere mich an zahlreiche Messeinsätze, an denen ich mit einem Time Domain Reflectometer (TDR) des Typs Tektronix 1503C vor Ort solche Kabelstrecken durchgemessen habe. Das TDR schickt einen Impuls auf das Kabel und detektiert Reflexionen solcher Impulse, die durch Fehler im Kabel hervorgerufen werden. Über die Antwortzeit, mit der die reflektierten Impulse eintreffen, lässt sich der Ort des Fehlers bestimmen. So etwas kennen Sie heute noch vom optischen Reflektometer (OTDR) oder vom Antennenmessgerät mit seiner Funktion „Distance to Fault“.
In dieser Zeit entstanden die sogenannten Brücken (Bridges), die Ethernet- oder Token-Ring-Segmente miteinander koppelten. Anfang der 90er Jahre brachte der Hersteller Kalpana eine Multiport-Brücke auf den Markt, die erstmals Daten so schnell übertragen konnte, wie das Netzsegment sie anlieferte („Wire Speed“). Kalpana nannte sein Gerät „Switch“. Diese Technik begründete schließlich die Erfolgsgeschichte von Ethernet.
Brücken und Switches brauchte (und braucht) man, um redundante Netzstrukturen aufzubauen. Ausgehend von einer zentralen Komponente („Root Bridge“) werden Informationen bezüglich optimaler Wege im Netz an alle Switches verteilt. Träger dieser Information sind „Hello-Pakete“. Bestimmte Ports werden deaktiviert („blocking“), damit keine Schleifen entstehen, über die sich Broadcasts ungehindert ausbreiten und so das Netz fluten könnten („Loops“). Letztlich entsteht auf diese Weise eine Baumstruktur („Spanning Tree“), über die Daten ausgetauscht werden.
Redundante Wege sind wie gesagt im Zustand „blocking“. Entsprechende Ports lauschen einzig auf Hello-Pakete und prüfen so, ob die Netzstruktur stabil ist. Bleiben an einem solchen Port die Hello-Pakete aus, aktiviert der Switch den Port, und die Redundanz wird aktiv.
Das entsprechende Protokoll stammt aus dem Jahr 1998 und heißt „Spanning Tree Protocol“ (STP). 2004 wurde eine verbesserte Version veröffentlicht, in der „Rapid STP“ und „Multiple STP“ (RSTP bzw. MSTP) definiert wurden.
Vieles davon wird Ihnen geläufig sein. Doch es scheint, RSTP sei inzwischen überholt. Moderne Netze nutzen stattdessen Routing-Techniken. Redundante Pfade lassen sich gleichzeitig und parallel nutzen. Unterbrechungen werden in Sekundenbruchteilen geheilt.
Jedoch, im Kleinen ist RSTP immer noch aktiv und bereitet zuweilen unerwartete Probleme. So wie neulich bei einem Kunden: Eine Produktionsanlage verlor regelmäßig die Netzverbindung. Der Switch in der Anlage – ein Produkt des Steuerungsherstellers – verfügt über Uplinks an zwei Distribution Switches. Im Netzwerk-Management ließ sich verifizieren, dass an beiden Distribution Switches der Link zum Anlagen-Switch aktiv war. Wurde einer der beiden Links deaktiviert, war das Problem behoben. Das konnte jedoch nicht die Lösung sein, weil in dem Fall keine Redundanz mehr bestand.
Das Logfile des Anlagen-Switchs lenkte die Fehlersuche in die richtige Bahn. Dort tauchten in kurzen Abständen Meldungen der Art „(R)STP: topology change detected“ auf. In der Tat bildet das Dreieck aus Anlagen-Switch und den beiden Distribution Switches eine Schleife, die durch das RSTP aufzutrennen ist, damit kein „Loop“ mit Broacast-Sturm entsteht. Offensichtlich funktionierte dieses Protokoll hier nicht einwandfrei.
Letztlich konnte die Ursache auf einen Kabelfehler zurückgeführt werden. Hierfür war die im Distribution Switch enthaltene TDR-Funktion nützlich, die eine der Kabelstrecken als defekt entlarvte. Obwohl der Distribution Switch einen Link erkannte, gingen offensichtlich sporadisch Pakete in Richtung Anlagen-Switch verloren. Da auch die Hello-Pakete davon betroffen waren, erkannte das RSTP eine Störung und aktivierte die Redundanz so lange, bis wieder Hello-Pakete empfangen wurden, und so fort.
Wir lernen daraus Folgendes: Redundanzverfahren sind so lange gut, wie ein Fehler für eine vollständige Unterbrechung sorgt. „Halb-defekte“ Strecken führen dagegen zu unerwarteten Problemen. Das können wie im beschriebenen Fall Kabel sein, auf denen Pakete nur mit einer gewissen Wahrscheinlichkeit verloren gehen. Das kann genauso gut ein Glasfaserpaar mit einer defekten Faser oder einem verschmutzten Stecker sein.
Grundsätzlich können alle Redundanzprotokolle von derlei Effekten in ihrer Funktion beeinträchtigt werden. Die Auswirkungen sind jedoch beim RSTP erfahrungsgemäß am gravierendsten. Es ist also nach wie vor hilfreich, sich mit der Funktionsweise dieses Protokolls auszukennen. Und Sie sollten passende Messtechnik für Ihre Verkabelung vorhalten.