Rollback you do not have to remember: confirmed network commits
Commit confirmed, revert timers, checkpoints and snapshot diffs: how to make a network change undo itself when it cuts you off, platform by platform.
Every network engineer knows the feeling: you press enter on an access list or a routing change, and the SSH session stops responding. Now the question is whether someone can reach a console before customers notice. The better question is why the change was able to strand you at all. Most serious network platforms can undo a change by themselves if you stop confirming it. This article walks through how, platform by platform, and the habits that make it reliable.
The principle: a change must earn its permanence
A change should become permanent only after you have proved, from a working session, that the device is still reachable and behaving. If you never get to confirm, because the change cut you off, the device should put itself back. That turns the worst case of a bad change from "drive to the datacenter" into "wait a few minutes".
Four building blocks make this work: a saved copy of the configuration before the change, a timer that reverts unless confirmed, a way to compare state before and after, and the discipline to save only after verifying.
Juniper: commit confirmed
Junos has the cleanest model. Changes are staged in a candidate configuration and applied with a commit; a confirmed commit rolls back on its own unless you commit again:
commit confirmed 5
# verify reachability, routing, the thing you changed
commit
If the session dies, the router rolls back to the previous configuration after five minutes. show system commit and rollback <n> give you history and a fast manual return.
Cisco IOS-XR: commit confirmed too
IOS-XR follows the same idea:
commit confirmed 300
# verify
commit
Use show configuration commit list to see recent commits and rollback configuration last 1 to step back deliberately.
Cisco IOS-XE: revert timers
IOS-XE applies commands live, so the safety net has to be armed first. The archive feature provides it:
archive
path bootflash:archive
maximum 14
!
configure terminal revert timer 5
! make the change
configure confirm
If you do not confirm within five minutes, the device rolls back to the configuration it had when you entered configuration mode. For replacing a whole configuration from a file, pair the replace with automatic revert on error rather than forcing it:
configure replace bootflash:known-good.cfg revert trigger error timer 5
A full replace with force skips the safety prompts, so reserve it for restoring a snapshot that the same device produced itself, and prefer merging or applying section by section for anything else.
Cisco NX-OS: checkpoints
NX-OS offers named checkpoints and atomic rollback:
checkpoint before-change-001
! make the change
show diff rollback-patch checkpoint before-change-001 running-config
rollback running-config checkpoint before-change-001 atomic
There is no built-in confirm timer, so on Nexus the discipline carries more weight: verify the hostname before the first command, apply one command at a time, check the result, and keep the checkpoint plus an off-box copy of the configuration until the change is proven.
Firewalls and Linux: build the timer yourself
Where a platform has no confirm mechanism, arm one outside the change. On a Linux host, systemd can schedule the undo before you touch anything risky:
systemd-run --on-active=240 --unit=net-safety /usr/local/sbin/restore-previous-network.sh
# make the change, then verify with a brand new SSH session
systemctl stop net-safety.timer
The timer fires even if your session dies, so a mistake in a firewall or SSH configuration fixes itself in four minutes. For firewall appliances with an API, the same idea becomes a scripted cutover: take a configuration backup on every node, apply the change, run reachability checks, and restore the backup automatically if they fail.
Snapshots and diffs: did anything else move?
A change can succeed at what it intended and still disturb something else. Before and after every step of a larger rollout, capture the state that matters (routing session summaries, interface status, overlay peers) and diff them:
show bgp all summary > before.txt
# change
show bgp all summary > after.txt
diff before.txt after.txt
If anything changed that should not have, roll back while the cause is still obvious. Automate it and you can enforce it on every device of a rollout, with automatic rollback when the diff is not clean.
Habits that make the tools work
- One half of a redundant pair at a time. Change the standby, verify, then the active. A mistake then costs redundancy for a few minutes, not service.
- Verify from a new session. An existing SSH session can survive a change that blocks new ones. Open a fresh one before you confirm.
- Save last. Write the running configuration to startup only after verification. Until then, a reload is also a rollback.
Ask your own team
- Which of your platforms support confirmed commits or revert timers, and are they used every time?
- Is there an off-box copy of every device's configuration from before the last change?
- Do rollouts compare routing state before and after each step?
- Is anything ever changed on both members of a redundant pair at once?
Our network changes follow this discipline on every platform, and if a change could touch your traffic, we agree the timing with you first. If you want help building the same safety nets into your own operations, talk to us.
Published 22 October 2026.
All field notes