Un switch lento, o que descarta paquetes Hello de OSPF y latidos de VRRP que nunca debería descartar, a menudo se remonta a una sola cosa: uso de CPU fijado alto durante varios minutos seguidos. Este es el orden que encuentra más rápido la tarea que realmente está consumiendo la CPU, los dos casos de campo que explican la mayoría de estos tickets, y las protecciones que evitan que vuelva a ocurrir.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
La primera pregunta no es «por qué la CPU está alta» — es «esto es realmente anormal», y eso se evalúa en una ventana de cinco minutos, no en un segundo.
Un breve pico de CPU por una tarea de software rutinaria no es inusual y se despeja solo. Lo que vale la pena perseguir es un uso de CPU que se mantiene alto en el promedio de cinco minutos que muestra display cpu-usage — ese patrón casi siempre significa un evento anormal o algo que genera un volumen inusual de tráfico del plano de control, y es exactamente el tipo de carga que empieza a desplazar los paquetes Hello de OSPF y los latidos de VRRP, momento en el que un problema de CPU se convierte en una interrupción.
A continuación, el orden que encuentra la falla más rápido: confirmar que la CPU realmente está anormalmente alta y ver qué tarea la está consumiendo, los dos casos de campo — una tormenta de paquetes TC (Topology Change) y un bucle MSTP recalculando la topología — que entre ambos explican la mayoría de estos tickets, y las protecciones que vale la pena tener configuradas antes de que vuelva a suceder.
Tres comprobaciones en secuencia — el número de uso general, qué tarea lo está consumiendo, y si el CPCAR está descartando paquetes de protocolo — cubren casi todos los casos reales.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Los dos casos de campo de esta nota comparten la misma firma en el paso 3: los contadores TC (Topology Change) subiendo en display stp tc-bpdu statistics. Eso no es coincidencia — una inundación de paquetes TC es, con diferencia, el motor único más común de una carga de CPU persistente en un switch, ya venga de puertos de borde que oscilan o de un dominio MSTP recalculando su topología.
display cpu-usage le dice dos cosas distintas según cómo lo lea — el número general, y el desglose por tarea debajo de él.
Un uso de CPU superior a aproximadamente el 70%, o una alarma hwEntityExtCpuUsageNotfication (que por defecto se dispara por encima del 90%), vale la pena investigarlo — pero solo si se mantiene en el promedio de cinco minutos, no en una sola muestra.
<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 chasingLas entradas de registro CPU_USAGE_HIGH nombran directamente las tres tareas principales — eso suele ser más rápido que revisar manualmente la tabla de tareas de 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 provienen de los mismos archivos de casos de campo del fabricante, comparten la misma firma de tormenta TC, y tienen la misma solución de dos comandos.
SÍNTOMALa gestión de red muestra la utilización de CPU subiendo y manteniéndose alta; el búfer de registro se llena de entradas CPU_USAGE_HIGH que nombran a FTS, SRMT y PPI como los principales consumidores, junto con entradas CPCAR_DROP_MPU para arp-miss, arp-reply y arp-request superando todas su límite de tasa al mismo tiempo.
CAUSAAl revisar display stp tc-bpdu statistics se ve el recuento de paquetes TC recibidos subiendo continuamente en varios puertos. Cada paquete TC dispara una purga de la tabla MAC y un ciclo de reaprendizaje de ARP; mientras sigan llegando paquetes TC, el switch sigue reaprendiendo ARP para una tabla grande, genera él mismo un gran volumen de tráfico arp-miss y arp-request, y la inundación de arp-reply resultante de los hosts finales supera el límite de tasa del CPCAR y se descarta parcialmente — lo que envejece las entradas ARP y reinicia el ciclo. Con la CPU tan ocupada procesando este ARP churn, los paquetes Hello de OSPF y los latidos de VRRP dejan de atenderse a tiempo y esos protocolos también empiezan a fluctuar.
SOLUCIÓNConfigure stp tc-protection globalmente para que una purga de tabla activada por TC ocurra como máximo una vez cada ventana de 2 segundos en lugar de en cada paquete TC, luego configure arp topology-change disable junto con mac-address update arp enable para que un cambio de topología refresque las entradas ARP siguiendo la interfaz de salida de la tabla MAC en lugar de reaprender el ARP 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 enableSÍNTOMALa utilización de CPU es alta en toda una red en anillo MSTP, y display interface brief muestra una o más interfaces funcionando muy por encima de la utilización normal de ancho de banda en una dirección.
CAUSAEn un anillo MSTP, algún evento — a menudo difícil de atribuir a una única causa raíz solo a partir del síntoma de la CPU — sigue disparando el recálculo de topología. Cada recálculo difunde una nueva ronda de BPDU de cambio de topología por el anillo, y el switch gasta ciclos de CPU recalculando el estado del árbol de expansión cada vez que llega uno, lo cual se confirma con display stp tc-bpdu statistics mostrando paquetes TC recibidos en volumen en varios puertos.
SOLUCIÓNEn lugar de perseguir primero el disparador exacto dentro del anillo MSTP, aplique los mismos dos comandos que el caso de tormenta TC — arp topology-change disable y mac-address update arp enable — para evitar que cada cambio de topología fuerce un reaprendizaje completo de ARP. En el caso de campo esto bajó el uso de CPU de inmediato; use display interface brief después para confirmar que la utilización de ancho de banda también volvió a la normalidad en los puertos afectados.
<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 fromSÍNTOMALa CPU se mantiene alta pero display cpu-defend statistics para los protocolos obvios no muestra nada inusual, y no hay ninguna interfaz oscilando visiblemente.
CAUSAUn pico de tarea de software de corta duración no es la misma falla que una sobrecarga sostenida genuina — si la columna FiveMin en display cpu-usage no está realmente elevada, perseguir contadores de CPCAR o estadísticas de TC está buscando en el lugar completamente equivocado. Tratar cada pico momentáneo como un incidente desperdicia tiempo que debería dedicarse primero a confirmar la persistencia.
SOLUCIÓNVuelva a comprobar el promedio FiveMin en una ventana más larga antes de hacer cualquier otra cosa. Si genuinamente no es persistente, la CPU no es la falla — mire el síntoma que realmente lo trajo aquí (respuesta lenta, pérdida de paquetes, un evento de interfaz) como su propia investigación en lugar de forzarlo en el árbol de fallas de CPU alta.
SÍNTOMAdisplay cpu-defend statistics muestra recuentos altos de Drop(Packets) para un protocolo que no tiene nada que ver con STP o ARP — vrrp, por ejemplo — mientras los contadores TC en display stp tc-bpdu statistics se mantienen planos.
CAUSAEl CPCAR protege la CPU por tipo de protocolo, y un contador TC estable descarta los dos casos anteriores impulsados por bucles. Una inundación de VRRP o similar puede provenir de un vecino mal configurado, un ataque genuino, o un dispositivo en algún lugar del segmento que funciona mal y envía a una tasa anormal — la solución aquí es específica del protocolo, no la corrección de ARP/TC usada para los casos de bucle.
SOLUCIÓNIdentifique la interfaz de origen que genera el tráfico de protocolo marcado (display cpu-defend statistics informa por slot, lo que reduce el punto de entrada), luego investigue ese vecino o dispositivo directamente en lugar de aplicar la corrección de tormenta TC, que no ayudará con una inundación no impulsada por bucle.
Sacadas directamente del terreno — las que vale la pena tener una respuesta lista.
Un breve pico de una tarea de software ordinaria que se despeja en segundos es un comportamiento normal del switch y no vale la pena perseguirlo. Lo que importa es la columna FiveMin en display cpu-usage — si el promedio de cinco minutos está persistentemente elevado, ese es el patrón consistente con un evento anormal o un volumen inusual de tráfico del plano de control, y vale la pena investigarlo con los pasos de esta nota. Trate el número instantáneo como ruido y el promedio de cinco minutos como señal.
Sí. Ambos casos de campo en esta nota muestran la CPU subiendo mucho antes de que aparezca algo tan obvio como una interfaz rebotando — la pista delatora es que los contadores de paquetes TC en display stp tc-bpdu statistics suben de forma constante, no un evento de enlace visible. Revise ese comando antes de descartar los bucles.
Limita la frecuencia con la que puede ocurrir una purga de tabla MAC/ARP activada por TC — como máximo una vez cada 2 segundos, sin importar cuántos paquetes TC lleguen en esa ventana. La contrapartida es un retraso muy pequeño en la rapidez con que la red reacciona a un cambio de topología genuino, lo cual en la práctica se ve ampliamente superado por no dejar que una tormenta TC borre repetidamente tablas que no necesita. Es práctica estándar dejarlo configurado permanentemente en lugar de solo durante un incidente.
Un cambio de topología generalmente significa que la interfaz de salida real de una dirección MAC puede haber cambiado, por lo que el comportamiento predeterminado es conservador: borrar las entradas afectadas y reaprenderlas para que el reenvío se mantenga correcto. Ese valor predeterminado es exactamente correcto para un cambio de topología genuino y puntual, y exactamente incorrecto cuando los paquetes TC llegan continuamente — por eso existe arp topology-change disable junto con mac-address update arp enable como alternativa más quirúrgica: seguir directamente el cambio de interfaz de la tabla MAC en lugar de borrar y reaprender toda la tabla ARP cada vez.
FTS y SRMT apareciendo juntos en la cima, junto con descartes de CPCAR en tipos de paquetes relacionados con arp y contadores TC en aumento, es la firma que muestran ambos casos de campo de esta nota. Si en cambio ve un solo protocolo no relacionado (digamos vrrp) dominando los descartes de CPCAR con contadores TC planos, eso apunta a una inundación específica de protocolo en lugar de un bucle, y la corrección de ARP/TC de aquí no será la solución — investigue directamente la interfaz de origen de ese protocolo.
Esta nota se basa en el modelo de clasificación de fallas de CPU del switch Huawei serie S y sus comandos display cpu-usage / cpu-defend statistics / stp tc-bpdu statistics, además de los casos de campo que los respaldan. Si su switch es de otro fabricante, los comandos exactos cambian, pero el orden de diagnóstico subyacente — confirmar persistencia, encontrar la tarea, verificar descartes de CPCAR, verificar contadores TC — se traslada directamente. Para un recorrido completo de la detección de bucles de Capa 2 y romper un bucle de forma segura una vez confirmado, vea nuestra nota dedicada a tormentas de bucle; esta nota cubre el lado del síntoma de CPU, no el análisis general de topología de bucles.
Envíenos su salida de display cpu-usage más las entradas de registro CPU_USAGE_HIGH, y le ayudaremos a leer qué tarea y qué tipo de paquete lo está impulsando realmente.