En un clúster de núcleo de campus S7706, un comando pensado como recurso de emergencia in situ — reboot chassis 1 — desconectó de golpe todos los AP aguas abajo. Esta es la cronología forense, los comandos exactos que la reconstruyeron, el mecanismo de conmutación de AC de «degradar y luego repromover» detrás de la eliminación por lotes, y el cambio de cableado que detuvo la repetición.
Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operador y empresariales · Actualizado en julio de 2026
El par de AC, las radios de los AP y los túneles CAPWAP nunca fueron la falla — el desencadenante estaba a dos saltos de distancia, en un reinicio de switch.
En un clúster S7706 V200R024C00SPC500 que actuaba como núcleo de campus, un ingeniero ejecutó reboot chassis 1 — un comando de recurso documentado para reiniciar un chasis de un sistema apilado/en clúster cuando un ciclo de encendido físico in situ no es una opción. Todos los AP aguas abajo cayeron a la vez, y los registros mostraron una ola de eventos de interfaz Down. En realidad, nada había fallado del lado inalámbrico.
A continuación: la cronología forense reconstruida a partir de display reset-reason y display ap offline-record, el mecanismo — un parpadeo VRRP de degradar y luego repromover que dispara una eliminación por lotes de sesiones de AP — y el cambio de topología verificado en laboratorio que impide la repetición con el mismo comando de reinicio.
Tres fuentes de registro distintas, cruzadas entre sí, cuentan una historia que ninguna cuenta por sí sola.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Leída por separado, cada fuente de registro cuenta solo una parte de la historia — reset-reason muestra un evento limpio, los registros de interfaz muestran una secuencia escalonada, y ap offline-record muestra una eliminación por lotes que ninguna de las otras dos explica por sí sola.
Ninguna de estas tres salidas por sí sola explica una caída masiva de AP — al cruzarlas sí.
En el maestro S7706, esto muestra exactamente un evento relevante: la tarjeta de interfaz que se reinició, y por qué.
<HUAWEI> display reset-reason
... ...
Info: The LPU chassis[1] board[1] does not have reset records.
Info: The LPU chassis[1] board[2] does not have reset records.
Info: The LPU chassis[1] board[3] does not have reset records.
The LPU chassis[1] board[4]'s reset time is 1 in total. Detailed information:
-- 1. 2025/03/07 03:21:36, Reset No.: 1
Reason: Reset for reboot chassis command
Info: The LPU chassis[1] board[5] does not have reset records.
Info: The LPU chassis[1] board[6] does not have reset records.
Info: The MPU chassis[1] board[8]'s reset time is 2 in total. Detailed information:
-- 1. 2025/03/07 04:34:02, Reset No.: 2
Reason: Reset for chassis combine
-- 2. 2025/02/28 16:53:02, Reset No.: 1
Reason: Reset for chassis combineEsta es la parte fácil de malinterpretar: un evento limpio de “Reset for reboot chassis command” parece demostrar que la conmutación también fue limpia. No demuestra nada del lado del AC — reset-reason solo registra reinicios de chasis y tarjetas, no transiciones de estado VRRP.
El propio registro del chasis en espera es explícito: sus interfaces físicas nunca cambiaron de estado — lo que registró fue el del par.
Mar 7 2025 03:21:45+08:00 TCLY-02G07-201.253 %%01IFPDT/4/IF_STATE(I)[3125]:Interface
XGigabitEthernet1/6/0/12 has turned into DOWN state.
Mar 7 2025 03:21:46+08:00 TCLY-02G07-201.253 %%01IFPDT/4/IF_STATE(I)[3128]:Interface
XGigabitEthernet1/6/0/24 has turned into DOWN state.
// recorded on the standby's log, but this is the master's interface state, propagated
// over the inter-chassis link -- the standby's own physical port state never went Down
Mar 7 2025 03:21:50+08:00 TCLY-02G07-201.253 %%01TRUNK/S/MEMBER_UP(I)[3191]:The status of the
trunk member went Up.(TrunkName=Eth-Trunk12, PortName=XGigabitEthernet2/6/0/1)
// Eth-Trunk members recorded "went Up" as an interface-state refresh once the
// standby had taken over -- not a sign the physical link had ever actually droppedEste es el comando que realmente explica la caída masiva — el campo de motivo dice «Batch delete», no un fallo de radio o de latido.
<HUAWEI> display ap offline-record all
... ...
MAC Last offline time Reason
------------------------------------------------------------------------------
0425-c58b-ea80 2025-03-07/04:24:10 Heartbeat packet transmission for the CAPWAP control tunnel
between the AC and AP times out.
0425-c58b-ea80 2025-03-07/03:15:36 Batch delete
04bd-702b-8aa0 2025-03-07/04:24:10 Heartbeat packet transmission for the CAPWAP control tunnel
between the AC and AP times out.
... ...Dos códigos de motivo distintos en el mismo AP cuentan dos partes distintas de la historia: «Batch delete» es la firma del evento de degradar y luego repromover en el lado del AC descrito abajo; las entradas de tiempo de espera de heartbeat de CAPWAP son la consecuencia ordinaria de la misma ventana de inestabilidad de interfaz aguas arriba.
reboot chassis 1 es una vía de escape, no un ciclo de encendido limpio — y esa diferencia es exactamente lo que causó esto.
reboot chassis 1 está documentado como un comando de recurso, pensado específicamente para situaciones en las que el chasis no puede someterse a un ciclo de encendido in situ, y conlleva sus propias restricciones de uso. Al ejecutarse, el chasis objetivo primero notifica a su par que la pila/clúster se está dividiendo, y luego reinicia sus tarjetas de interfaz una por una — no puede garantizar que todo el tráfico se detenga simultáneamente como lo haría un ciclo de encendido real.
En esta topología, la ruta de anuncios VRRP pasa por AC-maestro — S7706-maestro — S7706-en espera — AC-en espera. Como las tarjetas de interfaz del S7706 maestro caen una por una durante el reinicio escalonado, en lugar de todas a la vez, los paquetes hello de VRRP siguen filtrándose de forma intermitente en lugar de detenerse limpiamente en el instante en que comienza el reinicio. El AC en espera ve que los hello se interrumpen, se promueve a Master — luego, casi de inmediato, ve que los hello se reanudan y se degrada de nuevo a Backup, antes de promoverse a Master otra vez una vez que la conmutación realmente se completa. Es precisamente esa transición de degradar justo después de una falsa promoción la que dispara una eliminación por lotes de todas las sesiones de AP que el AC en espera había empezado a adoptar.
Esta misma disciplina — no confiar en un estado de alto nivel limpio hasta haber comprobado si un proceso del plano de control realmente falló por debajo — es la misma que recorremos en nuestra nota de solución de problemas de CPU alta en switches: un equipo puede parecer estructuralmente correcto en la superficie mientras un breve evento del plano de control por debajo causa el daño real.
Debajo de todo esto hay un hueco de topología: la red tal como está construida no tiene un enlace redundante entre AC-maestro/S7706-en espera o AC-en espera/S7706-maestro, por lo que la ruta de hello de VRRP tiene exactamente una vía para filtrarse — y esa vía pasa directamente por el chasis que se está reiniciando.
La salida de reset-reason parecía completamente normal. Esa es precisamente la trampa.
SÍNTOMAUn ingeniero ejecuta reboot chassis 1 en un S7706 en clúster en producción, esperando el mismo comportamiento que un reinicio completo del equipo — en cambio, todos los AP aguas abajo caen.
CAUSALa documentación fuente confirma que reboot chassis 1 es un comando de recurso destinado únicamente a situaciones en las que un ciclo de encendido físico del chasis in situ no es posible, y conlleva sus propias restricciones de uso — su secuencia de reinicio escalonada, tarjeta por tarjeta, no equivale a un ciclo de encendido real, que corta todo el tráfico simultáneamente.
SOLUCIÓNPrefiera un ciclo de encendido real, o un reinicio completo del equipo en lugar de un reinicio de un solo chasis, dentro de una ventana de cambio adecuada siempre que el acceso al sitio lo permita. Trate reboot chassis N como un último recurso con su propio perfil de riesgo distinto, no como un sustituto rutinario.
SÍNTOMAdisplay reset-reason muestra exactamente un evento ordenado — «Reset for reboot chassis command» — sin embargo, el par de AC osciló Backup → Master → Backup → Master durante la misma ventana.
CAUSAComo las tarjetas de interfaz del S7706 principal se reinician secuencialmente y no juntas, los anuncios de VRRP en la ruta AC-maestro—S7706-maestro—S7706-en espera—AC-en espera siguen filtrándose de forma intermitente durante el reinicio en lugar de detenerse en el instante en que comienza — y reset-reason no tiene ninguna visibilidad sobre el estado de VRRP.
SOLUCIÓNNo interprete una entrada limpia de reset-reason como prueba de que toda la conmutación fue limpia — cruce display ap offline-record all y el historial de transición VRRP propio del AC en espera para la misma ventana de tiempo antes de cerrar el incidente.
SÍNTOMAdisplay ap offline-record all muestra «Batch delete» como motivo del evento de caída masiva, no un tiempo de espera de latido ni un fallo de radio.
CAUSAEl estado VRRP del par de AC no conmuta solo una vez — se degrada de nuevo a Backup casi inmediatamente después de promoverse a Master, por los hello que se filtran descritos arriba — y esa transición específica de degradar justo después de promover es la que dispara una eliminación por lotes de todas las sesiones de AP que el AC en espera había empezado a adoptar.
SOLUCIÓNAl solucionar un evento de caída masiva de AP en un par de AC redundante, obtenga el historial completo de transiciones de VRRP, no solo el estado final — una conmutación limpia única y una que oscila se ven idénticas si solo comprueba dónde terminó la máquina de estados.
SÍNTOMALa reproducción en laboratorio confirma el fallo en la topología documentada, y el mismo comando de reinicio deja de reproducirlo una vez que se añade un enlace adicional en cada lado.
CAUSALa topología tal como se implementó no tiene una ruta redundante entre AC-maestro/S7706-en espera y AC-en espera/S7706-maestro — los hello de VRRP tienen exactamente una ruta para filtrarse durante un reinicio, y esa ruta pasa directamente por el chasis que se está reiniciando.
SOLUCIÓNAñada un enlace cada uno entre AC-maestro—S7706-en espera y AC-en espera—S7706-maestro, con ambos AC y ambos chasis S7706 conectados mediante agregación Eth-Trunk en cada lado. Verificado en laboratorio: el mismo comando reboot chassis ya no tumba ningún AP una vez que estos enlaces están en su lugar.
Cuatro cambios, en orden de qué tan directamente aborda cada uno lo que realmente ocurrió aquí.
Extraídas directamente del campo — las que vale la pena tener respondidas de antemano.
Esos eventos Down en el registro del en espera se refieren al estado de interfaz del par (el maestro), propagado al en espera a través del enlace entre chasis — no al estado del puerto físico propio del en espera. El caso fuente es explícito: el estado físico de la interfaz propia del chasis en espera nunca cambió durante todo el incidente.
No. Está documentado como un comando de emergencia específicamente para cuando no se puede cortar la energía del chasis in situ, y se comporta de forma distinta — reiniciando las tarjetas de interfaz una por una en lugar de cortar todo el tráfico de golpe. La recomendación fuente es explícita: este problema exacto no ocurriría bajo un reinicio real por corte de energía.
El disparador de eliminación por lotes descrito aquí es específico de que el estado VRRP de un par de AC oscile Backup → Master → Backup → Master durante el reinicio escalonado de un par. Un diseño con un solo AC no tiene esa ruta de conmutación en absoluto — pero pierde la redundancia por completo en su lugar, lo cual es un riesgo distinto, no uno más seguro.
No. reset-reason solo registra reinicios de chasis y tarjetas, no transiciones de estado VRRP en el par de AC. Un único evento de reinicio limpio del lado del switch es totalmente compatible con una conmutación oscilante ocurriendo del lado del AC — esa transición simplemente no aparecerá en absoluto en la salida de este comando.
La reproducción en laboratorio tras añadir los enlaces no reprodujo la caída de AP bajo el mismo comando de reinicio, porque los enlaces cruzados eliminan la única vía por la que los hello de VRRP podían filtrarse. El comportamiento subyacente de reinicio escalonado, tarjeta por tarjeta, de reboot chassis N no cambia — la solución elimina la vía de fuga, no la secuenciación interna del reinicio.
Este post-mortem se basa en un único caso documentado S7706 V200R024C00SPC500 en el propio manual de mantenimiento de switches de campus Huawei serie S. Otros modelos de chasis, versiones de software o proveedores de AC WLAN pueden usar temporizadores de detección de conmutación y disparadores de eliminación por lotes distintos — trate el mecanismo de degradar y luego repromover descrito aquí como un patrón que vale la pena verificar, no una coincidencia garantizada para todo evento de caída masiva de AP.
Envíenos la salida de su display reset-reason y display ap offline-record all, más la topología del par de AC — le ayudaremos a determinar si es el mismo mecanismo.