LogoفارسیFA

Hands-On Lab: Upgrading Cisco IOS Using TFTP

This hands-on lab copies a new IOS image to a router's flash memory from a TFTP server, verifies sufficient flash space before starting, and points the boot system variable at the new image to make it load on next reload.

IOS Upgrade via TFTPFlash Memory VerificationBoot System Command

~3 min read · Updated Sep 23, 2026

Lab Objective

Verify a router has sufficient flash space for a new IOS image, copy the image from a TFTP server into flash, configure the boot system variable to point at the new image, and verify the configuration without yet reloading the device.

Lab Purpose

Upgrading IOS is a routine but consequential maintenance task, and skipping the flash space verification step is a common cause of a failed upgrade partway through the copy process, potentially leaving a router with a corrupted or incomplete image file.

Lab Topology

R1 ---- Gi0/0: 192.168.75.1/24

TFTP server: 192.168.75.100/24
New IOS image on server: c2900-universalk9-mz.SPA.157-3.M.bin
                          (approximately 89 MB)

Task 1: Configure Basic Addressing

Configure R1's interface connecting to the TFTP server's segment.

Task 2: Verify Available Flash Space

Check flash memory to confirm sufficient space exists before attempting the copy.

Task 3: Copy the New IOS Image to Flash

Copy the image from the TFTP server into R1's flash memory.

Task 4: Verify the Image Copied Successfully

Confirm the new image file appears in flash with the correct file size.

Task 5: Configure the Boot System Variable

Point the boot system variable at the newly copied image so it loads on the next reload.

Task 6: Verify the Boot Configuration Without Reloading

Confirm the boot system statement is correctly saved, without yet reloading the router.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.75.1 255.255.255.0
R1(config-if)# no shutdown
R1(config-if)# end

R1# show flash

-524288000 bytes total (198254592 bytes free)
-- Roughly 189 MB free -- more than enough
-- for the ~89 MB image, but this check must
-- always be done first, since copying a large
-- image with insufficient space can leave
-- a corrupted partial file consuming space
-- without providing a usable image

R1# copy tftp: flash:

Address or name of remote host []? 192.168.75.100
Source filename []? c2900-universalk9-mz.SPA.157-3.M.bin
Destination filename [c2900-universalk9-mz.SPA.157-3.M.bin]?

Accessing tftp://192.168.75.100/c2900-universalk9-mz.SPA.157-3.M.bin...
Loading c2900-universalk9-mz.SPA.157-3.M.bin from 192.168.75.100
[OK - 93326848 bytes]

93326848 bytes copied in 214.628 secs

R1# show flash

    93326848  c2900-universalk9-mz.SPA.157-3.M.bin
-- File size matches exactly what the TFTP
-- transfer reported, confirming a complete,
-- uncorrupted copy

R1(config)# boot system flash:c2900-universalk9-mz.SPA.157-3.M.bin
R1(config)# end
R1# copy running-config startup-config

R1# show running-config | include boot system

boot system flash:c2900-universalk9-mz.SPA.157-3.M.bin
-- The boot variable is saved and will take
-- effect the next time the router reloads --
-- no reload has occurred yet in this lab,
-- deliberately, since reloading during a
-- maintenance window is typically scheduled
-- as a separate, deliberate step

Key Takeaway

Verifying free flash space with show flash before starting the copy is not optional — a router that runs out of space mid-transfer can be left with a partially written, unusable image file, and in the worst case this can happen to the currently running image itself if flash management is not handled carefully, potentially leaving the device unable to boot at all.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring UDLD

This hands-on lab configures UDLD in aggressive mode on a fiber link between two switches, simulating a unidirectional fiber failure and verifying UDLD detects the mismatch and shuts down the affected port before a Layer 2 loop can form.

Continue

Hands-On Lab: Configuring Loop Guard

This hands-on lab configures Loop Guard on a switch's non-designated ports to prevent a unidirectional link failure from causing a Layer 2 loop, simulating a one-way BPDU loss and verifying the affected port enters a loop-inconsistent blocking state rather than incorrectly transitioning to forwarding.

Continue

Hands-On Lab: Configuring BPDU Guard and BPDU Filter

This hands-on lab configures BPDU Guard globally for PortFast-enabled ports and demonstrates the distinct, riskier behavior of BPDU Filter, comparing how each responds when a switch is connected to an access port that should only ever see end-user devices.

Continue

Hands-On Lab: Configuring Root Guard

This hands-on lab configures Root Guard on switch ports facing access-layer switches to prevent an unauthorized or misconfigured switch from becoming the Spanning Tree root, verifying the port enters a root-inconsistent state when a superior BPDU is received.

Continue

Hands-On Lab: Comprehensive Troubleshooting Challenge

This hands-on lab presents a multi-layer connectivity failure across VLANs, trunking, routing, and NAT simultaneously, requiring systematic bottom-up troubleshooting to identify and correct three independent faults before full connectivity is restored.

Continue

Hands-On Lab: Configuring Enhanced Object Tracking with HSRP

This hands-on lab configures IP SLA-based object tracking on an HSRP-enabled router, automatically lowering its priority when its WAN uplink fails, forcing failover to the standby router without requiring a full interface shutdown.

Continue
Previous ArticleNext Article