A router that won't come up looks like one problem from the outside, but it's actually several problems stacked in sequence — power, indicator LEDs, console output, and only then whatever the reset-reason log reports once you can finally see it. This is the diagnostic order that finds the fault fastest, with the exact commands and the reset-reason categories behind them.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
What looks like a single dead router is usually four or five different problems stacked in sequence — and each one hides the next until you clear it.
A router that won't come up gets diagnosed backwards more often than not: someone assumes a software or configuration fault before ruling out power, or assumes the hardware is dead before checking whether the console cable is even the right one. The order that actually works is power first, then the indicator LEDs, then whether the serial console produces any readable output at all, and only once you can see the console does it make sense to look at why the device keeps resetting — and whether that reset reason points at a genuine system-software or configuration-file corruption rather than routine churn.
What follows is the fault tree this is built on, the checks for each stage with the exact commands to run, five root causes pulled from the reset-reason model itself, and six FAQ answers — including where this hands off to password recovery or login-lockout recovery once the device is actually up.
Boot failures split into exactly two shapes: there's no console output at all, or the device boots and then resets repeatedly.
Placing the symptom on this tree first tells you whether you're dealing with a physical-layer problem (power, cable, serial settings) or a software/configuration one you can only see once the console is actually readable.
Diagram labels are kept in English for engineering clarity.
Once the console is readable and the device is at least booting, display reset-reason and the six categories behind it (covered below) tell you whether a reboot is routine housekeeping or a genuine corruption signal worth escalating. If the device boots fine but you can't actually log into it, that's a different problem covered in our login lockout recovery guide and our password recovery guide.
Three checks before you can even see the console, then a fourth that reads what the device itself is telling you about why it keeps resetting.
Before assuming a cable, driver or firmware problem, rule out power with a single glance at the panel.
No output, or unreadable garbage, is almost always a parameter mismatch or a bad cable — not a power or firmware fault.
Default serial parameters:
Baud rate : 9600
Data bits : 8
Stop bits : 1
Parity : None
Flow control : NoneOnce the console is readable, display reset-reason gives you a per-board history of every reset and why the device believes it happened.
<Huawei> display reset-reason
The LPU frame[0] board[1]'s reset total 10, detailed information:
-- 1. 03/10 10:58:08, Reset No.: 10
Reason: Reset by user command
-- 2. 03/10 10:31:02, Reset No.: 9
Reason: Reset by user command
...
-- 10. 03/04 22:09:33, Reset No.: 1
Reason: A link fault fails to be rectified.
The MPU frame[0] board[14]'s reset total 10, detailed information:
-- 1. 03/10 10:58:12, Reset No.: 10
Reason: Reset by user commandThe reset-reason table lists well over a hundred distinct strings; in practice they collapse into six buckets that tell you what to do next.
If the reason falls into the exception, hardware or self-healing-corruption buckets, collect this before contacting support rather than after.
<Huawei> system-view
[Huawei] diagnose
[Huawei-diagnose] display reset-reason
[Huawei-diagnose] display inspect black-box record 6 0 0 0
[Huawei-diagnose] display inspect black-box record 8 0 0 0
[Huawei-diagnose] display inspect black-box record 10 0 0 0
[Huawei-diagnose] display inttrace level 1
[Huawei-diagnose] display inttrace level 2
[Huawei-diagnose] display inttrace level 3
[Huawei-diagnose] display lastwords allOnce the stages above have told you where the problem sits, these five explain most of what actually goes wrong — including the two real corruption signals worth taking seriously.
SYMPTOMThe Power LED is lit, but the terminal shows nothing at all, or unreadable characters.
CAUSEThis isn't a power fault — a lit Power LED already rules that out. It's almost always a wrong COM port, mismatched serial parameters, or a bad console cable.
FIXVerify the default serial parameters (9600 baud, 8 data bits, 1 stop bit, no parity, no flow control) and swap in a known-good cable before assuming anything deeper is wrong.
SYMPTOMThe device appears to give up and fully power down after rebooting itself two or three times in a row.
CAUSEPower off the board because of reset three times continuously is a deliberate safeguard: after three consecutive failed warm restarts, the router power-cycles itself rather than looping forever, trading one longer outage for not repeatedly stressing the hardware.
FIXDon't treat the power-down itself as the fault — pull display reset-reason and look at the reason behind the first of the three failed reboots, since that's the actual problem to chase.
SYMPTOMdisplay reset-reason shows Reset by configuration damage, and the running configuration doesn't fully match what you expected to see.
CAUSEThe saved configuration file failed an integrity check at boot time. VRP recovered automatically by rolling back to a known-good configuration rather than booting into a half-applied, corrupted one.
FIXThis is a genuine corruption signal, not routine churn — collect logs, alarms and the current configuration and involve support. In the meantime, the device is running on its rollback configuration, which is why settings look reverted rather than missing.
SYMPTOMThe reset reason cites a signature or package verification failure, with no configuration issue involved at all.
CAUSEThe system software package failed its integrity/signature check while loading — a corrupted or tampered firmware image, not a configuration problem.
FIXThis sits squarely in the category that needs vendor support directly — don't keep re-flashing the same file. Obtain a fresh, verified firmware image, and involve support if the failure recurs after reloading it.
SYMPTOMdisplay reset-reason lists something like Load cfm from sd card, reboot system from cfm, or Reset for normal factory configuration, right when you were bracing for a hardware problem.
CAUSEThese are normal, intentional recovery paths — an SD-card configuration fallback, or a factory-reset command that was actually issued. The reset-reason table mixes routine housekeeping in with genuine corruption signals, and it's easy to over-react to any line that contains the word 'reset'.
FIXCross-check the exact reason string against the six categories (user-triggered, load, software exception, device-management, hardware, self-healing) before treating any single reset entry as an emergency — most of them are not.
Pulled straight from the field — the ones worth having an answer ready for.
Not necessarily a failed PSU specifically, but it does mean the unit isn't receiving power at all — check the outlet, the power cable itself, and whether the PSU is seated and switched on before assuming the PSU has failed outright. Only once power is confirmed reaching the unit and the LED still won't light does the PSU itself become the prime suspect.
9600 baud, 8 data bits, 1 stop bit, no parity, no flow control. Confirm the PC's terminal software matches these exactly and that you've picked the correct COM port before suspecting the cable or the device itself.
Once you can read the console, run display reset-reason and look at the Reason field for the most recent entries. Match the exact wording against the six categories (user-triggered, load, software exception, device-management, hardware, self-healing) rather than assuming the worst from the fact that it's rebooting at all — most reset reasons are routine.
No. A large share of the reasons — user commands, scheduled resets, normal firmware loading during an upgrade, version synchronization after a switchover — are expected behavior, not faults. The ones genuinely worth escalating are software exceptions (deadlock, watchdog, kernel panic), hardware self-test failures, and the two self-healing corruption signals: configuration damage rollback and system-software signature failure.
Without powering the device off, collect the full diagnostic bundle with display diagnostic-information file-name, plus display reset-reason, the relevant display inspect black-box record entries, display inttrace at levels 1 through 3, and display lastwords all. Having all of this ready before the call significantly shortens the time to root cause.
No — that's a separate failure domain. A device that boots cleanly but won't authenticate you is a credentials or access-path problem, not a startup one. See our password recovery guide for console/Telnet/BootROM recovery methods, or our login lockout recovery guide if Telnet, SSH and console access have all stopped working at once.
This note is built around the Huawei AR-series router's VRP reset-reason model and its display reset-reason / display diagnostic-information commands, plus the field-tested recovery guidance behind them. If your device is a different vendor, the exact reason strings and commands change, but the underlying layered diagnosis — power, console, then reading the software's own account of why it reset — carries over directly. It doesn't cover chassis-based multi-slot systems' backplane-level hardware diagnostics in depth, or faults that require physical board-level repair.
Tell us where it's stuck in the chain — power, console, or a specific reason from display reset-reason — and we'll help you read it.