Cisco ASR 9001 Password recovery

2025年7月16日 LOG admin

Unable to log in to a Cisco ASR 9001 because you forgot the root login and password? The ASR 9001 runs Cisco IOS XR, and its local user database lives inside the startup configuration — so the classic IOS "0x2142 + copy startup-config running-config" trick does not apply here. Instead you break into ROMMON, change the configuration register so the router boots without a valid administrative account, complete the first-boot Administrative User Dialog, and let IOS XR write a fresh root-system account. This guide covers the full ASR9001 root password recovery, the exact ROMMON commands, the baud-rate gotcha that trips most people up, and how to verify and save the new credentials.

Why the 0x2142 trick does not work on IOS XR

On classic IOS the password lives in the startup configuration in NVRAM, and 0x2142 tells the router to ignore NVRAM while it boots. The router comes up with an empty running configuration, you copy the startup configuration in, replace the password, and save. It is a five-minute job because "running" and "startup" are two copies of one document.

IOS XR is architecturally different in three ways that break that trick.

The configuration is a committed database, not a flat file. IOS XR reads its configuration from the internal filesystem and applies it through the two-stage commit process. There is no "skip loading the configuration" switch that leaves the router usable — bypassing the configuration leaves you with an unconfigured router, not with a router that has all its interfaces up and no password.
Administrative accounts live in the AAA database. The root-system user is created and stored as part of the IOS XR configuration model, and the password is stored as a hashed secret (type 5 in older releases, type 8 or 9 in the XR 7.x family, with type 10 available on newer ones). There is no plaintext password to overwrite in a text file.
Administration is a plane of its own. Routing functions, the XR plane and — on releases that ship it — the System Admin VM each hold their own credentials. Recovering one does not automatically recover the others.

For that reason Cisco's supported recovery path for the ASR 9000 family is the ROMMON route described below: boot the RSP with a configuration register that forces the first-boot dialog, and let IOS XR create a new administrative account from scratch.

Before you start: prerequisites

Assume a single Route Switch Processor (RSP) on the ASR 9001. On a dual-RSP (redundant) chassis, apply the procedure to the primary RSP first — see the troubleshooting section.
A console connection to the RSP console port (RJ-45 or USB) using a terminal that can send a real BREAK signal — PuTTY, SecureCRT, Tera Term, or screen/minicom on Linux and macOS.
Physical or remote-hands access, because you must power-cycle the chassis.
The existing configuration is not erased: this procedure only recreates the administrative user.
A maintenance window. The router stops forwarding traffic while it is in ROMMON and while it boots into the dialog. On a single-RSP 9001 there is no redundant control plane to carry you through, so plan for an outage of twenty to forty minutes including the boot.

Step 1 – Power cycle and send the BREAK sequence

Power off the ASR 9001, power it back on, and during the boot banner send the BREAK signal. In PuTTY press Fn + Break (laptop keyboards) or Ctrl + Break. In SecureCRT or Tera Term use the Send Break menu item. On macOS or Linux with screen, press Ctrl + A then Ctrl + B. Depending on the terminal you may need to press it several times within the first couple of seconds of boot.

The timing window is narrow. The RSP begins its boot sequence within a second or two of power being applied, and the ROM Monitor intercepts BREAK only during the first stage of that sequence. If the router gets past it you will see the normal image-loading banners and you will have to power-cycle again. Practice the key sequence once before you power on, so that the first attempt lands inside the window.

Step 2 – Confirm you are in ROMMON

When the BREAK is accepted you will see the ROM Monitor prompt instead of a login prompt. Nothing from the IOS XR configuration has loaded at this point.

rommon B1>

If you see a login prompt or an image banner instead, the BREAK was too late — power-cycle and try again. The B1 suffix is the boot counter, not a port number, and it increments with each reset; rommon B2>, rommon B3> and so on are normal.

Step 3 – Set the configuration register to 0x142

Tell ROMMON to boot with a configuration register that ignores the saved administrative credentials, then reset the router:

rommon B1> confreg 0x142
rommon B2> reset

0x142 keeps the console at 9600 baud while bypassing the normal startup path, which is why the router drops you into the first-boot dialog rather than the usual login prompt.

Step 4 – Match the console baud rate

After the reset the console speed can appear to change. If you see garbage characters, set your terminal to 9600 baud, 8 data bits, no parity, 1 stop bit (8N1), with no flow control. In PuTTY: Connection → Serial → Speed = 9600. When the terminal matches, the router prints:

router con0/0/CPU0 is now available

Press RETURN to get started.

Step 5 – Complete the administrative user dialog

Press Return and IOS XR starts the Administrative User Dialog. Enter a new root-system username and secret (password), then confirm it:

--- Administrative User Dialog ---

Enter root-system username: admin
Enter secret:
Enter secret again:

Choose a username and password that follow your organisation's naming and password policy. The secret you enter becomes the privilege-15 / root-system password for the local administrative account.

Step 6 – The configuration register resets automatically

Once the new account has been saved, IOS XR restores the configuration register to its previous value — typically 0x102 (9600 baud console, normal boot). There is no manual step required to change it back.

Step 7 – Log in and save the configuration

RP/0/RSP0/CPU0:router# copy running-config startup-config

While you are there, confirm the register value and the local user database:

RP/0/RSP0/CPU0:router# show configuration | include config-register
RP/0/RSP0/CPU0:router# show running-config username

What the configuration register actually controls

It helps to know what the value you typed means, because it explains both the symptom and the recovery. The configuration register is a 16-bit value that the ROM Monitor reads before the operating system loads. The low bits control the console line speed and the console behaviour, the middle bits control how the router sources its startup configuration, and the high bits control break handling and boot behaviour. 0x142 sets the "ignore the saved configuration, start from the first-boot path" combination while holding the console at 9600 8N1; 0x102 — the value the router normally carries — is the same register with the bypass bits cleared.

Two practical consequences follow. First, the register is a router-wide setting, not a per-user one, so the change affects every subsequent boot until it is cleared. Second, if the automatic restore in Step 6 does not happen on your release, you must set the register back by hand from configuration mode, or the router will keep booting into the first-boot path:

RP/0/RSP0/CPU0:router(config)# config-register 0x102
RP/0/RSP0/CPU0:router(config)# commit

ROMMON command reference for the procedure

You only need a handful of commands to finish a recovery, but knowing the rest of the environment helps when something goes wrong:

set — prints every environment variable currently set, including the image the router will boot and the console settings. set BOOT shows the boot image path.
confreg 0x142 — writes the configuration register value that drives the recovery boot.
dir — lists the filesystems visible to ROMMON. dir bootflash: shows the images and package files, which is how you confirm an image is present before booting manually.
boot <image> — boots a specific image instead of the default one. Use this when the router refuses to start from the configured image after the register change.
unset BOOT / set BOOT <image> — clears or redefines the boot target when the saved path points at a file that is no longer there.
reset — performs a warm reset; this is the command that applies the register change.
sync — flushes pending writes, worth running before you power the chassis off from ROMMON.
help — lists the ROMMON command set for your release; the available commands differ between IOS XR generations.

Nothing in ROMMON is committed automatically. If you change the boot variable and then power off without booting, you have changed a persistent variable on the RSP — note what you changed so the next engineer is not surprised.

Alternative: create a second account if you still have any admin access

If a second administrative account with sufficient privilege still works, use it instead of the ROMMON route. It is faster, it needs no outage, and it leaves the configuration register untouched:

RP/0/RSP0/CPU0:router# configure terminal
RP/0/RSP0/CPU0:router(config)# username rescue group root-system
RP/0/RSP0/CPU0:router(config-un)# password
RP/0/RSP0/CPU0:router(config-un)# commit

Add the new account to a group with administrative rights — on IOS XR those are the predefined groups such as root-system, root-lr and cisco-support. Then log in with the new account and reset the password of the account you lost. This is also the sane path when you have locked yourself out of the XR plane through a bad AAA configuration: if the router still accepts a locally defined account, you can repair the AAA configuration with a single commit.

The System Admin VM and the disaster-recovery account

On ASR 9000 releases that carry the System Admin VM, the chassis has an administrative plane in addition to the XR plane, and it has its own credentials. If the account you lost is the XR root-system account, the ROMMON procedure above is the right tool. If the account you lost is the chassis administrator for the System Admin plane, the XR recovery does not help, and you are in either of these two situations:

You still have a working XR administrative account. Log in to XR, enter the system administration mode and set a new administrative password from there.
You have neither. Newer releases provide a disaster-recovery username and password that can be pre-configured precisely for this case, and Cisco's documented fallback beyond that is recovery using PXE boot or an external bootable USB. Both are larger operations than the ROMMON procedure and should be planned as such.

The lesson worth taking away is organisational: record the disaster-recovery credentials somewhere the on-call engineer can reach, otherwise a forgotten password turns into a site visit plus firmware-level recovery.

After recovery: verify and harden the new account

show running-config username — confirm the accounts you expect exist, and that no unexpected account was left behind.
show configuration | include config-register — confirm the register is back at its normal value.
show users and show logging | include login — confirm no one else is attached, and review the attempt history around the window.
Confirm the password's storage type. Modern XR releases default to a strong hash; if your configuration shows an old plain type, migrate the account with a secret form that uses the stronger algorithm your release supports.
If the router authenticates against TACACS+ or RADIUS in normal operation, verify that path still works too, so that a local-account recovery does not mask a broken AAA reachability problem.
Save the configuration, and take a copy off the box — the configuration management commands that let you roll back a bad commit are covered in Cisco IOS XR Configuration Management: Commit, Rollback and Replace.

Troubleshooting

BREAK is ignored: a USB-to-serial adapter without proper driver support cannot transmit a real BREAK. Try another adapter or driver, or use Ctrl + Break from a native serial tool.
Garbage on screen after reset: baud-rate mismatch — set the terminal back to 9600 8N1 and reconnect.
Dual-RSP chassis: repeat the procedure for the standby RSP, or perform a clean install. A user database that differs between RSPs can stop the standby from syncing.
Completely blank console: verify the cable and that you are connected to the RSP console port, not an auxiliary or management port.
The router boots into ROMMON again instead of the dialog: the RSP never loaded an image. Check dir bootflash: from ROMMON, then boot the image explicitly with boot. A line card or RSP stuck in an inactive state at this point is a firmware problem rather than a password problem — see Cisco ASR 9901 SW_INACTIVE Fix: FPD Firmware Reflash Guide.
The dialog appears but the new password is rejected at login: the account was created in a console session that was never committed. Log in, create the account with an explicit commit, and verify with show running-config username.
Registration or FPD prompts during boot: let them finish. Interrupting the first boot after a register change can leave the RSP with an incomplete image activation.

FAQ

Does this procedure erase the router configuration? No. The interfaces, routing protocols, VRFs and MPLS configuration remain in place; only the administrative account is re-created. That is the whole point of using the register value rather than a factory reset.

Will the router lose its config if the reload is interrupted? The startup configuration is written to internal storage, so a power failure during ROMMON does not normally cost you the configuration — but an incomplete package activation can cost you a boot slot. Boot cleanly and let the RSP complete its startup before you touch anything.

Can I do this over a management network instead of console? No. The BREAK sequence is a serial-console signal. If you have out-of-band console access through a terminal server, you can send the break remotely — the terminal server sends it on the wire exactly as a local terminal would.

How long does the whole thing take? Five to ten minutes of hands-on work, plus the RSP's boot time — plan for a maintenance window of at least thirty minutes. If you have to hunt for a working serial adapter, double it.