Straight from Huawei's NetEngine AR Quick Maintenance Guide — what to gather before you touch a device someone else configured, the four checks that build a health snapshot in minutes, and the baseline you save before you run a single command that changes anything.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
The guide's advice for taking over maintenance of a device is blunt: get the map and the tools before you log in, not after something breaks.
Huawei's NetEngine AR Quick Maintenance Guide opens its maintenance chapter with a short, two-step recommendation for anyone about to take over responsibility for a device: pull the network topology and the data plan first, then stage the tools you will need — before doing anything else. It is a small step that matters most exactly when it is most often skipped: the first day with a network someone else built, where nobody currently on site wrote down what is actually configured.
What follows is that guide's actual first-day sequence: the map and tools to gather, the four checks that build a health snapshot in a few minutes, and — separately — what to do if you cannot even log in yet.
Six steps, in the guide's own order — each one assumes you are starting from zero.
Diagram labels are kept in English for engineering clarity.
The guide branches at step 3: if you cannot log in at all, this flow does not apply yet — it points you to a separate procedure for devices you cannot log in to instead.
Two things, per the guide, before you touch the device at all: the map, and the tools.
| Category | Item | Purpose |
|---|---|---|
| Documentation | Network topology diagram + data plan | Interfaces, VLANs, IP addresses — printed and posted in the equipment room for quick reference |
| Cable | Standard RS232 serial cable | Console-port login |
| Cable | Serial-to-USB adapter | Console login via the maintenance terminal's USB port |
| Cable | Two straight-through Ethernet cables | Bring up the management port or other services |
| Cable | Fiber patch cords + SFP/eSFP/SFP+ modules | Connect to peer devices |
| Maintenance terminal | Laptop with serial communication software | Logging in to the device |
| Auxiliary instrument | Optical power meter | Optical interface testing — power, receive sensitivity |
If you cannot get a session on the device at all with this kit, the guide routes you to a separate procedure for devices you cannot log in to — that is outside what this checklist covers.
Indicator lights, active alarms, a health-command snapshot, board status — in that order, the guide says, and each one tells you when to stop and escalate.
| Check | Command / Method | What Normal Looks Like |
|---|---|---|
| Indicator lights | Visual check against the silkscreen | SYS slow green blink; ACT solid green = active; PWR/TEMP/FAN/STATUS solid green; STAT slow green blink (solid on 9ES2/4ES2G-S) |
| Active alarms | display alarm active | No Critical or Major entries in the output |
| Health snapshot | display health | Temperature Status = NORMAL, Power State = Supply, Fan Register = YES, CPU usage below 80%, memory usage below 60%, storage usage below 80% |
| Board status | display device | Online = Present, Power = PowerOn, Register = Registered, Alarm = Normal for every board in position |
<Huawei> display alarm active | include Major
1/Independent/2014-10-02 21:38:10/2014-10-02 21:39:00/0xff8c205c/hwCPUUtilizationRising/Major/End/
OID 1.3.6.1.4.1.2011.5.25.219.2.14.1 CPU utilization exceeded the pre-alarm threshold.
<Huawei> display health
Slot Card Sensor No. SensorName Status Upper Lower Temp(C)
11 - 1 SRU-400H TEMP NORMAL 70 0 48
PowerNo Present Mode State Current(A) Voltage(V) Power(W)
9 YES AC Supply N/A 12 350
System CPU Usage Information: SlotID 11 CPU Usage 7% Upper Limit 80%
System Memory Usage Information: SlotID 11 Used 14% Upper Limit 95%
<Huawei> display device
AR6300's Device status:
Slot Sub Type Online Power Register Alarm Primary
14 - SRU-200H Present PowerOn Registered Normal Master
<Huawei> display diagnostic-information dia-info.txt
Info: The diagnostic information was saved to the device successfully.
<Huawei> save logfile
<Huawei> system-view
[Huawei] diagnose
[Huawei-diagnose] save diag-logfileAny check that comes back abnormal has the same next step in the guide: if the documented remediation does not clear it, move to collecting and reporting fault information — not repeating the check.
None of these are exotic edge cases — they are the same handful of mistakes the source guide's own structure warns against.
RISKCPU under 80% and memory under 60% are the guide's pass thresholds, not a guarantee — the guide's own instruction for a high reading is to watch it for five to ten minutes before deciding it is a problem, not to accept or dismiss it on a single snapshot.
SAFER PRACTICETake the health snapshot more than once in your first session, a few minutes apart, before you conclude the device is either fine or already struggling.
RISKThe guide explicitly says to check display cpu-usage and display memory before running display diagnostic-information, and to hold off on the diagnostic dump if either is already elevated — the command itself adds load exactly when the device can least afford it.
SAFER PRACTICECheck CPU and memory first. If either is high, wait for it to settle before pulling a full diagnostic snapshot.
RISKThe same silkscreen means different things on different modules — a solid ACT light means the main control board is active while off means standby, and OUTPUT solid green means cold standby while blinking green means it is actually supplying power. Reacting to a light without checking what it means for that specific module leads to chasing a non-issue.
SAFER PRACTICEKeep the normal-state table open during your first indicator-light pass, and only escalate a light that does not match its own row.
RISKNone of this first-day flow calls for reboot, format or delete — but an unfamiliar device with an unclear configuration is exactly when the temptation to "just restart it and see" is strongest, and exactly when it is least safe to do.
SAFER PRACTICEIf a check fails and the fix is not obvious, collect fault information first — don't reach for a command from our dangerous commands checklist to "test" something on a device you don't understand yet.
RISKEvery check in this guide — indicator lights aside — assumes you can already reach the device through Console, Telnet or STelnet. If you cannot get a session at all, following this flow anyway just burns time on steps that require a login you don't have.
SAFER PRACTICEConfirm you have a working session before starting the health-snapshot checks; if you don't, the guide's own next step is a separate procedure for devices you can't log in to.
The guide's own fault-reporting chapter doubles as the day-one baseline checklist — save this now, before you've made a single change, and you'll have it later when you actually need it.
Pulled straight from the field — the ones worth having an answer ready for.
Per the guide: get the network topology diagram and the data plan (interfaces, VLANs, IP addresses) before anything else, and stage your tools and cables — console cable, adapter, straight-through cables, fiber and SFPs, an optical power meter — so you're not hunting for equipment mid-check.
This checklist's health-snapshot steps all assume Console, Telnet or STelnet access already works. If it doesn't, the guide routes you to a separate procedure for devices you can't log in to, rather than any of the checks covered here.
The guide lists a specific kit: a standard RS232 serial cable, a serial-to-USB adapter for terminals without a serial port, two straight-through Ethernet cables, fiber patch cords with SFP/eSFP/SFP+ modules, and an optical power meter for optical interface testing.
The guide's threshold is CPU under 80% and memory under 60%, but a reading above that isn't an instant verdict — the instruction is to watch it for five to ten minutes. If it stays high, that's when to move to collecting fault information rather than continuing to watch it.
At minimum: a saved configuration plus display current-configuration, a full display diagnostic-information dump, and both log types (save logfile and save diag-logfile) transferred off the device the same day — see the checklist above for the full sequence.
This checklist is built from Huawei's NetEngine AR Quick Maintenance Guide — its "before you take over maintenance" recommendations and its indicator-light, alarm, health-snapshot and board-status checks. It covers the first-day sequence for AR-series routers specifically. What to do when you can't log in at all, hardware fault return procedures, and switch- or firewall-specific handover steps are different chapters of the same guide and aren't covered here.
Send us the device model, software version and what you can already see on the health snapshot — we'll help you figure out what's actually running before you change anything.