As a network engineer, I’ve broken configs enough times to know the value of a solid rollback strategy. One of the most powerful, yet sometimes underutilized, commands in the Cisco IOS and IOS-XE toolkit is configure replace. While it might seem like a simple operation, understanding its nuances and integrating it into modern workflows is crucial for maintaining network stability.
This post, originally penned in 2011, touched upon the fundamental use of configure replace. Today, I’m going to dive deeper, updating the information to reflect current best practices, platform relevance (hello, IOS-XE!), and how this command fits into the larger landscape of network automation and Infrastructure as Code (IaC).
What is `configure replace` and Why Use It?
At its core, the configure replace command allows you to replace the current running configuration of your Cisco device with an entirely different configuration file. Unlike simply pasting configuration lines, which merges changes, configure replace performs an atomic operation. It intelligently calculates the differences between the current running configuration and the specified configuration file, then applies the necessary additions and deletions to make the running configuration identical to the new file.
I find this command particularly indispensable for several reasons:
- Atomic Rollback: If a configuration change goes wrong, you can quickly revert to a known good state. This is a lifesaver in emergency situations.
- Standardization: Apply a baseline configuration or a specific module’s configuration across multiple devices consistently.
- Testing & Staging: Rapidly deploy and rollback test configurations in a lab environment or during a maintenance window.
- Minimizing Errors: By providing a complete configuration file, you reduce the risk of partial application errors that can occur with manual pasting.
The Classic `configure replace` Workflow
Let’s revisit the fundamental operation, just as I learned it back in the day, which remains fully valid on modern Cisco IOS-XE platforms like the Catalyst 9000 series, ISR 4000 series, and ASR 1000 series.
First, you need to ensure your desired configuration file is accessible by the router, typically in its flash memory or via a remote server (TFTP/FTP/SCP).
Step 1: Verify the Configuration File’s Presence
You can check for available files on your device’s flash memory using the dir flash: command. While my original example shows a Cisco 2800 series router (a classic, but now retired!), the command output and principle apply directly to today’s devices:
R1#dir flash:
Directory of flash:/
1 -rw- 1241 Feb 14 2011 17:19:34 +00:00 _DO_NOT_DELETE_baseconfig
2 -rw- 59478200 Sep 7 2010 22:50:24 +00:00 c2800nm-adventerprisek9-mz.124-24.T3.bin
3 -rw- 64652888 Sep 7 2010 23:00:30 +00:00 c2800nm-adventerprisek9-mz.151-2.T1.bin
4 drw- 0 Mar 31 2009 17:35:40 +00:00 ips
11 -rw- 59491364 Oct 6 2010 18:32:50 +00:00 c2800nm-adventerprisek9-mz.124-24.T4.bin
12 -rw- 2290 Jan 30 2011 17:50:32 +00:00 r1
13 -rw- 61731904 Jan 13 2010 17:40:32 +00:00 c2800nm-adventerprisek9-mz.150-1.M1.bin
14 -rw- 4326 Jan 26 2011 22:39:10 +00:00 r2
15 -rw- 59455672 Feb 17 2010 16:39:38 +00:00 c2800nm-adventerprisek9-mz.124-24.T2.bin
16 -rw- 1652 Apr 7 2011 19:27:20 +00:00 Nedumpillil
17 -rw- 1785 Mar 13 2011 02:51:50 +00:00 scsosna
18 -rw- 2540 Jun 12 2011 05:55:06 +00:00 Rack1R1
19 -rw- 1970 May 22 2011 13:09:20 +00:00 ice.txt
20 -rw- 2271 Jun 11 2011 19:06:52 +00:00 13.txt
21 -rw- 600 Jun 2 2011 15:45:14 +00:00 vlan.dat
1054457856 bytes total (749060096 bytes free)
Let’s assume we want to replace the running configuration with the file named Rack1R1 stored in flash memory.
Step 2: Execute the `configure replace` Command
This is where the magic happens. You’ll specify the location of your desired configuration file. You’ll also be prompted for confirmation, which is a good thing – this command makes significant changes!
R1#configure replace flash:Rack1R1
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
Total number of passes: 0
Rollback Done
Rack1R1#
Notice how the prompt changed from R1# to Rack1R1#. This is a strong indicator that the configuration replacement was successful and the new hostname from the `Rack1R1` file has been applied. Always observe the prompt change as a quick sanity check!
Rolling Back to Startup-Config
I often find myself using configure replace nvram: if I’ve made some egregious configuration mistakes and just want to reset to the last saved good configuration (which resides in NVRAM as the startup-config).
Rack1R1#configure replace nvram:
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
Total number of passes: 0
Rollback Done
R1#
Here, the prompt reverted to R1#, confirming the configuration from NVRAM (which had hostname R1) was successfully loaded. A crucial point to remember: If you accidentally saved your “messy” configuration to NVRAM, then `configure replace nvram:` will unfortunately load that same messy config. Always save a known-good configuration!
Advanced `configure replace` Features (IOS-XE)
Modern IOS-XE devices offer additional parameters that make `configure replace` even more robust:
list: This incredibly useful option displays the exact differences (additions and deletions) that will be applied before committing the replacement. It’s like a dry run for your configuration change.time: This enables a rollback timer. If you don’t issue theconfigure confirmcommand within the specified time (default 300 seconds if not specified), the device automatically reverts to its original configuration. This is fantastic for preventing complete lockouts during remote changes.nolock: Disables the configuration lock that normally prevents other users from making changes during a replace operation. Use with extreme caution in multi-user environments.force: Forces the replacement even if errors are encountered during the diff generation. Not recommended for production.
Here’s an example using list and time:
R1#configure replace flash:new_config.cfg list time 60
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. This replacement will automatically revert
in 60 seconds unless confirmed. Enter Y if you are sure
you want to proceed. ? [no]: Y
+++ no access-list 10
+++ access-list 10 permit ip any any
--- ip access-list standard TEST
--- permit any
--- exit
+++ interface GigabitEthernet0/1
+++ ip address 192.168.1.1 255.255.255.0
+++ no shutdown
+++ exit
Rollback: Config Apply Failed. Automatically reverting...
After reviewing the listed changes, if you’re satisfied, you would then type configure confirm within the 60-second window:
R1#configure confirm
Total number of passes: 0
Rollback Done
R1#
If you realize immediately that the change is wrong and you want to revert without waiting for the timer, you can use:
R1#configure revert now
Rollback: Manual revert.
Best Practices & Critical Considerations
While powerful, configure replace must be used thoughtfully:
- Always Save a Known Good Config: Before performing a significant
configure replace, always perform acopy running-config flash:good_config_DATEto have a specific rollback point. - Persistence is Key: Remember that
configure replaceonly modifies the running configuration. For the changes to persist across a reboot, you *must* explicitly save them usingcopy running-config startup-config(orwrite memory). - Configuration Archiving: Modern IOS-XE devices support configuration archiving. Configure
archiveto automatically save running configurations to a remote server or local flash at regular intervals or when changes are committed. This provides a robust history of configurations. - Validate After Replace: Don’t just assume success. Use commands like
show running-config diff flash:your_file.cfg(after you’ve saved your new running-config) or application-specificshowcommands (e.g.,show ip interface brief,show route) to verify the desired state. - Security: Be mindful of where you store your configuration files. Ensure appropriate access controls are in place for remote servers (TFTP/FTP/SCP) or local flash storage.
Modern Alternatives: Configuration Management as Code
While `configure replace` is excellent for individual device management or emergency rollbacks, modern enterprise networks demand more scalable and automated solutions. This is where Network Automation and Infrastructure as Code (IaC) come into play.
Git-based Workflows
Instead of manually saving config files to flash, network engineers now increasingly manage their device configurations in Git repositories. This provides:
- Version Control: A complete history of every change, who made it, and when.
- Collaboration: Teams can work on configurations simultaneously using branches and pull requests.
- Auditing: Full audit trail for compliance and troubleshooting.
Automation Tools and Orchestration
Tools like Ansible, Terraform, and Cisco’s own Network Services Orchestrator (NSO) or Cisco Catalyst Center (formerly DNA Center) are now the backbone of large-scale configuration management. These platforms can:
- Automate Deployment: Push configurations to hundreds or thousands of devices simultaneously.
- Declarative Configuration: Define the desired state of the network, and the tools ensure that state is achieved.
- Pre-Checks & Post-Checks: Integrate validation steps before and after configuration changes.
- Automated Rollback: Many orchestration tools have built-in rollback capabilities, often leveraging mechanisms similar to `configure replace` or more sophisticated transaction models.
Even with these advanced tools, understanding `configure replace` is still valuable. An Ansible playbook or a NSO service might very well be executing a `configure replace` command under the hood on a specific device to achieve an atomic configuration update or rollback, but it’s abstracted away and managed systematically.
Observability-Driven Configuration Management
In 2024 and beyond, it’s not enough to just apply a configuration. We need to continuously monitor its impact. Integrating network observability platforms with your configuration management workflows ensures that after a `configure replace` or an automated deployment, the network’s health and performance are validated. Tools using streaming telemetry (like gNMI) can detect anomalies or performance regressions almost instantly, allowing for rapid automated or manual rollback if a bad configuration slips through.
Conclusion
The configure replace command has been a cornerstone of Cisco device management for years, and its utility endures. Whether you’re a seasoned engineer performing an emergency rollback or a network automation enthusiast integrating it into a larger orchestration framework, its atomic operation provides a critical layer of safety and efficiency.
Remember, mastering the CLI remains fundamental, but combining that knowledge with modern automation tools and a vigilant approach to observability is the key to managing today’s complex, dynamic networks. So, go forth, configure (and replace!), but always do so with a solid plan and a backup!
- Justifying a $50k or even Higher Annual Switch Upgrade: What Must-Have Features Are We Missing? - November 13, 2025
- Managing Overlapping Private IPs in Multi-Client Site-to-Site VPNs: Best Practices? - November 7, 2025
- Epson EpiqVision Flex CO-W01 Projector Review - February 21, 2025