Upgrading IOS is a critical skill for any network engineer and appears on the CCNA 200-301 exam as a core operational task. A failed upgrade can brick a router or switch, causing network outages that cost thousands per minute. This chapter covers the complete step-by-step process, including file verification, boot variables, and backup strategies, so you can upgrade with confidence. The relevant exam objective is 'Configure and verify device management using backup and restore software and configuration files.'
Jump to a section
Think of upgrading IOS like upgrading the operating system on your smartphone. First, you check your current OS version (Settings > About Phone) and verify there's enough storage space for the new OS file. You download the new OS file from the manufacturer's website to your computer, then transfer it to your phone via USB. Before installing, you back up your photos, contacts, and apps—this is like backing up the startup configuration (running-config to startup-config). The phone then copies the new OS to a separate partition, verifies its digital signature, and sets the boot partition to the new OS. It reboots, loading the new system. If something goes wrong (boot loop), you can boot into recovery mode and restore the old OS from the backup. In Cisco terms: you copy the IOS image to flash, verify the MD5 hash, set the boot system command, save the config, and reload. The old IOS remains in flash as a fallback—like keeping your old phone OS file on the computer just in case.
What is an IOS Upgrade and Why?
An IOS upgrade replaces the network operating system on a Cisco router or switch with a newer version to gain features, fix bugs, or address security vulnerabilities. The IOS image is a file (e.g., c2960-lanbasek9-mz.150-2.SE11.bin) stored in flash memory. On the CCNA exam, you must know how to copy a new image to the device, verify its integrity, and configure the device to boot from it.
Step-by-Step Mechanism at the File Level
Prepare the Image: Download the correct IOS from Cisco.com (requires a service contract). Verify the file's MD5 checksum against Cisco's published value.
Copy to Flash: Use copy tftp flash or copy usbflash0: flash:. The file is transferred via TFTP (UDP port 69) or from a USB drive. TFTP has no reliability or security—use it only in a lab. For production, use SCP or FTP with authentication.
Verify the Image: Use verify /md5 flash:filename.bin to confirm the file isn't corrupted. The output shows the computed MD5 hash. Compare it to Cisco's published hash.
Backup Configuration: Save the running-config to startup-config with copy running-config startup-config. Also copy the current IOS to a backup location: copy flash: tftp:.
Set Boot Variable: Use boot system flash:filename.bin in global configuration mode. This tells the device which IOS to load on next reload. If multiple boot statements exist, the first one that points to a valid file is used.
Save and Reload: copy running-config startup-config then reload. The device reboots and loads the new IOS.
Post-Upgrade Verification: Use show version to confirm the new IOS version, and show flash to see the new and old images.
Key States, Timers, and Defaults
Boot Variable Default: If no boot system command is configured, the device boots from the first valid IOS image in flash (alphabetically or by file system order).
TFTP Timeout: Default 60 seconds per block retransmission. A large image (e.g., 100 MB) can take 10-15 minutes.
Flash Space: Minimum free flash space is often 10-20% of the image size for boot helper and crash info. The command show flash: shows available and used space.
Reload Grace Period: reload has a 60-second default grace period before the device actually reboots. Use reload in 5 to schedule a reload in 5 minutes.
IOS CLI Verification Commands
Check current IOS:
Router# show version
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.4(3)M2, RELEASE SOFTWARE (fc2)
...
System image file is "flash:c1900-universalk9-mz.SPA.154-3.M2.bin"Check flash contents:
Router# show flash:
-#- --length-- -----date/time------ path
1 1024 Mar 1 2020 00:00:00 +00:00 c1900-universalk9-mz.SPA.154-3.M2.bin
2 2048 Mar 1 2020 00:01:00 +00:00 c1900-universalk9-mz.SPA.151-4.M4.binVerify MD5:
Router# verify /md5 flash:c1900-universalk9-mz.SPA.154-3.M2.bin
MD5 of flash:c1900-universalk9-mz.SPA.154-3.M2.bin = 4e7e7e7e7e7e7e7e7e7e7e7e7e7e7e7eSet boot system:
Router(config)# boot system flash:c1900-universalk9-mz.SPA.154-3.M2.bin
Router(config)# exit
Router# copy running-config startup-configInteraction with Related Protocols
TFTP: Used for image transfer. It's a simple UDP-based protocol with no security. The device acts as a TFTP client; a TFTP server must be running on the network. Firewalls must allow UDP port 69.
SCP/FTP: More secure alternatives. SCP uses SSH (TCP 22) and requires AAA authentication.
ROMmon: If the image is corrupt or missing, the device boots into ROMmon (ROM monitor) mode. From there, you can use tftpdnld to load a new image via TFTP.
Boot Helper: A small IOS subset that runs from ROM to facilitate TFTP downloads when no valid IOS is in flash.
Common Pitfalls
Insufficient flash: Always check flash space before copying. The copy command will fail if not enough space. Delete old images with delete flash:old-image.bin.
Wrong image: Downloading the wrong platform image (e.g., a 2960 image for a 3750) causes boot failure. Verify the filename matches your device model.
Not saving config: If you forget copy running-config startup-config after setting boot system, the device reverts to default boot order on reload.
Interrupted TFTP: A network drop during TFTP transfer corrupts the image. Always verify the MD5 hash before reloading.
Backup Current Configuration and IOS
Before making any changes, back up the current running configuration to startup-config with `copy running-config startup-config`. Also copy the existing IOS image to a TFTP server as a fallback: `copy flash: tftp:`. This ensures you can restore the device to its previous state if the upgrade fails. On the exam, always assume you should back up first—even if not explicitly stated.
Check Flash Space and Current IOS
Use `show flash:` to display available and used flash memory. Compare the new image size against free space. If space is low, delete old images with `delete flash:unused-image.bin`. Also use `show version` to record the current IOS version and image filename. This step prevents the common 'insufficient space' error during the copy.
Copy New IOS to Flash
Copy the new IOS image from a TFTP server (or USB) to flash: `copy tftp: flash:`. You will be prompted for the TFTP server IP, source filename, and destination filename (usually the same). The transfer can take several minutes. For USB: `copy usbflash0: flash:`. Monitor the progress; if it fails, check TFTP server connectivity and flash space.
Verify Image Integrity with MD5
After the copy completes, verify the file's MD5 checksum: `verify /md5 flash:new-image.bin`. Compare the output hash to Cisco's published hash (found on the download page). If they don't match, delete the corrupted image and recopy. This step ensures the image is not corrupted—a corrupted image will cause a boot failure.
Configure Boot System Variable
Enter global configuration mode and set the boot variable: `boot system flash:new-image.bin`. This tells the device which image to load on next reload. You can configure multiple boot statements for fallback. Use `no boot system` to remove previous entries. Verify with `show boot` or `show running-config | include boot system`.
Save Configuration and Reload
Save the running configuration: `copy running-config startup-config`. Then reload the device: `reload`. You'll be prompted to confirm; the device will reboot after a 60-second grace period. During reload, the device loads the new IOS. If the image is valid, you'll see normal boot messages. If it fails, the device may enter ROMmon mode.
Verify Upgrade and Clean Up
After the device reloads, use `show version` to confirm the new IOS version and image filename. Also use `show flash` to verify the new image is present and old images remain (if you kept them). Optionally, delete the old IOS image to free space: `delete flash:old-image.bin`. Always keep at least one backup image in flash if space permits.
In a large enterprise, upgrading IOS is a planned maintenance event, often scheduled during change windows. For example, a network engineer at a university upgrades the core distribution switches to a new IOS version that fixes a critical OSPF bug. The engineer first tests the new image on a lab switch, then stages the image on a TFTP server in the network operations center (NOC). During the maintenance window, the engineer connects to each switch via SSH, backs up the config, copies the image, verifies the MD5, sets boot variables, and reloads one switch at a time to minimize impact. After each reload, they verify connectivity and OSPF neighbor states. If a switch fails to boot, they console into it, break into ROMmon, and use tftpdnld to load a backup image.
Another scenario: a service provider upgrades IOS on hundreds of remote routers. They use a centralized management tool like Cisco Prime Infrastructure to push images via FTP and schedule reloads during off-peak hours. They also configure boot fallback to the old image in case the new one fails. This requires careful planning of flash space—some routers have limited flash and need to delete old images before copying.
Common scale considerations: TFTP is slow and unreliable over WAN links; use FTP or SCP for remote sites. Always have a console server for out-of-band access in case SSH fails after reload. Misconfiguring the boot variable (e.g., pointing to a nonexistent file) causes the device to enter ROMmon, requiring physical access or a console server to recover. This is why you always verify the boot variable with show boot before reloading.
The CCNA 200-301 exam tests your ability to perform an IOS upgrade as part of device management. The specific objective is 'Configure and verify device management using backup and restore software and configuration files.' Expect scenario-based questions where you must choose the correct sequence of commands or identify errors in a given configuration.
Common Wrong Answers: 1. 'Copy running-config to startup-config before copying the image' – This is correct but candidates often think it's unnecessary. It is always necessary to save the config before reload. 2. 'Use `copy running-config tftp` to back up the IOS' – This backs up the config, not the IOS. The IOS is in flash, not in running-config. 3. 'Set boot system to the new image after reload' – You must set it before reload; otherwise, the device boots the old image. 4. 'Skip MD5 verification if the file copied successfully' – The exam expects you to verify integrity; a successful copy does not guarantee the file is uncorrupted.
Specific Values and Commands:
- Default boot order: first valid image in flash.
- verify /md5 command syntax.
- show version shows the current image filename.
- show flash shows file sizes and free space.
- The copy tftp flash command prompts for source IP, source filename, and destination filename.
Decision Rule: In a scenario question, always choose the option that includes backup, verification, and saving config before reload. If a question asks 'What should the engineer do before reloading?', the answer is 'Save the running configuration to startup-config' and 'Verify the new image with MD5'.
Always back up the current configuration and IOS before upgrading.
Use `copy tftp: flash:` to transfer the new IOS image to flash.
Verify the image integrity with `verify /md5 flash:filename.bin` before reloading.
Set the boot system with `boot system flash:filename.bin` in global configuration mode.
Save the configuration with `copy running-config startup-config` before issuing `reload`.
After reload, confirm the new IOS version with `show version`.
If the device fails to boot, it may enter ROMmon; use `tftpdnld` to recover.
These come up on the exam all the time. Here's how to tell them apart.
TFTP for IOS Transfer
Uses UDP port 69, no reliability or security
No authentication; anyone with network access can initiate transfer
Slower over high-latency links due to stop-and-wait
Simplest to set up (no encryption overhead)
Commonly used in lab and exam scenarios
SCP for IOS Transfer
Uses SSH (TCP 22), encrypted and reliable
Requires authentication (AAA or local username/password)
Faster over WAN due to TCP windowing
Requires SSH server configuration on the device (ip scp server enable)
Preferred in production for security
Mistake
You can upgrade IOS by simply overwriting the existing image file via TFTP.
Correct
You must copy the new image to flash as a separate file (or delete the old one first if space is tight). Overwriting an in-use image can cause boot failure. Always copy the new image, then set the boot variable to the new file.
Candidates think TFTP copy replaces the file atomically, but the device may be reading the old image during the copy.
Mistake
The `boot system` command is saved automatically when entered.
Correct
The `boot system` command is stored in the running configuration only. You must explicitly save it to startup-config with `copy running-config startup-config` for it to persist across reloads.
Many commands are auto-saved, but boot variables are not.
Mistake
After copying the new IOS, you can immediately reload without saving the running-config.
Correct
You should always save the running-config before reload to ensure any configuration changes (including boot system) are retained. If you reload without saving, the device boots with the startup-config, which may not include the new boot system command.
Candidates forget that reload uses startup-config, not running-config.
Mistake
MD5 verification is optional if the TFTP transfer completed without errors.
Correct
TFTP does not guarantee data integrity; a corrupted file can still have a successful transfer. Always use `verify /md5` to confirm the file matches Cisco's published checksum.
TFTP uses UDP and only verifies block checksums, not the entire file.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
`copy tftp flash` copies a file (like an IOS image) from a TFTP server to flash memory. `copy tftp running-config` copies a configuration file into the running configuration (merging with existing config). For IOS upgrades, always use `copy tftp flash` to place the image in flash, then set boot system.
Yes, you can use a USB flash drive: `copy usbflash0: flash:`. Alternatively, use FTP (`copy ftp: flash:`) or SCP (`copy scp: flash:`). The device must support the protocol. For CCNA, TFTP is the most commonly tested method.
The device will boot from the first valid IOS image in flash (alphabetically or by file system order). This might be the old image if it is still present. To ensure the new image is used, you must set `boot system flash:new-image.bin` and save the config.
At the ROMmon prompt (`rommon 1 >`), use the `tftpdnld` command to download a valid IOS image via TFTP. You need to set environment variables like IP address, TFTP server, and filename. Alternatively, use XMODEM via console (very slow). Always keep a backup image in flash to avoid this.
Only if flash does not have enough free space. Use `show flash:` to check. If space is insufficient, delete the old image with `delete flash:old-image.bin`. Otherwise, keep it as a fallback. The exam may test that you check flash space first.
It computes the MD5 hash of a file in flash and displays it. You compare this hash to the one published by Cisco on the download page. If they match, the file is intact. If not, the file is corrupted and must be recopied. This prevents boot failures due to corrupt images.
Yes, you can perform all steps via SSH: copy the image using SCP (which runs over SSH), configure boot system, and reload. However, if the reload fails and the device enters ROMmon, you lose SSH access. Always have console access available as a backup.
You've just covered IOS Upgrade Step-by-Step Process — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?