Junos commit and rollback: the feature worth envying

The difference between Junos and most other platforms is not syntax. It is that configuration is a transaction. Understanding that changes how you work, and it is the feature most engineers miss after using it.

Candidate and active

Editing changes a candidate configuration. The device continues running the active one. Nothing you type takes effect until you commit, so you can restructure something extensively, review the whole change as a unit, and apply it atomically.

show | compare          # exactly what will change
commit check            # will it even parse and validate?
commit confirmed 5      # apply, but revert unless confirmed
commit                  # confirm it

commit confirmed

This is the one to internalise. It applies the change and starts a timer. If you do not issue a second commit within that window, the device reverts. If your change cuts your own access, the device fixes it for you.

Anyone who has locked themselves out of a remote firewall understands immediately why this matters. It converts the highest-risk category of remote work into something routine.

Rollback history

Junos keeps previous configurations numbered. Rolling back is one command, and you can see what changed between any two versions:

run show system commit
show | compare rollback 1
rollback 1
commit

This is a genuine audit trail on the device itself, independent of whatever configuration management you run.

Approximating it elsewhere

On IOS, reload in 10 before a risky change gives you the same safety net crudely: if you lose access, the device reboots into the saved configuration. Save only after you have confirmed the change works. On RouterOS, safe mode does the same thing more elegantly.

The principle transfers even where the feature does not: decide how the change undoes itself before you make it.