Em um campus WAC, todos os APs Fit sob um mesmo switch de acesso caem ao mesmo tempo — sem cabo desconectado, sem queda de energia, sem nada de anormal no próprio AP. A causa real está duas camadas adiante: uma mudança de topologia STP em qualquer ponto do domínio de camada 2 inunda a rede com TC-BPDU, o switch que atua como gateway dos APs envelhece e limpa sua tabela ARP em resposta, e cada AP sob ele perde o gateway e é declarado offline em massa. Esta é a cadeia, os comandos que confirmam cada elo, e a correção de duas linhas.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Na verdade não há nada quebrado no AP — ele é apenas o último elo de uma cadeia que começa em outro lugar completamente diferente na malha de comutação.
O chamado sempre parece igual: um campus gerenciado por WAC relata que um lote de APs Fit — às vezes todos os conectados sob um mesmo switch de acesso — ficou offline de uma vez, sem nenhum evento de energia correlacionado, sem cabo desconectado, sem mudança de firmware. O instinto é começar a diagnosticar os próprios APs: verificar a alimentação, o uplink, a AC. Quase nunca é aí que a falha realmente está.
A seguir está a cadeia de causa-raiz por trás da versão mais comum dessa falha, os comandos que confirmam cada elo dessa cadeia em vez de apenas o sintoma final, as duas linhas de configuração que a fecham, e as perguntas de campo que vale a pena ter respondidas antes da próxima ocorrência.
Três pontos de partida diferentes produzem o mesmo sintoma no lado do AP — apenas um deles vale a pena rastrear de volta pela malha de comutação.
Colocar a falha nessa árvore antes de mexer nos próprios APs indica se você está diante de um problema isolado de hardware, uma sobrecarga de CPU, ou a cadeia TC-BPDU da qual esta nota realmente trata.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Os passos 1 e 2 são um comportamento STP normal e saudável — uma notificação de mudança de topologia deve se propagar. A falha está inteiramente no passo 3: a tabela ARP deste switch em particular não deveria ser tratada como suspeita só porque em outro ponto do domínio uma porta subiu ou caiu.
Quatro verificações, em ordem — cada uma descarta um ramo diferente da árvore antes de você se comprometer com a explicação do TC-BPDU.
O ramo em que você está depende inteiramente de isso ser um único AP ou o equivalente a um switch inteiro.
Antes de culpar especificamente o TC-BPDU, descarte a outra causa geral: excesso de pacotes chegando à 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 é a verificação que realmente confirma a cadeia — execute-a no switch que está diretamente a montante dos APs afetados e atua como seu gateway.
<Switch> display stp topology-change //查看拓扑变化
<Switch> display stp tc-bpdu statistics //查看端口TC报文收发计数Duas linhas, e precisam ser aplicadas juntas — apenas uma delas é só uma correção parcial.
<Switch> system-view
[Switch] mac-address update arp //开启MAC刷新ARP功能，即MAC地址的出接口变化时，通知更新ARP表项的出接口
[Switch] arp topology-change disable //关闭设备响应TC报文的功能，即当设备收到TC报文时，不对ARP表项进行老化或删除A cadeia acima é o mecanismo — estas são as formas como os engenheiros realmente ficam presos nisso em campo.
SINTOMATodos os APs sob um mesmo switch caem juntos, com energia limpa e uplink intacto em cada um deles.
CAUSAO AP na verdade nunca falhou. Ele simplesmente perdeu sua entrada ARP para o gateway ou a AC, porque o switch atrás do qual ele está envelheceu essa entrada em resposta a um TC-BPDU recebido — a falha está inteiramente a montante, no tratamento da tabela ARP do switch, não no AP ou em seu rádio.
SOLUÇÃOPare de diagnosticar os APs individualmente assim que mais de um sob o mesmo switch estiver afetado — vá direto para display stp topology-change e display stp tc-bpdu statistics no switch a montante.
SINTOMAO próprio uplink e as portas do switch gateway dos APs nunca oscilaram, e mesmo assim sua tabela ARP se esvaziou.
CAUSAUma notificação de mudança de topologia se propaga para todos os switches do mesmo domínio spanning-tree, não apenas para o switch onde a porta realmente oscilou. Se esse switch ainda responde ao TC-BPDU envelhecendo sua tabela ARP, um evento de link do outro lado do campus pode esvaziar a tabela ARP deste switch e derrubar todos os APs atrás dele.
SOLUÇÃONão restrinja a busca pela causa-raiz aos próprios uplinks do switch gateway dos APs — verifique mudanças de topologia em qualquer ponto do mesmo domínio STP por volta do momento em que os APs caíram.
SINTOMAMesmo sintoma aparente — um lote de APs offline de uma vez — mas a AC ou o switch core foi reiniciado, resetado ou passou por failover pouco antes disso acontecer.
CAUSAUm evento de failover de chassi na própria AC é um mecanismo completamente diferente — uma sequência de rebaixamento e depois repromoção na unidade controladora que exclui registros de AP em massa — e deixa seu próprio rastro forense no motivo do reset e nos registros de offline dos APs, não em display stp tc-bpdu statistics.
SOLUÇÃOVerifique se o chassi AC/core teve um reboot ou failover de slot na mesma janela antes de presumir que se trata de uma tempestade TC-BPDU; se teve, o mecanismo de failover de chassi é a explicação mais provável.
SINTOMAQuedas de AP igualmente abruptas, mas dessa vez acompanhadas de desempenho geralmente ruim, CPU alta em todo lugar, e endereços MAC oscilando entre portas por toda a malha de comutação.
CAUSAUma limpeza de ARP impulsionada por TC-BPDU pode ocorrer a partir de uma única mudança de topologia breve e por outro lado saudável — não requer um loop de camada 2 real. Um loop genuíno produz sua própria assinatura muito mais ampla: inundação de broadcast, oscilação de MAC nas portas, e congestionamento em toda a rede, não apenas um evento de queda de AP confinado a um switch gateway.
SOLUÇÃOSe os sintomas forem mais amplos do que apenas quedas de AP — tempestades de broadcast, tabelas MAC oscilando, lentidão generalizada — siga o processo de localização de loop em vez da cadeia TC-BPDU/ARP desta nota.
SINTOMAAs quedas de AP se tornam menos frequentes depois de aplicar uma correção, mas ainda ocorrem ocasionalmente após uma mudança de topologia em outro lugar.
CAUSAmac-address update arp apenas faz as entradas ARP atualizarem mais rápido quando a interface de saída de um MAC muda — não impede que o switch envelheça ou exclua entradas ARP em resposta a um TC-BPDU. Configurá-lo sozinho ainda deixa uma janela em que as entradas podem ser apagadas.
SOLUÇÃOConfigure os dois comandos juntos: mac-address update arp para convergência mais rápida, e arp topology-change disable para impedir completamente que a tabela ARP seja afetada pelo TC-BPDU.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Verifique primeiro o motivo do reset e o tempo de atividade do próprio chassi AC/core. Se ele reiniciou, resetou ou passou por failover pouco antes dos APs caírem, trabalhe esse mecanismo — o rastro do reboot explica diretamente. Se a AC/core não foi tocada e apenas o switch de acesso intermediário mostra uma mudança de topologia recente, essa cadeia TC-BPDU é a explicação mais provável.
Quase qualquer coisa que faça uma porta subir ou cair no mesmo domínio spanning-tree: um reboot de dispositivo, um cabo reconectado, uma porta oscilando intermitentemente, até uma mudança de manutenção planejada em um switch não relacionado. O ponto dessa cadeia de falha é que a mudança não precisa acontecer perto dos APs que acabam caindo.
Sim, para o switch que atua como gateway dos APs — isso impede que eventos de mudança de topologia normais e saudáveis apaguem entradas ARP que ainda são válidas. Deve ser combinado com mac-address update arp para que as entradas ainda sejam atualizadas corretamente nas ocasiões em que a interface de saída realmente muda, que é o cenário que o envelhecimento de ARP por TC-BPDU originalmente deveria tratar.
Porque o TC-BPDU se propaga para todo o domínio spanning-tree, não apenas para o switch onde a oscilação ocorreu. Qualquer switch que ainda envelheça sua tabela ARP ao receber um TC-BPDU reage da mesma forma, independentemente de onde a mudança de topologia realmente se originou — exatamente por isso a correção precisa ser aplicada no switch gateway dos APs, não rastreada até a porta que oscilou.
Estabeleça uma linha de base de display stp tc-bpdu statistics em seus switches gateway de APs e observe contagens subindo fora das janelas de manutenção planejadas — uma contagem crescente ali, antes de qualquer alarme de AP offline, é o sinal mais precoce de que essa cadeia está começando. Combinar isso com verificações periódicas de display cpu-defend statistics também detecta o ramo de sobrecarga de CPU antes que ele se agrave.
Esta nota é construída em torno do modelo de classificação de falhas WAC/Fit-AP da Huawei e dos comandos display stp / display cpu-defend por trás dele, além dos casos de campo que os motivam. Ela cobre especificamente a cadeia de limpeza de ARP impulsionada por TC-BPDU — não substitui uma investigação completa de loop de camada 2 quando os sintomas são mais amplos do que um evento de queda de AP, e não cobre failover de chassi da AC ou falhas de hardware, que têm seus próprios caminhos de diagnóstico separados.
Diga-nos se é o equivalente a um switch ou o campus inteiro, além da saída de display stp tc-bpdu statistics do switch gateway dos APs, e ajudaremos você a interpretá-la.