Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Hintergrundinformationen

Theorie der PVID- und Typinkonsistenzen

Fehlerbehebung

Zugehörige Informationen

Einleitung

In diesem Dokument wird die Fehlerbehebung bei zwei STP-Inkonsistenzen (Spanning Tree Protocol) beschrieben: Port-VLAN-ID (PVID) und Typ.

Voraussetzungen

Anforderungen

Cisco empfiehlt, sich mit STP-Konzepten vertraut zu machen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Hintergrundinformationen

In Layer-2-Netzwerken (L2) kann es nur einen Pfad zwischen zwei Geräten geben. Redundanz wird durch das Spanning-Tree Protocol (STP) unterstützt, das redundante Pfade erkennt und blockiert und so Weiterleitungsschleifen vermeidet. Bestimmte Fehlkonfigurationen können zu einem STP-Ausfall und einem Netzwerkausfall führen. Um Ausfallzeiten zu vermeiden, wurden einige Verbesserungen implementiert, sodass STP bestimmte Fälle von Fehlkonfigurationen erkennt und der entsprechende Port in einen "inkonsistenten" Zustand versetzt wird.

Es gibt verschiedene Arten von STP-Inkonsistenzen:

- Loop Inconsistency (Schleifeninkonsistenz): Diese wird von der Funktion "Loop Guard" erkannt. Weitere Informationen finden Sie unter STP mit Loop Guard und BPDU-Skew-Erkennung konfigurieren.

- Root-Inkonsistenz - Diese wird vom Root Guard-Feature erkannt. Weitere Informationen finden Sie unter Enhance Spanning Tree Protocol with Root Guard.

- EtherChannel-Inkonsistenz: Diese wird von der Funktion zur EtherChannel-Konsistenzerkennung erkannt. Weitere Informationen finden Sie unter Understanding EtherChannel Inconsistency Detection.

- Port VLAN ID (PVID)-Inkonsistenz - Eine PVST+ Bridge Protocol Data Unit (BPDU) pro VLAN wird über ein anderes VLAN empfangen als ursprünglich: (Port VLAN ID Mismatchor*PVID_Inc).

- Typinkonsistenz - Ein PVST+-BPDU wird auf einem Nicht-802.1Q-Trunk empfangen.

Theorie der PVID- und Typinkonsistenzen

Cisco Catalyst Switches implementieren PVST, die Inter-Switch Link (ISL) Trunks verwenden. Mit Unterstützung von IEEE 802.1Q und ISL-Trunking war eine Möglichkeit für die Interaktion zwischen PVST und dem IEEE 802.1Q-Konzept eines einzigen Spanning Tree für alle VLANs erforderlich. Um diese Anforderung zu erfüllen, wurde die PVST+-Funktion eingeführt.

Hinweis: Aus STP-Sicht ist IEEE 802.1D nicht VLAN-fähig und IEEE 802.1Q VLAN-fähig, verwendet jedoch eine einzelne STP-Instanz für alle VLANs. Das heißt, wenn der Port blockiert, wird er für alle VLANs an diesem Port blockiert.

Dasselbe gilt für die Weiterleitung.

Diese Liste zeigt, wie PVST+ mit IEEE 802.1Q oder IEEE 802.1D zusammenarbeitet, wenn das native VLAN auf einem IEEE 802.1Q-Trunk VLAN 1 ist:

- VLAN 1 STP-BPDUs werden an die IEEE STP-MAC-Adresse (0180.c200.0000) gesendet, nicht markiert.

- VLAN 1 STP-BPDUs werden auch unmarkiert an die PVST+-MAC-Adresse gesendet.

- Nicht-VLAN 1 STP-BPDUs werden an die PVST+-MAC-Adresse (auch als SSTP-MAC-Adresse (Shared Spanning Tree Protocol) 0100.0ccc.cccd bezeichnet) gesendet, die mit einem entsprechenden IEEE 802.1Q VLAN-Tag versehen ist.

Wenn das native VLAN auf einem IEEE 802.1Q-Trunk nicht VLAN 1 ist:

- VLAN 1 STP-BPDUs werden an die PVST+-MAC-Adresse gesendet, die mit einem entsprechenden IEEE 802.1Q-VLAN-Tag versehen ist.

- VLAN 1 STP-BPDUs werden auch an die IEEE-STP-MAC-Adresse im nativen VLAN des IEEE 802.1Q-Trunks gesendet, nicht markiert.

- Nicht-VLAN 1 STP-BPDUs werden an die PVST+-MAC-Adresse gesendet, die mit einem entsprechenden IEEE 802.1Q VLAN-Tag versehen ist.

Hinweis: Native VLAN-STP-BPDUs werden unmarkiert gesendet.

Auf diese Weise wird VLAN 1 STP von PVST+ mit STP von IEEE 802.1D oder 802.1Q zusammengeführt, während andere VLANs über die Cloud von IEEE 802.1D- oder 802.1Q-Brücken getunnelt werden. So ähnelt beispielsweise die IEEE 802.1D- oder 802.1Q-Cloud einer "Leitung" zu den PVST+-VLANs mit Ausnahme von 1.

Damit STP ordnungsgemäß funktioniert, sollten Sie beim Verbinden von PVST+-Bridges mit IEEE 802.1D- oder 802.1Q-Bridges bestimmte Regeln beachten. Die Hauptregel lautet, dass PVST+-Bridges eine Verbindung zu IEEE 802.1D- oder 802.1Q-Bridges über einen IEEE 802.1Q-Trunk mit einem konsistenten nativen VLAN auf allen Bridges herstellen müssen, die mit der Cloud von IEEE 802.1Q- oder 802.1D-Bridges verbunden sind.

Die PVST+-BPDU enthält eine VLAN-Nummer, anhand derer PVST+-Bridges erkennen können, ob die vorherige Regel nicht eingehalten wird. Wenn ein Catalyst Switch eine fehlerhafte Konfiguration erkennt, werden die entsprechenden Ports in den Status "PVID-inconsistent" (PVID inkonsistent) oder "type-inconsistent" (Typinkonsistent) gesetzt, wodurch der Datenverkehr im entsprechenden VLAN an einem entsprechenden Port effektiv blockiert wird. Diese Zustände verhindern Weiterleitungsschleifen, die durch Fehlkonfigurationen verursacht wurden oder falsch verkabelt waren.

Um die Notwendigkeit der Inkonsistenzerkennung zu verdeutlichen, betrachten Sie diese Topologie, in der Switches A und C PVST+ STP und Switch B 802.1Q STP ausführen:

Wenn die BPDU des Roots in VLAN 1 besser ist als die BPDU des Roots in VLAN 2, gibt es in der VLAN 2-Topologie keinen blockierenden Port. Die BPDU von VLAN 2 bildet nie einen "vollständigen Kreis" um die Topologie. Sie wird durch die VLAN 1-BPDU auf der B-C-Verbindung ersetzt, da auf B nur ein mit VLAN 1-STP von PVST+ zusammengeführter STP ausgeführt wird. Es besteht also eine Weiterleitungsschleife. Glücklicherweise sendet Switch A PVST+-BPDUs von VLAN 2 (an die SSTP-Adresse, die von Switch B geflutet wird) an Switch C. Switch C kann Port C-B in einen typinkonsistenten Zustand versetzen, wodurch der Loop verhindert wird.

Hinweis: In einigen Befehlsausgaben wird der *-inkonsistente STP-Status als "defekt" bezeichnet.

Wenn eine STP-Inkonsistenz erkannt wird, senden Switches die folgenden Syslog-Meldungen:

%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 diesem Beispiel wurde die BPDU über VLAN 1 empfangen, und über VLAN 10 wurde die BPDU erstellt. Wenn Inkonsistenzen erkannt werden, werden beide VLANs auf dem Port blockiert, an dem dieses BPDU empfangen wird.

Hinweis: Die Meldungen können je nach Typ und Version der verwendeten Cisco IOS® Software-Version variieren.

Wenn der Port keine inkonsistenten BPDUs mehr empfängt, wird der Status "*" gelöscht, und STP ändert den Port-Status auf Grundlage des normalen STP-Betriebs. Es wird eine Syslog-Meldung gesendet, die die folgende Änderung anzeigt:

%SPANTREE-SP-2-UNBLOCK_CONSIST_PORT: Unblocking FastEthernet0/1 on vlan 1.

Port consistency restored.

Weitere Informationen zum PVST+-Betrieb finden Sie unter Spanning Tree from PVST+ to Rapid-PVST Migration Configuration Example (Spanning-Tree von PVST+ zu Rapid-PVST-Migration).

Fehlerbehebung

Um die Liste der inkonsistenten Ports anzuzeigen, unterstützt die aktuelle Cisco IOS-basierte STP-Implementierung den Befehl show spanning-tree inconsistentports.

In den meisten Fällen ist der Grund für die Erkennung von STP-Inkonsistenz auf dem Port offensichtlich:

- Der Access-Port empfängt eine mit IEEE 802.1Q gekennzeichnete SSTP-BPDU.

In diesem Szenario empfängt der Access-Port auf Bridge A von Bridge B eine markierte PVST+-BPDU vom STP eines anderen VLAN als 1. Der Port auf A kann in den typinkonsistenten Zustand versetzt werden.

Hinweis: Die Switches müssen nicht direkt verbunden werden. Wenn sie über einen oder mehrere IEEE 802.1D- oder IEEE 802.1Q-Switches oder sogar Hubs verbunden sind, hat dies denselben Effekt.

- Der IEEE 802.1Q-Trunking-Port empfängt eine nicht markierte SSTP-BPDU mit einem VLAN-Typ, einer Länge und einem Wert (TLV), die nicht mit dem VLAN übereinstimmen, in dem die BPDU empfangen wurde.

In diesem Szenario empfängt der Trunk-Port auf A eine PVST+-BPDU vom STP von VLAN 2 mit einem Tag von VLAN 2. Dadurch wird der Port auf A sowohl in VLAN 1 als auch in VLAN 2 blockiert.

Wenn Geräte an beiden Enden einer Point-to-Point-Verbindung Cisco Catalyst Switches sind, zeigt eine Untersuchung der Konfiguration des lokalen und des Remote-Ports in der Regel eine Konfigurationsabweichung auf:

- Der Port ist auf der einen Seite für IEEE 802.1Q-Trunking konfiguriert, auf der anderen Seite ist der Access-Port.

- IEEE 802.1Q-Trunks sind auf beiden Seiten vorhanden, die nativen VLANs unterscheiden sich jedoch.

In diesen Fällen beheben Sie die Konfigurationsdiskrepanz, um die STP-Inkonsistenz zu beheben.

In einigen Fällen ist es schwieriger, den Grund zu finden:

- Eine BPDU wird von einem gemeinsam genutzten Medium mit mehreren Geräten empfangen.

- Ein BPDU wird von der Switch-Cloud empfangen, die ein IEEE 802.1D- oder 802.1Q-STP-Modell implementiert, während PVST+-Switches mit der Cloud verbunden sind.

- Ein BPDU kommt von einem Tunnel (z. B. Data Link Switch Plus [DLSw+] Cloud, L2-Protokoll-Tunneling, EoMPLS, Virtual Path Links [VPLs], LAN-Emulation [LANE]).

In diesem Beispiel ist Switch B falsch konfiguriert und injiziert eine SSTP-BPDU in die Cloud. Dadurch werden die Ports an den Switches A, C und D typinkonsistent. Das Problem besteht darin, dass das Gerät, von dem die "anstößige" BPDU stammt, nicht direkt mit den betroffenen Switches verbunden ist. Wenn sich also viele Geräte im Trunk befinden, kann die Fehlerbehebung für alle Geräte sehr zeitaufwendig sein.

Glücklicherweise gibt es einen systematischen Ansatz zur Fehlerbehebung:

1. Richten Sie die Quell-MAC-Adresse ein, und senden Sie die Bridge-ID der BPDU. Dies muss während des Auftretens des Problems erfolgen

2. Suchen Sie nach der Bridge, die die "anstößige" BPDU generiert. Dies kann zu einem späteren Zeitpunkt erfolgen, nicht unbedingt dann, wenn das Problem auftritt.

Für Schritt 1 gibt es normalerweise zwei Optionen: Verwenden Sie einen Paketanalysator, oder aktivieren Sie das Debuggen, um den Dump empfangener BPDUs anzuzeigen.

Weitere Informationen zur Verwendung eines Debugverfahrens zum Auslesen von STP-BPDUs finden Sie im Abschnitt Use STP Debug Commands (STP-Debug-Befehle verwenden) von Troubleshoot STP Issues on Catalyst Switches (STP-Probleme bei Catalyst-Switches beheben).

Dies ist ein Beispiel für eine Debugausgabe, die empfangene BPDU anzeigt:

*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

Sobald Sie die Quell-MAC-Adresse und die Sendebridge-ID kennen, müssen Sie das Gerät finden, zu dem diese MAC-Adresse gehört. Dies kann dadurch erschwert werden, dass Switches die MAC-Adressen einer Quelle in der Regel nicht aus BPDU-Frames abrufen. Wenn Sie den Befehl show mac-address-table addressBPDU_mac_address (für Cisco IOS-basierte Switches) ausführen, wird in der Regel kein Eintrag gefunden.

Eine Möglichkeit, die "anstößige" MAC-Adresse zu finden, besteht darin, die Ausgabe des Befehls show spanning-tree (Spanning-Tree anzeigen) von allen mit der Cloud verbundenen Switches zu erfassen. Diese Befehlsausgaben enthalten Informationen über die Bridge-ID jeder Bridge.

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.

Hinweis: Je nach Modell, Softwareversion und Konfiguration kann ein Switch mehrere Bridge-ID-MAC-Adressen haben. Glücklicherweise können sich alle Adressen in der Regel in einem bestimmten Bereich befinden (z. B. von 0001.1234.5600 bis 0001.1234.5640). Wenn Sie eine Bridge-ID-MAC-Adresse kennen, können Sie überprüfen, ob die gesendete Bridge-ID-MAC-Adresse (in Schritt 1 gefunden) in den Bereich der angegebenen Bridge-ID-MAC-Adressen fällt. Sie können auch Netzwerkmanagement-Tools verwenden, um die Bridge-IDs aller Bridges zu erfassen.

Sobald Sie die Bridge gefunden haben, von der das anstößige BPDU gesendet wurde, müssen Sie die Konfiguration des Ports überprüfen, der mit der Cloud verbunden ist: Stellen Sie sicher, dass er konsistent (Trunking im Gegensatz zu Nicht-Trunking und nativem VLAN) mit anderen Switches ist, die ebenfalls mit der Cloud verbunden sind.

Es kann vorkommen, dass die Bridge ordnungsgemäße BPDUs sendet, diese jedoch innerhalb der Tunneling-Cloud falsch geändert werden. In diesem Fall können Sie sehen, dass die fehlerhafte BPDU, die in die Cloud gelangt, mit der Konfiguration der anderen Bridges übereinstimmt, aber dieselbe BPDU wird inkonsistent, wenn sie die Cloud verlässt (z. B. wenn die BPDU die Cloud in einem anderen VLAN verlässt oder markiert oder unmarkiert wird). In einem solchen Fall kann es hilfreich sein zu überprüfen, ob die Quell-MAC-Adresse der beanstandeten BPDU zu derselben Bridge gehört wie die sendende Bridge-ID. Ist dies nicht der Fall, können Sie versuchen, die Bridge ausfindig zu machen, die die Quell-MAC-Adresse des BPDUs besitzt, und deren Konfiguration überprüfen.

Um den Switch zu finden, der die Quell-MAC-Adresse der BPDU besitzt, können Sie denselben Ansatz (zur Suche nach der Bridge-ID) verwenden, mit der Ausnahme, dass jetzt die Befehlsausgabe show module (für Catalyst 4000 und 6000) überprüft wird. Bei anderen Catalyst Switches können Sie die Ausgabe des Befehls show interface überprüfen, um die MAC-Adressen anzuzeigen, die zu den Ports gehören.

Cat4000-#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.

Hinweis: Wenn es sich bei der Cloud um DLSw+ handelt, siehe Verständnis und Konfiguration von DLSw und 802.1Q

Zugehörige Informationen

- LAN/Spanning Tree Protocol-Produktunterstützung

- Technologie-Support

- Technischer Support und Downloads von Cisco