Tempête de broadcast, adresses MAC qui oscillent entre les ports, la moitié du réseau injoignable — voici à quoi ressemble une boucle de niveau 2 vue de l'intérieur. Voici comment confirmer que c'est bien une boucle, la trouver vite, la casser sans aggraver la situation, et l'empêcher de revenir, avec les vraies commandes de diagnostic et les cas de mauvaise configuration tirés du manuel de maintenance des commutateurs Huawei.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Les liens et équipements redondants sont censés rendre un réseau plus fiable — jusqu'à ce qu'un changement de réseau forme une véritable boucle, et cette même redondance se transforme en tempête de broadcast.
Les réseaux de commutation Ethernet déploient des équipements et des liens redondants délibérément, pour la fiabilité. Mais les ajustements réseau, les changements de configuration et les mises à niveau de version créent régulièrement, par accident, des trames de données ou de protocole qui circulent en anneau — et dès qu'un protocole de rupture de boucle ne tourne pas, ou qu'un changement de configuration y perce silencieusement un trou, cette redondance devient une tempête de broadcast au lieu d'un filet de sécurité. Une seule trame broadcast prise dans une boucle est retransmise sur tous les autres ports de chaque commutateur de l'anneau, encore et encore, jusqu'à saturer chaque lien près du débit ligne — et le trafic normal n'a tout simplement plus jamais son tour.
Cette note couvre comment déterminer que c'est bien ce qui se passe (par opposition à un autre type de panne), comment localiser la boucle rapidement, comment la casser sans aggraver la panne, et les cas spécifiques de mauvaise configuration — VLAN 1 laissé sur un port, ports edge STP jamais réglés, régions MSTP qui ne correspondent pas, nœuds RRPP fonctionnant dans des modes différents — qui représentent une grande part des boucles qui n'auraient jamais dû exister au départ.
Les symptômes d'une boucle et le flux de confirmation en quatre méthodes, côte à côte.
Les quatre méthodes de confirmation ci-dessous n'ont pas d'ordre fixe — utilisez-en une ou plusieurs ensemble, selon celle à laquelle la situation vous donne accès en premier.
Les légendes du schéma restent en anglais pour la clarté technique.
Les quatre reposent sur des commandes déjà disponibles sur chaque commutateur — aucun outillage spécial requis.
Exécutez display interface brief et comparez deux relevés à un court intervalle : sur un port portant une boucle, InUti et OutUti grimpent régulièrement vers le plafond de débit du port. Si un seul port d'un seul appareil montre un trafic lourd dans les deux sens, suspectez un auto-boucle sur un seul port ; si deux ports d'un même appareil sont tous deux lourds, suspectez une boucle à deux ports provoquant une oscillation de protocole ; si un seul sens est lourd sur un port unique, la boucle est plus probablement en aval de ce port plutôt que sur lui.
<HUAWEI> display interface brief | include up
Interface PHY Protocol InUti OutUti inErrors outErrors
GigabitEthernet0/0/16 up up 76% 76% 0 0
GigabitEthernet1/0/12 up up 76% 76% 0 0
// both interfaces climbing toward rate ceiling between two readings -- consistent with a loop
<HUAWEI> display interface XGigabitEthernet2/0/1
Broadcast: 184920331, Multicast: 20524
// broadcast/multicast counters far above this device's other interfaces point at the same conclusionL'oscillation MAC se produit quand une interface apprend une adresse MAC qu'une autre interface du même VLAN apprend aussi — le dernier apprentissage écrase l'entrée antérieure. Une boucle produit toujours une oscillation MAC ; une oscillation MAC ne signifie pas toujours une boucle (elle peut aussi signifier une attaque non autorisée), mais voir la même adresse MAC rebondir entre deux ports précis est la confirmation directe la plus fiable disponible.
[HUAWEI] vlan 10
[HUAWEI-vlan10] loop-detect eth-loop alarm-only
<HUAWEI> display trapbuffer
L2IFPPI/4/MFLPVLANALARM:OID 1.3.6.1.4.1.2011.5.25.160.3.7 Loop exists in vlan 1001, for
flapping mac-address 0025-9e6e-1c55 between port GE2/1/23 and port GE2/1/22.
// the same MAC bouncing between two named ports in the same VLAN -- direct evidence of a loopLoop Detection (commutateurs châssis) et Loopback Detection (tous les formats de commutateurs) envoient périodiquement une trame de détection spéciale hors d'une interface et vérifient si l'appareil lui-même la reçoit en retour — soit sur la même interface (auto-boucle), soit sur une autre (boucle réseau). C'est le moyen le plus direct de prouver qu'une boucle existe, au prix de ressources système supplémentaires, raison pour laquelle le manuel recommande explicitement de la désactiver à nouveau une fois la vérification terminée, et de ne jamais l'activer sur un port montant.
[HUAWEI] loopback-detect enable
<HUAWEI> display loopback-detect
Loopback-detect is enabled in the system view
Interface ProtocolID RecoverTime Action Status
GigabitEthernet0/0/2 602 30 block NORMAL
// "Status" flips away from NORMAL the moment this device receives its own detection frame back
[HUAWEI] undo loopback-detect enable
// disable again once the check is complete -- this is a diagnostic tool, not a permanent settingUne part de tâche PPI (Product Process Interface) élevée dans display cpu-usage — soutenue, pas un pic bref — suggère fortement qu'une boucle inonde le CPU de paquets qu'il doit traiter. Si le PPI lui-même semble normal, vérifiez display cpu-defend statistics pour des paquets de protocole rejetés par la limitation de débit ; un rejet important dans ce sens pointe dans la même direction.
<HUAWEI> display cpu-usage
CPU Usage : 91% Max: 96%
TaskName CPU Runtime Task Explanation
PPI 70% 0/512f8c PPI Product Process Interface
// a sustained high PPI share, not a brief spike, is the pattern that suggests a loop
<HUAWEI> display cpu-defend vrrp statistics all
Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(Packets)
vrrp 79880066214 2581617736 1174644777 37950869
// heavy protocol packet drop under rate-limiting is consistent with a loop saturating the linkUne fois la boucle confirmée, la priorité passe du diagnostic au rétablissement de l'activité — aussi vite que possible, sans introduire un second problème.
[SwitchA-GigabitEthernet1/0/1] undo port trunk allow-pass vlan 1
// narrowest-impact break: remove only the looped VLAN from this one port
[SwitchA-GigabitEthernet1/0/1] shutdown
// broader but reversible -- undo shutdown restores the port once the loop is actually fixedSYMPTÔMEL'activité tombe entièrement en panne sur un commutateur à double montée, un redémarrage la rétablit brièvement, et la même panne exacte revient quelque temps après.
CAUSEChaque port trunk porte le VLAN 1 par défaut à moins qu'il ne soit explicitement retiré. Si deux ports qui ne devraient jamais partager un domaine de broadcast portent tous deux encore le VLAN 1, ce VLAN forme une boucle même pendant que l'instance STP ou RRPP protégeant réellement les autres VLAN fonctionne parfaitement — parce que le VLAN 1 n'a jamais été inclus dans ce que ces protocoles protègent.
SOLUTIONVérifiez un VLAN 1 commun parmi les ports montrant un trafic anormal, puis soit retirez le VLAN 1 des ports qui n'en ont pas besoin (undo port trunk allow-pass vlan 1), soit intégrez explicitement le VLAN 1 dans l'instance protégée s'il doit réellement circuler sur l'anneau.
SYMPTÔMESTP est activé globalement sur les deux commutateurs, mais le réseau est quand même inondé de trafic broadcast comme si aucun protocole de rupture de boucle ne tournait du tout.
CAUSESur les versions de commutateur concernées, un port a besoin de bpdu enable configuré avant de réellement transmettre les BPDU STP reçus au CPU pour traitement — sans cela, les BPDU sont simplement rejetés au port, donc aucun port bloquant n'est jamais calculé, même si STP semble activé globalement.
SOLUTIONExécutez display stp interface sur chaque port de l'anneau — si tous les ports montrent Designated Port et qu'aucun ne montre Alternate ou Root, la négociation STP n'a jamais réellement eu lieu. Configurez bpdu enable sur les ports devant recevoir et traiter les trames STP.
SYMPTÔMECertains ordinateurs portables n'obtiennent pas d'adresse IP spécifiquement lors d'un démarrage depuis une carte réseau (démarrage type PXE), alors que d'autres appareils sur le même commutateur n'ont aucun problème.
CAUSEUne carte réseau effectuant un démarrage réseau fait brièvement osciller le lien au démarrage. Si le port du commutateur faisant face à ce terminal n'est pas configuré comme port edge STP, cette oscillation déclenche un recalcul complet de la topologie STP — environ 30 secondes pendant lesquelles le port ne transmet pas. Le terminal n'envoie que quatre tentatives de découverte DHCP dans cette fenêtre, n'obtient aucune réponse à aucune d'elles, et abandonne simplement.
SOLUTIONConfigurez stp edged-port enable sur chaque port connecté à un terminal final plutôt qu'à un autre commutateur. Les versions de plateforme plus récentes peuvent auto-détecter les ports faisant face aux terminaux et régler cela automatiquement, mais cela vaut la peine de le confirmer plutôt que de le supposer.
SYMPTÔMEPlusieurs instances STP sont configurées délibérément pour qu'un port donné puisse transmettre dans une instance VLAN et bloquer dans une autre, mais chaque instance converge identiquement à l'instance 0, quelles que soient les valeurs de coût par instance définies.
CAUSEDeux commutateurs MSTP ne partagent une région — et ne peuvent donc faire tourner leurs instances indépendamment — que lorsque le nom de région, le mappage instance-VLAN, le sélecteur de format et le niveau de révision correspondent tous exactement. Si le nom de région seul diffère, les commutateurs reviennent à calculer chaque instance de la même manière que l'instance 0, annulant silencieusement tout l'intérêt de configurer des instances séparées.
SOLUTIONComparez display stp region-configuration sur les deux commutateurs — le nom de région d'abord. Alignez le nom de région, puis reconfirmez que les valeurs de coût par instance prennent réellement effet indépendamment.
SYMPTÔMEAprès qu'un lien sur l'anneau RRPP tombe en panne puis se rétablit, les tables MAC et ARP des nœuds de transit ne se rafraîchissent pas, et le trafic reste cassé même si l'anneau physique est à nouveau sain.
CAUSERRPP a deux modes de fonctionnement — le mode propriétaire Huawei par défaut et le mode GB (norme nationale) — et chaque nœud du même anneau doit utiliser le même. Si le nœud maître est réglé en mode GB tandis que les nœuds de transit restent sur le défaut, les paquets de notification common/complete du maître ne sont tout simplement pas traités par les nœuds de transit, donc leurs tables MAC et ARP ne reçoivent jamais l'information que la topologie a changé.
SOLUTIONVérifiez display rrpp verbose domain sur le nœud maître pour confirmer son mode de fonctionnement, puis vérifiez la même chose sur chaque nœud de transit — alignez-les tous sur un mode, quel qu'il soit, de façon cohérente sur tout l'anneau.
La panne ressemblait à un problème de routage. La cause réelle était un VLAN que personne n'avait pensé à vérifier.
Le montage : un commutateur avec deux liens montants vers des routeurs, et des appareils de couche accès pendus en aval. Le symptôme : les deux liens montants sont devenus totalement inactifs pour l'activité, un redémarrage a rétabli le service un moment, puis la même panne exacte est revenue.
La piste des journaux pointait d'abord vers OSPF, pas du tout vers la couche 2 — la relation de voisinage montante n'arrêtait pas de tomber, apparemment sans raison :
NBR_CHG_DOWN(l): Neighbor event:neighbor state changed to Down. (ProcessId=88,
NeighborAddress=x.x.x.x, NeighborEvent=KillNbr, NeighborPreviousState=Loading,
NeighborCurrentState=Down)
NBR_DOWN_REASON(l): Neighbor state leaves full or changed to Down. (ProcessId=88,
NeighborRouterId=x.x.x.x, NeighborAreaId=0, NeighborInterface=Vlanif4, NeighborDownImmediate
reason=Neighbor Down Due to Kill Neighbor, NeighborDownPrimeReason=Physical Interface State Change)Les journaux de diagnostic ont raconté la vraie histoire : les ports montants GE1/0/0 et GE1/0/1 montraient tous deux un trafic sortant anormal, tandis que les ports en aval GE1/0/3 et GE1/0/4 montraient tous deux un trafic entrant anormal en même temps — les quatre coincés juste au plafond de débit du port :
Interface GigabitEthernet1/0/0's flow is abnormal. (Speed=1000Mbps, CurrentInSpeed=0Mbps,
CurrentOutSpeed=849Mbps, File=IFPDT_FUNC_C, Line=13072)
Interface GigabitEthernet1/0/3's flow is abnormal. (Speed=1000Mbps, CurrentInSpeed=847Mbps,
CurrentOutSpeed=846Mbps, File=IFPDT_FUNC_C, Line=13072)
Interface GigabitEthernet1/0/4's flow is abnormal. (Speed=1000Mbps, CurrentInSpeed=849Mbps,
CurrentOutSpeed=849Mbps, File=IFPDT_FUNC_C, Line=13072)Comparer la configuration de chaque port signalé n'a révélé qu'une seule chose en commun : le VLAN 1. Le trafic entrant sur GE1/0/3 et GE1/0/4 à l'intérieur du VLAN 1 était rediffusé directement vers les autres ports signalés, y compris les deux liens montants — les inondant jusqu'à ce que les paquets hello OSPF eux-mêmes soient rejetés, ce qui a réellement fait tomber la relation de voisinage. Retirer GE1/0/3 et GE1/0/4 du VLAN 1 a résolu la panne immédiatement, sans autre changement nécessaire.
Le point généralisable : une boucle VLAN 1 est assez courante pour qu'il vaille la peine de la vérifier en premier, spécifiquement, chaque fois que le trafic de plusieurs ports sans lien apparent semble anormal — comparez leurs configurations à la recherche d'un VLAN partagé avant de supposer que la panne se situe ailleurs, plus exotique.
Une fois l'incendie immédiat éteint, ces cinq vérifications sont ce qui prévient réellement le prochain.
Cette note s'appuie sur le propre manuel de maintenance des commutateurs Huawei — les étapes de diagnostic, les cas de mauvaise configuration et les recommandations de renforcement proviennent tous de cette référence. Elle ne couvre pas en profondeur le comportement des sous-anneaux ERPS, les spécificités de Smart Link, ni les scénarios de boucle causés par un équipement tiers renvoyant des trames qu'il ne peut pas traiter autrement — chacun mériterait un examen séparé.
Les questions qui reviennent chaque fois qu'une boucle suspectée est réellement sur la table.
L'oscillation d'adresse MAC est le signe révélateur : une vraie boucle produit toujours la même adresse MAC rebondissant entre deux ports précis du même VLAN, parce que le commutateur continue de la réapprendre depuis les deux directions. Un seul appareil défaillant ou compromis générant un trafic broadcast lourd ne produit généralement pas cette signature d'oscillation bilatérale particulière entre deux ports — cela se manifeste par un trafic élevé sans le motif de dérive MAC correspondant.
Pas à lui seul. Une part PPI élevée et soutenue est un indicateur fort, mais bien d'autres conditions peuvent aussi faire grimper l'utilisation CPU. Vérifiez de façon croisée avec le trafic d'interface et l'oscillation MAC, ou déployez la détection de boucle pour une réponse directe, avant de traiter un CPU élevé comme une preuve en soi.
Le shutdown est presque toujours le meilleur choix — il est instantanément réversible avec undo shutdown et ne risque pas d'endommager un connecteur ou une extrémité de fibre. Débrancher physiquement un câble est un dernier recours réservé au cas où l'appareil lui-même ne peut plus être joint à distance pour émettre la commande shutdown.
Oui, potentiellement — retirer le VLAN par défaut d'un port Access en particulier peut affecter l'appareil ou l'utilisateur en aval réellement connecté dessus, donc confirmez ce qui se trouve derrière un port avant d'y toucher. Retirer un ID de VLAN spécifique d'un port Trunk ou Hybrid a généralement un impact plus restreint, puisque les autres VLAN sur ce même port continuent de transmettre normalement.
Les protocoles de rupture de boucle (STP/RSTP/MSTP, RRPP, SEP, ERPS) sont la véritable défense et devraient être choisis délibérément pour correspondre à la conception du réseau — faire tourner RRPP et MSTP ensemble sur les mêmes ports n'est pas recommandé. Loop Detection et Loopback Detection sont des outils de diagnostic supplémentaires qui consomment des ressources système en plus ; le manuel recommande spécifiquement de les désactiver à nouveau une fois la vérification de déploiement terminée, plutôt que de les laisser tourner en permanence partout.
Envoyez-nous votre sortie display interface brief et un croquis approximatif de la topologie — nous vous aiderons à trouver la boucle et à la casser en toute sécurité.