Dépannage de Spanning Tree PVID et des incohérences de type

Introduction

Dans des réseaux de couche 2 (L2), il ne peut y avoir qu'un seul chemin d'accès entre deux périphériques quels qu'ils soient. La Redondance est prise en charge avec le Protocole Spanning Tree (STP), qui détecte et bloque des chemins redondants et évite de ce fait les boucles de réacheminement. Certaines erreurs de configuration peuvent engendrer un échec du STP et entraîner une panne du réseau. Pour éviter les périodes d'inactivités, quelques améliorations ont été apportées de sorte que le STP détecte certains cas d'erreur de configuration et place le port en question dans un état d' « inconsistance ».

Il existe différents types d'inconsistances du STP :

• Inconsistance de boucle - Ceci est détecté par la fonction Loop Guard. Pour plus d'informations, référez-vous à Amélioration du Protocole Spanning Tree à l'aide des fonctions de détection et de protection Loop Guard et BPDU.

• Inconsistance de la racine - Ceci est détecté par la fonction Root Guard. Pour plus d'informations, référez-vous à Amélioration du Protocole Spanning Tree à l'aide de la fonction Root Guard.

• Inconsistance de l'EtherChannel - Ceci est détecté par la fonction de détection d'incohérence EtherChannel. Pour plus d'informations, référez-vous à Compréhension de la détection d'incohérence de l'EtherChannel.

• Incohérence du Port VLAN ID (PVID) - Une unité Bridge Protocol Data Unit (BPDU) de Per VLAN Spanning Tree (PVST+) est reçue sur un VLAN différent de celui qui l'a envoyée : (Disparité du Port VLAN ID ou *PVID_Inc).

• Incohérence de type - Une BPDU de PVST+ est reçue sur une agrégation non-802.1Q.

Ce document explique comment diagnostiquer la cause derrière les deux dernières incohérences, PVID et type. Consultez les documents précédemment mentionnés pour le dépannage des autres incohérences.

Conditions préalables

Conditions requises

Il est sous-entendu que les lecteurs de ce document ont des notions certaines des concepts liés au STP :

Components Used

Ce document n'est pas limité à des versions de matériel ou de logiciel spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Théorie derrière le PVID- et les inconsistances de type

Les commutateurs Cisco Catalyst mettent en place un PVST en utilisant des agrégations d'Inter-Switch Link (ISL). Avec la prise en charge de l'agrégation IEEE 802.1Q et ISL, une méthode était nécessaire pour l'interopérabilité entre PVST et le concept IEEE 802.1Q d'un seul spanning tree pour tous les VLAN. La fonction PVST+ a été mise en place pour répondre à cette condition.

Remarque : du point de vue du protocole STP, IEEE 802.1D n'est pas sensible au VLAN et IEEE 802.1Q est sensible au VLAN, mais il utilise une instance STP unique pour tous les VLAN. En d'autres termes, si le port fait blocage alors il y aura un blocage pour tous les VLAN sur ce port. Il en est de même pour le transfert.

Cette liste montre la façon dont le PVST+ interagit avec l'IEEE 802.1Q ou l'IEEE 802.1D, quand le VLAN natif sur une agrégation d'IEEE 802.1Q est VLAN 1 :

• Les BPDU du STP sur VLAN 1 sont envoyées sur l'adresse MAC d'IEEE STP (0180.c200.0000), non marqués.

• Les BPDU du STP sur VLAN 1 sont également envoyées sur l'adresse MAC PVST+, non marqués.

• Le BPDU du STP hors-VLAN 1 sont envoyés sur l'adresse MAC PVST+ (également appelée l'adresse MAC de Protocole Spanning Tree Partagé [SSTP], 0100.0ccc.cccd), marquée avec une balise VLAN correspondante d'IEEE 802.1Q.

Quand le VLAN natif sur une agrégation d'IEEE 802.1Q n'est pas considéré VLAN 1 :

• Les BPDU du STP sur VLAN 1 sont envoyées sur l'adresse MAC PVST+, marquée avec une balise VLAN correspondante d'IEEE 802.1Q.

• Les BPDU du STP sur VLAN 1 sont également envoyées vers l'adresse MAC d'IEEE STP sur le VLAN natif de l'agrégation d'IEEE 802.1Q, non marqués.

• Les BPDU STP hors-VLAN 1 sont envoyées sur l'adresse MAC PVST+, marquée avec une balise VLAN correspondante d'IEEE 802.1Q.

  Remarque : les BPDU STP de VLAN natif sont envoyées sans étiquette.

De cette façon, le STP du VLAN 1 de PVST+ fusionne avec le STP d'IEEE 802.1D ou de 802.1Q, tandis que les autres VLAN sont transmis par tunnel au travers du nuage de l'IEEE 802.1D ou des ponts 802.1Q. Par exemple, l'IEEE 802.1D ou le nuage 802.1Q ont l'air identiques vis-à-vis d'un « fil » des VLAN PVST+ autres que 1.

Pour un bon fonctionnement du STP, vous devez respecter certaines règles lors de la connexion des ponts PVST+ sur l'IEEE 802.1D ou aux ponts 802.1Q. La règle principale veut que les ponts PVST+ soient connectés à l'IEEE 802.1D ou aux ponts de 802.1Q par une agrégation d'IEEE 802.1Q avec un VLAN natif cohérent sur tous les ponts connectés au nuage de l'IEEE 802.1Q ou aux ponts 802.1D.

Le BPDU PVST+ contient un numéro de VLAN qui permet aux ponts PVST+ de détecter le respect ou non de la règle précédente. Quand un commutateur Catalyst détecte une erreur de configuration, les ports correspondants sont placés dans un état d' « Incohérence PVID » ou « Incohérence de type », ce qui va bloquer effectivement le traffic sur le VLAN correspondant du port en question. Ces états permettent d'éviter les boucles de réacheminement causées par des erreur de configuration ou de mauvais branchement.

Pour illustrer le besoin de détection d'incohérence, considérez la topologie suivante, où les commutateurs A et C gèrent le STP du PVST+ et le commutateur B gère le STP du 802.1Q :

Si la BPDU de la racine dans le VLAN 1 est plus performante que la BPDU de la racine dans le VLAN 2 il n'y aura aucun blocage de port dans la topologie VLAN 2. La BPDU du VLAN 2 ne fait jamais un « tour complet » autour de la topologie ; il est remplacé par la BPDU du VLAN 1 sur la liaison B-C, car B ne gère uniquement qu'un STP fusionné avec le STP d'un VLAN 1 de PVST+. Ainsi, il se crée une boucle de réacheminement. Heureusement, le commutateur A envoie les BPDU du PVST+ du VLAN 2 (à l'adresse SSTP qui est inondée par le commutateur B) vers le commutateur C. Le commutateur C passera le port C-B dans un état d'incohérence de type, ce qui devrait éviter la formation d'une boucle.

Remarque : dans certaines sorties de commande, l'état *-incohérent du STP est appelé “ rompu. ”

Quand une incohérence de STP est détectée, les commutateurs envoient les messages syslog suivants :

%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

Dans cet exemple, le VLAN 1 correspond au point où la BPDU a été reçue, et VLAN 10 le point d'où la BPDU a été envoyée. Quand une incohérence est détectée, les deux VLAN sont bloqués au niveau du port où ce BPDU est reçue

Remarque : les messages peuvent varier en fonction du type et de la version du logiciel Cisco IOS® ou du système d'exploitation Catalyst OS (CatOS) utilisé.

Remarque : si le port cesse de recevoir des BPDU incohérentes, l'état *-incohérent est effacé et STP change l'état du port en fonction du fonctionnement normal du STP. Un message syslog est envoyé pour indiquer ce changement :

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

Pour plus de détails sur le fonctionnement du PVST+, reportez-vous à Pontage entre les VLAN d'IEEE 802.1Q.

Dépannage

De manière à pouvoir consulter la liste de ports incohérents, les plus récentes applications basées sur Cisco IOS prennent en charge la commande show spanning-tree inconsistentports.

Dans la plupart des cas, la raison pour une détection d'incohérence de STP sur le port est évidente :

• Le port d'accès reçoit une BPDU de SSTP avec IEEE 802.1Q marqué.

  

  Dans ce scénario, le port d'accès sur le pont A reçoit, provenant du pont B, une BPDU de PVST+ marquée depuis le STP d'un VLAN autre que 1. Le port sur A est placé en état d'inconsistance de type.

  Remarque : les commutateurs ne doivent pas être connectés directement ; s'ils sont connectés par un ou plusieurs commutateurs IEEE 802.1D ou l'IEEE 802.1Q - ou même par des concentrateurs - alors l'effet est identique.

• Le port agrégation d'IEEE 802.1Q reçoit une BPDU de SSTP non marqué avec un type de VLAN, une longueur, une valeur (TLV) qui ne correspond pas au VLAN où la BPDU a été reçue.

  

  Dans ce scénario, le port agrégation sur A reçoit une BPDU de PVST+ depuis le STP du VLAN 2 avec un marquage de VLAN 2. Ceci déclenche un blocage du port sur A, dans le VLAN 1 et le VLAN 2.

Si les périphériques aux deux extrémités d'une liaison point par point sont des commutateurs Cisco Catalyst, un examen de la configuration locale et à distance révélera la disparité de la configuration :

• Le port est configuré pour l'agrégation d'IEEE 802.1Q d'un côté mais l'autre côté est un port d'accès.

• Les agrégations d'IEEE 802.1Q existent des deux côtés, mais les VLAN natifs sont différents.

Dans de tels cas, il faut réparer la disparité de configuration pour résoudre l'incohérence de STP.

Dans certains cas, l'identification de la raison n'est pas si évidente :

• Une BPDU est reçue depuis un média partagé comportant plusieurs périphériques.

• Une BPDU est reçue depuis le nuage de commutateur, appliquant un IEEE 802.1D ou un modèle STP de 802.1Q, alors que des commutateurs PVST+ sont connectés au nuage.

• Une BPDU provient de l'arrière d'un tunnel (par exemple, un nuage Data Link Switch Plus [DLSw+], un protocole de tunneling L2, EoMPLS, liaisons de circuit virtuel [VPLs], émulation LAN [LANE], et autres).

Dans cet exemple, le commutateur B est mal configuré et injecte une BPDU de SSTP dans le nuage. Ceci engendre une inconsistance de type au niveau des ports aux commutateurs A, C et D. Le problème est que le périphérique à l'origine de la BPDU « fautive » n'est pas directement connecté aux commutateurs affectés. Et donc, avec autant de périphériques sur l'agrégation, cela prendrait trop de temps de les dépanner tous.

Heureusement, il existe une approche systématique pour le dépannage de ce problème :

1. Etablir l'adresse source MAC et envoyer l'ID de pont de la BPDU. Ceci doit se faire pendant que le problème se produit.

2. Recherchez le pont qui est à l'origine de la BPDU « fautive ». Ceci peut être fait à un temps ultérieur, pas nécessairement pendant que le problème se produit.

Pour l'étape 1, il existe habituellement deux options : utilisez un analyseur de paquets ou activez le débogage pour observer le vidage des BPDU reçues.

Pour plus de détails au sujet de l'utilisation d'un débogage pour le vidage de BPDU du STP, reportez-vous à la section Commandes de débogage STP dans Dépannage du STP sur commutateur Catalyst utilisant un Cisco IOS intégré (mode natif).

Voici un exemple de sorties de débogage montrant les BPDU reçues :

*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

Une fois que vous connaissez l'adresse source MAC et l'ID du pont d'envoi, vous devez rechercher le périphérique auquel appartient cette adresse MAC. Ceci peut être assez difficile du fait que les commutateurs ne savent généralement pas identifier la source des adresses MAC provenant des trames BPDU. Si vous lancez la commande show mac-address-table address BPDU_mac_address (pour commutateurs fonctionnant sous Cisco IOS) ou la commande show cam mac_address (pour commutateurs fonctionnant sous CatOS) résulte en aucune entrée trouvée.

Une façon de rechercher l'adresse MAC « fautive » consiste à collecter, à partir de tous les commutateurs connectés au nuage, les sorties de commande show spanning-tree (pour Cisco IOS) ou de la commande show spantree (pour CatOS). Ces sorties de commande incluent des informations sur l'ID de pont de chaque pont.

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.

Remarque : Selon le modèle, la version du logiciel et la configuration, un commutateur peut avoir plusieurs adresses MAC d'ID de pont. Heureusement, toutes ces adresses se trouvent habituellement dans une plage bien définie (par exemple, de 0001.1234.5600 à 0001.1234.5640). Si vous connaissez une adresse MAC d'ID de pont, alors vous pourrez vérifier si l'adresse MAC d'ID de pont émetteur (vue à l'étape 1) fait partie d'une plage d'adresses MAC d'ID de pont données.

Vous pouvez également utiliser des outils de gestion de réseau pour collecter les ID de pont pour tous les ponts.

Une fois que vous avez trouvé le pont émettant la BPDU « fautive », vous devez vérifier la configuration du port en relation avec le nuage : assurez-vous de sa consistance (agrégation par opposition à une non-agrégation et VLAN natif) avec les autres commutateurs en connexion avec le même nuage.

Il pourrait arriver que le pont envoie les bonnes BPDU, mais qu'elles subissent des modifications incorrectes une fois à l'intérieur du nuage de tunneling. Dans un tel cas, vous noterez que la BPDU « fautive » entrant dans le nuage est cohérente avec la configuration des autres ponts, mais que la même BPDU devient incohérente quand elle quitte le nuage (par exemple, la BPDU quitte le nuage par un VLAN différent, ou est marqué ou non marquée). Quand cela se produit, il peut s'avérer utile de vérifier si l'adresse MAC source de la BPDU « fautive » appartient au même pont que l'ID de pont émetteur. Si tel n'est pas le cas, alors vous pourriez essayer de localiser le pont qui détient l'adresse MAC source de la BPDU et en vérifiez sa configuration.

Pour localiser le commutateur qui détient l'adresse MAC source de la BPDU, vous pourriez suivre la même approche que l'on utilise pour rechercher l'ID de pont, excepté que maintenant la sortie de commande show module sera inspectée (pour Catalyst 4000, 5000 et 6000). Pour les Catalyst 2900 XL, 3500 XL, 2950 et 3550, vous devrez examiner la sortie de commande show interface command pour voir les adresses MAC qui appartiennent aux ports.

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.

Remarque : si le cloud est DLSw+, reportez-vous à Présentation et configuration de DLSw et 802.1Q.

Informations connexes

• Pages de support pour les produits LAN
• Page de support sur la commutation LAN
• Support technique - Cisco Systems