Understanding the Cisco ‘configure replace’ Command

As I prepared this article, my full intention was for it to be a conclusive reference for using the Cisco Configuration Replacement and Configuration Rollback feature. When testing with various IOS versions, I found one key feature did not behave as documented. This feature is invoked with ‘time’ paramater and used to undo changes when the configuration is not confirmed. To say it didn’t behave as documented is probably an understatement. It simply did not work in my lab. Therefore this article is primarily about the ‘configure replace’ command .

In a previous article, we looked at using the ‘archive’ feature to automate the backup of IOS configurations. Having those files saved on an external server has many benefits. One benefit is the ability restore to a previous version of configuration. For example, there could be a need to restore a configuration to the state it was last saved. An obvious method to do this might be to copy the file to the running configuration.

Copy TFTP to Running Configuration

R1#copy tftp://192.168.2.2/R1-1.txt running-config

One serious issue with this is that there may be undesired commands left in the configuration. This is due to the fact that anything copied into running-config is actually a merge. So any commands that are not overwritten by those in the originating file will remain in the running configuration. Another option is to copy the configuration to startup-config and perform a reload.

Copy TFTP to Startup Configuration

R1#copy tftp://192.168.2.2/R1-1.txt startup-config
R1#reload
Proceed with reload? [confirm]

The obvious problem with this method is the fact that the network will be impacted for three to five minutes while the router reboots. A better option would be to deduce the commands that are necessary to return the current state of the IOS device to the configuration found in the file to be restored. That is exactly what the ‘configure replace’ does.

Using the ‘configuration replace’ Command

R1#$eplace tftp://192.168.2.2/R1-1.txt 
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]: yes
Loading R1.txt from 192.168.2.2 (via FastEthernet0/0): !
[OK - 4968 bytes]

This command actually goes through the process of comparing the running-config to that of the file specified in the command. It then iterates and applies the commands necessary to reach the configuration found in the file. This is similar to the process of comparing two archives. The following ‘show archive’ command shows that the running-config has two commands not found in the R1-1.txt archive. Using the ‘configure replace’ command would add those two commands.

show archive config differences

R1#show archive config differences tftp://192.168.2.2/R1-1.txt system:running-config
Loading R1-1.txt from 192.168.2.2 (via FastEthernet0/0): !
[OK - 6487 bytes]
!Contextual Config Diffs:
+interface Loopback9
 +ip address 9.9.9.9 255.255.255.255

In the previous example, the ‘copy tftp running-config’ would have similar results. This is true simply because it would only be adding two commands. Nothing is removed, so the ‘merge’ behavior would achieve the same results. However, consider example below.

show archive config differences

R1#show archive config differences tftp://192.168.2.2/R1-1.txt system:running-config
Loading R1-1.txt from 192.168.2.2 (via FastEthernet0/0): !
[OK - 6487 bytes]
!Contextual Config Diffs:
+interface Loopback9
 +ip address 9.9.9.9 255.255.255.255
-interface Loopback1
 -ip address 2.2.2.2 255.255.255.255

In this example, we can see that the R1-1.txt file has ‘loopback 1’ that isn’t in running-config. Additionally, running-config has ‘loopback 9’ that isn’t in R1-1.txt. If we performed a ‘copy tftp running-config’, the resulting running configuration would have both loopback interfaces. If we use the ‘configure replace’, only the ‘loopback 1’ interface will remain. There is a ‘list’ paramater that outlines the commands used to reach the final configuration iteration.

R1#configure replace tftp://192.168.2.2/R1-1.txt list    
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 R1-1.txt from 192.168.2.2 (via FastEthernet0/0): !
[OK - 6487 bytes]

Loading R1-1.txt from 192.168.2.2 (via FastEthernet0/0): !
!Pass 1
!List of Rollback Commands:
interface Loopback9
 no ip address 9.9.9.9 255.255.255.255
no interface Loopback9
interface Loopback1
 ip address 2.2.2.2 255.255.255.255
end

Total number of passes: 1
Rollback Done

The really useful feature that I mentioned earlier is the timed rollback. Unfortunately it doesn’t work correctly in my lab. The feature is invoked using the “time” or the “revert trigger timer” paramaters. As documented, the configuration should revert to the previous configuration if the administrator doesn’t enter the ‘configure confirm’ within the specified amount of time.

Time Based Configuration Rollback

R1#configure replace tftp://192.168.2.2 time ?
    confirmation time in minutes

R1#configure replace tftp://192.168.2.2 revert ?
  trigger  Define triggers for reverting back to the original
           config

R1#configure replace tftp://192.168.2.2 revert trig
R1#configure replace tftp://192.168.2.2 revert trigger ?
  error  Revert back to the original config upon error
  timer  Revert back to the original config if timer expires

R1#configure replace tftp://192.168.2.2 revert trigger time
R1#configure replace tftp://192.168.2.2 revert trigger timer ?
    Confirmation time in minutes

R1#configure replace tftp://192.168.2.2 revert trigger timer

Another benefit of understanding the configuration replace feature is that it gives an administrator the ability to use a text editor to modify one of the saved files, saving it as something else, then using the ‘configure replace’ command. This makes the router do the heavy lifting of determining the differences and the iterations of commands required to reach that configuration. A consideration that should be understood is that the syntax must be exact. Subcommands must also be spaced exactly as they are in a saved configuration. For example, subcommands must have one leading space. Sub-subcommands must have two leading spaces.

Text based configuration files offer a lot of flexibility for administrators who understand how to work with them. Cisco IOS devices have specific rules for what is merged and what is overwritten. Copying anything to the running-config is typically a merge. Using the ‘configure replace’ allows these devices to mimic a full replacement of the current configuration. At the end of the day, it is the device itself that is figuring out how to reach the desired configuration and iterating through the required commands. In any case, it is a feature that may prove useful in your environment.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in How-To. Bookmark the permalink.

One Response to Understanding the Cisco ‘configure replace’ Command

  1. A says:

    Why didn’t it work? I’ve attempted to run this command as well and was subsequently locked out of config mode. Do you have any any experience with or solution for this?

Comments are closed.