ExtremeXOS密码回复

2025年7月29日 LOG admin

Losing the admin password on an ExtremeXOS (EXOS) switch is a recoverable event — but only if you have console access. ExtremeXOS deliberately offers no remote or mechanical way to clear a configuration, so the recovery path runs through the boot ROM. This article documents the factory-default recovery procedure: resetting the switch to its default configuration from the boot ROM, then logging in with the default credentials and saving the blank configuration over the old one.

Objective and scope

Reset a switch to the factory default config from the boot ROM, because the admin password is unknown and there is no other account available.

Environment covered by this procedure:

Platform: Summit (all EXOS-capable Summit and BlackDiamond chassis blades), and by extension the EXOS software family.
Software: EXOS — all versions.
Boot ROM: all boot ROM versions except 2.0.2.1, for the reason explained below.

What you gain is full administrative access again. What you lose is the entire stored configuration, because the recovery works by discarding it. Plan for that before you start.

Background: why the console port is mandatory

On most switches there is a "reset" or "mode" button, a recessed pinhole, or a documented escape sequence over the network. ExtremeXOS has none of these for clearing a configuration. There is no mechanical process such as a switch to clear the config, which means console access is mandatory.

The reasoning is straightforward once you see the boot order. The saved configuration — including the user accounts and their password hashes — lives in the persistent configuration store. That store is only reachable at two points: from a running EXOS image, which demands a login, or from the boot ROM, which runs before any configuration is loaded and therefore before any account is checked. Clearing the configuration at the boot ROM level is what breaks the loop.

It follows that if you have no console access and no valid account, there is no software-only path in. Restoring a configuration backup will not help either, because loading a configuration also requires a login. Console access is the prerequisite for everything that follows.

Prerequisites

Physical console access to the switch — an RJ-45 console cable, or USB-to-serial adapter, and a terminal emulator such as PuTTY, SecureCRT, screen or Minicom.
Console settings: 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control is the common ExtremeXOS default. A wrong baud rate produces a completely blank screen.
Ability to power-cycle the switch, because both procedures begin with a reboot. On a stack or chassis, be aware that power-cycling affects the whole unit.
Acceptance of configuration loss. If somebody still has a copy of the configuration — a saved script, a TFTP backup, a previous admin's notes — collect it before you reset.
A maintenance window. The switch will be down and then unconfigured.

Procedure: Summit X870 (GRUB menu)

The X870 family boots through GNU GRUB rather than the classic boot ROM prompt, so the recovery is menu-driven:

1. Power cycle the switch while connected to the console port.
2. When you see the GNU GRUB menu, select one of the below options:
     EXOS: Primary   - 22.x.x.x - default configuration
     EXOS: Secondary - 22.x.x.x - default configuration

Both menu entries boot the corresponding EXOS image with the default configuration rather than the saved one. You do not need to know the password to pick an entry — GRUB runs before EXOS does. When the switch comes up, it is running a factory-default configuration.

Procedure: all other EXOS switches (boot ROM)

1. Power cycle the switch while connected to the console port.
2. When prompted, press and hold the spacebar to enter the boot ROM.
3. At the boot ROM prompt, type the command:  config none
4. Type the command:  boot
5. Once the switch boots up to EXOS, save the config with the command:  save
   (this overwrites the old config with the new, blank config)

The order matters. config none clears the in-memory configuration pointer and the startup configuration reference; boot then continues the normal boot path, but with nothing to load, EXOS starts from factory defaults. Step 5 is the step people forget: until you run save, the old configuration is still sitting in persistent storage, and the next reboot will load it again — password and all.

Logging in after the reset

Once EXOS is up with the default configuration, the switch has no user-defined accounts. Log in with the default credentials:

login: admin
password: <press Enter>

If the banner still appears after using the config none command, still log in with the default username and password anyway. The banner can be stored in a different part of the memory, so it displays before EXOS is fully loaded and before the configuration was read. A login banner is therefore not evidence that your reset failed.

If an empty password is rejected, try the documented admin / admin pairing for your EXOS release — behaviour has varied across versions and platforms. What matters is that a factory-default EXOS image does not carry your old account's password hash.

Now commit the blank configuration over the old one and confirm:

save
show version
show configuration
show accounts

show configuration should show essentially nothing beyond defaults, and show accounts should list only the built-in admin account. Set a new password immediately:

configure account admin

Stacks and multi-slot chassis

On a Summit stack, the saved configuration is stored per node, and the stack forms around whichever node wins master election. Running the boot ROM recovery on the master therefore returns the stack to a default configuration, but the member nodes still hold configuration files of their own. After the master comes up defaulted, bring members up one at a time and confirm each one joins cleanly rather than re-importing an old configuration — if a member does re-adopt stale settings, clear it the same way on that node. On a BlackDiamond chassis the same logic runs across management and I/O modules: recover the management module that owns the running configuration, then verify with show slot that every slot is present and in the expected state before you restore service.

What the recovery does not do

It is worth being precise about the boundaries of this procedure, because several commonly assumed side effects do not happen. The recovery does not reflash or downgrade the EXOS image, does not reset the boot ROM version, does not touch license files, and does not clear the switch's serial number or identity. It discards the configuration — accounts, VLANs, routing, monitoring settings and any partially completed changes that were never saved. That is also why it is the correct tool for a forgotten password: the password is a configuration object, and the configuration is exactly what you are allowed to remove from the boot ROM without authenticating.

Boot ROM version caveats

In Boot ROM v2.0.2.1, the config none command has been removed for security reasons. It was added back into Boot ROM v2.0.2.3.
If the config none command is not present, the only way to default the switch from boot ROM is by loading a rescue image (see the boot ROM menu's TFTP download procedure: boot a rescue or newly downloaded image, which starts with a default configuration).
For the X430 switch, Boot ROM versions prior to 1.0.1.5 do not have the config none option. Update to at least 1.0.1.5 to be able to clear the configuration through the boot ROM.

Before you start, check the boot ROM revision if the switch is reachable at all (or note it from inventory). Knowing whether config none exists on your platform tells you whether you are looking at a two-minute job or a TFTP rescue-image job.

Verifying the recovery

The recovery is complete when all of the following are true:

You are logged in as an account with administrative rights.
show configuration reflects an empty/default configuration, not the old one.
save has completed successfully, so the blank configuration is what will be loaded at next boot.
You have set a new admin password and confirmed it works.

Then, and only then, move on to restoring the previous configuration from a backup — if you have one. Loading a configuration file you did not author is worth reviewing first, since that is the file that carried the password you just spent a maintenance window clearing.

Troubleshooting

Nothing on the console: wrong baud rate, wrong cable, or flow control enabled. Verify 9600-8-N-1 before assuming the switch is dead.
Spacebar does not enter the boot ROM: timing is tight; start pressing as soon as power is applied and hold it through the initial POST messages.
config none is not a valid command: your boot ROM is a version that dropped it (2.0.2.1) or predates it (X430 before 1.0.1.5). Use the rescue-image route or update the boot ROM.
The banner still shows after the reset: expected in some builds — the banner lives in a part of memory read before EXOS is fully loaded. Log in with the defaults anyway.
Logging in works, but the old config comes back after the next reboot: you skipped the save step. The in-memory default configuration was never written over the stored one.
Default login rejected: confirm you actually booted the default configuration option (X870 GRUB) or that config none was accepted without error.

FAQ

Can I recover the password without a console connection? No. There is no mechanical or network process to clear the configuration on ExtremeXOS; console access is mandatory.

Will this erase my VLANs and routing configuration? Yes. The procedure works by discarding the saved configuration, so every local setting goes. Restore from a backup if one exists.

Does the reset change the booted EXOS image? No. You are clearing the configuration, not reflashing the software. On the X870 GRUB menu you choose which image to boot, but the images themselves are untouched.

Why did ExtremeXOS remove config none in 2.0.2.1? Because an unauthenticated console command that wipes device configuration is itself an attack path. It was reinstated in 2.0.2.3, which tells you the practical cost of the "fix" outweighed the risk.

Does clearing the configuration affect the other switches in a stack? The master's configuration is what the stack runs, so yes — the stack comes up defaulted. Members keep their own stored configuration files, so verify each one as it joins and clear any node that re-adopts stale settings.

How do I avoid this next time? Keep an off-device backup of the configuration, use named accounts with documented credential storage, and keep boot ROM versions consistent across the estate so you know in advance which recovery path each switch supports.