Grundlegendes zum Rapid Spanning Tree Protocol (802.1w)

Einleitung

Dieses Dokument enthält Informationen zu den Verbesserungen, die RSTP zum vorherigen 802.1D-Standard hinzugefügt hat.

Hintergrund

Der STP-Standard 802.1D (Spanning Tree Protocol) wurde zu einer Zeit entwickelt, als die Wiederherstellung der Netzwerkverbindung nach einem Ausfall innerhalb von etwa einer Minute als angemessene Leistung galt. Mit dem Aufkommen des Layer-3-Switchings in LAN-Umgebungen konkurriert die Bridge jetzt mit gerouteten Lösungen, bei denen Protokolle wie Open Shortest Path First (OSPF) und Enhanced Interior Gateway Routing Protocol (EIGRP) in der Lage sind, einen alternativen Pfad in kürzerer Zeit bereitzustellen.

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 verkürzen. Der Nachteil ist, dass diese Mechanismen proprietär sind und eine zusätzliche Konfiguration erfordern.

Rapid Spanning Tree Protocol (RSTP, IEEE 802.1w) kann eher als eine Weiterentwicklung des 802.1D-Standards denn als Revolution betrachtet werden. Die 802.1D-Terminologie ist im Wesentlichen gleich. Die meisten Parameter wurden unverändert gelassen, sodass Benutzer, die mit 802.1D vertraut sind, das neue Protokoll schnell und bequem konfigurieren können. In den meisten Fällen schneidet RSTP besser ab als proprietäre Erweiterungen von Cisco ohne zusätzliche Konfiguration. 802.1w kann für die Interoperabilität mit älteren Bridges auch Port-weise auf 802.1D zurückgesetzt werden. Dadurch entfallen die damit verbundenen Vorteile.

Die neue Ausgabe des 802.1D-Standards, IEEE 802.1D-2004, enthält die Standards IEEE 802.1t-2001 und IEEE 802.1w.

Unterstützung von RSTP auf Catalyst-Switches

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

Catalyst-Plattform	MST mit RSTP	RPVST+ (auch bekannt als PVRST+)
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 Port-Status und -Rollen

802.1D ist in den folgenden fünf Port-Status definiert:

• disabled

• listening

• learning

• blocking

• forwarding

Weitere Informationen zum Port-Status finden Sie in der Tabelle im Abschnitt Port-Status in diesem Dokument.

Der Status des Ports ist unterschiedlich, je nachdem, ob er Datenverkehr blockiert oder weiterleitet und welche Rolle er in der aktiven Topologie spielt (Root-Port, designierter Port usw.) Aus betrieblicher Sicht gibt es beispielsweise keinen Unterschied zwischen einem Port im Blockieren- und im Mithören-Status. Beide verwerfen Frames und erlernen keine MAC-Adressen. Der tatsächliche Unterschied liegt in der Rolle, die Spanning Tree dem Port zuweist. Es kann davon ausgegangen werden, dass ein mithörender Port entweder designiert oder Root und auf dem Weg in den Weiterleitungsstatus ist. Leider gibt es nach Beginn des Weiterleitungsstatus keine Möglichkeit, aus dem Port-Status abzuleiten, ob der Port Root oder designiert ist. Dies zeigt ebenfalls, dass diese statusbasierte Terminologie nicht hilfreich ist. RSTP entkoppelt die Rolle und den Status eines Ports, um dieses Problem zu beheben.

Port-Status

Es gibt nur noch drei Port-Status in RSTP, die den drei möglichen Betriebsstatus entsprechen. Die 802.1D-Status „disabled“ (deaktiviert), „blocking“ (blockieren) und „listening“ (mithören) werden zu einem eindeutigen 802.1w-Verwerfungsstatus zusammengeführt.

STP-Port-Status (802.1D)	RSTP-Port-Status (802.1w)	Ist der Port in der aktiven Topologie enthalten?	Lernt der Port 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 Port-Rolle ist jetzt eine Variable, die einem bestimmten Port zugewiesen wird. Die Rollen des Root-Ports und des designierten Ports bleiben bestehen, während die Rolle des blockierenden Ports in die Rollen Backup und alternative Ports aufgeteilt wird. Der Spanning Tree-Algorithmus (STA) bestimmt die Rolle eines Ports basierend auf Bridge Protocol Data Units (BPDUs). Der Einfachheit halber sollten Sie bei BPDUs beachten, dass es immer eine Methode gibt, zwei von ihnen zu vergleichen und zu entscheiden, ob eine nützlicher ist als die andere. Dies basiert auf dem in der BPDU gespeicherten Wert und gelegentlich auf dem Port, an dem sie empfangen werden. Vor diesem Hintergrund werden in diesem Abschnitt praktische Ansätze für Port-Rollen erläutert.

Root-Port-Rollen

• Der Port, der die besten BPDU auf einer Bridge empfängt, ist der Root-Port. Dies ist der Port, der in Bezug auf die Pfadkosten der Root-Bridge am nächsten ist. Der STA wählt eine einzelne Root-Bridge im gesamten überbrückten Netzwerk (pro VLAN) aus. 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, die keinen Root-Port hat. Alle anderen Bridges empfangen BPDUs auf mindestens einem Port.

  

Designierte Port-Rolle

• Ein Port ist designiert, wenn er die beste BPDU in dem Segment senden kann, mit dem er verbunden ist. 802.1D-Bridges verbinden verschiedene Segmente, z. B. Ethernet-Segmente, um eine Bridged-Domäne zu erstellen. In einem bestimmten Segment kann es nur einen Pfad zur Root-Bridge geben. Bei zwei Pfaden liegt eine Bridge-Schleife im Netzwerk vor. Alle Bridges, die mit einem bestimmten Segment verbunden sind, hören die BPDUs von allen mit und einigen sich auf die Bridge, welche die 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 Port-Rollen entsprechen dem Blockierungsstatus von 802.1D. Ein blockierter Port ist definitionsgemäß weder ein designierter noch ein Root-Port. Ein blockierter Port empfängt eine nützlichere BPDU als die, die er in seinem Segment sendet. Denken Sie daran, dass ein Port BPDUs empfangen muss, um blockiert zu bleiben. RSTP führt zu diesem Zweck diese beiden Rollen ein.

• Ein alternativer Port empfängt nützlichere BPDUs von einer anderen Bridge und ist ein blockierter Port. Dies wird im folgenden Diagramm dargestellt:

  

• Ein Backup-Port empfängt mehr nützliche BPDUs von der gleichen Bridge, auf der er sich befindet, und ist ein blockierter Port. Dies wird im folgenden Diagramm dargestellt:

  

Diese Unterscheidung wird bereits intern in 802.1D vorgenommen. So funktioniert im Grunde Cisco UplinkFast. Das Prinzip ist, dass ein alternativer Port einen alternativen Pfad zur Root-Bridge bereitstellt und daher den Root-Port bei einem Ausfall ersetzen kann. Natürlich bietet ein Backup-Port eine redundante Verbindung zu demselben Segment und kann keine alternative Verbindung zur Root-Bridge garantieren. Daher wird es aus der Uplink-Gruppe ausgeschlossen.

Infolgedessen berechnet RSTP die endgültige Topologie für Spanning Tree nach denselben Kriterien wie 802.1D. Es gibt keine Änderung bei der Verwendung der verschiedenen Bridge- und Port-Prioritäten. Die Namensblockierung wird für den Verwerfungsstatus in der Cisco Implementierung verwendet. CatOS-Versionen 7.1 und höher zeigen weiterhin den Mithör- und den Lernstatus an. Dadurch erhalten Sie mehr Informationen über einen Port, als der IEEE-Standard erfordert. Die neue Funktion besteht jedoch darin, dass es jetzt einen Unterschied zwischen der Rolle, die das Protokoll für einen Port festlegt, und dessen aktuellen Status gibt. Beispielsweise kann ein Port jetzt gleichzeitig designiert und blockierend sein. Dies geschieht in der Regel für sehr kurze Zeiträume, bedeutet aber, dass sich dieser Port in einem Übergangszustand in Richtung des designierten Weiterleitungsstatus befindet.

Neues BPDU-Format

Durch RSTP wurden nur wenige Änderungen am BPDU-Format vorgenommen. In 802.1D sind nur zwei Flags definiert: Topology Change (TC) und TC Acknowledgment (TCA). RSTP verwendet jedoch alle sechs Bits des Flag-Bytes, die verbleiben, um:

• die Rolle und den Status des Ports zu verschlüsseln, von dem die BPDU ausgeht

• den Angebots-/Vereinbarungsmechanismus zu verarbeiten

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

Ein Bild mit höherer Auflösung finden Sie unter Cisco BPDU-, IEEE BPDU- und BPDU-Diagramme.

Hinweis: Bit 0 (Topologieänderung) ist das unwichtigste Bit.

Eine weitere wichtige Änderung ist, dass die RSTP-BPDU jetzt Typ 2, Version 2 ist. Dies impliziert, dass veraltete Bridges diese neue BPDU verwerfen müssen. Diese Eigenschaft erleichtert es einer 802.1w-Bridge, mit ihr verbundene Legacy-Bridges zu erkennen.

Neue BPDU-Bearbeitung

BPDUs werden bei jedem Hello gesendet

BPDUs werden bei jedem Hello gesendet und nicht mehr einfach weitergeleitet. Bei 802.1D generiert eine Nicht-Root-Bridge nur BPDUs, wenn sie am Root-Port empfängt. Eine Bridge leitet mehr BPDUs weiter, als sie tatsächlich generiert. Dies ist bei 802.1w 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 erhält.

Schnellere Alterung der Informationen

Wenn auf einem bestimmten Port Hellos nicht dreimal hintereinander empfangen werden, können Protokollinformationen sofort veralten (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 denkt, dass sie die Verbindung zu ihrem direkten Nachbar-Root oder der designierten Bridge verliert, wenn sie drei BPDUs hintereinander verpasst. Diese schnelle Veraltung der Informationen ermöglicht eine schnelle Fehlererkennung. Wenn eine Bridge keine BPDUs von einem Nachbarn empfängt, ist die Verbindung zu diesem Nachbarn sicher verlorengegangen. Dies steht im Gegensatz zu 802.1D, bei dem das Problem überall auf dem Pfad zum Root auftreten kann.

Hinweis: Ausfälle werden bei Ausfällen physischer Links noch viel schneller erkannt.

Akzeptiert minderwertige BPDUs

Dieses Konzept ist der Kern der BackboneFast-Engine. Der IEEE 802.1w-Ausschuss hat einen ähnlichen Mechanismus in RSTP integriert. Wenn eine Bridge minderwertige Informationen von ihrer designierten oder Root-Bridge erhält, akzeptiert sie diese sofort und ersetzt die zuvor gespeicherten Informationen.

Da Bridge C weiterhin weiß, dass die Root aktiv ist, sendet sie sofort eine BPDU an Bridge B, die Informationen zur 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 Status „Weiterleitung“

Der schnelle Übergang ist die wichtigste Funktion, die mit 802.1w eingeführt wurde. Der veraltete STA hat passiv auf die Konvergenz des Netzwerks gewartet, bevor er einen Port in den Weiterleitungsstatus versetzt hat. Das Erreichen einer schnelleren Konvergenz war abhängig von Änderungen an den konservativen Standardparametern (Weiterleitungsverzögerung und max_age-Timer), was häufig die Stabilität des Netzwerks gefährdete. Das neue Rapid-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, der zwischen RSTP-konformen Bridges stattfindet. Um eine schnelle Konvergenz auf 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-Benutzer bereits bekannt, da es im Wesentlichen der PortFast-Funktion entspricht. Alle Ports, die direkt mit Endstationen verbunden sind, können keine Bridge-Schleifen im Netzwerk bilden. Daher wechselt der Edge-Port direkt in den Weiterleitungsstatus und überspringt die Überwachungs- und Lernphasen. Weder Edge-Ports noch PortFast-fähige Ports generieren beim Umschalten des Links Topologieänderungen. Ein Edge-Port, der eine BPDU empfängt, verliert sofort den Edge-Port-Status und wird zu einem normalen Spanning Tree-Port. An diesem Punkt gibt es einen durch die Benutzer konfigurierten Wert und einen Betriebswert für den Edge-Port-Status. In der Cisco Implementierung ist vorgesehen, dass das Schlüsselwort PortFast für die Edge-Port-Konfiguration verwendet wird. Dies erleichtert den Übergang zu RSTP.

Leitungstyp

RSTP kann nur auf Edge-Ports und Punkt-zu-Punkt-Links einen schnellen Übergang in den Weiterleitungsstatus erreichen. Der Link-Typ wird automatisch vom Duplex-Modus eines Ports abgeleitet. Ein Port, der im Vollduplex-Modus arbeitet, wird als Point-to-Point-Port betrachtet, während ein Halbduplex-Port standardmäßig als gemeinsamer Port betrachtet wird. Dieser Wert für den automatischen Link-Typ kann durch explizite Konfiguration überschrieben werden. In Switch-Netzwerken werden heute die meisten Links im Vollduplex-Modus betrieben und von RSTP wie Punkt-zu-Punkt-Links behandelt. Dies macht sie zu Kandidaten für einen schnellen Übergang in den Weiterleitungsstatus.

Konvergenz mit 802.1D

Dieses Diagramm zeigt, wie 802.1D einen neuen Link verarbeitet, der einem überbrückten Netzwerk hinzugefügt wird:

In diesem Szenario wird ein Link zwischen der Root-Bridge und Bridge A hinzugefügt. Angenommen, es besteht bereits eine indirekte Verbindung zwischen Bridge A und der Root-Bridge (C – D im Diagramm). Der STA blockiert einen Port und deaktiviert die Bridge-Schleife. Zunächst werden beide Ports am Link zwischen Root und Bridge A bei ihrer Aktivierung in den Überwachungsstatus versetzt. Bridge A kann den Root jetzt direkt hören. Sie propagiert ihre BPDUs sofort auf den designierten Ports in Richtung der Spanning Tree-Verästelungen. Sobald die Bridges B und C diese neuen übergeordneten Informationen von Bridge A erhalten, werden die Informationen sofort an die Verästelungen weitergeleitet. Nach einigen Sekunden empfängt Bridge D eine BPDU von der Root-Instanz und blockiert sofort Port P1.

Spanning Tree ist sehr effizient in der Berechnung der neuen Topologie des Netzwerks. Das einzige Problem ist jetzt, dass die doppelte Weiterleitungsverzögerung vergehen muss, bevor der Link zwischen Root und Bridge A schließlich im Weiterleitungsstatus endet. Das bedeutet, dass der Datenverkehr 30 Sekunden lang unterbrochen wurde (der gesamte A-, B- und C-Teil des Netzwerks wird isoliert), da dem 8021.D-Algorithmus ein Feedback-Mechanismus fehlt, der eindeutig angibt, dass das Netzwerk in Sekundenschnelle konvergiert.

Konvergenz mit 802.1w

Jetzt können Sie sehen, wie RSTP mit einer ähnlichen Situation umgeht. Denken Sie daran, dass die endgültige Topologie genau der von 802.1D berechneten Topologie entspricht (d. h. ein blockierter Port an der gleichen Stelle wie zuvor). Nur die Schritte zum Erreichen dieser Topologie wurden geändert.

Beide Ports auf dem Link zwischen Switch A und Root werden sofort nach dem Aktivieren als blockierend eingestuft. Bisher verhält sich alles wie in einer reinen 802.1D-Umgebung. In diesem Stadium findet jedoch eine Aushandlung 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. Der Link 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 der Link zwischen Switch A und Root in den Weiterleitungsstatus versetzt, und Sie erreichen folgende Situation:

Es kann immer noch keine Schleife geben. Anstatt vor Switch A zu blockieren, wird das Netzwerk jetzt nach Switch A blockiert. Die potenzielle Bridge-Schleife wird jedoch an einer anderen Stelle abgeschnitten. Dieser Schnitt wird zusammen mit den neuen BPDUs, die vom Root über Switch A gesendet werden, den Tree entlang nach unten weitergeleitet. In diesem Stadium handeln die neu blockierten Ports auf Switch A auch einen schnellen Übergang in den Weiterleitungsstatus mit ihren benachbarten Ports auf Switch B und Switch C aus, die beide einen Synchronisierungsvorgang initiieren. Abgesehen vom Root-Port in Richtung A hat Switch B nur designierte Edge-Ports. Daher muss kein Port blockiert werden, um Switch A für den Wechsel in den Weiterleitungsstatus zu autorisieren. Ebenso muss Switch C nur seinen designierten Port für D blockieren. Der in diesem Diagramm gezeigte Status wird jetzt erreicht:

Denken Sie daran, dass die endgültige Topologie genau mit dem 802.1D-Beispiel übereinstimmt, was bedeutet, dass Port P1 auf D blockiert wird. Dies bedeutet, dass die endgültige Netzwerktopologie gerade in der Zeit erreicht wird, welche die neuen BPDUs benötigen, um sich den Tree entlang nach unten zu bewegen. Bei dieser schnellen Konvergenz ist kein Timer beteiligt. Der einzige neue Mechanismus, der von RSTP eingeführt wird, ist die Bestätigung, dass ein Switch auf seinem neuen Root-Port senden kann, um den sofortigen Übergang in den Weiterleitungsstatus zu autorisieren, und die lange Mithör- und Lernphase mit der doppelten Weiterleitungsverzögerung umgeht. Der Admin muss sich nur folgende Punkte merken, um von der schnellen Konvergenz zu profitieren:

• Diese Aushandlung zwischen Bridges ist nur möglich, wenn Bridges über Punkt-zu-Punkt-Links (d. h. Vollduplex-Links, es sei denn, es liegt eine explizite Portkonfiguration vor) verbunden sind.

• Edge-Ports spielen jetzt eine noch wichtigere Rolle, da in 802.1D PortFast auf Ports aktiviert ist. Wenn der Netzwerkadmin beispielsweise die Edge-Ports auf Switch B nicht ordnungsgemäß konfiguriert, wird ihre Verbindung durch den entstehenden Link zwischen Switch A und Root beeinträchtigt.

Angebots-/Vereinbarungssequenz

Wenn ein Port vom STA als designierter Port ausgewählt wird, wartet 802.1D dennoch zweimal <forward delay> Sekunden (standardmäßig 2 x 15), bevor der Übergang in den Weiterleitungsstatus erfolgt. In RSTP entspricht diese Bedingung einem Port mit einer designierten Rolle, aber einem blockierenden Status. Diese Diagramme veranschaulichen, wie ein schneller Übergang Schritt für Schritt erreicht wird. Angenommen, zwischen Root und Switch A wird ein neuer Link erstellt. Beide Ports in diesem Link werden in den Blockierungsstatus gesetzt, bis sie eine BPDU von ihrem Gegenstück empfangen.

Wenn sich ein designierter Port in einem Verwerfungs- oder Lernstatus befindet (und nur in diesem Fall), legt er das Angebots-Bit in den BPDUs fest, die er versendet. Dies geschieht für Port p0 der Root-Bridge, wie in Schritt 1 des vorherigen Diagramms gezeigt. Da Switch A übergeordnete Informationen erhält, weiß er sofort, dass p1 der neue Root-Port ist. Switch A startet dann eine Synchronisierung, um zu überprüfen, ob alle seine Ports mit diesen neuen Informationen synchron sind. Ein Port ist synchronisiert, wenn er eines der folgenden Kriterien erfüllt:

• Der Port befindet sich im Blockierungsstatus, d. h. er verwirft Pakete in einer stabilen Topologie.

• Der Port ist ein Edge-Port.

Um die Auswirkungen des Synchronisierungsmechanismus auf verschiedene Arten von Ports zu veranschaulichen, nehmen wir an, es gibt einen alternativen Port p2, einen designierten Weiterleitungsport p3 und einen Edge-Port p4 auf Switch A. Beachten Sie, dass p2 und p4 bereits eines der Kriterien erfüllen. Um synchron zu sein (siehe Schritt 2 im vorherigen Diagramm), muss Switch A nur Port p3 blockieren und ihm den Status „Discarding“ (verwerfend) zuweisen. Nachdem alle Ports synchronisiert sind, kann Switch A die Blockierung seines neu ausgewählten Root-Ports p1 aufheben und eine Zustimmungsnachricht senden, um an den Root zu antworten (siehe Schritt 3). Diese Nachricht ist eine Kopie der Angebot-BPDU, in der das Zustimmungs-Bit anstelle des Angebots-Bit festgelegt ist. Dadurch wird sichergestellt, dass Port p0 genau weiß, welchem Angebot die erhaltene Vereinbarung entspricht.

Sobald p0 diese Vereinbarung erhalten hat, kann er sofort in den Weiterleitungsstatus übergehen. Dies ist Schritt 4 in der vorherigen Abbildung. Beachten Sie, dass Port p3 nach der Synchronisierung im verwerfenden Status verbleibt. In Schritt 4 befindet sich dieser Port in genau der gleichen Situation wie Port p0 in Schritt 1. Er beginnt dann, seinem Nachbarn Vorschläge zu machen, und versucht, schnell in den Weiterleitungsstatus zu wechseln.

• Der Mechanismus der Angebotsvereinbarung läuft sehr schnell ab, da er nicht auf Timer angewiesen ist. Diese Handshake-Welle breitet sich schnell zum Netzwerk-Edge aus und stellt die Verbindung nach einer Topologieänderung schnell wieder her.

• Wenn ein designierter verwerfender Port keine Vereinbarung erhält, nachdem er ein Angebot gesendet hat, wechselt er langsam in den Weiterleitungsstatus und greift auf die herkömmliche 802.1D-Sequenz zum Mithören und Lernen zurück. Dies kann der Fall sein, wenn die Remote-Bridge RSTP-BPDUs nicht versteht oder der Port der Remote-Bridge blockierend ist.

• Cisco hat eine Verbesserung des Synchronisierungsmechanismus eingeführt, die es einer Bridge ermöglicht, bei der Synchronisierung nur den früheren Root-Port in den verwerfenden Status zu versetzen. Details zur Funktionsweise dieses Mechanismus sind nicht Teil dieses Dokuments. Man kann jedoch davon ausgehen, dass er in den meisten gängigen Rekonvergenzfällen aufgerufen wird. Das im Abschnitt Konvergenz mit 802.1w dieses Dokuments beschriebene Szenario ist äußerst effizient, da nur die Ports auf dem Pfad zum letzten blockierten Port vorübergehend verwechselt werden.

UplinkFast

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

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

Neue Mechanismen für Topologieänderungen

Wenn eine 802.1D-Bridge eine Topologieänderung erkennt, benachrichtigt sie über einen zuverlässigen Mechanismus zuerst die Root-Bridge. Dies wird im folgenden Diagramm dargestellt:

Sobald die Root-Bridge eine Änderung in der Netzwerktopologie erkennt, setzt sie das TC-Flag auf den BPDUs, die sie sendet. Diese werden dann an alle Bridges im Netzwerk weitergeleitet. Wenn eine Bridge eine BPDU mit gesetztem TC-Flag-Bit empfängt, reduziert sie die Alterungszeit der Bridge-Tabelle auf die Verzögerung bei der Weiterleitung in Sekunden. Dadurch wird eine relativ schnelle Löschung veralteter Informationen sichergestellt. Dieser Topologieänderungsmechanismus wurde in RSTP grundlegend neu gestaltet. Sowohl die Erkennung einer Topologieänderung als auch deren Verbreitung im Netzwerk wurden weiterentwickelt.

Erkennung von Topologieänderungen

Bei RSTP verursachen nur Nicht-Edge-Ports, die in den Weiterleitungsstatus wechseln, eine Topologieänderung. Dies bedeutet, dass ein Verbindungsverlust im Gegensatz zu 802.1D nicht mehr als Topologieänderung berücksichtigt wird (d. h. ein Port, der zum Blockieren wechselt, generiert keinen TC mehr). Wenn eine RSTP-Bridge eine Topologieänderung erkennt, geschieht Folgendes:

• Sie startet den TC-While-Timer mit einem Wert, der dem Doppelten der Hello-Zeit für alle ihre designierten Nicht-Edge-Ports und den Root-Port, falls erforderlich, entspricht.

• Sie löscht die MAC-Adressen, die all diesen Ports zugeordnet sind.

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

Verbreitung der Topologieänderung

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

• Sie löscht die erlernten MAC-Adressen von allen ihren Ports, mit Ausnahme des Ports, der die Topologieänderung empfängt.

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

Auf diese Weise flutet das TCN sehr schnell im gesamten Netzwerk. Die TC-Verbreitung ist jetzt ein einstufiger Prozess. Tatsächlich überträgt der Initiator der Topologieänderung diese Informationen im gesamten Netzwerk, im Gegensatz zu 802.1D, bei dem dies nur durch die Root-Bridge erfolgte. 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 für <max age plus forward delay> Sekunden aufrechtzuerhalten.

In nur wenigen Sekunden oder einem kleinen Vielfachen der Hello-Zeiten werden die meisten Einträge in den CAM-Tabellen des gesamten Netzwerks (VLAN) geleert. Dieser Ansatz führt möglicherweise eher zu einer vorübergehenden Flutung, löscht auf der anderen Seite aber auch potenziell veraltete Informationen, die eine schnelle Wiederherstellung der Verbindung verhindern.

Kompatibilität mit 802.1D

RSTP kann mit älteren STP-Protokollen zusammenarbeiten. Es ist jedoch wichtig zu beachten, dass die inhärenten Vorteile von 802.1w für die schnelle Konvergenz verloren gehen, wenn es mit älteren Bridges interagiert.

Jeder Port verwaltet eine Variable, die das Protokoll definiert, das im entsprechenden Segment ausgeführt werden soll. Ein Migrationsverzögerungs-Timer von drei Sekunden wird ebenfalls gestartet, wenn der Port hochgefahren wird. Wenn dieser Timer ausgeführt wird, wird der aktuelle STP- oder RSTP-Modus, der dem Port zugeordnet ist, gesperrt. Sobald die Migrationsverzögerung abläuft, passt sich der Port an den Modus an, welcher der nächsten durch ihn empfangenen BPDU entspricht. Wenn der Port seinen Betriebsmodus aufgrund einer empfangenen BPDU ändert, wird die Migrationsverzögerung neu gestartet. Dadurch wird die mögliche Häufigkeit von Modusänderungen eingeschränkt.

Nehmen wir an, die Bridges A und B in der vorherigen Abbildung führen beide RSTP aus, wobei Switch A für das Segment designiert ist. Eine ältere STP-Bridge C wird auf diesem Link eingeführt. Da 802.1D-Bridges RSTP-BPDUs ignorieren und verwerfen, glaubt C, dass es keine anderen Bridges im Segment gibt, und beginnt, seine minderwertigen BPDUs im 802.1D-Format zu senden. Switch A empfängt diese BPDUs und ändert nach dem Doppelten der Hello-Zeit seinen Modus nur auf diesem Port in 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 Bridge A im STP-Modus an diesem Port ausgeführt wird, wenn Bridge C entfernt wird, obwohl sie im RSTP-Modus mit eindeutigem Nachbarn B effizienter arbeiten kann. Dies liegt daran, dass A nicht weiß, dass Bridge C aus dem Segment entfernt wurde. 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 BPDUs (Topology Change Notifications, TCNs) und BPDUs mit TC- oder TCA-Bit verarbeiten.

Schlussfolgerung

RSTP (IEEE 802.1w) enthält von Haus aus die meisten proprietären Erweiterungen von Cisco für 802.1D Spanning Tree, z. B. BackboneFast, UplinkFast und PortFast. RSTP kann in einem ordnungsgemäß konfigurierten Netzwerk eine viel schnellere Konvergenz erreichen, manchmal im Bereich weniger hundert Millisekunden. Klassische 802.1D-Timer wie Forward Delay und max_age werden nur als Backup verwendet und sind nicht erforderlich, wenn Point-to-Point-Links und Edge-Ports ordnungsgemäß identifiziert und vom Admin festgelegt werden. Außerdem sind die Timer nicht erforderlich, wenn keine Interaktion mit älteren Bridges erfolgt.

Zugehörige Informationen

• Konfigurieren von MST (802.1s)/RSTP (802.1w) auf Switches der Catalyst-Serie mit CatOS
• Verständnis und Konfiguration der Cisco Uplink Fast-Funktion
• Tools und Ressourcen
• Technischer Support und Dokumentation für Cisco Systeme