Problemen oplossen: Spanning Tree PVID- en type-inconsistenties
Inhoud
Inleiding Voorwaarden Vereisten
Gebruikte componenten Conventies
Theorie achter PVID- en Type-inconsistenties Probleemoplossing
Gerelateerde informatie
Inleiding
In Layer 2 (L2) netwerken kan er slechts één pad tussen twee apparaten zijn. Redundantie wordt ondersteund met Spanning-Tree Protocol (STP), dat redundante paden detecteert en blokkeert, en daardoor lusvorming vermijdt. Bepaalde fouten kunnen tot STP-storing leiden en
netwerkstoring veroorzaken. Om downtime te voorkomen, werden bepaalde verbeteringen
geïmplementeerd zodat STP bepaalde gevallen van configuratie van het systeem detecteert en de relevante poort in een "inconsistente" staat wordt gezet.
Er kunnen verschillende typen STP-inconsistenties zijn:
Inconsistentie loop: dit wordt gedetecteerd door de functie Loop Guard. Raadpleeg voor meer informatie de verbeteringen in Spanning-Tree Protocol met Loop Guard en BPDU Skew Detectie-functies.
●
Opstarten inconsistentie: dit wordt gedetecteerd door de optie Root Guard. Raadpleeg voor meer informatie de Verbetering in Spanning-Tree Protocol Root Guard.
●
EtherChannel-inconsistentie-Dit wordt gedetecteerd door de EtherChannel-detectie optie.
Raadpleeg voor meer informatie het gedeelte EtherChannel Inconsistentie detecteren.
●
Port VLAN ID (PVID) inconsistentie-A per-VLAN omspannende boom (PVST+) Bridge Data Unit (BPDU) wordt ontvangen op een ander VLAN dan dat er oorspronkelijk uit kwam: (Port
VLAN ID Mismatch of *PVID_Inc).
●
Type inconsistentie-A PVST+ BPDU wordt ontvangen op een niet-802.1Q stam.
●
Dit document legt uit hoe u de oorzaak van de laatste twee inconsistenties, PVID en type, kunt oplossen. Raadpleeg de eerder genoemde documenten voor het oplossen van andere
inconsistenties.
Voorwaarden
Vereisten
Lezers van dit document zouden kennis moeten hebben van STP-concepten.
Gebruikte componenten
Dit document is niet beperkt tot specifieke software- of hardwareversies.
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 de potentiële impact van elke opdracht begrijpen.
Conventies
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
Theorie achter PVID- en Type-inconsistenties
Cisco Catalyst switches implementeren PVST met Inter-Switch Link (ISL) trunks. Dankzij de ondersteuning van IEEE 802.1Q en ISL trunking was er een manier nodig voor samenwerking tussen PVST en het IEEE 802.1Q-concept van één enkele overspannende boom voor alle VLAN’s. Om aan deze eis te voldoen is de functie PVST+ geïntroduceerd.
Opmerking: Vanuit het STP-standpunt is IEEE 802.1D niet VLAN-bewust en is IEEE 802.1Q VLAN-bewust, maar het gebruikt één enkele STP-instantie voor alle VLAN’s. Dat wil zeggen, als de haven blokkeert dan blokkeert het voor alle VLAN's op die haven. Hetzelfde geldt voor het doorsturen.
Deze lijst toont hoe PVST+ met IEEE 802.1Q of IEEE 802.1D interopereert als het inheemse VLAN op een stam van IEEE 802.1Q VLAN 1 is:
VLAN 1 STP-BPDU’s worden naar het IEEE STP MAC-adres (10.8.00.c200.000) verzonden.
●
VLAN 1 STP BPDU's worden ook naar het PVST+ MAC-adres verzonden, zonder tag.
●
Niet-VLAN 1 STP-BPDU’s worden naar het MAC-adres van PVST+ verzonden (ook wel het MAC-adres van het gedeelde Spanning Tree Protocol [SSTP] genoemd, C0100.0cc.ccd), met een corresponderende VLAN-tag van IEEE 802.1Q.
●
Als het native VLAN op een IEEE 802.1Q stam niet VLAN 1 is:
VLAN 1 STP-BPDU’s worden naar het MAC-adres van PVST+ verzonden en voorzien van een bijbehorende IEEE 802.1Q VLAN-tag.
●
VLAN 1 STP-BPDU’s worden ook naar het IEEE STP MAC-adres op het Native VLAN van de IEEE 802.1Q-stam verzonden, zonder tag.
●
Niet-VLAN 1 STP-BPDU’s worden naar het MAC-adres van PVST+ verzonden en voorzien van een bijbehorende IEEE 802.1Q VLAN-tag.Opmerking: BPDU’s van native VLAN-VLAN’s worden niet-gelabeld verzonden.
●
Op deze manier combineert VLAN 1 STP van PVST+ met STP van IEEE 802.1D of 802.1Q, terwijl andere VLAN’s door de cloud van IEEE 802.1D of 802.1Q bruggen worden gedraaid.
Bijvoorbeeld, de wolk van IEEE 802.1D of 802.1Q lijkt op een "draad" aan PVST+ VLANs anders dan 1.
Voor STP om correct te functioneren, observeer bepaalde regels wanneer u PVST+ bruggen aan de bruggen van IEEE 802.1D of 802.1Q verbindt. De belangrijkste regel is dat PVST+-bruggen moeten worden aangesloten op IEEE 802.1D of 802.1Q bruggen door een IEEE 802.1Q stam met een consistent Native VLAN op alle bruggen die aan de cloud van IEEE 802.1Q of 802.1D
bruggen verbinden.
De PVST+ BPDU bevat een VLAN-nummer dat PVST+ bruggen toestaat om te ontdekken of de vorige regel niet wordt gerespecteerd. Wanneer een Catalyst-schakelaar een misconfiguratie detecteert, worden de corresponderende poorten in een "PVID-inconsistente" of "type-
inconsistente" staat geplaatst, die effectief het verkeer in het corresponderende VLAN op een corresponderende poort blokkeert. Deze staten verhinderen het verzenden loops die
misconfiguraties of misbedrading veroorzaken.
Om de behoefte aan inconsistentiedetectie te illustreren, neem deze topologie in acht, waar de switches A en C PVST+ STP en switch B 802.1Q STP uitvoeren:
Als de BPDU van de wortel in VLAN 1 beter is dan BPDU van de wortel in VLAN 2 dan is er geen blokkerende haven in de VLAN 2 topologie. De BPDU van VLAN 2 maakt nooit een "volledige cirkel" rond de topologie; het wordt vervangen door VLAN 1 BPDU op de B-C verbinding, omdat B slechts één STP met VLAN 1 STP van PVST+ loopt. Er is dus een doorvoerlus. Gelukkig,
verstuurt schakelaar A PVST+ BPDUs van VLAN 2 (naar het SSTP adres dat door schakelaar B wordt overstroomd) naar schakelaar C. De switch C zal poort C-B in een type-inconsistente staat
plaatsen, die de lus verhindert.
Opmerking: in sommige commando outputs wordt de *-inconsistente STP status 'gebroken' genoemd.
Wanneer STP-inconsistentie wordt gedetecteerd, sturen switches deze syslog-berichten:
%SPANTREE-2-RECV_1Q_NON_TRUNK: Received IEEE 802.1Q BPDU on non trunk FastEthernet0/1 on vlan 1.
%SPANTREE-2-BLOCK_PORT_TYPE: Blocking FastEthernet0/1 on vlan 1.
Inconsistent port type.
%SPANTREE-2-RX_1QPVIDERR: Rcved pvid_inc BPDU on 1Q port 3/25 vlan 1
%SPANTREE-2-RX_BLKPORTPVID: Block 3/25 on rcving vlan 1 for inc peer vlan 10
%SPANTREE-2-TX_BLKPORTPVID: Block 3/25 on xmtting vlan 10 for inc peer vlan
In dat voorbeeld is VLAN 1 waar de BPDU werd ontvangen, en VLAN 10 is waar de BPDU ontstond. Wanneer inconsistentie wordt gedetecteerd, worden beide VLAN’s geblokkeerd in de poort waar deze BPDU is ontvangen
Opmerking: Berichten kunnen verschillen op basis van het type en de versie van het Cisco IOS®
Software release of Catalyst OS (CatOS) besturingssysteem dat in gebruik is.
Opmerking: Als de poort stopt met het ontvangen van inconsistente BPDU's wordt de *-
inconsistente status gewist en STP verandert de poortstatus op basis van normale STP-activiteit.
Er wordt een syslogbericht verzonden om de wijziging aan te geven:
%SPANTREE-SP-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet0/1 on vlan 1.
Port consistency restored.
Voor meer informatie over werking PVST+, verwijs naar Overbrugging tussen IEEE 802.1Q VLAN.
Probleemoplossing
Om de lijst van inconsistente poorten te zien, steunt de recente op Cisco IOS gebaseerde STP implementatie de show in-boom inconsistente poorten opdracht.
In de meeste gevallen is de reden voor het opsporen van STP-inconsistentie in de haven duidelijk:
Toegangspoort ontvangt een IEEE 802.1Q-gelabeld SSTP
BPDU. In dit scenario
ontvangt de toegangpoort op brug A, van brug B, een gelabelde PVST+ BPDU van STP van een VLAN anders dan 1. De haven op A zal in type-onsamenhangende staat worden
geplaatst.Opmerking: de schakelaars hoeven niet rechtstreeks aan te sluiten; als zij door één
●
of meer IEEE 802.1D of IEEE 802.1Q switches - of zelfs hubs - worden aangesloten, is het effect hetzelfde.
De trunking-poort van IEEE 802.1Q ontvangt een niet-gelabelde SSTP BPDU met een VLAN- type, -lengte en -waarde (TLV) die niet overeenkomen met het VLAN waar de BPDU is
ontvangen. In dit
scenario, ontvangt de boomstampoort op A een PVST+ BPDU van STP van VLAN 2 met een tag van VLAN 2. Dit leidt de haven op A in om in zowel VLAN 1 als VLAN 2 te worden
geblokkeerd.
●
Als apparaten op beide eindpunten van een point-to-point link Cisco Catalyst switches zijn, dan blijkt een onderzoek van de lokale en externe poortconfiguratie doorgaans de configuratie- dismatch:
De poort is ingesteld voor IEEE 802.1Q-trunking aan de ene kant, maar de andere kant is toegangpoort.
●
De trunks IEEE 802.1Q zijn aan beide zijden, maar de inheemse VLAN’s zijn anders.
●
In deze gevallen, bevestig de configuratie mismatch om de STP inconsistentie op te lossen.
In sommige gevallen is het misschien niet zo makkelijk om de reden te vinden:
Een BPDU wordt ontvangen van een gedeeld medium met meerdere apparaten.
●
Er wordt een BPDU ontvangen vanuit de switchcloud, die implementeert van een IEEE 802.1D- of 802.1Q STP-model terwijl PVST+-switches op de cloud zijn aangesloten.
●
Een BPDU komt van achter een bepaalde tunnel (bijvoorbeeld Data Link Switch Plus [DLSw+]-cloud, L2-protocol-tunneling, EoMPLS, Virtual Path Links [VPL’s], LAN-emulatie [LANE] en anderen).
●
In dit voorbeeld wordt schakelaar B verkeerd ingesteld en wordt een SSTP BPDU in de cloud geïnjecteerd. Dit zorgt ervoor dat de poorten op de switches A, C en D inconsequent zijn. De kwestie is dat het apparaat dat aan de "beledigende" BPDU voortkomt niet direct op de getroffen switches is aangesloten. Dus met veel apparaten in de romp, zou het tijdrovend kunnen worden om alle problemen op te lossen.
Gelukkig is er een systematische benadering van het oplossen van dit probleem:
Het bron-MAC-adres vaststellen en bridge-ID van de BPDU verzenden. Dit moet gebeuren zolang de kwestie zich voordoet.
1.
Vind de brug die voortkomt uit de "beledigende" BPDU. Dit kan op een later tijdstip worden gedaan, niet noodzakelijk wanneer het probleem zich voordoet.
2.
Voor Stap 1 zijn er doorgaans twee opties: Gebruik een pakketanalyzer of laat debug in om het dumpen van ontvangen BPDU’s te zien.
Voor meer informatie over het gebruik van een debug om STP BPDU's te dumpen, zie het gedeelte Debugging Commands van de STP van de sectie van het Problemen opsporen en verhelpen STP op Catalyst switch die Cisco IOS (Native Mode) uitvoeren.
Dit is een voorbeeld van debug uitvoer die ontvangen BPDU toont:
*Mar 14 19:33:27: STP SW: PROC RX: 0100.0ccc.cccd<-0030.9617.4f08 type/len 0032
*Mar 14 19:33:27: encap SNAP linktype sstp vlan 10 len 64 on v10 Fa0/14
*Mar 14 19:33:27: AA AA 03 00000C 010B SSTP
*Mar 14 19:33:27: CFG P:0000 V:00 T:00 F:00 R:8000 0050.0f2d.4000 00000000
*Mar 14 19:33:27: B:8000 0050.0f2d.4000 80.99 A:0000 M:1400 H:0200 F:0F00
*Mar 14 19:33:27: T:0000 L:0002 D:0001
Zodra u het bron MAC adres en het verzenden van bridge ID kent, moet u het apparaat vinden waartoe dit MAC-adres behoort. Dit kan worden gecompliceerd door het feit dat de switches normaal geen MAC-adressen van een bron leren van BPDU-frames. Als u de opdracht
BPDU_mac_adres van de show mac-adres-lijst aangeeft (voor Cisco IOS-gebaseerde switches) of de opdracht mac_adres (voor op CatOS gebaseerde switches) dan wordt er doorgaans geen ingang gevonden.
Eén manier om het MAC-adres "offending" te vinden is door van alle switches die op de cloud zijn aangesloten, output te verzamelen van de show-overspannende-boom (voor Cisco IOS) of de show spantree (voor CatOS) opdracht. Deze opdrachtoutput bevat informatie over de bridge-ID van elke brug.
Boris# show spanning-tree
!--- Use with Cisco IOS. VLAN0001 Spanning tree enabled protocol rstp Root ID Priority 0 Address 0007.4f1c.e847 Cost 131 Port 136 (GigabitEthernet3/8) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 00d0.003f.8800 !--- Output suppressed. Doris (enable) show spantree
!--- Use with CatOS. VLAN 1 Spanning tree mode RAPID-PVST+ Spanning tree type ieee Spanning tree enabled Designated Root 00-07-4f-1c-e8-47 Designated Root Priority 0 Designated Root Cost 123 Designated Root Port 9/7 Root Max Age 20 sec Hello Time 2 sec Forward Delay 15 sec Bridge ID MAC ADDR 00-d0-03-ef-4c-00 !--- Output suppressed.
Opmerking: Afhankelijk van het model, de softwareversie en de configuratie kan een schakelaar meerdere bridge ID MAC-adressen hebben. Gelukkig zullen alle adressen doorgaans binnen een bepaald gebied liggen (bijvoorbeeld van 001.1234.5600 tot 0001.1234.5640). Als u één bridge ID MAC-adres kent, kunt u controleren of het verzendende bridge-ID MAC-adres (in Stap 1
gevonden) binnen het bereik van de gegeven bridge-ID MAC-adressen valt.
U kunt ook netwerkbeheertools gebruiken om de bridge-ID's van alle bruggen te verzamelen.
Zodra u de brug hebt gevonden die "de beledigende" BPDU stuurt, moet u de configuratie van de poort die aan de cloud is bevestigd verifiëren: Zorg ervoor dat deze consistent is (in tegenstelling tot non-trunking en Native VLAN) met andere switches die op dezelfde cloud worden aangesloten.
Het zou kunnen dat de brug echte BPDU's verstuurt, maar ze worden onjuist aangepast in de tunneling-wolk. In dat geval, kunt u zien dat de "beledigende" BPDU die de cloud ingaat consistent is met de configuratie van de andere bruggen, maar dezelfde BPDU inconsequent wordt als deze de cloud verlaat (bijvoorbeeld, de BPDU verlaat de cloud in een ander VLAN, of wordt getagd of niet getagd). In dat geval kan het helpen om te controleren of het bron-MAC-adres van de
"beledigende" BPDU tot dezelfde brug behoort als de verzendende bridge-ID. Als dit niet het geval is, kunt u proberen om de brug te vinden die het bron adres van MAC van de BPDU bezit en zijn configuratie verifiëren.
Om de switch te vinden die het bron MAC-adres van de BPDU bezit, kunt u dezelfde benadering volgen die wordt gebruikt om de bridge-ID te vinden, behalve nu wordt de opdrachtoutput van de show module geïnspecteerd (voor Catalyst 4000, 5000 en 6000). Voor Catalyst 2900 XL, 3500 XL, 2950, en 3550 moet u de uitvoer van de opdracht van de showinterface onderzoeken om de MAC adressen te zien die aan de poorten toebehoren.
Cat4000-IOS# show module
!--- Use for Catalyst 4000,5000,6000 Mod Ports Card Type Model Serial No. ----+---+--- ---+---+--- 1 2 1000BaseX (GBIC)
Supervisor(active) WS-X4515 ZZZ00000001 5 14 1000BaseT (RJ45), 1000BaseX (GBIC) WS-X4412-2GB-T ZZZ00000002 M MAC addresses Hw Fw Sw Status --+---+---+--- +---+--- 1 000a.4172.ea40 to 000a.4172.ea41 1.2 12.1(12r)EW 12.1(14)E1, EARL Ok 5 0001.4230.d800 to 0001.4230.d80d 1.0 Ok !--- Output suppressed. cat3550# show interface | i bia
Hardware is Gigabit Ethernet, address is 0002.4b28.da80 (bia 0002.4b28.da80) Hardware is Gigabit Ethernet, address is 0002.4b28.da83 (bia 0002.4b28.da83) Hardware is Gigabit Ethernet, address is 0002.4b28.da86 (bia 0002.4b28.da86) Hardware is Gigabit Ethernet, address is 0002.4b28.da88 (bia 0002.4b28.da88) Hardware is Gigabit Ethernet, address is 0002.4b28.da89 (bia 0002.4b28.da89)
!--- Output suppressed.
N.B.: Als de cloud DLSw+ is, raadpleegt u Meer begrip en het configureren van DLSw en 802.1Q.
Gerelateerde informatie
Productondersteuningspagina’s voor LAN
●
Ondersteuningspagina voor LAN-switching
●
Technische ondersteuning - Cisco-systemen
●
