ExtremeXOS交换机密码恢复

2025年4月3日 LOG admin

This is the operational runbook for recovering an ExtremeXOS switch whose admin password is unknown. Where the reference article explains how the boot ROM recovery works, this one is written as a checklist you can follow in a maintenance window: what to gather first, how to pick the right recovery path for the platform in front of you, what to do when config none is missing, how to tell that the reset really took effect, and how to bring the switch back into service without repeating the incident.

Objective

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

Environment

Platform: Summit.
Software: EXOS All.
Boot ROM: all boot ROM versions except 2.0.2.1.

Note the phrase "except 2.0.2.1" — that single excluded revision is the reason this runbook has a fallback branch at all. Read the boot ROM caveats section before you begin.

Before you touch the console

Ten minutes of preparation saves an hour of recovery. Work through this list first.

Is the password genuinely lost? Check for stored credentials, a password manager, a previous engineer's notes, or a documentation wiki entry. Also check whether any named account still works — recovery wipes everything, so any surviving account is a cheaper exit.
Is there a configuration backup? A saved script, a TFTP copy, or an exported text configuration turns a rebuild into a restore. Locate it now, not after the reset.
Do you know what the switch was doing? Port assignments, VLANs, uplinks, routing, stacking roles, and any SNMP or AAA configuration. If nobody knows, plan to reverse-engineer it from the neighbours — LLDP from the upstream switch is a good start.
Do you have a maintenance window and the authority to use it? The switch goes down, and comes back unconfigured. That is a service outage, not a maintenance blip.
Can the console port be reached physically? Confirm cabling and terminal settings before the window, so you are not troubleshooting your adapter at 2 a.m.

Console connection checklist

Console cable appropriate to the platform (RJ-45 rollover to a DB-9 or USB-serial adapter, or USB-C on newer hardware).
Terminal emulator set to 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control — the usual ExtremeXOS default. Some platforms differ; the hardware manual is authoritative.
Logging enabled in the terminal application so you capture the entire boot sequence. When something goes wrong, that capture is the evidence.
Power control confirmed — a PDU outlet you can cycle, or physical access to the switch's power feed.

If you see nothing at all on the console, do not assume the switch is broken. A baud-rate mismatch produces exactly the same blank screen as a dead device.

Step 1: Identify the platform and pick the path

There are two recovery routes and the choice depends on the hardware:

Summit X870 family — boots through a GNU GRUB menu. There is no need to reach a classic boot ROM prompt; you select an image entry that boots with the default configuration.
All other EXOS switches — press and hold the spacebar during boot to enter the boot ROM, then use config none.

If you are not sure which family you have, watch the first seconds of the boot messages. A GRUB menu is unmistakable — it presents a numbered list of images with kernel and default-configuration entries. The classic path instead shows low-level POST output followed by a boot ROM prompt.

Step 2A: Summit X870 procedure

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 entries boot the corresponding image with a default configuration. Choose Primary unless you have a reason to prefer the secondary image — for example if the primary image is known to be corrupt or if the two images are at different software versions. GRUB runs before EXOS, so no credentials are needed at this screen.

Step 2B: All other EXOS switches

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 to continue the boot process.
5. Once the switch boots up to EXOS, save the config with the command:  save
   to overwrite the old config with the new, blank config.

Step 5 is not optional. config none changes the running behaviour for this boot; save is what overwrites the stored configuration. Skip it and the password you just cleared returns at the next reload.

Step 3: When `config none` is not available

Two situations drop you into this branch:

Boot ROM 2.0.2.1 — the config none command was removed for security reasons. It was added back into boot ROM 2.0.2.3.
X430 with boot ROM older than 1.0.1.5 — the option does not exist yet. Update to at least 1.0.1.5 to be able to clear the configuration through the boot ROM.

If config none is not present, the only way to default the switch from the boot ROM is by loading a rescue image — use the boot ROM menu's TFTP download facility to pull a new image to the switch and boot it. A freshly loaded image starts with a default configuration, which gives you the same net result: a switch you can log into with default credentials.

Practical points for the rescue-image route:

Have an EXOS image file and a reachable TFTP server ready, and know the switch's management or boot-time IP situation. This is the one recovery path that may need network configuration before the switch is configured — so test the TFTP server from the management segment in advance.
Once the rescue image boots, save immediately, before doing anything else.
Then decide whether to bless the rescue image as the production image or reinstall the intended release. Do not leave a switch running an image nobody chose.

Step 4: Log in and confirm the reset

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 — it is not a reliable indicator that the configuration survived.

Confirm you are on a default configuration before celebrating:

save
show version
show switch
show configuration
show accounts

A default configuration shows no VLANs beyond the default, no user-defined accounts, no uplink configuration. If show configuration is full of your old VLANs, the reset did not take — return to the boot ROM and check that config none was accepted without error.

Step 5: Set credentials and bring the switch back

configure account admin
create account netadmin
configure snmp add community readonly public

Set the admin password, then work through the rebuild in a deliberate order so you can verify each layer before adding the next: hostname and management IP, VLANs, uplinks with correct tagging, routing, then monitoring (SNMP, syslog, NTP). Save at each meaningful milestone — save is cheap, and a saved intermediate configuration is far easier to reason about than a single uncommitted pile of changes.

Finally, export the configuration off the device. That single habit is what turns the next password incident from an outage into a non-event.

Verification checklist

Login works with the credentials you just set, and with a named account, not just admin.
show configuration reflects what you intend to persist, and save has run after the last change.
Uplinks are up, LLDP neighbours match your documentation, and the intended VLANs carry traffic.
NTP is synchronised and logs are reaching the syslog server.
The switch has survived one deliberate test reload with the configuration intact.

Pitfalls seen in the field

Forgetting save. The single most common cause of "the password came back".
Trusting the banner. A leftover login banner does not mean the reset failed.
Assuming every EXOS switch has config none. Boot ROM 2.0.2.1 dropped it; the X430 gained it only at 1.0.1.5.
Spacebar timing. Press it as soon as power is applied and hold it — the window is short.
Replacing hardware when the configuration is the problem. An unknown password is a configuration issue. Do not RMA a switch because of it.
No network path for the rescue image. If you need the TFTP branch, arrange server reachability before the window, because the switch is not configured to help you.
No backup afterwards. Rebuilding from scratch and then not exporting the result guarantees a repeat performance.

FAQ

Is there a button or jumper to clear the config? No. There is no mechanical process such as a switch to clear the config, which means console access is mandatory.

Can I do this over SSH? No. Every path requires the boot ROM or GRUB, which are only reachable on the console.

Will I lose the running software image? No. You are clearing configuration, not flashing software, unless you take the rescue-image branch — and even then the image you load is a deliberate choice.

Which credentials work after the reset? The platform's default account, normally admin with an empty password (just press Enter). Some releases document admin / admin; try both.

How long does it take? The reset itself is minutes. Rebuilding a production configuration is the real work — budget hours, not minutes, and have the old configuration's intent documented before you start.

Do I need to worry about the licence after a reset? No. Licences are stored separately from the configuration; the recovery discards settings, not entitlements.

What if nobody knows how the switch was configured? Rebuild it from the neighbours and your documentation: LLDP on the upstream device reveals the uplink ports, and port descriptions on peer switches usually recover the intent. Go layer by layer and verify before adding the next one.