A switch that's sluggish, or dropping OSPF Hello and VRRP heartbeats it should never drop, often traces back to one thing: CPU usage pinned high for minutes at a time. This is the order that finds the actual task burning the CPU fastest, the two field cases that explain most of these tickets, and the protections that keep it from happening again.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The first question isn't "why is CPU high" — it's "is this actually abnormal," and that's a five-minute-window question, not a one-second one.
A brief CPU spike from a routine software task isn't unusual and clears on its own. What's worth chasing is CPU usage that stays high across the five-minute average shown in display cpu-usage — that pattern almost always means either an abnormal event or something generating an unusual volume of control-plane traffic, and it's exactly the kind of load that starts crowding out OSPF Hello packets and VRRP heartbeats, which is when a CPU problem turns into an outage.
What follows is the order that finds the fault fastest: confirm CPU really is abnormally high and see which task is burning it, the two field cases — a storm of TC (Topology Change) packets and an MSTP loop recomputing topology — that between them explain most of these tickets, and the protections worth having configured before it happens again.
Three checks in sequence — the overall usage number, which task is consuming it, and whether CPCAR is dropping protocol packets — cover almost every real case.
Diagram labels are kept in English for engineering clarity.
The two field cases in this note both share the same signature at step 3: TC (Topology Change) counters climbing on display stp tc-bpdu statistics. That's not a coincidence — a flood of TC packets is by far the most common single driver of persistent switch CPU load, whether it comes from flapping edge ports or an MSTP domain recomputing its topology.
display cpu-usage tells you two different things depending on how you read it — the overall number, and the per-task breakdown underneath it.
A CPU usage above roughly 70%, or an hwEntityExtCpuUsageNotfication alarm (which by default fires above 90%), is worth investigating — but only if it holds across the five-minute average, not a single sample.
<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 chasingCPU_USAGE_HIGH log entries name the top three tasks directly — that's usually faster than digging through display cpu-usage's task table by hand.
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 stormBoth come from the same manufacturer's field case files, both share the same TC-storm signature, and both have the same two-command fix.
SYMPTOMNetwork management shows CPU utilization climbing and staying high; the log buffer fills with CPU_USAGE_HIGH entries naming FTS, SRMT and PPI as the top consumers, alongside CPCAR_DROP_MPU entries for arp-miss, arp-reply and arp-request all exceeding their rate limit at the same time.
CAUSEChecking display stp tc-bpdu statistics shows the count of received TC packets climbing continuously across ports. Each TC packet triggers a MAC table flush and an ARP re-learn cycle; when TC packets keep arriving, the switch keeps re-learning ARP for a large table, generates a large volume of arp-miss and arp-request traffic of its own, and the resulting arp-reply flood from end hosts exceeds the CPCAR rate limit and gets partially dropped — which ages out ARP entries and restarts the cycle. With the CPU this busy processing ARP churn, OSPF Hello and VRRP heartbeat packets stop being serviced in time and those protocols start flapping too.
FIXConfigure stp tc-protection globally so a TC-triggered table flush happens at most once per 2-second window instead of on every single TC packet, then configure arp topology-change disable together with mac-address update arp enable so a topology change refreshes ARP entries by tracking the MAC table's outbound interface instead of re-learning ARP from scratch across the board.
<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 enableSYMPTOMCPU utilization is high across an MSTP-ringed network, and display interface brief shows one or more interfaces running well above normal bandwidth utilization in one direction.
CAUSEIn an MSTP ring, some event — often one that's hard to pin to a single root cause from the CPU symptom alone — keeps triggering topology recalculation. Each recalculation broadcasts a fresh round of topology-change BPDUs across the ring, and the switch spends CPU cycles recomputing spanning-tree state every time one arrives, which is confirmed by display stp tc-bpdu statistics showing TC packets received in volume across multiple ports.
FIXRather than chasing the exact trigger inside the MSTP ring first, apply the same two commands as the TC-storm case — arp topology-change disable and mac-address update arp enable — to stop each topology change from forcing a full ARP re-learn. In the field case this brought CPU usage down immediately; use display interface brief afterward to confirm bandwidth utilization has also returned to normal on the affected ports.
<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 fromSYMPTOMCPU stays high but display cpu-defend statistics for the obvious protocols shows nothing unusual, and there's no interface visibly flapping.
CAUSEA short-lived software task spike is not the same fault as a genuine sustained overload — if the FiveMin column in display cpu-usage isn't actually elevated, chasing CPCAR counters or TC statistics is looking in the wrong place entirely. Treating every momentary spike as an incident wastes time that should go toward confirming persistence first.
FIXRe-check the FiveMin average over a longer window before doing anything else. If it genuinely isn't persistent, the CPU isn't the fault — look at the symptom that actually brought you here (slow response, packet loss, an interface event) as its own investigation instead of forcing it onto the CPU-high fault tree.
SYMPTOMdisplay cpu-defend statistics shows heavy Drop(Packets) counts for a protocol that has nothing to do with STP or ARP — vrrp, for instance — while TC counters on display stp tc-bpdu statistics stay flat.
CAUSECPCAR protects the CPU per protocol type, and a flat TC counter rules out the two loop-driven cases above. A VRRP flood or similar can come from a misconfigured neighbor, a genuine attack, or a device somewhere on the segment malfunctioning and sending at an abnormal rate — the fix here is protocol-specific, not the ARP/TC remediation used for the loop cases.
FIXIdentify the source interface generating the flagged protocol traffic (display cpu-defend statistics reports per-slot, which narrows down the ingress point), then investigate that neighbor or device directly rather than applying the TC-storm remediation, which won't help a non-loop-driven flood.
Pulled straight from the field — the ones worth having an answer ready for.
A brief spike from an ordinary software task clearing within seconds is normal switch behavior and not worth chasing. What matters is the FiveMin column in display cpu-usage — if the five-minute average is persistently elevated, that's the pattern consistent with an abnormal event or an unusual volume of control-plane traffic, and it's worth investigating with the steps in this note. Treat the instantaneous number as noise and the five-minute average as signal.
Yes. Both field cases in this note show CPU climbing well before anything as obvious as an interface bouncing appears — the giveaway is the TC packet counters on display stp tc-bpdu statistics climbing steadily, not a visible link event. Check that command before ruling loops out.
It limits how often a TC-triggered MAC/ARP table flush can happen — at most once every 2 seconds, regardless of how many TC packets arrive in that window. The tradeoff is a very small delay in how fast the network reacts to a genuine topology change, which in practice is far outweighed by not letting a TC storm repeatedly clear tables it doesn't need to. It's standard practice to leave it configured permanently rather than only during an incident.
A topology change usually means a MAC address's actual outbound interface may have shifted, so the default behavior is conservative: clear the affected entries and relearn them so forwarding stays correct. That default is exactly right for a genuine one-off topology change, and exactly wrong when TC packets are arriving continuously — which is why arp topology-change disable paired with mac-address update arp enable exists as the more surgical alternative: track the MAC table's interface change directly instead of clearing and relearning the whole ARP table each time.
FTS and SRMT appearing together at the top, alongside CPCAR drops on arp-related packet types and climbing TC counters, is the signature this note's two field cases both show. If instead you see a single unrelated protocol (say vrrp) dominating CPCAR drops with flat TC counters, that points to a protocol-specific flood rather than a loop, and the ARP/TC remediation here won't be the fix — investigate that protocol's source interface directly instead.
This note is built around the Huawei S-series switch's CPU-fault-classification model and its display cpu-usage / cpu-defend statistics / stp tc-bpdu statistics commands, plus the field cases behind them. If your switch is a different vendor, the exact commands change, but the underlying diagnostic order — confirm persistence, find the task, check CPCAR drops, check TC counters — carries over directly. For a full walkthrough of Layer 2 loop detection and breaking a loop safely once you've confirmed one, see our dedicated loop-storm troubleshooting note; this note covers the CPU-symptom side, not general loop topology analysis.
Send us your display cpu-usage output plus the CPU_USAGE_HIGH log entries, and we'll help you read which task and which packet type is actually driving it.