Ein einziger falsch verkabelter Switch kann ein OT-Netzwerk so lange mit Broadcast-Verkehr fluten, bis nichts anderes mehr durchkommt. Produktionslinien stehen still, Sicherheitssysteme werden unerreichbar, oft innerhalb einer Minute. Das Schwierige ist nie, den Loop zu beheben. Es ist, ihn zu finden.
Loops und Broadcast-Storms
Ein Switching-Loop entsteht, wenn es mehr als einen Layer-2-Pfad zwischen zwei Switches gibt. Empfängt ein Switch einen Broadcast-Frame, etwa einen ARP-Request, leitet er ihn über jeden Port weiter ausser über den, an dem er angekommen ist. In einer Loop-Topologie kommt dieser Frame direkt zurück, wird erneut weitergeleitet, und die Kopien vervielfachen sich exponentiell.
Das ist ein Broadcast-Storm. Das Netzwerk wird mit doppelten Frames geflutet, die verfügbare Bandbreite fällt auf null, die Switch-CPUs laufen voll, und die MAC-Adresstabellen flattern, weil dieselben Adressen Port um Port auftauchen. Legitimer Verkehr kommt nicht mehr durch.
Ohne Spanning Tree, in einer Minute
Von einem einzigen versehentlichen Loop aus geht der Zusammenbruch schnell, und in einem Industrienetzwerk sind die Folgen physisch:
- 0–5 sAus einem ARP-Request werden Kopien, die sich exponentiell vermehren.
- 5–15 sDie Switch-CPUs erreichen 100%, während sie den Storm-Verkehr verarbeiten.
- 15–30 sJede Verbindung ist ausgelastet; legitimer Verkehr beginnt auszufallen.
- 30–60 sDie MAC-Tabellen flattern ununterbrochen; die Switches werden instabil.
- 1 min+Komplettausfall des Segments. Die Produktionslinie steht still.
Wie Spanning Tree das verhindert
Industrienetzwerke brauchen Redundanz: fällt eine Verbindung aus, muss die Produktion weiterlaufen. Doch redundante Layer-2-Pfade sind genau das, was Loops erzeugt. Das Spanning Tree Protocol (IEEE 802.1D) und sein moderner Nachfolger RSTP (802.1w) lösen diesen Widerspruch auf. Sie erhalten die physische Redundanz und stellen zugleich eine loop-freie logische Topologie her.
Es funktioniert über eine Wahl. Die Switches tauschen BPDUs aus und bestimmen eine Root Bridge, den Switch mit der niedrigsten Bridge-ID, die eine konfigurierbare Priorität mit der MAC-Adresse des Switches kombiniert. Jeder andere Switch berechnet dann über die Pfadkosten seinen kürzesten Weg zur Root, und jedem Port wird eine Rolle zugewiesen:
- Root PortDer beste Pfad zur Root Bridge. Leitet Verkehr weiter.
- Designated PortLeitet den Verkehr für das Netzwerksegment weiter, das er bedient.
- Blocked PortEin redundanter Pfad, logisch deaktiviert gehalten, bis er gebraucht wird.
Ändert sich die Topologie, wenn eine Verbindung wegfällt oder ein Switch hinzukommt, berechnet Spanning Tree den Baum neu und aktualisiert die Port-Zustände. Mit RSTP geschieht diese Rekonvergenz in Sekunden.
STP, RSTP und MRP: die Konvergenzzeit entscheidet
Welches Protokoll den Baum aufspannt, bestimmt, wie lange ein Industrienetzwerk nach einer Topologieänderung steht. Klassisches STP nach IEEE 802.1D braucht 30 bis 50 Sekunden für die Neukonvergenz, davon je 15 Sekunden im Listening- und im Learning-Zustand, alles timer-basiert. RSTP (802.1w) drückt das über Proposal/Agreement-Handshakes und Edge-Port-Bezeichnung auf 1 bis 6 Sekunden. Für Echtzeitanwendungen ist auch das zu langsam; dort übernimmt MRP.
- Listening-Zustand: 15 s
- Learning-Zustand: 15 s
- Timer-basierte Konvergenz
- Eine Root Bridge pro Netzwerk
- Keine VLAN-Optimierung
- Proposal/Agreement-Mechanismus
- Schneller Edge-Port-Übergang
- Backup-Port-Rollen
- Standard für Neuinstallationen
- Rückwärtskompatibel zu STP
- Spezifisch für Ring-Topologien
- Garantierte Failover-Zeiten
- Empfohlen für PROFINET
- Industrial-Ethernet-Standard
- Für Echtzeitanwendungen
Der teuerste Fehler in gewachsenen Netzwerken ist die Mischung. Sobald ein einziger Switch noch Legacy-STP spricht, fällt das Segment auf die langsamen STP-Timer zurück. Die Konvergenzzeit, mit der geplant wurde, ist dann nicht die, die man bekommt, und das zeigt sich erst im Ausfall.
Industrielle Failover-Szenarien
Ist die Redundanz richtig ausgelegt, sieht ein Ausfall aus der Anlage heraus unspektakulär aus:
- Primärer Ring fällt ausDer sekundäre Ring hält die SPS-Konnektivität aufrecht.
- Switch fällt ausBlockierte Ports aktivieren sich unter RSTP innerhalb von 1 bis 6 Sekunden.
- KabelbruchAutomatische Umleitung über den alternativen Pfad.
- SCADA-ZugriffMehrere redundante Pfade zu den Kontrollsystemen.
Vorausgesetzt, die Redundanz ist tatsächlich vorhanden und der Baum sieht sie auch so. Genau diese Annahme lässt sich ohne eine Karte der Topologie nicht prüfen.
Wenn es nie wirklich konfiguriert wurde
Richtig gemacht, beginnt der Storm nie. Doch ein Netzwerk, das über zwei Jahrzehnte gewachsen ist, über Hersteller und Übergaben hinweg, hat Spanning Tree selten richtig konfiguriert. Die Root Bridge liegt dort, wo die Wahl zufällig gelandet ist. Die Prioritäten stehen auf Werkseinstellung. Eine «temporäre» redundante Verbindung wurde vor Jahren dauerhaft. Der Baum bleibt stabil, unbemerkt, bis eine Topologieänderung den Loop auslöst, den er immer verborgen hat.
Der Blast Radius
Bildet sich ein Loop, ist die Frage, wie weit sich der Schaden ausbreitet. Der Blast Radius eines Layer-2-Ausfalls ist jedes Gerät in derselben Broadcast-Domäne, also im selben VLAN. In den flachen Netzwerk-Designs, die in älteren Industrieanlagen noch verbreitet sind, können das Hunderte Geräte über mehrere Produktionslinien hinweg sein.
Und Layer-2-Ausfälle kümmern sich nicht um Geografie. Ein Broadcast-Storm, ausgelöst durch ein falsch gepatchtes Kabel an einem entfernten Standort, kann eine WAN-Verbindung auslasten und ein Gebäude Kilometer entfernt lahmlegen.
Zwei Wege, wie sich derselbe Fehler entfaltet
Produktionswerk
- 0 sEine Technikerin schliesst ein redundantes Kabel an, und im Produktionsnetzwerk bildet sich ein Loop.
- 15 sProduktionslinie 1 steht still, weil die PLC-Kommunikation eine Zeitüberschreitung erleidet.
- 45 sDie gesamte Produktion steht.
Fernwärme, bis ins Bürogebäude
- 0 sWartung im Heizwerk; ein Kabel kommt in den falschen Port.
- 30 sDie Kesselüberwachung fällt aus und das SCADA-System ist überlastet.
- 90 sDie WAN-Verbindung läuft voll; der Storm flutet das Unternehmensnetzwerk.
- 3 minDas Bürogebäude ist offline. 200 Mitarbeitende, fünf Kilometer entfernt, können nicht arbeiten.
Spanning Tree ist ein Graph, keine Tabelle
Üblicherweise inspiziert man Spanning Tree, indem man sich auf einen Switch einloggt und show spanning-tree liest, dann den nächsten Switch, dann den nächsten. Jeder meldet seine eigenen Ports: dieser leitet weiter, jener blockiert. Was keiner von ihnen zeigt, ist der Baum selbst. Welcher Switch ist tatsächlich Root? Welchen physischen Loop bricht ein bestimmter Blocked Port auf? Fällt diese Verbindung aus, wie gross ist der Blast Radius?
Spanning Tree ist eine Eigenschaft des gesamten Netzwerks, nicht eines einzelnen Switches, und es hat die Gestalt eines Graphen. Einen Graphen liest man nicht aus einer Spalte von Port-Zuständen auf zwanzig getrennten Konsolen. Man muss ihn zeichnen.
Den Spanning Tree visuell abzubilden beantwortet diese Fragen aus dem laufenden Netzwerk, bevor eine Änderung gemacht wird, statt im Incident-Review danach.
Warum manuelle STP-Analyse fast unmöglich ist
Die Spanning-Tree-Topologie eines gewachsenen Netzwerks von Hand zu rekonstruieren bedeutet, BPDU-Austausch, Bridge-Prioritäten, Port-Kosten und VLAN-Konfigurationen über Dutzende bis Hunderte Switches hinweg zusammenzutragen. Vier Dinge machen das in der Praxis unbezahlbar:
- DatensammlungPer-VLAN-Spanning-Tree-Instanzen, Bridge-Prioritäten und MAC-Adressen, Port-Kosten und -Zustände, BPDU-Timing-Parameter, dazu herstellerspezifische Implementierungen.
- TopologieDutzende zu dokumentierende Switches, mehrere redundante Pfade, undokumentierte Verbindungen und der Unterschied zwischen physischer und logischer Topologie.
- DynamikKonfigurationsdrift über die Jahre, wartungsbedingte Änderungen, Notfall-Bypass-Verbindungen. Die Analyse ist veraltet, sobald jemand ein Kabel steckt.
- RisikobewertungBlast-Radius-Berechnung, Single Points of Failure, suboptimale Root-Bridge-Platzierung, Konvergenzzeit-Schätzung, Lastverteilung.
