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 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه