En un campus WAC, todos los AP Fit conectados bajo un mismo switch de acceso se desconectan a la vez — sin cable desconectado, sin corte de energía, sin nada anormal en el propio AP. La causa real está dos capas más allá: un cambio de topología STP en cualquier punto del dominio de capa 2 inunda la red con TC-BPDU, el switch que actúa como gateway de los AP envejece y vacía su tabla ARP en respuesta, y cada AP bajo él pierde su gateway y es dado de baja en bloque. Esta es la cadena, los comandos que confirman cada eslabón y la corrección de dos líneas.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
En realidad no hay nada roto en el AP — es solo el último eslabón de una cadena que comienza en otro lugar completamente distinto de la red de conmutación.
El ticket siempre se ve igual: un campus gestionado por WAC informa que un lote de AP Fit —a veces todos los conectados bajo un mismo switch de acceso— quedó fuera de línea a la vez, sin ningún corte de energía correlacionado, sin cable desconectado, sin cambio de firmware. El instinto es empezar a diagnosticar los propios AP: revisar su alimentación, su enlace ascendente, la AC. Casi nunca es ahí donde está realmente la falla.
A continuación, la cadena de causa raíz detrás de la versión más común de esta falla, los comandos que confirman cada eslabón de esa cadena en lugar de solo el síntoma final, las dos líneas de configuración que la cierran, y las preguntas de campo que conviene tener respondidas antes de la próxima vez.
Tres orígenes distintos producen el mismo síntoma en el lado del AP — solo uno de ellos merece rastrearse hacia atrás a través de la red de conmutación.
Ubicar la falla en este árbol antes de tocar los propios AP indica si se trata de un problema de hardware aislado, una sobrecarga de CPU, o la cadena TC-BPDU de la que realmente trata esta nota.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Los pasos 1 y 2 son un comportamiento STP normal y saludable — una notificación de cambio de topología debe propagarse. La falla está enteramente en el paso 3: la tabla ARP de este switch en particular no debería tratarse como sospechosa solo porque en otro punto del dominio un puerto pasó a up o down.
Cuatro comprobaciones, en orden — cada una descarta una rama distinta del árbol antes de decantarse por la explicación TC-BPDU.
La rama en la que se encuentra depende por completo de si esto afecta a un solo AP o a todo un switch.
Antes de culpar específicamente a TC-BPDU, descarte la otra causa a nivel de red: demasiados paquetes llegando a la CPU.
<AC> display cpu-defend statistics
Statistics on slot 1
Packet Type Pass Drop LastDropTime
------------------------------------------------------
ND 38214 129552 2026-07-20 09:41:02
ARP 9021 0 -
// a disproportionate count on one protocol -> chase that source, don't assume TC-BPDU yetEsta es la comprobación que realmente confirma la cadena — ejecútela en el switch que está directamente aguas arriba de los AP afectados y actúa como su gateway.
<Switch> display stp topology-change //查看拓扑变化
<Switch> display stp tc-bpdu statistics //查看端口TC报文收发计数Dos líneas, y deben aplicarse juntas — una sola es solo una corrección a medias.
<Switch> system-view
[Switch] mac-address update arp //开启MAC刷新ARP功能，即MAC地址的出接口变化时，通知更新ARP表项的出接口
[Switch] arp topology-change disable //关闭设备响应TC报文的功能，即当设备收到TC报文时，不对ARP表项进行老化或删除La cadena anterior es el mecanismo — estas son las formas en que los ingenieros realmente se atascan con esto en el campo.
SÍNTOMATodos los AP bajo un mismo switch caen juntos, con alimentación limpia y enlace ascendente intacto en cada uno.
CAUSAEl AP en realidad nunca falló. Simplemente perdió su entrada ARP para su gateway o la AC, porque el switch detrás del cual está envejeció esa entrada en respuesta a un TC-BPDU recibido — la falla está enteramente aguas arriba, en el manejo de la tabla ARP del switch, no en el AP ni en su radio.
SOLUCIÓNDeje de diagnosticar los AP individualmente una vez que más de uno bajo el mismo switch esté afectado — vaya directamente a display stp topology-change y display stp tc-bpdu statistics en el switch aguas arriba.
SÍNTOMAEl propio enlace ascendente y los puertos del switch gateway de los AP nunca parpadearon, y aun así su tabla ARP se vació.
CAUSAUna notificación de cambio de topología se propaga a todos los switches del mismo dominio spanning-tree, no solo al switch donde el puerto realmente parpadeó. Si ese switch todavía responde al TC-BPDU envejeciendo su tabla ARP, un evento de enlace en el otro extremo del campus puede vaciar la tabla ARP de este switch y hacer caer a todos los AP detrás de él.
SOLUCIÓNNo limite la búsqueda de la causa raíz a los enlaces ascendentes propios del switch gateway de los AP — verifique cambios de topología en cualquier parte del mismo dominio STP en torno al momento en que cayeron los AP.
SÍNTOMAMismo síntoma aparente — un lote de AP fuera de línea a la vez — pero la AC o el switch núcleo se reinició, restableció o conmutó poco antes de que ocurriera.
CAUSAUn evento de conmutación de chasis en la propia AC es un mecanismo completamente distinto — una secuencia de degradación y luego repromoción en la unidad de control que elimina en masa los registros de AP — y deja su propio rastro forense en el motivo de reinicio y los registros de desconexión de AP, no en display stp tc-bpdu statistics.
SOLUCIÓNVerifique si el chasis AC/núcleo tuvo un reinicio o una conmutación de slot en la misma ventana antes de asumir que se trata de una tormenta TC-BPDU; si fue así, el mecanismo de conmutación de chasis es la explicación más probable.
SÍNTOMACaídas de AP igualmente abruptas, pero esta vez acompañadas de un rendimiento generalmente pobre, alta CPU en todas partes, y direcciones MAC alternando entre puertos en toda la red de conmutación.
CAUSAUn vaciado de ARP impulsado por TC-BPDU puede ocurrir a partir de un único cambio de topología breve y por lo demás saludable — no requiere un verdadero bucle de capa 2. Un bucle genuino produce su propia firma mucho más amplia: inundación de difusión, alternancia de MAC en los puertos, y congestión a nivel de red, no solo un evento de caída de AP confinado a un switch gateway.
SOLUCIÓNSi los síntomas van más allá de las simples caídas de AP —tormentas de difusión, tablas MAC alternando, lentitud generalizada— siga el proceso de búsqueda de bucles en lugar de la cadena TC-BPDU/ARP de esta nota.
SÍNTOMALas caídas de AP se vuelven menos frecuentes tras aplicar una corrección, pero aún recurren ocasionalmente tras un cambio de topología en otro lugar.
CAUSAmac-address update arp solo hace que las entradas ARP se actualicen más rápido cuando cambia la interfaz de salida de un MAC — no impide que el switch envejezca o elimine entradas ARP en respuesta a un TC-BPDU. Configurarlo solo deja una ventana en la que aún se pueden borrar entradas.
SOLUCIÓNConfigure ambos comandos juntos: mac-address update arp para una convergencia más rápida, y arp topology-change disable para impedir por completo que el TC-BPDU afecte la tabla ARP.
Extraídas directamente del campo — aquellas para las que vale la pena tener una respuesta lista.
Primero verifique el motivo de reinicio y el tiempo de actividad del propio chasis AC/núcleo. Si se reinició, restableció o conmutó poco antes de que cayeran los AP, trabaje ese mecanismo — el rastro del reinicio lo explica directamente. Si la AC/núcleo no se tocó y solo el switch de acceso intermedio muestra un cambio de topología reciente, esta cadena TC-BPDU es la explicación más probable.
Casi cualquier cosa que haga que un puerto suba o baje en el mismo dominio spanning-tree: un reinicio de dispositivo, un cable reconectado, un puerto parpadeando intermitentemente, incluso un cambio de mantenimiento planificado en un switch no relacionado. El punto de esta cadena de fallas es que el cambio no tiene que ocurrir cerca de los AP que terminan cayendo.
Sí, para el switch que actúa como gateway de los AP — impide que eventos de cambio de topología normales y saludables borren entradas ARP que aún son válidas. Debe combinarse con mac-address update arp para que las entradas sigan actualizándose correctamente en las ocasiones en que la interfaz de salida realmente cambia, que es el escenario que el envejecimiento de ARP por TC-BPDU pretendía originalmente manejar.
Porque el TC-BPDU se propaga a todo el dominio spanning-tree, no solo al switch donde ocurrió el parpadeo. Cualquier switch que todavía envejezca su tabla ARP al recibir un TC-BPDU reacciona igual, sin importar dónde se originó realmente el cambio de topología — precisamente por eso la corrección debe aplicarse en el switch gateway de los AP, no rastreándose hasta el puerto que parpadeó.
Establezca una línea base de display stp tc-bpdu statistics en sus switches gateway de AP y observe si los recuentos suben fuera de las ventanas de mantenimiento planificadas — un recuento ascendente ahí, antes de cualquier alarma de AP fuera de línea, es la señal más temprana de que esta cadena está comenzando. Combinarlo con comprobaciones periódicas de display cpu-defend statistics también detecta la rama de sobrecarga de CPU antes de que escale.
Esta nota se basa en el modelo de clasificación de fallas WAC/Fit-AP de Huawei y los comandos display stp / display cpu-defend detrás de él, además de los casos de campo que los motivan. Cubre específicamente la cadena de vaciado de ARP impulsada por TC-BPDU — no reemplaza una investigación completa de bucle de capa 2 cuando los síntomas son más amplios que un evento de caída de AP, y no cubre la conmutación de chasis de la AC ni fallas de hardware, que tienen sus propias rutas de diagnóstico separadas.
Cuéntenos si es el equivalente a un switch o todo el campus, además de la salida de display stp tc-bpdu statistics del switch gateway de los AP, y le ayudaremos a interpretarla.