Inhalt

Einleitung

Hintergrund

Unterstützung von RSTP in Catalyst-Switches

Neue Hafenstaaten und Hafenrollen

Hafenstaaten

Port-Rollen

Neues BPDU-Format

Vollständige Ansicht der Diagramme zu Cisco BPDU, IEEE BPDU und BPDU

Neue BPDU-Verarbeitung

BPDUs werden an jede Begrüßungszeit gesendet

Schnelleres Altern von Informationen

Akzeptiert minderwertige BPDUs

Schneller Übergang in den Weiterleitungsstatus

Edge-Ports

Verbindungstyp

Konvergenz mit 802.1D

Konvergenz mit 802.1w

Reihenfolge von Angeboten/Vereinbarungen

UplinkFast

Neue Mechanismen zur Topologieänderung

Erkennung von Topologieänderungen

Propagierung von Topologieänderungen

Kompatibilität mit 802.1D

Schlussfolgerung

Zugehörige Informationen

Einleitung

In diesem Dokument werden die Verbesserungen beschrieben, die durch das RSTP gegenüber dem vorherigen 802.1D-Standard vorgenommen wurden.

Hintergrund

Der STP-Standard (802.1D Spanning Tree Protocol) wurde zu einem Zeitpunkt entwickelt, als die Wiederherstellung der Verbindung nach einem Ausfall innerhalb von etwa einer Minute als angemessene Leistung angesehen wurde. Mit der Einführung von Layer-3-Switching in LAN-Umgebungen steht die Bridge nun im Wettbewerb mit Routing-Lösungen, bei denen Protokolle wie Open Shortest Path First (OSPF) und Enhanced Interior Gateway Routing Protocol (EIGRP) in kürzerer Zeit einen alternativen Pfad bereitstellen können.

Cisco hat die ursprüngliche 802.1D-Spezifikation um Funktionen wie Uplink Fast, Backbone Fast und Port Fast erweitert, um die Konvergenzzeit eines überbrückten Netzwerks zu beschleunigen. Der Nachteil ist, dass diese Mechanismen proprietär sind und einer zusätzlichen Konfiguration bedürfen.

Rapid Spanning Tree Protocol (RSTP; IEEE 802.1w) kann als Weiterentwicklung des 802.1D-Standards und nicht als Revolution angesehen werden. Die Terminologie für 802.1D ist in erster Linie dieselbe. Die meisten Parameter wurden unverändert gelassen, sodass Benutzer, die mit 802.1D vertraut sind, das neue Protokoll schnell und komfortabel konfigurieren können. In den meisten Fällen schneidet RSTP besser ab als proprietäre Erweiterungen von Cisco, ohne dass eine zusätzliche Konfiguration erforderlich ist. 802.1w kann auch auf 802.1D zurückgesetzt werden, um die Interoperabilität mit älteren Bridges auf Port-Basis sicherzustellen. Damit werden die Vorteile der neuen Lösung zunichte gemacht.

Die neue Ausgabe des 802.1D-Standards IEEE 802.1D-2004 umfasst die Standards IEEE 802.1t-2001 und IEEE 802.1w.

Unterstützung von RSTP in Catalyst-Switches

Diese Tabelle zeigt die Unterstützung von RSTP in einigen Catalyst-Switch-Familien sowie die erforderliche Mindestsoftware für diese Unterstützung.

Catalyst-Plattform

MST mit RSTP

RPVST+ (auch als PVRST+ bekannt)

Catalyst 2900 XL/3500 XL

Nicht verfügbar.

Nicht verfügbar.

Catalyst 2940

12,1(20)EA2

12,1(20)EA2

Catalyst 2950/2955/3550

12,1(9)EA1

12.1(13)EA1

Catalyst 2970/3750

12.1(14)EA1

12.1(14)EA1

Catalyst 3560

12,1(19)EA1

12,1(19)EA1

Catalyst 3750 Metro

12.1(14)AX

12.1(14)AX

Catalyst 2948G-L3/4908G-L3

Nicht verfügbar.

Nicht verfügbar.

Catalyst 4000/4500 (Cisco IOS®)

12.1(12c)EW

12.1(19)EW

Catalyst 6000/6500 (Cisco IOS)

12.1(11b)EX, 12.1(13)E, 12.2(14)SX

12.1(13)E

Catalyst 8500

Nicht verfügbar.

Nicht verfügbar.

Neue Hafenstaaten und Hafenrollen

802.1D ist in den folgenden fünf Portstatus definiert:

- disabled

- listening

- learning

- blocking

- forwarding

Weitere Informationen zu den Hafenzuständen finden Sie in der Tabelle im Abschnitt Hafenstaaten dieses Dokuments.

Der Status des Ports ist unterschiedlich, unabhängig davon, ob der Datenverkehr blockiert oder weitergeleitet wird und welche Rolle er in der aktiven Topologie spielt (Root-Port, designierter Port usw.). Beispielsweise besteht aus betrieblicher Sicht kein Unterschied zwischen einem Port im Blockierstatus und einem Port im Listening-Status. Beide verwerfen Frames und lernen keine MAC-Adressen. Der eigentliche Unterschied liegt in der Rolle, die der Spanning Tree dem Port zuweist. Es kann davon ausgegangen werden, dass ein Überwachungsport entweder als Root oder als Root festgelegt ist und sich auf dem Weg in den Weiterleitungsstatus befindet. Im Weiterleitungsstatus kann leider nicht aus dem Port-Status abgeleitet werden, ob der Port Root oder designiert ist. Dies zeigt, dass diese zustandsbasierte Terminologie fehlerhaft ist. Das RSTP trennt die Rolle und den Status eines Ports, um dieses Problem zu beheben.

Hafenstaaten

Es gibt im RSTP nur noch drei Port-Status, die den drei möglichen Betriebszuständen entsprechen. Die Status "Deaktiviert", "Blockiert" und "Überwacht" in 802.1D werden in einen eindeutigen Status für das Verwerfen zusammengefasst.

STP (802.1D)-Portstatus

RSTP (802.1w)-Portstatus

Ist der Port in der aktiven Topologie enthalten?

Sind Port Learning MAC-Adressen?

Deaktiviert

Verwerfen

Nein

Nein

Blocking

Verwerfen

Nein

Nein

Listening

Verwerfen

Ja

Nein

Learning

Learning

Ja

Ja

Forwarding

Forwarding

Ja

Ja

Port-Rollen

Die Portrolle ist nun eine Variable, die einem bestimmten Port zugewiesen wird. Der Root-Port und die zugewiesenen Port-Rollen bleiben erhalten, während die blockierende Port-Rolle in die Backup- und die alternative Port-Rolle aufgeteilt wird. Der Spanning Tree Algorithm (STA) bestimmt die Rolle eines Ports auf der Grundlage von Bridge Protocol Data Units (BPDUs). Um die Dinge zu vereinfachen, ist es wichtig, sich an eine BPDU zu erinnern, dass es immer eine Methode gibt, um zwei davon zu vergleichen und zu entscheiden, ob eine nützlicher als die andere ist. Diese basiert auf dem Wert, der in der BPDU und gelegentlich auch auf dem Port gespeichert ist, an dem sie empfangen werden. In diesem Zusammenhang werden in den Informationen in diesem Abschnitt praktische Ansätze für Portrollen erläutert.

Root-Port-Rollen

- Der Port, der die beste BPDU auf einer Bridge empfängt, ist der Root-Port. Gemessen an den Pfadkosten ist dieser Port der Root-Bridge am nächsten. Der STA wählt eine einzelne Root-Bridge im gesamten überbrückten Netzwerk (pro VLAN). Die Root-Bridge sendet BPDUs, die nützlicher sind als die, die jede andere Bridge sendet. Die Root-Bridge ist die einzige Bridge im Netzwerk ohne Root-Port. Alle anderen Bridges empfangen BPDUs an mindestens einem Port.

Festgelegte Portrolle

- Ein Port wird festgelegt, wenn er die beste BPDU an das Segment senden kann, mit dem er verbunden ist. 802.1D-Bridges verknüpfen verschiedene Segmente, z. B. Ethernet-Segmente, zu einer Bridge-Domäne. Auf einem bestimmten Segment kann es nur einen Pfad zur Root-Bridge geben. Wenn es zwei Pfade gibt, gibt es eine Bridge-Schleife im Netzwerk. Alle Bridges, die mit einem bestimmten Segment verbunden sind, überwachen die BPDUs jedes einzelnen Segments und stimmen sich auf die Bridge zu, die das beste BPDU als designierte Bridge für das Segment sendet. Der entsprechende Port auf der Bridge ist der designierte Port für dieses Segment.

Alternative und Backup-Port-Rollen

- Diese beiden Portrollen entsprechen dem Blockierungsstatus von 802.1D. Ein blockierter Port ist nicht als designierter oder Root-Port definiert. Ein blockierter Port erhält eine nützlichere BPDU als die, die er an sein Segment sendet. Denken Sie daran, dass ein Port BPDUs empfangen muss, um blockiert zu bleiben. Zu diesem Zweck führt das RSTP diese beiden Rollen ein.

- Ein alternativer Port empfängt nützlichere BPDUs von einer anderen Bridge und wird bei einem Port blockiert. Dies wird in diesem Diagramm veranschaulicht:

- Ein Backup-Port empfängt mehr nützliche BPDUs von derselben Bridge, auf der er sich befindet, und wird als Port blockiert. Dies wird in diesem Diagramm veranschaulicht:

Diese Unterscheidung erfolgt bereits intern in 802.1D. Auf diese Weise funktioniert Cisco UplinkFast. Der Grund hierfür ist, dass ein alternativer Port einen alternativen Pfad zur Root-Bridge bereitstellt und daher den Root-Port bei einem Ausfall ersetzen kann. Ein Backup-Port bietet natürlich redundante Konnektivität zu demselben Segment und kann keine alternative Konnektivität zur Root-Bridge garantieren. Daher wird sie aus der Uplink-Gruppe ausgeschlossen.

Daher berechnet das RSTP die endgültige Topologie für den Spanning Tree, der dieselben Kriterien wie 802.1D verwendet. Die Art und Weise, wie die unterschiedlichen Bridge- und Port-Prioritäten verwendet werden, bleibt unverändert. Der Name "blocking" wird für den Status "discarding" in der Cisco Implementierung verwendet. CatOS 7.1 und höher zeigt immer noch die Zustände "Zuhören" und "Lernen" an. Dadurch werden mehr Informationen über einen Port bereitgestellt, als vom IEEE-Standard gefordert. Die neue Funktion sieht jedoch vor, dass zwischen der Rolle, die das Protokoll für einen Port bestimmt, und seinem aktuellen Status ein Unterschied besteht. So ist es nun beispielsweise möglich, einen Port gleichzeitig zu bestimmen und zu blockieren. Dies geschieht in der Regel für sehr kurze Zeiträume, bedeutet jedoch, dass sich dieser Port in einem Übergangszustand in Richtung des designierten Weiterleitungszustands befindet.

Neues BPDU-Format

RSTP hat nur wenige Änderungen am BPDU-Format vorgenommen. In 802.1D sind nur zwei Flags definiert, "Topology Change" (TC) und "TC Acknowledgment" (TCA). Das RSTP verwendet jedoch alle verbleibenden sechs Bits des Flagbyte, um Folgendes auszuführen:

- Codieren der Rolle und des Status des Ports, der den BPDU generiert

- Bearbeitung des Vorschlags-/Vereinbarungsmechanismus

Vollständige Ansicht der Diagramme zu Cisco BPDU, IEEE BPDU und BPDU

Ein Bild mit höherer Auflösung finden Sie in den Diagrammen zu Cisco BPDU, IEEE BPDU und BPDU.

Hinweis: Bit 0 (Topologieänderung) ist das Bit mit der geringsten Bedeutung.

Eine weitere wichtige Änderung besteht darin, dass die RSTP-BPDU jetzt vom Typ 2, Version 2, ist. Dies impliziert, dass bei Legacy-Bridges diese neue BPDU verworfen werden muss. Diese Eigenschaft macht es einer 802.1w-Bridge leicht, damit verbundene Legacy-Bridges zu erkennen.

Neue BPDU-Verarbeitung

BPDUs werden an jede Begrüßungszeit gesendet

BPDUs werden jedes Mal gesendet und nicht mehr einfach weitergeleitet. Bei 802.1D erzeugt eine Nicht-Root-Bridge BPDUs nur, wenn sie eine solche am Root-Port empfängt. Eine Bridge leitet BPDUs mehr weiter, als sie tatsächlich generiert. Bei 802.1w ist dies nicht der Fall. Eine Bridge sendet alle <Hello-time> Sekunden (standardmäßig 2) eine BPDU mit ihren aktuellen Informationen, selbst wenn sie keine von der Root-Bridge empfängt.

Schnelleres Altern von Informationen

Wenn Hellos an einem bestimmten Port nicht dreimal hintereinander empfangen werden, können die Protokollinformationen sofort veraltet werden (oder wenn max_age abläuft). Aufgrund der zuvor erwähnten Protokolländerung werden BPDUs jetzt als Keep-Alive-Mechanismus zwischen Bridges verwendet. Eine Bridge geht davon aus, dass sie die Verbindung zum direkten Nachbar-Root oder zur designierten Bridge verliert, wenn drei BPDUs hintereinander fehlen. Diese schnelle Alterung der Informationen ermöglicht eine schnelle Fehlererkennung. Wenn eine Bridge keine BPDUs von einem Nachbarn empfängt, ist sicher, dass die Verbindung zu diesem Nachbarn unterbrochen wird. Dies steht im Gegensatz zu 802.1D, bei dem das Problem überall auf dem Pfad zum Root auftreten kann.

Hinweis: Bei physischen Verbindungsausfällen werden Ausfälle noch viel schneller erkannt.

Akzeptiert minderwertige BPDUs

Dieses Konzept bildet den Kern der BackboneFast-Engine. Der IEEE 802.1w-Ausschuss hat einen ähnlichen Mechanismus in das RSTP integriert. Wenn eine Bridge von ihrer designierten oder Root-Bridge unterlegene Informationen empfängt, akzeptiert sie diese sofort und ersetzt die zuvor gespeicherte.

Da Bridge C immer noch weiß, dass die Root aktiv und fehlerfrei ist, sendet sie sofort eine BPDU an Bridge B, die Informationen über die Root-Bridge enthält. Infolgedessen sendet Bridge B keine eigenen BPDUs und akzeptiert den Port, der zu Bridge C führt, als neuen Root-Port.

Schneller Übergang in den Weiterleitungsstatus

Eine schnelle Umrüstung ist die wichtigste Funktion von 802.1w. Das Legacy-STA wartete passiv auf die Konvergenz des Netzwerks, bevor es einen Port in den Weiterleitungsstatus umwandelte. Um eine schnellere Konvergenz zu erreichen, wurden die konservativen Standardparameter (forward delay und max_age timers) geändert, was oft die Stabilität des Netzwerks gefährdete. Das neue schnelle STP kann aktiv bestätigen, dass ein Port sicher in den Weiterleitungsstatus übergehen kann, ohne dass eine Timer-Konfiguration erforderlich ist. Es gibt jetzt einen echten Feedback-Mechanismus zwischen RSTP-konformen Bridges. Um eine schnelle Konvergenz an einem Port zu erreichen, stützt sich das Protokoll auf zwei neue Variablen: Edge-Ports und Link-Typ.

Edge-Ports

Das Edge-Port-Konzept ist Cisco Spanning Tree-Benutzern bereits bekannt, da es im Wesentlichen der PortFast-Funktion entspricht. Alle Ports, die direkt mit Endgeräten verbunden sind, können keine Bridge-Schleifen im Netzwerk erstellen. Aus diesem Grund wechselt der Edge-Port direkt in den Weiterleitungsstatus und überspringt die Phasen des Abhörens und Lernens. Weder Edge-Ports noch PortFast-fähige Ports generieren Topologieänderungen, wenn die Verbindung umgeschaltet wird. Ein Edge-Port, der eine BPDU empfängt, verliert sofort den Edge-Port-Status und wird zu einem normalen Spanning-Tree-Port. Zu diesem Zeitpunkt gibt es einen benutzerdefinierten Wert und einen Betriebswert für den Edge-Port-Status. Die Cisco Implementierung legt fest, dass das PortFast-Schlüsselwort für die Edge-Port-Konfiguration verwendet werden muss. Dadurch wird der Übergang zum RSTP vereinfacht.

Verbindungstyp

RSTP kann nur einen schnellen Übergang in den Weiterleitungsstatus an Edge-Ports und an Point-to-Point-Verbindungen erreichen. Der Verbindungstyp wird automatisch vom Duplexmodus eines Ports abgeleitet. Bei einem Vollduplex-Port wird angenommen, dass er Point-to-Point ist, während ein Halbduplex-Port standardmäßig als gemeinsamer Port gilt. Dieser Wert für den automatischen Verbindungstyp kann durch eine explizite Konfiguration überschrieben werden. In Switched-Netzwerken arbeiten die meisten Verbindungen heute im Vollduplex-Modus und werden vom RSTP als Point-to-Point-Verbindungen behandelt. Dadurch sind sie für einen schnellen Übergang in den Weiterleitungsstatus in Frage.

Konvergenz mit 802.1D

Dieses Diagramm zeigt, wie 802.1D mit einer neuen Verbindung umgeht, die zu einem überbrückten Netzwerk hinzugefügt wird:

In diesem Szenario wird eine Verbindung zwischen der Root-Bridge und Bridge A hinzugefügt. Angenommen, es besteht bereits eine indirekte Verbindung zwischen Brücke A und der Root-Brücke (durch C - D im Diagramm). Der STA blockiert einen Port und deaktiviert die Bridge-Schleife. Zunächst werden beide Ports an der Verbindung zwischen dem Root und Bridge A in den Listening-Status versetzt. Brücke A kann nun die Wurzel direkt hören. Die BPDUs werden sofort an die dafür vorgesehenen Ports und die Blätter des Trees verteilt. Sobald die Brücken B und C diese neue überlegene Information von der Brücke A erhalten, geben sie diese sofort an die Blätter weiter. Innerhalb weniger Sekunden empfängt Bridge D eine BPDU vom Root-Switch und blockiert Port P1 sofort.

Spanning Tree ermöglicht eine effiziente Berechnung der neuen Netzwerktopologie. Das einzige Problem besteht nun darin, dass die doppelte Weiterleitungsverzögerung ablaufen muss, bevor die Verbindung zwischen dem Root und Bridge A irgendwann in den Weiterleitungsstatus gelangt. Dies bedeutet eine Unterbrechung des Datenverkehrs von 30 Sekunden (der gesamte A-, B- und C-Teil des Netzwerks ist isoliert), da dem 8021D-Algorithmus ein Feedback-Mechanismus fehlt, der deutlich signalisiert, dass das Netzwerk innerhalb von Sekunden konvergiert.

Konvergenz mit 802.1w

Jetzt können Sie sehen, wie RSTP mit einer ähnlichen Situation umgeht. Beachten Sie, dass die endgültige Topologie genau mit der von 802.1D berechneten Topologie übereinstimmt (d. h. ein blockierter Port am gleichen Ort wie zuvor). Nur die Schritte zum Erreichen dieser Topologie haben sich geändert.

Beide Ports an der Verbindung zwischen Switch A und dem Root werden blockiert, sobald sie verfügbar sind. Bisher verhält sich alles wie in einer reinen 802.1D-Umgebung. Zu diesem Zeitpunkt findet jedoch eine Verhandlung zwischen Switch A und dem Root statt. Sobald Switch A die BPDU des Roots empfängt, blockiert er die designierten Nicht-Edge-Ports. Dieser Vorgang wird als Synchronisierung bezeichnet. Anschließend autorisiert Bridge A die Root-Bridge explizit, ihren Port in den Weiterleitungsstatus zu versetzen. Dieses Diagramm veranschaulicht das Ergebnis dieses Prozesses im Netzwerk. Die Verbindung zwischen Switch A und der Root-Bridge wird blockiert, und beide Bridges tauschen BPDUs aus.

Sobald Switch A seine designierten Nicht-Edge-Ports blockiert, wird die Verbindung zwischen Switch A und dem Root in den Weiterleitungsstatus versetzt, und Sie erreichen die Situation:

Es kann immer noch keine Schleife geben. Anstatt vor Switch A zu blockieren, blockiert das Netzwerk nun nach Switch A. Die potenzielle Bridge-Schleife wird jedoch an einem anderen Ort unterbrochen. Dieser Schnitt wird zusammen mit den neuen BPDUs, die vom Root generiert werden, über Switch A durch den Tree geleitet. Zu diesem Zeitpunkt handeln die neu blockierten Ports an Switch A auch einen schnellen Übergang in den Weiterleitungsstatus mit ihren Nachbarports an Switch B und Switch C aus, die beide einen Synchronisierungsvorgang initiieren. Abgesehen vom Root-Port zu A verfügt Switch B nur über designierte Edge-Ports. Daher verfügt er über keinen zu sperrenden Port, um Switch A zu autorisieren, in den Weiterleitungsstatus zu wechseln. In ähnlicher Weise muss Switch C nur seinen designierten Port zu D blockieren. Der in diesem Diagramm gezeigte Zustand ist nun erreicht:

Denken Sie daran, dass die endgültige Topologie genau mit dem Beispiel 802.1D übereinstimmt, was bedeutet, dass Port P1 auf D am Ende blockiert. Dies bedeutet, dass die endgültige Netzwerktopologie gerade in der Zeit erreicht ist, die erforderlich ist, damit die neuen BPDUs den Tree hinunter wandern können. Bei dieser schnellen Konvergenz ist kein Timer involviert. Der einzige neue Mechanismus, der vom RSTP eingeführt wurde, ist die Bestätigung, dass ein Switch seinen neuen Root-Port einschalten kann, um einen sofortigen Übergang in den Weiterleitungsstatus zu autorisieren. Außerdem werden die lang andauernden Abhör- und Lernphasen mit der doppelten Vorwärtsverzögerung umgangen. Der Administrator muss sich nur diese merken, um von der schnellen Konvergenz zu profitieren:

- Diese Aushandlung zwischen Bridges ist nur möglich, wenn Bridges über Point-to-Point-Verbindungen verbunden sind (d. h. Vollduplex-Verbindungen, sofern keine explizite Port-Konfiguration vorliegt).

- Edge-Ports spielen eine noch wichtigere Rolle, da PortFast jetzt auf Ports in 802.1D aktiviert ist. Wenn der Netzwerkadministrator beispielsweise die Edge-Ports an Switch B nicht richtig konfiguriert, wird deren Konnektivität durch die Verbindung zwischen Switch A und dem Root beeinträchtigt, der gestartet wird.

Reihenfolge von Angeboten/Vereinbarungen

Wenn ein Port vom STA als designierter Port ausgewählt wird, wartet 802.1D noch immer zweimal Sekunden (standardmäßig 2 x 15), bevor er in den Weiterleitungsstatus überführt wird. Im RSTP entspricht diese Bedingung einem Port mit einer zugewiesenen Rolle, jedoch einem Blockierungsstatus. Diese Diagramme zeigen, wie schnell der Übergang Schritt für Schritt erfolgt. Angenommen, es wird eine neue Verbindung zwischen dem Root und Switch A erstellt. Beide Ports dieser Verbindung werden in einen designierten Blockierungsstatus versetzt, bis sie eine BPDU von ihrem Gegenstück erhalten.

Wenn sich ein designierter Port in einem verwerfenden oder lernenden Zustand befindet (und nur in diesem Fall), legt er das Vorschlagsbit für die BPDUs fest, die er sendet. Dies geschieht für den Port p0 der Root-Bridge, wie in Schritt 1 des vorhergehenden Diagramms gezeigt. Da Switch A überlegene Informationen empfängt, weiß er sofort, dass p1 der neue Root-Port ist. Switch A startet dann eine Synchronisierung, um sicherzustellen, dass alle Ports mit den neuen Informationen synchronisiert sind. Ein Port ist synchronisiert, wenn eines der folgenden Kriterien erfüllt ist:

- Der Port befindet sich im blockierenden Zustand, d. h. er wird in einer stabilen Topologie verworfen.

- Der Port ist ein Edge-Port.

Zur Veranschaulichung der Auswirkung des Synchronisationsmechanismus auf verschiedene Porttypen ist davon auszugehen, dass ein alternativer Port p2, ein designierter Weiterleitungs-Port p3 und ein Edge-Port p4 auf Switch A vorhanden sind. Beachten Sie, dass p2 und p4 bereits eines der Kriterien erfüllen. Um synchronisiert zu sein (siehe Schritt 2 des vorherigen Diagramms), muss Switch A nur Port p3 blockieren und ihm den Status "Verwerfen" zuweisen. Nachdem alle Ports synchronisiert sind, kann Switch A die Blockierung seines neu ausgewählten Root-Ports p1 aufheben und eine Vereinbarungsnachricht senden, um an den Root zu antworten. (siehe Schritt 3). Diese Nachricht ist eine Kopie des Angebots-BPDU, wobei das Vereinbarungs-Bit anstelle des Angebots-Bits festgelegt ist. Dadurch wird sichergestellt, dass der Hafen p0 genau weiß, welchem Vorschlag die Vereinbarung entspricht, die er erhält.

Sobald p0 diese Vereinbarung empfängt, kann sie sofort in den Weiterleitungsstatus übergehen. Dies ist Schritt 4 der vorherigen Abbildung. Beachten Sie, dass Port p3 nach der Synchronisierung in einem festgelegten Verwerfungszustand belassen wird. In Schritt 4 befindet sich dieser Port in der exakt gleichen Situation wie Port p0 in Schritt 1. Dann beginnt es, seinem Nachbarn einen Vorschlag zu machen, und versucht, schnell in den Weiterleitungsstatus zu wechseln.

- Der Mechanismus der Vorschlagsvereinbarung ist sehr schnell, da er sich nicht auf Timer stützt. Diese Welle des Handshakes breitet sich schnell zum Netzwerk-Edge aus und stellt die Verbindungen nach einer Änderung der Topologie schnell wieder her.

- Erhält ein designierter verwerfender Port nach dem Senden eines Vorschlags keine Vereinbarung, wechselt er langsam in den Weiterleitungsstatus und wechselt zurück zur traditionellen 802.1D-Sequenz des Abhörens. Dies kann auftreten, wenn die Remote-Bridge RSTP-BPDUs nicht versteht oder wenn der Port der Remote-Bridge blockiert.

- Cisco hat eine Erweiterung des Synchronisierungsmechanismus eingeführt, die es einer Bridge ermöglicht, bei der Synchronisierung nur ihren früheren Root-Port in den Status "Verwerfen" zu versetzen. Details zur Funktionsweise dieses Mechanismus werden in diesem Dokument nicht behandelt. Man kann jedoch davon ausgehen, dass sie in den meisten gängigen Rekonvergenzfällen aufgerufen wird. Das im Abschnitt Konvergenz mit 802.1w beschriebene Szenario wird äußerst effizient, da nur die Ports auf dem Pfad zum endgültig blockierten Port vorübergehend verwechselt werden.

UplinkFast

Eine weitere Form des sofortigen Übergangs in den Weiterleitungsstatus, der im RSTP enthalten ist, ähnelt der proprietären Spanning Tree-Erweiterung von Cisco UplinkFast. Wenn eine Bridge ihren Root-Port verliert, kann sie ihren besten alternativen Port direkt in den Weiterleitungsmodus versetzen (das Aussehen eines neuen Root-Ports wird auch vom RSTP übernommen). Die Auswahl eines alternativen Ports als neuer Root-Port löst eine Topologieänderung aus. Der Mechanismus zur Änderung der 802.1w-Topologie löscht die entsprechenden Einträge in den Content Addressable Memory (CAM)-Tabellen der Upstream-Bridge. Dadurch ist der Dummy-Multicast-Generierungsprozess von UplinkFast nicht mehr erforderlich.

UplinkFast muss nicht weiter konfiguriert werden, da der Mechanismus nativ enthalten und automatisch im RSTP aktiviert ist.

Neue Mechanismen zur Topologieänderung

Wenn eine 802.1D-Bridge eine Topologieänderung erkennt, verwendet sie einen zuverlässigen Mechanismus, um zunächst die Root-Bridge zu benachrichtigen. Dies wird in diesem Diagramm veranschaulicht:

Sobald die Root-Bridge eine Änderung der Netzwerktopologie erkennt, setzt sie das TC-Flag auf den von ihr gesendeten BPDUs, die dann an alle Bridges im Netzwerk weitergeleitet werden. Wenn eine Bridge eine BPDU empfängt, deren TC-Flag-Bit gesetzt ist, reduziert sie ihre Alterungszeit in der Bridge-Tabelle auf Vorwärtsverzögerungssekunden. Dadurch wird eine relativ schnelle Ausspülung veralteter Informationen gewährleistet. Dieser Mechanismus zur Änderung der Topologie wurde im RSTP umfassend umgestaltet. Sowohl die Erkennung einer Topologieänderung als auch deren Ausbreitung im Netzwerk entwickeln sich weiter.

Erkennung von Topologieänderungen

Im RSTP verursachen nur Nicht-Edge-Ports, die in den Weiterleitungsstatus übergehen, eine Topologieänderung. Dies bedeutet, dass ein Verbindungsverlust im Gegensatz zu 802.1D nicht mehr als Topologieänderung angesehen wird (d. h., ein Port, der auf die Blockierung umschaltet, generiert kein TC mehr). Wenn eine RSTP-Bridge eine Topologieänderung erkennt, geschieht Folgendes:

- Er startet den TC While-Timer mit einem Wert, der der doppelten Hello-Zeit für alle designierten Nicht-Edge-Ports und ggf. den Root-Port entspricht.

- Er löscht die MAC-Adressen, die allen diesen Ports zugeordnet sind.

Hinweis: Solange der TC While-Timer auf einem Port ausgeführt wird, haben die von diesem Port gesendeten BPDUs das TC-Bit. BPDUs werden auch am Root-Port gesendet, während der Timer aktiv ist.

Propagierung von Topologieänderungen

Wenn eine Bridge eine BPDU empfängt, deren TC-Bit von einem Nachbarn festgelegt wurde, geschieht Folgendes:

- Er löscht die MAC-Adressen, die auf allen Ports erfasst wurden, mit Ausnahme des Ports, der die Topologieänderung erhält.

- Er startet den TC While-Timer und sendet BPDUs mit dem TC-Bit, das auf allen designierten Ports und dem Root-Port festgelegt ist (RSTP verwendet nicht mehr die spezifische TCN-BPDU, es sei denn, eine Legacy-Bridge benötigt eine Benachrichtigung).

Auf diese Weise durchflutet das TCN sehr schnell das gesamte Netzwerk. Die TC-Propagierung ist nun ein einstufiger Prozess. Tatsächlich werden diese Informationen vom Initiator der Topologieänderung über das gesamte Netzwerk hinweg übertragen, im Gegensatz zu 802.1D, bei dem nur die Root-Bridge dies tat. Dieser Mechanismus ist viel schneller als das 802.1D-Äquivalent. Es ist nicht erforderlich, auf die Benachrichtigung der Root-Bridge zu warten und dann den Topologieänderungsstatus für das gesamte Netzwerk <Max. Alter plus Weiterleitungsverzögerung> Sekunden beizubehalten.

In wenigen Sekunden oder einem kleinen Vielfachen von Hello-Times werden die meisten Einträge in den CAM-Tabellen des gesamten Netzwerks (VLAN) geleert. Dieser Ansatz führt zu potenziell zeitweiligeren Überschwemmungen, löscht jedoch potenzielle veraltete Informationen, die eine schnelle Wiederherstellung der Netzwerkanbindung verhindern.

Kompatibilität mit 802.1D

Das RSTP ist mit älteren STP-Protokollen kompatibel. Die Vorteile von 802.1w durch die schnelle Konvergenz gehen jedoch verloren, wenn es mit älteren Bridges interagiert.

Jeder Port verfügt über eine Variable, die das Protokoll für das entsprechende Segment definiert. Ein Migrations-Verzögerungszeitgeber von drei Sekunden wird ebenfalls gestartet, wenn der Port aktiviert wird. Wenn dieser Timer ausgeführt wird, ist der aktuelle, mit dem Port verknüpfte STP- oder RSTP-Modus gesperrt. Sobald die Migrationsverzögerung abläuft, passt sich der Port dem Modus an, der der nächsten empfangenen BPDU entspricht. Wenn der Port seinen Betriebsmodus infolge eines empfangenen BPDU ändert, startet die Migrationsverzögerung neu. Dadurch wird die mögliche Modenwechselfrequenz begrenzt.

Angenommen, die Brücken A und B in der vorherigen Abbildung führen beide RSTP aus, wobei Switch A für das Segment festgelegt ist. Eine ältere STP Bridge C wird für diese Verbindung eingeführt. Da 802.1D-Bridges RSTP-BPDUs ignorieren und verwerfen, glaubt C, dass es keine anderen Bridges im Segment gibt, und beginnt, die untergeordneten 802.1D-BPDUs zu senden. Switch A empfängt diese BPDUs und ändert seinen Modus nach der zweifachen Hello-Time-Sekunde nur an diesem Port auf 802.1D. Infolgedessen versteht C jetzt die BPDUs von Switch A und akzeptiert A als designierte Bridge für dieses Segment.

Beachten Sie in diesem speziellen Fall, dass bei Entfernen von Bridge C Bridge A auf diesem Port im STP-Modus ausgeführt wird, obwohl sie im RSTP-Modus mit ihrem eindeutigen Nachbarn B effizienter arbeiten kann. Dies liegt daran, dass A nicht weiß, dass Bridge C aus dem Segment entfernt wird. In diesem speziellen (seltenen) Fall ist ein Benutzereingriff erforderlich, um die Protokollerkennung des Ports manuell neu zu starten.

Wenn sich ein Port im 802.1D-Kompatibilitätsmodus befindet, kann er auch TCN-BPDUs (Topology Change Notification) und BPDUs mit TC- oder TCA-Bit-Set verarbeiten.

Schlussfolgerung

RSTP (IEEE 802.1w) beinhaltet die meisten proprietären Erweiterungen von 802.1D Spanning Tree, wie BackboneFast, UplinkFast und PortFast. Das RSTP kann in einem ordnungsgemäß konfigurierten Netzwerk eine wesentlich schnellere Konvergenz erreichen, die in manchen Fällen mehrere Hundert Millisekunden beträgt. Klassische 802.1D-Timer, wie Forward Delay und max_age, werden nur als Backup verwendet und sind nicht erforderlich, wenn Point-to-Point-Verbindungen und Edge-Ports vom Administrator richtig identifiziert und festgelegt werden. Außerdem sind die Timer nicht erforderlich, wenn keine Interaktion mit älteren Bridges besteht.

Zugehörige Informationen

- Konfigurieren von MST (802.1s)/RSTP (802.1w) auf Catalyst-Switches mit CatOS

- Die Cisco Uplink Fast-Funktion verstehen und konfigurieren

- Tools und Ressourcen

- Technischer Support und Dokumentation für Cisco Systeme