About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Cisco's configuration rollback does not undo the last commands you typed. It moves the running configuration toward a complete saved file. Without a suitable complete saved file, this feature has no target from which to reconstruct the intended state. If you load the file with copy into the running configuration, the device merges it and leaves the bad lines standing.
That is the discipline. Save a complete device-written configuration before the change. Know whether the return will add and remove lines, or only add them. Expect some lines to fail when the hardware does not match the file. Do not treat a confirmation timer as tested on your release until you have read the guide for that release: the Fuji 16.7.x chapter describes the timer in minutes and, in one note, in seconds.
Nothing in this article was run. The behaviour is the behaviour described in one Cisco chapter. Later trains can differ.
Why it matters
A failed change on a router is often reversed by someone who still has a session, typing the opposite commands from memory. That works for a single line. It fails for an access list, a policy map, or a block of routing statements, because the opposite of a list is not obvious and the order is the meaning.
The other habit is to paste yesterday's backup into the running configuration. On IOS XE, as this guide describes it, that paste is a merge. Lines in the backup are applied. Lines that exist only in the running configuration are kept. The device can end up with both the old list and the new list, or with the new list still installed because nothing removed it.
The Fuji 16.7.x chapter exists to give operators a third action: replace the running configuration with a saved one without reloading, by applying only the differences. The recovery value is real. The conditions are strict, and they are easy to miss if the only thing remembered is the command name.
What "rollback" means in this feature
The chapter borrows the database word and then defines it differently. Database rollback concerns transaction effects and depends on the database’s logging and recovery design. This Cisco feature instead compares configurations; it does not replay an operator-command undo journal. Rollback here means returning to a specific saved configuration state. The guide says you save the running configuration before you change anything, and after the change you use that file with configure replace. Any saved complete IOS configuration can be the target, so you are not limited to a fixed number of journal steps. You are limited to the files you actually kept.
The archive feature, which stores numbered copies under a path you set, is how Cisco expects those checkpoints to be managed. The maximum number of archived files is 1 to 14, default 10, and the oldest is deleted when the next one is saved. That rotation limit is not the same statement as "rollback can use any saved file". A file you copied somewhere the rotation does not touch is still a valid target. A file the rotation has already deleted is not.
The chapter contradicts itself on whether the archive is required. One passage says no archive configuration is needed to use configure replace, and that using the archive is optional. The procedure then says you must create a configuration archive before performing the replace steps. This article does not pick a winner. A plan that depends on archive config should follow the procedure. A plan that uses a file written by copy running-config to a URL should treat that file as the target and should not assume the archive exists.
What replace does, and what copy does
When configure replace runs, the current running configuration is compared with the target file. The guide says the comparison is the same algorithm as show archive config differences. The resulting differences are applied by the parser. Commands already present are not applied again. Commands in the running configuration that are absent from the file are removed. Commands that need to be added are added.
Order-dependent commands, and the guide names access lists, are handled with more than one pass. Under normal circumstances no more than three passes are needed. A limit of five passes is there to stop a loop.
copy from a URL into the running configuration is described as the common alternative, and the guide lists the differences:
- Copy merges. It keeps commands from the file and from the running configuration. It does not remove running commands that are missing from the file. Replace removes them.
- Copy applies every command in the file, even commands that are already present. The guide says that can cause service outages. Replace applies only the commands that need to change.
- Copy accepts a partial file. Replace requires a complete configuration generated by a Cisco device, or an external file that follows the same format.
The format rules are part of the prerequisite, not a style preference. Top-level commands start at the beginning of the line. Commands in the first submode are indented one space, the next level two spaces, and so on. The guide says this is how the device writes files for show running-config and copy running-config. A file the device wrote complies. A file that was re-indented by an editor or a backup tool is not guaranteed to comply. This article did not test any tool.
There is a separate failure for files that did not come from IOS. The chapter notes that if a login banner uses a delimiter other than the EXT character, ASCII 3, the banner configuration is rejected and left out of the replaced configuration. It names ^C, %, # and CC as delimiters that do not work in that case. A replaced configuration can therefore be missing its banner even when the rest of the file is accepted. That is a reason to read the result, not a reason to assume the file landed whole.
What replace will refuse
Three restrictions are stated as hard limits.
Free memory must be larger than the two files together, the running configuration and the replacement file. If it is not, the replace is not performed.
Commands that describe physical parts of the device cannot be added or removed against the hardware. The guide's example is an interface ethernet 0 line: replace cannot remove it if that interface is physically present, and cannot add interface ethernet 1 if that interface is not present. Those lines fail with error messages. The rest of the discussion does not say the whole operation is cancelled. Plan for a device that is partly moved toward the file, with the hardware lines reported as failed.
In rare cases a command cannot be removed from the running configuration without a reload. Replace reports that those lines failed. The guide's stated benefit of the feature is that you can return toward a saved file, including the startup configuration, without reloading and without undoing lines by hand. That benefit stops at the lines that need a reload. A reload is a separate decision, with its own outage, and this article does not recommend one.
Lock, list, force, and the timer
The running configuration is locked by default for the duration of the replace, so another user cannot change it mid-operation and cause the replace to fail. The lock is cleared when the operation ends. show configuration lock displays locks. The nolock keyword turns the lock off. Our recommendation, not a Cisco instruction: leave the lock on unless you have a specific reason to allow a concurrent session. A second editor during a replace is how a return stops halfway for a reason that is hard to reconstruct afterwards.
The list keyword displays the command lines applied on each pass, and the number of passes. The force keyword replaces without prompting for confirmation. Those are different kinds of "do it". The list option reports commands applied during replacement; it is not a dry run. The separately documented differences display is the pre-change comparison. Force is how you skip the question. They are not a pair that should be chosen by habit.
The archived chapter describes confirmed rollback conceptually: a change remains conditional until confirmed, and otherwise returns to the earlier configuration after a deadline. It also describes error-triggered return. These are state-changing controls, not diagnostic checks. They cannot establish that an unreachable device will recover safely on a different release or platform.
The historical chapter conflicts about timer units: its command description and a confirmation note disagree. It also conflicts about whether an archive must already exist. This review therefore supplies no timer, confirmation, immediate-return or reset syntax and recommends no value or prerequisite from those passages. An approved operational procedure needs the exact release’s command reference and a controlled verification of timer behaviour, including a recovery path independent of the management connection being changed.
The distinction still matters when reviewing a backup plan. A saved checkpoint says what configuration you intend to restore. A confirmation facility says how the device handles an unconfirmed change. Neither is proof that the saved configuration fits the current hardware, that every command can be reversed, or that the operator will regain access. Record those as separate checks rather than treating the presence of a timer as a complete rollback design.
What to decide before anyone is locked out
Decide the checkpoint rule first. The file you will return to is the running configuration saved before the change, written by the device, not a partial snippet and not a file saved after the bad change has already been archived by a timer. A timer copy taken after the failure is a record of the failure.
Decide the command. If the intention is that the running configuration should lose the lines that are not in the file, the guide says that is configure replace, not copy into the running configuration. If the intention is to add a partial block and keep everything else, replace is the wrong tool, because it expects a complete file and it removes what the file does not contain.
Decide what a failed line means. Hardware lines that do not match the chassis will fail. A replacement router with different interface names will not become the old router because the file said so. The error messages are the list of what did not move. The recovery plan should say who reads them and who decides whether the remaining difference is acceptable, rather than repeating the command with force.
Decide whether the session is at risk. If the change can drop the path back to the operator, the confirmation timer is the mechanism the guide provides, and the unit conflict above has to be resolved on your release before the change, not during it. A timer you do not understand is not a safety net. Console access that does not depend on the path you are changing is the access that still works if the timer is wrong. This article does not describe how to cable a console.
Decide who else is in the configuration. The default lock exists because a concurrent change can make the replace finish unsuccessfully. A change window with two engineers in configuration mode is a way to trip that.
How to look before you change anything
The monitoring section of the chapter documents show archive as the view of files saved in the archive: how many exist, the name of the next file, and which one is most recent. It also shows deleted slots after rotation. That is the read you want when the question is "what checkpoints does this device still have?" It does not show files you stored on a server outside the archive path. Those have to be found where they were written.
debug archive versioning and debug archive config timestamp are documented for troubleshooting the feature. Debug output is not a prerequisite for a recovery plan, and turning debug on during an incident adds load. This article does not recommend enabling it as a first step.
show archive config differences is named as the same comparison replace uses. It is the way to see a difference without applying it, if the release you run still provides that command as documented. Confirm the command on your release before you depend on it. It was not run here.
Risks and limits
The chapter used here was updated on 10 December 2017 for IOS XE Fuji 16.7.x. The vendor site returned HTTP 403 on 13 November 2026, so the wording is from the Internet Archive capture of 9 December 2022. The guide tells readers to check release notes and Cisco Feature Navigator because a release may not support every feature in the module. This article does not claim support on any current train, and it does not claim that Nexus, ASA, IOS XR or Meraki work this way. Those platforms are outside the chapter.
The archive rotation, the file-system list, and where a copy has to live to survive a dead device are a separate problem. A replace is only as good as the file you name.
No configuration was replaced. No timer was measured. The pass limit, the memory rule and the hardware rule are the guide's statements, not results from a lab.
Research and verification
Drafted with AI assistance on 11 November 2026 and independently source-reviewed on 13 November 2026. No equipment was configured, no article commands were executed and no lab behaviour is claimed. This is educational source research, not an approved production recovery procedure.
Sources
- Cisco, Managing Configuration Files Configuration Guide, Cisco IOS XE Fuji 16.7.x, chapter "Configuration Replace and Configuration Rollback", updated 10 December 2017. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/config-mgmt/configuration/xe-16-7/config-mgmt-xe-16-7-book/cm-config-rollback.html — replace versus copy, passes, lock,
list,force,time,configure confirm,configure revert,revert trigger, memory and hardware restrictions, banner delimiter note, archive maximum and default,show archive. Text read from https://web.archive.org/web/20221209064244/https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/config-mgmt/configuration/xe-16-7/config-mgmt-xe-16-7-book/cm-config-rollback.html captured 9 December 2022, because www.cisco.com returned HTTP 403 on 13 November 2026.
This article was originally published on .