Once you already know which subsystem to check on a CloudEngine leaf or spine switch, this is the command to reach for — grouped the way an engineer actually thinks about it: hardware, interface and packet loss, MAC/ARP table entries, protocol (OSPF, BGP, VXLAN, M-LAG), and traffic (mirroring, QoS). Every command here is taken directly from the CloudEngine 16800/9800/8800/6800 maintenance handbook's own diagnostic command chapter.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
One tells you what to collect before you escalate. This one is the dictionary you reach for while you're still trying to find it yourself.
Our Fault Information Collection Checklist covers the collection order to follow the moment something misbehaves — the one-shot capture, a baseline checklist, log handling, and a cheat sheet organized by fault type (IPSec, OSPF, BGP, DHCP, reboot, ARP), platform-agnostic across Huawei routers and switches. This note is narrower and more specific: it is the CloudEngine 16800/9800/8800/6800 series maintenance handbook's own chapter on common information collection and diagnostic commands, reorganized into the five scenario groups a data center engineer actually thinks in.
Those five groups are hardware (boards, power, fans, optics), interface and packet loss (link state, counters, CPU-defend drops), table entries (MAC and ARP), protocol (OSPF, BGP, VXLAN tunnels, M-LAG peer state), and traffic (mirroring a port to chase a capture, or reading whether a traffic policy actually matched anything). Match the symptom to a group, and the right command is usually one of two or three.
The same baseline bundle applies here as anywhere else — grab it first, then go looking for the scenario-specific command.
display diagnostic-information collects the device's boards, current configuration, interface information, clock, software version and more in a single pass. Give it a file name so the output lands on flash rather than scrolling past on the terminal.
<HUAWEI> display diagnostic-information dia-info.txt
100%
Info: The diagnostic information was saved to the device successfully.From V300R022C10 onward there is a lighter alternative when only the logs, KPI data and PADS files are actually needed rather than the full display bundle: collect diagnostic information, run from the user view or the diagnose view, which zips the current log directory straight to diagnostic_information.zip under flash.
<HUAWEI> collect diagnostic informationThis command is documented as one that can raise CPU usage while it runs — avoid it over a serial console, avoid running it from more than one terminal session at once, and don't make it routine housekeeping on a healthy device.
Match the symptom, then run two or three commands — not the whole handbook.
Hardware
| Command | What it tells you |
|---|---|
| display device | Per-board status — a board reporting Abnormal is the first thing to confirm. |
| display device alarm hardware | Power, fan and temperature alarms actually raised on the box. |
| display device power system | Power draw against supply capacity — the check before inserting another board or optic. |
| display device elabel | Hardware identity and manufacture information, needed for an RMA. |
| display device board reset slot-id | Run from the diagnose view — the recorded reason a specific board actually reset. |
Interface & Packet Loss
| Command | What it tells you |
|---|---|
| display interface | Physical state, configuration and packet counters — the standard first stop for a suspect link. |
| display interface transceiver verbose | Optical transmit/receive power, for a link that's up but unreliable. |
| reset counters interface / ping / display interface | Clear, generate traffic, re-read — the only way the counters reflect this window, not the last few weeks. |
| display cpu-defend statistics packet-type packet-type | Packets actually being rate-limited or dropped by CPU-plane protection — a packet-loss cause that display interface alone won't surface. |
Table Entries — MAC & ARP
| Command | What it tells you |
|---|---|
| display mac-address | MAC-VLAN-port mapping — the first stop when traffic is forwarding to the wrong place. |
| display mac-address flapping | The live record of a MAC address moving between ports or VLANs, with a MoveNum counter. |
| display mac-address flapping aged-table | Flap records that have already aged out of the live table above — see Gotcha 2 for why this matters. |
| display arp | ARP entry type and state for a given IP — confirms whether the gateway's own table is the problem. |
| display arp statistics | ARP table counters, for a broader view of table churn. |
Protocol — OSPF, BGP, VXLAN, M-LAG
| Command | What it tells you |
|---|---|
| display ospf peer verbose | Per-neighbor state detail well beyond a plain up/down. |
| display bgp peer ipv4-address log-info | The neighbor Down error code directly — the fastest read on why a session flapped. |
| display vxlan troubleshooting | An automated one-click check against a library of known VXLAN fault signatures — see Gotcha 3 for its limits. |
| display vxlan tunnel | Actual tunnel and VTEP peer state for the overlay. |
| display dfs-group / display dfs-group consistency-check global | M-LAG peer status, and a purpose-built check for configuration drift between the two peer devices. |
| display dfs black-box module | A per-module state snapshot (arp, bridge-domain, adjacency and more) — run on both M-LAG peers, see Gotcha 4. |
[~Device1] display vxlan troubleshooting
[~Device1] display vxlan tunnel
<HUAWEI> display dfs-group
<HUAWEI> display dfs-group 1 consistency-check global
[~HUAWEI-diagnose] display dfs black-box arp
[~HUAWEI-diagnose] display dfs black-box bridge-domainTraffic — Mirroring & QoS
| Command | What it tells you |
|---|---|
| display port-mirroring | Confirms the observe-port and mirror-port pairing actually matches what was configured. |
| display interface brief (Input on the mirror port, Output on the observe port) | Confirms mirrored traffic is actually arriving at the observe port before blaming the capture tool. |
| observe-port / mirroring / port-mirroring observe-port | The configuration commands themselves — see Gotcha 5 on the privacy line before enabling them. |
| display traffic-policy statistics interface interface inbound/outbound | Whether a traffic policy is actually matching, and what it's doing to the packets that hit it. |
[~HUAWEI] observe-port 1 interface 25GE1/0/1
[*HUAWEI-25GE1/0/2] port-mirroring observe-port 1 inbound
<HUAWEI> display port-mirroring
[~HUAWEI] display traffic-policy statistics interface 100GE 1/0/1 inboundThis applies to every group above that touches a counter — it's worth doing right once, not per-scenario.
display interface and display ip interface report statistics accumulated since the device booted or since the counters were last cleared — not since the problem started. On a spine-leaf fabric with ports that have been up for months, that accumulated history gets in the way of reading what's happening right now.
reset counters interface 100GE 1/0/1
ping -c 20 10.0.0.2
display interface 100GE 1/0/1A nonzero Total Error after this sequence is worth chasing. Before the reset, it only proves something happened at some point since the last clear.
The commands above have sharp edges of their own — these are the ones that catch DC engineers off guard.
SYMPTOMdisplay diagnostic-information ties up a serial console session for a long time, or CPU usage climbs noticeably when it's run from two terminals at once.
CAUSEThe command is explicitly documented as one that raises CPU usage while it runs, and a serial connection is slow enough that a long diagnostic dump ties up the whole session — running it redundantly from multiple sessions compounds both problems.
FIXUse Telnet or STelnet rather than a serial console for this specific command, never run it from two sessions at once, and on V300R022C10 and later reach for collect diagnostic information instead when only the logs are actually needed.
<HUAWEI> display diagnostic-information dia-info.txtSYMPTOMdisplay mac-address flapping keeps reporting the same MoveNum value no matter how long the underlying flapping continues, making it look like the moves have stopped.
CAUSEMoveNum is a bounded counter that caps at 65535 — once it saturates it simply stops incrementing, even though the MAC address is still moving between ports or VLANs in the background.
FIXDon't read a static MoveNum as proof the flapping stopped — cross-check display mac-address flapping aged-table for the historical record, and confirm current behaviour against trapbuffer alarms rather than the live counter alone.
<HUAWEI> display mac-address flapping
<HUAWEI> display mac-address flapping aged-tableSYMPTOMdisplay vxlan troubleshooting comes back clean, but tenants still can't reach each other across the fabric.
CAUSEThe command auto-matches an Event Description against a defined library of known VXLAN fault signatures — a genuinely novel failure, or one sitting in an adjacent subsystem such as bridge-domain mapping, the underlying IGP, or M-LAG peer-link state, falls outside what it's designed to catch.
FIXTreat a clean result as one data point, not a clearance — pair it with display vxlan tunnel for actual tunnel and VTEP state, and display mac-address bridge-domain for the specific bridge domain in question.
[~Device1] display vxlan troubleshooting
[~Device1] display vxlan tunnelSYMPTOMdisplay dfs black-box arp, or any of the other black-box module variants, looks fine on the device being investigated, yet the M-LAG pair keeps behaving as though the two devices disagree about something.
CAUSEEach display dfs black-box module command captures only the device it's run on — an M-LAG pair is two independent devices synchronizing state over a peer-link, and a discrepancy only shows up by comparing both sides.
FIXPull the same black-box output from both peer devices, or lead with display dfs-group consistency-check global, which exists specifically to catch configuration drift between the two before concluding the state is actually consistent.
[~HUAWEI-diagnose] display dfs black-box arp
<HUAWEI> display dfs-group 1 consistency-check globalSYMPTOMConfiguring observe-port and pointing a capture tool at it to chase a packet-level fault between leaf and spine feels like a purely technical step.
CAUSEThe vendor's own documentation flags mirroring as something that may involve capturing or storing the content of someone's actual communications, and states it should only be enabled within whatever scope local law actually allows — the fact that the port sits inside a data center fabric rather than a campus network doesn't change that line.
FIXConfirm scope and authorization before configuring an observe-port and mirroring live traffic to it, especially before pointing a capture tool at the mirrored feed.
[~HUAWEI] observe-port 1 interface 25GE1/0/1
[*HUAWEI-25GE1/0/2] port-mirroring observe-port 1 inboundMatch the symptom on the left to the group on the right.
Diagram labels are kept in English for engineering clarity.
The questions that come up first once someone actually opens the command dictionary.
That note covers the collection order to follow before you escalate a fault to support — one-shot capture, baseline checklist, log handling, and a cheat sheet by fault type, platform-agnostic across Huawei routers and switches. This one is the day-to-day command dictionary for CloudEngine data center switches specifically, organized by the five scenario groups you already reach for once you have a working theory.
Start with display diagnostic-information (or collect diagnostic information on V300R022C10 and later) for the baseline snapshot, then match the symptom: a board, power or fan issue is Hardware; a link that's up but dropping packets is Interface & Packet Loss; traffic forwarding to the wrong place is Table Entries; a routing or overlay session that won't form is Protocol; anything involving a capture or a traffic-policy hit count is Traffic.
display mac-address flapping shows the live flapping record and its MoveNum counter; the aged-table variant shows entries that have already aged out of that live table. This matters because MoveNum caps at 65535 and stops incrementing once saturated, so the aged history can show flapping the live view no longer reflects.
No — it's an automated pattern match against known VXLAN fault signatures, not a full diagnosis. Pair a clean result with display vxlan tunnel for actual tunnel and VTEP state, and with display mac-address bridge-domain for a specific tenant.
Both. Every display dfs black-box module command only reports the device it's run on, so a discrepancy between the pair only becomes visible by comparing both sides — or by running display dfs-group consistency-check global, built specifically to surface that kind of drift in one command.
Yes — display diagnostic-information file-name is the same one-shot bundle regardless of platform, and from V300R022C10 onward collect diagnostic information adds a lighter option that zips just the log, KPI and PADS files into diagnostic_information.zip without the full display bundle.
This is a command dictionary, not a root-cause guide. It's built from the CloudEngine 16800/9800/8800/6800 maintenance handbook's own chapter on common information collection and diagnostic commands, cross-checked against the hardware, MAC, ARP, VXLAN and M-LAG fault-handling chapters in the same handbook. For the collection order to follow before escalating any fault, see the Fault Information Collection Checklist. Once a specific fault type is already confirmed — a port that's physically down, or CPU usage pinned high — the deeper root-cause walkthrough is its own separate note, not this one.
Send us the output and which group it came from — hardware, interface, table entries, protocol or traffic — and we'll help you read it.