Junos Commit Confirmed and Rollback: Safe Configuration

Junos separates candidate configuration from active configuration, and that model gives network engineers something Cisco IOS cannot: every committed configuration is kept as a rollback file, and a change that breaks remote access can undo itself automatically. The two tools that make this safe — commit confirmed for automatic rollback and the 49-slot rollback system — belong in every Junos engineer's change procedure. This guide explains both with real examples, then chains them into one repeatable workflow that survives a bad filter on the management interface, a dropped SSH session, or a mistyped interface name.

Why Junos Configuration Management Is Different

Editing Junos happens in a candidate configuration: changes are staged with set or edit commands and only take effect when you run commit. Nothing you type is live until that moment, which is exactly why a Junos change can be diffed and reversed before a single packet is affected. On commit, Junos stores the previous configuration as a rollback file — juniper.conf.1.gz becomes juniper.conf.2.gz and so on, up to a maximum of 49 rollback configurations. That archive is the safety net for every change below.

The archive lives in /config on the routing engine, next to the currently committed juniper.conf.gz, so you can inspect it from the Junos shell as well as from configuration mode:

user@router> file list /config | match juniper.conf
user@router> file show /config/juniper.conf.2.gz | match "host-name"

Three properties of this model matter operationally. First, rollback replaces configuration, not forwarding state — it does not clear ARP entries, MAC tables or interface counters. Second, on a dual routing-engine chassis each RE keeps its own archive, and commit synchronize copies the resulting configuration to both. Third, the archive is finite: a maintenance window with dozens of commits pushes older revisions out of the 49 slots, so a rollback number you noted on Monday may point at a different change by Friday.

Commit Check Before You Commit

Validate syntax and semantics without applying anything:

user@router# commit check
configuration check succeeds

If the check fails, Junos reports the exact statement and line, and nothing changes. This catches typos, missing statements and semantic errors before they touch the live network. Pair it with a diff against the committed configuration to see precisely what the candidate would do:

user@router# show | compare
[edit interfaces ge-0/0/3 unit 0 family inet]
+      address 10.0.0.1/24;

show | compare prints the difference between the candidate and the running configuration, marking added lines with + and removed ones with -. On a device several engineers share, always run it before commit: the diff shows somebody else's half-finished change too, not just yours.

Commit Confirmed: Automatic Rollback

For risky remote changes — a firewall filter on a management interface, a routing policy on the uplink — use commit confirmed. If you do not issue a confirming commit before the timer expires, Junos automatically rolls back to the previous configuration:

user@router# set interfaces ge-0/0/3 unit 0 family inet address 10.0.0.1/24
user@router# commit confirmed 5
commit confirmed will be rolled back in 5 minutes
user@router# commit

The default confirmation window is 10 minutes; the example above uses 5, and any value from 1 to 65,535 minutes is accepted. As long as you still have access after the change takes effect, run a plain commit to confirm it permanently. If the change locks you out, the router rolls itself back when the timer expires — your management session returns and the change is gone. A worked walkthrough of letting the timer expire is published by the Network Curiosity blog on Junos commit confirmed.

Four behaviours are worth memorising, because they change how you plan a window:

• The timer is absolute. A confirmed commit armed for 5 minutes rolls back five minutes later whether or not you are still logged in; logging out does not cancel it.
• Confirming is an ordinary commit. Any later commit from any session confirms the pending change, and a second commit confirmed simply replaces the timer.
• Everything committed inside the window reverts. If a colleague commits an unrelated change while your confirmed commit is pending, that change rolls back too when the timer fires. On shared devices, tell the team before arming one.
• The pending confirmation survives a reboot. Junos remembers it across a restart, so a maintenance reload during the window still ends in a rollback rather than a surprise.

To commit and leave configuration mode in one step while the timer keeps running, use commit confirmed and-quit 10.

Manual Rollback and Comparison

When a change survives but should not have, roll back manually. Find what changed first, then revert:

user@router> show configuration | compare rollback 1
user@router# rollback 1
user@router# commit
user@router> show system rollback ?

compare rollback 1 shows the diff between the candidate and the previous configuration; rollback 1 loads that configuration as the new candidate; a final commit applies it. The rollback file numbering means rollback 0 refers to the current committed configuration — useful for discarding uncommitted edits. Inside configuration mode, rollback ? lists every available revision with its timestamp so you can pick the right one instead of counting backwards:

user@router# rollback ?
Possible completions:
  <[Enter]>
  0   2026-08-14 09:12:44 UTC
  1   2026-08-14 08:55:03 UTC
  2   2026-08-14 08:41:19 UTC

To see who committed what and when, read the commit history instead of guessing from timestamps:

user@router> show system commit
0   2026-08-14 09:12:44 UTC by admin via cli
1   2026-08-14 08:55:03 UTC by admin via cli
    fix uplink MTU mismatch

The trailing line is a commit comment — free text you attach with commit comment "fix uplink MTU mismatch". Comments turn an anonymous list of timestamps into a readable change log, which is what you will actually need at 3 a.m. Cisco IOS XR has a parallel commit/rollback model; see our IOS XR commit and rollback guide for the comparison. Junos configuration groups can shrink these changes further — our apply-groups guide shows how.

Rescue Configuration and Scheduled Commits

Two more tools round out the change process. A rescue configuration is a known-good snapshot that stays put no matter how many times you commit, because it has its own single slot outside the 49-file ring:

user@router> request system configuration rescue save
user@router> show system configuration rescue
user@router# rollback rescue
user@router# commit check
user@router# commit

Save the rescue file immediately after every approved change window so it tracks the steady state; a nightly scheduled save works well too. commit at "23:30" schedules a commit for a specific time, which suits changes that should take effect after the last user leaves but still need a human watching the window. load override terminal replaces the entire candidate with a pasted configuration in one shot — always follow it with commit check, because an override that omits an important statement will happily delete it from the device.

Putting It Together: a Safe Change Procedure

Chained together, the tools above give one workflow that works the same way on an EX switch, a QFX leaf or an MX edge router:

user@router> configure
user@router# load merge terminal        # or set / edit commands
user@router# show | compare
user@router# commit check
user@router# commit comment "CR-4821 uplink MTU fix"
user@router# commit confirmed 10
# ... verify from a second session, then confirm ...
user@router# commit
user@router> show system commit

On a virtual chassis or dual-RE platform, use commit synchronize for the final step so both members converge; it accepts the same confirmed and comment keywords. Write the rollback number into the change ticket as part of the plan, not as an afterthought — the fastest recovery in Junos is rollback N followed by commit, and it is only fast if you already know which number you want.

Real Change Windows: Three Worked Scenarios

The same three commands cover most real-world risk. A management-interface change on a remote branch router is the classic commit confirmed case: arm 10 minutes, keep a second SSH session open, and confirm only after the new session actually establishes. A routing-policy change on an uplink is better handled with show | compare plus commit check first, then a confirming commit — the risk there is a policy that silently blackholes traffic rather than cutting your session, so the confirmation test is a ping or a route lookup, not just reachability. Replacing a virtual chassis member is the one case where commit synchronize confirmed 10 really pays for itself: both members converge together, and if the new member fails to join, the old configuration is still there after ten minutes.

Verifying That a Rollback Actually Happened

Automatic rollback is quiet by design — the device simply returns to the previous configuration — so confirm it instead of assuming. The commit history shows the rollback as a commit, and the message log records the event:

user@router> show system commit
user@router> show log messages | match -i rollback
user@router> show configuration | compare rollback 1

If show system commit shows an entry newer than the change you armed, somebody else's commit confirmed the pending one — check the timestamp before re-applying anything. A rollback that did not happen matters just as much: if the timer was supposed to expire and the new configuration is still in place, the pending commit was confirmed somewhere, and another engineer may already be building on top of it.

Junos Compared with IOS-Style Change Safety

The practical difference is where the safety net lives. On a Junos device the candidate, the diff, the automatic rollback and the 49-slot archive are all part of the base operating system, available on every platform from an EX2200 to an MX960 without extra licensing. On IOS and IOS XE the equivalents are assembled from separate features — configure replace with a revert timer, an archive path for configuration history, and reload in for a scheduled restart. The Junos commit model simply makes the safe path the default one.

Common Mistakes

• Committing without commit check on a production device, then reading the error from the failed-commit banner after the change has half applied.
• Arming commit confirmed and walking away, assuming the change is now permanent. It is not until the confirming commit is issued.
• Reading rollback 1 as "undo my last change" — it means "restore the previous committed configuration", which may include another engineer's change.
• Forgetting that on a virtual chassis the shared configuration rolls back as a unit, not per member.
• Treating the 49-slot archive as an audit trail. Use show system commit plus commit comments for that purpose.

Operational Checklist

• Always commit check before a confirming commit on production.
• Use commit confirmed for any change that could cut your management path.
• Document which rollback number corresponds to which change window.
• Keep the 49-file archive in mind: heavy commit traffic eventually pushes old rollbacks out.
• Hold a second session, a console lead, or an out-of-band path open while a confirmed commit is pending.
• Re-save the rescue configuration after each successful window and reference the commit comment in the ticket.

Once rollback is routine, tighten the change itself: template shared settings with configuration groups, verify the result with Junos traceoptions logs, and compare the mechanism with NX-OS checkpoints and rollback. For the operational side of the same discipline, see our Juniper interface troubleshooting checklist.

原文链接：https://www.juniper.net/documentation/us/en/software/junos/cli/topics/topic-map/junos-configuration-commit.html