Cisco IOS 15 - backups and restores of configuration and images

Note: Thanks to my friend, who goes by Arpanet on the forum, for pointing out these interesting features.

Logging Configuration Commands

There are many reasons why it is useful to have a detailed overview of all configuration changes on the switch. Whether for security reasons, collaboration between multiple admins, or for personal control. One of the newer features in IOS (so if you don't find it on the switch, you need to upgrade IOS, also a problem with C6500) is the archive command.

With the archive command, we can arrange for logging of every command that changes the configuration. It also records which user made the change. So it is useful when each admin has their own account (we can use authentication via RADIUS).

The records are stored in the switch's memory. The log is circular, so when it fills up, the oldest records are gradually deleted. We can also set the records to be sent to a syslog server.

SWITCH(config)#archive                          // switch to archive configuration mode
SWITCH(config-archive)#log config               // switch to logging configuration
SWITCH(config-archive-log-cfg)#logging enable   // enables logging
SWITCH(config-archive-log-cfg)#logging size 200 // number of records to keep 1 - 1000, default 100
SWITCH(config-archive-log-cfg)#hidekeys         // replaces passwords in the log with asterisks
SWITCH(config-archive-log-cfg)#notify syslog    // when this command is used, records will also be sent to syslog (we can specify whether the messages are in plain text or XML)

We can then view the logged commands. Either display all, or filter by user and session.

SWITCH#show archive log config all
idx   sess           user@line      Logged command
    1     1         bouska@vty5     |  logging enable
    2     1         bouska@vty5     |  logging size 500
    3     1         bouska@vty5     |  hidekeys

Note: To clear the log, we can disable and re-enable logging or set the maximum records to 1 and then back. Alternatively, simply use SWITCH#clear archive log config force.

Configuration Backup

Configuration archives offer a mechanism for storing, organizing, and managing Cisco IOS configuration file archives. They provide automation and the ability to rollback (configure replace) - revert to an older configuration.

To create configuration archives (configuration backups), we can use the archive function. Basically, this function works the same as using the copy command, e.g., copy running-config tftp:. But it provides mechanisms for automation.

We only need to specify the location (url) where we want to store the backups and the filename prefix. The specified prefix is then supplemented with a dash and the configuration number. When the specified number of configurations is filled, they are overwritten from the oldest (this works only on some storage).

SWITCH(config)#archive                                // switch to archive configuration mode
SWITCH(config-archive)#path t[1](ftp://10.0.0.10/switch01) // in the first step, we must set the path and file prefix
SWITCH(config-archive)#maximum 14                     // (optional) number of configurations to keep

We have now enabled configuration archives. We can trigger the creation of an archive manually or automate it in some way.

SWITCH#archive config          // performs manual configuration archiving (to the specified path)

Note: As the storage location (url), we can use a number of protocols (depending on the type of IOS), simple TFTP, secure SCP (secure copy), common FTP, or others. For FTP, we enter the path in the form 2. Or we can use the ip ftp username and ip ftp password commands, which define global data.

Displaying information about performed archives is done as follows.

SWITCH#show archive
The next archive file will be named t[3](https://bing.com/search?q=) Archive #  Name
   0
   1       t[3](https://bing.com/search?q=)   2       t[3](https://bing.com/search?q=)   3       t[4](ftp://10.0.0.10/switch01-3) <- Most Recent
   4

Note: In the filename prefix, we can use the parameters $h for hostname (switch name) and $t for time.

Automatic Backup

We can link the automation of archiving to saving the configuration (when the running configuration is overwritten, e.g., after the write command) or set regular backups at a time interval.

SWITCH(config-archive)#write-memory           // enables automatic archiving when saving to memory
SWITCH(config-archive)#time-period 1440       // specifies the time after which automatic archiving will be performed, in minutes

Note: If we change the name (path) where the configuration is stored, it will start saving from 1 again.

Rollback to Previous Configuration and Configuration Replacement

If we use the command copy startup-config running-config (generally any copying to the running configuration), the running configuration is not overwritten but a merge of configurations is performed (so no commands are removed). This is often not what we want if we are, for example, reverting to an older configuration after some problem. On the other hand, it is useful if we are only adding some part of the configuration (saved in a file) to the running one.

Therefore, we have the configure replace command, which overwrites the running configuration with a saved one (it must be a complete configuration). To minimize problems, the running configuration is compared with the file, and only changes are written (executed). Additionally, the entire application is performed in several cycles to properly handle command dependencies.

When we combine configuration archives with configuration replacement, we achieve something Cisco calls configuration rollback. The idea is that we have configurations saved in the archive at a certain state/point (checkpoint) and can revert to these states using configuration replacement.

Configuration Replacement

When using the command, we must specify the URL to the configuration file to be used. Here we enter the full name, not just the prefix as in archiving. We can, for example, display a list of archives and choose from them. The basic usage looks as follows.

SWITCH#configure replace tftp://10.0.0.10/SWITCH-1
This will apply all necessary additions and deletions
to replace the current running configuration with the
contents of the specified configuration file, which is
assumed to be a complete configuration, not a partial
configuration. Enter Y if you are sure you want to proceed. ? [no]: y
Loading SWITCH-1 from 10.0.0.10 (via Vlan10): !
[OK - 11484 bytes]
Total number of passes: 1
Rollback Done

We can use several keywords after the configure replace command, such as:

• force - does not ask for confirmation when writing the configuration
• list - lists the applied commands in individual passes
• time - waits for confirmation, otherwise reverts back

Using these keywords might look like this. I don't want to be delayed by confirmation and want to see the list of applied changes.

SWITCH#configure replace tftp://10.0.0.10/SWITCH-1 list force
Loading SWITCH-1 from 10.0.0.10 (via Vlan10): !
[OK - 11526 bytes]
!Pass 1
Total number of passes: 1
Rollback Done

The total number of passes indicates that some changes were applied (otherwise it would be 0) and that it was done in one pass. Under !Pass 1, there should be a list of commands, but it is missing here. This is probably a bug in my IOS version (I haven't addressed this issue).

A practical example might also be overwriting the running configuration with the startup configuration.

SWITCH#configure replace nvram:startup-config

Configuration Comparison

Comparing two configurations, just like when replacing a configuration, can be done manually. Here is an example of comparing a saved configuration on TFTP with the running configuration.

SWITCH#show archive config differences tftp://10.0.0.10/SWITCH-2 system:running-config
Loading SWITCH-2 from 10.0.0.10 (via Vlan10): !                 
[OK - 11484 bytes]
!
!Contextual Config Diffs:
interface GigabitEthernet1/0/1
 +switchport access vlan 100
 +switchport mode access
+ntp clock-period 36028833
interface GigabitEthernet1/0/1
 -shutdown
-ntp clock-period 36028834

Timed Rollback

Another option is to use timed rollback with the time keyword. It works by first creating a current backup (archives must be configured), then loading the specified configuration. If the confirmation command is not entered within the specified time interval (10 to 120s), the configuration automatically reverts to the saved state. This can be useful when we are connected remotely and want to try a configuration that might disrupt our connection.

SWITCH#configure replace tftp://10.0.0.10/SWITCH-1 time 120 // timed rollback with 120s
SWITCH#configure confirm                                     // confirm changes

Managing IOS Images

The archive command can also be used for various operations with IOS images on the switch.

Working with TAR Files

With archive tar, we can work with TAR files, supporting creating a tar file (/create), listing files inside the tar (/table), and extracting the contents of the tar (/xtract).

Uploading Image to Server

Another function is the ability to upload an image file to a server (upload) as a backup or for subsequent download to another switch. By default, we have a directory on the switch with the IOS name and version, containing the BIN file with the OS itself, possibly the web interface. Using archive, the active directory with the image (found using show version) is packed into a TAR file and uploaded to the URL. Here is an example including part of the output.

SWITCH#archive upload-sw ftp://user:password@10.0.0.10/c3750e-universalk9-mz.122-40.SE.tar
System software to be uploaded:
System Type:              0x00000002
Writing c3750e-universalk9-mz.122-40.SE.tar !
archiving c3750e-universalk9-mz.122-40.SE (directory)
archiving c3750e-universalk9-mz.122-40.SE/c3750e-universalk9-mz.122-40.SE.bin (11439675 bytes)!

Note: If uploading to a TFTP server, it must be specially configured. I also had trouble uploading the file with the full name to FTP, so I had to shorten it.

Downloading the Image from the Server

The opposite function to upload is download, i.e., downloading the image from the server to the switch. This is essentially an upgrade of the switch, as the tar file is downloaded, extracted, and the switch may be restarted. We can choose whether to overwrite the current image with this new one or keep the current image and add the new one. During the upgrade, it checks if there is enough free space and if the image matches the switch or if it is the same version already on the switch.

SWITCH#archive download-sw ftp://user:password@10.0.0.10/c3750.tar
Loading c3750.tar !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!
[OK - 25353216/4096 bytes]
Loading c3750.tar !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
examining image...
extracting info (110 bytes)
extracting c3750e-universalk9-mz.122-40.SE/info (397 bytes)
extracting c3750e-universalk9-mz.122-40.SE/info (399 bytes)
extracting info (110 bytes)
Stacking Version Number: 1.36
System Type:             0x00000002
  Ios Image File Size:   0x00AEB200
  Total Image File Size: 0x017F7800
  Minimum Dram required: 0x08000000
  Image Suffix:           universalk9-122-40.SE
  Image Directory:        c3750e-universalk9-mz.122-40.SE
  Image Name:             c3750e-universalk9-mz.122-40.SE.bin
  Image Feature:          IP|LAYER_3|PLUS|SSH|3DES|MIN_DRAM_MEG=128

When a download is in progress, we can check the status of the operation, and the response will be one of the following.

SWITCH#show archive status
IDLE: No upgrade in progress
LOADING: Upgrade in progress
EXTRACT: Extracting the image
VERIFY: Verifying software
RELOAD: Upgrade completed. Reload pending

Note: On a stack, the archive command can only be used on the master switch, and the image is then copied to all members. To upgrade a switch with an incompatible image, we can use archive copy-sw to copy from an existing stack member. The switch will automatically restart and join.

With the archive download-sw command, we can use some of the following switches, for example:

• /overwrite - overwrites the original image in flash memory
• /reload - restarts the switch after downloading the image (if there are no unsaved configuration changes)
• /leave-old-sw - keeps the original image on the switch
• /allow-feature-upgrade - allows installation of an image with different feature sets

Note: If the memory is full, we can manually delete the original image using delete /force /recursive url. Just do not restart the switch until the new image is uploaded.

The entire upgrade operation can take quite a long time. The process is such that a update directory is created, the downloaded image is extracted into it, if overwrite is set, the original directory is then deleted, and the update is renamed to the correct name.