In previous articles, you learned how to install a TFTP server and how to back up IOS configuration files. Now, let’s assume that disaster has struck. The “disaster” could take several forms: an engineer fat fingered a command and screwed up the configuration, a hardware failure occurred, or perhaps a natural disaster took out our datacenter. Whatever the reason, we need to restore that configuration — and fast!

We’re using the same basic topology (shown above) as we did when we backed up the configuration. We’ll “simulate” a disaster by wiping out the startup-configuration on the PHOENIX router.
copy tftp startup
In the previous article, you learned that we use the copy startup tftp command to copy the startup-configuration to the TFTP server. We’ll use a variation of the copy command to restore (the syntax is always “copy <source> <destination>”) as well.
I’ve left my configurations in place from the previous article and, if you’re following along, you should too. We want the serial connection between PHOENIX and DALLAS to be up and active, so make sure that you can ping between the two devices:
PHOENIX# ping 192.168.12.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/9 ms PHOENIX#
For reference, let’s take a look at the output of show ip interface brief and show interfaces description on the PHOENIX router:
PHOENIX# show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 192.0.2.236 YES manual up up Ethernet0/1 unassigned YES NVRAM administratively down down Ethernet0/2 unassigned YES NVRAM administratively down down Ethernet0/3 unassigned YES NVRAM administratively down down Serial1/0 unassigned YES NVRAM administratively down down Serial1/1 192.168.12.1 YES manual up up Serial1/2 unassigned YES NVRAM administratively down down Serial1/3 unassigned YES NVRAM administratively down down PHOENIX# show interfaces description Interface Status Protocol Description Et0/0 up up CONNECTION TO PHYSICAL ETHERNET NETWORK Et0/1 admin down down Et0/2 admin down down Et0/3 admin down down Se1/0 admin down down Se1/1 up up CONNECTION TO DALLAS SERIAL 1/1 Se1/2 admin down down Se1/3 admin down down
If you’re following along, your output should look similar.
Poof!
To simulate our disaster, go ahead and erase the startup configuration on the PHOENIX router and instruct it to reload.
While it’s reloading, if you glance at the console of the DALLAS router, you should see that the serial connection between the two routers has dropped:
*Sep 19 15:25:29.767: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/1, changed state to down
Due to our “disaster”, the DALLAS router is now disconnected from the rest of the network.
After the router has finished reloading, you should immediately notice that it has a blank configuration:
--- System Configuration Dialog --- Would you like to enter the initial configuration dialog? [yes/no]: no
In addition, you’ll notice that the prompt has reverted to the default:
Router>
Let’s compare the output of show ip interface brief and show interfaces description to what it was previously:
Router> enable Router# show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 unassigned YES NVRAM administratively down down Ethernet0/1 unassigned YES NVRAM administratively down down Ethernet0/2 unassigned YES NVRAM administratively down down Ethernet0/3 unassigned YES NVRAM administratively down down Serial1/0 unassigned YES NVRAM administratively down down Serial1/1 unassigned YES NVRAM administratively down down Serial1/2 unassigned YES NVRAM administratively down down Serial1/3 unassigned YES NVRAM administratively down down Router# show interfaces description Interface Status Protocol Description Et0/0 admin down down Et0/1 admin down down Et0/2 admin down down Et0/3 admin down down Se1/0 admin down down Se1/1 admin down down Se1/2 admin down down Se1/3 admin down down Router#
Yep, our configuration is gone and the network is down! Let’s restore the configuration file from the TFTP server and get the network up and running again.
First, we’ll need to manually configure an IP address on the Ethernet 0/0 interface that is used to connect to the TFTP server (using DHCP would also be a suitable option, assuming DHCP is available on your network):
Router# conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)# interface ethernet 0/0 Router(config-if)# ip address 192.0.2.236 255.255.255.0 Router(config-if)# no shutdown Router(config-if)#
You will (hopefully) see log entries showing that the Ethernet connection has come up.
*Sep 19 15:39:27.308: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up *Sep 19 15:39:28.312: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
Let’s use ping to verify that we can actually communicate with the TFTP server:
Router(config-if)# end Router# ping 192.0.2.235 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.0.2.235, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/18/69 ms Router#
It looks like everything is working. We’re going to take the configuration file that we previously backed up to the TFTP server and copy it to our running-configuration:
Router# copy tftp running-config Address or name of remote host []? 192.0.2.235 Source filename []? phoenix.cfg Destination filename [running-config]? Accessing tftp://192.0.2.235/phoenix.cfg... Loading phoenix.cfg from 192.0.2.235 (via Ethernet0/0): ! [OK - 1409 bytes] 1409 bytes copied in 9.126 secs (154 bytes/sec) PHOENIX# *Sep 19 15:44:56.709: %SYS-5-CONFIG_I: Configured from tftp://192.0.2.235/phoenix.cfg by console PHOENIX#
The configuration file was successfully copied and the changes applied to our running-configuration, as evidenced by the prompt:
PHOENIX#
It looks like we’re back in business. There’s an old saying, “Trust but verify”, so double check the configuration, make sure your connections are up, that you have connectivity between networks, etc. before declaring that the “disaster” has been resolved.
Summary
While the process of backing up and restoring IOS configuration files via TFTP is quite simple, you’ll want to make sure you have it mastered before taking the CCNA test. Other popular uses of TFTP include backing up Cisco IOS software and upgrading Cisco IOS, which we’ll look at in the next two articles.
Image Source
Related posts:




