VMware ESXi and vSphere Cluster Management
Cisco Device Boot Sequence: POST, Bootstrap, IOS, and Configuration Loading
Learn how a Cisco device starts: POST, bootstrap execution, IOS image selection, RAM loading, startup-config loading, ROMMON, and verification commands.
What the Cisco Boot Sequence Does
The Cisco boot sequence is the ordered process a router or switch follows after it is powered on or reloaded. It prepares the hardware, loads Cisco IOS, and applies the saved device configuration.
Cisco IOS is the Cisco Internetwork Operating System that provides the device's operating environment. An IOS image is the software file that contains Cisco IOS.
The boot sequence is different from normal IOS operation. During boot, the device performs diagnostics and locates software and configuration files. After startup finishes, IOS operates normally and processes commands, forwards traffic, and provides management functions.
Boot Sequence Order
- POST: The device performs a power-on self-test of essential hardware.
- Bootstrap execution: Startup code runs and initializes enough of the system to locate an IOS image.
- IOS image selection: The bootstrap program determines which IOS image to use, usually from flash memory and boot settings.
- IOS loading: The selected image is copied or decompressed into RAM, where it runs.
- Startup configuration loading: IOS searches for startup-config, usually in NVRAM, and loads it into RAM as running-config.
Each stage depends on the successful completion of the earlier stages or on the availability of an appropriate fallback. For example, IOS cannot load normally if the device cannot find a usable image, and startup-config cannot be applied until IOS is running.
Cisco IOS Boot Sequence Stages
| Stage | Primary action | Memory or storage involved | Outcome |
|---|---|---|---|
| POST | Tests and identifies essential hardware. | Hardware and startup diagnostic code | Hardware is accepted for startup, or boot may stop because of a fault. |
| Bootstrap initialization | Runs low-level startup code and initializes the system enough to find IOS. | ROM and RAM | The device can search for an IOS image. |
| IOS image selection | Evaluates boot settings and available image files. | Flash, boot system statements, and configuration register | A preferred or fallback IOS image is selected. |
| IOS loading into RAM | Copies or decompresses the selected IOS image into RAM. | Flash and RAM | IOS starts and takes control of the device. |
| Startup configuration loading | Reads the saved configuration and applies it. | NVRAM and RAM | startup-config becomes running-config. |
Stage 1: Power-On Self-Test
POST means power-on self-test. It is the initial hardware diagnostic performed when a Cisco device starts or reloads.
POST discovers and verifies essential components such as the processor, memory, and other platform-dependent hardware. The exact tests and messages vary by device model and software family.
If POST fails, the device may display diagnostic messages, stop before normal IOS operation, or indicate a hardware problem. A failed POST is therefore different from a missing IOS image: the problem occurs before normal software loading can proceed.
Stage 2: ROM and the Bootstrap Program
ROM is persistent memory that contains low-level startup and recovery code. It retains its contents when power is removed. The code stored there is available before the main IOS image has been loaded.
After POST succeeds, the device makes the bootstrap program available in RAM for execution. The bootstrap program is startup code that initializes enough of the system to locate and start an IOS image.
Bootstrap code is not the same as the full IOS operating system. It provides the early control needed to inspect boot settings, access storage, select an image, and transfer IOS into RAM.
Stage 3: Finding and Selecting the IOS Image
The bootstrap program determines which IOS image should be loaded. On traditional Cisco IOS platforms, the usual location is flash memory. Flash is nonvolatile storage that commonly holds IOS image files and other device files.
Image selection can be influenced by:
- boot system statements: Configuration directives that specify an IOS image or boot path.
- Configuration register: A boot-control value that influences startup behavior, including how IOS and configuration files are located.
- Available files: The IOS images actually present and usable in flash or another supported storage location.
- Platform rules: Device-specific software and storage behavior.
When multiple IOS images are present, a boot system setting can identify the preferred image. The bootstrap program attempts that image first. If the preferred image is missing or invalid, the device may try another configured or discoverable image, depending on the platform and boot settings. If no usable image can be loaded, the device may enter ROMMON.
Configuring a Preferred Image
On platforms that support this syntax, the following command specifies an IOS image in flash:
Router(config)# boot system flash:cisco-ios-image.binThe exact syntax and image naming rules vary by platform. After configuring a boot system statement, verify it with show boot and confirm that the named file exists in flash.
Stage 4: Loading IOS into RAM
After selecting a usable image, the device copies or decompresses the IOS image from flash into RAM. RAM is volatile working memory: its contents are lost when the device powers off.
IOS runs from RAM because RAM provides the working space needed for operating-system code and active processes. The image file remains stored in nonvolatile flash so it can be loaded again during a later boot.
When IOS starts successfully, the device reaches normal IOS operation. At this point, the command-line interface and platform services become available, although the device may not yet have its saved network configuration applied.
Stage 5: Loading the Startup Configuration
After IOS starts, it searches for the startup-config. On traditional Cisco IOS devices, startup-config is usually stored in NVRAM.
Startup-config is the saved configuration intended for use during boot. IOS reads it from NVRAM and loads it into RAM. The loaded configuration becomes the running-config, which is the active configuration currently held in RAM.
The distinction is important:
- startup-config: Saved, nonvolatile configuration used at the next startup.
- running-config: Active configuration in RAM that controls the device now.
Changes made to running-config take effect immediately but do not automatically survive a reload. To preserve them, save the active configuration:
Router# copy running-config startup-configIf IOS cannot find a startup configuration, it still may start normally. The device uses default settings and may display an initial configuration dialog. An administrator can configure the device manually and save the intended running configuration for future boots.
Memory Roles During Boot
| Memory type | Volatile or nonvolatile | Typical boot-related contents | Role in startup |
|---|---|---|---|
| ROM | Nonvolatile | POST-related and low-level startup or recovery code | Provides code needed before the main IOS image runs. |
| Flash | Nonvolatile | IOS image files and other device files | Provides the usual source for the IOS image. |
| RAM | Volatile | Running IOS, running-config, and active processes | Holds the operating system and active configuration while the device runs. |
| NVRAM | Nonvolatile | startup-config on traditional Cisco IOS devices | Preserves the saved configuration across reloads and power loss. |
Normal Startup Example
- A router is powered on and completes POST.
- Bootstrap code runs from the device's low-level startup storage.
- Bootstrap finds the configured IOS image in flash.
- The image is loaded into RAM and IOS starts.
- IOS reads startup-config from NVRAM.
- The saved configuration is applied as running-config, and the router enters normal operation.
No Saved Configuration
In this scenario, IOS loads successfully, but the device cannot find a startup-config. The device uses default settings and may offer an initial configuration dialog.
The administrator can answer the dialog or exit it and configure the device manually. The resulting active configuration should be saved if it is intended to be used after the next reload:
Router# copy running-config startup-configROMMON and Other Boot Failure Modes
ROMMON, or ROM monitor mode, is a low-level recovery environment used when normal IOS boot cannot proceed. It provides limited commands for examining storage, changing boot behavior, and performing platform-specific recovery actions.
A device may enter ROMMON because of:
- A missing IOS image.
- A corrupted or otherwise invalid IOS image.
- An incorrect boot variable or boot system filename.
- A configuration-register setting that prevents normal image or configuration loading.
- A platform-specific storage or hardware problem.
Recovery procedures vary by platform and software family. An administrator should first identify the device model, inspect available storage when possible, verify boot settings, and follow the supported recovery method for that platform. Avoid assuming that a recovery command or image format for one Cisco family applies to another.
Common Boot Outcomes
| Condition | Likely result | Where the device stops or continues | Administrative next step |
|---|---|---|---|
| Successful normal boot | IOS and the saved configuration load. | Continues into normal IOS operation. | Verify the IOS image, boot settings, and configuration. |
| Startup-config absent | IOS starts with default settings and may show the initial configuration dialog. | IOS continues, but no saved configuration is applied. | Configure the device and save the intended running-config. |
| IOS image absent or corrupt | Bootstrap cannot start a usable IOS image. | May enter ROMMON. | Inspect storage and use a supported image-recovery procedure. |
| Incorrect boot variable or configuration register | The preferred image or saved configuration may be ignored. | May boot an unexpected image, start without startup-config, or enter ROMMON. | Verify boot settings and register behavior before changing them. |
Verifying Boot Information During Normal Operation
Use verification commands from privileged EXEC mode. Command output differs between platforms, so interpret the results together rather than relying on one line.
Check IOS Version, Image, and Configuration Register
Router# show versionshow version displays the running IOS version and commonly identifies the IOS image file, system uptime, platform details, memory information, and configuration-register value.
Check Boot Variables
Router# show bootshow boot displays boot variables and the configured boot path on supported Cisco IOS platforms. If the command is unavailable or its output differs, use the platform's supported equivalent.
Inspect Flash for IOS Images
Router# dir flash:dir flash: lists files in flash memory. Compare the filenames with the image named by the boot settings. A file being present does not by itself prove that the image is valid or compatible with the platform.
Compare Saved and Active Configurations
Router# show startup-config
Router# show running-configshow startup-config displays the saved configuration. show running-config displays the active configuration in RAM. Comparing them helps identify unsaved changes, a missing startup-config, or differences created after the device booted.
To save intended active changes:
Router# copy running-config startup-configTroubleshooting Boot Problems
The Device Starts in ROMMON Instead of IOS
Likely causes include no valid IOS image in flash, an incorrect configured image path, a corrupt image, or boot settings that prevent normal startup.
- Inspect flash contents when the recovery environment permits it.
- Check boot variables and the configuration-register information.
- Confirm that the image name and location match the configured boot path.
- Use platform documentation for the supported recovery procedure.
The Initial Configuration Dialog Appears After Every Reload
Possible causes include an unsaved configuration, unreadable startup-config storage, or a configuration-register setting that causes the saved configuration to be ignored.
- Compare
show running-configandshow startup-config. - Save the intended active configuration with
copy running-config startup-config. - Verify the configuration-register behavior with
show version.
The Device Boots an Unexpected IOS Release
This can happen when multiple images exist in flash, a boot system statement points to a different image, or the preferred image is unavailable and fallback selection occurs.
- Review
show boot. - List image files with
dir flash:. - Use
show versionto identify the image that actually loaded. - Confirm that the intended boot system configuration names the correct compatible image.
Exam-Relevant Summary
- POST comes first: It tests essential hardware before normal software loading.
- Bootstrap follows POST: It initializes enough of the device to locate IOS.
- Flash usually stores the IOS image: The image is loaded into RAM to run.
- NVRAM traditionally stores startup-config: IOS loads it into RAM as running-config.
- Running-config is active but volatile: Save it to startup-config if it must survive a reload.
- No startup-config does not necessarily mean IOS failed: IOS may start with defaults and show an initial setup dialog.
- ROMMON indicates a recovery condition: It commonly results from an unavailable image, invalid boot settings, or configuration-register behavior.
- Verify rather than assume: Use
show version,show boot,dir flash:,show startup-config, andshow running-config.
For a related overview, see Cisco device boot sequence fundamentals.