Commutation LAN : Protocole Spanning Tree

Présentation des changements de topologie SPT (Spanning-Tree Protocol)

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (7 octobre 2015) | Commentaires


Interactif : Ce document propose une analyse personnalisée de votre périphérique Cisco.


Contenu


Introduction

Lorsque vous surveillez les opérations du protocole STP (Spanning-Tree Protocol), l’augmentation du nombre de modifications de topologie dans le journal des statistiques peut vous inquiéter. Les modifications de topologie sont normales dans le protocole STP. Cependant, un nombre trop important de modifications peut avoir un impact sur les performances du réseau. Ce document indique que le but de cette topologie est de :

  • Modifier le mécanisme dans les environnements PVST (Per VLAN Spanning Tree) et PVST+.

  • Déterminer le déclencheur d’une modification de topologie.

  • Décrire les problèmes liés au mécanisme de modification de topologie.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et 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. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Objectif du mécanisme de modification de topologie

Grâce aux trames qu’il reçoit, un pont crée une table associant à un port les adresses MAC (Media Access Control) des hôtes pouvant être atteints via ce port. Cette table est utilisée pour transférer les trames directement à leur port de destination, ce qui évite les inondations.

Le délai de vieillissement par défaut de cette table est de 300 secondes (cinq minutes). L’entrée disparaît de la table du pont uniquement lorsqu’un hôte est silencieux depuis cinq minutes. Voici un exemple indiquant pourquoi il peut être nécessaire d’accélérer ce vieillissement :

Dans ce réseau, supposons que le pont B1 bloque son lien vers B4. A et B sont deux stations possédant une connexion établie. Le trafic entre A et B se dirige vers B1, B2, B3 et B4. Le schéma indique la table d’adresses MAC apprise par les quatre ponts dans cette situation :

17a.gif

Supposons maintenant que le lien entre B2 et B3 présente une défaillance. La communication entre A et B est interrompue au minimum jusqu’à ce que B1 passe son port vers B4 en mode de transfert (ce qui prend 50 secondes au maximum avec les paramètres par défaut). Cependant, lorsque A souhaite envoyer une trame à B, B1 dispose toujours d’une entrée menant à B2 et le paquet est envoyé vers un trou noir. Le même s'applique quand B veut atteindre A. Communication est perdu pendant cinq minutes, jusqu'aux entrées pour des adresses MAC A et B vieillissent.

/image/gif/paws/12013/17b.gif

Le transfert de bases de données implémentées par des ponts est très efficace dans un réseau stable. Cependant, le délai de vieillissement de cinq minutes pose souvent un problème après la modification de la topologie du réseau. Le mécanisme de modification de topologie permet de contourner ce type de problème. Lorsque le pont détecte une modification de la topologie du réseau (désactivation ou passage en mode de transfert d’un lien), il annonce l’événement à l’ensemble du réseau ponté.

L’implémentation pratique de cette action est décrite dans la section Principe de fonctionnement. Chaque pont est notifié et réduit le délai de vieillissement à la valeur paramètre forward_delay (qui est de 15 secondes par défaut) pendant une certaine période (max_age + forward_delay). Une réduction du délai de vieillissement est plus avantageuse qu’une suppression de la table car les hôtes actifs (qui transmettent efficacement le trafic) ne sont pas supprimés de la table.

Dans cet exemple, le pont B2 ou B3 envoie des notifications de modification de topologie dès qu’il détecte une désactivation de lien. Tous les ponts sont alors informés de l’événement et réduisent leur délai de vieillissement à 15 secondes. Puisque B1 ne reçoit aucun paquet depuis B sur son port relié à B2 dans un délai de quinze secondes, il expire l’entrée de B sur ce port. Le même événement se produit pour l’entrée de A sur le port reliant B3 à B4. Plus tard, lorsque le lien entre B1 et B4 passe en mode de transfert, le trafic est immédiatement inondé et réappris sur ce lien.

Principe de fonctionnement

Cette section explique comment une passerelle annonce une modification de topologie au niveau du Bridge Protocol Data Unit (BPDU).

Le moment auquel un pont considère qu’il a détecté une modification de topologie a déjà été brièvement expliqué. Voici la définition exacte :

  • Lorsqu’un pont effectuant des transferts est désactivé (crée un blocage, par exemple).

  • Lorsqu’un port passe en mode de transfert et que le pont possède un port désigné. (c’est-à-dire que le pont n’est pas autonome).

Le processus d’envoi de notifications à tous les ponts du réseau comporte deux étapes :

  • Le pont notifie le pont racine du spanning tree.

  • Le pont racine « diffuse » l’information dans l’ensemble du réseau.

Notification du pont racine

En fonctionnement STP normal, un pont reçoit en continu des BPDU de configuration sur son port racine depuis le pont racine. Cependant, il n’envoie jamais de BPDU vers le pont racine. Pour ce faire, une BPDU spéciale appelée BPDU de notification de modification de topologie (NMT) a été introduite. Par conséquent, lorsqu’un pont doit signaler une modification de topologie, il commence à envoyer des NMT sur son port racine. Le pont désigné reçoit la NMT, en accuse réception, puis en génère une autre pour son propre port racine. Le processus se poursuit jusqu’à ce que la NMT atteigne le pont racine.

/image/gif/paws/12013/17c.gif

LA NMT est une BPDU très simple (ne contenant aucune information) envoyée par le pont toutes les hello_time secondes (paramètre hello_time configuré localement et non celui spécifié dans les BPDU de configuration). Le pont désigné accuse réception de la NMT en renvoyant immédiatement une BPDU de configuration normale avec l’ensemble de bits accusé de réception de modification de topologie. Le pont notifiant la modification de topologie envoie ses NMT jusqu’à ce que le pont désigné en accuse réception. Par conséquent, le pont désigné répond à la NMT bien qu’il ne reçoive pas de BPDU de configuration depuis sa racine.

Diffusion de l’événement sur le réseau

Une fois que la racine sait qu’une modification de topologie s’est produite sur le réseau, elle commence à envoyer des BPDU de configuration avec l’ensemble de bits de modification de topologie (MT). Ces BPDU sont relayées par chaque pont du réseau avec cet ensemble de bits. Les ponts ont alors tous connaissance de la modification de topologie et la racine peut réduire son délai de vieillissement à la valeur de forward_delay. Les ponts reçoivent des BPDU de modification de topologie sur les ports de transfert et de blocage.

Le bit MT est défini par la racine pour une période maximale correspondant (en secondes) à max_age + forward_delay, soit 20 + 15 = 35 secondes par défaut.

17d.gif

Que faire lorsque qu’il existe de nombreuses modifications de topologie dans le réseau

Voici certains problèmes pouvant être générés par les NMT. Des informations relatives à la méthode de limitation des modifications de topologie et à la recherche de leur provenance sont ensuite fournies.

Si vous disposez de la sortie d'une commande show-tech support de votre dispositif Cisco, vous pouvez utiliser l'outil Output Interpreter (clients enregistrés uniquement) pour afficher les problèmes potentiels ainsi que les correctifs. Pour utiliser l’outil Output Interpreter (clients enregistrés uniquement) , vous devez être enregistré et connecté, et JavaScript doit être activé.

Trafic inondé

Plus le serveur comporte d’hôtes, plus la topologie a de chances d’être modifiée. Par exemple, un hôte directement relié déclenche une modification de topologie lorsqu’il est alimenté. Dans les très grands réseaux (et réseaux plats), le réseau peut atteindre un point où la topologie est en constante modification. C'est comme si le délai de vieillissement était configuré sur quinze secondes, ce qui entraîne un niveau élevé d’inondation. Voici un scénario catastrophique arrivé à un client qui effectuait une sauvegarde du serveur.

17e.gif

L’expiration de l’entrée du périphérique recevant la sauvegarde était désastreuse car elle a causé une très importante augmentation du trafic pour tous les utilisateurs. Pour plus d’informations sur la manière d’éviter la génération de TCN, reportez-vous à la section Éviter la génération de notifications de modification de topologie (TCN) à l’aide de la commande Portfast.

Problème dans les environnements pontés ATM LANE

Ce cas est plus grave que les cas d’inondation normale du trafic résultant d’un vieillissement rapide. À la réception d’une modification de topologie pour un VLAN, les lames d’émulation LAN (LANE) d’un commutateur Catalyst reconfigurent leur table LE-arp pour le LAN émulé (ELAN) correspondant. Toutes les lames LAN du réseau ELAN envoient la même demande au même moment, ce qui peut imposer une forte contrainte au LAN Emulation Server (LES) si de nombreuses entrées doivent être reconfirmées. Nous avons abordé les problèmes de connectivité dans ce scénario. Si le réseau est sensible aux modifications de topologie, le réel problème n’est pas la modification de topologie en elle-même, mais la conception du réseau. Nous vous recommandons de limiter autant que possible la génération de TCN afin de préserver le CPU du LES (au minimum). Pour plus d’informations sur la manière de limiter la génération de TCN, reportez-vous à la section Éviter la génération de notifications de modification de topologie (TCN) à l’aide de la commande Portfast.

Éviter la génération de notifications de modification de topologie (NMT) à l’aide de la commande Portfast

La fonctionnalité portfast est une modification propriétaire Cisco de l’implémentation du protocole STP. La commande est appliquée à des ports spécifiques et a deux effets :

  • Les ports activés sont directement placés en mode de transfert STP et ne passent pas par le processus d’apprentissage et d’écoute. Le protocole STP s’exécute toujours sur des ports disposant de portfast.

  • Le commutateur ne génère jamais de NMT lorsqu’un port configuré pour portfast s’active ou se désactive.

Activez portfast sur les ports sur lesquels les hôtes connectés sont très susceptibles d’activer ou de désactiver leur lien (il s’agit généralement de terminaux que les utilisateurs mettent fréquemment sous tension et hors tension). Normalement, cette fonctionnalité n’est pas nécessaire pour les ports de serveur. Elle doit être utilisée sur les ports menant à des concentrateurs ou à d’autres ponts. Un port passant directement en mode de transfert sur un lien redondant peut créer des boucles de pontage temporaires.

Les modifications de topologie peuvent être utiles. N’activez donc pas portfast sur un port pour lequel une activation/désactivation de lien est un événement significatif pour le réseau.

Rechercher la source d’une TCN

Les modifications de topologie en elles-mêmes ne sont pas une mauvaise chose, mais un bon administrateur réseau doit connaître leur origine afin de s’assurer qu’elles ne sont pas liées à un réel problème. L’identification du pont ayant émis la modification de topologie n’est pas aisée. Toutefois, ce n’est pas complexe d’un point de vue technique.

La plupart des ponts comptabilisent uniquement le nombre de TCN qu’ils ont envoyées ou reçues. Les commutateurs Catalyst 4500/4000, 5500/5000 et 6500/6000 peuvent afficher le port et l’ID du pont ayant envoyé la dernière modification de topologie qu’ils ont reçue. Il est alors possible de remonter jusqu’au pont émetteur à partir de la racine. Pour plus d’informations, reportez-vous à la commande show spantree statistics.

Si vous possédez la sortie d’une commande show spantree statistics de votre périphérique Cisco, utilisez l’outil Output Interpreter (clients enregistrés uniquement) pour afficher les problèmes potentiels ainsi que les correctifs. Pour utiliser l’outil Output Interpreter (clients enregistrés uniquement) , vous devez vous connecter en tant qu’utilisateur inscrit et JavaScript doit être activé.

Conclusion

Il est important de considérer qu’une NMT ne lance pas de nouveau calcul STP. Cette crainte provient du fait que les TCN sont souvent associées à des environnements STP instables. Les NMT en sont la conséquence et non la cause. Elles ont un impact uniquement sur le délai de vieillissement. Elles ne changent pas la topologie ni créent de boucle.

Le nombre ou le taux de modifications de topologie n’est pas un problème en soi. Le problème est de savoir la signification de la modification de topologie. Un réseau sain peut subir un taux élevé de modifications de topologie. Cependant, une modification de topologie doit être idéalement liée à un événement significatif dans le réseau, tel que l’activation ou la désactivation d’un serveur ou une transition de lien. Cela est possible grâce à l’activation de la commande portfast sur les ports dont le fonctionnement normal implique des activations et désactivations.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 12013