De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft hoe u Cisco IOS®-software moet gebruiken om problemen met Spanning Tree Protocol (STP) op te lossen.
Cisco raadt kennis van de volgende onderwerpen aan:
Verschillende Spanning Tree types en hoe ze te configureren. Zie STP en IEEE 802.1s MST configureren voor meer informatie.
Diverse Spanning Tree-functies en hoe u deze kunt configureren. Zie STP-functies configureren voor meer informatie.
De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:
Catalyst 6500 met Supervisor 2-engine
Cisco IOS-softwarerelease 12.1(13)E
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.
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
Er zijn specifieke opdrachten die alleen van toepassing zijn op Catalyst 6500/6000. U kunt de meeste beginselen echter toepassen op elke Cisco Catalyst switch waarin Cisco IOS-software wordt uitgevoerd.
Problemen met de meeste STV's hebben deze drie problemen:
Doorsturen van lussen.
Buitensporige overstroming door een hoog percentage STP topologiewijzigingen (TC).
Kwesties in verband met de convergentietijd.
Omdat een brug geen mechanisme heeft om te volgen of een bepaald pakket meerdere malen wordt doorgestuurd (bijvoorbeeld een IP-tijd om te leven [TTL]) of wordt gebruikt om verkeer weg te gooien dat te lang in het netwerk circuleert. Er kan slechts één pad bestaan tussen twee apparaten in hetzelfde Layer 2 (L2)-domein.
Het doel van STP is redundante poorten te blokkeren op basis van een STP-algoritme en redundante fysieke topologie op te lossen in een boomachtige topologie. Een het door:sturen lijn (zoals een lijn STP) komt voor wanneer geen haven in een overtollige topologie wordt geblokkeerd, en het verkeer door:sturen in cirkels voor onbepaalde tijd.
Zodra de het door:sturen lijn begint, verstopt het de laag-bandbreedte verbindingen langs zijn weg. Als alle koppelingen van dezelfde bandbreedte zijn, zijn alle koppelingen verstopt. Deze congestie veroorzaakt pakketverlies en leidt tot een netwerk down situatie in het beïnvloede L2 domein.
Bij buitensporige overstromingen zijn de symptomen minder duidelijk. Langzame verbindingen kunnen door overstroomd verkeer worden verstopt, en apparaten of gebruikers achter deze overstroomde verbindingen kunnen traagheid, of totaal verlies van connectiviteit ervaren.
STP maakt bepaalde aannames over zijn operationele omgeving. Dit zijn de meest relevante aannames voor dit document:
Elke verbinding tussen de twee bruggen is tweerichtings. Dit betekent dat, als A rechtstreeks met B verbindt, A ontvangt wat B heeft verzonden en B ontvangt wat A heeft verzonden, zolang de verbinding tussen hen bestaat.
Elke brug die STP in werking stelt kan, de Eenheden van de Gegevens van het Protocol van de Brug STP (BPDUs) regelmatig ontvangen, verwerken en overbrengen, die ook als pakketten STP worden bekend.
Hoewel deze veronderstellingen logisch en voor de hand liggend lijken, zijn er situaties waarin niet aan deze veronderstellingen wordt voldaan. De meeste van deze situaties hebben betrekking op een bepaald soort hardwareprobleem; softwarestoornissen kunnen echter ook leiden tot STP-storingen. Verschillende hardwarestoringen, foutieve configuraties, verbindingsproblemen veroorzaken de meerderheid van STP-storingen, terwijl softwarestoringen verantwoordelijk zijn voor de minderheid. STP-storingen kunnen ook optreden door overbodige extra aansluitingen tussen de switches. VLAN’s gaan door deze extra verbindingen naar een benedenstaat. Om dit probleem op te lossen, verwijder alle ongewenste connecties tussen de switches.
Wanneer aan een van deze veronderstellingen niet is voldaan, kunnen een of meer bruggen de BPDU's niet ontvangen of verwerken. Dit betekent dat de brug (of bruggen) niet de netwerktopologie ontdekt. Zonder kennis van de juiste topologie kan de switch de lussen niet blokkeren. Daarom circuleert het overstroomde verkeer over de van een lus voorzien topologie, verbruikt alle bandbreedte, en brengt het netwerk neer.
De voorbeelden van waarom de switches geen BPDUs kunnen ontvangen omvatten slechte transceivers of Gigabit Interface Converters (GBICs), kabelkwesties, of hardwaremislukkingen op de poort, de lijnkaart, of de Supervisor-motor. Een veelvoorkomende reden voor STP-falen is een unidirectionele link tussen de bruggen. In zo'n situatie stuurt één brug BPDU's, maar de downstream brug ontvangt ze nooit. STP-verwerking kan ook worden onderbroken door een overbelaste CPU (99% of meer) omdat de switch geen ontvangen BPDU's kan verwerken. BPDU's kunnen langs het pad van de ene brug naar de andere gecorrumpeerd worden, wat ook goed STP-gedrag voorkomt.
Afgezien van de doorsturen lijnen, wanneer er geen poorten worden geblokkeerd, zijn er situaties waarin alleen bepaalde pakketten onjuist worden doorgestuurd door de poorten die verkeer blokkeren. In de meeste gevallen wordt dit veroorzaakt door softwareproblemen. Zulk gedrag kan langzame lijnen veroorzaken. Dit betekent dat sommige pakketten van een lus worden voorzien, maar het merendeel van het verkeer loopt nog steeds door het netwerk, omdat de verbindingen niet verstopt zijn.
Het doorsturen van lussen varieert enorm, zowel qua oorsprong (oorzaak) als effect. Door de grote verscheidenheid aan problemen die van invloed kunnen zijn op STP, kan dit document alleen algemene richtlijnen geven over hoe u problemen kunt oplossen bij het doorsturen van loops.
Voordat u begint met probleemoplossing, hebt u deze informatie nodig:
Een topologiediagram dat alle switches en bruggen gedetailleerd weergeeft.
hun bijbehorende poortnummers (onderling verbonden).
STP-configuratiedetails, zoals welke switch de root en back-uproot is, welke links niet-standaardkosten of -prioriteit hebben, en de locatie van de poorten die verkeer blokkeren.
Wanneer een het door:sturen lijn in het netwerk heeft ontwikkeld, zijn de gebruikelijke symptomen:
Verlies van connectiviteit naar, van en door getroffen netwerkregio's.
Hoog CPU-gebruik op routers die zijn aangesloten op getroffen segmenten of VLAN’s die tot diverse symptomen kunnen leiden, zoals het routeren van protocolbuur flappen of actieve HSRP-routerflapping (Hot Standby Router Protocol).
Hoog linkgebruik (vaak 100 procent).
Hoog switch backplane gebruik (vergeleken met het basislijngebruik).
Syslog-berichten die pakketlooping in het netwerk aangeven (bijvoorbeeld HSRP-duplicaat van IP-adresberichten).
Syslog berichten die constant adres relearning of MAC adres flapping berichten aangeven.
Het aantal outputs daalt op vele interfaces toeneemt.
Om al deze redenen alleen kunnen verschillende kwesties worden aangegeven (of helemaal geen kwestie). Echter, wanneer veel van deze tegelijkertijd worden waargenomen, is het zeer waarschijnlijk dat een doorschakellus zich heeft ontwikkeld in het netwerk. De snelste manier om dit te verifiëren is het gebruik van backplane switch-verkeer te controleren:
cat#show catalyst6000 traffic-meter traffic meter = 13% Never cleared peak = 14% reached at 12:08:57 CET Fri Oct 4 2002
Opmerking: Catalyst 4000 met Cisco IOS-software ondersteunt deze opdracht momenteel niet.
Als het huidige verkeersniveau buitensporig is of als het basisniveau niet bekend is, controleert u of het piekniveau recentelijk is bereikt en of het dicht bij het huidige verkeersniveau ligt. Bijvoorbeeld, als het piekniveau 15 procent is en het slechts twee minuten geleden werd bereikt en het huidige verkeersniveau 14 procent is, dan betekent dat dat de switch een ongewoon hoge belasting heeft. Als de verkeerslading op een normaal niveau is, dan betekent dat waarschijnlijk dat er ofwel geen lus is of dat dit apparaat niet betrokken is bij de lus. Het kan echter nog steeds betrokken zijn bij een trage lus.
Zodra is vastgesteld dat de reden voor de netwerkstroomonderbreking een voorwaartse lijn is, is de hoogste prioriteit om de lijn tegen te houden en de netwerkverrichting te herstellen.
Als u de lus wilt stoppen, moet u weten welke poorten aan de loop deelnemen: kijk naar de poorten met het hoogste koppelingsgebruik (pakketten per seconde). De opdracht interfaceCisco IOS-software toont het gebruik voor elke interface.
Als u alleen de gebruiksinformatie en de interfacenaam (voor een snelle analyse) wilt weergeven, filtert u de reguliere expressieuitvoer met de Cisco IOS-software. Probleem met de diavoorstelling | omvat regel|\/secorder om alleen het pakket per seconde statistieken en de interfacenaam weer te geven:
cat#show interface | include line|\/sec GigabitEthernet2/1 is up, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/2 is up, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/3 is up, line protocol is up 5 minute input rate 99765230 bits/sec, 24912 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/4 is up, line protocol is up 5 minute input rate 1000 bits/sec, 27 packets/sec 5 minute output rate 101002134 bits/sec, 25043 packets/sec GigabitEthernet2/5 is administratively down, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/6 is administratively down, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/7 is up, line protocol is down 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec GigabitEthernet2/8 is up, line protocol is up 5 minute input rate 2000 bits/sec, 41 packets/sec 5 minute output rate 99552940 bits/sec, 24892 packets/sec
Besteed aandacht aan de interfaces met het hoogste verbindingsgebruik. In dit voorbeeld zijn dit interfaces g2/3, g2/4 en g2/8; het zijn de poorten die deelnemen aan de loop.
Om de lus te doorbreken moet u de betrokken poorten afsluiten of loskoppelen. Het is bijzonder belangrijk om niet alleen de lus te stoppen, maar ook om de basisoorzaak van de lus te vinden en te repareren. Het is relatief makkelijker om de lus te doorbreken
Opmerking: u hoeft niet alle poorten tegelijk uit te schakelen of los te koppelen. Je kan ze een voor een afsluiten. Het is beter om poorten te sluiten op het aggregatiepunt dat door de loop wordt beïnvloed, zoals een distributiekanaal of core switch. Als u alle poorten tegelijk afsluit en ze één voor één weer aansluit, werkt dit niet; de lus wordt gestopt en kan niet onmiddellijk starten nadat de defecte poort opnieuw is aangesloten. Het is dan ook moeilijk om een verband te leggen tussen het falen van een bepaalde haven.
Opmerking: om de lus te breken, wordt aanbevolen om informatie te verzamelen voordat u de switches opnieuw opstart. Anders is een latere analyse van de basisoorzaak moeilijk. Nadat u elke poort hebt uitgeschakeld of losgekoppeld, moet u controleren of de backplane van de switch weer op een normaal niveau wordt gebruikt.
Opmerking: Houd in gedachten dat poorten de lus niet ondersteunen, maar het verkeer dat met de lus komt overspoelen. Wanneer u dergelijke overstromende poorten sluit, vermindert u backplane gebruik slechts een klein bedrag, maar u stopt de lus niet.
In de volgende voorbeeldtopologie, is de lijn tussen switches A, B, en D. Daarom worden de verbindingen AB, AD, en BD in stand gehouden. Als je een van deze koppelingen afsluit, stop je de lus. De verbindingen AC, AE, BC, en BE zijn enkel overstromend verkeer dat met de lijn aankomt.
Nadat de support poort is uitgeschakeld, gaat backplane gebruik terug naar een normale waarde. U moet weten welke port shutdown het backplane gebruik (en het gebruik van andere poorten) naar een normaal niveau heeft gebracht. Op dit punt, wordt de lijn tegengehouden, en de netwerkverrichting verbetert; nochtans, omdat de originele oorzaak van de lijn niet werd bevestigd, zijn er nog andere kwesties.
Zodra de lus wordt gestopt, moet u de reden bepalen waarom de lus is begonnen. Dit is het moeilijke deel van het proces, omdat de redenen kunnen variëren. Het is ook moeilijk om een exacte procedure te formaliseren die in elk geval werkt.
Richtsnoeren:
Onderzoek het topologiediagram om een overtollige weg te vinden. Dit omvat de ondersteuningspoort die in de vorige stap is gevonden en die naar dezelfde switch terugkomt (de padpakketten die tijdens de loop worden besproken). In de vorige voorbeeldtopologie is dit pad AD-DB-BA.
Controleer voor elke switch op het redundante pad of de switch de juiste STP root kent.
Alle switches in een L2 netwerk moeten het eens worden over een gemeenschappelijke STP root. Het is een duidelijk symptoom van problemen wanneer de bruggen constant een verschillende ID voor de STP wortel in een bepaalde instantie van VLAN of STP tonen. Geef de opdracht Spanning-Tree VLAN VLAN-id uit om de root-brug-ID voor een bepaald VLAN weer te geven:
cat#show spanning-tree vlan 333 MST03 Spanning tree enabled protocol mstp Root ID Priority 32771 Address 0050.14bb.6000 Cost 20000 Port 136 (GigabitEthernet3/8) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32771 (priority 32768 sys-id-ext 3) Address 00d0.003f.8800 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Interface Role Sts Cost Prio.Nbr Status ---------------- ---- --- --------- -------- ------------------------ Gi3/8 Root FWD 20000 128.136 P2p Po1 Desg FWD 20000 128.833 P2p
Het VLAN-nummer kan worden gevonden vanuit de poort, omdat poorten die betrokken zijn bij de loop in eerdere stappen zijn ingesteld. Als de poorten in kwestie trunks zijn, zijn vaak alle VLAN’s op de trunk betrokken. Als dit niet het geval is (bijvoorbeeld als het lijkt dat de lus op één VLAN is gebeurd), kunt u proberen de interfaces te publiceren | omvatten L2|line|broadcast-opdracht (alleen op Supervisor 2 en latere motoren op Catalyst 6500/6000 Series switches, omdat Supervisor 1 geen per-VLAN-switchstatistieken biedt). Bekijk alleen VLAN-interfaces. VLAN met het hoogste aantal switched pakketten is vaak waar de lijn voorkwam:
cat#show interface | include L2|line|broadcast Vlan1 is up, line protocol is up L2 Switched: ucast: 653704527 pkt, 124614363025 bytes - mcast: 23036247 pkt, 1748707536 bytes Received 23201637 broadcasts, 0 runts, 0 giants, 0 throttles Vlan10 is up, line protocol is up L2 Switched: ucast: 2510912 pkt, 137067402 bytes - mcast: 41608705 pkt, 1931758378 bytes Received 1321246 broadcasts, 0 runts, 0 giants, 0 throttles Vlan11 is up, line protocol is up L2 Switched: ucast: 73125 pkt, 2242976 bytes - mcast: 3191097 pkt, 173652249 bytes Received 1440503 broadcasts, 0 runts, 0 giants, 0 throttles Vlan100 is up, line protocol is up L2 Switched: ucast: 458110 pkt, 21858256 bytes - mcast: 64534391 pkt, 2977052824 bytes Received 1176671 broadcasts, 0 runts, 0 giants, 0 throttles Vlan101 is up, line protocol is up L2 Switched: ucast: 70649 pkt, 2124024 bytes - mcast: 2175964 pkt, 108413700 bytes Received 1104890 broadcasts, 0 runts, 0 giants, 0 throttles
In dit voorbeeld is VLAN 1 verantwoordelijk voor het hoogste aantal uitzendingen en L2-switched verkeer. Zorg ervoor dat de wortelpoort correct is geïdentificeerd.
De basishaven moet de laagste kosten voor de root-brug hebben (soms is één weg korter in termen van hop maar langer in termen van kosten, aangezien de lagesnelheidshavens hogere kosten hebben). Om te bepalen welke poort als de root voor een gegeven VLAN wordt beschouwd, moet u de opdracht Spanning-Tree VLAN uitgeven:
cat#show spanning-tree vlan 333 MST03 Spanning tree enabled protocol mstp Root ID Priority 32771 Address 0050.14bb.6000 Cost 20000 Port 136 (GigabitEthernet3/8) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32771 (priority 32768 sys-id-ext 3) Address 00d0.003f.8800 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Interface Role Sts Cost Prio.Nbr Status ---------------- ---- --- --------- -------- ------------------------ Gi3/8 Root FWD 20000 128.136 P2p Po1 Desg FWD 20000 128.833 P2p
Zorg ervoor dat de BPDUs regelmatig worden ontvangen op de wortelhaven en op havens die verondersteld worden te blokkeren.
BPDU's worden door de root-brug verzonden met elk hellointerval (standaard twee seconden). Niet-root-bruggen ontvangen, verwerken, wijzigen en verspreiden de BPDU's die van de root worden ontvangen. Geef de opdracht interfacedetails over de overspannen-boom uit om te zien of de BPDU's worden ontvangen:
cat#show spanning-tree interface g3/2 detail Port 130 (GigabitEthernet3/2) of MST00 is backup blocking Port path cost 20000, Port priority 128, Port Identifier 128.130. Designated root has priority 0, address 0007.4f1c.e847 Designated bridge has priority 32768, address 00d0.003f.8800 Designated port id is 128.129, designated path cost 2000019 Timers: message age 4, forward delay 0, hold 0 Number of transitions to forwarding state: 0 Link type is point-to-point by default, Internal Loop guard is enabled by default on the port BPDU: sent 3, received 53 cat#show spanning-tree interface g3/2 detail Port 130 (GigabitEthernet3/2) of MST00 is backup blocking Port path cost 20000, Port priority 128, Port Identifier 128.130. Designated root has priority 0, address 0007.4f1c.e847 Designated bridge has priority 32768, address 00d0.003f.8800 Designated port id is 128.129, designated path cost 2000019 Timers: message age 5, forward delay 0, hold 0 Number of transitions to forwarding state: 0 Link type is point-to-point by default, Internal Loop guard is enabled by default on the port BPDU: sent 3, received 54
Opmerking: er is een BPDU ontvangen tussen de twee uitgangen van het commando (de teller ging van 53 naar 54).
De getoonde tellers zijn feitelijk tellers die door het STP-proces zelf worden onderhouden. Dit betekent dat, als de ontvangsttellers verhoogd werden, niet alleen BPDU door een fysieke poort werd ontvangen, maar het werd ook door het STP-proces ontvangen. Als dereceived
BPDU-teller niet toeneemt op de poort die verondersteld wordt de root-alternatieve of back-uppoort te zijn, dan controleert u of de poort multicast ontvangt (BPDU's worden als multicast verzonden). Geef de opdracht interface-tegenstanders uit:
cat#show interface g3/2 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Gi3/2 14873036 2 89387 0 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Gi3/2 114365997 83776 732086 19 cat#show interface g3/2 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Gi3/2 14873677 2 89391 0 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Gi3/2 114366106 83776 732087 19
Een korte beschrijving van STP-poortrollen kan worden gevonden in het gedeelte Enhance STP with Loop Guard en BPDU Skew Detection van Verbeteringen in Spanning-Tree Protocol met behulp van Loop Guard en BPDU Skew Detection Properties. Als er geen BPDU's worden ontvangen, controleert u of de poort de fouten telt. Geef de opdracht storingen in interface-interfacetellers uit:
cat#show interface g4/3 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi4/3 0 0 0 0 0 0 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Gi4/3 0 0 0 0 0 0 0
Het is mogelijk dat BPDU's door de fysieke poort worden ontvangen maar nog steeds niet het STP-proces bereiken. Als de opdrachten die in de vorige twee voorbeelden zijn gebruikt, laten zien dat bepaalde multicast worden ontvangen en dat fouten niet worden geteld, controleert u of de BPDU's op het STP-procesniveau worden gedropt. Geef de opdracht Remote Command switch test Spanning-Tree proces-statsop op Catalyst 6500 uit:
cat#remote command switch test spanning-tree process-stats ------------------TX STATS------------------ transmission rate/sec = 2 paks transmitted = 5011226 paks transmitted (opt) = 0 opt chunk alloc failures = 0 max opt chunk allocated = 0 ------------------RX STATS------------------ receive rate/sec = 1 paks received at stp isr = 3947627 paks queued at stp isr = 3947627 paks dropped at stp isr = 0 drop rate/sec = 0 paks dequeued at stp proc = 3947627 paks waiting in queue = 0 queue depth = 7(max) 12288(total) --------------PROCESSING STATS--------------- queue wait time (in ms) = 0(avg) 540(max) processing time (in ms) = 0(avg) 4(max) proc switch count = 100 add vlan ports = 20 time since last clearing = 2087269 sec
Het bevel dat in dit voorbeeld wordt gebruikt toont de STP processtatistieken. Het is belangrijk om te verifiëren dat de drop-tellers niet toenemen en dat ontvangen pakketten wel toenemen. Als de ontvangen pakketten niet worden verhoogd maar de fysieke poort wel multicast ontvangt, controleert u of de pakketten worden ontvangen door de switch in-band-interface (de interface van de CPU). De switch van het bevel van de uitgifte toont ibc | i rx_inputopdracht op Catalyst 6500/6000:
cat#remote command switch show ibc | i rx_input rx_inputs=5626468, rx_cumbytes=859971138 cat# remote command switch show ibc | i rx_input rx_inputs=5626471, rx_cumbytes=859971539
Dit voorbeeld laat zien dat tussen de uitgangen, de in-band poort 23 pakketten heeft ontvangen.
Opmerking: deze 23 pakketten zijn niet alleen BPDU-pakketten; dit is een algemene teller voor alle pakketten die worden ontvangen door de in-band poort.
Als er geen aanwijzing is dat BPDU's op de lokale switch of poort worden gedropt, moet u naar de switch aan de andere kant van de link gaan en controleren of die switch BPDU's verstuurt. Controleer of de BPDU's regelmatig worden verzonden op niet-root, aangewezen poorten. Als, de havenrol overeenstemt, verzendt de haven BPDUs, maar de buur ontvangt hen niet. Controleer of BPDU's zijn verzonden. Geef de detailopdracht over-boominterface uit:
cat#show spanning-tree interface g3/1 detail Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding Port path cost 20000, Port priority 128, Port Identifier 128.129. Designated root has priority 0, address 0007.4f1c.e847 Designated bridge has priority 32768, address 00d0.003f.8800 Designated port id is 128.129, designated path cost 2000019 Timers: message age 0, forward delay 0, hold 0 Number of transitions to forwarding state: 0 Link type is point-to-point by default, Internal Loop guard is enabled by default on the port BPDU: sent 1774, received 1 cat#show spanning-tree interface g3/1 detail Port 129 (GigabitEthernet3/1) of MST00 is designated forwarding Port path cost 20000, Port priority 128, Port Identifier 128.129. Designated root has priority 0, address 0007.4f1c.e847 Designated bridge has priority 32768, address 00d0.003f.8800 Designated port id is 128.129, designated path cost 2000019 Timers: message age 0, forward delay 0, hold 0 Number of transitions to forwarding state: 0 Link type is point-to-point by default, Internal Loop guard is enabled by default on the port BPDU: sent 1776, received 1
In dit voorbeeld, worden twee BPDUs verzonden tussen de output.
Opmerking: het STP-proces onderhoudt de BPDU: sentcounter. Dit betekent dat de teller aangeeft dat de BPDU naar de fysieke poort is verzonden en is verzonden. Controleer of de poorttellers toenemen voor verzonden multicast-pakketten. Geef de opdracht tegenstanders van interface-interface uit. Dit kan helpen bij het bepalen van de BPDU-verkeersstroom.
cat#show interface g3/1 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Gi3/1 127985312 83776 812319 19 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Gi3/1 131825915 3442 872342 386 cat# show interface g3/1 counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Gi3/1 127985312 83776 812319 19 Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts Gi3/1 131826447 3442 872346 386
Met al deze stappen is het idee om de switch of link te vinden waar BPDU's niet ontvangen, verzonden of verwerkt worden. Het is mogelijk dat STP de juiste staat voor de haven heeft berekend, maar wegens een kwestie van het controlevliegtuig, kan het deze staat op de het door:sturen hardware niet plaatsen. Er kan een lus worden gemaakt als de poort niet op hardwareniveau is geblokkeerd. Als u denkt dat dit een probleem is in uw netwerk, neemt u contact op met Cisco Technical Support voor verdere assistentie.
Zodra het apparaat of de verbinding die de lijn veroorzaakt wordt gevonden, moet dit apparaat van het netwerk worden geïsoleerd, of de kwestie moet worden opgelost.(zoals vervang de vezel of GBIC). De redundante koppelingen, die in Stap 3 zijn losgekoppeld, moeten worden hersteld.
Het is belangrijk om het apparaat of de verbinding niet te manipuleren dat de lijn veroorzaakt, omdat vele voorwaarden die tot een lijn leiden voorbijgaand, intermitterend, en onstabiel zijn. Dit betekent dat, als de conditie wordt gezuiverd in of na onderzoek, de conditie niet gedurende enige tijd voorkomt of helemaal niet. De voorwaarde moet worden geregistreerd zodat de technische ondersteuning van Cisco de voorwaarde verder kan onderzoeken. Het is belangrijk dat u informatie over de conditie verzamelt voordat u de switches opnieuw stelt. Als een voorwaarde is verdwenen, is het onmogelijk om de worteloorzaak van de lijn te bepalen. Als u de informatie verzamelt, zorgt u ervoor dat dit probleem niet opnieuw de lus veroorzaakt. Raadpleeg het gedeelte Netwerk beveiligen tegen doorsturen van lus voor meer informatie.
De rol van het mechanisme van de Verandering van de Topologie (TC) is L2 het door:sturen tabellen te verbeteren nadat de topologie is veranderd. Dit is noodzakelijk om een connectiviteitsstroomuitval te voorkomen, omdat MAC-adressen die eerder toegankelijk waren via bepaalde poorten kunnen veranderen en toegankelijk worden via verschillende poorten. TC verkort de doorsturen tabelpagina op alle switches in het VLAN waar de TC voorkomt. Zo, als het adres niet opnieuw wordt verdiend, het uit en de overstroming komt voor om pakketten te verzekeren het adres van bestemmingsMAC bereiken.
TC wordt geactiveerd door de wijziging van de STP-status van een poort in of uit de STP-verzendingsstaat. Na TC, zelfs als het specifieke adres van bestemmingsMAC is verouderd, overstroming niet voor lang. Het adres wordt opnieuw verdiend door het eerste pakket dat afkomstig is van de host waarvan het MAC-adres is verouderd. De kwestie kan zich voordoen wanneer TC herhaaldelijk voorkomen, met korte intervallen. De switches verouderen voortdurend hun uitroltafels, zodat overstromingen bijna constant kunnen zijn.
Opmerking: met Rapid STP of Multiple STP (IEEE 802.1w en IEEE 802.1s) wordt TC geactiveerd door een wijziging van de status van de poort naar doorsturen, evenals de rolverandering van aangewezen toroot. Met Rapid STP wordt de L2-doorvoertabel direct doorgespoeld, in tegenstelling tot 802.1d, wat de verouderingstijd verkort. Het onmiddellijk doorspoelen van de voorwaartse tabel herstelt de connectiviteit sneller, maar kan meer overstromingen veroorzaken
TC is een zeldzame gebeurtenis in een goed geconfigureerd netwerk. Wanneer een link op een switch naar boven of beneden gaat, is er uiteindelijk een TC, zodra de STP status van de poort is veranderd in of van doorsturen. Als de haven klapt, veroorzaakt dit herhaaldelijke TC's en overstromingen.
Poorten waarvoor de STP-portfast-functie is ingeschakeld, kunnen geen TC's veroorzaken wanneer ze naar of van de status van doorsturen gaan. De configuratie van portfast op alle eindapparaatpoorten (zoals printers, pc's en servers) kan TC's tot een laag bedrag beperken en wordt ten zeerste aanbevolen.
Als er herhaalde TC's op het netwerk zijn, moet u de bron van deze TC's identificeren en actie ondernemen om ze te verminderen, om de overstroming tot een minimum te beperken.
Met 802.1d, wordt de informatie STP over een TC gebeurtenis verspreid onder de bruggen door een TC Kennisgeving (TCN), die een speciaal type van BPDU is. Als u de poorten volgt die TCN BPDU's ontvangen, kunt u het apparaat vinden dat de TC's heeft voortgebracht.
U kunt bepalen dat er overstroming van langzame prestaties is, pakketdalingen op verbindingen die niet verondersteld worden om worden verstopt, en de pakketanalyzer toont meerdere unicastpakketten aan de zelfde bestemming die niet op het lokale segment is. Raadpleeg Unicast Flooding in Switched Campus Networks voor meer informatie over het overstromen van unicast.
Op een Catalyst 6500/6000 waarop Cisco IOS-software wordt uitgevoerd, kunt u de teller van de voorwaartse motor (alleen op de Supervisor 2-motor) controleren om de hoeveelheid overstromingen te schatten. Geef de switch van de afstandsbediening vroegtijdige statistieken weer | In MISS_DA|ST_FRcommando:
cat#remote command switch show earl statistics | i MISS_DA|ST_FR ST_MISS_DA = 18 530308834 ST_FRMS = 97 969084354 cat#remote command switch show earl statistics | i MISS_DA|ST_FR ST_MISS_DA = 4 530308838 ST_FRMS = 23 969084377
In dit voorbeeld toont de eerste kolom de verandering sinds de laatste keer dat deze opdracht is uitgevoerd, en de tweede kolom toont de cumulatieve waarde sinds de laatste herstart. De eerste regel toont de hoeveelheid overstroomde frames en de tweede regel toont de hoeveelheid verwerkte frames. Als de twee waarden dicht bij elkaar liggen, of de eerste waarde stijgt met een hoog tempo, kan het dat de switch overspoelt verkeer. Dit kan echter alleen worden gebruikt in combinatie met andere manieren om overstromingen te controleren, aangezien de tellers niet korrelig zijn. Er is één teller per switch, niet per poort of VLAN. Het is normaal om sommige overstromende pakketten te zien, aangezien de switch altijd kan overstromen als het adres van bestemmingsMAC niet in de het door:sturen lijst is. Dit kan het geval zijn wanneer de switch een pakketje ontvangt met een doeladres dat nog niet is aangeleerd.
Als het VLAN-nummer bekend is voor het VLAN waar buitensporige overstroming optreedt, controleert u de STP-tellers om te zien of het aantal TC’s hoog is of regelmatig toeneemt. Geef de opdracht Spanning-Tree VLAN VLAN-id uit (in dit voorbeeld wordt VLAN 1 gebruikt):
cat#show spanning-tree vlan 1 detail VLAN0001 is executing the ieee compatible Spanning Tree protocol Bridge Identifier has priority 32768, sysid 1, address 0007.0e8f.04c0 Configured hello time 2, max age 20, forward delay 15 Current root has priority 0, address 0007.4f1c.e847 Root port is 65 (GigabitEthernet2/1), cost of root path is 119 Topology change flag not set, detected flag not set Number of topology changes 1 last change occurred 00:00:35 ago from GigabitEthernet1/1 Times: hold 1, topology change 35, notification 2 hello 2, max age 20, forward delay 15 Timers: hello 0, topology change 0, notification 0, aging 300
Als het VLAN-nummer niet bekend is, kunt u de pakketanalyzer gebruiken of de TC-tellers op alle VLAN’s controleren.
U kunt het aantal van topologie controleren veranderingsteller om te zien of het regelmatig stijgt. Verplaats vervolgens naar de brug die is verbonden met de poort die wordt weergegeven, om de laatste TC te ontvangen (in het vorige voorbeeld, poort Gigabit Ethernet1/1) en zie waar de TC kwam voor die brug. Dit proces moet worden herhaald tot de eindstation poort zonder STP portfast ingeschakeld is, of tot de flappende link gevonden is die moet worden hersteld. De hele procedure moet worden herhaald als TC's uit andere bronnen afkomstig zijn. Als de link tot een end-host behoort, kunt u de portfast-functie configureren om de generatie van TC's te voorkomen.
Opmerking: in de Cisco IOS-software STP-implementatie kan de teller voor TC’s alleen worden verhoogd als een TCN BPDU wordt ontvangen door een poort in een VLAN. Als een normale configuratie BPDU met een TC-vlag wordt ontvangen, wordt de TC-teller niet verhoogd. Dit betekent dat, als je denkt dat een TC de reden is voor overstroming, de bronnen voor de TC vanaf de STP-root-brug in dat VLAN zullen worden opgespoord. Het kan de meest nauwkeurige informatie hebben over het aantal en de bron van de TC's.
Er zijn situaties waarin de eigenlijke werking van STP niet overeenkomt met het verwachte gedrag. Dit zijn de twee meest voorkomende problemen:
STV-convergentie of reconvergentie duurt langer dan verwacht.
Het topologieresultaat is anders dan verwacht.
Meestal zijn dit de redenen voor dit gedrag:
Een wanverhouding tussen de echte en gedocumenteerde topologie.
Misconfiguratie, zoals een inconsistente configuratie van STP timers, een STP diameter die toeneemt, of portfast misconfiguratie.
Overload switch CPU tijdens convergentie of reconvergentie.
Softwaredefect.
Zoals eerder vermeld, kan dit document alleen algemene richtlijnen bieden voor probleemoplossing, vanwege de grote verscheidenheid aan problemen die van invloed kunnen zijn op STP. Om te begrijpen waarom het convergeren langer duurt dan verwacht, bekijk de opeenvolging van gebeurtenissen STP om te weten te komen wat en in welke orde gebeurt. Omdat de STP-implementatie in Cisco IOS-software geen resultaten registreert (behalve voor specifieke gebeurtenissen, zoals poortinconsistenties), kunt u Cisco IOS-software gebruiken om STP te debuggen voor een helderder weergave. Voor STP, met een Catalyst 6500/6000 die Cisco IOS-software uitvoert, wordt de verwerking uitgevoerd op de Switch Processor (SP) (of Supervisor), zodat de debugs op de SP moeten worden ingeschakeld. Voor Cisco IOS-softwarebruggroepen wordt de verwerking uitgevoerd op de routeprocessor (RP), zodat de debugs op de RP (MSFC) ingeschakeld moeten worden.
Veel STPdebugcommando's zijn bedoeld voor ontwikkeltechniek gebruik. Ze leveren geen output die zinvol is voor iemand zonder gedetailleerde kennis van de STP-implementatie in Cisco IOS-software. Sommige debugs kunnen output leveren die direct leesbaar is, zoals wijzigingen in de poortstatus, rolveranderingen, gebeurtenissen zoals TC’s en een dump van ontvangen en verzonden BPDU’s. Deze sectie geeft geen volledige beschrijving van alle debugs, maar introduceert kort de meest gebruikte.
Opmerking: wanneer u debugcommando's gebruikt, dient u de minimaal noodzakelijke debugs in te schakelen. Als real-time debugs niet nodig zijn, registreer de uitvoer naar het logbestand in plaats van het af te drukken naar de console. Excessieve debugs kunnen de CPU overbelasten en de werking van de switch verstoren.
Als u wilt dat de debug-uitvoer naar het logbestand in plaats van naar de console of naar Telnet-sessies wordt verzonden, geeft u de logboekinformatie en geen registratieopdrachten in de globale configuratiemodus uit. Om het algemene gebeurtenissenlogboek te zien, geef het debug Spanning-Tree gebeurtenisbevel voor Per VLAN Spanning-Tree (PVST) en Rapid-PVST uit. Dit is de eerste debug die informatie geeft over wat er is gebeurd met de STP. In de modus Multiple Spanning-Tree (MST) werkt het niet om de opdracht debug Spanning-Tree Event uit te geven. Daarom geef het debug Spanning-Tree mstp rolescommando uit om de poortrol te zien veranderen. Als u de wijzigingen in de poort-STP-status wilt zien, geeft u de opdracht debug Spanning-Tree switch uit samen met de opdracht debug pm vpcommando:
cat-sp#debug spanning-tree switch state Spanning Tree Port state changes debugging is on cat-sp#debug pm vp Virtual port events debugging is on Nov 19 14:03:37: SP: pm_vp 3/1(333): during state forwarding, got event 4(remove) Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): forwarding -> notforwarding port 3/1 (was forwarding) goes down in vlan 333 Nov 19 14:03:37: SP: *** vp_fwdchange: single: notfwd: 3/1(333) Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): notforwarding -> present Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/1(333) Nov 19 14:03:37: SP: @@@ pm_vp 3/1(333): present -> not_present Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/1(333) Nov 19 14:03:37: SP: pm_vp 3/2(333): during state notforwarding, got event 4(remove) Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): notforwarding -> present Nov 19 14:03:37: SP: *** vp_linkchange: single: down: 3/2(333) Port 3/2 (was not forwarding) in vlan 333 goes down Nov 19 14:03:37: SP: @@@ pm_vp 3/2(333): present -> not_present Nov 19 14:03:37: SP: *** vp_statechange: single: remove: 3/2(333) Nov 19 14:03:53: SP: pm_vp 3/1(333): during state not_present, got event 0(add) Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): not_present -> present Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/1(333) Nov 19 14:03:53: SP: pm_vp 3/1(333): during state present, got event 8(linkup) Nov 19 14:03:53: SP: @@@ pm_vp 3/1(333): present -> notforwarding Nov 19 14:03:53: SP: STP SW: Gi3/1 new blocking req for 0 vlans Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/1(333) Port 3/1 link goes up and blocking in vlan 333 Nov 19 14:03:53: SP: pm_vp 3/2(333): during state not_present, got event 0(add) Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): not_present -> present Nov 19 14:03:53: SP: *** vp_statechange: single: added: 3/2(333) Nov 19 14:03:53: SP: pm_vp 3/2(333): during state present, got event 8(linkup) Nov 19 14:03:53: SP: @@@ pm_vp 3/2(333): present -> notforwarding Nov 19 14:03:53: SP: STP SW: Gi3/2 new blocking req for 0 vlans Nov 19 14:03:53: SP: *** vp_linkchange: single: up: 3/2(333) Port 3/2 goes up and blocking in vlan 333 Nov 19 14:04:08: SP: STP SW: Gi3/1 new learning req for 1 vlans Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 0 vlans Nov 19 14:04:23: SP: STP SW: Gi3/1 new forwarding req for 1 vlans Nov 19 14:04:23: SP: pm_vp 3/1(333): during state notforwarding, got event 14(forward_notnotify) Nov 19 14:04:23: SP: @@@ pm_vp 3/1(333): notforwarding -> forwarding Nov 19 14:04:23: SP: *** vp_list_fwdchange: forward: 3/1(333) Port 3/1 goes via learning to forwarding in vlan 333
Om te begrijpen waarom STP zich op een bepaalde manier gedraagt, is het vaak handig om de BPDU's te zien die door de switch worden ontvangen en verzonden:
cat-sp#debug spanning-tree bpdu receive Spanning Tree BPDU Received debugging is on Nov 6 11:44:27: SP: STP: VLAN1 rx BPDU: config protocol = ieee, packet from GigabitEthernet2/1 , linktype IEEE_SPANNING , enctype 2, encsize 17 Nov 6 11:44:27: SP: STP: enc 01 80 C2 00 00 00 00 06 52 5F 0E 50 00 26 42 42 03 Nov 6 11:44:27: SP: STP: Data 0000000000000000074F1CE8470000001380480006525F0E4 080100100140002000F00 Nov 6 11:44:27: SP: STP: VLAN1 Gi2/1:0000 00 00 00 000000074F1CE847 00000013 80480006525F0E40 8010 0100 1400 0200 0F00
Dit debug werkt voor PVST, Rapid-PVST, en MST modi; maar het decodeert niet de inhoud van BPDUs. U kunt deze knop echter gebruiken om er zeker van te zijn dat BPDU's worden ontvangen. Om de inhoud van BPDU te zien, geef dedebug over:spannen-tree switch rx-decodecommando samen met dedebug over:spannen-tree switch rx procesbevel voor PVST en Rapid-PVST uit. Geef de debug Spanning-Tree mstp bpdu-rxopdracht uit om de inhoud van de BPDU voor MST te zien:
cat-sp#debug spanning-tree switch rx decode Spanning Tree Switch Shim decode received packets debugging is on cat-sp#debug spanning-tree switch rx process Spanning Tree Switch Shim process receive bpdu debugging is on Nov 6 12:23:20: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026 Nov 6 12:23:20: SP: encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1 Nov 6 12:23:20: SP: 42 42 03 SPAN Nov 6 12:23:20: SP: CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013 Nov 6 12:23:20: SP: B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00 Nov 6 12:23:22: SP: STP SW: PROC RX: 0180.c200.0000<-0006.525f.0e50 type/len 0026 Nov 6 12:23:22: SP: encap SAP linktype ieee-st vlan 1 len 52 on v1 Gi2/1 Nov 6 12:23:22: SP: 42 42 03 SPAN Nov 6 12:23:22: SP: CFG P:0000 V:00 T:00 F:00 R:0000 0007.4f1c.e847 00000013 Nov 6 12:23:22: SP: B:8048 0006.525f.0e40 80.10 A:0100 M:1400 H:0200 F:0F00
Voor de MST-modus kunt u gedetailleerde BPDU-decodering inschakelen met deze debugopdracht:
cat-sp#debug spanning-tree mstp bpdu-rx Multiple Spanning Tree Received BPDUs debugging is on Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated] Nov 19 14:37:43: SP: MST: Proto:0 Version:3 Type:2 Role: DesgFlags[ F ] Nov 19 14:37:43: SP: MST: Port_id:32897 cost:2000019 Nov 19 14:37:43: SP: MST: root_id :0007.4f1c.e847 Prio:0 Nov 19 14:37:43: SP: MST: br_id :00d0.003f.8800 Prio:32768 Nov 19 14:37:43: SP: MST: age:2 max_age:20 hello:2 fwdelay:15 Nov 19 14:37:43: SP: MST: V3_len:90 PathCost:30000 region:STATIC rev:1 Nov 19 14:37:43: SP: MST: ist_m_id :0005.74 Nov 19 14:37:43: SP: MST:BPDU DUMP [rcvd_bpdu Gi3/2 Repeated] Nov 19 14:37:43: SP: MST: Proto:0 Version:3 Type:2 Role: DesgFlags[ F ] Nov 19 14:37:43: SP: MST: Port_id:32897 cost:2000019 Nov 19 14:37:43: SP: MST: root_id :0007.4f1c.e847 Prio:0 Nov 19 14:37:43: SP: MST: br_id :00d0.003f.8800 Prio:32768 Nov 19 14:37:43: SP: MST: age:2 max_age:20 hello:2 fwdelay:15 Nov 19 14:37:43: SP: MST: V3_len:90 PathCost:30000 region:STATIC rev:1 Nov 19 14:37:43: SP: MST: ist_m_id :0005.7428.1440 Prio:32768 Hops:18 Num Mrec: 1 Nov 19 14:37:43: SP: MST: stci=3 Flags[ F ] Hop:19 Role:Desg [Repeated] Nov 19 14:37:43: SP: MST: br_id:00d0.003f.8800 Prio:32771 Port_id:32897 Cost:2000028.1440 Prio:32768 Hops:18 Num Mrec: 1 Nov 19 14:37:43: SP: MST: stci=3 Flags[ F ] Hop:19 Role:Desg [Repeated] Nov 19 14:37:43: SP: MST: br_id:00d0.003f.8800 Prio:32771 Port_id:32897 Cost:20000
Opmerking: voor Cisco IOS-softwarerelease 12.1.13E en hoger worden voorwaardelijke debugs voor STP ondersteund. Dit betekent dat u BPDU's kunt debuggen die worden ontvangen of verzonden op een per-poort of per-VLAN-basis.
Geef debug voorwaarde vlan VLAN_num uit of debug de bevelen van de voorwaardeninterface, om het werkingsgebied van te beperken debug output aan per-interface of per-VLAN.
Cisco heeft een aantal functies en verbeteringen ontwikkeld om de netwerken te beschermen tegen doorsturen van lusjes wanneer een STP niet in staat is bepaalde storingen te beheren.
Wanneer u problemen oplossen met STP, helpt het om de oorzaak van een bepaalde fout te isoleren en mogelijk te vinden, terwijl de implementatie van deze verbeteringen de enige manier is om het netwerk te beveiligen tegen het doorsturen van lijnen.
Dit zijn methodes om uw netwerk tegen het door:sturen van lijnen te beschermen:
Raadpleeg voor meer informatie over UDLD begrip en configuratie van de functie voor unidirectionele linkdetectie-protocol.
Raadpleeg voor meer informatie over Loop Guard Spanning-Tree Protocol-verbeteringen met Loop Guard en BPDU Skew Detection-functies.
Als deze optie is ingeschakeld, elimineren UDLD en Loop Guard de meeste oorzaken van het doorsturen van lussen. In plaats van een doorschakellus te maken, sluit de defecte link (of alle links afhankelijk van de defecte hardware) af of worden geblokkeerd.
Opmerking: hoewel deze twee functies enigszins redundant lijken, heeft elk hun eigen unieke mogelijkheden. Gebruik daarom beide functies tegelijkertijd om het hoogste beschermingsniveau te bieden. Raadpleeg voor een gedetailleerde vergelijking van UDLD en Loop Guard Loop Guard vs. Unidirectionele linkdetectie.
Er zijn verschillende meningen over de vraag of je agressieve of normale UDLD moet gebruiken. De agressieve UDLD kan niet meer bescherming bieden tegen lussen in vergelijking met de normale UDLD. Aggressive UDLD detecteert poortstuck scenario's (wanneer de link is omhoog, maar er zijn geen bijbehorende verkeersmazen). Het nadeel van deze toegevoegde functionaliteit is dat agressieve UDLD mogelijk koppelingen kan uitschakelen wanneer er geen consistente fout aanwezig is. Vaak verwarren mensen de wijziging van het UDLDhellointerval met de agressieve UDLD eigenschap. Dit klopt niet. De timers kunnen in beide UDLD-modi worden gewijzigd.
Opmerking: in zeldzame gevallen kan een agressieve UDLD alle uplinkpoorten afsluiten, waardoor de switch in feite wordt geïsoleerd van de rest van het netwerk. Dit kan bijvoorbeeld gebeuren wanneer beide upstream switches extreem hoge CPU-gebruik ervaren en er agressieve modus UDLD wordt gebruikt. Daarom wordt geadviseerd dat u tijden outs vormt die niet kunnen eroderen, als de switch niet out-of-band beheer op zijn plaats heeft.
U moet portfast inschakelen om de hoeveelheid TC's en de daaropvolgende overstroming te beperken, wat de prestaties van het netwerk kan beïnvloeden. Gebruik deze opdracht alleen met poorten die verbinding maken met eindstations. Anders kan een onbedoelde topologielijn een gegevenspakketlus veroorzaken en de switch- en netwerkwerking verstoren.
Waarschuwing: voorzichtigheid is geboden wanneer u de opdracht no Spanning-tree portfast gebruikt. Deze opdracht verwijdert alleen poortspecifieke poortfast-opdrachten. Deze opdracht laat impliciet portfast toe als u het overspannen-boom portfast standaardbevel op globale configuratiewijze bepaalt en als de haven geen trunkhaven is. Als u poortfast niet wereldwijd vormt, is de opdracht no Spanning-tree portfast gelijk aan de opdracht Spanning-tree portfast deactiveren.
Desirablemode kan Port Aggregation Protocol (PAgP) in staat stellen om de runtime consistentie tussen de kanaalpeers te verzekeren. Dit geeft een extra mate van bescherming tegen lusjes, vooral tijdens kanaalherconfiguraties (zoals wanneer de verbindingen zich bij het kanaal aansluiten of verlaten, en de opsporing van de verbindingsmislukking). Er is een ingebouwde Channel MisConfiguration Guard, die standaard is ingeschakeld en die het doorsturen van loops verhindert vanwege kanaalmisconfiguratie of andere omstandigheden. Zie Inconsistentiedetectie van EtherChannel voor meer informatie over deze functie.
Auto-onderhandeling mechanismen kunnen verre fouteninformatie overbrengen, die de snelste manier is om mislukking aan de verre kant te ontdekken. Als de fout wordt gedetecteerd aan de kant van de afstandsbediening, brengt de lokale kant de link naar beneden, zelfs als de link pulsen krijgt. Vergeleken met detectiemechanismen op hoog niveau zoals UDLD is automatisch onderhandelen extreem snel (binnen microseconden), maar mist de end-to-end dekking van UDLD (zoals de gehele datapath: CPU—doorsturen van logica—poort1—poort2—doorsturen van logica—CPU tegenover poort1—poort2). Agressieve UDLD-modus biedt dezelfde functionaliteit als automatische onderhandeling met betrekking tot de detectie van storingen. Wanneer de onderhandeling aan beide kanten van de verbinding wordt gesteund, is er geen behoefte om agressieve wijze UDLD toe te laten.
STP-timers zijn afhankelijk van elkaar en van de netwerktopologie. STP werkt niet correct met willekeurige die wijzigingen aan de timers worden gemaakt. Raadpleeg voor meer informatie over STP-timers het begrip en de afstemming van Spanning Tree Protocol-timers.
Met Root Guard en BPDU Guard kunt u STP beveiligen tegen invloed van buitenaf. Als zo'n aanval mogelijk is, moeten Root Guard en BPDU Guard worden gebruikt om het netwerk te beschermen. Raadpleeg voor meer informatie over Root Guard en BPDU Guard deze documenten:
Als u Root Guard correct vormt, voorkomt het STP invloed van de buitenkant. Als BPDU Guard is ingeschakeld, worden de poorten die BPDU's ontvangen, uitgeschakeld. Dit is handig om incidenten te onderzoeken, omdat BPDU Guard het syslog-bericht produceert en de poort sluit. Als Root- of BPDU-bewakers geen korte cyclusverbindingen voorkomen, dan verbinden twee snel ingeschakelde poorten direct of via de hub.
Het beheer VLAN is ingesloten in een bouwsteen, niet in het gehele netwerk.
De switch Management Interface ontvangt uitzendingspakketten op het beheer VLAN. Als er buitensporige uitzendingen optreden (zoals een broadcast-storm of een defecte toepassing), kan de switch-CPU worden overbelast, wat mogelijk de STP-werking kan vervormen.
De STP root en back-up STP root moeten zo geconfigureerd zijn dat convergentie, in het geval van storingen, op een voorspelbare manier plaatsvindt en in elk scenario een optimale topologie opbouwt. Laat de STP-prioriteit niet achter bij de standaardwaarde om onvoorspelbare root switch selectie te voorkomen.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
4.0 |
28-Aug-2024 |
Bijgewerkt SEO, en het Formatteren. |
3.0 |
18-Jul-2023 |
Bijgewerkte Inleiding, SEO, Branding Vereisten, Machinevertaling, Stijl Vereisten en het Formatteren. |
2.0 |
28-Jun-2022 |
De opmaak alleen herzien voor recente en externe publicatie. |
1.0 |
19-Nov-2002 |
Eerste vrijgave |