Junos commit confirmed: A Safe Change-Window Procedure

Junos keeps a candidate configuration separate from the active one, and commit confirmed applies the candidate immediately while arming a timer that rolls the device back unless you confirm. The command is well known; the failure mode is that engineers confirm within seconds, which means the safety net never covered the window in which the change could actually have hurt them. This article is the procedure rather than the syntax: what to verify, from where, and how the same guarantee is enforced when the change comes from an automation pipeline.

What a commit actually does

Nothing typed in configuration mode affects the network until commit. On commit, Junos validates syntax, validates logical consistency (a policy referencing a nonexistent prefix list fails here, not at packet time), then applies the configuration atomically. If any validation step fails the entire commit is rejected and the active configuration is untouched — you never end up with three of five changes live.

lab@sw-01# configure
lab@sw-01# set interfaces ge-0/0/3 unit 0 family inet address 10.10.10.1/30
lab@sw-01# commit check
lab@sw-01# commit confirmed 5
commit confirmed will be rolled back in 5 minutes
commit complete

commit check stages validation without applying — useful hours before a window. commit confirmed 5 applies the change and starts a five-minute countdown; omit the number and the default is 10 minutes. The config is live the moment the command returns: this is not a dry run.

The gap between the two commits is the whole point

A confirming commit must be issued before the timer expires. The safety net only earns its keep if step 2 below actually happens between the two:

1. Apply the change with commit confirmed 5.
2. Verify from outside the device, over the path you just changed: ping the far end, check the routing adjacency, run a traceroute, test the application.
3. If verification passes, return and run a plain commit to make it permanent.
4. If it fails, either do nothing and let the timer restore service, or rollback 1 and commit deliberately.

Timer sizing that works in practice: 5 minutes for a routed change you can verify quickly, 10-15 for firewall or policy changes, longer only when you must coordinate verification with a remote team. A very long timeout on a change that breaks traffic turns a five-minute outage into a thirty-minute one.

Re-arming, rollback history and comments

lab@sw-01# commit confirmed 10
lab@sw-01# rollback 1
lab@sw-01# show | compare
lab@sw-01# commit comment "CHG12345 uplink renumber"
lab@sw-01> show system rollback ?

• Re-issuing commit confirmed before the deadline resets the timer — useful when observation needs to continue — but remember it also restarts the clock, so an explicit commit is still required.
• Junos retains up to 50 rollback configurations: rollback 0 is the currently active configuration, rollback 1 the previous commit, and so on. rollback 1 loads a configuration into the candidate; nothing changes until you commit, which is your chance to inspect the diff.
• Devices with heavy commit activity cycle through 50 rollbacks quickly — on a busy platform that history can span days, not months. Use an external backup tool (Oxidized or equivalent) for a real audit trail.
• Always attach a change reference with commit comment; a rollback file with no ticket number is of limited value at 03:00.

Pairing it with the other Junos safety mechanisms

• Rescue configuration: a known-good baseline you can activate from the loader prompt when nothing else is reachable.
• commit at and commit synchronize: schedule a commit for a specific time, and apply it consistently on both Routing Engines.
• Configuration archival: push a copy of every commit to a remote server so a recovery point exists off-box.
• Login class restrictions: stop users who can bypass change control from issuing a plain commit that defeats the confirmation window.

The automation equivalent: NETCONF confirmed commit

The same semantics are available over NETCONF as a confirmed-commit capability (RFC 6241), which is what makes automated Junos changes survivable when a pipeline session drops mid-change:

from ncclient import manager
with manager.connect(host="10.10.10.1", port=830,
                     username="automation", hostkey_verify=False) as m:
    m.lock(target="candidate")
    m.edit_config(target="candidate", config=config_xml)
    m.commit(confirmed=True, timeout="300")   # 5-minute rollback window
    # verify externally, then confirm
    m.commit()
    m.unlock(target="candidate")

If the pipeline dies before the confirming commit, the device rolls back on its own. That property is worth more than any amount of pipeline-level error handling: it means a broken automation run degrades into its previous state rather than into an outage.

Pitfalls

• Confirming too fast, so the risky window is never covered.
• Managing the device through the interface you are changing; the rollback saves you only if the timer was set.
• Believing commit confirmed is a preview — it is applied traffic-immediately.
• Assuming rollback restores sessions: it restores configuration, not traffic that already dropped.

For revision history and rollback identifiers see Junos rollback configuration and revision identifiers; for a compare-and-rollback view on a platform without an automatic timer, see IOS XR configuration management, commit and rollback.

原文链接：https://infrarunbook.com/article/junos-commit-and-rollback-explained