Cisco IOS XR Configuration Management: Commit and Rollback

IOS XR separates the configuration you are editing from the configuration the router is running. Nothing takes effect until it is committed, every commit is recorded with an ID and a comment, and any of them can be rolled back. That model turns configuration change from an act of faith into a reversible operation - provided the engineer uses the features rather than treating XR like IOS with different prompt formatting.

The core model: target, running, commit database

Because the target and the running configuration are separate, an abandoned editing session leaves no trace on the router - and an interrupted change is visible with the right command rather than inferred from broken behaviour. When a support case requires "the config when it broke", the commit list is the evidence.

Commit confirmed: the remote-change safety net

RP/0/RSP0/CPU0:router# configure
RP/0/RSP0/CPU0:router(config)# interface GigabitEthernet0/0/0/1
RP/0/RSP0/CPU0:router(config-if)# ipv4 address 10.0.0.1 255.255.255.0
RP/0/RSP0/CPU0:router(config-if)# commit confirmed 5

commit confirmed applies the change and starts a timer; if the change is not confirmed with commit before the timer expires, the router automatically rolls back to the previous configuration. This is the single most important habit for anyone editing interfaces, ACLs or routing policy over a path that the change might itself break. The timer gives you the same protection on a management-plane ACL as a console cable, without needing the console cable.

Diffing and commenting changes

RP/0/RSP0/CPU0:router(config)# show configuration
RP/0/RSP0/CPU0:router(config)# commit comment "CASE-12345 open BGP peer to AS64512"
RP/0/RSP0/CPU0:router# show configuration commit changes
RP/0/RSP0/CPU0:router# show configuration commit changes last 3
RP/0/RSP0/CPU0:router# show configuration rollback-changes

Committing with a comment costs nothing and makes the commit database readable weeks later. During an incident, show configuration commit changes answers the first question every investigation asks: what changed?

Rollback: selective and complete

! roll back the last commit
RP/0/RSP0/CPU0:router# rollback configuration last 1

! roll back to a specific commit ID
RP/0/RSP0/CPU0:router# rollback configuration to 1000000075

! roll back a single interface rather than the whole config
RP/0/RSP0/CPU0:router(config)# rollback configuration to 1000000075 interface GigabitEthernet0/0/0/1

The selective form is what makes rollback usable on a production router carrying live traffic: an interface-level rollback restores the previous state of that entity without touching the rest of the configuration committed since. Note that a commit ID removed from the commit database can no longer be rolled back to, which is a reason to check show configuration commit list before relying on an old reference.

Loading and replacing whole configurations

RP/0/RSP0/CPU0:router(config)# load /path/to/config.cfg
RP/0/RSP0/CPU0:router(config)# load harddisk:/baseline.cfg replace
RP/0/RSP0/CPU0:router(config)# commit
RP/0/RSP0/CPU0:router# show configuration

load merges a file into the target configuration; load ... replace replaces it wholesale. Merge is the safe default for adding a block of configuration. Replace is what you want when the intent is to restore a known baseline exactly - and it is also the operation that most deserves a commit confirmed timer, because a mistake there removes configuration rather than adding it.

For the surrounding operational practices - process and memory troubleshooting, RPL policy, and automated backups - see IOS XR processes, CPU and memory troubleshooting, IOS XR RPL routing policy and configuration backup with Oxidized. The equivalent safety net on Junos is described in commit confirmed on Junos.

原文链接：http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.7/system_management/command/reference/yr37conf.html