Sie haben die Diagramme gesehen. Busnetze. Ringtopologien. Sie alle haben einen fatalen Fehler. Ein einziger Kettenbruch und alles steht still.
Sternnetzwerke sehen sicherer aus. Sie haben einen zentralen Schalter. Jeder Knoten wird daran angeschlossen. Wenn ein Computer ausfällt, bleiben die anderen online. Aber es gibt eine Falle. Dieser zentrale Schalter? Es ist ein Single Point of Failure.
Schauen Sie sich das Setup unten an.
![Diagrammbeschreibung: Ein Netzwerk mit Switch A, Switch B und Switch C. Mit jedem Switch sind Knoten verbunden. Schalter A und C sind mit Schalter B verbunden.]
In diesem Szenario ist Switch B das Rückgrat. Es verbindet Switch A und Switch C.
Wenn Schalter A ausfällt, werden die Knoten auf A dunkel. Aber die Knoten auf B und C kommunizieren immer noch miteinander. Das Gleiche gilt, wenn Switch C ausfällt. Teilweiser Ausfall. Überschaubar.
Aber wenn Schalter B stirbt?
Alles geht auf Null. Das gesamte Netzwerk bricht zusammen. Warum? Weil B die Brücke ist. Keine Brücke, kein Verkehr.
Hier kommt Redundanz ins Spiel. Dabei geht es nicht nur um Notstromversorgung oder zusätzliche Festplatten. Es geht um architektonische Widerstandsfähigkeit.
Was passiert, wenn wir das physische Layout ändern?
Stellen Sie sich vor, Sie fügen eine direkte Verbindung zwischen Switch A und Switch C hinzu. Ein redundantes Segment.
Wenn nun Switch B ausfällt, kann A immer noch mit C kommunizieren. Der Pfad ändert sich. Der Verkehr wird umgeleitet. Das Netzwerk bleibt bestehen.
Das ist der Kern der Netzwerkredundanz. Es ist keine Zauberei. Es ist nur eine zweite Möglichkeit, von Punkt X nach Punkt Y zu gelangen.
Aber das Hinzufügen eines Kabels reicht nicht aus. Sie benötigen Protokolle, die diese Redundanz verstehen. Andernfalls erzeugen Sie Schleifen. Und Schleifen bringen Netzwerke schneller zum Absturz als ein toter Schalter.
Wir kratzen hier nur an der Oberfläche. Die eigentliche Arbeit passiert, wenn man über Spanning-Tree-Protokolle und Failover-Zeiten spricht.
Aber zuerst muss man das Problem erkennen. Und das Problem ist einfach.
Abhängigkeit von einem einzigen Fehlerpunkt.
Wenn Sie das beseitigen, überleben Sie den nächsten Hardwarefehler.
Der erste Schalter stirbt. Der Zweite übernimmt. Der Verkehr bewegt sich weiter.
Das ist das Schöne an der Netzwerkredundanz. Sie haben den Single Point of Failure beseitigt. Wenn sich ein Teil der Hardware selbst blockiert, bleibt der Kreislauf geschlossen. Das Netzwerk atmet.
Aber jetzt haben wir ein neues Problem.
Die Schleife des Todes
Stellen Sie sich zwei Schalter vor, die über zwei verschiedene Kabel verbunden sind. Oder vielleicht schließt sich ein dritter Schalter der Party an. Jetzt haben Sie überall Wege.
Es eignet sich hervorragend für Redundanz. Bis das nicht mehr der Fall ist.
Wenn ein Switch einen Frame sendet und nicht weiß, wohin er geht, überflutet er ihn an jeden Port. In einer einfachen Linientopologie erreicht dieser Frame das Ende und stoppt. In einer Schleife? Es hüpft ewig.
Sendungen vervielfachen sich. Unicast-Frames springen hin und her. Plötzlich ist Ihr Netzwerk nicht nur langsam. Es ist tot. Die CPU steigt bei jedem Schalter auf 100 %. Pakete gehen verloren. Die gesamte Infrastruktur steht still.
Das ist der Sendesturm. Es ist keine Funktion. Es ist eine Feuerübung.
Die Schleife stoppen
Wie kann man also die physische Redundanz ohne logisches Chaos aufrechterhalten?
Sie benötigen ein Protokoll. Etwas, das besagt: „Hey, ich sehe zwei Pfade. Ich werde einen blockieren. Wenn dieser kaputt geht, werde ich den anderen freigeben.“
Geben Sie Spanning Tree Protocol (STP) ein.
Es gibt es schon seit den 80ern. Es ist alt. Es ist klobig. Aber es funktioniert. STP untersucht alle Verbindungen zwischen Switches. Es berechnet den besten Pfad zur Root-Bridge (dem Hauptswitch). Dann versetzt es jeden anderen redundanten Link in einen blockierenden Zustand.
Verkehrsströme. Die Backup-Leitung steht dort im Leerlauf. Bereit.
Wenn das Primärkabel durchtrennt wird? Der blockierende Port wird aktiviert. Es wird aktiv. Das Netzwerk heilt.
Es dauert allerdings ein paar Sekunden. Vielleicht dreißig. In dieser Zeit starren Benutzer auf Ladebalken.
Die schnellere Lösung: Rapid Spanning Tree
Dreißig Sekunden sind eine Ewigkeit in der Serverzeit. Wenn Sie ein Rechenzentrum oder auch nur ein geschäftiges Büro betreiben, sind dreißig Sekunden Ausfallzeit inakzeptabel.
Geben Sie Rapid Spanning Tree Protocol (RSTP) oder 802.1w ein.
Es ist die gleiche Grundidee. Blockieren Sie redundante Links. Entsperren Sie sie bei Bedarf. Aber RSTP verkürzt die Konvergenzzeit von Sekunden auf Bruchteile einer Sekunde.
Dies geschieht durch eine schnellere Neuverhandlung der Portrollen. Es wartet nicht auf Timeouts. Es redet. Es entscheidet. Es wirkt.
Welches sollten Sie verwenden?
Wenn Sie ein modernes Netzwerk aufbauen, verwenden Sie kein einfaches STP. Sie verwenden RSTP. Oder sein Cousin, Multiple Spanning Tree Protocol (MSTP), mit dem Sie verschiedene Spanning Trees für verschiedene VLANs ausführen können.
Warum?
Weil Sie möglicherweise möchten, dass Sprach-VLANs einen anderen Weg einschlagen als Daten-VLANs. Mit MSTP können Sie diese Last ausgleichen. Oder halten Sie sie zumindest davon ab, sich gegenseitig aus dem Weg zu gehen.
Wenn Sie Cisco-Geräte verwenden, denken Sie wahrscheinlich an PVST+ (Per-VLAN Spanning Tree). Es ist proprietär. Es führt für jedes einzelne VLAN eine separate STP-Instanz aus.
Es belastet die CPU stark. Aber es gibt Ihnen eine detaillierte Kontrolle.
Das Fazit
Redundanz ist nicht verhandelbar
