Inicio / Notas técnicas / Resolución de problemas de M-LAG

Fallas de M-LAG: split-brain, fallos de sincronización y los casos que los provocan

Dos equipos actuando como uno solo valen tanto como el heartbeat y la sincronización entre ellos. Este es el orden de diagnóstico para las fallas de M-LAG — estado del emparejamiento DFS y del peer-link, por qué el tráfico del lado de acceso da vueltas por el peer-link, por qué un peer-link sobrecargado causa pérdida de paquetes durante la conmutación, por qué la elección activo-standby nunca se completa, y el caso de sincronización de la tabla de DHCP Snooping que solo aparece después de que falla el dispositivo primario.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Por qué dos equipos actuando como uno solo siempre fallan de la misma manera

M-LAG hace que dos switches parezcan un único peer Eth-Trunk para todo lo que está aguas abajo — lo que significa que la falla rara vez está realmente en el equipo aguas abajo.

M-LAG existe para permitir que un servidor o un switch aguas arriba tenga doble homing en dos chasis independientes sin ejecutar Spanning Tree, tratando a los dos miembros como si fueran puertos de un único equipo lógico. Esa ilusión es precisamente lo que hace confusas las fallas de M-LAG: un equipo puede mostrar su interfaz M-LAG como Up mientras los dos chasis han derivado silenciosamente fuera de sincronía en la configuración del gateway, o el peer-link puede estar cargando todo el tráfico que un puerto de acceso caído debería haber descartado, agotando silenciosamente su propio ancho de banda. La forma más rápida de resolverlo es verificar primero el emparejamiento y el estado del peer-link, y luego hacer coincidir el síntoma con el caso concreto al que se parece, en lugar de asumir de entrada que el equipo aguas abajo es el culpable.

A continuación: una topología M-LAG para situar la falla, el orden para verificar el emparejamiento DFS y el estado del peer-link antes de tocar cualquier otra cosa, el caso de MAC de gateway del lado de acceso que hace que el tráfico dé vueltas por el peer-link, el caso de agotamiento de ancho de banda del peer-link que aparece durante la conmutación, el caso de proxy L2 de ARP faltante que bloquea la elección activo-standby, el fallo de sincronización de la tabla de DHCP Snooping que solo aparece después de que falla el dispositivo primario, cinco causas raíz recurrentes, y respuestas de preguntas frecuentes probadas en campo.

Vea el emparejamiento antes de leer un solo contador de interfaz

DFS-Group, peer-link, roles Master y Backup, puertos miembro emparejados uno a uno entre los dos chasis — todo lo que está aguas abajo solo ve un único switch lógico.

Cada caso a continuación asume esta forma: dos switches CloudEngine en el mismo DFS-Group, unidos por un peer-link dedicado (típicamente un Eth-Trunk propio), cada uno con la mitad de cada Eth-Trunk miembro de M-LAG que da hacia un servidor de doble homing o una red aguas arriba, con un heartbeat corriendo sobre el peer-link para detectar si el otro chasis realmente está vivo.

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Estos mismos pares Device A/Device B son exactamente los pares de Server Leaf que dan doble homing a los hosts en un fabric VXLAN — vea nuestra nota de resolución de problemas del overlay VXLAN para lo que ocurre una capa por encima de esta. La función consistency-check es lo que evita que la configuración de los dos chasis derive silenciosamente; casi cada caso a continuación se remonta al peer-link, al heartbeat, o a una pieza de configuración que consistency-check detectó o pasó por alto.

Recorriendo la verificación de estado y luego el caso concreto

Cuatro investigaciones distintas, cuatro conjuntos de comandos distintos — y la disciplina de confirmar primero el propio emparejamiento antes de asumir cuál aplica.

Confirmar primero el emparejamiento DFS y el estado del peer-link

El campo Causation en display dfs-group m-lag brief indica directamente por qué un puerto miembro no está en el estado esperado — léalo antes de tocar el equipo aguas abajo.

Verifique display dfs-group m-lag brief en ambos chasis. Si Causation no es un guion, está nombrando la razón exacta por la que el miembro M-LAG no está completamente up — no es un marcador de posición para ignorar.
Verifique display dfs-group peer-link para confirmar que la interfaz del peer-link en sí, y el heartbeat que transporta, están ambos Up.
Verifique display error-down recovery — un puerto miembro M-LAG que entró en Error-Down y no se ha recuperado se ve idéntico a una falla de cable desde el lado del equipo aguas abajo.
Verifique display eth-trunk para el Eth-Trunk miembro de M-LAG en ambos chasis para confirmar que los mismos puertos miembro están realmente Up en cada lado, no solo configurados.

<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: una MAC de gateway del lado de acceso no coincidente hace que el tráfico dé vueltas por el peer-link

Ambos chasis muestran la interfaz M-LAG como Up — la discrepancia está una capa más profunda, en la propia configuración del gateway.

Síntoma: el tráfico reenviado a través de una interfaz M-LAG se comporta de forma anormal — pérdida intermitente, o tráfico que parece dar vueltas entre los dos chasis a través del peer-link.
Causa raíz: la configuración del gateway del lado de acceso (por ejemplo, la dirección MAC de la interfaz VBDIF o VLANIF) difiere entre Device A y Device B, por lo que el tráfico de retorno se reenvía a través del peer-link en lugar de salir por el puerto miembro local correcto.
Habilite consistency-check en modo estricto para que una discrepancia de configuración real genere una alarma en lugar de reenviar incorrectamente en silencio, y luego compare lado a lado la configuración de la interfaz marcada en ambos chasis.
Solución: haga que la configuración del gateway sea idéntica en ambos chasis — misma MAC, misma vinculación VLAN/BD — y luego confirme que la alarma 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: un peer-link sobrecargado causa pérdida de paquetes persistente durante la conmutación

El peer-link no es solo para tráfico de heartbeat y sincronización — durante una falla de puerto miembro, también carga todos los paquetes que de otro modo habrían salido por el puerto local caído.

Síntoma: después de que falla una interfaz miembro de M-LAG, el tráfico a través del fabric muestra pérdida de paquetes continua en lugar de un impacto breve y puntual.
Causa raíz: cuando un puerto miembro M-LAG local está caído, su parte del tráfico tiene que cruzar el peer-link para llegar al miembro superviviente en el otro chasis; si el propio ancho de banda del peer-link se dimensionó solo para tráfico de heartbeat y sincronización de tablas, no puede absorber esa carga adicional.
Verifique display interface para el Eth-Trunk del peer-link y compare la tasa de tráfico con su ancho de banda configurado durante la ventana de falla.
Solución: dimensione el peer-link para la carga de conmutación en el peor caso, no solo para el tráfico de sincronización en estado estable — agregue enlaces miembro al Eth-Trunk del peer-link, o mueva parte del tráfico miembro de M-LAG para reducir lo que una sola falla empujaría a través de él.

<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: la tabla de enlace de DHCP Snooping no se sincroniza entre el par M-LAG

Este caso es invisible hasta que el dispositivo primario que construyó la tabla de enlace realmente falla — entonces el DHCP Snooping del backup simplemente no protege nada.

Síntoma: Device A y Device B forman un par M-LAG con DHCP Snooping habilitado; Device A genera la tabla de enlace de Snooping a medida que los clientes se conectan, pero Device B no construye una tabla propia correspondiente.
Consecuencia: si Device A falla entonces, Device B toma el relevo del reenvío pero su DHCP Snooping no tiene entradas de enlace — la protección anti-suplantación deja de funcionar silenciosamente justo cuando la red más la necesita.
Verifique display dhcp configuration y display dhcp snooping configuration en ambos chasis, incluyendo en puertos que no son miembros de M-LAG — un solo ajuste relacionado con DHCP que difiera basta para romper la sincronización.
Verifique display dfs-group m-lag brief en busca de un valor de Causation que no sea un guion, y verifique display clock en ambos chasis — una configuración inconsistente o relojes no sincronizados entre los dos nodos M-LAG son las dos razones más comunes por las que la tabla de enlace no se replica.
Solución: haga que la configuración relacionada con DHCP Snooping sea idéntica en cada puerto de ambos chasis, incluidos los puertos que no son de M-LAG, y sincronice los relojes entre los dos nodos (por ejemplo, vía 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 raíz que aparecen una y otra vez

Una vez que las comprobaciones anteriores le han indicado cuál de las cuatro investigaciones aplica, estas cinco explican la mayor parte de lo que realmente está mal.

1. Un puerto miembro queda en Error-Down sin temporizador de recuperación

SÍNTOMAUna interfaz miembro M-LAG permanece down en un chasis mientras el chasis par muestra su propio lado como up, y el puerto nunca vuelve por sí solo.

CAUSAEl puerto fue colocado en Error-Down (comúnmente por m-lag-mad, el mecanismo de detección multi-activo) y no se configuró un tiempo de recuperación automática para esa razón de error-down, por lo que el puerto espera indefinidamente una intervención manual.

SOLUCIÓNVerifique display error-down recovery para conocer la razón y el tiempo de recuperación restante; configure un intervalo de recuperación automática para esa razón, o restaure manualmente la interfaz una vez confirmado que la causa subyacente está resuelta.

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

2. La configuración del gateway del lado de acceso difiere entre los dos chasis

SÍNTOMAEl tráfico a través de una interfaz M-LAG es intermitente, o parece dar vueltas entre los dos chasis a través del peer-link.

CAUSALa dirección MAC de la interfaz de gateway (u otra configuración de gateway) es diferente en Device A y Device B, por lo que el tráfico de retorno dirigido al gateway se reenvía a través del peer-link en lugar de salir directamente por el puerto local correcto.

SOLUCIÓNHabilite consistency-check en modo estricto para que este tipo de discrepancia genere una alarma, compare lado a lado el elemento de configuración marcado, y luego hágalo idéntico en ambos chasis.

3. El ancho de banda del peer-link no se dimensionó para la carga de conmutación

SÍNTOMADespués de que falla una interfaz miembro de M-LAG, la pérdida de paquetes a través del fabric continúa en lugar de recuperarse tras una conmutación breve.

CAUSALa parte del tráfico del puerto caído ahora tiene que cruzar el peer-link para llegar al miembro superviviente en el otro chasis; un peer-link dimensionado solo para tráfico de heartbeat y sincronización de tablas se satura bajo esa carga adicional.

SOLUCIÓNVerifique display interface para la utilización del peer-link durante la ventana de falla, y luego agregue enlaces miembro al Eth-Trunk del peer-link o reequilibre el tráfico para que la falla de un solo puerto no lo sobrecargue.

4. La elección activo-standby nunca se completa sin ARP L2-Proxy

SÍNTOMAUna interfaz M-LAG configurada para selección de miembro activo-standby (en lugar de activo-activo) nunca se estabiliza en un único puerto activo — ambos lados se comportan como si estuvieran reenviando.

CAUSALa elección activo-standby depende de que los paquetes ARP, ND, IGMP, DHCP o MLD sean visibles en ambos chasis para decidir qué puerto miembro debe estar activo; sin arp l2-proxy enable, los paquetes relevantes para la elección no llegan al chasis par y los dos lados nunca se ponen de acuerdo.

SOLUCIÓNHabilite arp l2-proxy en la interfaz M-LAG para que los paquetes relevantes para la elección sean visibles para ambos chasis, y luego confirme que se elige un único puerto miembro activo.

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

5. La tabla de enlace de DHCP Snooping no se sincroniza entre el par M-LAG

SÍNTOMADHCP Snooping está habilitado en ambos chasis M-LAG, pero solo el dispositivo que realmente procesó el intercambio DHCP del cliente construye una entrada de enlace — la tabla del chasis par permanece vacía para ese cliente.

CAUSALa sincronización de la tabla de enlace entre los dos nodos M-LAG depende de una configuración relacionada con DHCP idéntica en cada puerto de ambos chasis (incluidos los puertos que no son de M-LAG) y de que los relojes de los dos chasis estén sincronizados; cualquiera de las dos discrepancias basta para romper silenciosamente la sincronización.

SOLUCIÓNCompare display dhcp snooping configuration puerto por puerto en ambos chasis, verifique display clock en busca de desviación, y alinee ambos antes de asumir que la función en sí está rota.

Cinco preguntas para las que conviene tener una respuesta lista

Extraídas directamente del campo — las que conviene tener respondidas de antemano.

¿Cómo evito que puertos específicos del chasis backup entren en Error-Down cada vez que falla el peer-link?

Por defecto, cuando el peer-link cae, el chasis backup pone sus puertos miembro M-LAG en Error-Down para evitar una condición doble-activo — que es el comportamiento seguro por defecto, pero puede ser más agresivo de lo que un despliegue determinado desea. m-lag unpaired-port suspend permite designar puertos específicos que deben permanecer up y seguir reenviando incluso sin un peer-link emparejado, para casos en los que un breve riesgo de reenvío duplicado es preferible a una interrupción total en esos puertos.

¿Una alarma de discrepancia de consistency-check realmente afecta el tráfico, o es solo una advertencia?

Depende de qué tipo la haya activado. Una inconsistencia de Tipo 1 cubre configuración que afecta la corrección del reenvío (como el caso de MAC de gateway anterior) — si no se resuelve, puede causar problemas reales de tráfico, y reiniciar el dispositivo primario de M-LAG mientras una discrepancia de Tipo 1 está pendiente puede desencadenar un evento doble-activo. Una inconsistencia de Tipo 2 cubre configuración que no afecta directamente el reenvío; vale la pena corregirla por coherencia, pero no romperá el tráfico por sí sola. Verifique qué tipo activó la alarma antes de decidir con qué urgencia actuar.

display dfs-group m-lag muestra un valor de Causation que no es un guion — ¿qué debo verificar primero?

Lea primero el propio texto de Causation antes de verificar cualquier otra cosa — nombra directamente la razón (falla de peer-link, emparejamiento DFS aún no completo, un dispositivo recién reiniciado todavía sincronizando, o una inconsistencia de configuración que impide que el miembro suba completamente). Relacione esa razón con display dfs-group peer-link y display m-lag consistency-check inconsistent-configuration en lugar de adivinar sobre el cableado aguas abajo.

El peer-link acaba de caer, pero el heartbeat se veía bien justo hasta ese momento — ¿qué pasa ahora con mis puertos M-LAG?

Una vez confirmado que el propio peer-link está caído, el chasis backup asume que puede que ya no sea seguro seguir reenviando de forma independiente y por defecto pone sus puertos miembro M-LAG en Error-Down, para evitar que ambos chasis reenvíen activamente el mismo tráfico sin forma de coordinarse. Cualquier puerto que haya excluido explícitamente con m-lag unpaired-port suspend es la excepción. Por eso la redundancia del peer-link (un trunk con más de un miembro físico) importa tanto como su ancho de banda.

Encontramos una discrepancia de consistency-check de Tipo 1 y estoy a punto de reiniciar el dispositivo primario de M-LAG para forzar una resincronización — ¿es seguro?

Todavía no. Reiniciar el primario mientras una discrepancia de Tipo 1 sigue pendiente es exactamente el escenario que puede desencadenar un evento doble-activo (split-brain), porque el backup puede arrancar creyendo que debe tomar el control del reenvío activo mientras el primario también sigue intentándolo. Resuelva primero la discrepancia de configuración marcada, confirme que display m-lag consistency-check inconsistent-configuration vuelve limpio, y solo entonces planifique el reinicio.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se basa en el modelo M-LAG basado en DFS-Group del manual de mantenimiento V300 de las series Huawei CloudEngine 16800/9800/8800/6800 — display dfs-group m-lag / peer-link, error-down recovery, consistency-check, además de los casos de campo que los respaldan, incluido el caso de sincronización de la tabla de enlace de DHCP Snooping. Si su plataforma usa una implementación diferente de MC-LAG o vPC, los comandos exactos cambian, pero el orden de diagnóstico — estado del emparejamiento, salud del peer-link, y luego el síntoma específico de tráfico o sincronización — se traslada directamente. No cubre en profundidad las interacciones de gateway doble-activo de VXLAN sobre M-LAG; vea nuestra nota de resolución de problemas del overlay VXLAN para la capa por encima de esta.

¿Atascado con un par M-LAG específico?

Cuéntenos qué muestran display dfs-group m-lag brief y display m-lag consistency-check inconsistent-configuration, y a cuál de estos casos corresponde, y le ayudamos a interpretarlo.

WhatsApp con un ingeniero →