Junos commit confirmed: The Remote-Change Safety Net

Junos keeps two configuration states — the candidate you edit and the active configuration that is actually running — and a commit applies the candidate atomically. That model makes commit confirmed possible, and it is the single most useful command in the platform: apply a change, and if you do not confirm it within the timeout, the device rolls back by itself. This article covers the mechanics, the correct usage pattern, and the ways engineers accidentally disable their own safety net.

Candidate versus active configuration

Nothing you type in configuration mode affects the live network until you commit. On commit, Junos validates syntax, validates logical consistency (a policy referencing a non-existent prefix list fails here), and then applies the change atomically. If validation fails, the active configuration is untouched — which is why a failed commit is a non-event, not an outage.

commit confirmed: what it does

lab@sw-01# configure
[edit]
lab@sw-01# set interfaces ge-0/0/3 description TEST-UPLINK
lab@sw-01# commit confirmed 5
commit confirmed will be rolled back in 5 minutes
commit complete

The change is applied immediately, but a timer starts. If you do not issue a normal commit before the timer expires, Junos automatically loads and commits the previously committed configuration — the default timeout is 10 minutes if you omit the argument.

# confirm the change before the timer expires
lab@sw-01# commit
commit complete

Why the gap between the two commits matters

The command is frequently misused by issuing commit confirmed and then confirming a few seconds later. That defeats the purpose: the safety net exists to cover the time it takes to verify reachability from outside the device, over the path you just changed. A workable pattern is:

1. Apply the change with commit confirmed 5.
2. From a separate session or host, verify the thing you changed — ping the far end, check the routing protocol adjacency, run a traceroute.
3. If verification passes, return and run commit.
4. If it fails, do nothing and let the rollback restore service, or issue rollback 1 and commit manually.

Five minutes is usually the right window for a routed change; use a longer value for changes where you must coordinate with a remote team.

Extending the timer

Re-issuing commit confirmed before the deadline resets the rollback timer, which is useful when a change needs more observation time but you still want the safety net. Remember that the second commit confirmed also restarts the clock, so you need an explicit commit to finish.

lab@sw-01# commit confirmed 10
commit confirmed will be rolled back in 10 minutes
commit complete

Validate before you commit

lab@sw-01# commit check
configuration check succeeds
lab@sw-01# show | compare

commit check performs the same validation as a commit without applying anything, and show | compare prints the diff between the candidate and the active configuration. Running both before every commit turns "did that do what I meant?" into a reading exercise rather than an outage.

Rollback and history

lab@sw-01# rollback 1
load complete
lab@sw-01# show | compare
lab@sw-01# commit

Junos keeps a rolling history of committed configurations. rollback 1 restores the previous one into the candidate — it does not take effect until you commit, which gives you a chance to inspect the diff. For deliberate changes, add a comment to make future rolls back obvious:

lab@sw-01# commit comment "CHG12345 uplink renumber"

Other safety mechanisms worth pairing with it

• Rescue configuration — a known-good baseline you can activate from the loader prompt when nothing else is reachable.
• commit at / commit synchronize — schedule a commit at a specific time, and synchronise across redundant routing engines.
• Configuration archival — push a copy of every commit to a remote server so you always have an off-box recovery point.
• Login class restrictions — prevent unauthorised users from issuing a plain commit that bypasses change control.

Pitfalls

• Confirming too fast, so the safety net never covers the risky window.
• Managing the device through the interface you are changing — if the session drops, the rollback still saves you, but only if the timer was set.
• Forgetting that commit confirmed applies the change: it is not a dry run.
• Using a very long timeout on a change that breaks traffic, turning a five-minute outage into a thirty-minute one.
• Relying on rollback instead of testing: rollback restores configuration, not the operational state of sessions that already dropped.

Comparing commit confirmed with equivalent features elsewhere

The safety-net idea exists on other platforms under different names, and knowing the equivalents helps when a mixed-vendor change window requires the same discipline everywhere.

Junos is unusual in that the rollback is automatic and non-disruptive to the hardware: no reboot, no optics re-initialisation. That makes it the strongest of the mechanisms for remote changes, and the reason the habit is worth building even on platforms where the equivalent is clumsier.

A change-window procedure that uses it properly

1. Prepare and review the configuration change; run commit check in the lab or on a spare device.
2. Take a configuration backup off the device, so you have a recovery point independent of the built-in history.
3. Announce the window, including the automatic rollback time, so colleagues know service should recover by itself if verification fails.
4. Apply with commit confirmed 5 (or a longer interval for multi-team changes).
5. Verify from outside the device: ping the reachable far end, check the adjacency, test the application path.
6. Confirm with commit, then add a comment tying the change to the ticket.
7. If verification fails, do nothing and let the rollback run; send the notification and reschedule.
8. After the window, compare the resulting configuration against the intended state and archive the diff.

Written down, this looks heavy for a one-line change. In practice steps 4 to 6 take a couple of minutes, and the procedure is what turns "we hope the change worked" into "we know it worked, and if it had not, the device would have fixed itself".

Related Junos articles

For the recovery baseline that works when the box is unreachable, see the Junos rescue configuration and recovery guide. A broader command reference sits in Junos troubleshooting commands, and the design-side counterpart for resilient changes is in Juniper MC-LAG best practices.

原文链接：https://juniper.net/documentation/us/en/software/junos/junos-xml-protocol/topics/task/junos-xml-protocol-configuration-committing-with-confirmation.html