A WAC campus loses every Fit AP under one access switch at once — no cable pulled, no power event, nothing wrong with the AP itself. The actual cause sits two layers away: an STP topology change anywhere in the Layer 2 domain floods TC-BPDU, the switch acting as the AP gateway ages out its ARP table in response, and every AP under it loses its gateway and gets dropped in bulk. This is the chain, the commands that confirm each link, and the two-line fix.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Nothing about the AP is actually broken here — the AP is just the last link in a chain that starts somewhere else in the switching fabric entirely.
The ticket always looks the same: a WAC-managed campus reports that a batch of Fit APs — sometimes an entire access switch's worth — went offline together, all at once, with no correlated power event, no cable pull, no firmware change. The instinct is to start troubleshooting the APs: check their power, check their uplinks, check the AC. Almost none of that is where the fault actually is.
What follows is the root-cause chain behind the single most common version of this fault, the commands that confirm each link in that chain rather than just the symptom at the end of it, the two configuration lines that close it off, and the field questions worth having answers to before the next occurrence.
Three different starting points produce the same symptom on the AP side — only one of them is a chain worth tracing back through the switching fabric.
Placing the fault on this tree before changing anything on the APs themselves tells you whether you're looking at an isolated hardware problem, a CPU overload, or the TC-BPDU chain this note is actually about.
Diagram labels are kept in English for engineering clarity.
Steps 1 and 2 are ordinary, healthy STP behavior — a topology change notification is supposed to propagate. The fault is entirely in step 3: this particular switch's ARP table shouldn't be treated as suspect just because somewhere else in the domain, a port went up or down.
Four checks, in order — each one rules out a different branch of the tree before you commit to the TC-BPDU explanation.
The branch you're on depends entirely on whether this is one AP or a whole switch's worth.
Before blaming TC-BPDU specifically, rule out the other network-wide cause: too many packets landing on the 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 yetThis is the check that actually confirms the chain — run it on whichever switch sits directly upstream of the affected APs and serves as their gateway.
<Switch> display stp topology-change //查看拓扑变化
<Switch> display stp tc-bpdu statistics //查看端口TC报文收发计数Two lines, and they need to be applied together — one alone is a half-fix.
<Switch> system-view
[Switch] mac-address update arp //开启MAC刷新ARP功能，即MAC地址的出接口变化时，通知更新ARP表项的出接口
[Switch] arp topology-change disable //关闭设备响应TC报文的功能，即当设备收到TC报文时，不对ARP表项进行老化或删除The chain above is the mechanism — these are the ways engineers actually get stuck on it in the field.
SYMPTOMEvery AP under one switch drops together, with clean power and an undamaged uplink on each one.
CAUSEThe AP never actually failed. It simply lost its ARP entry for its gateway or the AC, because the switch it sits behind aged that entry out in response to a TC-BPDU it received — the fault is entirely upstream, in the switch's ARP table handling, not in the AP or its radio.
FIXStop diagnosing the APs individually once more than one under the same switch is affected — go straight to display stp topology-change and display stp tc-bpdu statistics on the upstream switch instead.
SYMPTOMThe AP-gateway switch's own uplink and ports never blinked, yet its ARP table still emptied out.
CAUSEA topology-change notification propagates to every switch in the same spanning-tree domain, not just the switch where the port actually flapped. If that switch still responds to TC-BPDU by aging its ARP table, a link event on the far side of the campus can empty this switch's ARP table and drop every AP behind it.
FIXDon't restrict the search for a root cause to the AP-gateway switch's own uplinks — check for topology changes anywhere in the same STP domain around the time the APs dropped.
SYMPTOMSame headline symptom — a batch of APs offline at once — but the AC or core switch was rebooted, reset, or failed over shortly before it happened.
CAUSEA chassis failover event on the AC itself is a completely different mechanism — a demote-then-repromote sequence on the controlling unit that batch-deletes AP records — and it leaves its own forensic trail in the reset reason and AP offline records, not in display stp tc-bpdu statistics.
FIXCheck whether the AC/core chassis had a reboot or slot failover in the same window before assuming this is a TC-BPDU storm; if it did, the chassis failover mechanism is the more likely explanation.
SYMPTOMSimilarly abrupt AP drops, but this time paired with generally poor performance, high CPU everywhere, and MAC addresses flapping between ports across the switching fabric.
CAUSEA TC-BPDU-driven ARP flush can happen from a single, brief, otherwise-healthy topology change — it doesn't require an actual Layer 2 loop. A genuine loop produces its own much broader signature: broadcast flooding, port MAC flapping, and network-wide congestion, not just an AP-drop event confined to one gateway switch.
FIXIf the symptoms are broader than just AP drops — broadcast storms, flapping MAC tables, widespread slowness — work the loop-finding process instead of the TC-BPDU/ARP chain in this note.
SYMPTOMAP drops become less frequent after applying a fix, but still recur occasionally after a topology change elsewhere.
CAUSEmac-address update arp only makes ARP entries update faster when a MAC's outbound interface changes — it doesn't stop the switch from aging or deleting ARP entries in response to a TC-BPDU in the first place. Configuring it alone still leaves a window where entries can be cleared.
FIXConfigure both commands together: mac-address update arp for faster convergence, and arp topology-change disable to stop the ARP table from being touched by TC-BPDU at all.
Pulled straight from the field — the ones worth having an answer ready for.
Check the AC/core chassis's own reset reason and uptime first. If it rebooted, reset, or failed over shortly before the APs dropped, work that mechanism — the reboot's forensic trail explains it directly. If the AC/core was untouched and only the intermediate access switch shows a recent topology change, this TC-BPDU chain is the more likely explanation.
Almost anything that brings a port up or down in the same spanning-tree domain: a device reboot, a cable reseated, a port flapping intermittently, even a planned maintenance change on an unrelated switch. The point of this fault chain is that the change doesn't have to happen anywhere near the APs that end up dropping.
Yes, for the switch acting as an AP gateway — it stops normal, healthy topology-change events from clearing ARP entries that are still valid. It should be paired with mac-address update arp so that entries still update correctly on the occasions the outbound interface genuinely does change, which is the scenario ARP aging on TC-BPDU was originally meant to handle.
Because TC-BPDU propagates to the whole spanning-tree domain, not just the switch where the flap happened. Every switch that still ages its ARP table on TC-BPDU receipt reacts the same way, regardless of where the actual topology change originated — which is exactly why the fix has to be applied on the AP-gateway switch, not chased back to the port that flapped.
Baseline display stp tc-bpdu statistics on your AP-gateway switches and watch for counts climbing outside of planned maintenance windows — a rising count there, ahead of any AP-offline alarm, is the earliest signal this chain is starting. Pairing that with periodic display cpu-defend statistics checks also catches the CPU-overload branch before it escalates.
This note is built around the Huawei WAC/Fit-AP fault-classification model and the display stp / display cpu-defend commands behind it, plus the field cases that motivate them. It covers the TC-BPDU-driven ARP-flush chain specifically — it doesn't replace a full Layer 2 loop investigation when the symptoms are broader than an AP-drop event, and it doesn't cover AC chassis failover or hardware faults, which have their own separate diagnostic paths.
Tell us whether it's one switch's worth or the whole campus, plus the display stp tc-bpdu statistics output from the AP-gateway switch, and we'll help you read it.