Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Conventions

Informations générales

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

Dépannage

Informations connexes

Introduction

Ce document décrit comment dépanner deux incohérences du protocole STP (Spanning Tree Protocol), l'ID de VLAN de port (PVID) et le type.

Conditions préalables

Exigences

Cisco vous recommande de connaître les concepts STP.

Composants utilisés

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Informations générales

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 temps d'arrêt, certaines améliorations ont été mises en oeuvre afin que STP détecte certains cas de mauvaise configuration et que le port concerné soit mis dans un état « incohérent ».

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 à Configurer STP avec la protection contre les boucles et la détection d'inclinaison 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 avec 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 PVID (Port VLAN ID) : une unité BPDU (Bridge Protocol Data Unit) PVST+ (Spanning Tree) par VLAN est reçue sur un VLAN différent de celui d'origine : (Port VLAN ID Mismatch*PVID_Inc).

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

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

Les commutateurs Cisco Catalyst implémentent le protocole PVST qui utilise des liaisons ISL (Inter-Switch Link). La prise en charge de l'IEEE 802.1Q et l'agrégation ISL requièrent la création d'une solution permettant l'interopérabilité entre le PVST et le concept IEEE 802.1Q d'un simple spanning-tree pour tous les VLAN. La fonction PVST+ a été mise en place pour répondre à cette condition.

Remarque : du point de vue STP, IEEE 802.1D n'est pas compatible VLAN et IEEE 802.1Q est compatible VLAN, mais il utilise une seule instance STP 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.

- Les BPDU STP non-VLAN 1 sont envoyées à l'adresse MAC PVST+ (également appelée adresse MAC SSTP (Shared Spanning Tree Protocol), 0100.0ccc.ccd), étiquetée avec une étiquette VLAN IEEE 802.1Q correspondante.

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 du 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 empêchent les boucles de transfert provoquées par une mauvaise configuration ou par un mauvais câblage.

Pour illustrer le besoin de détection d'incohérence, considérez cette topologie, où les commutateurs A et C exécutent le protocole STP PVST+ et le commutateur B exécute le protocole STP 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 « cercle complet » autour de la topologie ; elle est remplacée par la BPDU du VLAN 1 sur la liaison B-C, car B exécute un seul STP fusionné avec le STP du VLAN 1 de PVST+. Ainsi, il se crée une boucle de réacheminement. Heureusement, le commutateur A envoie les BPDU PVST+ du VLAN 2 (à l’adresse SSTP qui est inondée par le commutateur B) vers le commutateur C. Le commutateur C peut mettre le port C-B dans un état de type incohérent, ce qui empêche la boucle.

Remarque : dans certaines sorties de commande, l'état STP incohérent * est appelé « cassé ».

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 de la version du logiciel Cisco IOS® utilisée.

Notez que si le port ne reçoit plus de BPDU incohérentes, l'état d'incohérence * est effacé et STP change l'état du port en fonction du fonctionnement STP normal. 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 de PVST+, référez-vous à Exemple de configuration de la migration Spanning Tree de PVST+ à Rapid-PVST.

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 peut être mis dans un état de type incohérent.

Remarque : il n'est pas nécessaire de connecter les commutateurs directement. S'ils sont connectés via un ou plusieurs commutateurs IEEE 802.1D ou IEEE 802.1Q, voire des concentrateurs, l'effet est le même.

- 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, il est plus difficile d'en déterminer la raison :

- 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. Ainsi, avec de nombreux périphériques sur le trunk, il peut prendre du temps pour tous les dépanner.

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

1. Établissez l'adresse MAC source et l'ID de pont d'envoi de la BPDU. Cela doit être fait 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 y a normalement deux options : utiliser un analyseur de paquets ou activer le débogage pour voir le vidage des BPDU reçues.

Pour plus de détails sur l'utilisation d'un débogage pour vider les BPDU STP, référez-vous à la section Utiliser les commandes de débogage STP de Dépanner les problèmes STP sur les commutateurs Catalyst.

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 émettez la commande show mac-address-table addressBPDU_mac_address (pour les commutateurs basés sur Cisco IOS), alors, généralement, aucune entrée n'est trouvée.

Une façon de trouver l'adresse MAC « offensante » est de collecter, à partir de tous les commutateurs qui sont connectés au cloud, le résultat de la commande show spanning-tree. 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.

Remarque : en fonction du modèle, de la version du logiciel et de la configuration, un commutateur peut avoir plusieurs adresses MAC d'ID de pont. Heureusement, toutes les adresses peuvent généralement se trouver dans une certaine plage (par exemple, de 0001.1234.5600 à 0001.1234.5640). Si vous connaissez une adresse MAC d'ID de pont, vous pouvez vérifier si l'adresse MAC d'ID de pont envoyée (trouvée à l'étape 1) est comprise dans la 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 qui a envoyé la trame BPDU incriminée, vous devez vérifier la configuration du port qui est connecté au nuage : assurez-vous qu'il est cohérent (agrégation par opposition à non-agrégation et VLAN natif) avec d'autres commutateurs qui sont également connectés au même nuage.

Il se peut que le pont envoie des BPDU correctes, mais elles sont modifiées de manière incorrecte dans le nuage de tunnellisation. Dans ce cas, vous pouvez voir que la BPDU incriminée qui entre dans le nuage est cohérente avec la configuration des autres ponts, mais la même BPDU devient incohérente quand elle quitte le nuage (par exemple, la BPDU sort du nuage dans un VLAN différent, ou devient balisée ou non balisée). Dans un tel cas, il peut aider à vérifier si l'adresse MAC source de la BPDU incriminée 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 possède l'adresse MAC source de la BPDU, vous pouvez utiliser la même approche (pour trouver l'ID de pont), sauf maintenant que la sortie de commande show module est inspectée (pour Catalyst 4000 et 6000). Pour les autres commutateurs Catalyst, vous pouvez examiner le résultat de la commande show interface pour voir les adresses MAC qui appartiennent aux ports.

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.

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

Informations connexes

- Support produit du protocole LAN/Spanning Tree

- Assistance technique sur la technologie

- Assistance technique de Cisco et téléchargements