Configuration Management & Recovery¶

Where a Cisco switch actually stores its configuration and IOS image, how it boots, and how to back up, restore, wipe, or recover one — the operational side of switch management that sits underneath the CLI reference.

All commands on this page are typed at the privileged EXEC prompt (Switch#) unless a block shows otherwise — enable first if you're at Switch>.

File Locations¶

A switch has three distinct storage areas, and mixing them up is the source of most "I saved it but it didn't stick" confusion:

Location	Contents	Persists on reboot?
RAM	`running-config` — the active configuration currently in effect	No — wiped on reload
NVRAM	`startup-config` — the configuration loaded at boot	Yes
Flash	The IOS image itself, plus (on some platforms) `vlan.dat` — the VLAN database	Yes

VLAN database caveat: on many Catalyst switches, VLAN definitions (vlan 10, name Office, etc.) are stored separately in vlan.dat on flash, not inside startup-config. This means erase startup-config alone does not remove your VLANs — see Erasing / Factory Reset below.

Boot Process¶

POST (Power-On Self-Test) — hardware check
Bootstrap — loaded from ROM, locates and loads the IOS image from flash
IOS loads — decompresses and starts running from flash into RAM
Startup-config loads — NVRAM's startup-config is copied into RAM, becoming the initial running-config
If no startup-config is found (blank NVRAM), the switch drops into setup mode (interactive initial-configuration dialog) or a basic unconfigured prompt

! Confirm IOS version, uptime, and config register value
show version
! List files in flash (IOS image, vlan.dat, etc.)
show flash:

Skipping startup-config: Catalyst 9000 vs the config register¶

On classic IOS, whether the switch loads startup-config at boot is governed by the config register — bit 0x40 set (e.g. 0x2142, 0x142) means "ignore NVRAM". On Catalyst 9000 / IOS-XE the register is decorative. The real control is a ROMMON variable:

show romvar | include IGNORE
SWITCH_IGNORE_STARTUP_CFG=1

With that set to 1, the switch boots with an empty running-config every time — hostname back to Switch, no SVIs, and every port back to VLAN 1 access. On a switch carrying trunks, that silently drops all tagged traffic.

config-register 0x102 is accepted in config mode and show version reports it:

Configuration register is 0x142 (will be 0x102 at next reload)

That line is not evidence of anything — it reads identically before and after an NVRAM erase, before and after a reload, and before and after the variable is actually cleared. Reloading on the strength of it produces a switch that comes up unconfigured.

Clear it properly, in config mode:

configure terminal
no system ignore startupconfig switch all
end
show romvar | include IGNORE      ! must read SWITCH_IGNORE_STARTUP_CFG=0
write memory

show version will still print the 0x142 line afterwards. Ignore it; the romvar is authoritative.

A secondhand switch often arrives with this set, because it is how the seller got past an unknown enable password. Check show romvar on any Catalyst 9000 before putting it into service — the switch works perfectly until the first power cut, then comes back bare.

Recovering a switch that booted bare¶

If startup-config is still intact (show startup-config returns it), no reboot is needed:

copy startup-config running-config

The config is restored live and interfaces come back as they were. Do not run write memory first — with a blank running-config that overwrites the only surviving copy of the configuration. Restore, verify, then save.

A config restored this way reports YES TFTP rather than YES manual in show ip interface brief. Cosmetic — it records how the config was loaded, and clears at the next clean boot.

Saving Configuration¶

Changes made in configuration mode go straight to running-config (RAM) and are lost on reload unless saved to NVRAM:

copy running-config startup-config

Shorthand (equivalent, older/common usage):

write memory
wr

Loading / Restoring Configuration¶

Reload from NVRAM¶

reload

Discards running-config and reboots, reloading startup-config from NVRAM. Always prompts to save unsaved changes first — don't reflexively answer "yes" if the running config has changes you didn't intend to keep.

Merge Startup-Config Back Into Running-Config¶

copy startup-config running-config

Caution: this merges NVRAM's saved config into the current running config rather than replacing it — leftover running-config lines not present in startup-config are not removed. If you need a clean known-good state, reload (which fully replaces running-config) is safer than this merge.

Backup and Restore via TFTP¶

Push a copy of the config to a TFTP server for safekeeping, or pull one down to restore:

! Backup running-config to a TFTP server
copy running-config tftp://10.0.99.5/sw01-running.cfg

! Restore a saved config from TFTP into running-config (merges, same caveat as above)
copy tftp://10.0.99.5/sw01-running.cfg running-config

! Restore directly into startup-config (takes effect on next reload)
copy tftp://10.0.99.5/sw01-startup.cfg startup-config

This is the practical way to keep off-switch backups — pair it with the logging server setup so both config and log history live somewhere other than the switch itself.

Exporting & Building Configs Offline¶

Other Export Methods¶

TFTP is the standard, but not the only option:

! Terminal capture — no server needed, good for a quick one-off
! Disable pagination so output isn't cut off
terminal length 0
! Copy the output from your terminal into a text file
show running-config

! SCP — needs working SSH plus AAA: aaa new-model, aaa authentication login default local,
! aaa authorization exec default local, and a privilege-15 user. Without AAA authorization,
! 'ip scp server enable' is accepted but every copy attempt fails.
conf t
 ip scp server enable
end
! Then pull the file from an SCP client on your workstation, e.g.:
!   scp admin@10.0.99.10:running-config ./sw01-running.cfg

! USB — on switches with a USB flash port
copy running-config usbflash0:sw01-running.cfg

Writing a Config From Scratch¶

A Cisco config file is just plain text IOS commands — nothing stops you writing one in a text editor instead of typing it live on a device. This is how templated/"golden config" deployments work: write one reference config, swap the hostname/IP/VLANs per site, and push it out.

To load a hand-written file onto a switch:

! Preferred: push via TFTP into startup-config, then reload — fully replaces the config
copy tftp://10.0.99.5/new-switch.cfg startup-config
reload

! Alternative: paste directly into configuration mode
conf t
! ...paste the file contents here...
end
copy running-config startup-config

Caution: pasting directly into conf t merges into the current running-config the same way copy startup-config running-config does — it does not clear out anything already there, and there's no error-checking as it streams in, so a typo partway through can leave the device in a half-applied state. The TFTP → startup-config → reload path is safer for a clean, fully-replaced config.

Gotchas When Writing Configs by Hand¶

Order matters for dependencies — vlan 10 must exist before any switchport access vlan 10 references it; an SVI can be created before ip routing is enabled, but won't actually route until it is. The Step-by-Step Switch Configuration walkthrough is ordered for exactly this reason.
Indentation is cosmetic — IOS tracks context (which interface/router/line block you're "inside") by the sequence of commands, not by leading whitespace. The indented look in this wiki's examples is a readability convention, not a syntax requirement.
Test before production — validate a hand-written config against a lab device, GNS3, or Packet Tracer before pushing it to a live switch, especially if it wasn't derived from a working device's actual show running-config output.

Erasing / Factory Reset¶

To fully return a switch to factory defaults (no VLANs, no hostname, no passwords):

! Wipes NVRAM config
erase startup-config
! Wipes the separately-stored VLAN database (confirm the flash: prompt)
delete vlan.dat
! Reboots into an unconfigured state
reload

erase nvram: is functionally equivalent to erase startup-config on most platforms.

Caution: this is destructive and immediate on reload — confirm you have a TFTP backup or genuinely intend a factory reset before running this on a live switch. Forgetting delete vlan.dat is the most common reason a "factory reset" switch still shows old VLANs after erase + reload.

Password Recovery¶

If the enable/console password is lost, recovery requires physical console access and interrupting the normal boot sequence — this cannot be done remotely.

Connect via console, unplug the switch's power, then press and hold the Mode button while reconnecting power. Keep holding while the System LED flashes green; release after it turns briefly amber and then solid green. The switch stops at the boot loader switch: prompt (you'll see "The system has been interrupted prior to initializing the flash file system"). If you instead see "The password-recovery mechanism has been triggered, but is currently disabled", recovery is only possible by wiping the config entirely.
Initialize the flash file system and hide the config so boot skips it:
```
flash_init
rename flash:config.text flash:config.text.old
boot
```
Answer no to the initial setup dialog, then type enable — you're in privileged EXEC with no password.

Restore the real config (passwords included):

rename flash:config.text.old flash:config.text
copy flash:config.text system:running-config

Set new passwords and save:

configure terminal
enable secret <new-password>
! Reset line con 0 / line vty passwords here as needed
end
copy running-config startup-config

Catalyst fixed-configuration switches have no confreg/config-register step — that's the Cisco router recovery method. Physical access to the console port and power is a prerequisite for this whole procedure — it's also why console/AUX port physical security matters as much as network-side hardening (see the Security Hardening checklist).

IOS Image Management¶

Before upgrading, always confirm flash has enough free space for the new image alongside (or instead of) the old one:

! Check free space and existing image(s)
show flash:
! Copy new image to flash
copy tftp://10.0.99.5/ios-image.bin flash:
! Verify the copy against the MD5 hash published on Cisco's download
! page — never reload onto an unverified image (TFTP corruption in
! transit is a classic cause of a switch that never boots back up)
verify /md5 flash:ios-image.bin

Point the boot process at the new image explicitly (otherwise the switch may pick whichever image it finds first):

conf t
 boot system flash:ios-image.bin
end
copy running-config startup-config
! Confirm the BOOT path-list actually points at the new image
show boot
reload

Verify after reload:

! Confirm the running IOS version matches the intended image
show version