De betekenis van Rapid Spanning Tree Protocol (802.1w)

Inleiding

Dit document bevat informatie over de verbeteringen die door RSTP zijn toegevoegd aan de vorige 802.1D-standaard. De 802.1D Spanning Tree Protocol (STP) is ontworpen op een moment dat het herstel van connectiviteit na een defect binnen een minuut of zo als adequate prestatie werd beschouwd. Dankzij Layer 3 switching in LAN-omgevingen concurreert het bruggen nu met routed solutions waar protocollen, zoals Open Shortest Path First (OSPF) en Enhanced Interior Gateway Routing Protocol (DHCP), in minder tijd een alternatieve route kunnen bieden.

Cisco verbeterde de originele 802.1D specificatie met functies zoals Snel uplinken, Snelle backbone en Port Fast om de conversietijd van een samengevoegd netwerk te versnellen. Het nadeel is dat deze mechanismen eigen zijn en extra configuratie nodig hebben.

Rapid Spanning Tree Protocol (RSTP) IEEE 802.1w) kan meer dan een revolutie als een evolutie van de 802.1D-standaard worden gezien. De terminologie van 802.1D blijft in de eerste plaats hetzelfde. De meeste parameters blijven ongewijzigd, zodat gebruikers die bekend zijn met 802.1D, het nieuwe protocol snel en veilig kunnen configureren. In de meeste gevallen, presteert RSTP beter dan de bedrijfseigen uitbreidingen van Cisco zonder enige extra configuratie. 802.1w kan ook terugkeren naar 802.1d om te kunnen samenwerken met bestaande bruggen per poort. Dit vermindert de voordelen die het introduceert.

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

Ondersteuning van RSTP in Catalyst-Switches

Deze tabel toont de ondersteuning van RSTP in Catalyst-switches en de minimale software die voor deze ondersteuning vereist is.

Catalyst 9300 platform	MST met RSTP	RPVST+ (ook bekend als PVRST+)
Catalyst 2900XL/3500XL 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)AX	12.1(14)AX
Catalyst 2948G-L3/4908G-L3 switch	Niet beschikbaar.	Niet beschikbaar.
Catalyst 4000/2948G/2980G (CATOS)	7.1	7.5
Catalyst 4000/4500 (IOS)	12.1(12c)EW	12.1(19)EW
Catalyst 5000/5500	Niet beschikbaar.	Niet beschikbaar.
Catalyst 6000/6500	7.1	7.5
Catalyst 6000/6500 (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 is gedefinieerd in deze vijf verschillende havenstaten:

• gehandicapt

• luisteren

• leren

• blokkeren

• doorsturen

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

De staat van de haven is gemengd, of het verkeer blokkeert of vooruitwijst, en de rol het speelt in de actieve topologie (wortelhaven, aangewezen haven, enz.). Vanuit operationeel oogpunt is er bijvoorbeeld geen verschil tussen een haven in de blokkerende staat en een haven in de luisterstaat. Zowel weggooien kaders als leren geen adressen van MAC. Het echte verschil ligt in de rol die de omspannende boom aan de haven toewijst. Er kan met zekerheid worden aangenomen dat een luisterpoort is aangewezen of geworteld en op weg is naar de verzendende staat. Helaas, eenmaal in de staat van verzending, is er geen manier om uit de havenstaat af te leiden of de haven wortel is of aangewezen. Dit draagt ertoe bij dat deze op de staat gebaseerde terminologie mislukt. RSTP ontkoppelt de rol en de status van een haven om dit probleem aan te pakken.

Poortstaten

Er zijn slechts drie havenstaten over in RSTP die overeenkomen met de drie mogelijke operationele staten. De 802.1D-staten zijn uitgeschakeld, geblokkeerd en geluisterd en zijn samengevoegd in een unieke 802.1w-teruggooistaat.

STP (802.1D) poortstaat	RSTP-poortstaat (802.1w)	Is poort opgenomen in actieve topologie?	Zijn de MAC-adressen van het leren van poorten?
Uitgeschakeld	ontslag	Nee	Nee
Blokken	ontslag	Nee	Nee
Luisteren	ontslag	Ja	Nee
Leren	Leren	Ja	Ja
Doorsturen	Doorsturen	Ja	Ja

Poortrollen

De rol is nu een variabele toegewezen aan een bepaalde haven. De wortelhaven en aangewezen havenrollen blijven, terwijl de blokkerende havenrol in de reserve en alternatieve havenrollen wordt verdeeld. Het Spanning Tree Algorithm (STA) bepaalt de rol van een poort op basis van Bridge Protocol Data Units (BPDU’s). Om zaken makkelijker te maken is het ding om te onthouden van een BPDU altijd een methode om ze te vergelijken en te beslissen of het ene bruikbaarder is dan het andere. Dit is gebaseerd op de waarde die is opgeslagen in de BPDU en soms op de haven waarop ze worden ontvangen. In dit verband wordt in de informatie in dit deel de praktische aanpak van de rol van havens toegelicht.

Root-poortrollen

• De poort die de beste BPDU op een brug ontvangt is de wortelhaven. Dit is de haven die qua padkosten het dichtst bij de root-brug staat. De STA kiest één root-brug in het hele bridging netwerk (per-VLAN). De root-brug stuurt BPDU's die nuttiger zijn dan die welke andere brug verstuurt. De root-brug is de enige brug in het netwerk die geen wortelhaven heeft. Alle andere bruggen ontvangen BPDU's op ten minste één poort.

  

Aangewezen poortrol

• Een poort wordt aangewezen als deze de beste BPDU op het segment kan verzenden naar wie deze is aangesloten. 802.1D bruggen verbinden verschillende segmenten, zoals Ethernet segmenten, om een rond domein te creëren. Op een bepaald segment kan er maar één pad naar de root-brug worden afgelegd. Als er twee zijn, is er een overbruggingslus in het netwerk. Alle bruggen die op een bepaald segment zijn aangesloten, luisteren naar de BPDU's van elk en komen overeen op de brug die de beste BPDU als de aangewezen brug voor het segment verstuurt. De haven op die brug die correspondeert is de aangewezen haven voor dat segment.

  

Alternatieve en back-uppoortrollen

• Deze twee poortrollen corresponderen met de blokkeringstoestand van 802.1D. Een geblokkeerde haven wordt gedefinieerd als niet de aangewezen of wortelhaven. Een geblokkeerde poort ontvangt een bruikbaarder BPDU dan degene die het op zijn segment verstuurt. Denk eraan dat een haven absoluut BPDU's moet ontvangen om geblokkeerd te blijven. RSTP voert deze twee rollen voor dit doel in.

• Een alternatieve poort ontvangt bruikbaarder BPDU's van een andere brug en is een poort geblokkeerd. Dit wordt in dit schema getoond:

  

• Een back-uppoort ontvangt bruikbaarder BPDU's vanaf dezelfde brug waarop het staat en is een poort geblokkeerd. Dit wordt in dit schema getoond:

  

Dit onderscheid wordt al intern binnen 802.1D gemaakt. Dit is in wezen hoe Cisco UplinkFast functioneert. De reden is dat een alternatieve poort een alternatieve route naar de root-brug biedt en daarom de root poort kan vervangen als deze faalt. Natuurlijk biedt een reservepoort redundante connectiviteit aan het zelfde segment en kan geen afwisselende verbinding aan de root-brug waarborgen. Daarom wordt het van de uplink-groep uitgesloten.

Als resultaat hiervan berekent RSTP de definitieve topologie voor het overspannen van boom die de zelfde criteria als 802.1D gebruikt. Er is absoluut geen verandering in de manier waarop de verschillende brug- en havenprioriteiten worden gebruikt. De naam die wordt geblokkeerd wordt gebruikt voor de teruggooistatus in Cisco-implementatie. CatOS release 7.1 en laat later nog steeds de luister- en leertoestand zien. Dit geeft zelfs meer informatie over een poort dan de standaard IEEE vereist. Het nieuwe kenmerk is echter dat er nu een verschil is tussen de rol die het protocol bepaalt voor een haven en de huidige staat. Het is nu bijvoorbeeld volkomen geldig dat een haven tegelijkertijd wordt aangewezen en geblokkeerd. Hoewel dit doorgaans voor zeer korte perioden gebeurt, betekent dit eenvoudigweg dat deze haven in een tijdelijke staat is naar de aangewezen staat van verzending.

Nieuwe BPDU-indeling

Er zijn weinig wijzigingen door RSTP in de BPDU-indeling geïntroduceerd. Slechts twee vlaggen, Topology Change (TC) en TC Recognition (TCA), worden gedefinieerd in 802.1D. RSTP gebruikt echter nu alle zes bits van de vlaggenbyte die nog aanwezig zijn om te voldoen:

• De rol en de status van de poort die aan de BPDU is begonnen, coderen

• Aanpakken van het voorstel/akkoord

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

Zie Cisco BPDU-, IEEE BPDU- en BPDU-diagrammen voor een hoger resolutie.

Opmerking: bit 0 (Topologie Change) is het minst significante bit.

Een andere belangrijke verandering is dat de RSTP BPDU nu van type 2 is, versie 2. De implicatie is dat oudere bruggen deze nieuwe BPDU moeten laten vallen. Dit bezit maakt het voor een 802.1w brug gemakkelijk om erfenis bruggen te detecteren die ermee verbonden zijn.

Nieuwe BPDU-verwerking

BPDU wordt elke Hallo-tijd verzonden

BPDU wordt elke gedag verstuurd en niet simpelweg meer relaxed. Met 802.1D genereert een niet-root-brug alleen BPDU’s als deze op de basispoort worden ontvangen. Een brug geeft BPDU's meer terug dan ze zelf genereert. Dit is niet het geval bij 802.1w. Een brug stuurt nu een BPDU met zijn huidige informatie elke <hallo-tijd> seconden (2 standaard), zelfs als er geen van de root-brug ontvangen wordt.

Snellere informatievergaring

Op een bepaalde poort, als hellos niet drie opeenvolgende keren ontvangen worden, kan de protocolinformatie onmiddellijk verouderd worden (of als max_age vervalt). Vanwege de eerder genoemde protocolwijziging worden BPDU's nu gebruikt als een houdbaar mechanisme tussen bruggen. Een brug is van mening dat zij connectiviteit aan zijn directe buurwortel of aangewezen brug verliest als zij drie BPDU's in een rij mist. Deze snelle veroudering van de informatie maakt een snelle detectie van storingen mogelijk. Als een brug er niet in slaagt BPDU's van een buur te ontvangen, is het zeker dat de verbinding met die buur verloren is. Dit is in tegenstelling tot 802.1D, waar het probleem overal op het pad naar de wortel zou kunnen zijn geweest.

Opmerking: Fouten worden zelfs veel sneller gedetecteerd in geval van fysieke verbindingsfouten.

Inferieure BPDU’s aanvaarden

Dit concept vormt de kern van de backboneFast-motor. Het IEEE 802.1w-comité heeft besloten een soortgelijk mechanisme in RSTP te integreren. Wanneer een brug inferieure informatie van zijn aangewezen of root-brug ontvangt, aanvaardt hij deze onmiddellijk en vervangt hij de eerder opgeslagen informatie.

Omdat Bridge C nog steeds weet dat de wortel nog leeft en goed is, stuurt het direct een BPDU naar Bridge B, die informatie over de root-brug bevat. Als resultaat hiervan stuurt Bridge B geen eigen BPDU's en accepteert hij de poort die naar Bridge C leidt als de nieuwe wortelpoort.

Snelle overgang naar doorvoerstaat

Snelle overgang is het belangrijkste kenmerk dat tegen 802.1w is geïntroduceerd. De nalatenschap STA wachtte passief tot het netwerk samenkwam voordat het een poort in de verzendende staat veranderde. Het behalen van een snellere convergentie was een kwestie van het aanpassen van de conservatieve standaardparameters (vooruit- en max_age timers) en bracht vaak de stabiliteit van het netwerk op het spel. De nieuwe snelle STP kan actief bevestigen dat een poort veilig naar de staat van het verzenden kan overgaan zonder op om het even welke klokconfiguratie te hoeven vertrouwen. Er bestaat nu een echt feedbackmechanisme dat tussen bruggen die aan RSTP voldoen plaatsvindt. Om een snelle convergentie van een haven te bereiken, is het protocol gebaseerd op twee nieuwe variabelen: randpoorten en link type.

Edge-poorten

Het begrip randpoort is al bekend bij Cisco die drie gebruikers overspant, omdat het in feite overeenkomt met de functie PortFast. Alle poorten die rechtstreeks zijn aangesloten op eindstations kunnen geen overbruggingslijnen in het netwerk maken. Daarom gaat de rand poort rechtstreeks over naar de verzendende staat, en slaat de luisterfase en de leerfasen over. Geen randpoorten of PortFast enabled-poorten genereren topologie wanneer de link verandert. Een randpoort die een BPDU ontvangt verliest direct de status van de randpoort en wordt een normale omspant boompoort. Op dit punt is er een door de gebruiker ingestelde waarde en een operationele waarde voor de status van de randpoort. De implementatie van Cisco blijft dat het sleutelwoord PortFast voor de configuratie van de randpoort wordt gebruikt. Dit maakt de overgang naar RSTP eenvoudiger.

Type link

RSTP kan alleen een snelle overgang naar de verzendende staat op randpoorten en op point-to-point links realiseren. Het type link wordt automatisch afgeleid van 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 gezien wordt als een gedeelde poort. Deze automatische instelling voor link type kan door een expliciete configuratie worden overbrugd. In geschakelde netwerken werken de meeste links momenteel in full-duplex modus en worden behandeld als point-to-point links door RSTP. Dit maakt hen kandidaten voor een snelle overgang naar de verzendende staat.

Convergentie met 802.1D

Dit diagram illustreert hoe 802.1D zich bezighoudt met een nieuwe link die aan een samengevoegd netwerk wordt toegevoegd:

In dit scenario wordt een link tussen de root-brug en Bridge A toegevoegd. Stel dat er al een indirecte verbinding is tussen Bridge A en de root-brug (via C - D in het diagram). De STA blokkeert een poort en blokkeert de overbruggingslus. Eerst worden beide poorten op het verband tussen de wortel en Bridge A in de luisterstaat gezet. Bridge A is nu in staat de wortel direct te horen. Het verspreidt zijn BPDU's onmiddellijk in de aangewezen havens, naar de bladeren van de boom. Zodra de bruggen B en C deze nieuwe superieure informatie van Bridge A ontvangen, geven zij de informatie onmiddellijk door aan de bladeren. In een paar seconden ontvangt Bridge D een BPDU uit de wortel en blokkeert direct poort P1.

Spanning Tree is zeer efficiënt in de manier waarop het de nieuwe topologie van het netwerk berekent. Het enige probleem is dat twee keer de voorwaartse vertraging moet verlopen voordat het verband tussen de wortel en Bridge A uiteindelijk in de verzendende staat eindigt. Dit betekent 30 seconden verstoring van het verkeer (het gehele A-, B- en C-gedeelte van het netwerk is geïsoleerd) omdat het 8021.D-algoritme geen feedback-mechanisme heeft om duidelijk aan te geven dat het netwerk in een paar seconden samenvalt.

Convergentie met 802.1w

Nu kun je zien hoe RSTP met een zelfde situatie omgaat. Onthoud dat de uiteindelijke topologie precies hetzelfde is als degene die door 802.1D (dat wil zeggen, één geblokkeerde poort op dezelfde plaats als voorheen) is berekend. Alleen de stappen die worden gebruikt om deze topologie te bereiken zijn veranderd.

Beide havens op de verbinding tussen A en de wortel worden geplaatst in aangewezen blokkades zodra zij naar voren komen. Tot nu toe gedraagt alles zich als een pure 802.1D omgeving. In dit stadium vindt echter een onderhandeling plaats tussen Switch A en de wortel. Zodra A de BPDU van de wortel ontvangt, blokkeert het de aangewezen havens die niet aan de rand zijn toegewezen. Deze handeling wordt sync genoemd. Zodra dit gebeurt, machtigt Bridge A de root-brug expliciet om haar haven in de staat van verzending 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-gegrensde aangewezen havens blokkeert, wordt het verband tussen Switch A en de wortel in de verzendende staat gelegd en bereikt u de situatie:

Er kan nog steeds geen sprake zijn van een lus. In plaats van boven Switch A te blokkeren, blokkeert het netwerk nu onder Switch A. Op een andere locatie wordt echter het potentiële overbruggingslus gesneden. Deze snede reist door de boom samen met de nieuwe BPDU's die door de wortel zijn ontstaan door Switch A. In dit stadium onderhandelen de nieuw geblokkeerde havens op Switch A ook over een snelle overgang naar de verzendende staat met hun buurhavens op Switch B en Switch C die beiden een sync-handeling initiëren. Afgezien van de wortelhaven naar A, heeft Switch B alleen grensaangewezen havens. Daarom heeft zij geen haven om te blokkeren om Switch A toestemming te geven naar de verzendende staat te gaan. Op dezelfde manier hoeft Switch C zijn aangewezen haven alleen te blokkeren naar D. De in dit schema weergegeven staat is nu bereikt:

Vergeet niet dat de uiteindelijke topologie precies hetzelfde is als het voorbeeld 802.1D, wat betekent dat poort P1 op D blokkeert. Dit betekent dat de uiteindelijke netwerktopologie wordt bereikt, net in de tijd die nodig is voor de nieuwe BPDU's om door de boom te reizen. Geen timer is betrokken bij deze snelle convergentie. Het enige nieuwe mechanisme dat door RSTP wordt geïntroduceerd is de erkenning dat een switch zijn nieuwe wortelhaven kan verzenden om onmiddellijke overgang naar de expediteurstaat toe te staan, en voorbij de tweemaal-de-de-de-vooruit-vertraging lange het luisteren en het leren fasen. De beheerder hoeft deze alleen te onthouden om te profiteren van een snelle convergentie:

• Deze onderhandeling tussen bruggen is alleen mogelijk wanneer bruggen worden 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 B niet correct aanpast, wordt hun connectiviteit beïnvloed door de link tussen A en de wortel die omhoog komt.

Samenvatting van voorstel/overeenkomst

Wanneer een poort door STA is geselecteerd om een aangewezen poort te worden, wacht 802.1D nog steeds twee <voorwaartse vertraging> seconden (2x15 standaard) voordat deze naar de verzendstaat overgaat. In RSTP komt deze voorwaarde overeen met een haven met een aangewezen rol maar een blokkerende staat. Deze diagrammen illustreren hoe snel een overgang stap voor stap tot stand komt. Stel dat er een nieuwe link wordt gecreëerd tussen de wortel en Switch A. Beide poorten op deze link worden in een aangewezen blokkerende status gezet totdat ze een BPDU van hun tegenhanger ontvangen.

Wanneer een aangewezen haven zich in een teruggooi- of leertoestand bevindt (en alleen in dit geval), wordt het voorstel op de BPDU's die het verstuurt, gezakt. Dit is wat voor haven p0 van de root-brug gebeurt, zoals getoond in stap 1 van het bovenstaande schema. Omdat Switch A superieure informatie ontvangt, weet het onmiddellijk dat p1 de nieuwe wortelhaven is. Switch A start vervolgens een sync om te controleren of al zijn poorten asynchrone zijn met deze nieuwe informatie. Een poort is in sync als het aan een van deze criteria voldoet:

• De haven bevindt zich in de blokkerende staat, wat betekent het weggooien in een stabiele topologie.

• De haven is een randhaven.

Om het effect van het sync-mechanisme op verschillende soorten havens te illustreren, bestaat er een alternatieve poort p2, een aangewezen expeditehaven p3, en een randpoort p4 op Switch A. Merk op dat p2 en p4 reeds aan één van de criteria voldoen. Om in sync te zijn (zie stap 2 van het bovenstaande diagram) moet Switch A gewoon poort p3 blokkeren, en deze de afvoerstatus toewijzen. Nu al zijn poorten asynchrone zijn, kan Switch A zijn nieuw geselecteerde basispoort p1 deblokkeren en een overeenkomstenbericht verzenden om naar de wortel te reageren. (zie stap 3). Dit bericht is een kopie van het BPDU-voorstel, waarbij het akkoord in plaats van het voorstel-bit is ingesteld. Dit zorgt ervoor dat de haven p0 precies weet op welk voorstel de overeenkomst die zij ontvangt, betrekking heeft.

Zodra p0 deze overeenkomst ontvangt, kan zij onmiddellijk overgaan naar de verzendende staat. Dit is stap 4 van het vorige cijfer. Merk op dat poort p3 achterblijft in een aangewezen uitwerpstatus na de sync. In stap 4 bevindt deze haven zich in precies dezelfde situatie als de haven p0 zich in stap 1. Daarna begint de haven zijn buurland voor te stellen en probeert hij snel over te stappen naar de verzendende staat.

• Het mechanisme van de ontwerpovereenkomst is zeer snel, aangezien het niet op een bepaald tijdstip berust. Deze golf van handschokken verspreidt zich snel naar de rand van het netwerk en herstelt snel connectiviteit na een verandering in de topologie.

• Indien een aangewezen teruggooihaven geen overeenkomst ontvangt nadat het een voorstel heeft verstuurd, gaat het langzaam over naar de staat van verzending en valt het terug naar de traditionele 802.1D-luisterleersequentie. Dit kan voorkomen als de afstandsbrug RSTP BPDU's niet begrijpt of als de poort van de afstandsbrug blokkeert.

• Cisco introduceerde een verbetering aan het sync-mechanisme dat een brug toestaat om alleen zijn voormalige wortelpoort in de teruggooistaat te zetten wanneer het syncs. Nadere gegevens over de werking van dit mechanisme vallen buiten het toepassingsgebied van dit document. Men kan er echter wel vanuit gaan dat dit in de meeste gewone gevallen van convergentie wordt toegepast. Het scenario dat in het gedeelte Convergentie met vak 802.1w van dit document wordt beschreven, wordt zeer efficiënt, aangezien alleen de poorten op het pad naar de laatste geblokkeerde poort tijdelijk in verwarring worden gebracht.

UplinkFast

Een andere vorm van onmiddellijke overgang naar de door:sturen staat in RSTP is gelijkaardig aan de Cisco UplinkFast eigen die drie uitbreiding overspant. Basit, wanneer een brug zijn wortelhaven verliest, kan het zijn beste afwisselende haven rechtstreeks in de expedentiatiemodus zetten (de verschijning van een nieuwe wortelhaven wordt ook door RSTP behandeld). De selectie van een alternatieve poort als de nieuwe wortelpoort genereert een topologie-verandering. Het 802.1w-mechanisme voor topologie maakt de juiste ingangen in de tabellen Content Adresseerbare Geheugen (CAM) van de upstream bridge vrij. Dit verwijdert de noodzaak van het dummy multicast generatieproces van UplinkFast.

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

Nieuwe mechanismen voor topologische verandering

Wanneer een 802.1D brug een topologie verandering detecteert, gebruikt het een betrouwbaar mechanisme om eerst de root-brug op de hoogte te stellen. Dit wordt in dit schema getoond:

Zodra de root-brug op de hoogte is van een verandering in de topologie van het netwerk, stelt zij de TC-vlag in op de BPDU's die zij verstuurt, die dan worden doorgegeven aan alle bruggen in het netwerk. Wanneer een brug een BPDU ontvangt met het TC vlaggenbit dat wordt ingesteld, vermindert zij de verouderingstijd van de overbruggingstabel tot voorwaartse vertragingsseconden. Dit waarborgt een relatief snelle doorspoeling van stabiele informatie. Raadpleeg het gedeelte Spanning-Tree Protocol voor meer informatie over dit proces. Dit mechanisme voor topologie-verandering is diep van elkaar verwijderd in RSTP. Zowel de detectie van een topologie verandering als de propagatie ervan door het netwerk evolueren.

Detectie van wijziging van topologie

In RSTP, veroorzaken alleen niet-randpoorten die naar de staat van het verzenden bewegen een topologie verandering. Dit betekent dat een verlies van connectiviteit niet meer als een topologie verandering wordt beschouwd, in tegenstelling tot 802.1D (dat wil zeggen, een haven die zich aan blokkering beweegt genereert niet meer een TC). Wanneer een brug van RSTP een topologie ontdekt, komen deze voor:

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

• Het ontwricht de MAC adressen geassocieerd met al deze havens.

Opmerking: Zolang de TC Terwijl timer op een poort loopt, hebben de BPDU's die uit die poort worden verstuurd het TC bit set. BPDU’s worden ook op de wortelpoort verzonden terwijl de timer actief is.

doorgifte van topologie-verandering

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

• Het ontruimt de MAC adressen die op al zijn havens worden geleerd, behalve degene die de topologie verandering ontvangt.

• De zender start de TC-timer en stuurt BPDU's met een TC die op al zijn aangewezen poorten en wortelpoort is ingesteld (RSTP gebruikt niet langer de specifieke TCN BPDU, tenzij een bestaande brug moet worden aangemeld).

Zo overspoelt de TCN snel over het hele netwerk heen. De TC-propagatie is nu een eenstapsproces. In feite verandert de initiatiefnemer van de topologie deze informatie door het netwerk, in tegenstelling tot 802.1D waar slechts de wortel deed. Dit mechanisme is veel sneller dan het 802.1D-equivalent. Er is geen behoefte om te wachten tot de root-brug wordt gemeld en dan de status van de topologie voor het gehele netwerk te bewaren voor <max pagina plus voorwaartse vertraging> seconden.

In slechts een paar seconden, of een klein aantal hallo-tijden, stromen de meeste ingangen in de CAM tabellen van het volledige netwerk (VLAN) door. Deze benadering resulteert in potentieel meer tijdelijke overstroming, maar aan de andere kant maakt het potentiële stabiele informatie vrij die snelle restitutie van connectiviteit verhindert.

Compatibiliteit met 802.1D

RSTP kan samenwerken met bestaande STP-protocollen. Het is echter belangrijk op te merken dat de inherente snelle convergentievoordelen van 802.1w verloren gaan als het interageert met bestaande bruggen.

Elke poort handhaaft een variabele die het protocol definieert om op het corresponderende segment te lopen. Een uitwijktimer voor de migratie van drie seconden start ook wanneer de poort wordt geopend. Wanneer deze timer draait, wordt de huidige STP- of RSTP-modus die aan de poort is gekoppeld, vergrendeld. Zodra het migratietempo is verlopen, past de poort zich aan in de modus die overeenkomt met de volgende BPDU die het ontvangt. Als de poort zijn werkwijze wijzigt als gevolg van een ontvangen BPDU, dan start de migratiedrempel opnieuw. Dit beperkt de mogelijke frequentie voor wijziging van de modus.

Stel bijvoorbeeld bruggen A en B in het bovenstaande cijfer in, dan draaien beide RSTP, waarbij Switch A is aangewezen voor het segment. Een bestaande STP Bridge C is aan deze link toegevoegd. Aangezien 802.1D-bruggen BPDU's van RSTP negeren en deze laten vallen, gelooft C dat er geen andere bruggen op het segment zijn en stuurt hij zijn inferieure BPDU's van 802.1D-formaat aan. Switch A ontvangt deze BPDU's en verandert, na tweemaal hallo-tijd seconden maximum, zijn modus in 802.1D op die poort. Als resultaat hiervan begrijpt C nu de BPDU's van Switch A en aanvaardt A als de aangewezen brug voor dat segment.

Opmerking in dit specifieke geval, als Bridge C is verwijderd, draait Bridge A in STP-modus op die poort, ook al kan het efficiënter werken in RSTP-modus met zijn unieke buurman B. Dit komt doordat A Bridge C niet kent uit het segment is verwijderd. Voor dit specifieke (zeldzame) geval is gebruikersinterventie vereist om de protocoldetectie van de haven handmatig te hervatten.

Wanneer een poort zich in 802.1D compatibiliteitsmodus bevindt, kan het ook BPDU's (TCN's) en BPDU's met een TC- of TCA-bit set verwerken.

Conclusie

RSTP (IEEE 802.1w) omvat als alternatief de meeste eigen verbeteringen van Cisco aan de 802.1D die boom, zoals BackboneFast, UplinkFast en PortFast overspannen. RSTP kan een veel snellere convergentie bereiken in een goed geconfigureerd netwerk, soms in de orde van enkele honderden milliseconden. Classic 802.1D-timers, zoals voorwaartse vertraging en max_age, worden alleen als back-up gebruikt en zijn niet nodig indien point-to-point links en randpoorten correct zijn geïdentificeerd en door de beheerder zijn ingesteld. De timers zouden ook niet nodig moeten zijn als er geen interactie is met bestaande bruggen.

Gerelateerde informatie

• MST (802.1s)/RSTP (802.1w) configureren op Catalyst 9000 Series Switches die CatOS uitvoeren
• De functies van Cisco uplinks begrijpen en configureren
• Ondersteuning voor LAN-switching technologie
• LAN-productondersteuning
• Tools en bronnen
• Technische ondersteuning en documentatie – Cisco Systems