Um switch lento, ou que descarta pacotes Hello do OSPF e batimentos do VRRP que nunca deveria descartar, muitas vezes remonta a uma única coisa: uso de CPU travado alto por vários minutos seguidos. Esta é a ordem que encontra mais rápido a tarefa que realmente está consumindo a CPU, os dois casos de campo que explicam a maioria desses chamados, e as proteções que impedem que isso se repita.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
A primeira pergunta não é «por que a CPU está alta» — é «isso é realmente anormal», e essa é uma pergunta de janela de cinco minutos, não de um segundo.
Um breve pico de CPU por uma tarefa de software rotineira não é incomum e se resolve sozinho. O que vale a pena perseguir é um uso de CPU que permanece alto na média de cinco minutos mostrada em display cpu-usage — esse padrão quase sempre significa um evento anormal ou algo gerando um volume incomum de tráfego do plano de controle, e é exatamente o tipo de carga que começa a atropelar os pacotes Hello do OSPF e os batimentos do VRRP, momento em que um problema de CPU vira uma interrupção.
A seguir está a ordem que encontra a falha mais rápido: confirmar que a CPU está realmente anormalmente alta e ver qual tarefa está consumindo-a, os dois casos de campo — uma tempestade de pacotes TC (Topology Change) e um loop MSTP recalculando a topologia — que juntos explicam a maioria desses chamados, e as proteções que vale a pena já ter configuradas antes que isso aconteça de novo.
Três verificações em sequência — o número geral de uso, qual tarefa está consumindo, e se o CPCAR está descartando pacotes de protocolo — cobrem quase todos os casos reais.
Os rótulos do diagrama permanecem em inglês para clareza técnica.
Os dois casos de campo desta nota compartilham a mesma assinatura no passo 3: contadores TC (Topology Change) subindo em display stp tc-bpdu statistics. Isso não é coincidência — uma inundação de pacotes TC é, de longe, o motor único mais comum de carga persistente de CPU em um switch, seja vindo de portas de borda oscilando ou de um domínio MSTP recalculando sua topologia.
display cpu-usage informa duas coisas diferentes dependendo de como você o lê — o número geral, e o detalhamento por tarefa abaixo dele.
Um uso de CPU acima de aproximadamente 70%, ou um alarme hwEntityExtCpuUsageNotfication (que por padrão dispara acima de 90%), vale a pena investigar — mas só se isso se mantiver na média de cinco minutos, não em uma única amostra.
<HUAWEI> display cpu-usage
Slot: 1 CPU:0
CPU utilization statistics at 2024-09-20 15:00:20 868 ms
System CPU Using Percentage : 1%
Dataplane CPU Using Percentage : 0%
CPU utilization for five seconds: 1%, one minute: 1%, five minutes: 1%.
Max CPU Usage : 1%
Max CPU Usage Stat. Time : 2024-09-20 14:55:45 808 ms
State: Unoverload
Overload threshold: 90%, Overload clear threshold: 75%, Duration: 60s
------------------
CPU Usage Details
------------------------------------------------------------------------------
CPU Current FiveSec OneMin FiveMin Max MaxTime
------------------------------------------------------------------------------
cpu0 70% 56% 45% 30% 98% 2024-09-20 14:55:55
cpu1 70% 56% 45% 30% 98% 2024-09-20 14:55:55
------------------------------------------------------------------------------
// read the FiveMin column, not the instantaneous figure -- a spike that
// clears in seconds is not the fault you're chasingAs entradas de log CPU_USAGE_HIGH nomeiam diretamente as três principais tarefas — isso geralmente é mais rápido do que vasculhar manualmente a tabela de tarefas do display cpu-usage.
Switch %%01VOSCPU/4/CPU_USAGE_HIGH(l)[31]:The CPU is overloaded(CpuUsage=96%,
Threshold=95%), and the tasks with top three CPU occupancy are:
FTS total : 18%
SRMT total : 11%
SOCK total : 8%
Switch %%01VOSCPU/4/CPU_USAGE_HIGH(l)[60]:The CPU is overloaded(CpuUsage=100%,
Threshold=95%), and the tasks with top three CPU occupancy are:
PPI total : 41%
SRMT total : 10%
FTS total : 8%
<HUAWEI> display cpu-defend statistics packet-type arp all
Statistics on slot 4:
-------------------------------------------------------------------------------
Packet Type Pass(Bytes) Drop(Bytes) Pass(Packets) Drop(Packets)
-------------------------------------------------------------------------------
arp 79880066214 2581617736 1174644777 37950869
-------------------------------------------------------------------------------
// Drop(Packets) growing -> CPU is being flooded with this packet type,
// not simply "broken" on its own
<HUAWEI> display stp tc-bpdu statistics
-------------------------- STP TC/TCN information --------------------------
MSTID Port TC(Send/Receive/Discard) TCN(Send/Receive/Discard)
0 10GE1/0/1 3/2/0 0/0/0
1 10GE1/0/3 14/9/0 -/-/-
// TC counters climbing across ports -> loop or topology-change stormAmbos vêm dos mesmos arquivos de casos de campo do fabricante, compartilham a mesma assinatura de tempestade TC, e têm a mesma correção de dois comandos.
SINTOMAO gerenciamento de rede mostra a utilização de CPU subindo e permanecendo alta; o buffer de log se enche de entradas CPU_USAGE_HIGH nomeando FTS, SRMT e PPI como os principais consumidores, junto com entradas CPCAR_DROP_MPU para arp-miss, arp-reply e arp-request todas excedendo seu limite de taxa ao mesmo tempo.
CAUSAVerificando display stp tc-bpdu statistics, o número de pacotes TC recebidos sobe continuamente em várias portas. Cada pacote TC dispara uma limpeza da tabela MAC e um ciclo de reaprendizado de ARP; enquanto os pacotes TC continuam chegando, o switch continua reaprendendo ARP para uma tabela grande, gera ele mesmo um grande volume de tráfego arp-miss e arp-request, e a inundação de arp-reply resultante dos hosts finais excede o limite de taxa do CPCAR e é parcialmente descartada — o que envelhece as entradas ARP e reinicia o ciclo. Com a CPU tão ocupada processando esse churn de ARP, os pacotes Hello do OSPF e os batimentos do VRRP deixam de ser atendidos a tempo e esses protocolos também começam a oscilar.
SOLUÇÃOConfigure stp tc-protection globalmente para que uma limpeza de tabela disparada por TC aconteça no máximo uma vez a cada janela de 2 segundos em vez de a cada pacote TC, depois configure arp topology-change disable junto com mac-address update arp enable para que uma mudança de topologia atualize as entradas ARP rastreando a interface de saída da tabela MAC em vez de reaprender o ARP do zero por completo.
<HUAWEI> display stp tc-bpdu statistics
-------------------------- STP TC/TCN information --------------------------
MSTID Port TC(Send/Receive/Discard) TCN(Send/Receive/Discard)
0 10GE1/0/1 3/2/0 0/0/0
1 10GE1/0/3 14/9/0 -/-/-
// TC counts still rising on the next check -> a genuine TC storm, not one-off
[HUAWEI] stp tc-protection
[HUAWEI] arp topology-change disable
[HUAWEI] mac-address update arp enableSINTOMAA utilização de CPU está alta em toda uma rede em anel MSTP, e display interface brief mostra uma ou mais interfaces funcionando bem acima da utilização normal de largura de banda em uma direção.
CAUSAEm um anel MSTP, algum evento — muitas vezes difícil de atribuir a uma única causa raiz apenas pelo sintoma de CPU — continua disparando o recálculo de topologia. Cada recálculo transmite uma nova rodada de BPDUs de mudança de topologia pelo anel, e o switch gasta ciclos de CPU recalculando o estado da árvore geradora a cada chegada, o que é confirmado por display stp tc-bpdu statistics mostrando pacotes TC recebidos em volume em várias portas.
SOLUÇÃOEm vez de perseguir primeiro o gatilho exato dentro do anel MSTP, aplique os mesmos dois comandos do caso de tempestade TC — arp topology-change disable e mac-address update arp enable — para impedir que cada mudança de topologia force um reaprendizado completo de ARP. No caso de campo, isso derrubou o uso de CPU imediatamente; use display interface brief depois para confirmar que a utilização de largura de banda também voltou ao normal nas portas afetadas.
<HUAWEI> display interface brief
Interface PHY Protocol InUti OutUti inErrors outErrors
GE4/0/1 up up 0.72% 81% 0 0
GE4/0/2 up up 81% 0.73% 2 0
// one direction pinned high on a ring port -- consistent with a loop
<HUAWEI> display stp tc-bpdu statistics
-------------------------- STP TC/TCN information --------------------------
MSTID Port TC(Send/Receive) TCN(Send/Receive)
0 GE4/0/1 3/2 0/0
0 GE1/0/10 14/9 0/0
[HUAWEI] arp topology-change disable
[HUAWEI] mac-address update arp enable
// CPU usage dropped immediately in the field case this is drawn fromSINTOMAA CPU permanece alta, mas display cpu-defend statistics para os protocolos óbvios não mostra nada incomum, e não há nenhuma interface oscilando visivelmente.
CAUSAUm pico de tarefa de software de curta duração não é a mesma falha que uma sobrecarga sustentada genuína — se a coluna FiveMin em display cpu-usage não estiver realmente elevada, perseguir contadores de CPCAR ou estatísticas de TC está procurando no lugar completamente errado. Tratar cada pico momentâneo como um incidente desperdiça tempo que deveria ir primeiro para confirmar a persistência.
SOLUÇÃOReverifique a média FiveMin em uma janela mais longa antes de fazer qualquer outra coisa. Se genuinamente não for persistente, a CPU não é a falha — olhe para o sintoma que realmente trouxe você aqui (resposta lenta, perda de pacotes, um evento de interface) como sua própria investigação em vez de forçá-lo na árvore de falhas de CPU alta.
SINTOMAdisplay cpu-defend statistics mostra contagens altas de Drop(Packets) para um protocolo que não tem nada a ver com STP ou ARP — vrrp, por exemplo — enquanto os contadores TC em display stp tc-bpdu statistics permanecem estáveis.
CAUSAO CPCAR protege a CPU por tipo de protocolo, e um contador TC estável descarta os dois casos acima impulsionados por loop. Uma inundação de VRRP ou similar pode vir de um vizinho mal configurado, um ataque genuíno, ou um dispositivo em algum lugar do segmento com mau funcionamento enviando a uma taxa anormal — a correção aqui é específica do protocolo, não a remediação de ARP/TC usada para os casos de loop.
SOLUÇÃOIdentifique a interface de origem que gera o tráfego de protocolo sinalizado (display cpu-defend statistics informa por slot, o que restringe o ponto de entrada), depois investigue esse vizinho ou dispositivo diretamente em vez de aplicar a remediação de tempestade TC, que não ajudará em uma inundação não impulsionada por loop.
Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.
Um breve pico de uma tarefa de software comum que se resolve em segundos é comportamento normal do switch e não vale a pena perseguir. O que importa é a coluna FiveMin em display cpu-usage — se a média de cinco minutos estiver persistentemente elevada, esse é o padrão consistente com um evento anormal ou um volume incomum de tráfego do plano de controle, e vale a pena investigar com os passos desta nota. Trate o número instantâneo como ruído e a média de cinco minutos como sinal.
Sim. Ambos os casos de campo nesta nota mostram a CPU subindo bem antes de qualquer coisa tão óbvia quanto uma interface oscilando aparecer — o indício revelador é os contadores de pacotes TC em display stp tc-bpdu statistics subindo constantemente, não um evento de link visível. Verifique esse comando antes de descartar loops.
Ele limita a frequência com que uma limpeza de tabela MAC/ARP disparada por TC pode acontecer — no máximo uma vez a cada 2 segundos, não importa quantos pacotes TC cheguem nessa janela. A contrapartida é um atraso muito pequeno na rapidez com que a rede reage a uma mudança de topologia genuína, o que na prática é amplamente superado por não deixar uma tempestade TC limpar repetidamente tabelas que não precisa. É prática padrão deixá-lo configurado permanentemente em vez de apenas durante um incidente.
Uma mudança de topologia geralmente significa que a interface de saída real de um endereço MAC pode ter mudado, então o comportamento padrão é conservador: limpar as entradas afetadas e reaprendê-las para que o encaminhamento permaneça correto. Esse padrão é exatamente certo para uma mudança de topologia genuína e pontual, e exatamente errado quando pacotes TC chegam continuamente — por isso arp topology-change disable combinado com mac-address update arp enable existe como a alternativa mais cirúrgica: rastrear diretamente a mudança de interface da tabela MAC em vez de limpar e reaprender toda a tabela ARP a cada vez.
FTS e SRMT aparecendo juntos no topo, junto com descartes de CPCAR em tipos de pacotes relacionados a arp e contadores TC subindo, é a assinatura que ambos os casos de campo desta nota mostram. Se em vez disso você vir um único protocolo não relacionado (digamos vrrp) dominando os descartes de CPCAR com contadores TC estáveis, isso aponta para uma inundação específica de protocolo em vez de um loop, e a remediação de ARP/TC aqui não será a solução — investigue diretamente a interface de origem desse protocolo.
Esta nota se baseia no modelo de classificação de falhas de CPU do switch Huawei série S e seus comandos display cpu-usage / cpu-defend statistics / stp tc-bpdu statistics, além dos casos de campo por trás deles. Se o seu switch for de outro fabricante, os comandos exatos mudam, mas a ordem de diagnóstico subjacente — confirmar persistência, encontrar a tarefa, verificar descartes de CPCAR, verificar contadores TC — se aplica diretamente. Para um passo a passo completo de detecção de loop de Camada 2 e como quebrar um loop com segurança depois de confirmá-lo, veja nossa nota dedicada de solução de problemas de tempestade de loop; esta nota cobre o lado do sintoma de CPU, não a análise geral de topologia de loop.
Envie-nos sua saída de display cpu-usage mais as entradas de log CPU_USAGE_HIGH, e ajudamos você a interpretar qual tarefa e qual tipo de pacote está realmente impulsionando isso.