Understand Rapid Spanning Tree Protocol (802.1w) (Inzicht in Rapid Spanning Tree Protocol (802.1w))

Inleiding

Dit document beschrijft informatie over de verbeteringen die door RSTP aan de vorige 802.1D-standaard zijn toegevoegd.

Achtergrond

De 802.1D Spanning Tree Protocol (STP)-standaard is ontworpen op een moment waarop het herstel van de connectiviteit na een stroomonderbreking binnen een minuut of zo als adequate prestaties werd beschouwd. Met de komst van Layer 3-switching in LAN-omgevingen concurreert de brug nu met gerouteerde oplossingen waar protocollen, zoals Open Shortest Path First (OSPF) en Enhanced Interior Gateway Routing Protocol (EIGRP), in minder tijd een alternatief pad kunnen bieden.

Cisco heeft de oorspronkelijke 802.1D-specificatie uitgebreid met functies, zoals Uplink Fast, Backbone Fast en Port Fast om de convergentietijd van een overbrugd netwerk te versnellen. Het nadeel is dat deze mechanismen bedrijfseigen zijn en extra configuratie nodig hebben.

Rapid Spanning Tree Protocol (RSTP; IEEE 802.1w) kan eerder als een evolutie van de 802.1D-standaard dan als een revolutie worden beschouwd. De 802.1D-terminologie blijft voornamelijk hetzelfde. De meeste parameters zijn onveranderd gebleven, zodat gebruikers die bekend zijn met 802.1D het nieuwe protocol snel en comfortabel kunnen configureren. In de meeste gevallen presteert RSTP beter dan bedrijfseigen extensies van Cisco zonder extra configuratie. 802.1w kan ook teruggaan naar 802.1D voor samenwerking met oudere bruggen, op een per-poortbasis. Hierdoor worden de voordelen die het oplevert verminderd.

De nieuwe editie van de 802.1D-standaard, IEEE 802.1D-2004, bevat IEEE 802.1t-2001- en IEEE 802.1w-standaarden.

Ondersteuning van RSTP in Catalyst-Switches

Deze tabel laat de ondersteuning van RSTP in bepaalde Catalyst switches-families zien, en de minimale software die voor die ondersteuning vereist is.

Catalyst-platform	MST met RSTP	RPVST+ (ook bekend als PVRST+)
Catalyst 2900-XL / 3500-XL switch	Niet beschikbaar.	Niet beschikbaar.
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)AXE	12.1(14)AXE
Catalyst 2948G-L3/4908G-L3 switch	Niet beschikbaar.	Niet beschikbaar.
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	Niet beschikbaar.	Niet beschikbaar.

Nieuwe poortstaten en poortrollen

802.1D wordt gedefinieerd in deze vijf verschillende poortstaten:

• uitgeschakeld

• luisteren

• scholing

• blokkeren

• doorsturen

Zie de tabel in het gedeelte Port States van dit document voor meer informatie over de havenstaten.

De staat van de haven is gemengd, of het blokkeert of voorwaarts verkeer, en de rol het in de actieve topologie speelt (wortelhaven, aangewezen haven, etc.). Vanuit operationeel oogpunt is er bijvoorbeeld geen verschil tussen een haven in de blokkerende staat en een haven in de luisterstaat. Zowel verwerp frames en leer niet de MAC-adressen. Het echte verschil zit in de rol die de overspannende boom toewijst aan de haven. Men kan er gerust van uitgaan dat een luisterpoort is aangewezen of geworteld en op weg is naar de doorvoerstaat. Helaas is er, eenmaal in de verzendende staat, geen manier om uit de havenstaat af te leiden of de haven wortel- of aangewezen is. Dit draagt ertoe bij het falen van deze op staten gebaseerde terminologie aan te tonen. RSTP ontkoppelt de rol en de status van een poort om deze kwestie aan te pakken.

Havenstaten

Er zijn nog slechts drie havenstaten in RSTP die corresponderen met de drie mogelijke operationele staten. De 802.1D-, blokkerings- en luisterstatus worden samengevoegd in een unieke 802.1w-afvoerstatus.

STP (802.1D)-poortstaat	RSTP (802.1w) poortstaat	Is de haven inbegrepen in Actieve Topologie?	Is Port Learning MAC-adressen?
Uitgeschakeld	Teruggooi	Nee	Nee
Afscherming	Teruggooi	Nee	Nee
Luisteren	Teruggooi	Ja	Nee
Leren	Leren	Ja	Ja
Doorsturen	Doorsturen	Ja	Ja

Poortrollen

De havenrol is nu een variabele die aan een bepaalde haven wordt toegewezen. De rootpoort en aangewezen poortrollen blijven, terwijl de blokkerende poortrol wordt gesplitst in de back-up- en alternatieve poortrollen. Het Spanning Tree Algoritme (STA) bepaalt de rol van een poort, gebaseerd op Bridge Protocol Data Units (BPDU’s). Om zaken te vereenvoudigen, is het ding om over een BPDU te herinneren er altijd een methode is om om het even welke twee van hen te vergelijken en te beslissen als één nuttiger is dan andere. Dit is gebaseerd op de waarde die is opgeslagen in de BPDU en af en toe op de poort waarop ze zijn ontvangen. In dit verband wordt in de informatie in dit deel een praktische benadering van de havenrol toegelicht.

Root-poortrollen

• De poort die de beste BPDU op een brug ontvangt, is de wortelpoort. Dit is de haven die het dichtst bij de root-brug ligt wat de kosten van het dienstregelingspad betreft. STA selecteert één enkele root-brug in het gehele overbrugde netwerk (per-VLAN). De root-brug stuurt BPDU's die nuttiger zijn dan die van een andere brug. De root-brug is de enige brug in het netwerk die geen wortelpoort heeft. Alle andere bruggen ontvangen BPDU's op ten minste één poort.

  

Aangewezen poortrol

• Een poort wordt aangewezen als deze de beste BPDU kan versturen op het segment waarnaar deze is verbonden. 802.1D bruggen koppelen verschillende segmenten, zoals Ethernet-segmenten, om een overbrugd domein te maken. Voor een gegeven segment kan er maar één pad zijn richting de root-brug. Als er twee paden zijn, is er een bruglus in het netwerk. Alle bruggen die met een bepaald segment zijn verbonden, luisteren naar de BPDU's van elk en stemmen in met de brug die de beste BPDU als de aangewezen brug voor het segment verzendt. De haven op de brug die correspondeert is de aangewezen haven voor dat segment.

  

Alternatieve en back-uppoortrollen

• Deze twee poortrollen komen overeen met de blokkerende status van 802.1D. Een geblokkeerde poort is gedefinieerd als niet de aangewezen poort of de hoofdpoort. Een geblokkeerde poort ontvangt een bruikbaarder BPDU dan de poort die op zijn segment wordt verstuurd. Vergeet niet dat een poort BPDU's moet ontvangen om geblokkeerd te kunnen blijven. RSTP introduceert deze twee rollen voor dit doel.

• Een alternatieve poort ontvangt bruikbaardere BPDU's van een andere brug en is een geblokkeerde poort. Dit wordt in dit diagram weergegeven:

  

• Een back-uppoort ontvangt bruikbaardere BPDU's van dezelfde brug waarop hij is ingeschakeld en is een poort geblokkeerd. Dit wordt in dit diagram weergegeven:

  

Dit onderscheid wordt intern al gemaakt binnen 802.1D. Dit is in essentie de manier waarop Cisco UplinkFast werkt. De reden is dat een alternatieve poort een alternatieve pad naar de root-brug biedt en daarom de root poort kan vervangen als deze mislukt. Een back-uppoort biedt uiteraard redundante connectiviteit met hetzelfde segment en kan geen alternatieve connectiviteit met de root-brug garanderen. Daarom is het uitgesloten van de uplinkgroep.

Dientengevolge, berekent RSTP de definitieve topologie voor het overspannen - boom die de zelfde criteria zoals 802.1D gebruikt. Er is geen verandering in de manier waarop de verschillende brug- en havenprioriteiten worden gebruikt. De naamblokkering wordt gebruikt voor de afvoerstatus in Cisco-implementatie. CatOS release 7.1 en later nog steeds de luisterings- en leertoestanden. Dit geeft meer informatie over een poort dan de IEEE-standaard vereist. De nieuwe functie is nu echter dat er een verschil is tussen de rol die het protocol bepaalt voor een poort en de huidige status. Het is nu bijvoorbeeld geldig om een poort tegelijkertijd aan te wijzen en te blokkeren. Terwijl dit meestal voor zeer korte perioden gebeurt, betekent het dat deze haven in een overgangsstaat naar de aangewezen doorvoerstaat is.

Nieuw BPDU-formaat

Er zijn weinig wijzigingen door RSTP in het BPDU-formaat geïntroduceerd. Slechts twee vlaggen, Topology Change (TC) en TC Acknowledgement (TCA), zijn gedefinieerd in 802.1D. RSTP gebruikt echter alle zes bits van de vlagbyte die overblijven om te kunnen uitvoeren:

• Codeer de rol en de staat van de poort die de BPDU start

• Behandel het voorstel/verdragsmechanisme

Volledige weergave van de diagrammen Cisco BPDU, IEEE BPDU en BPDU

Voor een afbeelding met een hogere resolutie, zie Cisco BPDU-, IEEE BPDU- en BPDU-diagrammen.

Opmerking: Bit 0 (Topologiewijziging) is het minst significante bit.

Een andere belangrijke verandering is dat RSTP BPDU nu type 2, versie 2 is. De implicatie is dat legacy bruggen deze nieuwe BPDU moeten laten vallen. Deze eigenschap maakt het gemakkelijk voor een 802.1w-brug om oudere bruggen te detecteren die er op zijn aangesloten.

Nieuwe BPDU-verwerking

BPDU's worden elke Hello-time verzonden

BPDU's worden elke hello-time gestuurd en niet meer alleen maar doorgegeven. Met 802.1D genereert een niet-root-brug alleen BPDU's wanneer er een wordt ontvangen op de hoofdpoort. Een brug geeft BPDU's meer door dan het ze genereert. Dit is niet het geval met 802.1w. Een bridge verstuurt een BPDU met de huidige informatie elke <hello-time> seconden (2 standaard), zelfs als het geen van de root-brug ontvangt.

Snellere veroudering van informatie

Voor een gegeven haven, als hellos niet drie opeenvolgende keer worden ontvangen, kan de protocolinformatie onmiddellijk uit worden verouderd (of als max_age verloopt). Vanwege de eerder genoemde protocolwijziging worden BPDU's nu gebruikt als een mechanisme tussen bruggen. Een brug is van mening dat het connectiviteit aan zijn directe buurwortel of aangewezen brug verliest als het drie BPDUs in een rij mist. Deze snelle veroudering van de informatie maakt snelle foutdetectie mogelijk. Als een brug er niet in slaagt om BPDUs van een buur te ontvangen, is het zeker dat de verbinding met die buur wordt verloren. Dit is tegengesteld aan 802.1D, waar het probleem overal op het pad naar de wortel kan zijn.

Opmerking: fouten worden zelfs veel sneller gedetecteerd in het geval van fysieke koppelingsfouten.

Aanvaardt lagere BPDU's

Dit concept is wat de kern vormt van de BackboneFast engine. De IEEE 802.1w-commissie heeft een soortgelijk mechanisme in RSTP opgenomen. Wanneer een brug inferieure informatie van zijn aangewezen of root-brug ontvangt, accepteert het onmiddellijk en vervangt het eerder opgeslagen.

Omdat Bridge C nog steeds weet dat de wortel nog leeft en goed is, wordt er onmiddellijk een BPDU naar Bridge B gestuurd die informatie bevat over de root-brug. Dientengevolge, verzendt de Brug B geen eigen BPDUs en aanvaardt de haven die tot Brug C als nieuwe wortelhaven leidt.

Snelle overgang naar doorsturen staat

Snelle transitie is het belangrijkste onderdeel van 802.1w. De legacy STA wachtte passief op het netwerk om samen te komen voordat het een poort veranderde in de doorsturen staat. Het bereiken van snellere convergentie was een kwestie van veranderingen die aan de conservatieve standaardparameters (voorwaartse vertraging en max_age timers) worden aangebracht en stelde vaak de stabiliteit van het netwerk op het spel. De nieuwe snelle STP kan actief bevestigen dat een poort veilig kan overschakelen naar de doorsturen staat zonder dat het nodig is om te vertrouwen op enige timer configuratie. Er is nu een echt terugkoppelingsmechanisme dat plaatsvindt tussen RSTP-conforme bruggen. Om snelle convergentie op een poort te bereiken, is het protocol gebaseerd op twee nieuwe variabelen: edge ports en link type.

Edge-poorten

Het concept van de randpoort is al bekend bij Cisco-gebruikers die de boom overspannen, omdat het in principe overeenkomt met de functie PortFast. Alle poorten die direct zijn verbonden met eindstations kunnen geen bruglijnen in het netwerk maken. Daarom overgaat de randpoort direct naar de doorstuurstatus en slaat de luisterfase en de leerfase over. Geen van de randpoorten of PortFast-enabled poorten genereren topologiewijzigingen wanneer de koppeling in- of uitschakelt. Een randpoort die een BPDU ontvangt, verliest onmiddellijk de status van de randpoort en wordt een normale overspannende boompoort. Op dit punt, is er een gebruiker-gevormde waarde en een operationele waarde voor de staat van de randhaven. De implementatie van Cisco houdt vol dat het PortFast-trefwoord moet worden gebruikt voor de configuratie van randpoorten. Dit maakt de overgang naar RSTP eenvoudiger.

Linktype

RSTP kan alleen een snelle overgang naar de doorsturen status op randpoorten en op point-to-point links realiseren. Het koppelingstype wordt automatisch afgeleid uit de duplexmodus van een poort. Een poort die in full-duplex werkt wordt verondersteld point-to-point te zijn, terwijl een half-duplex poort standaard als een gedeelde poort wordt beschouwd. Deze automatische link type waarde kan worden overschreven door expliciete configuratie. In geschakelde netwerken werken de meeste links vandaag in full-duplex modus en worden door RSTP behandeld als point-to-point links. Dit maakt ze kandidaat voor een snelle overgang naar de staat van doortocht.

Convergentie met 802.1D

Dit diagram illustreert hoe 802.1D omgaat met een nieuwe link die wordt toegevoegd aan een overbrugd netwerk:

In dit scenario wordt een koppeling tussen de root-brug en Bridge A toegevoegd. Stel dat er al een indirect verband is tussen brug A en de root-brug (bij C - D in het diagram). De STA blokkeert een poort en schakelt de bruglus uit. Ten eerste, als ze omhoog komen, worden beide poorten op de verbinding tussen de wortel en brug A in de luisterstaat gezet. Bridge A is nu in staat de root direct te horen. Het verspreidt onmiddellijk zijn BPDU's op de aangewezen havens, naar de bladeren van de boom. Zodra Bridges B en C deze nieuwe superieure informatie van Bridge A ontvangen, geven ze de informatie onmiddellijk door naar de bladeren. In een paar seconden ontvangt Bridge D een BPDU van de root en blokkeert direct poort P1.

Spanning Tree is zeer efficiënt in hoe het de nieuwe topologie van het netwerk berekent. Het enige probleem is nu dat tweemaal de voorwaartse vertraging moet verstrijken voordat het verband tussen de wortel en Bridge A uiteindelijk in de doorvoerstaat terechtkomt. Dit betekent 30 seconden van verstoring van verkeer (het volledige A, B, en deel C van het netwerk wordt geïsoleerd) omdat het algoritme 8021.D een terugkoppelingsmechanisme mist om duidelijk te adverteren dat het netwerk in een kwestie van seconden samenkomt.

Convergentie met 802.1w

Nu, kunt u zien hoe RSTP met een gelijkaardige situatie omgaat. Vergeet niet dat de uiteindelijke topologie precies hetzelfde is als die berekend door 802.1D (dat wil zeggen, een geblokkeerde poort op dezelfde plaats als voorheen). Slechts zijn de stappen die worden gebruikt om deze topologie te bereiken veranderd.

Beide Switches op de verbinding tussen de A-stam en de A-stam worden meteen na de opening van het schip geblokkeerd. Tot nu toe gedraagt alles zich als in een zuivere 802.1D omgeving. In dit stadium wordt echter onderhandeld tussen Switch A en de kern van de zaak. Zodra Switch A de BPDU van de wortel ontvangt, blokkeert het de niet-rand aangewezen poorten. Deze handeling wordt sync genoemd. Zodra dit is gedaan, geeft Bridge A de root-brug expliciet toestemming om zijn poort in de verzendstaat te plaatsen. Dit diagram illustreert het resultaat van dit proces op het netwerk. Het verband tussen Switch A en de root-brug wordt geblokkeerd, en beide bruggen wisselen BPDU's uit.

Zodra Switch A zijn niet-rand aangewezen poorten blokkeert, wordt het verband tussen Switch A en de root in de doorvoerstaat gezet en bereikt u de situatie:

Er kan nog steeds geen sprake zijn van een lus. In plaats van te blokkeren voor Switch A, blokkeert het netwerk nu na Switch A. Echter, de potentiële bridge loop wordt op een andere locatie gesneden. Deze snede reist langs de boomstructuur, samen met de nieuwe BPDU's die door de wortel via Switch A ontstaan. In dit stadium onderhandelen de onlangs geblokkeerde poorten op Switch A ook over een snelle overgang naar de doorsturen staat met hun buurpoorten op Switch B en Switch C die beide een sync-bewerking starten. Buiten de wortelpoort naar A heeft Switch B alleen 'edge'-aangewezen poorten. Daarom heeft het geen enkele haven om te blokkeren om Switch A toestemming te geven naar de staat van verzending te gaan. Op dezelfde manier hoeft Switch C alleen zijn aangewezen poort naar D te blokkeren. De staat die in dit diagram wordt getoond, is nu bereikt:

Vergeet niet dat de uiteindelijke topologie precies hetzelfde is als het 802.1D voorbeeld, wat betekent dat poort P1 op D eindigt met blokkeren. Dit betekent dat de definitieve netwerktopologie wordt bereikt, enkel in de tijd noodzakelijk voor nieuwe BPDUs om onderaan de boom te reizen. Geen timer is betrokken bij deze snelle convergentie. Het enige nieuwe die mechanisme door RSTP wordt geïntroduceerd is de erkenning die een switch op zijn nieuwe wortelhaven kan verzenden om directe overgang naar de door:sturen staat toe te staan, en omzeilt tweemaal de voorwaartse-voorwaartse lange het luisteren en het leren stadia. De beheerder hoeft deze alleen te onthouden om te profiteren van een snelle convergentie:

• Deze onderhandeling tussen bruggen is alleen mogelijk wanneer bruggen zijn verbonden door point-to-point links (dat wil zeggen full-duplex links, tenzij expliciete poortconfiguratie).

• Edge-poorten spelen een nog belangrijker rol nu PortFast is ingeschakeld op poorten in 802.1D. Als de netwerkbeheerder bijvoorbeeld de randpoorten op Switch B niet goed kan configureren, wordt hun verbinding beïnvloed door het verband tussen Switch A en de root die omhoog komt.

Voorstel/overeenkomstvolgorde

Wanneer een poort door de STA is geselecteerd om een aangewezen poort te worden, wacht 802.1D nog steeds twee keer <voorwaartse vertraging> seconden (2 x 15 standaard) voordat deze overgaat naar de status van het doorsturen. In RSTP komt deze voorwaarde overeen met een haven met een aangewezen rol maar een blokkerende staat. Deze diagrammen laten zien hoe de snelle overgang stap voor stap wordt bereikt. Stel dat er een nieuwe koppeling wordt gemaakt tussen de root en Switch A. Beide havens op deze verbinding worden in een aangewezen blokkerende staat geplaatst tot zij een BPDU van hun tegenhanger ontvangen.

Wanneer een aangewezen poort zich in een verwerpings- of leertoestand bevindt (en alleen in dit geval), wordt het voorstelbit ingesteld op de BPDU's die worden verzonden. Dit is wat voor poort p0 van de root-brug optreedt, zoals in stap 1 van het bovenstaande schema is aangegeven. Omdat Switch A superieure informatie ontvangt, weet het direct dat p1 de nieuwe wortelpoort is. Switch A start vervolgens een sync om te verifiëren dat alle poorten synchroon zijn met deze nieuwe informatie. Een poort is synchroon als deze aan een van de volgende criteria voldoet:

• De haven is in de blokkerende staat, wat in een stabiele topologie het verwerpen betekent.

• De poort is een randpoort.

Om het effect van het synchronisatiemechanisme op verschillende soorten poorten te illustreren, veronderstel dat er een alternatieve poort p2, een aangewezen doorstuurpoort p3, en een randpoort p4 op Switch A. Merk op dat p2 en p4 al aan een van de criteria voldoen. Om in sync te zijn (zie stap 2 van het vorige diagram), moet Switch A alleen poort p3 blokkeren, en het de verwerpingsstaat toewijzen. Nu al zijn poorten synchroon zijn, kan Switch A de nieuw geselecteerde rootpoort p1 deblokkeren en een toestemmingsbericht verzenden om op de rootpoort te reageren. (zie stap 3). Dit bericht is een kopie van het voorstel BPDU, met de overeenkomst bit ingesteld in plaats van het voorstel bit. Dit zorgt ervoor dat haven p0 precies weet met welk voorstel de overeenkomst die zij ontvangt overeenkomt.

Zodra p0 die overeenkomst ontvangt, kan het onmiddellijk overgang naar de door:sturen staat. Dit is stap 4 van het vorige cijfer. Merk op dat poort p3 wordt achtergelaten in een toegewezen verwerpingsstaat na de sync. In stap 4 bevindt die haven zich in precies dezelfde situatie als haven p0 in stap 1 is. Het begint vervolgens te voorstellen aan zijn buurman, en probeert een snelle overgang naar de doorvoerstaat.

• Het voorstel voor een akkoord is zeer snel, aangezien het niet afhankelijk is van tijdslimieten. Deze golf van handdrukken verspreidt zich snel naar de rand van het netwerk, en herstelt snel connectiviteit na een verandering in de topologie.

• Als een aangewezen teruggooihaven geen overeenkomst ontvangt nadat het een voorstel verzendt, gaat het langzaam over naar de door:sturen staat, en valt terug op de traditionele 802.1D luisterend-learning opeenvolging. Dit kan voorkomen als de externe brug RSTP BPDUs niet begrijpt, of als de poort van de externe brug blokkeert.

• Cisco heeft een verbetering in het synchronisatiemechanisme geïntroduceerd dat een brug toestaat om alleen zijn voormalige wortelpoort in de afvoerstaat te plaatsen wanneer deze synchroniseert. De details van de werking van dit mechanisme vallen buiten de reikwijdte van dit document. Men kan er echter gerust van uitgaan dat dit in de meeste gebruikelijke reconvergentiegevallen het geval is. Het scenario dat in het gedeelte Convergentie met 802.1w van dit document wordt beschreven, wordt uiterst efficiënt, omdat alleen de poorten op het pad naar de laatste geblokkeerde poort tijdelijk worden verward.

UplinkFast

Een andere vorm van onmiddellijke overgang naar de doorsturen staat die in RSTP is opgenomen, is vergelijkbaar met de Cisco UplinkFast proprietary Spanning Tree Extension. Fundamenteel, wanneer een brug zijn wortelhaven verliest, kan het zijn beste afwisselende haven in de door:sturen wijze (de verschijning van een nieuwe wortelhaven wordt ook behandeld door RSTP) direct zetten. De selectie van een alternatieve poort als de nieuwe wortelpoort genereert een topologiewijziging. Het mechanisme van de topologieverandering 802.1w ontruimt de aangewezen ingangen in de Content Adressable Memory (CAM) lijsten van de stroomopwaartse brug. Dit verwijdert de behoefte aan het dummy multicast generatieproces van UplinkFast.

UplinkFast hoeft niet verder te worden geconfigureerd omdat het mechanisme native is opgenomen en automatisch is ingeschakeld in RSTP.

Nieuwe mechanismen voor topologiewijziging

Wanneer een 802.1D-bridge een topologiewijziging detecteert, gebruikt het een betrouwbaar mechanisme om de root-brug eerst op de hoogte te stellen. Dit wordt in dit diagram weergegeven:

Zodra de root-brug zich bewust is van een verandering in de netwerktopologie, stelt zij de TC-vlag op de BPDU's die zij verstuurt, die vervolgens worden doorgegeven aan alle bruggen in het netwerk. Wanneer een brug een BPDU ontvangt met de TC vlag bit ingesteld, vermindert het zijn bridge-table verouderingstijd om vertragingsseconden door te sturen. Dit zorgt voor een relatief snelle stroom van verouderde informatie. Dit mechanisme van de topologieverandering wordt diepgaand gerenoveerd in RSTP. Zowel de opsporing van een topologieverandering als zijn propagatie door het netwerk evolueren.

Detectie van topologiewijzigingen

In RSTP, slechts veroorzaken de niet-randhavens die zich aan de door:sturen staat bewegen een topologieverandering. Dit betekent dat een verlies van connectiviteit niet meer als een topologieverandering wordt beschouwd, in tegenstelling tot 802.1D (namelijk een haven die zich aan het blokkeren beweegt produceert niet meer een TC). Wanneer een RSTP-brug een topologiewijziging detecteert, komen deze voor:

• Het start de TC Terwijl timer met een waarde gelijk aan tweemaal de hello-tijd voor al zijn niet-rand aangewezen poorten en zijn wortelpoort, indien nodig.

• Het spoelt de MAC-adressen die aan al deze poorten gekoppeld zijn.

Opmerking: zolang de TC als de timer op een poort draait, hebben de BPDU's die uit die poort worden verzonden de TC bit-set. BPDU's worden ook verzonden op de wortelpoort terwijl de timer actief is.

Doorgifte van topologiewijzigingen

Wanneer een brug een BPDU ontvangt met de TC bit ingesteld van een buur, komen deze voor:

• Het ontruimt de adressen van MAC die op al zijn havens, behalve worden geleerd die de topologieverandering ontvangen.

• Het start de TC Terwijl timer en verstuurt BPDU's met de TC bit ingesteld op al zijn aangewezen poorten en wortelpoort (RSTP gebruikt niet langer de specifieke TCN BPDU, tenzij een legacy bridge een melding nodig heeft).

Op deze manier stromen de TCN's heel snel door het hele netwerk. De TC-voortplanting is nu een eenstapsproces. In feite, de initiatiefnemer van de topologieverandering overspoelt deze informatie door het netwerk, in tegenstelling tot 802.1D waar slechts de root-brug. Dit mechanisme is veel sneller dan het 802.1D equivalent. U hoeft niet te wachten tot de root-brug is aangemeld en de status van de topologiewijziging voor het hele netwerk gedurende <max. pagina plus voorwaartse vertraging> seconden te handhaven.

In slechts een paar seconden, of een klein veelvoud van hello-tijden, de meeste ingangen in de CAM-tabellen van het gehele netwerk (VLAN) flush. Deze aanpak resulteert in potentieel meer tijdelijke overstromingen, maar aan de andere kant het ontruimt potentiële verouderde informatie die snelle connectiviteit restitutie verhindert.

Compatibiliteit met 802.1D

RSTP kan interworking met oudere STP-protocollen. Het is echter belangrijk om op te merken dat de inherente snelle convergentievoordelen van 802.1w verloren gaan wanneer het interageert met legacy bruggen.

Elke poort behoudt een variabele die het protocol definieert dat op het corresponderende segment moet worden uitgevoerd. Een migratievertragingstimer van drie seconden begint ook als de poort omhoog komt. Wanneer deze timer wordt uitgevoerd, is de huidige STP- of RSTP-modus die aan de poort is gekoppeld, vergrendeld. Zodra de migratievertraging verloopt, past de poort zich aan aan de modus die overeenkomt met de volgende BPDU die hij ontvangt. Als de poort zijn werkwijze wijzigt als gevolg van een ontvangen BPDU, wordt de migratievertraging opnieuw gestart. Dit beperkt de mogelijke frequentie van de modemverandering.

Stel bijvoorbeeld dat bruggen A en B in het vorige getal allebei RSTP draaien, waarbij Switch A voor het segment is bestemd. Een legacy STP Bridge C wordt toegevoegd aan deze link. Aangezien 802.1D-bruggen RSTP BPDU's negeren en laten vallen, gelooft C dat er geen andere bruggen op het segment zijn en begint zijn inferieure 802.1D-formaat BPDU's te verzenden. Switch A ontvangt deze BPDU's en wijzigt, na tweemaal zoveel seconden te hebben gewacht, de modus alleen op die poort naar 802.1D. Als gevolg daarvan begrijpt C nu de BPDU's van Switch A en accepteert A als de aangewezen brug voor dat segment.

Opmerking In dit specifieke geval, als Bridge C is verwijderd, loopt Bridge A in STP-modus op die poort, ook al kan het efficiënter werken in RSTP-modus met zijn unieke buur B. Dit komt doordat A niet weet dat Bridge C uit het segment wordt verwijderd. Voor dit specifieke (zeldzame) geval, is gebruikersinterventie vereist om de protocoldetectie van de poort handmatig opnieuw te starten.

Wanneer een poort zich in de 802.1D-compatibiliteitsmodus bevindt, kan deze ook BPDU's (topology change notification) en BPDU's met een TC- of TCA-bitset verwerken.

Conclusie

RSTP (IEEE 802.1w) biedt standaard de meeste bedrijfseigen verbeteringen van Cisco voor de 802.1D-Spanning Tree, zoals BackboneFast, UplinkFast en PortFast. RSTP kan veel snellere convergentie bereiken in een goed geconfigureerd netwerk, soms in de orde van een paar honderd milliseconden. Klassieke 802.1D-timers, zoals voorwaartse vertraging en max_age, worden alleen gebruikt als back-up en zijn niet nodig als point-to-point links en randpoorten door de beheerder correct worden geïdentificeerd en ingesteld. Ook zijn de timers niet nodig als er geen interactie is met legacy bruggen.

Gerelateerde informatie

• MST (802.1s)/RSTP (802.1w) configureren op Catalyst Series Switches waarop CatOS wordt uitgevoerd
• De Cisco Uplink Fast-functie begrijpen en configureren
• Tools en bronnen
• Technische ondersteuning en documentatie – Cisco Systems