Início / Notas técnicas / Solução de problemas de M-LAG

Falhas de M-LAG: split-brain, falhas de sincronização e os casos que as causam

Dois equipamentos agindo como um só valem tanto quanto o heartbeat e a sincronização entre eles. Esta é a ordem de diagnóstico para falhas de M-LAG — estado do pareamento DFS e do peer-link, por que o tráfego do lado de acesso dá voltas pelo peer-link, por que um peer-link sobrecarregado causa perda de pacotes durante a comutação, por que a eleição ativo-standby nunca se completa, e o caso de sincronização da tabela de DHCP Snooping que só aparece depois que o dispositivo primário falha.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

Por que dois equipamentos agindo como um só sempre falham da mesma forma

O M-LAG faz dois switches parecerem um único peer Eth-Trunk para tudo que está a jusante — o que significa que a falha raramente está de fato no equipamento a jusante.

O M-LAG existe para permitir que um servidor ou um switch a montante faça dual-homing em dois chassis independentes sem rodar Spanning Tree, tratando os dois membros como se fossem portas de um único equipamento lógico. É exatamente essa ilusão que torna as falhas de M-LAG confusas: um equipamento pode mostrar sua interface M-LAG como Up enquanto os dois chassis derivaram silenciosamente para fora de sincronia na configuração do gateway, ou o peer-link pode estar carregando todo o tráfego que uma porta de acesso com falha deveria ter descartado, esgotando silenciosamente sua própria largura de banda. A forma mais rápida de resolver isso é verificar primeiro o pareamento e o estado do peer-link, e então relacionar o sintoma ao caso específico que ele mais se parece, em vez de presumir de antemão que o equipamento a jusante é o culpado.

A seguir: uma topologia M-LAG para localizar a falha, a ordem para verificar o pareamento DFS e o estado do peer-link antes de mexer em qualquer outra coisa, o caso de MAC de gateway do lado de acesso que faz o tráfego dar voltas pelo peer-link, o caso de esgotamento de largura de banda do peer-link que aparece durante a comutação, o caso de proxy L2 de ARP ausente que bloqueia a eleição ativo-standby, a falha de sincronização da tabela de DHCP Snooping que só aparece depois que o dispositivo primário falha, cinco causas-raiz recorrentes, e respostas de perguntas frequentes testadas em campo.

Veja o pareamento antes de ler um único contador de interface

DFS-Group, peer-link, papéis Master e Backup, portas membro pareadas uma a uma entre os dois chassis — tudo a jusante vê apenas um único switch lógico.

Cada caso abaixo assume esta forma: dois switches CloudEngine no mesmo DFS-Group, unidos por um peer-link dedicado (tipicamente um Eth-Trunk próprio), cada um mantendo metade de cada Eth-Trunk membro de M-LAG voltado para um servidor com dual-homing ou uma rede a montante, com um heartbeat rodando sobre o peer-link para detectar se o outro chassi está realmente vivo.

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Esses mesmos pares Device A/Device B são exatamente os pares de Server Leaf que fazem dual-homing dos hosts em um fabric VXLAN — veja nossa nota de solução de problemas do overlay VXLAN para o que acontece uma camada acima desta. O recurso consistency-check é o que impede que a configuração dos dois chassis derive silenciosamente; quase todos os casos abaixo remontam ao peer-link, ao heartbeat, ou a um item de configuração que o consistency-check detectou ou deixou passar.

Percorrendo a verificação de estado e depois o caso específico

Quatro investigações diferentes, quatro conjuntos de comandos diferentes — e a disciplina de confirmar primeiro o próprio pareamento antes de presumir qual delas se aplica.

Confirmar primeiro o pareamento DFS e o estado do peer-link

O campo Causation em display dfs-group m-lag brief informa diretamente por que uma porta membro não está no estado esperado — leia isso antes de mexer no equipamento a jusante.

Verifique display dfs-group m-lag brief nos dois chassis. Se Causation não for um traço, ele está nomeando o motivo exato pelo qual o membro M-LAG não está totalmente up — não é um espaço reservado para ignorar.
Verifique display dfs-group peer-link para confirmar que a interface do peer-link em si, e o heartbeat que ela carrega, estão ambos Up.
Verifique display error-down recovery — uma porta membro M-LAG que entrou em Error-Down e não se recuperou parece idêntica a uma falha de cabo do lado do equipamento a jusante.
Verifique display eth-trunk para o Eth-Trunk membro de M-LAG nos dois chassis para confirmar que as mesmas portas membro estão realmente Up em cada lado, não apenas configuradas.

<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

Caso: uma MAC de gateway do lado de acesso divergente faz o tráfego dar voltas pelo peer-link

Ambos os chassis mostram a interface M-LAG como Up — a divergência está uma camada mais profunda, na própria configuração do gateway.

Sintoma: o tráfego encaminhado através de uma interface M-LAG se comporta de forma anormal — perda intermitente, ou tráfego que parece dar voltas entre os dois chassis pelo peer-link.
Causa raiz: a configuração do gateway do lado de acesso (por exemplo, o endereço MAC da interface VBDIF ou VLANIF) difere entre o Device A e o Device B, então o tráfego de retorno é encaminhado através do peer-link em vez de sair pela porta membro local correta.
Habilite o consistency-check em modo estrito para que uma divergência de configuração real gere um alarme em vez de encaminhar incorretamente em silêncio, e então compare lado a lado a configuração da interface sinalizada nos dois chassis.
Correção: torne a configuração do gateway idêntica nos dois chassis — mesma MAC, mesma vinculação VLAN/BD — e depois confirme que o alarme de consistency-check desaparece.

[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

Caso: um peer-link sobrecarregado causa perda de pacotes persistente durante a comutação

O peer-link não serve apenas para tráfego de heartbeat e sincronização — durante uma falha de porta membro, ele também carrega todos os pacotes que de outra forma sairiam pela porta local com falha.

Sintoma: depois que uma interface membro de M-LAG falha, o tráfego pelo fabric mostra perda de pacotes contínua em vez de um impacto breve e pontual.
Causa raiz: quando uma porta membro M-LAG local está caída, sua parcela do tráfego precisa atravessar o peer-link para chegar ao membro sobrevivente no outro chassi; se a própria largura de banda do peer-link foi dimensionada apenas para tráfego de heartbeat e sincronização de tabelas, ela não consegue absorver essa carga extra.
Verifique display interface para o Eth-Trunk do peer-link e compare a taxa de tráfego com sua largura de banda configurada durante a janela de falha.
Correção: dimensione o peer-link para a carga de comutação no pior caso, não apenas para o tráfego de sincronização em estado estável — adicione links membro ao Eth-Trunk do peer-link, ou mova parte do tráfego membro de M-LAG para reduzir o que uma única falha empurraria por ele.

<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

Caso: a tabela de vinculação do DHCP Snooping não sincroniza entre o par M-LAG

Este caso é invisível até que o dispositivo primário que construiu a tabela de vinculação realmente falhe — então o DHCP Snooping do backup simplesmente não protege nada.

Sintoma: o Device A e o Device B formam um par M-LAG com DHCP Snooping habilitado; o Device A gera a tabela de vinculação do Snooping à medida que os clientes ficam online, mas o Device B não constrói uma tabela correspondente própria.
Consequência: se o Device A então falhar, o Device B assume o encaminhamento, mas seu DHCP Snooping não tem entradas de vinculação — a proteção antifalsificação para de funcionar silenciosamente exatamente quando a rede mais precisa dela.
Verifique display dhcp configuration e display dhcp snooping configuration nos dois chassis, incluindo em portas que não são membros de M-LAG — uma única configuração relacionada a DHCP diferente já é suficiente para quebrar a sincronização.
Verifique display dfs-group m-lag brief em busca de um valor de Causation diferente de traço, e verifique display clock nos dois chassis — configuração inconsistente ou relógios não sincronizados entre os dois nós M-LAG são as duas razões mais comuns para a tabela de vinculação não replicar.
Correção: torne a configuração relacionada ao DHCP Snooping idêntica em cada porta dos dois chassis, incluindo portas que não são de M-LAG, e sincronize os relógios entre os dois nós (por exemplo, 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 causas-raiz que aparecem repetidamente

Depois que as verificações acima indicarem qual das quatro investigações se aplica, essas cinco respondem pela maior parte do que realmente está errado.

1. Uma porta membro fica em Error-Down sem temporizador de recuperação

SINTOMAUma interface membro M-LAG permanece down em um chassi enquanto o chassi par mostra seu próprio lado como up, e a porta nunca volta sozinha.

CAUSAA porta foi colocada em Error-Down (comumente pelo m-lag-mad, o mecanismo de detecção multi-ativo) e nenhum tempo de recuperação automática foi configurado para esse motivo de error-down, então a porta espera indefinidamente por intervenção manual.

CORREÇÃOVerifique display error-down recovery para o motivo e o tempo de recuperação restante; configure um intervalo de recuperação automática para esse motivo, ou restaure manualmente a interface após confirmar que a causa subjacente foi resolvida.

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

2. A configuração do gateway do lado de acesso difere entre os dois chassis

SINTOMAO tráfego através de uma interface M-LAG é intermitente, ou parece dar voltas entre os dois chassis pelo peer-link.

CAUSAO endereço MAC da interface de gateway (ou outra configuração de gateway) é diferente no Device A e no Device B, então o tráfego de retorno endereçado ao gateway é encaminhado através do peer-link em vez de sair diretamente pela porta local correta.

CORREÇÃOHabilite o consistency-check em modo estrito para que esse tipo de divergência gere um alarme, compare lado a lado o item de configuração sinalizado, e depois torne-o idêntico nos dois chassis.

3. A largura de banda do peer-link não foi dimensionada para a carga de comutação

SINTOMADepois que uma interface membro de M-LAG falha, a perda de pacotes pelo fabric continua em vez de se recuperar após uma comutação breve.

CAUSAA parcela de tráfego da porta com falha agora precisa atravessar o peer-link para chegar ao membro sobrevivente no outro chassi; um peer-link dimensionado apenas para tráfego de heartbeat e sincronização de tabelas satura sob essa carga extra.

CORREÇÃOVerifique display interface para a utilização do peer-link durante a janela de falha, e depois adicione links membro ao Eth-Trunk do peer-link ou reequilibre o tráfego para que a falha de uma única porta não o sobrecarregue.

4. A eleição ativo-standby nunca se completa sem ARP L2-Proxy

SINTOMAUma interface M-LAG configurada para seleção de membro ativo-standby (em vez de ativo-ativo) nunca se estabiliza em uma única porta ativa — ambos os lados se comportam como se estivessem encaminhando.

CAUSAA eleição ativo-standby depende de os pacotes ARP, ND, IGMP, DHCP ou MLD serem visíveis nos dois chassis para decidir qual porta membro deve estar ativa; sem arp l2-proxy enable, os pacotes relevantes para a eleição não chegam ao chassi par e os dois lados nunca chegam a um acordo.

CORREÇÃOHabilite arp l2-proxy na interface M-LAG para que os pacotes relevantes para a eleição fiquem visíveis para os dois chassis, e depois confirme que uma única porta membro ativa é eleita.

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

5. A tabela de vinculação do DHCP Snooping não sincroniza entre o par M-LAG

SINTOMAO DHCP Snooping está habilitado em ambos os chassis M-LAG, mas apenas o dispositivo que realmente processou a troca DHCP do cliente constrói uma entrada de vinculação — a tabela do chassi par permanece vazia para esse cliente.

CAUSAA sincronização da tabela de vinculação entre os dois nós M-LAG depende de configuração relacionada a DHCP idêntica em cada porta dos dois chassis (incluindo portas que não são de M-LAG) e de os relógios dos dois chassis estarem sincronizados; qualquer uma dessas divergências é suficiente para quebrar silenciosamente a sincronização.

CORREÇÃOCompare display dhcp snooping configuration porta por porta nos dois chassis, verifique display clock em busca de desvio, e alinhe ambos antes de presumir que o recurso em si está quebrado.

Cinco perguntas para as quais vale a pena ter uma resposta pronta

Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.

Como faço para impedir que portas específicas no chassi backup entrem em Error-Down toda vez que o peer-link falha?

Por padrão, quando o peer-link cai, o chassi backup coloca suas portas membro M-LAG em Error-Down para evitar uma condição de duplo-ativo — que é o comportamento padrão seguro, mas pode ser mais agressivo do que uma determinada implantação deseja. O m-lag unpaired-port suspend permite designar portas específicas que devem permanecer up e continuar encaminhando mesmo sem um peer-link pareado, para casos em que um breve risco de encaminhamento duplicado é preferível a uma interrupção total nessas portas.

Um alarme de divergência de consistency-check realmente afeta o tráfego, ou é apenas um aviso?

Depende de qual tipo a acionou. Uma inconsistência de Tipo 1 cobre configuração que afeta a correção do encaminhamento (como o caso de MAC de gateway acima) — se não resolvida, pode causar problemas reais de tráfego, e reiniciar o dispositivo primário do M-LAG enquanto uma divergência de Tipo 1 está pendente pode desencadear um evento de duplo-ativo. Uma inconsistência de Tipo 2 cobre configuração que não afeta diretamente o encaminhamento; vale a pena corrigi-la por uma questão de consistência, mas ela por si só não quebrará o tráfego. Verifique qual tipo acionou o alarme antes de decidir com que urgência agir.

display dfs-group m-lag mostra um valor de Causation que não é um traço — o que devo verificar primeiro?

Leia primeiro o próprio texto de Causation antes de verificar qualquer outra coisa — ele nomeia diretamente o motivo (falha de peer-link, pareamento DFS ainda não concluído, um dispositivo recém-reiniciado ainda sincronizando, ou uma inconsistência de configuração impedindo o membro de subir totalmente). Relacione esse motivo com display dfs-group peer-link e display m-lag consistency-check inconsistent-configuration em vez de adivinhar sobre o cabeamento a jusante.

O peer-link acabou de cair, mas o heartbeat parecia bem até então — o que acontece agora com minhas portas M-LAG?

Assim que o próprio peer-link é confirmado como caído, o chassi backup presume que pode não ser mais seguro continuar encaminhando de forma independente e, por padrão, coloca suas portas membro M-LAG em Error-Down, para evitar que os dois chassis encaminhem ativamente o mesmo tráfego sem forma de coordenação. Qualquer porta explicitamente excluída com m-lag unpaired-port suspend é a exceção. É por isso que a redundância do peer-link (um trunk com mais de um membro físico) importa tanto quanto sua largura de banda.

Encontramos uma divergência de consistency-check de Tipo 1 e estou prestes a reiniciar o dispositivo primário do M-LAG para forçar uma ressincronização — isso é seguro?

Ainda não. Reiniciar o primário enquanto uma divergência de Tipo 1 ainda está pendente é exatamente o cenário que pode desencadear um evento de duplo-ativo (split-brain), porque o backup pode subir acreditando que deve assumir o encaminhamento ativo enquanto o primário também ainda está tentando. Resolva primeiro a divergência de configuração sinalizada, confirme que display m-lag consistency-check inconsistent-configuration volta limpo, e só então planeje o reinício.

Limites honestos desta nota

Limites honestos desta nota

Esta nota se baseia no modelo M-LAG baseado em DFS-Group do manual de manutenção V300 das séries Huawei CloudEngine 16800/9800/8800/6800 — display dfs-group m-lag / peer-link, error-down recovery, consistency-check, além dos casos de campo por trás deles, incluindo o caso de sincronização da tabela de vinculação do DHCP Snooping. Se a sua plataforma usa uma implementação diferente de MC-LAG ou vPC, os comandos exatos mudam, mas a ordem de diagnóstico — estado do pareamento, saúde do peer-link, e então o sintoma específico de tráfego ou sincronização — se aplica diretamente. Não cobre em profundidade as interações de gateway duplo-ativo de VXLAN sobre M-LAG; veja nossa nota de solução de problemas do overlay VXLAN para a camada acima desta.

Travado em um par M-LAG específico?

Conte-nos o que display dfs-group m-lag brief e display m-lag consistency-check inconsistent-configuration mostram, e a qual desses casos isso corresponde, e ajudamos você a interpretar.

WhatsApp com um engenheiro →