In dit document wordt beschreven hoe u storingen in Spanning Tree Protocol (STP) in overbrugde Cisco Catalyst-netwerken kunt oplossen en voorkomen.
Er zijn geen specifieke vereisten van toepassing op dit document.
Dit document richt zich op klassiek STP-gedrag en Cisco IOS Software-opdrachten.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Dit document bespreekt enkele van de veelvoorkomende redenen waarom STP kan mislukken en de informatie om de bron van het probleem te identificeren. Daarnaast wordt het type ontwerp beschreven dat Spanning Tree-gerelateerde problemen minimaliseert en eenvoudig te troubleshooten is.
In dit document wordt niet de basiswerking van STP beschreven. Raadpleeg het volgende document voor informatie over de werking van STP:
Dit document gaat niet in op Rapid STP (RSTP), gedefinieerd in IEEE 802.1w. Ook het MST-protocol (Multiple Spanning Tree) komt niet aan bod. Dit wordt gedefinieerd in IEEE 802.1s. Tenzij anders vermeld, zijn de timer- en convergentiebeschrijvingen in dit document van toepassing op klassiek IEEE 802.1D STP-gedrag.
Raadpleeg de volgende documenten voor meer informatie over RSTP en MST:
Raadpleeg voor een specifieker STP-document voor probleemoplossing voor Catalyst-switches waarop Cisco IOS-software wordt uitgevoerd, het document Stp-problemen oplossen op Catalyst-Switches .
Opmerking: in dit document worden oude STV-gegevens bewaard om basiskennis van het klassieke IEEE 802.1D-STP-gedrag te bieden. Klassieke STP wordt niet aanbevolen voor productieomgevingen. Gebruik voor productienetwerken een Layer 3-gerouteerd ontwerp waar praktisch en implementeer een nieuwer Spanning Tree-protocol of -modus, zoals Rapid Spanning Tree Protocol (RSTP), Rapid PVST+ of Multiple Spanning Tree (MST), op basis van platformondersteuning en netwerkontwerpvereisten
De primaire functie van de Spanning Tree-algoritme (STA) is het beëindigen van lussen die redundante links creëren in brugnetwerken. De STP werkt op laag 2 van het Open Systems Interconnection (OSI) model. Met behulp van Bridge Protocol Data Units (BPDU’s) tussen bruggen selecteert het STP de poorten die uiteindelijk verkeer doorsturen of blokkeren. Dit protocol kan in specifieke gevallen verkeerd verlopen en het troubleshooten van daardoor veroorzaakte problemen kan zeer lastig zijn, mede afhankelijk van de opzet van het netwerk. In dit specifieke gebied voert u het belangrijkste deel van het probleemoplossingsproces uit voordat het probleem zich voordoet.
Een STA-probleem resulteert doorgaans in een overbruggingslus. De meeste klanten die contact opnemen met Cisco Technical Support in verband met Spanning Tree-problemen vermoeden dat er sprake is van een bug, maar dat is zelden het geval. Zelfs als de software het probleem vormt, wordt een overbruggingslus in een STP-omgeving nog steeds veroorzaakt door een poort die verkeer kan blokkeren maar in plaats daarvan verkeer doorstuurt.
Raadpleeg de Spanning Tree-video waarin wordt getoond hoe de Spanning Tree in eerste instantie convergeert. Daarin wordt ook uitgelegd waarom bij een geblokkeerde poort de doorstuurmodus wordt geactiveerd als gevolg van overmatig verlies van BPDU’s, waardoor een STA-probleem optreedt.
Verder worden in dit document de verschillende situaties benoemd die tot STA-problemen kunnen leiden. De meeste van deze problemen zijn het gevolg van overmatig verlies van BPDU’s. Door dat verlies gaan geblokkeerde poorten van de blokkeringsmodus over naar de doorstuurmodus.
Duplex-mismatch op een point-to-point link is een zeer vaak voorkomende configuratiefout. Op oudere 10/100-Mbps Ethernet-koppelingen, als u de duplexmodus handmatig op Full aan de ene kant van de koppeling instelt en de andere kant in de automatische onderhandelingsmodus laat, eindigt de koppeling in half-duplex. (Een poort met de duplexmodus ingesteld op full-duplex onderhandelt niet meer.)

In het slechtste geval is bij een brug die BPDU’s verzendt de duplexmodus ingesteld op half-duplex op een poort, maar is deze ingesteld op full-duplex bij de peerpoort aan de andere kant van de link. In het vorige voorbeeld kan de duplex-mismatch van de link tussen brug A en B al snel resulteren in een overbruggingslus. Aangezien brug B is ingesteld op full-duplex vindt er geen carrier sense plaats voorafgaand aan linktoegang. Brug B stuurt frames ondanks dat brug A de link al gebruikt. Dit is een probleem voor brug A: deze detecteert een botsing en voert de uitstelalgoritme uit voordat de brug een volgende verzending van het frame uitvoert. Als er voldoende verkeer is van brug B naar brug A wordt elk pakket, inclusief de BPDU’s, dat door brug A wordt verzonden opgeschort, of er vindt een botsing plaats, en wordt uiteindelijk afgewezen. Vanuit STP-oogpunt: omdat brug B geen BPDU’s meer ontvangt van brug A, heeft brug B geen root-brug meer. Hierdoor deblokkeert brug B de poort die is verbonden met brug C, waardoor de lus ontstaat.
Wanneer er een duplex mismatch is, kan deze foutmelding worden gezien op de switch consoles van Catalyst switches die Cisco IOS Software draaien:
%CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet5/1 (not half duplex), with TBA05071417(Cat6K-B) 4/1 (half duplex).
Controleer de duplexinstellingen en stel de duplexconfiguratie opnieuw in als deze niet overeenkomt.
Raadpleeg voor meer informatie over het oplossen van een duplexmismatch het document Configure and Verify Ethernet 10/100/1000Mb Half/Full Duplex Auto-Negotiation (Configureren en verifiëren van Ethernet 10/1000Mb Half/Full Duplex automatische onderhandeling).
Unidirectionele links zijn een veelvoorkomende oorzaak van een overbruggingslus. Bij glasvezellinks resulteren niet-gedetecteerde fouten vaak in unidirectionele links. Een probleem met een transceiver vormt een andere oorzaak. Alles wat ertoe kan leiden dat een link actief blijft en eenrichtingscommunicatie mogelijk maakt is een groot STP-probleem. Dit voorbeeld maakt een en ander duidelijk:

Veronderstel dat er sprake is van een unidirectionele link tussen brug A en brug B. De link wijst verkeer van brug A naar brug B af maar verzendt wel verkeer van brug B naar brug A. Stel dat brug B blokkeerde voordat de link unidirectioneel werd. Een poort kan echter alleen verkeer blokkeren als deze BPDU’s ontvangt van een brug met een hogere prioriteit. Aangezien in dit voorbeeld alle BPDU’s afkomstig van brug A verloren gaan, geeft brug B uiteindelijk de poort naar brug A de doorstuurtoestand en stuurt verkeer door. Deze situatie leidt tot lusvorming. Als deze fout bij het opstarten aanwezig is, wordt het STP niet goed geconvergeerd. Als er sprake is van een duplex-mismatch kan opnieuw opstarten tijdelijk effect hebben. In dit voorbeeld heeft het opnieuw opstarten van de bruggen echter helemaal geen effect.
Om de unidirectionele link te detecteren voordat de doorstuurlus ontstaat, heeft Cisco het UDLD-protocol (UniDirectional Link Detection) ontwikkeld en geïmplementeerd. UDLD detecteert unidirectionele omstandigheden op ondersteunde Layer 2-koppelingen. Configureer de agressieve modus UDLD op ondersteunde point-to-point-koppelingen waarbij automatische uitschakeling van de poort vereist is na detectie van een unidirectionele toestand.
Voor meer informatie over het gebruik van UDLD raadpleegt u het document De UDLD-protocolfunctie configureren.
Beschadigde pakketten kunnen leiden tot hetzelfde probleem. Als een link veel fysieke fouten ondervindt, kan een aantal opeenvolgende BPDU’s verloren gaan. Dit verlies kan ertoe leiden dat een blokkerende poort overgaat naar de doorstuurtoestand. Dit komt niet vaak voor omdat de standaardparameters van STP zeer conservatief zijn. Met de klassieke IEEE 802.1D-standaardtimers kan een geblokkeerde poort ongeveer 50 seconden duren voordat de laatste superieure BPDU is uitgeschakeld om de doorstuurstatus te bereiken: 20 seconden maximale leeftijd, 15 seconden luisteren en 15 seconden leren. De verzending van één BPDU verbreekt al de lus. Een dergelijke situatie komt vaak voor als STP-parameters onzorgvuldig worden aangepast. Een voorbeeld van een aanpassing is verlaging van de parameter max age.
Duplex-mismatch, slechte kabels of onjuiste kabellengte kan leiden tot beschadigde pakketten. Raadpleeg het document Problemen met de Switch-poort en de interface oplossen voor een uitleg over de uitvoer van de foutteller van Cisco IOS-software.
STP is geïmplementeerd in software, zelfs op hoogwaardige switches die de meeste switchingfuncties in hardware met gespecialiseerde ASIC’s (Application-Specific Integrated Circuits) uitvoeren. Als er om welke reden dan ook sprake is van een overmatig gebruik van de CPU van de brug, kunnen de middelen ontoereikend zijn voor de transmissie van BPDU's. De STA is doorgaans niet processorintensief en heeft prioriteit op andere processen. In de sectie Zoeken naar resourcefouten in dit document staan enkele richtlijnen met betrekking tot het aantal STP-instanties dat een bepaald platform kan verwerken.
PortFast is een functie die u normaliter alleen inschakelt voor een poort of interface die is verbonden met een host. Wanneer de link bij deze poort komt, slaat de brug de eerste fasen van de STA over en gaat direct over naar de doorstuurmodus.

In dit voorbeeld is apparaat A een brug waarbij poort p1 al doorstuurt. Poort p2 heeft een PortFast-configuratie. Apparaat B is een hub. Zodra u de tweede kabel aansluit op apparaat A, gaat poort p2 over naar de doorstuurmodus en wordt een lus gevormd tussen poort p1 en poort p2. Deze lus stopt zodra poort p1 of poort p2 een BPDU ontvangt die een van deze twee poorten in blokkeermodus zet. Maar er is een probleem met een dergelijke tijdelijke lus. Als het verkeer in de lus erg intensief is, kan de brug problemen ervaren met de verzending van de BPDU die de lus stopt. Dit probleem kan de convergentie aanzienlijk vertragen en in extreme gevallen kan zelfs het netwerk uitvallen.
Raadpleeg voor meer informatie over het juiste gebruik van PortFast op switches waarop Cisco IOS-software wordt uitgevoerd, het document Met PortFast en andere opdrachten om vertragingen bij het opstarten van werkstations te verhelpen.
Zelfs bij een PortFast-configuratie neemt de poort of de interface nog steeds deel aan het STP. Als een switch met een lagere brugprioriteit dan die van de op dat moment actieve root-brug verbinding maakt met een PortFast-geconfigureerde poort of interface, kan deze als root-brug worden aangesteld. Deze verandering van root-brug kan een negatief effect hebben op de actieve STP-topologie, waardoor het netwerk niet optimaal functioneert. Om deze situatie te voorkomen, hebben de meeste Catalyst-switches die Cisco IOS Software uitvoeren een functie met de naam BPDU Guard. BPDU Guard schakelt een PortFast-geconfigureerde poort of interface uit als die poort of interface een BPDU ontvangt.
Raadpleeg voor meer informatie over het gebruik van de BPDU Guard-functie op switches waarop Cisco IOS-software wordt uitgevoerd, het document Begrijp de Spanning Tree PortFast BPDU Guard Enhancement.
Een agressieve waarde voor de parameter max age en de doorstuurvertraging kunnen leiden tot een zeer instabiele STP-topologie. In dergelijke gevallen kan door het verlies van enkele BPDU’s een lus ontstaan. Een ander weinig bekend probleem heeft betrekking op de diameter van het brugnetwerk. De conservatieve standaardwaarden van de STP-timers leggen een maximale netwerkdiameter van zeven op. Deze maximale netwerkdiameter beperkt hoe ver weg elke andere brug zich in het netwerk mag bevinden. In dit geval mogen twee specifieke bruggen maximaal zeven hops van elkaar af liggen. Een deel van deze beperking wordt veroorzaakt door het veld age van BPDU’s.
Wanneer een BPDU wordt verspreid van de root-brug naar de vertakkingen van de boomstructuur, wordt het veld age telkens opgehoogd wanneer de BPDU een brug passeert. Uiteindelijk verwijdert de brug de BPDU wanneer het veld age de maximale waarde overschrijdt. Dit probleem kan optreden als de root te ver van enkele bruggen in het netwerk ligt. Dit probleem beïnvloedt de convergentie van de Spanning Tree.
Ga voorzichtig te werk als u de standaardwaarde van STP-timers gaat wijzigen. Er is gevaar als je op deze manier probeert om een snellere herconvergentie te bereiken. Een wijziging van een STP-timer heeft impact op de diameter van het netwerk en de stabiliteit van het STP. U kunt de brugprioriteit om de root-brug te selecteren wijzigen en de parameter port cost of priority wijzigen om redundantie en taakverdeling te beheren.
Cisco Catalyst-software omvat macro’s waarmee u de belangrijkste STP-parameters kunt afstemmen:
De opdracht Spanning-tree uplinkfast voor Cisco IOS Software verhoogt de prioriteit van de switch, zodat de switch niet de root-brug wordt. De opdracht vermindert de STP-convergentietijd na een directe uplinkfout. Gebruik deze oude functie op een toegangslaag met redundante uplinks naar de distributielaag wanneer het switch en de STP-modus deze ondersteunen. Raadpleeg het document Understanding and Configuring the Cisco UplinkFast Feature (De Cisco-functie Uplink Fast begrijpen en configureren).
De opdracht Spanning-tree backbonefast voor Cisco IOS Software kan de STP-convergentietijd van de switch verkorten in het geval van een indirecte verbindingsfout. BackboneFast is een bedrijfseigen functie van Cisco. Raadpleeg het document Backbone Fast op Catalyst-Switches begrijpen en configureren.
Voor meer informatie over STP-timers en de regels om ze af te stemmen wanneer dat absoluut noodzakelijk is, raadpleegt u het document Spanning Tree Protocol Timers begrijpen en afstemmen.
Zoals aangegeven in de Inleiding is STP een van de eerste functies die in Cisco-producten werd geïmplementeerd. U kunt ervan uitgaan dat deze functie zeer stabiel is. Alleen interactie met nieuwere functies, zoals EtherChannel, heeft ertoe geleid dat STP in enkele zeer specifieke gevallen niet goed werkte. Dit probleem is ondertussen opgelost. Een aantal factoren kunnen tot een softwarebug leiden en verschillende effecten hebben. Het is niet mogelijk de problemen die het gevolg zijn van een bug adequaat te beschrijven. De gevaarlijkste situatie die kan ontstaan door softwarefouten is het gevolg van het negeren van BPDU’s of een blokkerende poort die overgaat naar de doorstuurmodus.
Helaas is er geen systematische procedure om een STP-probleem te troubleshooten. In deze sectie worden wel enkele van de acties benoemd die beschikbaar zijn. De meeste stappen in deze sectie zijn van toepassing op het troubleshooten van problemen met overbruggingslussen in het algemeen. U kunt een meer conventionele benadering toepassen om andere STP-problemen te identificeren die leiden tot verlies van connectiviteit. U kunt bijvoorbeeld het pad controleren dat door verkeer dat een probleem ondervindt wordt genomen.
Als u de uitvoer van een show tech-support -opdracht van uw Cisco-apparaat hebt, kunt u Cisco CLI Analyzer gebruiken.
Opmerking: alleen geregistreerde Cisco-gebruikers hebben toegang tot interne Cisco-tools en -informatie.
Voordat u een probleem met een overbruggingslus gaat troubleshooten, moet u minimaal op de hoogte zijn van het volgende:
De topologie van het brugnetwerk
De locatie van de root-brug
De locatie van de geblokkeerde poorten en de redundante links
Deze kennis is om ten minste twee redenen essentieel:
Om te weten wat u in het netwerk moet oplossen, moet u weten hoe het netwerk eruit ziet als het goed functioneert.
Bij de meeste stappen voor troubleshooting wordt de opdracht show gebruikt om fouten te identificeren. Als u kennis heeft van het netwerk, kunt u de aandacht richten op de kritieke poorten op de belangrijkste apparaten.
Vroeger kon een broadcast storm een zeer schadelijk effect hebben op het netwerk. Tegenwoordig zijn er links met hoge snelheden en apparaten die switching bieden op hardwareniveau en is het onwaarschijnlijk dat één host – bijvoorbeeld een server – ervoor zorgt dat een netwerk uitvalt als gevolg van broadcasts. De beste manier om een overbruggingslus te identificeren, is door het verkeer op een verzadigde link vast te leggen en te controleren of u vergelijkbare pakketten meerdere keren ziet. Als alle gebruikers in een bepaald brugdomein echter op hetzelfde moment verbindingsproblemen ervaren, kunt u er al van uitgaan dat er sprake is van een overbruggingslus.
Controleer de poortbenutting op uw apparaten en zoek naar abnormale waarden. Zie de sectie Poortbenutting controleren in dit document.
Overbruggingslussen hebben zeer grote gevolgen op een brugnetwerk. Beheerders hebben doorgaans geen tijd om de oorzaak van de lus te achterhalen en geven er de voorkeur aan connectiviteit zo snel mogelijk te herstellen. Om een actieve lus te stoppen, gebruikt u console- of out-of-band-toegang om één vermoedelijk redundant pad tegelijk uit te schakelen en de connectiviteit na elke wijziging te verifiëren. Vermijd het uitschakelen van koppelingen die het enige beheer- of doorstuurpad naar een netwerksegment bieden. Als u een deel van het netwerk kunt identificeren dat de meeste problemen ondervindt, begint u met het uitschakelen van poorten in dat deel. U kunt ook in eerste instantie poorten uitschakelen die blokkerend kunnen zijn. Telkens wanneer u een poort uitschakelt, moet u controleren of de connectiviteit in het netwerk is hersteld. Door te bepalen welke uitgeschakelde poort de lus stopt, identificeert u ook het redundante pad waar deze poort zich bevindt. Als deze poort blokkeerde, heeft u waarschijnlijk de link gevonden waar de fout optrad.
Als u de bron van het probleem niet exact kunt vaststellen, of als het probleem tijdelijk is, schakelt u vastlegging in van STP-gebeurtenissen op de bruggen en switches van het netwerk die het probleem ervaren. Als u het te configureren aantal apparaten wilt beperken, schakel dan ten minste vastlegging in op apparaten die geblokkeerde poorten hosten – de overgang van een geblokkeerde poort creëert de lus.
Waarschuwing: foutopsporingsopdrachten kunnen tijdens een overbruggingslus besturingsplanbelasting toevoegen. Voer ze alleen uit met console- of out-of-band-toegang, bewaak het CPU-gebruik en schakel foutopsporing uit na het verzamelen van gegevens.
Voer de opdracht debug spanning-tree events EXEC uit om STP event debugging in te schakelen. Configureer de logboekbuffer om de berichten in de logboekbuffer vast te leggen.
U kunt de debug-output ook verzenden naar een syslog-apparaat. Wanneer echter een overbruggingslus wordt gevormd, is het erg lastig om connectiviteit met een syslog-server te behouden.
De kritieke poorten die als eerste moeten worden gecontroleerd, zijn de blokkerende poorten. In deze sectie vindt u een lijst van wat u moet zoeken op de verschillende poorten, met een snelle beschrijving van de opdrachten die u moet geven voor switches die Cisco IOS-software uitvoeren.
U moet met name controleren of geblokkeerde poorten en root-poorten BPDU’s ontvangen. Verschillende problemen kunnen ertoe leiden dat een poort geen pakketten of BPDU’s ontvangt.
Cisco IOS Software-In Cisco IOS Software Release 12.0 of hoger, heeft de uitvoer van de opdracht spanning-tree vlan <vlan-id> detail een BPDU-veld. Dit veld toont voor elke interface het aantal BPDU’s dat is ontvangen. Voer de opdracht nog een- of tweemaal uit om te bepalen of het apparaat BPDU’s ontvangt. Een andere optie is om STP debug in te schakelen met de debug spanning-tree bpdu opdracht om de ontvangst van BPDU's te verifiëren.
Om na te gaan of er sprake is van een duplex-mismatch, moet u beide kanten van de point-to-point link controleren.
Cisco IOS Software-Geef de opdracht show interfaces [interface-number] status om de snelheid en de duplexstatus van de specifieke poort te controleren.
Als een interface overmatig veel verkeer moet verwerken, worden essentiële BPDU’s mogelijk niet verzonden. Een overbelaste link duidt ook op een mogelijke overbruggingslus.
Cisco IOS Software-Gebruik de show interfaces om het gebruik op een interface te bepalen. Verschillende velden kunnen hierbij behulpzaam zijn, zoals load en packets input/output. Raadpleeg het document Problemen met Switch-poort en -interface oplossen voor een uitleg over de uitvoer van de show interfaces -opdracht.
Cisco IOS-software – controleer op oplopende teller input errors van de opdracht show interfaces. De foutenteller omvat Runts, Giants, no buffer, CRC, frame, overrun en ignored.
Raadpleeg het document Problemen met de Switch-poort en -interface oplossen voor een uitleg van de show interfaces command output.
Een hoge CPU-benutting kan gevaarlijk zijn voor een systeem met STA. Gebruik de volgende methode om na te gaan of de CPU-resource voldoende is voor een apparaat:
Cisco IOS-software – voer de opdracht show processes cpu uit. Controleer of de CPU-benutting niet te hoog is.
Het aantal verschillende STP-instanties dat een Supervisor Engine kan verwerken is beperkt. Zorg dat het totale aantal logische poorten bij alle STP-instanties voor verschillende VLAN’s het ondersteunde maximumaantal voor elk type Supervisor Engine en geheugenconfiguratie niet overschrijdt.
Geef de opdracht show spanning-tree summary totals voor switches op. Deze opdracht geeft het aantal logische poorten of interfaces per VLAN weer in de kolom STP Active. Het totale aantal staat onder aan deze kolom. Dat totaal vertegenwoordigt de som van alle logische poorten bij alle STP-instanties voor de verschillende VLAN’s. Zorg dat dit aantal het ondersteunde maximumaantal voor elk type Supervisor Engine niet overschrijdt.
(number of non-ATM trunks * number of active Vlans on that trunk) + 2*(number of ATM trunks * number of active Vlans on that trunk) + number of non-trunking ports
Raadpleeg de volgende documenten voor een overzicht van de beperkingen voor STP die van toepassing zijn op Catalyst-switches:
| Platform | STP-beperkingen – Cisco IOS-software |
|---|---|
| Catalyst 6500/6000 Supervisor Engine 720 | Release Notes voor Cisco IOS Release 12.2SXF en Rebuilds |
| Catalyst 4500/4000 | Releaseopmerkingen voor de Catalyst 4500-reeks Switch, Cisco IOS, 12.1EW |
| Catalyst 3750 | Catalyst 3750 Switch Software Configuration Guide, Rel. 12.1(19)EA1 |
show interfaces
show spanning-tree
show processes cpu
debug spanning-tree
logging buffered
Vaak is tijdens het troubleshooten geen informatie beschikbaar over de locatie van de root. Laat het STP niet bepalen welke brug als root fungeert. Doorgaans kunt u voor elk VLAN bepalen welke switch het beste als root kan fungeren. Dit is afhankelijk van de opzet van het netwerk. In het algemeen moet u een krachtige brug in het midden van het netwerk selecteren. Als de root-brug zich in het midden van het netwerk bevindt en deze directe verbindingen heeft met de servers en routers, dan wordt de gemiddelde afstand van de clients tot de servers en routers verkleind.

Het diagram toont:
Als bridge B root is, wordt link A naar C geblokkeerd op bridge A of bridge C. In dit geval kunnen hosts die verbinding maken met switch B in twee stappen toegang krijgen tot de server en de router. Hosts die verbinding maken met brug C hebben via drie hops toegang tot de server en de router. De gemiddelde afstand is tweeënhalve hop.
Als bridge A root is, zijn de router en de server in twee sprongen bereikbaar voor beide hosts die verbinding maken op B en C. De gemiddelde afstand is nu twee sprongen.
De logica achter dit eenvoudige voorbeeld is van toepassing op complexere topologieën.
Plan de ordening van uw redundante links. Maak geen gebruik van de plug-and-play functie van het STP. Stem de STP-parameter cost af om te bepalen welke poorten moeten worden geblokkeerd. Deze afstemming is doorgaans niet nodig bij een hiërarchisch ontwerp met een root-brug op een goede locatie.
Kennis van de locatie van redundante links zorgt ervoor dat u een onbedoelde overbruggingslus en de oorzaak ervan kunt identificeren. Kennis van de locatie van geblokkeerde poorten maakt het mogelijk de locatie van de fout te bepalen.
De enige kritieke actie die het STP neemt is het blokkeren van de poorten. Eén blokkerende poort die per ongeluk overgaat naar de doorstuurmodus kan een groot deel van het netwerk platleggen. Een goede manier om het inherente risico van STP-gebruik te beperken, is door het aantal geblokkeerde poorten zo veel mogelijk te verminderen.
Vermijd onnodige onafhankelijke Layer 2-paden tussen twee switching nodes. Bundel parallelle links naar een EtherChannel wanneer het ontwerp en het platform het ondersteunen:

Distributieswitches zijn dubbel verbonden met twee core-switches. Gebruikers die verbinding maken via distributieswitches, hebben alleen toegang tot een subset van de VLAN’s die in het netwerk beschikbaar zijn. In dit voorbeeld bevinden gebruikers die verbinding maken met Dist 2 zich allemaal in VLAN 2. Met Dist 3 worden alleen gebruikers in VLAN 3 verbonden. Trunks bieden standaard toegang tot alle VLAN’s die in het VTP-domein (VLAN Trunking Protocol) zijn gedefinieerd. Alleen Dist 2 ontvangt onnodig broadcast en multicast verkeer voor VLAN 3, maar deze switch blokkeert ook een van de poorten voor VLAN 3. Dit leidt tot drie redundante paden tussen Core A en Core B. Deze redundantie resulteert in meer geblokkeerde poorten en een grotere kans op lusvorming.
VTP-snoeien vermindert onnodig overstroomd verkeer voor in aanmerking komende VLAN's, maar expliciete trunk-allowed VLAN-configuratie biedt deterministische VLAN-plaatsing. Behandel VTP-snoeien niet als vervanging voor het verwijderen van ongebruikte VLAN's uit lijsten met toegestane stammen.
In het volgende voorbeeld wordt alleen een toegangs-VLAN gebruikt om de distributieswitches te verbinden met de core:

In deze opzet wordt slechts één poort per VLAN geblokkeerd. In deze opzet kunt u ook alle redundante links in één stap verwijderen als u Core A en Core B uitschakelt.
Layer 3-switching houdt in dat routing ongeveer met de snelheid van switching plaatsvindt. Een router voert twee hoofdfuncties uit:
Een router creëert een doorstuurtabel. Een router wisselt doorgaans informatie uit met peers via routingprotocollen.
Een router ontvangt pakketten en stuurt deze door naar de juiste interface op basis van het bestemmingsadres.
High-end Cisco Layer 3-switches kunnen deze functie uitvoeren, met dezelfde snelheid als de Layer 2-switchfunctie. Als u een routinghop toevoegt en aanvullende segmentatie van het netwerk creëert, komt de snelheid niet in gevaar. In het volgende diagram is het voorbeeld uit de sectie Ongebruikte VLAN’s via pruning verwijderen als basis gebruikt:

Core A en Core B zijn nu Layer 3-switches. VLAN 2 en VLAN 3 zijn niet langer overbrugd tussen Core A en Core B, dus een STP-lus kan die gerouteerde grens niet overschrijden. Laag 2-lussen blijven mogelijk binnen elk overbrugd VLAN.
Er is nog steeds sprake van redundantie bij gebruik van Layer 3-routingprotocollen. Het ontwerp maakt gebruik van Layer 3-routering voor padredundantie. Convergentietijd is afhankelijk van het routeringsprotocol, het foutdetectiemechanisme, timers, topologie en platform.
Er is geen enkele poort meer die door STP wordt geblokkeerd. Er is dus ook geen risico van een overbruggingslus.
De snelheid komt niet in gevaar omdat verkeer het VLAN via Layer 3-switching net zo snel kan verlaten als via overbrugging binnen het VLAN.
Deze opzet heeft echter één nadeel. Migratie naar dit type opzet houdt doorgaans in dat het adresseringsschema moet worden aangepast.
Zelfs als u alle geblokkeerde poorten uit uw netwerk heeft verwijderd en er geen sprake is van fysieke redundantie moet u STP niet uitschakelen. STP is doorgaans niet processorintensief: de CPU in de meeste Cisco-switches is niet betrokken bij pakketswitching. Bovendien wordt de beschikbare bandbreedte niet aanzienlijk verlaagd door de enkele BPDU’s die op elke link worden verzonden. Een brugnetwerk zonder STP kan echter in een fractie van een seconde uitvallen als een operator bijvoorbeeld een fout maakt op een patchpaneel. Doorgaans is uitschakeling van het STP op een brugnetwerk het risico niet waard.
Een Cisco-switch heeft doorgaans één IP-adres dat is gekoppeld aan een VLAN: het administratieve VLAN. In dit VLAN fungeert de switch als een generieke IP-host. Uitgezonden, multicast- en besturingsvliegtuigverkeer in het beheerdersnetwerk kan CPU-bronnen verbruiken, afhankelijk van het type verkeer, het platform, de softwarerelease en de configuratie van het controlevlak. Als er sprake is van veel broadcast of multicast verkeer op het administratieve VLAN, kan dat een negatieve invloed hebben op de CPU en het vermogen van de CPU om essentiële BPDU’s te verwerken. Houd gebruikersverkeer daarom weg van het administratieve VLAN.
In oudere releases was er geen manier om VLAN 1 uit een trunk te verwijderen in Cisco-implementatie. VLAN 1 fungeert doorgaans als een administratief VLAN waarbij alle switches toegankelijk zijn in hetzelfde IP-subnet. Hoewel dat nuttig is, kan deze opzet problemen opleveren omdat een overbruggingslus op VLAN 1 van invloed is op alle trunks, waardoor het gehele netwerk kan uitvallen. Dat probleem is altijd van toepassing, ongeacht welk VLAN u gebruikt. Segmenteer de brugdomeinen door Layer 3-switches met hoge snelheid in te zetten.
Vanaf Cisco IOS Software Release 12.1(11b)E kunt u VLAN 1 uit de trunks verwijderen. VLAN 1 blijft aanwezig, maar het kan de beveiliging verbeteren en onnodig Layer-2-verkeer verminderen.
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
5.0 |
09-Sep-2026
|
Hercertificering, opmaak en vaste koppelingen. |
3.0 |
09-May-2024
|
hercertificering |
2.0 |
10-Jan-2023
|
Dit artikel is intern gemaakt om te voldoen aan het artikel dat momenteel op Cisco.com staat.
Afbeeldingen geconverteerd naar .png-indeling.
Bijgewerkt Intro, Alt Text, Rounds, etc. |
1.0 |
05-Dec-2017
|
Eerste vrijgave |