Dépannage STP sur les commutateurs Catalyst exécutant le logiciel système Cisco IOS

Introduction

Ce document fournit des instructions pour employer le logiciel Cisco IOS® pour dépanner des problèmes avec le protocole Spanning-Tree (STP). Il y a des commandes spécifiques qui s'appliquent au Catalyst 6500/6000 seulement; cependant, vous pouvez appliquer la plupart des principes à n'importe quel commutateur Cisco Catalyst qui exécute le logiciel Cisco IOS.

La plupart des opérations de dépannage STP sont liées à trois problèmes :

• boucles de transfert

• Inondation excessive due à un taux élevé de modifications de topologie STP (TC)

• problèmes liés au temps de convergence

Comme le pontage ne dispose d’aucun mécanisme permettant de déterminer si un paquet donné est transféré plusieurs fois (par exemple, une durée de vie IP [TTL] est utilisée pour rejeter le trafic circulant trop longtemps sur le réseau), un seul chemin peut exister entre deux périphériques dans le même domaine de couche 2 (L2).

Le but du protocole STP est de bloquer les ports redondants à partir d'un algorithme STP, afin de résoudre la topologie physique redondante dans une topologie arborescente. Une boucle de transfert (telle qu'une boucle STP) se produit lorsqu'aucun port d'une topologie redondante n'est bloqué et que le trafic est transféré en cercle indéfiniment.

Une fois que la boucle de transfert démarre, elle congestionnera probablement les liaisons à bande passante la plus faible le long de son chemin. Si toutes les liaisons sont de la même bande passante, toutes les liaisons seront probablement congestionnées. Cet encombrement entraînera la perte de paquets et une panne du réseau dans le domaine L2 affecté.

Avec une inondation excessive, les symptômes pourraient ne pas être aussi apparents. Certaines liaisons lentes peuvent être congestionnées par le trafic inondé, et les périphériques ou les utilisateurs derrière ces liaisons encombrées peuvent subir une lenteur ou une perte totale de connectivité.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Différents types Spanning Tree et comment les configurer. Référez-vous à Configuration de STP et IEEE 802.1s MST pour plus d'informations.

• Diverses fonctionnalités Spanning Tree et comment les configurer. Référez-vous à Configuration des fonctionnalités STP pour plus d'informations.

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Catalyst 6500 avec moteur Supervisor 2

• Logiciel Cisco IOS Version 12.1(13)E

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. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Pourquoi STP échoue

STP émet certaines hypothèses sur son environnement opérationnel. Voici les hypothèses les plus pertinentes pour ce document :

• Chaque liaison entre les deux ponts est bidirectionnelle. Cela signifie que, si A se connecte directement à B, A recevra ce que B a envoyé et B recevra ce que A a envoyé, tant que la liaison est établie entre eux.

• Chaque pont qui exécute STP peut recevoir, traiter et transmettre régulièrement des unités BPDU (Bridge Protocol Data Units) STP, également appelées paquets STP.

Bien que ces hypothèses semblent logiques et évidentes, il existe des situations où elles ne sont pas respectées. La plupart de ces situations impliquent une sorte de problème matériel ; cependant, les défauts logiciels peuvent également entraîner des pannes STP. Diverses défaillances matérielles, erreurs de configuration ou erreurs de câblage provoquent la majorité des pannes STP, tandis que les pannes logicielles en représentent la minorité. Des pannes STP peuvent également se produire en raison de connexions supplémentaires inutiles qui existent entre les commutateurs. Les VLAN sont désactivés en raison de ces connexions supplémentaires. Pour résoudre ce problème, supprimez toutes les connexions indésirables entre les commutateurs.

Lorsqu'une de ces hypothèses n'est pas respectée, un ou plusieurs ponts peuvent ne plus recevoir ou traiter les BPDU. Cela signifie que le ou les ponts ne pourront pas découvrir la topologie du réseau. Sans connaissance de la topologie correcte, le commutateur ne peut pas bloquer les boucles. Par conséquent, le trafic inondé circule sur la topologie en boucle, consomme toute la bande passante et désactive le réseau.

Les commutateurs peuvent ne pas recevoir de BPDU par exemple, des émetteurs-récepteurs défectueux ou des GBIC (Gigabit Interface Converters), des problèmes de câblage ou des pannes matérielles sur le port, la carte de ligne ou le moteur de supervision. Une raison fréquente des pannes STP est une liaison unidirectionnelle entre les ponts. Dans une telle situation, un pont envoie des BPDU, mais le pont en aval ne les reçoit jamais. Le traitement STP peut également être perturbé par un processeur surchargé (99 % ou plus), car le commutateur ne peut pas traiter les BPDU reçus. Les BPDU peuvent être corrompus le long du chemin d'un pont à l'autre, ce qui empêche également le comportement STP approprié.

En dehors des boucles de transfert, lorsqu'aucun port n'est bloqué, il y a des situations où seuls certains paquets sont transmis de manière incorrecte via les ports de blocage. Dans la plupart des cas, cela est dû à des problèmes logiciels. Un tel comportement pourrait entraîner “ boucles lentes. ” Cela signifie que certains paquets sont en boucle, mais que la majorité du trafic circule toujours sur le réseau, car les liaisons ne sont probablement pas encombrées.

Les sections restantes de ce document fournissent des directives pour le dépannage des problèmes STP les plus courants.

Dépannage des boucles de transfert

Les boucles de transfert varient considérablement tant en leur origine (cause) qu'en leur effet. En raison de la grande variété de problèmes qui peuvent affecter STP, ce document ne peut fournir que des directives générales sur la façon de dépanner les boucles de transfert.

Avant de commencer le dépannage, vous devez obtenir les informations suivantes :

• Un schéma de topologie réel qui détaille tous les commutateurs et ponts

• Leurs numéros de port correspondants (interconnexion)

• Détails de configuration STP, tels que le commutateur racine et racine de sauvegarde, les liaisons dont le coût ou la priorité n'est pas par défaut et l'emplacement des ports de blocage

En règle générale, le dépannage comprend les étapes suivantes (selon la situation, certaines étapes peuvent ne pas être nécessaires) :

1. Identifiez la boucle.

   Lorsqu’une boucle de transfert s’est développée sur le réseau, voici les symptômes habituels :

   • Perte de connectivité vers, depuis et via les régions du réseau affectées

   • Utilisation élevée du CPU sur les routeurs connectés aux segments ou VLAN affectés qui peuvent entraîner divers symptômes, tels que le battement de voisinage du protocole de routage ou le battement de routeur actif HSRP (Hot Standby Router Protocol)

   • Utilisation élevée des liaisons (souvent 100 %)

   • Utilisation élevée du fond de panier du commutateur (par rapport à l'utilisation de base)

   • Messages Syslog qui indiquent une boucle de paquets dans le réseau (par exemple, messages d'adresse IP dupliqués HSRP)

   • Messages Syslog qui indiquent un réapprentissage constant d'adresses ou des messages de battement d'adresses MAC

   • Un nombre croissant de pertes de sortie sur de nombreuses interfaces

   Note : Chacune de ces raisons seule peut indiquer des problèmes différents (ou aucun problème du tout). Cependant, lorsque plusieurs de ces éléments sont observés en même temps, il est hautement probable qu’une boucle de transfert ait été développée dans le réseau.

   Remarque : La façon la plus rapide de vérifier ceci est de vérifier l'utilisation du trafic du fond de panier du commutateur :

   cat# show catalyst6000 traffic-meter
   
     traffic meter =   13%  Never cleared
              peak =   14%  reached at 12:08:57 CET Fri Oct 4 2002

   Remarque : le Catalyst 4000 avec le logiciel Cisco IOS ne prend pas actuellement en charge cette commande.

   Si le niveau de trafic actuel est bien au-dessus de la normale ou si le niveau de référence n'est pas connu, vérifiez si le niveau de pic a été atteint récemment et s'il est proche du niveau de trafic actuel. Par exemple, si le niveau de trafic maximal est de 15 % et qu'il a été atteint il y a seulement deux minutes et que le niveau de trafic actuel est de 14 %, cela signifie que le commutateur fonctionne sous une charge exceptionnellement élevée.

   Si la charge de trafic est normale, cela signifie probablement qu'il n'y a pas de boucle ou que ce périphérique n'est pas impliqué dans la boucle. Cependant, il pourrait encore être impliqué dans une boucle lente.

2. Découvrez la topologie (étendue) de la boucle.

   Une fois qu'il a été établi que la cause de la panne réseau est une boucle de transfert, la priorité la plus élevée est d'arrêter la boucle et de restaurer le fonctionnement du réseau. Pour arrêter la boucle, vous devez savoir quels ports sont impliqués dans la boucle : examinez les ports dont l’utilisation de liaison est la plus élevée (paquets par seconde). La commande logicielle show interface Cisco IOS affiche l'utilisation de chaque interface.

   Afin d'afficher uniquement les informations d'utilisation et le nom de l'interface (pour une analyse rapide), vous pouvez utiliser le filtrage de sortie d'expression régulière du logiciel Cisco IOS. Émettez l'interface show | include line|\/sec pour afficher uniquement les statistiques de paquet par seconde et le nom de l'interface :

   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
   

   Soyez particulièrement attentif aux interfaces dont l’utilisation des liaisons est la plus élevée. Dans cet exemple, il s'agit des interfaces g2/3, g2/4 et g2/8 ; ce sont probablement les ports qui sont impliqués dans la boucle.

3. Cassez la boucle.

   Pour rompre la boucle, vous devez arrêter ou déconnecter les ports concernés. Il est très important non seulement d'arrêter la boucle, mais aussi de trouver et de corriger la cause première de la boucle. Il est relativement plus facile de rompre la boucle.

   Remarque : pour faciliter l'analyse des causes ultérieures, vous n'avez pas besoin d'arrêter ou de déconnecter tous les ports simultanément ; au lieu de cela, arrêtez -les un à la fois. Il est généralement préférable d'arrêter les ports au point d'agrégation affecté par la boucle, tel qu'un commutateur de distribution ou de coeur de réseau. Si vous arrêtez tous les ports en même temps et que vous les activez ou les reconnectez un par un, cela peut ne pas fonctionner ; la boucle sera arrêtée et pourrait ne pas démarrer immédiatement après la reconnexion du port incriminé. Par conséquent, il serait difficile de corréler une défaillance à un port particulier.

   Remarque : Il est recommandé de collecter des informations avant de redémarrer les commutateurs pour rompre la boucle. Sinon, l'analyse des causes profondes sera très difficile.

   Après avoir désactivé ou déconnecté chaque port, vous devez vérifier si l'utilisation du fond de panier du commutateur est revenue à un niveau normal.

   Remarque : Gardez à l'esprit que, généralement, certains ports ne supportent pas la boucle mais inondent le trafic qui arrive avec la boucle. Lorsque vous arrêtez de tels ports d'inondation, vous réduirez seulement une petite quantité d'utilisation du fond de panier, mais vous n'arrêterez pas la boucle.

   Dans l’exemple de topologie suivant, la boucle est située entre les commutateurs A, B et D. Par conséquent, les liaisons AB, AD et BD sont maintenues. Si vous arrêtez l'une de ces liaisons, vous arrêterez la boucle. Les liaisons AC, AE, BC et BE ne font qu'inonder le trafic arrivant avec la boucle.

   

   Après l'arrêt du port de maintien, l'utilisation du fond de panier s'arrête à une valeur normale. Il est très important de noter quel arrêt du port a ramené l'utilisation du fond de panier (et l'utilisation d'autres ports) à un niveau normal.

   À ce stade, la boucle sera arrêtée et le fonctionnement du réseau devrait s'améliorer ; toutefois, comme la cause initiale de la boucle n'a probablement pas été corrigée, il se peut qu'il y ait encore des problèmes en suspens.

4. Recherchez et corrigez la cause de la boucle.

   Une fois la boucle arrêtée, vous devez déterminer la raison pour laquelle elle a commencé. C'est souvent la partie la plus difficile du processus, car les raisons peuvent varier. Il est également difficile de formaliser une procédure exacte qui fonctionne dans tous les cas. Cependant, voici quelques directives générales :

   • Examinez le schéma de topologie pour trouver un chemin redondant. Cela inclut le port de maintien trouvé à l'étape précédente qui revient au même commutateur (le chemin que les paquets empruntaient pendant la boucle). Dans l'exemple de topologie précédent, ce chemin est AD-DB-BA.

   • Pour chaque commutateur sur le chemin redondant, vérifiez les problèmes suivants :

   1. Le commutateur connaît-il la racine STP correcte ?

      Tous les commutateurs d’un réseau de couche 2 doivent convenir d’une racine STP commune. Il s'agit d'un symptôme clair de problèmes lorsque les ponts affichent systématiquement un ID différent pour la racine STP dans un VLAN ou une instance STP particulière. Exécutez la commande show spanning-tree vlan vlan-id pour afficher l'ID de pont racine pour un VLAN donné :

      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

      Le numéro de VLAN se trouve à partir du port, car les ports impliqués dans la boucle ont été établis au cours des étapes précédentes. Si les ports en question sont des agrégations, tous les VLAN de l’agrégation sont souvent impliqués. Si ce n'est pas le cas (par exemple, s'il apparaît que la boucle s'est produite sur un VLAN unique), vous pouvez essayer d'émettre la commande show interfaces | include L2|line|broadcast, commande (uniquement sur les moteurs Supervisor 2 et versions ultérieures des commutateurs de la gamme Catalyst 6500/6000, car Supervisor 1 ne fournit pas de statistiques de commutation par VLAN). Examinez uniquement les interfaces VLAN. Le VLAN avec le plus grand nombre de paquets commutés sera le plus souvent celui où la boucle s’est produite :

      cat# show int | 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

      Dans cet exemple, le VLAN 1 représente le plus grand nombre de diffusions et de trafic commuté de couche 2.

   2. Le port racine est-il correctement identifié ?

      Le port racine doit avoir le coût le plus bas vers le pont racine (un chemin est parfois plus court en termes de sauts mais plus long en termes de coût, car les ports à faible vitesse ont des coûts plus élevés).

      Pour déterminer quel port est considéré comme la racine d'un VLAN donné, émettez la commande show spanning-tree vlan vlan :

      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

   3. Les BPDU sont-ils reçus régulièrement sur le port racine et sur les ports censés être bloquants ?

      Les BPDU sont envoyés par le pont racine à chaque intervalle Hello (deux secondes par défaut). Les ponts non racine reçoivent, traitent, modifient et propagent les BPDU qui sont reçus de la racine.

      Exécutez la commande show spanning-tree interface interface detail pour voir si les BPDU sont reçus :

      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
      

      Remarque : une BPDU a été reçue entre les deux sorties de la commande (le compteur est passé de 53 à 54).

      Les compteurs affichés sont en fait des compteurs gérés par le processus STP lui-même. Cela signifie que, si les compteurs de réception ont été incrémentés, non seulement les BPDU ont été reçus par un port physique, mais également par le processus STP.

      Si le compteur BPDU reçu ne s'incrémente pas sur le port qui est censé être le port alternatif ou de secours racine, vérifiez si le port reçoit des multidiffusions (les BPDU sont envoyés en multidiffusion). Émettez la commande show interface interface counters :

      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

      (Une brève description des rôles de port STP se trouve dans la section Résumé succinct des rôles de port STP de la section Améliorations du protocole Spanning Tree à l'aide de la protection contre les boucles et des fonctions de détection de décalage BPDU.)

      Si aucune BPDU n'est reçue, vérifiez si le port ne compte pas les erreurs. Émettez la commande show interface interface counters errors :

      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

      Il est possible que les BPDU soient reçus par le port physique mais n'atteignent toujours pas le processus STP. Si les commandes utilisées dans les deux exemples précédents montrent que certaines multidiffusions sont reçues et que les erreurs ne s'incrémentent pas, vérifiez si les BPDU sont supprimés au niveau du processus STP. Exécutez la commande remote switch test spanning-tree process-stats sur le Catalyst 6500 :

      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

      La commande utilisée dans cet exemple affiche les statistiques de processus STP. Il est important de vérifier que les compteurs de perte n'augmentent pas et que les paquets reçus augmentent.

      Si les paquets reçus n'augmentent pas mais que le port physique reçoit des multidiffusions, vérifiez que les paquets sont reçus par l'interface intrabande du commutateur (l'interface du processeur). Émettez la commande remote switch show ibc | i rx_input sur 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

      Cet exemple montre que, entre les sorties, le port intrabande a reçu 23 paquets.

      Remarque : ces 23 paquets ne sont pas seulement des paquets BPDU ; il s'agit d'un compteur global pour tous les paquets reçus par le port intrabande.

      Si rien n'indique que des BPDU sont abandonnés sur le commutateur ou le port local, vous devez passer au commutateur de l'autre côté de la liaison et vérifier si ce commutateur envoie des BPDU.

   4. Les BPDU sont-ils envoyés régulièrement sur des ports désignés non racine ?

      Si, selon le rôle de port, le port envoie des BPDU, mais que le voisin ne les reçoit pas, vérifiez si des BPDU sont effectivement envoyés. Émettez la commande show spanning-tree interface interface detail :

      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

      Dans cet exemple, deux BPDU ont été envoyés entre les sorties.

      Remarque : le processus STP gère le BPDU : compteur envoyé. Cela signifie que le compteur indique que le BPDU a été envoyé vers le port physique, pour être finalement envoyé. Vérifiez si les compteurs de port augmentent pour les paquets de multidiffusion transmis. Exécutez la commande show interface interface counters. Cela peut aider à déterminer si les BPDU sortent ou non :

      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

      Avec toutes ces étapes, l'idée est de trouver le commutateur ou la liaison où les BPDU ne sont pas reçus, envoyés ou traités.

      Il est possible, cependant improbable, que le STP ait calculé l'état correct pour le port, mais en raison d'un problème de plan de contrôle, il n'a pas pu définir cet état sur le matériel de transfert. Une boucle peut être créée si le port de blocage supposé n'est pas bloqué au niveau matériel. Si vous soupçonnez un tel problème sur votre réseau, contactez le support technique Cisco pour obtenir de l'aide.

5. Restaurer la redondance

   Une fois que le périphérique ou la liaison à l'origine de la boucle a été trouvé, ce périphérique doit être isolé du réseau, ou des actions doivent être prises pour résoudre le problème (par exemple, remplacer la fibre ou le GBIC). Les liaisons redondantes, déconnectées à l'étape 3, doivent être restaurées.

   Il est important de manipuler le moins possible le périphérique ou la liaison à l’origine de la boucle, car de nombreuses conditions qui mènent à une boucle peuvent être très transitoires, intermittentes et instables. Cela signifie que, si la condition est effacée pendant ou après le dépannage, il peut falloir un certain temps avant qu'une telle condition ne se reproduise. Il est possible que la condition ne se reproduise pas du tout. Tout doit être mis en oeuvre pour préserver cette condition, afin que l'assistance technique de Cisco puisse l'examiner plus avant. Il est important de collecter des informations sur la condition avant de réinitialiser les commutateurs. Si une condition n'est plus présente, il est souvent impossible de déterminer la cause première de la boucle. La recherche du périphérique ou de la liaison qui déclenche la boucle est une réalisation majeure, mais vous devez vous assurer qu'une autre défaillance du même type ne provoque pas à nouveau la boucle. Pour plus d'informations, consultez la section Sécurisation du réseau contre les boucles de transfert de ce document.

Dépannage des modifications excessives de la topologie provoquant des inondations

Le rôle du mécanisme TC est de corriger les tables de transfert L2 après que la topologie de transfert a changé. Ceci est nécessaire pour éviter une panne de connectivité car, après un TC, certaines adresses MAC précédemment accessibles via des ports particuliers peuvent devenir accessibles via différents ports. TC raccourcit le délai de vieillissement de la table de transfert sur tous les commutateurs du VLAN où le TC se produit ; ainsi, si l’adresse n’est pas réapprise, elle expirera et une inondation se produira pour s’assurer que les paquets atteignent l’adresse MAC de destination.

TC est déclenché par le changement de l'état STP d'un port vers ou depuis l'état de transfert STP. Après TC, même si l’adresse MAC de destination particulière a expiré, l’inondation ne doit pas se poursuivre longtemps. L’adresse sera réapprise par le premier paquet provenant de l’hôte dont l’adresse MAC a été obsolète. La question pourrait se poser lorsque des TC se produisent à plusieurs reprises, à intervalles courts. Les commutateurs continueront à accélérer le vieillissement de leurs tables de transfert, de sorte que l’inondation sera presque constante.

Remarque : Avec le protocole STP rapide ou le protocole STP multiple (IEEE 802.1w et IEEE 802.1s), TC est déclenché par un changement de l'état du port en transfert, ainsi que par le changement de rôle désigné en racine. Avec le protocole Rapid STP, la table de transfert L2 est immédiatement vidée, par opposition à la norme 802.1d, ce qui réduit le temps de vieillissement. Le vidage immédiat de la table de transfert restaure la connectivité plus rapidement, mais provoquera davantage d'inondation.

TC devrait être un événement rare dans un réseau bien configuré. Lorsqu'une liaison sur un port de commutateur est activée ou désactivée, il y a finalement un TC, une fois que l'état STP du port est modifié vers ou depuis le transfert. Lorsque le port clignote, cela provoquerait des TC répétitifs et des inondations.

Les ports avec la fonctionnalité STP portfast activée ne provoqueront pas de TC lors de l'accès à ou depuis l'état de transfert. La configuration de portfast sur tous les ports des périphériques finaux (tels que les imprimantes, les PC et les serveurs) doit limiter les TC à un faible volume et est fortement recommandée. Pour plus d'informations sur les TC, référez-vous à Comprendre les modifications de topologie du protocole Spanning Tree.

S'il y a des TC répétitifs sur le réseau, vous devez identifier la source de ces TC et prendre des mesures pour les réduire, afin de réduire au minimum l'inondation.

Avec 802.1d, les informations STP sur un événement TC sont propagées parmi les ponts par le biais d'une notification TC (TCN), qui est un type spécial de BPDU. Si vous suivez les ports qui reçoivent des BPDU TCN, vous pouvez trouver le périphérique qui est à l'origine des TC.

Déterminer si l'inondation est causée par les TC STP

Normalement, vous pouvez déterminer qu'il y a inondation à partir de performances lentes, que les paquets tombent sur des liaisons qui ne sont pas supposées être encombrées, et que l'analyseur de paquets affiche plusieurs paquets de monodiffusion vers la même destination qui ne se trouve pas sur le segment local.

Pour plus d'informations sur l'inondation monodiffusion, référez-vous à Inondation monodiffusion dans les réseaux de campus commutés.

Sur un Catalyst 6500/6000 qui exécute le logiciel Cisco IOS, vous pouvez vérifier le compteur du moteur de transfert (uniquement sur le moteur Supervisor 2) pour estimer la quantité d'inondation. Émettez la commande remote switch show earl statistics | i MISS_DA|ST_FR, commande :

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

Dans cet exemple, la première colonne affiche la modification depuis la dernière exécution de cette commande et la deuxième colonne indique la valeur cumulée depuis le dernier redémarrage. La première ligne indique la quantité de trames inondées et la deuxième ligne indique la quantité de trames traitées. Si les deux valeurs sont proches les unes des autres ou si la première augmente à un rythme élevé, il se peut que le commutateur inonde le trafic. Cependant, cela ne peut être utilisé qu'en conjonction avec d'autres moyens de vérifier l'inondation, car les compteurs ne sont pas granulaires. Il y a un compteur par commutateur, pas par port ou VLAN. Il est normal de voir certains paquets inondés, car le commutateur inonde toujours si l’adresse MAC de destination ne figure pas dans la table de transfert. Ce sera le cas lorsque le commutateur reçoit un paquet avec une adresse de destination qui n’a pas encore été apprise.

Repérer la source des TC

Si le numéro de VLAN est connu pour le VLAN où une inondation excessive se produit, vérifiez les compteurs STP pour voir si le nombre de TC est élevé ou augmente régulièrement. Émettez la commande show spanning-tree vlan vlan-id detail (dans cet exemple, VLAN 1 est utilisé) :

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

Si le numéro de VLAN n'est pas connu, vous pouvez utiliser l'analyseur de paquets ou vérifier les compteurs TC pour tous les VLAN.

Prendre des mesures pour prévenir les TC excessifs

Vous pouvez surveiller le nombre de modifications de topologie pour voir si elles augmentent régulièrement. Ensuite, passez au pont connecté au port indiqué, pour recevoir le dernier TC (dans l'exemple précédent, le port GigabitEthernet1/1) et voir d'où le TC est venu pour ce pont. Ce processus doit être répété jusqu'à ce que le port de la station d'extrémité sans STP portfast activé soit trouvé, ou jusqu'à ce que la liaison de battement soit trouvée qui doit être corrigée. Il faut répéter toute la procédure si les TC proviennent toujours d'autres sources. Si la liaison appartient à un hôte final, vous devez configurer la fonctionnalité portfast pour empêcher la génération de TC.

Remarque : dans l'implémentation STP du logiciel Cisco IOS, le compteur pour les TC ne s'incrémente que si une BPDU TCN est reçue par un port dans un VLAN. Si une BPDU de configuration normale avec un indicateur TC défini est reçue, le compteur TC n'est pas incrémenté. Cela signifie que, si vous suspectez un TC d'être la raison de l'inondation, il est préférable de commencer à rechercher les sources du TC à partir du pont racine STP dans ce VLAN. Il disposera des renseignements les plus exacts concernant le montant et la source des TC.

Dépannage des problèmes liés au temps de convergence

Il y a des situations où le fonctionnement réel de STP ne correspond pas au comportement attendu. Voici les deux problèmes les plus fréquents :

• La convergence ou la reconvergence STP prend plus de temps que prévu.

• La topologie résultante est différente de ce qui était prévu.

Le plus souvent, ce sont les raisons de ce comportement :

• Incompatibilité entre la topologie réelle et la topologie documentée

• Une mauvaise configuration, telle qu'une configuration incohérente des compteurs STP, un diamètre supérieur à STP ou une mauvaise configuration de portfast

• CPU de commutateur surchargé lors de la convergence ou de la reconvergence

• Défaillance logicielle

Comme mentionné précédemment, ce document ne peut fournir que des directives générales pour le dépannage, en raison de la grande variété de problèmes qui pourraient affecter STP.

Pour comprendre pourquoi la convergence prend plus de temps que prévu, examinez la séquence des événements STP pour savoir ce qui se passait et dans quel ordre. Étant donné que la mise en oeuvre STP dans le logiciel Cisco IOS n'a pas de journalisation spéciale (sauf pour des événements spécifiques, tels que les incohérences de port), vous pouvez utiliser les fonctionnalités de débogage STP du logiciel Cisco IOS pour comprendre ce qui se passe.

Pour STP, avec un Catalyst 6500/6000 qui exécute le logiciel Cisco IOS, le traitement est effectué sur le processeur de commutation (SP) (ou Supervisor), de sorte que les débogages doivent être activés sur le SP. Pour les groupes de ponts du logiciel Cisco IOS, le traitement est effectué sur le processeur de routage (RP), de sorte que les débogages doivent être activés sur le RP (MSFC).

Commandes de débogage STP

De nombreuses commandes debug STP sont destinées à l'ingénierie de développement. Ils ne fournissent aucune sortie significative pour quelqu'un sans connaissance détaillée de la mise en oeuvre STP dans le logiciel Cisco IOS. Certains débogages peuvent fournir une sortie qui est instantanément lisible, comme les changements d'état des ports, les changements de rôle, les événements tels que les TC, et un vidage des BPDU reçus et transmis. Cette section ne fournit pas une description complète de tous les débogages, mais présente plutôt brièvement les plus fréquemment utilisés.

Remarque : Lorsque vous utilisez les commandes debug, activez le minimum de débogages nécessaires. Si aucun débogage en temps réel n'est nécessaire, enregistrez la sortie dans le journal plutôt que de l'imprimer sur la console. Les débogages excessifs peuvent surcharger le processeur et perturber le fonctionnement du commutateur. Pour diriger la sortie de débogage vers le journal au lieu de vers la console ou vers les sessions Telnet, émettez les commandes logging console informational et no logging monitor en mode de configuration globale.

Pour afficher le journal des événements généraux, exécutez la commande debug spanning-tree event pour Per VLAN Spanning-Tree (PVST) et Rapid-PVST. C'est le premier débogage qui donne une idée générale de ce qui se passe avec STP.

En mode Multiple Spanning-Tree (MST), il ne fonctionne pas pour émettre la commande debug spanning-tree event. Par conséquent, émettez la commande debug spanning-tree mstp rôles pour voir les modifications de rôle de port.

Pour afficher les modifications de l'état STP du port, exécutez la commande debug spanning-tree switch state avec la commande debug pm vp :

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

Pour comprendre pourquoi STP se comporte d’une certaine manière, il est souvent utile de voir les BPDU qui sont reçus et envoyés par le commutateur :

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

Ce débogage fonctionne pour les modes PVST, Rapid-PVST et MST ; mais il ne décode pas le contenu des BPDU. Cependant, vous pouvez l'utiliser pour vous assurer que les BPDU sont reçus.

Pour afficher le contenu du BPDU, exécutez la commande debug spanning-tree switch rx decode avec la commande debug spanning-tree switch rx process pour PVST et Rapid-PVST. Exécutez la commande debug spanning-tree mstp bpdu-rx pour afficher le contenu du BPDU pour MST :

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

Pour le mode MST, vous pouvez activer le décodage BPDU détaillé avec cette commande debug :

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

Remarque : Pour le logiciel Cisco IOS Version 12.1.13E et ultérieure, les débogages conditionnels pour STP sont pris en charge. Cela signifie que vous pouvez déboguer des BPDU qui sont reçus ou transmis par port ou par VLAN.

Émettez les commandes debug condition vlan vlan_num ou debug condition interface interface, pour limiter la portée du résultat debug à chaque interface ou par VLAN.

Sécurisation du réseau contre les boucles de transfert

Pour gérer l'incapacité de STP à gérer correctement certaines défaillances, Cisco a développé un certain nombre de fonctionnalités et d'améliorations pour protéger les réseaux contre les boucles de transfert.

Le dépannage du protocole STP permet d'isoler et éventuellement de trouver la cause d'une défaillance particulière, tandis que la mise en oeuvre de ces améliorations est le seul moyen de sécuriser le réseau contre les boucles de transfert.

Voici des méthodes pour protéger votre réseau contre les boucles de transfert :

1. Activez la détection de liaison unidirectionnelle (UDLD) sur toutes les liaisons de commutateur à commutateur. Pour plus d'informations sur UDLD, référez-vous à Comprendre et configurer la fonctionnalité du protocole de détection de liaison unidirectionnelle.

2. Activez la protection contre les boucles sur tous les commutateurs. Pour plus d'informations sur la protection contre les boucles, référez-vous à Améliorations du protocole Spanning Tree à l'aide de la protection contre les boucles et des fonctionnalités de détection des différences de temps de propagation des BPDU.

   Lorsque cette option est activée, UDLD et Loop Guard éliminent la majorité des causes possibles de boucles de transfert. Plutôt que de créer une boucle de transfert, la liaison offensante (ou toutes les liaisons dépendantes du matériel défaillant) est arrêtée ou bloquée.

   Remarque : Bien que ces deux fonctionnalités semblent quelque peu redondantes, chacune possède ses capacités uniques. Par conséquent, utilisez les deux fonctionnalités simultanément pour fournir le niveau de protection le plus élevé. Pour une comparaison détaillée de UDLD et de Loop Guard, référez-vous à Loop Guard vs. Unidirectional Link Detection.

   Il y a différentes opinions sur la nécessité d'utiliser un UDLD agressif ou normal. Il est à noter que l'UDLD agressif n'offre pas plus de protection contre les boucles que l'UDLD en mode normal. L'UDLD agressif détecte les scénarios de blocage de port (lorsque la liaison est active, mais qu'il n'y a pas de trous noirs de trafic associés). L'inconvénient de cette fonctionnalité supplémentaire est que l'UDLD agressif peut potentiellement désactiver les liaisons en l'absence de défaillance cohérente. Souvent, les utilisateurs confondent la modification de l'intervalle Hello UDLD avec la fonctionnalité UDLD agressive. C'est incorrect. Les minuteurs peuvent être modifiés dans les deux modes UDLD.

   Remarque : Dans de rares cas, un UDLD agressif peut arrêter tous les ports de liaison ascendante, ce qui isole essentiellement le commutateur du reste du réseau. Par exemple, cela peut se produire lorsque les deux commutateurs en amont connaissent une utilisation très élevée du CPU et que le mode UDLD agressif est utilisé. Par conséquent, il est recommandé de configurer errordisable-timeouts, si le commutateur n'a pas de gestion hors bande en place.

3. Activez portfast sur tous les ports des stations d'extrémité.

   Vous devez activer PortFast pour limiter la quantité de TC et la propagation subséquente, ce qui peut affecter les performances du réseau. Utilisez uniquement cette commande avec les ports qui se connectent aux stations d'extrémité. Sinon, une boucle topologique accidentelle peut provoquer une boucle de paquets de données et perturber le fonctionnement du commutateur et du réseau.

   Attention : Faites attention lorsque vous utilisez la commande no spanning-tree portfast. Cette commande supprime uniquement les commandes portfast spécifiques aux ports. Cette commande active implicitement portfast si vous définissez la commande spanning-tree portfast default en mode de configuration globale et si le port n'est pas un port agrégé. Si vous ne configurez pas portfast globalement, la commande no spanning-tree portfast est équivalente à la commande spanning-tree portfast disable.

4. Définissez EtherChannels sur le mode desirable des deux côtés (si pris en charge) et sur l'option non silencieuse.

   Le mode souhaitable active le protocole PAgP (Port Aggregation Protocol) pour assurer la cohérence du runtime entre les homologues de canalisation. Cela offre un niveau de protection supplémentaire contre les boucles, en particulier lors des reconfigurations de canaux (par exemple lorsque des liaisons rejoignent ou quittent le canal, et lors de la détection des défaillances de liaison). Il existe un dispositif intégré de protection contre les erreurs de configuration des canaux, qui est activé par défaut et qui empêche les boucles de transfert en raison d'une mauvaise configuration des canaux ou d'autres conditions. Pour plus d'informations sur cette fonctionnalité, référez-vous à Comprendre la détection des incohérences EtherChannel.

5. Ne désactivez pas la négociation automatique (si elle est prise en charge) sur les liaisons de commutateur à commutateur.

   Les mécanismes de négociation automatique peuvent transmettre des informations de panne à distance, ce qui est le moyen le plus rapide de détecter une défaillance sur le côté distant. Si une défaillance est détectée sur le côté distant, le côté local désactive la liaison même si celle-ci reçoit toujours des impulsions. Par rapport aux mécanismes de détection de haut niveau tels que UDLD, la négociation automatique est très rapide (en quelques microsecondes), mais elle ne couvre pas de bout en bout l'UDLD (comme l'ensemble du chemin de données : CPU—logique de transfert—port1—port2—logique de transfert—CPU versus port1—port2). Le mode UDLD agressif offre des fonctionnalités similaires à celles de la négociation automatique en ce qui concerne la détection des défaillances. Lorsque la négociation est prise en charge des deux côtés de la liaison, il n'est pas nécessaire d'activer UDLD en mode agressif.

6. Soyez prudent lorsque vous réglez les compteurs STP.

   Les temporisateurs STP dépendent les uns des autres et de la topologie du réseau. STP peut ne pas fonctionner correctement avec des modifications arbitraires apportées aux compteurs. Pour plus d'informations sur les compteurs STP, référez-vous à Compréhension et réglage des compteurs de protocole Spanning Tree.

7. Si des attaques par déni de service sont possibles, sécurisez le périmètre STP du réseau avec Root Guard.

   Root Guard et BPDU Guard vous permettent de sécuriser STP contre toute influence extérieure. Si une telle attaque est possible, Root Guard et BPDU Guard doivent être utilisés pour protéger le réseau. Pour plus d'informations sur Root Guard et BPDU Guard, reportez-vous aux documents suivants :

   • Amélioration de la protection de la racine du protocole Spanning Tree

   • Amélioration de la protection des BPDU en PortFast pour le spanning tree

8. Activez la protection BPDU sur les ports portfast, afin d'empêcher STP d'être affecté par les périphériques réseau non autorisés (tels que les concentrateurs, les commutateurs et les routeurs de pontage) connectés aux ports.

   Si Root Guard est correctement configuré, cela empêchera déjà le STP d'être influencé de l'extérieur. Si la protection BPDU est activée, elle arrêtera les ports qui reçoivent des BPDU (pas seulement des BPDU supérieures). Cela peut être utile si de tels incidents doivent être examinés, car BPDU Guard produit le message syslog et arrête le port. Il est à noter que les boucles de courte durée ne sont pas empêchées par les gardes racine ou BPDU, si deux ports portfast sont connectés directement ou via le concentrateur.

9. Évitez le trafic utilisateur sur le VLAN de gestion. Le VLAN de gestion est contenu dans un bloc de construction, pas dans l’ensemble du réseau.

   L’interface de gestion du commutateur reçoit des paquets de diffusion sur le VLAN de gestion. Si des diffusions excessives se produisent (par exemple une tempête de diffusion ou une application défectueuse), le processeur du commutateur risque d’être surchargé, ce qui pourrait fausser le fonctionnement du protocole STP.

10. Emplacement prévisible (codé en dur) de la racine STP et de la racine STP de sauvegarde.

    La racine STP et la racine STP de secours doivent être configurées de sorte que la convergence, en cas de panne, se produise de manière prévisible et crée une topologie optimale dans chaque scénario. Ne laissez pas la priorité STP à la valeur par défaut, pour empêcher la sélection de commutateur racine imprévisible.

Informations connexes

• Support pour les produits LAN
• Prise en charge de la technologie de commutation LAN
• Support et documentation techniques - Cisco Systems