The command toolbox for day-to-day AntiDDoS maintenance, grouped by scenario — the alarms worth reading closely, why a board can look present and still be unhealthy, the physical states an interface can report besides a clean Up, what a full session table actually looks like, what each License state really means for production traffic, the SPU overload escalation path, and how to confirm BGP diversion is actually working.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Most AntiDDoS shifts don't start with a mystery — they start with an alert, and the question is which command actually answers it.
On a day-to-day AntiDDoS detection-and-cleaning deployment, most of what an on-call engineer needs isn't a deep root-cause investigation — it's the right command for the scenario in front of them: an alarm just fired, a board looks off, a service stopped passing traffic, someone asks whether the License is still valid, the SPU board is pegged, or a BGP-diverted route doesn't seem to be landing. Six different scenarios, six different commands, and the difference between reading the output correctly and guessing is usually the minutes that matter.
What follows is that toolbox, organized the way it actually gets reached for — grouped by scenario, with the real command output for each, the six things that trip people up even after they know which command to run, and answers to the questions that come up constantly once the toolbox itself isn't the problem anymore.
Match the situation in front of you, then run two or three commands — not the whole handbook.
Alarms & Hardware Health
| Command | What it tells you |
|---|---|
| display alarm active verbose | Every active alarm in full — AlarmName, Severity, State and a Description that usually names the actual reason, not just a code. |
| display alarm active | The quick list — sequence, ID, severity, date/time and a one-line description, for scanning a lot of alarms fast. |
| display device | Per-slot status for every board, SPU, fan and power module — Online, Power, Register, Alarm and Primary side by side. |
Interface State
| Command | What it tells you |
|---|---|
| display interface interface-type interface-number | The current state field — the exact physical-layer condition, which is one of twelve named states, not just Up or Down. |
| display interface (Line protocol current state) | The link-layer state above the physical layer — BFD-linked, bit-error, dampening-suppressed or Mac-flapping conditions that a healthy physical layer can still hide. |
Session Table
| Command | What it tells you |
|---|---|
| display firewall session table | Current Total Sessions plus one summary line per session — the fastest way to see if the count itself is the problem. |
| display firewall session table verbose | The full record — zone pair, TTL, receiving interface and slot/CPU, forward and reverse packet/byte counts, and TCP State. |
| display firewall session table verbose unidirection | Sessions that only ever went one way — the signature of a return-path or policy problem, not a session-table problem. |
License Status
| Command | What it tells you |
|---|---|
| display license | The active License file and its License state — Normal, Trial, Demo, Emergency or Default. |
| display license verbose | Per-item detail — control value versus used value, expiry date, authorize type — for confirming exactly which resource or feature is actually constrained. |
SPU CPU Load
| Command | What it tells you |
|---|---|
| display health | Per-board CPU utilization — the number to watch on the SPU board specifically once syslog has already flagged it. |
BGP Diversion
| Command | What it tells you |
|---|---|
| display bgp peer | Whether the BGP session to the router is actually Established, and how many prefixes it has received. |
| display bgp routing-table peer peer-address advertised-routes | The specific routes actually being advertised toward that peer — confirms the diversion route itself, not just the session. |
| display current-configuration | include 255.255.255.255 | A leftover host-route static entry that silently outranks the BGP-advertised route — see Gotcha 6. |
The command is only half of it — here's what the real output actually looks like, and what to check next.
display alarm active verbose is the one command that turns a bare alarm name into an actual explanation — the Description field usually says exactly what changed.
<HUAWEI> display alarm active verbose
Sequence : 24
AlarmId : 0x8520003 AlarmName : linkDown
AlarmType : processing_error Severity : Major State : active
RootKindFlag: Independent
StartTime : 2024-01-18 13:27:43+08:00 DST
Description : The interface status changes. (ifName=Ethernet1/0/2, AdminStatus=DOWN, OperStatus=DOWN, Reason=The interface is shut down.)
<HUAWEI> display alarm active
--------------------------------------------------------------------------------
Sequence AlarmId Severity Date Time Description
--------------------------------------------------------------------------------
1 0x8272004 Minor 2024-01-18 Administrator type users login failed
15:00:38 too frequently.(failed times=0, statis
tic period=0 minutes)display device is the companion check for the board itself — Alarm: Abnormal on a slot means a major or critical hardware alarm exists there even if Online and Power both look fine.
<HUAWEI> display device
AntiDDoS12004's Device status:
--------------------------------------------------------------------------------
Slot Card Type Online Power Register Alarm Primary
--------------------------------------------------------------------------------
3 - SPUA-USG-02 Present On Registered Normal NA
PWR1 - PAH-3000WA Present On Registered Abnormal NA
PWR2 - PAH-3000WA Present On Registered Abnormal NAThe current state field in display interface is one of twelve named physical-layer conditions when it isn't simply Up — reading which one it is saves a lot of guessing.
| current state value | What it means |
|---|---|
| Transceiver type mismatch | The installed media type doesn't match what the interface expects. |
| The optical power is too low | Optical module receive/transmit power has dropped below the working threshold. |
| Port unavailable | A configuration such as port splitting or a high-performance mode has made the port unavailable. |
| Cable for stack or peer-link interface only | This cable type is only supported on a stack or peer-link port. |
| Transceiver type for stack only | This media type is only supported on a stack port. |
| RTU license down | Insufficient License resources for this interface. |
| Serdes-Mode mismatch | The frequency/SerDes mode configured is insufficient to bring the port up. |
| SerDes P/N mismatch | The optical module's data-lane mapping doesn't match the port's. |
| Single forward state | A Phy fault on the optical/electrical module. |
| Configuration conflicts with transceiver | The current configuration conflicts with the installed media type. |
| Device hardware verification failed | The device failed hardware verification. |
| Transceiver loose | The media isn't fully seated in the port. |
Above the physical layer, Administratively DOWN, Flow Down (tied to a bound management VRRP state), OFFLINE (the board isn't present) and ERROR DOWN(monitor-link) (a downstream interface forced down by an upstream link failure) are administrative or link-status conditions, not the twelve physical causes above — worth telling apart before assuming a cable or optic is at fault.
<HUAWEI> display interface 10GE 0/0/1
10GE0/0/1 current state: UP (ifindex: 6)
Line protocol current state : UP
Last physical up time : 2024-03-28 10:44:55
Last physical down time : 2024-03-28 10:43:49Current Total Sessions is the single field to watch when new connections stop forming while existing ones keep working fine.
<HUAWEI> display firewall session table verbose
Current Total Sessions : NUM
TYPE VPN:SRCVPN --> DSTVPN ID: ID-NUMBER
Zone: SRCZONE--> DSTZONE TTL: TOTALTIME Left: LEFTTIME
Recv Interface: RECVINTERFACE Rev Slot: SLOTID CPU: CPUID
Interface: OUTINTERFACE Nexthop: IP-ADDRESS
<-- packets:NUMBER bytes:BYTES --> packets:NUMBER bytes:BYTES
SRCIP --> DSTIP PolicyName: POLICYNAME
TCP State: TCP StateIf Current Total Sessions has reached the specification ceiling, the handbook's own fix is to lower the session aging time — not to assume an attack is under way. If a specific business flow has no session entry at all, the usual causes are upstream routing not delivering the traffic here in the first place, a security policy denying it, a dynamic blacklist entry, an inbound hardware fault, or bandwidth-management limiting the session count and dropping the new session outright.
display license's License state field is one of five values, and the four that aren't Normal have four genuinely different causes and durations.
| License state | What it means |
|---|---|
| Normal | Correctly activated and current — the state a production License should stay in. |
| Trial | A Normal license degraded to a 60-day trial window, triggered by an ESN mismatch, an expired temporary license, an invalidated license, or a board swap without a matching ESN — a new, correctly matched License needs reapplying. |
| Demo | A genuine evaluation License from activation — functions work normally but on a fixed expiry that needs tracking toward a commercial License. |
| Emergency | A manually triggered disaster-recovery state (license emergency) for genuine emergencies — lasts 7 days, usable up to 3 times total. |
| Default | No License is active, or the previous one has expired or been invalidated — production impact until a valid License is reapplied. |
syslog usually flags a CPU problem before display health confirms it — the handbook's response order runs from immediate containment to long-term capacity.
An Established peer isn't proof the diversion route itself is actually being advertised — check both, in order.
[HUAWEI] display bgp peer
BGP local router ID : 172.16.1.1
Local AS number : 100
Total number of peers : 1
Peers in established state : 1
Peer V AS MsgRcvd MsgSent OutQ Up/Down State PrefRcv
172.16.1.100 4 100 11445 84285 0 0164h59m Established 3
[HUAWEI] display bgp routing-table peer 172.16.1.100 advertised-routes
Total Number of Routes: 3351
Network NextHop MED LocPrf PrefVal Path/0gn
*> 2.2.2.2/32 172.16.1.1 0 100 0 ?
*> 2.2.2.4/32 172.16.1.10 0 100 0 ?If the peer is Established and the route still isn't landing, check for a conflicting host-route static entry to the same destination — it silently takes precedence over the BGP-advertised route.
[HUAWEI] display current-configuration | include 255.255.255.255
ip route-static 192.168.1.137 255.255.255.255 192.168.1.1
// a /32 static route to the same destination blocks BGP diversion -- remove itMatch the situation on the left to the command group on the right.
Diagram labels are kept in English for engineering clarity.
Knowing the command is one thing — reading the output correctly is the part that actually saves time.
SYMPTOMdisplay alarm active verbose reports a Major linkDown alarm, and the instinct is to dispatch someone to check cabling or the optic.
CAUSEThe Description field on this exact alarm carries a Reason= clause, and it can just as easily read Reason=The interface is shut down. as a genuine physical fault — the alarm fires the same way either way.
FIXRead AdminStatus and the Reason= text in the Description field before assuming hardware — an admin shutdown needs a config check, not a truck roll.
Description : The interface status changes. (ifName=Ethernet1/0/2, AdminStatus=DOWN, OperStatus=DOWN, Reason=The interface is shut down.)SYMPTOMdisplay device shows Online: Present, Power: On, Register: Registered for a slot, and it still gets flagged as unhealthy.
CAUSEOnline, Power and Register describe presence and registration, not health. The Alarm column is the one that actually reports condition — Abnormal there means a major or critical hardware alarm exists on that slot right now.
FIXTreat Alarm: Abnormal as the field that matters, and cross-check display device alarm hardware for the specific alarm behind it.
PWR1 - PAH-3000WA Present On Registered Abnormal NASYMPTOMNew connections stop forming while existing sessions keep working fine, and the first assumption is an attack in progress.
CAUSECurrent Total Sessions in display firewall session table can simply be at the specification ceiling from ordinary business growth — bandwidth management can also cap the session count on its own and drop new sessions once that cap is hit, independent of any attack.
FIXCheck Current Total Sessions against the specification limit first; the handbook's documented fix for a genuinely full table is lowering the session aging time, not assuming an attack.
SYMPTOMdisplay license shows a state other than Normal, and it's tempting to treat any non-Normal state the same way.
CAUSETrial is what a Normal license degrades into (ESN mismatch, expired temporary license, invalidated license, or an unmatched board swap) and lasts 60 days. Demo is a genuine evaluation license from the start, on its own expiry. Emergency is manually triggered with license emergency for real disasters, lasts exactly 7 days, and is capped at 3 uses total.
FIXIdentify which of the three it actually is before deciding how urgent the reissue is — Emergency's 3-use cap in particular means it shouldn't be treated as a routine workaround.
SYMPTOMdisplay health confirms SPU CPU utilization at 95% or higher during an active attack, and the instinct is to immediately plan a hardware upgrade.
CAUSEBoard expansion is real capacity, but it isn't available in the next five minutes. The handbook's own sequence starts with a blackhole on the upstream router for the worst-hit IP, protecting everything else sharing that SPU board, then carrier-side rate-limiting in parallel.
FIXBlackhole the worst-hit IP upstream first, engage the carrier for rate-limiting or protocol filtering next, and treat SPU board expansion as the follow-up for sustained load, not the first move.
SYMPTOMdisplay bgp peer shows Established, PrefRcv is non-zero, and diverted traffic still isn't arriving at the cleaning device.
CAUSEA leftover host-route static entry to the same destination outranks the BGP-advertised route in the routing table, so the diversion route the peer is genuinely advertising is never actually installed.
FIXSearch for a conflicting /32 with display current-configuration | include 255.255.255.255 and remove it if found.
[HUAWEI] display current-configuration | include 255.255.255.255
ip route-static 192.168.1.137 255.255.255.255 192.168.1.1Pulled from real maintenance shifts — worth having a ready answer for.
Read the Description field in display alarm active verbose directly — it carries a Reason= clause (for example Reason=The interface is shut down.) that tells you whether AdminStatus or OperStatus actually drove the transition, before you go looking at cabling or the optic.
No. Alarm: Abnormal means the slot already has a major or critical hardware alarm outstanding, viewable in detail with display device alarm hardware; Online, Power and Register only describe presence and registration, not the board's actual health.
Compare display firewall session table verbose against display firewall session table verbose unidirection. A session that only ever went one way usually points at return-path routing or a security policy blocking the reverse leg, not a problem with the session table itself.
No. Trial is what a Normal license degrades into — an ESN mismatch, an expired temporary license, an invalidated license, or a board swap without a matching ESN — and it only runs for 60 days. Demo is what a genuine evaluation license shows from the start, on its own separate expiry. Both need a properly reissued License before they run out.
Configure a blackhole on the upstream router for the IP taking the worst of the attack first, to protect everything else behind the same SPU board. Engage the upstream carrier for rate-limiting or protocol filtering in parallel. SPU board expansion is the long-term fix once the immediate load is under control, not the first step.
Check for a conflicting host-route static entry with display current-configuration | include 255.255.255.255. A /32 static route to the same destination silently takes precedence over the BGP-advertised route and blocks diversion even though the peering session itself is completely healthy.
This is a scenario-grouped command toolbox for Huawei AntiDDoS12000/1900-series detection-and-cleaning appliances, built directly from the AntiDDoS troubleshooting handbook's own quick-maintenance and fault-handling chapters. It isn't a replacement for the alarm-handling reference for every individual AlarmId, and it doesn't cover Flowspec or blackhole configuration syntax itself. For the emergency procedures that reach for several of these same commands under pressure — bypassing a device that's blocking legitimate traffic — see the companion note below.
Send us the output — the alarm, the device or interface status, the session table, or the BGP peer state — and we'll help you read it.