An AntiDDoS device that looks fully configured can still let an attack straight through. This is the diagnostic chain that finds why, in order — whether a diversion task actually exists, whether the attack traffic clears the detection threshold, whether the detection device is actually still talking to SecoManager, and the one display command that catches a resource table quietly exhausted underneath everything else.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The device is up, the policy is attached, the license shows active — and the attack still went through. That gap is almost always in one of four specific places.
A protection policy that's fully configured doesn't guarantee the device is actually defending a given IP address at this exact moment. Between “policy exists” and “traffic is being scrubbed” sits a chain of state that has to hold end to end: a diversion task has to exist for the attacked IP, the detection device has to have actually seen the attack traffic cross its threshold, that detection device has to still be able to tell SecoManager about it, and the device's own resource table has to have a free entry left to hold the new state. Any one weak link and the attack rides straight through while everything upstream still reports green.
What follows is that chain in the order worth checking it, the exact commands for each stage, the five root causes that show up again and again once you're past the first couple of checks, and field-case FAQ answers for the situations that don't fit neatly into any one stage.
Four links, checked top to bottom — the first one that comes back empty is where the real problem is.
Work down this chain in order rather than jumping straight to the resource table check at the bottom; each stage rules out an entire category of causes before you get to the next one.
Diagram labels are kept in English for engineering clarity.
Notice what this chain deliberately leaves out: it never asks whether the attack-defense policy itself is well tuned. That question only matters once all four links above are confirmed intact — tuning a policy that never receives traffic, or never gets a free table entry to act on, changes nothing.
Each stage has its own place to look and its own command — and confirming one stage is the fastest way to rule out everything behind it.
Start here, not in the device CLI — diversion status lives on the SecoManager side, and it tells you which of the next stages actually applies.
<Huawei> display anti-ddos destination-ip ip x.x.x.x
// no entry returned -> this IP's traffic was never mirrored to the detection device
// an entry with zero counters -> traffic is arriving but hasn't crossed threshold yetA diversion task is generated only once the detection device itself reports the anomaly — a perfectly configured defense policy downstream changes nothing if this step never fires.
<Huawei> display interface brief
// confirm the detection interface status is up and is actually receiving mirrored traffic,
// not just physically up with nothing arriving on itThe detector can see the attack perfectly well and still never generate a diversion task if SecoManager never hears about it.
<Huawei> ping -a x.x.x.x(detection device log-port IP) x.x.x.x(SecoManager collector IP)
// unreachable in either direction -> the detector-to-manager channel itself is the fault,
// not the attack-defense configuration on either endThis is the check that catches the failure with no obvious symptom anywhere else — everything upstream reports fine, and the device still isn't defending.
<Huawei> display anti-ddos resource slot slot-id cpu cpu-id
// check the free column for the resource item this attack/IP needs
// free = 0 -> defense for anything new on this resource stops here, regardless of policy
<Huawei> display cpu-usage slot slot-id cpu cpu-id
<Huawei> display ddos slot
// cross-check: is the SPU CPU actually registered, and how loaded is it right nowOnce the four-stage chain above has told you where the problem sits, these five account for most of what's actually wrong.
SYMPTOMdisplay anti-ddos destination-ip ip x.x.x.x returns no monitoring entry at all for the attacked address, even though the defense policy and protection object both look correctly configured.
CAUSEDiversion depends entirely on the detection device seeing this IP's traffic in the first place. If the router's mirror or diversion configuration upstream doesn't actually include this address's traffic — a scoping mistake, not an AntiDDoS mistake — the device never gets a chance to measure it, let alone compare it against a threshold.
FIXCheck the mirror/diversion configuration on the router feeding the detection device against the product documentation for that interface configuration, before touching anything inside the AntiDDoS policy itself.
SYMPTOMDiversion task exists, detection threshold was clearly crossed, the channel to SecoManager is fine — and the attack still isn't being scrubbed.
CAUSEdisplay anti-ddos resource shows the free column for the relevant resource item at 0. The device has run out of room to install new defense state, and this doesn't announce itself the way a hardware fault or a license expiry does — it just quietly caps what the device can protect from that point on.
FIXMake display anti-ddos resource a standard step in this checklist, not a last resort. If free is 0, the fix is capacity and cleanup on that resource item, not another look at the policy configuration.
<Huawei> display anti-ddos resource
// free column at 0 for the resource item this attack needs -> defense stops here
// regardless of how correctly everything upstream is configuredSYMPTOMdisplay ddos slot shows the CPU as not registered, and defense simply never engages on that board no matter what the policy says.
CAUSEAn unregistered detection or scrubbing CPU can't run the defense functions at all. This is very often a License problem underneath — a Trial-state License (mismatched ESN), an expired License, or a License that's dropped into Default state — rather than anything wrong with the CPU itself.
FIXCheck display license first. If the state isn't Normal, resolving the License is the actual fix; registering the CPU manually against the right type only makes sense once the License itself is healthy.
<Huawei> display ddos slot
// CPU not registered -> check License state before anything else
<Huawei> display license
// License state should read Normal; Trial / Default / expired all block real defense capacity
[Huawei] firewall ddos detect-spu slot x cpu x
// specifies the CPU type once the License itself is confirmed healthySYMPTOMdisplay health shows SPU-card CPU utilization already at or above 95%, and defense quality degrades under load that a healthy device would otherwise absorb.
CAUSEA saturated SPU CPU can't keep up with new state installation or per-packet inspection at the rate the attack demands, independent of whether the resource table itself still has free entries.
FIXAs an immediate measure, configure a blackhole on the upstream router for the single most damaging attacked IP to protect the CPU headroom for everything else being defended. Ask the upstream carrier to apply rate-limiting or protocol filtering against the attack at their edge. As a structural fix, consider adding SPU cards to raise the device's ceiling.
SYMPTOMBusiness traffic drops noticeably right after passing through the AntiDDoS device, or business traffic spikes and keeps forwarding at the same elevated volume with no visible reduction.
CAUSEThese are two different problems that get chased with the same troubleshooting steps by mistake. A drop against an otherwise-flat baseline, appearing only after the device, points at a false block (legitimate traffic caught by an over-tight policy). A clear spike above baseline that still forwards at nearly full volume after the device points at a missed attack (a protection leak) — the four-stage chain above is what to run in that case.
FIXClassify which shape you're looking at before opening any configuration. A false block gets fixed by loosening the specific policy rule that's over-triggering; a missed attack gets fixed by working the diversion-threshold-communication-resource chain, not by tightening policy further.
Pulled straight from the field — the ones worth having an answer ready for.
Not necessarily the whole device — resource items are tracked separately, and a chassis with multiple SPU cards can be checked per slot and per CPU with display anti-ddos resource slot slot-id cpu cpu-id. What it does mean is that the specific resource item reading 0 can't accept new state, which is enough on its own to explain why one particular attack or IP isn't being defended while others still are.
Look at the baseline first. If business traffic was flat before the device and only drops after it, with no corresponding spike anywhere upstream, that's a false block — legitimate traffic is being caught by a policy rule that's too aggressive. If traffic was already visibly elevated above normal before it reached the device, a drop after the device is exactly what correct scrubbing looks like.
Confirm the destination IP actually has a protection object created and deployed to the device, not just configured somewhere in SecoManager. If the IP was never deployed to the device itself, the device never performs traffic statistics for that address at all — there's naturally no traffic data to trigger anything, regardless of how correct the rest of the configuration is.
Yes, directly. Trial state most often means the License was activated with an ESN that doesn't match the device, and it's capped at 60 days of use. A device running on a Trial or expired License can drop into Default state, which interrupts the business function outright rather than just degrading it. Re-issuing and re-activating a License matched to the correct ESN is the only real fix — there's no configuration workaround for a License-state problem.
Two usual causes outrank a wrongly tuned threshold value: the detection interface isn't actually receiving the mirrored traffic for that specific IP at all (check display interface brief and the mirror configuration first), or the destination-IP monitoring entry itself was never created because the address was never deployed as a protection object. Confirm traffic is arriving before assuming the threshold number itself needs to change.
This note is built around the Huawei AntiDDoS device family managed through SecoManager, and the field checklist behind its diversion, detection, communication and resource-table behavior. It assumes a SecoManager-managed deployment with diversion-based scrubbing; a standalone or bypass-mode deployment follows a related but not identical checklist. It doesn't cover FlowSpec- or BGP-diversion-specific configuration in depth, or cloud-scrubbing linkage for attacks that exceed local capacity entirely.
Tell us which stage of the chain came back empty — diversion, threshold, communication, or the resource table — plus the display anti-ddos resource output, and we'll help you read it.