Image of Jeremy L. Gaddis, CCNA, CCNP (and Cortney, in case you were wondering)

Restore IOS Configuration from a TFTP Server

by Jeremy L. Gaddis on September 19, 2011 · 0 comments

Post image for Restore IOS Configuration from a TFTP Server

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!

TFTP Topology

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

Previous post:

Next post: