The moment a Huawei router or switch starts misbehaving, what you collect in the first few minutes decides whether the next step is a fix or a second round-trip. This is the collection order taken straight from Huawei's own AR router maintenance handbook and the Sx3 switch handbook: one command that grabs almost everything, a baseline checklist, log and counter collection done right, and a cheat sheet of exactly what to pull once you already suspect a specific fault type.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The goal isn't more data — it's the specific data that lets someone else locate the fault without a second phone call.
Huawei's own switch maintenance handbook opens its diagnostics chapter with a blunt instruction: when you can't pin down the cause yourself, collect the relevant fault information and hand it to the reseller or to Huawei's own support for localization. What that means in practice is three things every time — the time and topology the fault happened in, the device's own identity and state (name, version, current configuration, interface information), and whatever logs and alarms were generated when it happened.
What follows is that collection work in order: the one command that grabs almost all of it in one pass, a baseline checklist of the display commands worth knowing by name, how to collect logs and reset counters without lying to yourself about what's actually live, and a cheat sheet of what to pull once you already have a working theory about which subsystem is at fault — IPSec, OSPF, BGP, DHCP, an unexpected reboot, or ARP.
One command, bundling the output of dozens of others — worth running before anything fault-specific.
display diagnostic-information collects the device's boot configuration, current configuration, interface information, clock, software version and more in a single pass — effectively a batch run of the display commands most people would think to run one at a time anyway.
<HUAWEI> display diagnostic-information dia-info.txt
This operation will take several minutes, please wait.........................
................................................................................
...
Info: The diagnostic information was saved to the device successfully.On an AR router, the same command can write straight to a .tar archive, and on a chassis with two main-control boards, the master and the standby each need their diagnostic information pulled separately.
<Huawei> display diagnostic-information xxx.tar
<Huawei> diagnose
[Huawei-diagnose] local-telnet slave
<Huawei> display diagnostic-information xxx.tarSkip the direct-to-terminal display and give it a file name — the output is long, and a saved file is what a support engineer actually wants attached to the ticket.
The display commands worth knowing by name, independent of what the fault turns out to be.
| Information | Command | Why it matters |
|---|---|---|
| Basic information | display diagnostic-information | The one-shot bundle above — provide this on any support request regardless of fault type. |
| Device information | display device | Flags a board in Abnormal status — the first thing to check when a specific board is suspect. |
| Interface information | display interface | Physical state, configuration and packet counters for an interface — the standard first stop for interconnect faults or packet loss. |
| Version information | display version | Software, BootROM, main-control, interface-board and fan-module versions, plus memory sizes — often the first thing a support engineer will ask for. |
| Patch information | display patch-information | Current patch package version and name — matters because behaviour can differ meaningfully between patch levels. |
| Electronic label | display elabel | Hardware identity and manufacture information — needed for an RMA or hardware return. |
| Device health | display health | Temperature, power, fan, power draw, CPU/memory usage and storage usage in one view. |
| Current configuration | display current-configuration | What the device is actually running right now — supports regular-expression filtering to narrow it down. |
| Saved configuration | display saved-configuration | What the device will load on its next boot — useful when the device came up but isn't behaving as configured. |
| Clock | display clock | Pins down exactly when the fault happened — essential for correlating with logs and alarms. |
| User log | display logfile buffer | Run from the diagnose view; shows the buffered user-facing log. |
| Diagnostic log | display diag-logfile buffer | Also from the diagnose view; the lower-level diagnostic log, distinct from the user log. |
| Alarm information | display trapbuffer | The information center's Trap buffer — the fastest way to see what alarms actually fired. |
| Memory usage | display memory-usage | Add slot slot-id for an interface board's memory; omit it for the main-control board's. |
| CPU usage | display cpu-usage | Same slot logic as memory usage — main-control by default, interface board with slot slot-id. |
A log you forgot to save and a counter you forgot to clear both tell the wrong story.
Pulling the actual log files
save logfile and save diag-logfile write the buffered log content to files under flash:/logfile/, which can then be pulled off the device over FTP/TFTP.
<HUAWEI> save logfile
<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] save diag-logfileResetting counters before you trust them
display interface and display ip interface show statistics accumulated since the device booted or since the counters were last cleared — not since the problem started. Clear them first, generate fresh traffic, then read again.
Input: 736 packets, 344842 bytes
Unicast: 0, Multicast: 714
Broadcast: 22, Jumbo: 0
Discard: 0, Total Error: 0
Output: 2911 packets, 514228 bytes
Unicast: 0, Multicast: 2910
Broadcast: 1, Jumbo: 0
Discard: 0, Total Error: 0A nonzero Total Error here only tells you something happened at some point since the last clear — reset the counter, re-test, and re-read before treating it as a live problem.
Once you already have a working theory about which subsystem is at fault, this narrows it down fast.
| Fault category | Commands to run | What you're looking for |
|---|---|---|
| IPSec | display ike error-info verbose [ peer remote-address ] display ike proposal number display ipsec sa display ike peer name peer-name display ipsec statistics display ipsec global config debugging ikev1 all / debugging ikev2 all / debugging ipsec all | display ike error-info verbose gives the actual IKE negotiation failure reason directly, instead of making you infer it from a bare "down" state. |
| OSPF | display ospf routing ipv4-address verbose display ospf peer verbose debugging ospf event debugging ospf packet hello | display ospf peer verbose shows per-neighbor state detail well beyond a plain up/down. |
| BGP | display bgp peer ipv4-address log-info display bgp routing-table ipv4-address debugging bgp [ peer ipv4-address ] all | display bgp peer log-info surfaces the neighbor Down error code directly — the fastest read on why a session flapped. |
| L2TP / PPP | display l2tp session-down-reason display l2tp tunnel-down-reason display ppp state all debugging l2tp all / debugging ppp all | The two down-reason commands exist specifically because an L2TP tunnel or session doesn't just report "down" — it logs why. |
| DHCP | display dhcp configuration display dhcp client / display dhcp client statistics display dhcp relay configuration / statistics display dhcp server configuration / statistics display ip pool interface interface-type interface-number debugging dhcp client / relay / server all | DHCP has three distinct roles — client, relay, server — and the collection commands are role-specific; pulling relay statistics from a box acting as server won't show you anything useful. |
| Unexpected restart | display reset-reason display inspect black-box record 6/8/10/11/12/13 0 0 0 display lastwords all display kernel-logbuf last | All of these are built to survive the reboot itself, specifically to answer "why did it restart" after the fact. |
| ARP | display arp history debugging arp packet | display arp history shows how an entry actually changed over time, not just its current snapshot. |
The same handbook covers further categories in the same format — SNMP, BFD, voice, 3G/LTE/5G modem faults and NQA among them — following the identical pattern: a display command for state, a debugging command for the live trace.
The collection commands themselves have sharp edges — these are the ones that catch engineers off guard.
SYMPTOMCPU usage spikes right when display diagnostic-information is run on a device that's already under load or mid-incident.
CAUSEThe command batches many display commands together and is explicitly documented as something that can raise CPU usage while it runs — and running it from several terminal sessions on the same device at once can push CPU noticeably higher still.
FIXDon't run it redundantly from multiple sessions at once, and don't make it routine housekeeping on a healthy device — save it for when the information is actually needed for a handoff.
<HUAWEI> display diagnostic-information dia-info.txtSYMPTOMA debugging xxx command is entered and nothing shows on screen — or, the opposite problem, debugging is left running well after the incident and starts competing for CPU with everything else.
CAUSEDebugging information isn't printed to a terminal session unless terminal debugging and terminal monitor are both explicitly turned on, with debug timeout 0 set so it doesn't time out unexpectedly mid-collection — and it stays on until someone explicitly turns it back off.
FIXRun the three-line preamble before any debugging command, collect for a bounded window, then explicitly undo both settings afterward.
terminal debugging
terminal monitor
debug timeout 0
...
undo terminal debugging
undo terminal monitorSYMPTOMdisplay interface shows Total Error greater than zero, and it's tempting to conclude the port is actively broken right now.
CAUSEThose counters accumulate from device boot, or from whenever they were last manually cleared — a nonzero Total Error might be leftover from something that happened days or weeks ago, not what's happening right now.
FIXClear the counters, generate fresh traffic with ping, then re-read the same display command — only the delta during that window tells you whether the problem is live.
reset counters interface ethernet 1/0/0
ping ...
display interface ethernet 1/0/0SYMPTOMMirroring a port's traffic to Wireshark on a laptop to chase a packet-level fault feels like a purely technical step.
CAUSEThe vendor's own documentation flags this feature 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 — not something to reach for automatically.
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.
[Router] observe-port interface ethernet 5/0/0
[Router] interface gigabitethernet 0/0/0
[Router-GigabitEthernet0/0/0] mirror to observe-port inboundSYMPTOMA chassis with two main-control boards fails over or misbehaves, and the diagnostic information collected only tells half the story.
CAUSEdisplay diagnostic-information run on the active main-control board only captures that board's state — the standby board keeps its own state and has to be reached separately to pull its own diagnostic file.
FIXFrom the diagnose view, use local-telnet slave to reach the standby board and run display diagnostic-information there too, so both boards' information reaches whoever is troubleshooting.
<Huawei> diagnose
[Huawei-diagnose] local-telnet slave
<Huawei> display diagnostic-information xxx.tarIn order — from "something's wrong" to "attached to the ticket".
Diagram labels are kept in English for engineering clarity.
The questions that come up first once someone actually opens a support ticket.
Start with display diagnostic-information (or the switch's dia-info.txt form) plus display clock for an exact timestamp, and write down the topology, what triggered the fault, and what's actually failing — before touching any fault-specific command.
No — debugging is invasive and should stay scoped to one category you already suspect, for example debugging ospf packet hello only once OSPF is the working theory, wrapped in terminal debugging / terminal monitor / debug timeout 0, run for a bounded window, then explicitly turned back off.
save logfile, run from the user view, saves the operational user-facing log; save diag-logfile, run from the diagnose view, saves the lower-level diagnostic log. Support engineers may ask for either one depending on what they're chasing, and sometimes both.
Yes — display reset-reason, the several display inspect black-box record variants, display lastwords all and display kernel-logbuf last are all built specifically to survive the reboot and answer "why did it restart" after the fact.
Both. The baseline checklist — one-shot capture plus device, version, interface, configuration and log information — applies to almost anything and is worth collecting first regardless of the fault. The by-fault-category table narrows it down further once a working theory already exists: IPSec, OSPF, BGP, DHCP, an unexpected reboot, or ARP.
This is a collection guide, not a root-cause guide. It's built from the AR router maintenance handbook's own appendix on information collection and diagnostic commands, cross-checked against the equivalent chapter in the Sx3 switch maintenance handbook. Once a specific fault type is already confirmed — an IPSec tunnel or an OSPF neighbor that won't come up, for instance — the deeper root-cause walkthrough for that one fault type is its own separate note, not this one.
Send us the diagnostic-information file and whatever fault-category output you pulled — we'll help you read it.