Em um cluster de núcleo de campus S7706, um comando pensado como recurso de emergência local — reboot chassis 1 — derrubou de uma vez todos os APs a jusante. Esta é a linha do tempo forense, os comandos exatos que a reconstruíram, o mecanismo de failover de AC de “rebaixar e depois repromover” por trás da exclusão em lote, e a mudança de cabeamento que impediu a repetição.
Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e corporativas · Atualizado em julho de 2026
O par de ACs, os rádios dos APs e os túneis CAPWAP nunca foram a falha — o gatilho estava a dois saltos de distância, em um reinício de switch.
Em um cluster S7706 V200R024C00SPC500 atuando como núcleo de campus, um engenheiro executou reboot chassis 1 — um comando de recurso documentado para reiniciar um chassi de um sistema empilhado/em cluster quando um ciclo de energia físico no local não é uma opção. Todos os APs a jusante caíram de uma vez, e os logs registraram uma onda de eventos de interface Down. Nada do lado sem fio realmente havia falhado.
A seguir: a linha do tempo forense reconstruída a partir de display reset-reason e display ap offline-record, o mecanismo — uma oscilação de VRRP de rebaixar e depois repromover que dispara uma exclusão em lote de sessões de AP — e a mudança de topologia verificada em laboratório que impede a repetição com o mesmo comando de reinício.
Três fontes de log separadas, cruzadas entre si, contam uma história que nenhuma conta sozinha.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Lida separadamente, cada fonte de log conta apenas parte da história — reset-reason mostra um evento limpo, os logs de interface mostram uma sequência em etapas, e ap offline-record mostra uma exclusão em lote que nenhuma das outras duas explica sozinha.
Nenhuma dessas três saídas sozinha explica uma queda em massa de APs — cruzá-las explica.
No mestre S7706, isso mostra exatamente um evento relevante: a placa de interface que resetou, e 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 é a parte fácil de interpretar mal: um evento limpo de “Reset for reboot chassis command” parece provar que o failover também foi limpo. Não prova nada do lado do AC — reset-reason só registra reinícios de chassi e placa, não transições de estado do VRRP.
O próprio log do chassi em espera é explícito: suas interfaces físicas nunca mudaram de estado — o que ele registrou foi o do 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 é o comando que realmente explica a queda em massa — o campo de motivo diz “Batch delete”, não uma falha de rádio ou de heartbeat.
<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.
... ...Dois códigos de motivo diferentes no mesmo AP contam duas partes diferentes da história: “Batch delete” é a assinatura do evento de rebaixar e depois repromover do lado do AC descrito abaixo; as entradas de timeout de heartbeat do CAPWAP são a consequência comum da mesma janela de instabilidade de interface a montante.
reboot chassis 1 é uma saída de emergência, não um ciclo de energia limpo — e essa diferença é exatamente o que causou isso.
reboot chassis 1 é documentado como um comando de recurso de emergência, pensado especificamente para situações em que o chassi não pode passar por um ciclo de energia no local, e traz suas próprias restrições de uso. Ao ser executado, o chassi-alvo primeiro notifica seu par de que a pilha/cluster está se dividindo, depois reinicia suas placas de interface uma de cada vez — não pode garantir que todo o tráfego pare simultaneamente como um ciclo de energia real faria.
Nessa topologia, o caminho dos anúncios VRRP passa por AC-mestre — S7706-mestre — S7706-em espera — AC-em espera. Como as placas de interface do S7706 mestre caem uma de cada vez durante o reinício em etapas, em vez de todas de uma vez, os pacotes hello do VRRP continuam vazando de forma intermitente em vez de parar de forma limpa no instante em que o reinício começa. O AC em espera vê os hellos se interromperem, se promove a Master — depois, quase imediatamente, vê os hellos retornarem e se rebaixa de volta a Backup, antes de se promover a Master novamente quando o failover realmente se completa. É exatamente essa transição de rebaixar logo após uma falsa promoção que dispara uma exclusão em lote de todas as sessões de AP que o AC em espera havia começado a adotar.
Essa mesma disciplina — não confiar em um status de alto nível limpo até verificar se um processo do plano de controle realmente falhou por baixo — é a mesma que percorremos em nossa nota de solução de problemas de CPU alta em switches: um equipamento pode parecer estruturalmente correto na superfície enquanto um breve evento do plano de controle por baixo causa o dano real.
Por trás de tudo isso está uma lacuna de topologia: a rede como construída não tem um link redundante entre AC-mestre/S7706-em espera ou AC-em espera/S7706-mestre, então o caminho dos hellos do VRRP tem exatamente uma rota para vazar — e essa rota passa diretamente pelo chassi que está sendo reiniciado.
A saída de reset-reason parecia completamente normal. É exatamente essa a armadilha.
SINTOMAUm engenheiro executa reboot chassis 1 em um S7706 em cluster em produção, esperando o mesmo comportamento de um reinício completo do equipamento — em vez disso, todos os APs a jusante caem.
CAUSAA documentação de origem confirma que reboot chassis 1 é um comando de recurso destinado apenas a situações em que um ciclo de energia físico do chassi no local não é possível, e traz suas próprias restrições de uso — sua sequência de reinício em etapas, placa por placa, não equivale a um ciclo de energia real, que interrompe todo o tráfego simultaneamente.
CORREÇÃOPrefira um ciclo de energia real, ou um reinício completo do equipamento em vez de um reinício de um único chassi, dentro de uma janela de mudança adequada sempre que o acesso ao local permitir. Trate reboot chassis N como um último recurso com seu próprio perfil de risco distinto, não como um substituto de rotina.
SINTOMAdisplay reset-reason mostra exatamente um evento limpo — “Reset for reboot chassis command” — mas o par de AC oscilou Backup → Master → Backup → Master durante a mesma janela.
CAUSAComo as placas de interface do S7706 principal reiniciam sequencialmente em vez de juntas, os anúncios de VRRP no caminho AC-mestre—S7706-mestre—S7706-em espera—AC-em espera continuam vazando de forma intermitente durante o reinício em vez de parar no instante em que ele começa — e reset-reason não tem nenhuma visibilidade sobre o estado do VRRP.
CORREÇÃONão interprete uma entrada limpa de reset-reason como prova de que todo o failover foi limpo — cruze display ap offline-record all e o histórico de transição VRRP do próprio AC em espera para a mesma janela de tempo antes de encerrar o incidente.
SINTOMAdisplay ap offline-record all mostra “Batch delete” como o motivo do evento de queda em massa, não um timeout de heartbeat ou uma falha de rádio.
CAUSAO estado VRRP do par de AC não faz failover apenas uma vez — ele se rebaixa de volta a Backup quase imediatamente após se promover a Master, por causa dos hellos vazando descritos acima — e é exatamente essa transição de rebaixar logo após promover que dispara uma exclusão em lote de todas as sessões de AP que o AC em espera havia começado a adotar.
CORREÇÃOAo solucionar um evento de queda em massa de AP em um par de AC redundante, obtenha o histórico completo de transições de VRRP, não apenas o estado final — um failover limpo único e um que oscila parecem idênticos se você só verificar onde a máquina de estados parou.
SINTOMAA reprodução em laboratório confirma a falha na topologia documentada, e o mesmo comando de reinício deixa de reproduzi-la depois que um link adicional é adicionado em cada lado.
CAUSAA topologia como implantada não tem um caminho redundante entre AC-mestre/S7706-em espera e AC-em espera/S7706-mestre — os hellos do VRRP têm exatamente uma rota para vazar durante um reinício, e essa rota passa diretamente pelo chassi que está sendo reiniciado.
CORREÇÃOAdicione um link cada entre AC-mestre—S7706-em espera e AC-em espera—S7706-mestre, com ambos os ACs e ambos os chassis S7706 conectados via agregação Eth-Trunk em cada lado. Verificado em laboratório: o mesmo comando reboot chassis não derruba mais nenhum AP depois que esses links são instalados.
Quatro mudanças, em ordem de quão diretamente cada uma aborda o que realmente aconteceu aqui.
Tiradas diretamente do campo — vale a pena ter uma resposta pronta para elas.
Esses eventos Down no log do em espera são sobre o estado de interface do par (o mestre), propagado ao em espera pelo link entre chassis — não o estado da porta física do próprio em espera. O caso de origem é explícito: o estado físico da própria interface do chassi em espera nunca mudou durante todo o incidente.
Não. Está documentado como um comando de emergência especificamente para quando não é possível cortar a energia do chassi no local, e se comporta de forma diferente — reiniciando as placas de interface uma de cada vez em vez de derrubar todo o tráfego de uma vez. A recomendação de origem é explícita: esse problema exato não ocorreria sob um reinício real por corte de energia.
O gatilho de exclusão em lote descrito aqui é específico de um par de AC ter seu estado VRRP oscilando Backup → Master → Backup → Master durante o reinício em etapas de um par. Um design com AC único não tem esse caminho de failover de forma alguma — mas perde a redundância por completo em vez disso, o que é um risco diferente, não mais seguro.
Não. reset-reason só registra reinícios de chassi e placa, não transições de estado do VRRP no par de AC. Um único evento de reset limpo do lado do switch é totalmente compatível com um failover oscilante acontecendo do lado do AC — essa transição simplesmente não aparece na saída desse comando.
A reprodução em laboratório após adicionar os links não reproduziu a queda de AP sob o mesmo comando de reinício, porque os links cruzados removem o único caminho pelo qual os hellos do VRRP podiam vazar. O comportamento subjacente de reinício em etapas, placa por placa, do reboot chassis N permanece inalterado — a correção remove o caminho de vazamento, não o sequenciamento interno do reinício.
Este post-mortem é construído a partir de um único caso documentado S7706 V200R024C00SPC500 no próprio manual de manutenção de switches de campus Huawei da série S. Diferentes modelos de chassi, versões de software ou fornecedores de AC WLAN podem usar temporizadores de detecção de failover e gatilhos de exclusão em lote diferentes — trate o mecanismo de rebaixar e depois repromover descrito aqui como um padrão que vale a pena verificar, não uma correspondência garantida para todo evento de queda em massa de AP.
Envie-nos a saída do seu display reset-reason e display ap offline-record all, além da topologia do par de AC — ajudaremos você a descobrir se é o mesmo mecanismo.