Cisco IOS XR Commit Replace and Rollback Configuration

IOS XR configuration does not change the moment you type a command — every change lives in a candidate configuration until you commit it. That commit-based model is what makes commit replace and configuration rollback such powerful safety tools on ASR 9000, NCS and 8000 series routers. commit replace is the IOS XR equivalent of wiping the router clean (like write erase on classic IOS), while rollback lets you return to any previously committed configuration. This article explains both mechanisms with real command sequences and the operational habits that keep you out of trouble.

Understanding the IOS XR Commit Model

In IOS XR every configuration session produces a commit with a unique ID, and each commit can carry an optional label. You can list all commits and roll back to any of them, which is fundamentally safer than classic IOS because the device keeps a complete history of configuration changes:

RP/0/0/CPU0:router# show configuration commit list
RP/0/0/CPU0:router(config)# commit label TEST

Three properties of this model are worth internalising before you use the commands.

First, the commit history is not a diff archive you have to interpret — it is a series of complete, restorable configurations. Rolling back to commit 1000000015 reconstructs the running configuration exactly as it was at that instant, without you replaying the individual changes.

Second, the history is finite but generous, and it is written by the router itself rather than by your terminal session. Closing your SSH window does not lose the ability to roll back.

Third, admin-mode configuration and SDR configuration have separate histories. A rollback performed in EXEC mode affects that SDR's configuration; admin-mode changes live in the admin plane. When you roll back after a maintenance window that touched both, check which plane you are in before you assume the rollback covered everything.

Reading the Commit History

RP/0/0/CPU0:router# show configuration commit list
RP/0/0/CPU0:router# show configuration commit list detail
RP/0/0/CPU0:router# show configuration commit changes 1000000015
RP/0/0/CPU0:router# show configuration commit changes last 2

show configuration commit list prints one line per commit: the commit ID, the optional label, the user who made it and the timestamp. show configuration commit changes then shows what that commit actually changed, which is how you confirm you have found the right rollback target instead of guessing from the timestamp.

Make this part of incident response, not an afterthought. When someone asks "what changed at 14:05?", the answer is two commands away and is far more reliable than interviewing the engineers who were logged in. The last <n> form is the fastest way to review the recent sequence during a change window.

Wiping the Running Configuration with Commit Replace

To erase the entire running configuration, enter configuration mode and issue commit replace. IOS XR warns that the operation is service affecting and asks for confirmation:

RP/0/0/CPU0:PE1# configure terminal
RP/0/0/CPU0:PE1(config)# commit replace
This commit will replace or remove the entire running configuration. This
operation can be service affecting.
Do you wish to proceed? [no]: yes

After the commit, show running-config returns an empty configuration. Note that commit replace removes the whole configuration, so it is normally used to decommission a router or to start from a clean slate during re-provisioning.

Be precise about what "empty" means here. The candidate configuration you are replacing is whatever is currently staged, and by default that is nothing — so the operating configuration becomes empty. Interfaces go down, routing protocols disappear, management addresses are removed and the router becomes reachable only through the console or a directly connected port. If a management interface carries your SSH session, that session terminates as the configuration is committed.

The safer variant for re-provisioning is to stage the replacement first and commit it in one step, so the router moves from one complete configuration to another without passing through an empty intermediate state:

RP/0/0/CPU0:PE1# configure terminal
RP/0/0/CPU0:PE1(config)# load harddisk:/golden-config.txt
RP/0/0/CPU0:PE1(config)# show configuration
RP/0/0/CPU0:PE1(config)# commit replace

The load brings the file into the candidate configuration, show configuration lets you inspect the candidate before it goes live — this is the step people skip — and commit replace then makes the candidate the entire running configuration. There is no merge, no leftover statement from the old configuration and no need to reboot.

Rolling Back to a Good Configuration

If a change breaks the router, roll back to a previous commit ID or label — this is the recovery path you will use far more often:

RP/0/0/CPU0:PE1# rollback configuration to 1000000015
Loading Rollback Changes.
Loaded Rollback Changes in 1 sec
Committing..
Configuration successfully rolled back to '1000000015'.

Because the rollback itself becomes a new commit, IOS XR never loses the ability to undo an undo.

Labels make this practical at 03:00 when nobody remembers which commit ID was the good one. Label the configuration before any risky change, then roll back by name:

RP/0/0/CPU0:PE1(config)# commit label pre-upgrade
RP/0/0/CPU0:PE1# rollback configuration to label pre-upgrade
RP/0/0/CPU0:PE1# rollback configuration last 1

Three behaviours to know before you rely on it:

• Rollback is a commit. It writes a new entry into the history and it takes effect immediately. There is no confirmation prompt and no dry run unless you check the changes first with show configuration commit changes.
• Rollback restores configuration, not state. Counters, BGP sessions and routing adjacencies are re-established from scratch; a rollback of an interface or protocol change will cause the corresponding adjacency to reset.
• Labels are not unique. The same label may appear on several commits, and the rollback targets the most recent matching label — so use dated, specific labels rather than reusing one name forever.

Configuration Sessions and Locking

XR's candidate model means two engineers can edit the same router simultaneously, which is either a feature or an outage depending on how you start the session:

RP/0/0/CPU0:PE1# configure terminal
RP/0/0/CPU0:PE1# configure exclusive
RP/0/0/CPU0:PE1# configure private
RP/0/0/CPU0:PE1# show configuration sessions

configure exclusive takes a lock so that only your session can commit — the right choice for planned changes on a shared router. configure private gives you an uncommitted private candidate. show configuration sessions lists who else is editing, which is the command to run before you wonder why your commit produced something unexpected.

Safer Change Windows with commit confirmed

For risky maintenance, IOS XR supports a confirmed commit that is automatically rolled back if you do not confirm it within a timer:

RP/0/0/CPU0:router(config)# commit confirmed 5
RP/0/0/CPU0:router(config)# commit

If connectivity to the router is lost during the change window, the router reverts to the previous configuration when the timer expires — a classic protection against locking yourself out.

The timer is in minutes and the sequence matters: you run commit confirmed <minutes> to activate the change provisionally, then verify that you can still reach the router and that services are healthy, then run a plain commit to make the change permanent. If you never reach the second command — because the change cut your management path — the router restores the pre-change configuration by itself. Think of commit confirmed as an automated rollback trigger armed in advance, and use it for anything that touches management reachability.

Operational Best Practices

• Always label important commits (commit label pre-maintenance) so rollback targets are easy to identify.
• Test rollback configuration in a lab before you need it in production.
• Use commit confirmed for any change that could cut your management session.
• Never run commit replace casually: it removes every interface, protocol and management statement.
• Inspect the candidate with show configuration before a commit replace from a file, and keep the previous configuration saved off-box first.
• Save a copy of the running configuration to the router's harddisk or to a TFTP/SCP server before periodic maintenance, so an off-box restore path exists independently of the commit history.
• Record the commit ID or label you rolled back to in the incident ticket — the rollback itself is a commit, and the next engineer will want to know where the timeline forked.

Snapshot Before You Change

The commit history protects you from your own mistakes; it does not protect you from a chassis that will not boot. Before any maintenance window, take a copy of the configuration that lives off the router:

RP/0/0/CPU0:PE1# show running-config | file harddisk:/backup-pre-change.cfg
RP/0/0/CPU0:PE1# show configuration commit list | file harddisk:/commits.txt

Writing the output to the router's harddisk gives you a file you can copy off with SFTP, and capturing the commit list alongside it records which IDs existed before your change — useful when you later need to prove that a commit in the history came from the maintenance window and not from someone else. If your process allows it, also copy both files to a management server, because a router with a failed route processor takes its harddisk contents with it.

Then, before you commit anything, ask the three questions that turn this from a procedure into a habit: which commit will I roll back to if this fails, how will I reach the router if the change cuts my management path, and how long am I prepared to spend recovering before I escalate? Answering them takes thirty seconds and is the difference between a rollback and an outage.

Rollback Across SDRs and the Admin Plane

On a chassis running Secure Domain Routers, "the configuration" is not a single object. Each SDR maintains its own running configuration and its own commit history, and the admin plane maintains another. Consequences you will meet in practice:

• A rollback executed from inside an SDR restores that SDR's configuration only. If the change you regret was an interface assignment or a resource allocation made in admin mode, you must roll back in admin mode.
• Commit IDs are not comparable across planes. An ID that is a good rollback target in one SDR means something unrelated elsewhere, so always record which plane a rollback target belongs to.
• commit replace in one SDR empties that SDR, not the chassis — a distinction that matters more than it sounds when you are re-provisioning a single customer instance on shared hardware.

Change-Window Checklist

1. Label the current commit (commit label pre-change) and write the commit ID into the ticket.
2. Save the running configuration to a file and copy it off-box.
3. Enter the session with configure exclusive so a colleague cannot commit behind you.
4. Stage the change, then read it back with show configuration before committing.
5. If management reachability is at risk, commit with commit confirmed 5 and confirm deliberately.
6. Verify the services the change was meant to affect, not just the CLI.
7. Commit a closing label (commit label post-change) so the good state has a name.

Which Recovery Tool to Reach For

Frequently Asked Questions

Does commit replace require a reload?

No. The new configuration takes effect immediately at commit time, which is exactly why the operation is service affecting — there is no reload window in which to change your mind.

Can I roll back to a commit made by another user?

Yes. The commit history belongs to the router, not to a session or a user, so any operator with sufficient privilege can roll back to any entry. This is why labels and the change ticket matter more than personal notes.

What happens to my changes if commit confirmed expires?

The router reverts to the configuration from before the confirmed commit. Anything else you configured in that session and never committed is discarded at the same time.

Is there an equivalent on other platforms?

The same candidate-plus-commit idea appears across vendors with different trade-offs — see our write-ups on Arista EOS configuration sessions and Junos commit confirmed and safe rollback.

Related articles: Cisco IOS XR BGP configuration (iBGP/eBGP), IOS XR commit and rollback configuration, and Nexus NX-OS checkpoint and rollback configuration.

原文链接：https://community.cisco.com/t5/networking-knowledge-base/quot-commit-replace-quot-command-in-cisco-ios-xr/ta-p/3153954