Tormenta de broadcast, direcciones MAC fluctuando entre puertos, media red inalcanzable — así se ve un bucle de Capa 2 desde dentro. Esto es cómo confirmar que realmente es un bucle, encontrarlo rápido, romperlo sin empeorar las cosas, y evitar que vuelva, con los comandos de diagnóstico reales y los casos de mala configuración del propio manual de mantenimiento de switches Huawei.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026
Los enlaces y equipos redundantes se supone que hacen una red más confiable — hasta que un cambio de red forma un bucle real, y esa misma redundancia se convierte en una tormenta de broadcast.
Las redes de conmutación Ethernet despliegan equipos y enlaces redundantes deliberadamente, por fiabilidad. Pero los ajustes de red, los cambios de configuración y las actualizaciones de versión crean rutinariamente por accidente tramas de datos o de protocolo que circulan en anillo — y en el momento en que un protocolo de ruptura de bucle no está corriendo, o un cambio de configuración le abre silenciosamente un agujero, esa redundancia se convierte en una tormenta de broadcast en lugar de una red de seguridad. Una sola trama de broadcast atrapada en un bucle se reenvía por todos los demás puertos de cada switch del anillo, una y otra vez, hasta saturar cada enlace cerca de la velocidad de línea — y el tráfico normal simplemente deja de tener su turno.
Esta nota cubre cómo determinar que esto es realmente lo que está pasando (en contraposición a otro tipo de interrupción), cómo localizar el bucle rápido, cómo romperlo sin empeorar la interrupción, y los casos específicos de mala configuración — VLAN 1 dejada en un puerto, puertos edge de STP nunca configurados, regiones MSTP que no coinciden, nodos RRPP corriendo modos diferentes — que representan una gran parte de los bucles que nunca debieron existir en primer lugar.
Los síntomas de un bucle y el flujo de confirmación de cuatro métodos, lado a lado.
Los cuatro métodos de confirmación siguientes no tienen un orden fijo — use uno o varios juntos, el que la situación le permita usar primero.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Los cuatro se basan en comandos ya disponibles en cada switch — no se requiere ninguna herramienta especial.
Ejecute display interface brief y compare dos lecturas con un breve intervalo: en un puerto que porta un bucle, InUti y OutUti suben constantemente hacia el techo de velocidad del puerto. Si solo un puerto de un dispositivo muestra tráfico pesado en ambas direcciones, sospeche un autobucle de un solo puerto; si dos puertos de un dispositivo están ambos pesados, sospeche un bucle de dos puertos causando oscilación de protocolo; si solo una dirección es pesada en un solo puerto, el bucle está más probablemente aguas abajo de ese puerto que en él.
<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 conclusionLa fluctuación MAC ocurre cuando una interfaz aprende una dirección MAC que otra interfaz en la misma VLAN también aprende — el aprendizaje posterior sobrescribe la entrada anterior. Un bucle siempre produce fluctuación MAC; la fluctuación MAC no siempre significa un bucle (también puede significar un ataque no autorizado), pero ver la misma dirección MAC rebotar entre dos puertos específicos es la confirmación directa más 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 (switches de chasis) y Loopback Detection (todos los formatos de switch) envían periódicamente una trama de detección especial fuera de una interfaz y verifican si el propio dispositivo la recibe de vuelta — ya sea en la misma interfaz (autobucle) o en otra distinta (bucle de red). Esta es la forma más directa de probar que existe un bucle, a costa de recursos de sistema adicionales, razón por la cual el manual recomienda explícitamente deshabilitarla de nuevo una vez completada la verificación, y nunca habilitarla en un puerto de enlace ascendente.
[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 settingUna participación alta y sostenida de la tarea PPI (Product Process Interface) en display cpu-usage — no un pico breve — sugiere fuertemente que un bucle está inundando la CPU con paquetes que tiene que procesar. Si el PPI en sí se ve normal, verifique display cpu-defend statistics en busca de paquetes de protocolo descartados por limitación de velocidad; un descarte fuerte ahí apunta en la misma dirección.
<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 linkUna vez confirmado el bucle, la prioridad pasa del diagnóstico a recuperar el negocio — lo más rápido posible, sin introducir un segundo problema.
[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 fixedSÍNTOMAEl negocio cae por completo en un switch de doble enlace ascendente, un reinicio lo restaura brevemente, y la misma interrupción exacta regresa algún tiempo después.
CAUSACada puerto trunk lleva la VLAN 1 por defecto a menos que se elimine explícitamente. Si dos puertos que nunca deberían compartir un dominio de broadcast aún llevan ambos la VLAN 1, esa VLAN forma bucle incluso mientras la instancia STP o RRPP que realmente protege las demás VLAN funciona perfectamente — porque la VLAN 1 nunca fue incluida en lo que esos protocolos protegen.
SOLUCIÓNVerifique una VLAN 1 común entre los puertos que muestran tráfico anormal, y luego elimine la VLAN 1 de los puertos que no la necesitan (undo port trunk allow-pass vlan 1), o incorpore explícitamente la VLAN 1 en la instancia protegida si realmente necesita circular por el anillo.
SÍNTOMASTP está habilitado globalmente en ambos switches, pero la red se sigue inundando de tráfico broadcast como si no corriera ningún protocolo de ruptura de bucle en absoluto.
CAUSAEn las versiones de switch afectadas, un puerto necesita bpdu enable configurado antes de realmente pasar las BPDU de STP recibidas al CPU para su procesamiento — sin él, las BPDU simplemente se descartan en el puerto, por lo que nunca se calcula ningún puerto bloqueante, aunque STP parezca habilitado globalmente.
SOLUCIÓNEjecute display stp interface en cada puerto del anillo — si todos los puertos muestran Designated Port y ninguno muestra Alternate o Root, la negociación STP nunca ocurrió realmente. Configure bpdu enable en los puertos que necesitan recibir y procesar tramas STP.
SÍNTOMACiertas laptops no logran obtener una dirección IP específicamente al arrancar desde una tarjeta de red (arranque estilo PXE), mientras que otros dispositivos en el mismo switch no tienen ningún problema.
CAUSAUna NIC haciendo un arranque de red hace oscilar brevemente el enlace durante el inicio. Si el puerto del switch que da a ese terminal no está configurado como puerto edge de STP, esa oscilación dispara un recálculo completo de la topología STP — unos 30 segundos durante los cuales el puerto no reenvía. El terminal solo envía cuatro intentos de descubrimiento DHCP en esa ventana, no obtiene respuesta a ninguno, y simplemente se rinde.
SOLUCIÓNConfigure stp edged-port enable en cada puerto que se conecta a un terminal final en lugar de a otro switch. Las versiones de plataforma más recientes pueden autodetectar los puertos orientados a terminales y configurar esto automáticamente, pero vale la pena confirmarlo en lugar de asumirlo.
SÍNTOMASe configuran deliberadamente varias instancias STP para que un puerto dado pueda reenviar en una instancia de VLAN y bloquear en otra, pero cada instancia converge idénticamente a la instancia 0, sin importar qué valores de costo por instancia se configuren.
CAUSADos switches MSTP solo comparten una región — y por lo tanto pueden correr sus instancias independientemente — cuando el nombre de región, el mapeo instancia-VLAN, el selector de formato y el nivel de revisión coinciden exactamente. Si solo el nombre de región difiere, los switches vuelven a calcular cada instancia de la misma manera que la instancia 0, anulando silenciosamente todo el propósito de configurar instancias separadas.
SOLUCIÓNCompare display stp region-configuration en ambos switches — el nombre de región primero. Alinee el nombre de región, luego reconfirme que los valores de costo por instancia realmente surtan efecto de forma independiente.
SÍNTOMADespués de que un enlace en el anillo RRPP falla y se recupera, las tablas MAC y ARP en los nodos de tránsito no se actualizan, y el tráfico sigue roto aunque el anillo físico esté saludable de nuevo.
CAUSARRPP tiene dos modos de trabajo — el modo propietario de Huawei por defecto y el modo GB (estándar nacional) — y cada nodo del mismo anillo debe correr el mismo. Si el nodo maestro está configurado en modo GB mientras los nodos de tránsito quedan en el predeterminado, los paquetes de notificación common/complete del maestro simplemente no son procesados por los nodos de tránsito, así que sus tablas MAC y ARP nunca se enteran de que la topología cambió.
SOLUCIÓNVerifique display rrpp verbose domain en el nodo maestro para confirmar su modo de trabajo, luego verifique lo mismo en cada nodo de tránsito — alinee todos a un modo, cualquiera que sea, de forma consistente en todo el anillo.
La interrupción parecía un problema de enrutamiento. La causa real fue una VLAN que nadie pensó en revisar.
La configuración: un switch con dos enlaces ascendentes hacia routers, y dispositivos de capa de acceso colgando aguas abajo. El síntoma: ambos enlaces ascendentes quedaron completamente oscuros para el negocio, un reinicio restauró el servicio por un tiempo, y luego regresó la misma falla exacta.
El rastro de logs apuntaba primero a OSPF, no a la Capa 2 en absoluto — la relación de vecino del enlace ascendente seguía cayendo, aparentemente sin razón:
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)Los registros de diagnóstico contaron la verdadera historia: los puertos ascendentes GE1/0/0 y GE1/0/1 mostraban ambos tráfico saliente anormal, mientras que los puertos descendentes GE1/0/3 y GE1/0/4 mostraban ambos tráfico entrante anormal al mismo tiempo — los cuatro justo en el techo de velocidad del puerto:
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)Comparar la configuración de cada puerto marcado reveló exactamente una cosa en común: la VLAN 1. El tráfico que entraba a GE1/0/3 y GE1/0/4 dentro de la VLAN 1 se retransmitía directamente a los otros puertos marcados, incluidos los dos enlaces ascendentes — inundándolos hasta que los propios paquetes hello de OSPF se descartaban, lo que en realidad tumbó la relación de vecino. Quitar GE1/0/3 y GE1/0/4 de la VLAN 1 despejó la falla de inmediato, sin necesitar más cambios.
El punto generalizable: un bucle de VLAN 1 es lo bastante común como para revisarlo primero, específicamente, cada vez que el tráfico de varios puertos sin relación aparente se ve anormal — compare sus configuraciones en busca de una VLAN compartida antes de suponer que la falla está en algo más exótico.
Una vez apagado el incendio inmediato, estas cinco comprobaciones son lo que realmente previene el siguiente.
Esta nota se basa en el Capítulo 6 del propio manual de mantenimiento de switches Huawei — los pasos de diagnóstico, los casos de mala configuración y las recomendaciones de refuerzo provienen todos de esa referencia. No cubre en profundidad el comportamiento de subanillos ERPS, las especificidades de Smart Link, ni los escenarios de bucle causados por equipos de terceros que rebotan tramas que no pueden procesar de otro modo — cada uno merecería una mirada aparte.
Las preguntas que surgen cada vez que un bucle sospechoso está realmente sobre la mesa.
La fluctuación de dirección MAC es la señal delatora: un bucle real siempre produce la misma dirección MAC rebotando entre dos puertos específicos en la misma VLAN, porque el switch la sigue re-aprendiendo desde ambas direcciones. Un solo dispositivo con mal comportamiento o comprometido que genera tráfico de broadcast pesado normalmente no produce esa firma particular de fluctuación bilateral entre dos puertos — aparece como tráfico alto sin el patrón de deriva MAC correspondiente.
No por sí solo. Una participación de PPI alta y sostenida es un fuerte indicador, pero muchas otras condiciones también pueden elevar el uso de CPU. Verifique cruzadamente con el tráfico de interfaz y la fluctuación MAC, o despliegue detección de bucle para una respuesta directa, antes de tratar el CPU alto como prueba por sí mismo.
El shutdown es casi siempre la mejor opción — es instantáneamente reversible con undo shutdown y no arriesga dañar un conector o extremo de fibra. Desconectar físicamente un cable es un último recurso reservado para cuando el dispositivo mismo ya no puede alcanzarse remotamente para emitir el comando shutdown.
Sí, potencialmente — quitar la VLAN por defecto de un puerto Access en particular puede afectar a cualquier dispositivo o usuario aguas abajo realmente conectado a él, así que confirme qué hay detrás de un puerto antes de tocarlo. Quitar un ID de VLAN específico de un puerto Trunk o Hybrid generalmente tiene un impacto más acotado, ya que otras VLAN en ese mismo puerto siguen reenviando normalmente.
Los protocolos de ruptura de bucle (STP/RSTP/MSTP, RRPP, SEP, ERPS) son la defensa real y deberían elegirse deliberadamente para coincidir con el diseño de la red — no se recomienda correr RRPP y MSTP juntos en los mismos puertos. Loop Detection y Loopback Detection son herramientas de diagnóstico suplementarias que consumen recursos de sistema adicionales; el manual recomienda específicamente deshabilitarlas de nuevo una vez completada una verificación de despliegue, en lugar de dejarlas corriendo permanentemente en todas partes.
Envíenos su salida de display interface brief y un boceto aproximado de la topología — le ayudamos a encontrar el bucle y romperlo de forma segura.