Un commutateur lent, ou qui perd des paquets Hello OSPF et des battements de cœur VRRP qu'il ne devrait jamais perdre, se ramène souvent à une seule chose : une utilisation CPU restée élevée pendant plusieurs minutes. Voici l'ordre qui trouve le plus vite la tâche qui consomme réellement le CPU, les deux cas de terrain qui expliquent la plupart de ces tickets, et les protections qui empêchent que cela se reproduise.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
La première question n'est pas « pourquoi le CPU est-il élevé » — c'est « est-ce vraiment anormal », et c'est une question qui se pose sur une fenêtre de cinq minutes, pas sur une seconde.
Un bref pic de CPU dû à une tâche logicielle courante n'a rien d'inhabituel et se résorbe de lui-même. Ce qui mérite d'être traqué, c'est une utilisation CPU qui reste élevée sur la moyenne de cinq minutes affichée par display cpu-usage — ce schéma signifie presque toujours un événement anormal ou un trafic de plan de contrôle d'un volume inhabituel, exactement le genre de charge qui commence à évincer les paquets Hello OSPF et les battements de cœur VRRP, moment où un problème de CPU se transforme en panne.
Voici l'ordre qui trouve la panne le plus vite : confirmer que le CPU est réellement anormalement élevé et voir quelle tâche le consomme, les deux cas de terrain — une tempête de paquets TC (Topology Change) et une boucle MSTP recalculant sa topologie — qui expliquent à eux deux la plupart de ces tickets, et les protections qu'il vaut la peine d'avoir déjà configurées avant que cela ne se reproduise.
Trois vérifications dans l'ordre — le chiffre d'utilisation global, quelle tâche le consomme, et si le CPCAR rejette des paquets de protocole — couvrent presque tous les cas réels.
Les légendes du schéma restent en anglais pour la clarté technique.
Les deux cas de terrain de cette note partagent la même signature à l'étape 3 : les compteurs TC (Topology Change) qui grimpent sur display stp tc-bpdu statistics. Ce n'est pas une coïncidence — une inondation de paquets TC est de loin le facteur unique le plus courant d'une charge CPU persistante sur un commutateur, qu'elle provienne de ports d'extrémité qui oscillent ou d'un domaine MSTP recalculant sa topologie.
display cpu-usage vous donne deux informations différentes selon la façon dont vous le lisez — le chiffre global, et la répartition par tâche en dessous.
Une utilisation CPU supérieure à environ 70 %, ou une alarme hwEntityExtCpuUsageNotfication (qui se déclenche par défaut au-delà de 90 %), mérite d'être examinée — mais seulement si cela se maintient sur la moyenne de cinq minutes, pas sur un seul échantillon.
<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 chasingLes entrées de journal CPU_USAGE_HIGH nomment directement les trois tâches principales — c'est généralement plus rapide que de fouiller manuellement la table des tâches 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 stormLes deux proviennent des mêmes dossiers de cas de terrain du fabricant, partagent la même signature de tempête TC, et ont la même correction en deux commandes.
SYMPTÔMELa gestion réseau montre l'utilisation CPU grimper et rester élevée ; le tampon de journal se remplit d'entrées CPU_USAGE_HIGH nommant FTS, SRMT et PPI comme principaux consommateurs, aux côtés d'entrées CPCAR_DROP_MPU pour arp-miss, arp-reply et arp-request dépassant tous leur limite de débit en même temps.
CAUSELa vérification de display stp tc-bpdu statistics montre le nombre de paquets TC reçus grimper continuellement sur les ports. Chaque paquet TC déclenche une purge de la table MAC et un cycle de réapprentissage ARP ; tant que les paquets TC continuent d'arriver, le commutateur continue de réapprendre l'ARP pour une grande table, génère lui-même un grand volume de trafic arp-miss et arp-request, et l'inondation d'arp-reply qui en résulte de la part des hôtes finaux dépasse la limite de débit du CPCAR et est partiellement rejetée — ce qui fait vieillir les entrées ARP et relance le cycle. Le CPU étant si occupé à traiter ce brassage ARP, les paquets Hello OSPF et les battements de cœur VRRP ne sont plus traités à temps et ces protocoles se mettent aussi à osciller.
SOLUTIONConfigurez stp tc-protection globalement pour qu'une purge de table déclenchée par TC se produise au plus une fois par fenêtre de 2 secondes au lieu de sur chaque paquet TC, puis configurez arp topology-change disable avec mac-address update arp enable pour qu'un changement de topologie rafraîchisse les entrées ARP en suivant l'interface de sortie de la table MAC au lieu de réapprendre l'ARP intégralement.
<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 enableSYMPTÔMEL'utilisation CPU est élevée sur tout un réseau en anneau MSTP, et display interface brief montre une ou plusieurs interfaces fonctionnant bien au-dessus de l'utilisation de bande passante normale dans une direction.
CAUSEDans un anneau MSTP, un événement — souvent difficile à rattacher à une cause unique à partir du seul symptôme CPU — continue de déclencher le recalcul de la topologie. Chaque recalcul diffuse une nouvelle salve de BPDU de changement de topologie sur l'anneau, et le commutateur consacre des cycles CPU à recalculer l'état du spanning tree à chaque arrivée, ce que confirme display stp tc-bpdu statistics montrant des paquets TC reçus en volume sur plusieurs ports.
SOLUTIONPlutôt que de d'abord traquer le déclencheur exact à l'intérieur de l'anneau MSTP, appliquez les deux mêmes commandes que le cas de tempête TC — arp topology-change disable et mac-address update arp enable — pour empêcher chaque changement de topologie de forcer un réapprentissage ARP complet. Dans le cas de terrain, cela a fait chuter immédiatement l'utilisation CPU ; utilisez ensuite display interface brief pour confirmer que l'utilisation de bande passante est également revenue à la normale sur les ports affectés.
<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 fromSYMPTÔMELe CPU reste élevé mais display cpu-defend statistics pour les protocoles évidents ne montre rien d'inhabituel, et aucune interface n'oscille visiblement.
CAUSEUn pic de tâche logicielle de courte durée n'est pas la même panne qu'une véritable surcharge soutenue — si la colonne FiveMin de display cpu-usage n'est pas réellement élevée, traquer les compteurs CPCAR ou les statistiques TC revient à chercher au mauvais endroit. Traiter chaque pic momentané comme un incident gaspille un temps qui devrait d'abord servir à confirmer la persistance.
SOLUTIONRevérifiez la moyenne FiveMin sur une fenêtre plus longue avant de faire quoi que ce soit d'autre. Si elle n'est vraiment pas persistante, le CPU n'est pas la panne — examinez le symptôme qui vous a réellement amené ici (réponse lente, perte de paquets, événement d'interface) comme sa propre enquête plutôt que de le forcer dans l'arbre de panne du CPU élevé.
SYMPTÔMEdisplay cpu-defend statistics montre des rejets Drop(Packets) importants pour un protocole qui n'a rien à voir avec STP ou ARP — vrrp, par exemple — tandis que les compteurs TC sur display stp tc-bpdu statistics restent stables.
CAUSELe CPCAR protège le CPU par type de protocole, et un compteur TC stable exclut les deux cas ci-dessus pilotés par une boucle. Une inondation VRRP ou similaire peut provenir d'un voisin mal configuré, d'une véritable attaque, ou d'un appareil quelque part sur le segment qui dysfonctionne et envoie à un débit anormal — la correction ici est spécifique au protocole, pas la remédiation ARP/TC utilisée pour les cas de boucle.
SOLUTIONIdentifiez l'interface source générant le trafic de protocole signalé (display cpu-defend statistics rapporte par slot, ce qui restreint le point d'entrée), puis enquêtez directement sur ce voisin ou cet appareil plutôt que d'appliquer la remédiation de tempête TC, qui n'aidera pas une inondation non liée à une boucle.
Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Un bref pic dû à une tâche logicielle ordinaire qui se résorbe en quelques secondes est un comportement normal du commutateur et ne mérite pas d'être traqué. Ce qui compte, c'est la colonne FiveMin de display cpu-usage — si la moyenne de cinq minutes est durablement élevée, ce schéma correspond à un événement anormal ou à un volume inhabituel de trafic de plan de contrôle, et cela vaut la peine d'être étudié avec les étapes de cette note. Considérez le chiffre instantané comme du bruit et la moyenne de cinq minutes comme le signal.
Oui. Les deux cas de terrain de cette note montrent le CPU grimper bien avant qu'apparaisse quoi que ce soit d'aussi évident qu'une interface qui rebondit — l'indice révélateur est la montée régulière des compteurs de paquets TC sur display stp tc-bpdu statistics, pas un événement de lien visible. Vérifiez cette commande avant d'écarter l'hypothèse d'une boucle.
Il limite la fréquence à laquelle une purge de table MAC/ARP déclenchée par TC peut se produire — au plus une fois toutes les 2 secondes, quel que soit le nombre de paquets TC arrivant dans cette fenêtre. Le compromis est un très léger délai dans la rapidité de réaction du réseau à un véritable changement de topologie, largement compensé en pratique par le fait de ne pas laisser une tempête TC purger à répétition des tables qui n'en ont pas besoin. C'est une pratique standard de le laisser configuré en permanence plutôt que seulement pendant un incident.
Un changement de topologie signifie généralement que l'interface de sortie réelle d'une adresse MAC a peut-être changé, donc le comportement par défaut est prudent : purger les entrées concernées et les réapprendre pour que le transfert reste correct. Ce comportement par défaut est parfaitement adapté à un véritable changement de topologie ponctuel, et parfaitement inadapté quand des paquets TC arrivent en continu — c'est pourquoi arp topology-change disable associé à mac-address update arp enable existe comme alternative plus chirurgicale : suivre directement le changement d'interface de la table MAC au lieu de purger et réapprendre toute la table ARP à chaque fois.
FTS et SRMT apparaissant ensemble en tête, aux côtés de rejets CPCAR sur des types de paquets liés à ARP et de compteurs TC en hausse, c'est la signature que montrent les deux cas de terrain de cette note. Si à l'inverse vous voyez un seul protocole sans rapport (disons vrrp) dominer les rejets CPCAR avec des compteurs TC stables, cela pointe vers une inondation spécifique à ce protocole plutôt qu'une boucle, et la remédiation ARP/TC d'ici ne sera pas la solution — enquêtez plutôt directement sur l'interface source de ce protocole.
Cette note s'appuie sur le modèle de classification des pannes CPU du commutateur Huawei série S et ses commandes display cpu-usage / cpu-defend statistics / stp tc-bpdu statistics, ainsi que sur les cas de terrain qui les sous-tendent. Si votre commutateur est d'un autre fournisseur, les commandes exactes changent, mais l'ordre de diagnostic sous-jacent — confirmer la persistance, trouver la tâche, vérifier les rejets CPCAR, vérifier les compteurs TC — s'applique directement. Pour un parcours complet de la détection de boucle de niveau 2 et la rupture sûre d'une boucle une fois confirmée, consultez notre note dédiée sur les tempêtes de boucle ; cette note couvre le côté symptôme CPU, pas l'analyse générale de la topologie de boucle.
Envoyez-nous votre sortie display cpu-usage ainsi que les entrées de journal CPU_USAGE_HIGH, et nous vous aiderons à identifier quelle tâche et quel type de paquet en est réellement la cause.