When the AntiDDoS device itself has become the outage — blocking real business traffic instead of protecting it — this is the fast path back: telling a false positive apart from a missed attack first, the diagnostic capture to run before touching anything, the Bypass procedure for both out-of-path and in-line deployments, how to confirm it actually worked, and the threshold tuning that keeps it from happening again.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
A DDoS scrubber that blocks real customers is a self-inflicted outage — and it needs a faster, calmer response than an actual attack does.
An AntiDDoS device that starts dropping legitimate traffic is its own kind of emergency: the business impact looks identical to an outage, but the fix isn't a network repair — it's recognizing that the device's own defense policy has become the problem, and unwinding it quickly and correctly. Reaching for the wrong lever first (or reaching for the right lever without checking what's actually wrong) wastes exactly the minutes that matter.
What follows is that response, straight from the AntiDDoS emergency-recovery handbook: how to tell this apart from an attack that's actually getting through, the information worth capturing before you touch anything, the Bypass procedure itself for both common deployment shapes, how to confirm it actually worked, and the tuning that stops it from happening again.
Bypass is the right answer to exactly one of these two — get this call right before doing anything else.
| Traffic pattern | Diagnosis |
|---|---|
| Inbound traffic hasn't risen noticeably compared to normal, but traffic coming out the other side of the AntiDDoS device has dropped noticeably. | False positive (误防) — the device's own policy is blocking traffic that was never actually an attack. This note applies: proceed to Bypass. |
| Inbound traffic has risen noticeably compared to normal, and traffic coming out the other side is still much higher than normal. | Missed attack (漏防) — the attack is getting through, not being blocked. Bypassing the device here removes the only defense in place; the correct response is to enable defense faster, not bypass it. |
Getting this diagnosis wrong in either direction burns the minutes that matter — bypassing during a real attack, or hunting for attack traffic that was never actually there, both delay the fix that's actually needed.
Six commands, run before recovery — the record you'll want once the pressure is off.
| Command | What it captures |
|---|---|
| collect diagnostic information | The full diagnostic information package for this incident. |
| display firewall statistic system discard | System-wide packet-discard statistics — what's actually being dropped and where. |
| display anti-ddos packet-trace statistic | Drop statistics specific to AntiDDoS processing — separating its drops from ordinary firewall discards. |
| display cpu-usage slot slot-id cpu cpu-id | SPU board CPU usage at the moment of the incident. |
| display anti-ddos resource slot slot-id cpu cpu-id | Resource-table usage — whether a table is near capacity independent of any attack. |
| display firewall session table verbose | Session-table usage at the time of the incident, for comparison against the post-bypass state. |
Out-of-path and in-line deployments fail differently, so the fastest way back differs too.
In this deployment shape, traffic is diverted to the AntiDDoS device only when something looks wrong — so shutting off diversion is the fastest lever, but it isn't the only one that needs pulling.
[HUAWEI-100GE4/0/1] display this
interface 100GE4/0/1
shutdown
ipv6 enable
ip address 172.16.1.1 255.255.255.0
ipv6 address 2001:db8:1::1/64In this deployment shape the device sits physically in the traffic path in transparent Layer 2 mode, so the recovery path depends on what kind of Bypass hardware is actually present.
Same goal, different mechanics — because the traffic gets to the device differently in each deployment.
Diagram labels are kept in English for engineering clarity.
Bypass stops the bleeding — it doesn't fix why the false positive happened in the first place.
[HUAWEI] reset anti-ddos blacklist slot slot-id cpu cpu-id
// clears the blacklist for one CPU only -- repeat for every CPU on the slot(s) in questionEvery one of these has cost someone real recovery time.
SYMPTOMThe diversion-facing interface is shut down on the device, but the affected traffic still seems to be getting diverted or blocked.
CAUSEThe diversion, Flowspec and blackhole tasks live in SecoManager, independent of the interface's own state — shutting down the interface stops traffic from physically reaching the device through that path, but it doesn't disable the tasks that would re-divert it the moment the interface comes back.
FIXTreat the interface shutdown and the SecoManager-side diversion/Flowspec/blackhole task disablement as one single action, not a sequence you can stop halfway through.
SYMPTOMThe protection object was removed through SecoManager, but the device still appears to be dropping some of the traffic.
CAUSEHardware filters are a separate binding from the protection object — removing the protection object doesn't automatically detach a hardware filter that's already associated and actively dropping traffic.
FIXExplicitly disassociate every hardware filter under Attack Defense > Filter > Hardware Filter as its own step, not an assumed side effect of removing the protection object.
SYMPTOMTraffic behavior changes for services other than the one being troubleshot, right after the protection object was edited.
CAUSEIf the affected IP was never given its own dedicated protection object, it's been sharing the default one along with every other IP in the same situation — turning off auto-diversion or auto-blackhole there changes behavior for all of them at once.
FIXConfirm whether the affected IP has a dedicated protection object before editing broadly, and understand the full blast radius before touching the default object.
SYMPTOMreset anti-ddos blacklist was run once, but the same legitimate traffic is still being blocked.
CAUSEThe dynamic blacklist is maintained per CPU. reset anti-ddos blacklist slot slot-id cpu cpu-id only clears the one CPU it's actually run against — the blacklist stays fully in effect on every other CPU on the slot.
FIXRepeat the reset command for every CPU on the relevant slot(s); a single run is not equivalent to clearing the device.
[HUAWEI] reset anti-ddos blacklist slot slot-id cpu cpu-id
// must be repeated for each CPU to fully clear the blacklistSYMPTOMThe Bypass procedure is executed in full, but the underlying business impact doesn't improve — or gets worse.
CAUSEBypass is the correct response to a false positive only. If inbound traffic is actually elevated and traffic past the device is still elevated, that's a missed attack — bypassing removes the one defense actually needed, rather than restoring blocked legitimate traffic.
FIXConfirm the traffic pattern against the false-positive/missed-attack diagnosis before starting Bypass, not after it's already underway.
The ones worth having an answer ready for before the next incident, not during it.
The interface shutdown itself is near-immediate, but it doesn't fully stop the problem unless the SecoManager diversion, Flowspec and blackhole tasks for that IP are disabled at the same time — treat all four steps as one action to execute together, not a sequence to work through one at a time under pressure.
The device stays physically in the traffic path the whole time, since it's deployed as transparent Layer 2 in-line — traffic keeps flowing through it during the change. Removing the protection object, unbinding hardware filters and disabling blackhole/Flowspec tasks is about stopping the device from applying protection logic to that traffic, not about physically removing it from the path.
Re-run the same pre-recovery captures — session table, discard statistics, packet-trace statistics — and compare them against the numbers from before the incident, and separately confirm the affected business itself is reachable from a real client, not just that the device's own counters look calmer.
Only once you've confirmed that's actually what you want — every IP without its own dedicated protection object shares the default one, so turning off auto-diversion or auto-blackhole there affects all of them at once, not just the IP currently in trouble. If that's too broad, create a dedicated protection object for the affected IP instead.
There's no fixed interval in the handbook for this — the right order is confirming what actually caused the false positive (usually a stale threshold or an unaccounted-for business change), adjusting that policy, and only then re-enabling protection during a lower-risk window while watching the same counters again.
The blacklist is maintained per CPU. reset anti-ddos blacklist slot slot-id cpu cpu-id only clears the CPU it's actually run against, so it has to be repeated for every CPU on the relevant slot(s) before the blacklist is genuinely gone device-wide.
This note is built directly from the AntiDDoS troubleshooting handbook's own emergency-recovery chapter, covering the false-positive quick-bypass path for both out-of-path and in-line deployments and the SecoManager operations behind it. It doesn't cover the missed-attack side of the same chapter — enabling defense quickly when an attack is actually getting through — and it doesn't replace the underlying Flowspec or blackhole configuration reference. For the day-to-day commands used to first notice something is wrong, see the companion note below.
Tell us the deployment shape — out-of-path or in-line — and whether you've confirmed false positive over missed attack, and we'll help you move fast.