Accueil / Notes techniques / Dépannage M-LAG

Pannes M-LAG : split-brain, échecs de synchronisation et les cas qui les provoquent

Deux équipements agissant comme un seul ne valent que ce que valent le heartbeat et la synchronisation entre eux. Voici l'ordre de diagnostic pour les pannes M-LAG — état du pairage DFS et du peer-link, pourquoi le trafic côté accès boucle via le peer-link, pourquoi un peer-link surchargé cause une perte de paquets pendant le basculement, pourquoi l'élection active-standby n'aboutit jamais, et le cas de synchronisation de la table DHCP Snooping qui n'apparaît qu'après la panne du dispositif primaire.

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

Pourquoi deux équipements se faisant passer pour un seul tombent en panne toujours de la même façon

M-LAG fait apparaître deux commutateurs comme un seul pair Eth-Trunk pour tout ce qui est en aval — ce qui signifie que la panne se situe rarement dans l'aval lui-même.

M-LAG existe pour permettre à un serveur ou à un commutateur en amont de se rattacher en double sur deux châssis indépendants sans faire tourner Spanning Tree, en traitant les deux membres comme s'il s'agissait de ports d'un seul équipement logique. C'est précisément cette illusion qui rend les pannes M-LAG déroutantes : un équipement peut afficher son interface M-LAG comme Up alors que les deux châssis ont discrètement dérivé hors synchronisation sur la configuration de la passerelle, ou le peer-link peut être en train de porter tout le trafic qu'un port d'accès en panne aurait dû laisser tomber, épuisant silencieusement sa propre bande passante. La façon la plus rapide de s'en sortir est de vérifier d'abord le pairage et l'état du peer-link, puis de faire correspondre le symptôme au cas précis qu'il évoque, plutôt que de présumer d'emblée que l'équipement en aval est en cause.

Voici la suite : une topologie M-LAG pour situer la panne, l'ordre pour vérifier le pairage DFS et l'état du peer-link avant de toucher à quoi que ce soit d'autre, le cas de MAC de passerelle côté accès qui fait boucler le trafic via le peer-link, le cas d'épuisement de bande passante du peer-link qui apparaît pendant le basculement, le cas de proxy L2 ARP manquant qui bloque l'élection active-standby, l'échec de synchronisation de la table DHCP Snooping qui n'apparaît qu'après la panne du dispositif primaire, cinq causes racines récurrentes, et des réponses de FAQ éprouvées sur le terrain.

Voyez le pairage avant de lire le moindre compteur d'interface

DFS-Group, peer-link, rôles Master et Backup, ports membres appairés un à un entre les deux châssis — tout ce qui est en aval ne voit qu'un seul commutateur logique.

Chaque cas ci-dessous suppose cette forme : deux commutateurs CloudEngine dans le même DFS-Group, reliés par un peer-link dédié (généralement son propre Eth-Trunk), chacun détenant la moitié de chaque Eth-Trunk membre M-LAG faisant face à un serveur à double rattachement ou à un réseau en amont, avec un heartbeat circulant sur le peer-link pour détecter si l'autre châssis est réellement vivant.

Les légendes du schéma restent en anglais pour la clarté technique.

Ces mêmes paires Device A/Device B sont exactement les paires de Server Leaf qui rattachent en double les hôtes dans un fabric VXLAN — voyez notre note de dépannage de l'overlay VXLAN pour ce qui se passe une couche au-dessus de celle-ci. La fonction consistency-check est ce qui empêche la configuration des deux châssis de dériver silencieusement l'une de l'autre ; presque chaque cas ci-dessous remonte soit au peer-link, soit au heartbeat, soit à un élément de configuration que consistency-check a détecté ou manqué.

Vérifier l'état, puis traiter le cas précis

Quatre investigations différentes, quatre jeux de commandes différents — et la discipline de confirmer d'abord le pairage lui-même avant de présumer laquelle s'applique.

Confirmer d'abord le pairage DFS et l'état du peer-link

Le champ Causation dans display dfs-group m-lag brief indique directement pourquoi un port membre n'est pas dans l'état attendu — à lire avant de toucher à l'équipement en aval.

Vérifiez display dfs-group m-lag brief sur les deux châssis. Si Causation n'est pas un tiret, cela nomme la raison exacte pour laquelle le membre M-LAG n'est pas entièrement up — pas un espace réservé à ignorer.
Vérifiez display dfs-group peer-link pour confirmer que l'interface de peer-link elle-même, et le heartbeat qu'elle transporte, sont tous deux Up.
Vérifiez display error-down recovery — un port membre M-LAG passé en Error-Down et non rétabli ressemble exactement à une panne de câble vue du côté de l'équipement en aval.
Vérifiez display eth-trunk pour l'Eth-Trunk membre M-LAG sur les deux châssis afin de confirmer que les mêmes ports membres sont réellement Up de chaque côté, pas seulement configurés.

<DeviceA> display dfs-group m-lag brief
 M-LAG ID  Interface        Local-State  Peer-State  Causation
 1         Eth-Trunk10      up           up          -
 2         Eth-Trunk20      down         up          Peer-link fault
// Causation names the reason directly -- not a placeholder

<DeviceA> display dfs-group peer-link
 Peer-link interface : Eth-Trunk1
 State                : up
 Heartbeat            : up

<DeviceA> display error-down recovery
 Interface        Error-down reason     Recovery time left
 GigabitEthernet0/0/3  m-lag-mad          disabled
// port stuck in error-down with no recovery timer set -- will not come back on its own

Cas : une MAC de passerelle côté accès non concordante fait boucler le trafic via le peer-link

Les deux châssis affichent l'interface M-LAG comme Up — la discordance se situe une couche plus profonde, dans la configuration de la passerelle elle-même.

Symptôme : le trafic transféré via une interface M-LAG se comporte anormalement — perte intermittente, ou trafic qui semble boucler entre les deux châssis via le peer-link.
Cause racine : la configuration de la passerelle côté accès (par exemple l'adresse MAC de l'interface VBDIF ou VLANIF) diffère entre Device A et Device B, si bien que le trafic retour est transféré via le peer-link au lieu de sortir par le bon port membre local.
Activez consistency-check en mode strict pour qu'une véritable discordance de configuration déclenche une alarme au lieu de transférer silencieusement de façon incorrecte, puis comparez côte à côte la configuration de l'interface signalée sur les deux châssis.
Correctif : rendez la configuration de la passerelle identique sur les deux châssis — même MAC, même liaison VLAN/BD — puis confirmez que l'alarme consistency-check disparaît.

[DeviceA] m-lag consistency-check port-mode strict
[DeviceA] m-lag consistency-check type1 vlanif

<DeviceA> display m-lag consistency-check inconsistent-configuration
 Interface   Config Item        DeviceA           DeviceB
 Vlanif100   MAC address        5489-98aa-0001    5489-98aa-0002
// gateway MAC differs between the two chassis -- return traffic loops via peer-link

[DeviceB] interface vlanif 100
[DeviceB-Vlanif100] mac-address 5489-98aa-0001
// align the gateway MAC on both chassis

Cas : un peer-link surchargé cause une perte de paquets persistante pendant le basculement

Le peer-link ne sert pas seulement au heartbeat et au trafic de synchronisation — lors d'une panne de port membre, il transporte aussi tous les paquets qui seraient autrement sortis par le port local en panne.

Symptôme : après la panne d'une interface membre M-LAG, le trafic à travers le fabric montre une perte de paquets continue plutôt qu'un impact bref et ponctuel.
Cause racine : lorsqu'un port membre M-LAG local est en panne, sa part de trafic doit traverser le peer-link pour atteindre le membre survivant sur l'autre châssis ; si la propre bande passante du peer-link n'a été dimensionnée que pour le heartbeat et le trafic de synchronisation de table, elle ne peut pas absorber cette charge supplémentaire.
Vérifiez display interface pour l'Eth-Trunk du peer-link et comparez le débit de trafic à sa bande passante configurée pendant la fenêtre de panne.
Correctif : dimensionnez le peer-link pour la charge de basculement dans le pire des cas, pas seulement pour le trafic de synchronisation en régime établi — ajoutez des liens membres à l'Eth-Trunk du peer-link, ou déplacez une partie du trafic membre M-LAG pour réduire ce qu'une panne unique y pousserait.

<DeviceA> display interface Eth-Trunk1
Eth-Trunk1 current state : UP
 Last 300 seconds input rate  9.8 Gbps, output rate 9.9 Gbps
 Bandwidth utilization      : 98%
// peer-link near saturation during the failover window -- undersized for this load

[DeviceA] interface eth-trunk 1
[DeviceA-Eth-Trunk1] trunkport GigabitEthernet0/0/23
// add another member link to the peer-link trunk to absorb failover traffic

Cas : la table de liaison DHCP Snooping ne se synchronise pas entre la paire M-LAG

Ce cas est invisible tant que le dispositif primaire ayant construit la table de liaison n'est pas réellement en panne — le DHCP Snooping du backup ne protège alors tout simplement plus rien.

Symptôme : Device A et Device B forment une paire M-LAG avec DHCP Snooping activé ; Device A génère la table de liaison Snooping au fur et à mesure que les clients se connectent, mais Device B ne construit pas de table correspondante de son côté.
Conséquence : si Device A tombe alors en panne, Device B prend le relais du transfert mais son DHCP Snooping n'a aucune entrée de liaison — la protection anti-usurpation cesse silencieusement de fonctionner exactement au moment où le réseau en a le plus besoin.
Vérifiez display dhcp configuration et display dhcp snooping configuration sur les deux châssis, y compris sur les ports qui ne sont pas membres M-LAG — un seul paramètre lié au DHCP qui diffère suffit à rompre la synchronisation.
Vérifiez display dfs-group m-lag brief pour une valeur Causation autre qu'un tiret, et vérifiez display clock sur les deux châssis — une configuration incohérente ou des horloges non synchronisées entre les deux nœuds M-LAG sont les deux raisons les plus courantes pour lesquelles la table de liaison ne se réplique pas.
Correctif : rendez la configuration liée au DHCP Snooping identique sur chaque port des deux châssis, y compris les ports non membres M-LAG, et synchronisez les horloges entre les deux nœuds (par exemple via NTP).

<DeviceA> display dhcp snooping configuration
 DHCP snooping is enabled globally
 GigabitEthernet0/0/1 : trusted
<DeviceB> display dhcp snooping configuration
 DHCP snooping is enabled globally
 GigabitEthernet0/0/1 : untrusted
// same physical role, different trust setting -- breaks binding-table sync

<DeviceA> display clock
2026-07-19 09:14:02
<DeviceB> display clock
2026-07-19 09:11:47
// clocks not synchronized -- configure NTP on both chassis

5 causes racines qui reviennent sans cesse

Une fois que les vérifications ci-dessus vous ont indiqué laquelle des quatre investigations s'applique, ces cinq causes expliquent l'essentiel des problèmes réels.

1. Un port membre reste en Error-Down sans minuteur de récupération

SYMPTÔMEUne interface membre M-LAG reste down sur un châssis alors que le châssis pair affiche son propre côté comme up, et le port ne revient jamais de lui-même.

CAUSELe port a été placé en Error-Down (généralement par m-lag-mad, le mécanisme de détection multi-actif) et aucun temps de récupération automatique n'a été configuré pour cette raison d'error-down, de sorte que le port attend indéfiniment une intervention manuelle.

CORRECTIFVérifiez display error-down recovery pour la raison et le temps de récupération restant ; configurez soit un intervalle de récupération automatique pour cette raison, soit restaurez manuellement l'interface une fois la cause sous-jacente confirmée résolue.

[DeviceA] error-down auto-recovery cause m-lag-mad interval 300

2. La configuration de la passerelle côté accès diffère entre les deux châssis

SYMPTÔMELe trafic via une interface M-LAG est intermittent, ou semble boucler entre les deux châssis via le peer-link.

CAUSEL'adresse MAC de l'interface de passerelle (ou une autre configuration de passerelle) diffère entre Device A et Device B, si bien que le trafic retour adressé à la passerelle est transféré via le peer-link au lieu de sortir directement par le bon port local.

CORRECTIFActivez consistency-check en mode strict pour que ce type de discordance déclenche une alarme, comparez côte à côte l'élément de configuration signalé, puis rendez-le identique sur les deux châssis.

3. La bande passante du peer-link n'a pas été dimensionnée pour la charge de basculement

SYMPTÔMEAprès la panne d'une interface membre M-LAG, la perte de paquets à travers le fabric persiste au lieu de se rétablir après un bref basculement.

CAUSELa part de trafic du port en panne doit désormais traverser le peer-link pour atteindre le membre survivant sur l'autre châssis ; un peer-link dimensionné uniquement pour le heartbeat et le trafic de synchronisation de table sature sous cette charge supplémentaire.

CORRECTIFVérifiez display interface pour l'utilisation du peer-link pendant la fenêtre de panne, puis ajoutez des liens membres à l'Eth-Trunk du peer-link ou rééquilibrez le trafic pour qu'une panne de port unique ne le surcharge pas.

4. L'élection active-standby n'aboutit jamais sans ARP L2-Proxy

SYMPTÔMEUne interface M-LAG configurée pour une sélection de membre active-standby (plutôt qu'active-active) ne se stabilise jamais sur un seul port actif — les deux côtés se comportent comme s'ils transféraient.

CAUSEL'élection active-standby repose sur la visibilité, sur les deux châssis, des paquets ARP, ND, IGMP, DHCP ou MLD pour décider quel port membre doit être actif ; sans arp l2-proxy enable, les paquets pertinents pour l'élection n'atteignent pas le châssis pair et les deux côtés ne s'accordent jamais.

CORRECTIFActivez arp l2-proxy sur l'interface M-LAG afin que les paquets pertinents pour l'élection soient visibles par les deux châssis, puis confirmez qu'un seul port membre actif est élu.

[DeviceA] interface eth-trunk 20
[DeviceA-Eth-Trunk20] arp l2-proxy enable

5. La table de liaison DHCP Snooping ne se synchronise pas entre la paire M-LAG

SYMPTÔMEDHCP Snooping est activé sur les deux châssis M-LAG, mais seul le dispositif ayant réellement traité l'échange DHCP du client construit une entrée de liaison — la table du châssis pair reste vide pour ce client.

CAUSELa synchronisation de la table de liaison entre les deux nœuds M-LAG dépend d'une configuration liée au DHCP identique sur chaque port des deux châssis (y compris les ports non membres M-LAG) et de la synchronisation des horloges des deux châssis ; l'une ou l'autre discordance suffit à rompre silencieusement la synchronisation.

CORRECTIFComparez display dhcp snooping configuration port par port sur les deux châssis, vérifiez display clock pour une dérive, et alignez les deux avant de présumer que la fonctionnalité elle-même est en panne.

Cinq questions auxquelles il vaut mieux avoir une réponse prête

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.

Comment empêcher des ports spécifiques sur le châssis backup de passer en Error-Down à chaque panne du peer-link ?

Par défaut, lorsque le peer-link tombe en panne, le châssis backup place ses ports membres M-LAG en Error-Down pour éviter une condition active-active — ce qui est le comportement par défaut sûr, mais qui peut être plus agressif que ce qu'un déploiement donné souhaite. m-lag unpaired-port suspend permet de désigner des ports spécifiques qui doivent rester up et continuer à transférer même sans peer-link apparié, pour les cas où un bref risque de transfert en double est préférable à une panne complète sur ces ports.

Une alarme de discordance consistency-check affecte-t-elle réellement le trafic, ou n'est-ce qu'un avertissement ?

Cela dépend du type qui l'a déclenchée. Une incohérence de Type 1 couvre une configuration qui affecte la correction du transfert (comme le cas de MAC de passerelle ci-dessus) — non résolue, elle peut causer de réels problèmes de trafic, et redémarrer le dispositif primaire M-LAG alors qu'une discordance de Type 1 est en suspens peut déclencher un événement actif-actif. Une incohérence de Type 2 couvre une configuration qui n'affecte pas directement le transfert ; elle vaut la peine d'être corrigée par souci de cohérence, mais elle ne cassera pas le trafic à elle seule. Vérifiez quel type a déclenché l'alarme avant de décider avec quelle urgence agir.

display dfs-group m-lag affiche une valeur Causation qui n'est pas un tiret — que dois-je vérifier en premier ?

Lisez d'abord le texte Causation lui-même avant de vérifier autre chose — il nomme directement la raison (panne de peer-link, pairage DFS pas encore terminé, dispositif tout juste redémarré encore en synchronisation, ou incohérence de configuration empêchant le membre de monter complètement). Faites correspondre cette raison à display dfs-group peer-link et display m-lag consistency-check inconsistent-configuration plutôt que de deviner sur le câblage en aval.

Le peer-link vient de tomber en panne, mais le heartbeat semblait encore bon juste avant — qu'arrive-t-il maintenant à mes ports M-LAG ?

Une fois le peer-link lui-même confirmé en panne, le châssis backup considère qu'il n'est peut-être plus sûr de continuer à transférer indépendamment et place par défaut ses ports membres M-LAG en Error-Down, afin d'éviter que les deux châssis transfèrent activement le même trafic sans moyen de se coordonner. Tout port explicitement exclu avec m-lag unpaired-port suspend fait exception. C'est pourquoi la redondance du peer-link (un trunk avec plus d'un membre physique) compte autant que sa bande passante.

Nous avons trouvé une discordance consistency-check de Type 1 et je m'apprête à redémarrer le dispositif primaire M-LAG pour forcer une resynchronisation — est-ce sûr ?

Pas encore. Redémarrer le primaire alors qu'une discordance de Type 1 est encore en suspens est exactement le scénario qui peut déclencher un événement actif-actif (split-brain), car le backup peut démarrer en croyant qu'il doit prendre le relais du transfert actif alors que le primaire essaie aussi encore de le faire. Résolvez d'abord la discordance de configuration signalée, confirmez que display m-lag consistency-check inconsistent-configuration revient propre, et ce n'est qu'alors qu'il faut planifier le redémarrage.

Limites honnêtes de cette note

Limites honnêtes de cette note

Cette note s'appuie sur le modèle M-LAG basé sur DFS-Group du manuel de maintenance V300 des séries Huawei CloudEngine 16800/9800/8800/6800 — display dfs-group m-lag / peer-link, error-down recovery, consistency-check, ainsi que sur les cas de terrain qui les sous-tendent, y compris le cas de synchronisation de la table de liaison DHCP Snooping. Si votre plateforme utilise une autre implémentation MC-LAG ou vPC, les commandes exactes changent, mais l'ordre de diagnostic — état du pairage, santé du peer-link, puis le symptôme de trafic ou de synchronisation spécifique — s'applique directement. Elle ne couvre pas en profondeur les interactions de passerelle active-active VXLAN-sur-M-LAG ; voyez notre note de dépannage de l'overlay VXLAN pour la couche au-dessus de celle-ci.

Bloqué sur une paire M-LAG en particulier ?

Dites-nous ce qu'affichent display dfs-group m-lag brief et display m-lag consistency-check inconsistent-configuration, ainsi que lequel de ces cas ça correspond, et nous vous aiderons à l'interpréter.

WhatsApp avec un ingénieur →