Comment diagnostiquer une boucle de pontage (ethernet)?

Étant donné que le spanning tree a échoué (ou si vous n'en avez pas) et que vous obtenez une boucle Ethernet, quel est le meilleur moyen de diagnostiquer le problème?

Quel commutateur? Quel câble? etc.

OK, supposons que votre topologie soit la suivante:

          SW1
         /   \
        /     \
       /       \
PC A--SW2-----SW3--PC B

Pour une raison quelconque, il existe une boucle de pontage, STP est désactivé ou quelqu'un a appliqué un filtre au mauvais endroit ou à un autre.

Le PC A veut communiquer avec le PC B. Ce sont les premiers ARP pour le MAC du PC B, la destination est une diffusion avec le MAC ffff.ffff.ffff. Donc, le cadre va à la fois SW1 et SW3. Le SRC MAC est le PC A. SW1 inonde alors la trame vers SW3 et SW3 inondera la trame provenant de SW2 à SW1.

SW1 et SW3 ont appris le MAC du PC A lorsque la première image est entrée. Lorsque la seconde image provient de la direction opposée, elle doit la réapprendre. Parce que ces événements se produisent si rapidement et à maintes reprises, vous verrez des messages de journal se plaindre du flapping MAC. Quelque chose comme "MAC FLAP 0000.0000.0001 oscille entre Gi0 / 24 et Gi0 / 23". C'est bon signe que vous avez une boucle.

Ce que vous pourriez faire alors, c'est d'essayer de retracer ce MAC. Essayez de rechercher dans le cache ARP d'un périphérique du même sous-réseau et voyez quelle adresse IP ce périphérique a. Donc, avec le MAC, vous pouvez essayer de le tracer avec sh mac-address-table ou avec l’IP, peut-être avez-vous une liste avec toutes les IP et leur emplacement de connexion.

Si l'hôte obtient une adresse IP d'un serveur DHCP, vous pouvez également essayer de localiser l'origine de l'hôte. Si vous avez activé l'option 82, ce serait d'une grande aide.

D'autres signes indiquent que la CLI sera très lente. La charge du processeur sera très élevée. Les commutateurs font presque tout dans les ASIC. Par conséquent, si un commutateur a une charge de processeur supérieure à 50%, il n’est probablement pas bon. Vous devez implémenter la surveillance SNMP et surveiller la charge de processeur élevée. Recherchez également les messages de volet MAC. Si les commutateurs ont une boucle, les voyants clignoteront probablement comme un fou.

Ce que vous pouvez faire pour vous protéger contre les boucles:

• Activer STP! (duh)
• Surveillance SNMP de la charge du processeur
• Activer les interruptions SNMP pour certains événements tels que les changements de topologie STP
• Activer le contrôle des tempêtes sur les ports pour limiter la diffusion
• Ne couvrez pas trop vos VLAN dans votre topologie L2
• Activer la sécurité du port et limiter le nombre d'adresses MAC par port
• Activer Option82 si vous exécutez DHCP

Un de mes utilisateurs a récemment emprunté un commutateur de bureau au bureau de quelqu'un. Au retour du commutateur, ils ont branché toutes les extrémités lâches d'Ethernet qui se trouvaient à proximité. Un de ces câbles est allé au réseau et un autre était deux extrémités du même câble. Le commutateur de bureau était branché sur le réseau et également sur lui-même. Le commutateur ne disposant pas de STP, les émissions en provenance du réseau passaient en boucle sur l'autre câble dans les deux sens. Bien sûr, chaque fois qu'une émission est reçue sur les ports en boucle, elle est répliquée sur le réseau. Cela rendait HSRP complètement fou et, en raison d'une conception médiocre, il entraînait également des échecs de contiguïté OSPF sur le campus.

La première indication du problème était un macflap transmis à mon courrier électronique. Cela nous a immédiatement conduit à la bonne armoire de câblage. À partir de là, le processus d'élimination reposait sur les voyants de port, l'interface pps et les journaux. Inutile de dire que j'ai depuis ré-architecturé tout le campus. La meilleure mesure préventive est probablement bpduguard. J'ai depuis déployé la fonctionnalité et c'était assez simple. Obtenir ce syslog errdisable dans mon courrier électronique n'est rien de moins que du bonheur.

Avec la plupart des équipements, le processeur atteint 100% et la seule chose à faire est de rompre les connexions physiques redondantes. Une fois que la CPU s'est calmée, vous pouvez reconnecter les liens un par un et voir lequel cause la boucle.

Pour les gros châssis (comme un 6500), j'ai dû retirer toutes les lames et les rebrancher une par une. Une fois que j'ai déterminé quelle lame, je devais alors tirer tous les liens individuels (16 GBIC) et les replacer un à la fois. Jamais amusant.

Certains équipements plus modernes ont un processeur protégé, ce qui devrait faciliter la tâche. Vous pouvez toujours interagir avec le boîtier. À ce stade, il est possible d’observer les compteurs de trafic et déterminer le lien défaillant.

J'ai récemment démarré dans une entreprise qui utilise des limites de diffusion sur chaque port. Si un port dépasse 5% de sa capacité, le commutateur le met dans ERRDISABLE.

 storm-control broadcast level 5.00  
 storm-control action shutdown

Cela a permis de sauver des vies lorsqu'un groupe a tendance à brancher des périphériques qui relient les réseaux sans fil au réseau local.

Bien que pour votre question réelle, j'ai toujours trouvé que c'était manuel.

pour IOS:

Vous aurez probablement des adresses MAC flottant entre les ports .. recherchez les MAC_MOVE_NOTIFICATIONerreurs (ou des erreurs similaires) dans:

sh logg

Maintenant pour trouver le port:

sh int g0/1 controller

cherchez hors de l'ordinaire Multicastet des Broadcastchiffres. Toute collision est un mauvais signe.

Dernier point mais non le moindre, vous ne pouvez pas vous connecter, car le processeur est utilisé :)

sh proc cpu

Comment se passe le changement ici? S'il ne s'agit que d'un commutateur L2, vous ne voulez rien de supérieur à ~ 10%.

Dans le cas où vous avez non géré, ou l'équivalent de non géré (informations de connexion manquantes ou connaissance du système d'exploitation du commutateur, etc.), de commutateurs et d'une boucle de pont, je décris comment je procéderais pour la trouver manuellement. Cela répond également au fond fondamental de la question initiale, "vous n'avez pas STP".

L'algorithme de base pour la localisation d'erreur dans cette boucle est similaire à STP, sauf que vous n'avez pas facilement accès à l'envoi de BPDU contenant des ID de port.

• Commencez par connecter un périphérique capable de renverser / renvoyer des paquets à un port de l’un des commutateurs. Ce périphérique est maintenant devenu le périphérique racine de votre arborescence.
  • Si vous devez localiser les pannes à plusieurs endroits, par exemple sur un "campus" ou un site similaire, vous avez tout intérêt à pouvoir vous connecter à distance avec un client ssh portable à la machine de transfert de paquets.
    • Personnellement, j'utilisais mon ordinateur portable Linux avec une connexion Internet avec tcpdump sur un écran et SSH, par exemple, depuis un ipad ou un téléphone.
  • Si vous ne parvenez pas à vous connecter à distance, utilisez un ami pour surveiller visuellement le tcpdump, qui submerge probablement à la vitesse du lien, ce qui permet de remarquer facilement une différence lorsque le chemin d'accès au périphérique source de la boucle est déconnecté.
• Ensuite, vous devrez essentiellement recréer un arbre, à partir de votre commutateur racine.
  1. Et parce que vous pouvez avoir le scénario où vous avez plusieurs liens en boucle alimentant votre périphérique racine, vous devez commencer par supprimer tous les ports connectés simultanément.
  2. Reconnectez les ports un à un et si à tout moment la rafale de paquets réapparaît, suivez ce port vers le commutateur connecté à l'autre extrémité.
  3. Répétez l'étape 1 jusqu'à ce que vous trouviez le (s) port (s) en boucle et que vous ne puissiez plus effectuer une itération plus détaillée dans votre arborescence manuelle.
  4. Une fois la situation de boucle résolue dans ce commutateur, revenez au commutateur situé en haut de l’arborescence et reprenez l’étape 2. Cette récursivité se poursuit jusqu’à ce que le dernier câble soit reconnecté à votre commutateur racine.

Il s'agit d'une recherche manuelle complètement exhaustive des ports en boucle.

En règle générale, une seule paire de ports est bouclée, ce qui signifie que la recherche exhaustive et sécurisée avec suppression préalable de tous les ports connectés (liaison), puis de les reconnecter un par un est inutile. Si une seule paire de ports dans l'arborescence est bouclée, vous pouvez la trouver en déconnectant simplement un port à la fois.

Néanmoins, la méthode, ou algorithme, "anti-faute" devient ce que j'ai décrit ci-dessus.

Aie. Mais ok, je peux penser à deux façons de faire ça ...

Eyeball it: Si les commutateurs ont des indicateurs de port, vous devriez pouvoir déterminer quels ports sont les plus actifs. Ce sont ceux-là pour commencer à regarder en premier. Espérons que les câbles sont étiquetés afin que vous puissiez rechercher le moyen facile de trouver deux ports occupés, sur deux commutateurs avec le même câble.

Surveillance SNMP: Si vous disposez de statistiques d'utilisation SNMP (ou similaires), recherchez le commutateur et les ports les plus actifs. Puis regarde les câbles.

... si vous avez des câbles non étiquetés, commencez à rechercher et à étiqueter dans le cadre de la vérification des ports les plus occupés.

Je vais répondre à cette question en partant du principe qu'il y a une panne totale du domaine de la couche 2 en question et que vous ne disposez d'aucun accès de gestion, car les processeurs sont tous indexés.

Le meilleur moyen de dépanner une boucle de pontage est de commencer à débrancher les liaisons montantes jusqu'à ce qu'elles disparaissent. Supposons que vous ayez une couche d'accès commutée standard avec tous les commutateurs d'accès connectés dans une paire de commutateurs de distribution. Allez au premier commutateur d'accès et débranchez les liaisons montantes. Si les voyants des switchports cessent de fonctionner, ce n'est pas ce commutateur, rebranchez-le et passez au suivant. Répétez l'opération jusqu'à ce que vous arriviez à un commutateur où vous avez débranché les liaisons montantes et que les voyants continuent de clignoter rapidement. Il s'agit de votre commutateur avec la boucle.

Maintenant, démarrez le processus de débranchement sur les ports des utilisateurs finaux jusqu’à ce que les voyants s’éteignent, le dernier à vous débrancher était le port posant problème, tracez le câble et corrigez l’utilisateur de manière appropriée.

Pour être honnête, si vous êtes connecté à distance (ou via un câble de console) à l'appareil, vous remarquerez qu'il est très lent, il y aura un délai entre le moment où vous tapez et les lettres qui apparaissent sur la CLI.

Si c’est un commutateur Cisco, il est facile de consulter les statistiques de l’interface, il utilisera 100% (ou 255/255) en permanence. Au cours de mes années consacrées aux commutateurs, je n’ai encore jamais vu un port légitimement atteindre une utilisation à 100%. En dehors de cela, vérifiez l'utilisation du processeur (généralement "Afficher l'historique des processeurs"), les interfaces en boucle affecteront généralement votre processeur assez fort, sauf si vous utilisez un commutateur haut de gamme.

STP devrait vraiment être activé cependant!

J'avais ce problème sur un réseau à l'autre bout des États-Unis et je devais aider à distance des analystes de niveau 1 via le téléphone et mon lien WAN vers leur site. Le problème était encore compliqué par le fait qu’ils possédaient plusieurs marques de commutateurs qu’ils avaient lentement ajoutés au réseau au fil des ans. Quand ils ont déménagé, ils ont indiqué où chaque port est allé, puis ont tout rattaché de la même manière dans le nouveau bureau et tout a commencé. Inutile de dire que la poignée de commutateurs qui fonctionnaient avec Spanning Tree ne convergeait pas de la même manière et comportait toutes sortes de boucles et de problèmes. Au moment où j’avais fini de tout réparer, on a découvert que pas moins de trois commutateurs non gérés avaient été connectés en boucle au reste de l’infrastructure.

J'ai été en mesure de localiser chacun des commutateurs non gérés en utilisant un outil appelé nedi (sur les commutateurs pouvant être gérés, j'ai activé lldp / cdp). J'ai d'abord généré des cartes avec Nedi. Ensuite, dans les zones où la carte indiquait les connexions d'un commutateur à un autre, puis de nouveau au même commutateur, le technicien réseau sur place a tracé la ligne manuellement. J'ai arrêté manuellement les interfaces impliquées dans la boucle ou demandé à la personne sur place de débrancher les câbles. En fin de compte, j'ai réussi à faire fonctionner le réseau comme il se doit, malgré tous les changements de marques fous.

Une chose à faire ici est de voir quelles machines sont connectées au commutateur à l’aide des commandes show cdp neighborou show lldp neighbor.

Si la commande de protection BPDU n'est pas utilisée et que quelqu'un connecte un commutateur non autorisé avec une priorité plus faible (ou une adresse MAC ancienne), le nouveau périphérique négociera en tant que racine Spanning Tree, ce qui posera sûrement un problème.

D'après mon expérience, c'est toujours le câble que je viens de brancher, ou qui n'est pas fermé ou ajouté au port-channel. Ce qui est plus difficile, c'est quand quelqu'un d'autre l'a fait et ne craint pas immédiatement.

Déterminer une boucle dépend vraiment de la marque de commutateur que vous avez. Par exemple, sur un commutateur Extreme, je peux exécuter elrp-client sur un VLAN et le commutateur enverra une trame de diffusion sur tous les ports de ce VLAN et verra s'il retourne par l'un d'eux. Si tel est le cas, il me dira lequel port (s) la trame a été reçue, révélant ainsi les candidats à la boucle.

Sur un Cisco, vous pouvez activer le contrôle de tempête, qui est un peu plus un instrument contondant puisqu'il bloquera le port pendant un certain temps jusqu'à ce que l'état disparaisse (ou que vous effaciez l'état errdisable) - d'une manière générale cependant, ce type n’est pertinent que lorsque vous utilisez des commutateurs Cisco dans une topologie mixte de périphériques qui ne couvrent pas et n’expédient pas de BPDU.

L’approche la plus rapide que j’ai trouvée est sans aucun doute la surveillance du débit des interfaces paquet / seconde. Une interface d'affichage rapide avec un filtre CLI approprié listera chaque interface et le débit paquet / seconde. Pour trouver la source de la boucle, recherchez la seule interface avec un débit INPUT élevé de paquets / s. Dans un environnement d'entreprise typique, avec des profils d'utilisation typiques, cela fonctionne à tout moment. Sur un 6500 avec de nombreuses interfaces, il ne faut pas longtemps pour repérer la source ...

Pendant la boucle, pour un grand nombre de flux de diffusion (par exemple, une requête ARP) au niveau de la station d'extrémité, la charge de la CPU peut également augmenter (par exemple, si vous utilisez une carte realtek à 100 Mbit / s bon marché qui calcule une somme de contrôle sur la CPU). Comme physiquement possible de trouver une boucle si le câble est déconnecté, la liaison a été perdue immédiatement sur 2 ports.