Onderken en instellen van backbone Fast op Catalyst-Switches

Inleiding

Dit document beschrijft hoe u snel de backbone kunt configureren. Backbone Fast is een bedrijfseigen functie van Cisco die, zodra deze is ingeschakeld op alle switches van een brugnetwerk, een switch tot 20 seconden (max_age) kan opslaan wanneer deze zich herstelt van een indirecte storing van de link. Na een snel onderzoek van wat Spanning-Tree Protocol (STP) basisgegevens, kunt u het exacte mislukkingsscenario zien waarop backbone snel van toepassing is en hoe u deze instelt voor Catalyst switches die zowel CatOS- als Cisco IOS^® software uitvoeren.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• Catalyst 2950 Series Switches die Cisco IOS-softwarerelease 12.1(6)EA2 en hoger uitvoeren

• Catalyst 3550 Series Switches die Cisco IOS-softwarerelease 12.1(4)EA1 en hoger uitvoeren

• Catalyst 4000 Series Switches die CatOS 5.1(1a) en hoger uitvoeren

• Catalyst 4500/4000 Series Switches die Cisco IOS-softwarerelease 12.1(8a)EW en hoger uitvoeren

• Catalyst 5500/5000 Series Switches die CatOS versie 4.1(1) en hoger uitvoeren

• Catalyst 6500/6000 Series Switches die CatOS versie 5.1(1)CSX en hoger uitvoeren

• Catalyst 6500/6000 Series switches die Cisco IOS-softwarerelease 12.0-7XE en hoger uitvoeren

BPDU’s en hoe ze te vergelijken

Bridge Protocol Data Units (BPDU's) kunnen strikt worden geclassificeerd door de velden die ze dragen. Tot deze velden behoren de root-brug-ID, de padkosten naar de wortel en de verzendbridge-ID. Een BPDU wordt om deze redenen beter geacht dan een andere BDPU:

• Wanneer een BPDU een beter root-brug-ID heeft dan een ander. Hoe lager de waarde, hoe beter.

• Als de root-brug-ID-waarden gelijk zijn, is de BPDU met de laagste padkosten voor de wortel beter.

• Als de root-brug-ID-waarden gelijk zijn en de kosten voor de wortel gelijk zijn, is de BPDU met de betere verzendbridge-ID beter. Hoe lager de waarde, hoe beter.

Er zijn andere variabelen die dan kunnen fungeren als een das-breker. Hoe beter een BPDU, hoe beter de toegang tot de beste root-brug.

Een brug die een BPDU op een haven beter ontvangt dan degene die zij verstuurt, zet deze haven in blokkerende modus tenzij het zijn wortelhaven is. Dit betekent dat er in het segment dat aangesloten is op deze haven, een andere brug is die een aangewezen brug is. Een brug slaat de waarde van de BPDU op een haven die door de huidige aangewezen brug wordt verstuurd.

Hoe STP van een indirect Link-fout herstelt

Dit illustreert hoe STP zich gedraagt wanneer het moet herberekenen na een storing van een indirecte verbinding, dat wil zeggen wanneer een brug de status van een aantal van zijn havens moet wijzigen vanwege een storing op een verbinding die er niet direct aan is gekoppeld.

Neem dit diagram, dat drie switches R, B, en S in een volledig gemaderde topologie omvat. Stel dat R de root-brug is en B de back-up root-brug. S blokkeert zijn poort P en B is de aangewezen brug voor link L3.

1. Als link L1 naar beneden gaat, detecteert switch B onmiddellijk de storing en gaat ervan uit dat de oorzaak is. Het stuurt BPDU's naar VS en beweert de nieuwe wortel te zijn.

2. Wanneer S deze nieuwe BPDU van B ontvangt, realiseert het zich dat deze inferieur is aan de BPDU die opgeslagen was voor port P en negeert het.

3. Nadat de timer max_age vervalt (20 seconden standaard), wordt de BPDU opgeslagen op S voor poort P pagina's buiten. De haven gaat onmiddellijk naar het luisteren en S begint zijn betere BPDU naar B te sturen.

4. Zodra B de BPDU van S ontvangt, stopt het met het verzenden van zijn BPDU.

5. Poort P beweegt naar de expedentierende staat door luisterstaat en leerstaten. Dit duurt twee keer de fw_vertragingswaarde, en nog eens 30 seconden. De volledige connectiviteit wordt dan hersteld.

Het duurde de max_age waarde (20 seconden) plus tweemaal de fw_vertragingswaarde (2x15 seconden) om te herstellen van deze indirecte link storing. Dit is 50 seconden met de standaardparameters. De backbone fast optie om max_age (20 seconden) op te slaan. Om dit te doen, komt het uit onmiddellijk nadat de haven inferieure BPDU's ontvangt.

Verbeteringen in backbone Fast naar standaard STP

Met het vorige voorbeeld, maakt STP informatie ongeldig die verkeerd wordt wegens een indirecte verbindingsmislukking. Om dit te doen wacht het passief op max_age. Om deze max_age vertraging weg te krijgen, voert backbone snel twee verbeteringen in:

• Het vermogen om een indirecte link zo snel mogelijk op te sporen. Dit wordt bereikt door de inferieure BPDU's te volgen die een aangewezen brug verstuurt wanneer zij een directe link defect ervaart.

• Een mechanisme dat een controle onmiddellijk mogelijk maakt of de BPDU-informatie die op een haven is opgeslagen, nog steeds geldig is. Dit wordt geïmplementeerd met een nieuwe protocol gegevenseenheid (PDU) en de Root Link Query, die in dit document worden aangeduid als de RLQ PDU.

Indirect-koppelingsfouten detecteren

Als een inferieure BPDU op een haven van onze aangewezen brug wordt ontvangen, dan is deze brug de wortel kwijtgeraakt en begint een wortel te adverteren met een hogere bridge-ID, een erger wortel dan de onze.

Het gebruikelijke gedrag wat betreft de specificaties van het Institute of Electrical and Electronics Engineers (IEEE) is om inferieure BPDU’s eenvoudigweg te negeren. Backbone gebruikt ze snel omdat zodra er een is ontvangen, het zeker is dat er een mislukking is opgetreden op het pad naar de wortel en dat u ten minste één poort moet verlaten.

Opmerking: Een indirecte verbindingsmislukking kan gebeuren zonder enige inferieure BPDU-generatie in het netwerk. U kunt in het vorige diagram een hub toevoegen:

De fout van de verbinding komt voor tussen root-brug R en de hub. B detecteert niet dat de link omlaag gaat en wacht max_age af voordat de nieuwe wortel wordt geclaimd. Onthoud dat het mechanisme alleen werkt als een brug een directe verbindingsfout detecteert.

Alleen bijhouden van inferieure BPDU's die door de aangewezen brug worden verstuurd. Aangezien dit de BPDU is die op de haven wordt opgeslagen. Als, bijvoorbeeld, een nieuw ingesloten brug inferieur BPDU begint te verzenden, start het de backbone fast-optie niet.

Reageren op fouten in indirecte link

Wanneer een inferieure BPDU op een niet-aangewezen poort wordt gedetecteerd, wordt de tweede fase van backbone fast geactiveerd. In plaats van passief te wachten max_age om poorten te verouderen die door de mislukking kunnen worden beïnvloed, wordt er een proactieve manier om ze onmiddellijk te testen geïntroduceerd door middel van de RLQ PDU. RLQ wordt gebruikt om een type ping voor de wortel op een niet aangewezen haven te bereiken en toegestaan om snel te bevestigen of de BPDU die op een haven is opgeslagen nog geldig is of moet worden weggegooid.

Wanneer u een inferieure BPDU van een aangewezen brug ontvangt, stuurt u een RLQ PDU op alle niet-aangewezen poorten behalve de haven waar u de inferieure BPDU en de zelflooppoorten hebt ontvangen. Dit om te controleren dat u nog steeds van de wortel op havens hoort waar u aan het ontvangen BPDU's wordt gebruikt. De haven waar u de inferieure BPDU heeft ontvangen, is uitgesloten omdat u zich al bewust bent van het feit dat het heeft geleden onder een mislukking, dat de eigenstroom en de aangewezen havens niet nuttig zijn, omdat zij niet tot de wortel leiden.

Na ontvangst van een reactie van RLQ op een haven, als het antwoord negatief is, verloor de haven verbinding aan de wortel en kunt u zijn BPDU verouderen. Bovendien, als alle andere niet-aangewezen havens al een negatief antwoord ontvingen, verliest de hele brug de wortel en kan de STP berekening vanaf nul starten.

Als het antwoord bevestigt dat je nog steeds toegang tot de root-brug kunt krijgen via deze haven, dan kun je onmiddellijk de haven verruimen waarop we de inferieure BPDU hebben ontvangen.

In dit voorbeeld zijn havens A, B, D, en E niet aangewezen havens voor switch S. A de wortelhaven en de anderen blokkeren. Wanneer E een inferieure BPDU (1) ontvangt, schakelt backbone snel in om STP-herberekening te versnellen.

Verzend een RLQ verzoek, dat op alle niet-aangewezen havens maar E (2) op wortel R zoekt. In de antwoorden wordt aangegeven welke wortel via deze havens toegankelijk is. De RLQ-respons die D ontvangt, geeft aan dat D zijn pad naar de wortel R. Age zijn BPDU onmiddellijk kwijt is (3). De poorten A en B krijgen bevestiging dat zij nog steeds een weg naar R (4) hebben. Dus, aangezien switch S nog steeds connectiviteit heeft aan de wortel, verwijder onmiddellijk haven E en ga door met regelmatige STP regels (5).

In een geval waar de switch alleen reacties heeft ontvangen met een wortel anders dan R, neem de wortel als verloren aan en herstart de STP-berekening direct vanaf nul. Merk op dat dit geval ook voorkomt wanneer de enige niet-aangewezen (en niet-zelflooped) haven op de brug de wortelhaven is en u een inferieure BPDU op deze haven ontvangt.

De Root Link Query PDU

De twee vormen van RLQ's zijn RLQ-verzoeken en RLQ-antwoorden.

Het RLQ- verzoek wordt verzonden op een haven waar u gewoonlijk BPDU's ontvangt, om te controleren dat u nog connectiviteit aan de wortel door deze haven hebt. Specificeer in het verzoek welke brug uw wortel is en de reactie van RLQ uiteindelijk met een root-brug terug die door deze haven kan worden benaderd. Als de twee wortels hetzelfde zijn, leeft de connectiviteit nog, anders, is het verloren.

Een brug die een RLQ vraag ontvangt antwoordt onmiddellijk als zij weet dat het verbinding met de gevraagde wortel heeft verloren omdat het een andere root-brug heeft dan die gespecificeerd in de RLQ query, en als het de wortel is.

Als dit niet het geval is, dan zendt het de vraag naar de wortel door zijn wortelhaven door.

RLQ-reacties zijn overstroomd op aangewezen poorten. De zender van het RLQ-verzoek plaatst zijn bridge-ID in de PDU. Dit om ervoor te zorgen dat wanneer het een antwoord op zijn eigen vraag ontvangt, het antwoord niet in zijn aangewezen havens terechtkomt.

De RLQ PDU heeft dezelfde pakketstructuur als een normale STP-BPDU. Het enige verschil is dat twee verschillende Cisco-specifieke SNAP-adressen worden gebruikt: één voor het verzoek en één voor het antwoord.

Dit is het standaard BPDU-formaat:

DA	SA	Lengte	DSAP	SSAP	CNTL	SNAP	PDU

Het PDF-veld is:

Protocolidentificatie	Versie	Berichttype	Vlaggen	Root-ID	Root Path-kosten
Zender-ID	PoortID	Berichtenpagina	Max. pagina	Hallo tijd	Voorgaande vertraging

Het berichttype dat in de PDU wordt gebruikt, verschilt ook van de standaard BPDU.

De enige velden die gebruikt worden, zijn de wortel ID en de verzendbridge-ID.

Deze Cisco-specifieke optie moet op alle switches in het netwerk worden geconfigureerd om deze PDU’s te kunnen verwerken.

Voorbeeld scenario met snelle optie voor backbone

Dit scenario is gebaseerd op het eerste voorbeeld, maar deze keer met backbone die snel werd geactiveerd op de drie switches.

1. De eerste fase is precies dezelfde als eerder is uitgelegd.

2. Zodra S de inferieure BPDU van B ontvangt, begint het zijn niet-aangewezen poorten te herbevestigen in plaats van max_age te wachten. Het stuurt een RLQ query naar de wortelpoort voor root-brug R.

3. Root-brug R ontvangt de query en geeft direct antwoord met een RLQ-respons die aangeeft dat er nog steeds een wortel R in die richting is.

4. We hebben nu alle niet-aangewezen havens gecontroleerd, en het heeft nog steeds verbinding met de wortel. Het kan dan onmiddellijk de informatie verouderen die opgeslagen is op port P. P transities naar het luisteren en begint BPDU's te verzenden. In dat stadium hebt u reeds max_age seconden opgeslagen, en is de standaard Spanning-Tree Algorithm (STA) dan van toepassing.

5. B ontvangt de betere BPDU van S (R betere wortel dan B) en beschouwt nu de havens die tot L3 leiden als zijn wortelhaven.

Backbone Fast configureren voor CatOS en Cisco IOS

Wanneer gebruikt, moet backbone fast op alle switches in het netwerk worden geactiveerd omdat backbone fast het gebruik van het RLQ- verzoek en -antwoordmechanisme vereist om switches van root path stabiliteit te informeren. Het RLQ-protocol is alleen actief wanneer backbone fast op een switch is ingeschakeld. Bovendien kan het netwerk ook problemen met de overstroming van RLQ ondervinden als backbone fast niet op alle switches is ingeschakeld. De standaardinstelling is dat backbone fast wordt uitgeschakeld.

Backbone fast wordt niet ondersteund op Catalyst 2900XL en 3500XL switches. In het algemeen, moet u backbone snel inschakelen als het switch domein deze switches bevat naast andere Catalyst switches. Wanneer u backbone fast implementeert in omgevingen met XL switches, onder strikte topologieën, kunt u de eigenschap inschakelen waar de XL switch de laatste switch in lijn is en alleen op twee plaatsen is verbonden met de kern. Voer deze optie niet uit als de XL-switches in een dagelijkse keten zijn opgebouwd.

U hoeft geen backbone snel te configureren met RSTP of IEEE 802.1w, omdat het mechanisme automatisch in RSTP is opgenomen en automatisch ingeschakeld. Raadpleeg voor meer informatie over RSTP of IEEE 802.1w Spanning Tree van PVST+ naar Rapid-PVST migratievoorbeeld.

Configuratie voor CatOS

Voor Catalyst 4000, 5000 en 6000 Series switches die CatOS in werking stellen, gebruik deze opdrachten om backbone snel en wereldwijd voor alle poorten mogelijk te maken en de configuratie te verifiëren.

Console> (enable) set spantree backbonefast enable
Backbonefast enabled for all VLANs
Console> (enable) show spantree backbonefast 

! This command show that the backbonefast feature is enabled.

Backbonefast is enabled.
Console> (enable)

Zo geeft u backbone snelle statistieken weer:

Console> (enable) show spantree summary
Summary of connected spanning tree ports by vlan
Uplinkfast disabled for bridge.
Backbonefast enabled for bridge.  
Vlan  Blocking Listening Learning Forwarding STP Active
----- -------- --------- -------- ---------- ----------
 1      0        0          0         1         1

      Blocking Listening Learning Forwarding STP Active
----- -------- --------- -------- ---------- ----------
Total   0        0         0        1           1

BackboneFast statistics 

! The show spantree summary command displays all backbonefast statistics.

-----------------------
Number of inferior BPDUs received (all VLANs): 0
Number of RLQ req PDUs received (all VLANs): 0
Number of RLQ res PDUs received (all VLANs): 0
Number of RLQ req PDUs transmitted (all VLANs): 0
Number of RLQ res PDUs transmitted (all VLANs): 0    
Console> (enable)

Configuratie voor Cisco IOS

Voor Catalyst switches die met Cisco IOS software lopen, gebruik deze opdrachten om backbone snel mondiaal voor alle interfaces mogelijk te maken.

CAT-IOS# configure terminal
CAT-IOS(config)# spanning-tree backbonefast
CAT-IOS(config)# end
CAT-IOS#

Om te verifiëren dat backbone fast is ingeschakeld en om statistieken te tonen:

CAT-IOS# show spanning-tree backbonefast

BackboneFast         is enabled

BackboneFast statistics
-----------------------
Number of transition via backboneFast (all VLANs)           : 0
Number of inferior BPDUs received (all VLANs)               : 0
Number of RLQ request PDUs received (all VLANs)             : 0
Number of RLQ response PDUs received (all VLANs)            : 0
Number of RLQ request PDUs sent (all VLANs)                 : 0
Number of RLQ response PDUs sent (all VLANs)                : 0
CAT-IOS#

Gerelateerde informatie

• Gebruik van PortFast en andere opdrachten voor het repareren van de connectiviteit van het werkstation
• De functies van Cisco UplinkFast begrijpen en configureren
• Verbeteringen in Spanning-Tree Protocol met Loop Guard en BPDU Skew Detectie-functies
• Verbetering in Spanning Tree Port Fast BPDU-bewaking
• Spanning Tree van PVST+ naar Rapid-PVST-migratieconversievoorbeeld
• Spanning Tree Protocol - Technologische ondersteuning
• Switches - productondersteuning
• LAN-switching - ondersteuning voor technologie
• Technische ondersteuning en documentatie – Cisco Systems