Junos commit confirmed: A Remote Change Runbook That Keeps Rollback Available

← Back to Blog

Short answer

Use commit confirmed to activate an approved Junos configuration change with a rollback deadline. Test the new management path and the affected service before confirming it. If confirmation never arrives, Junos restores the previous configuration. The useful control is the decision point between applying a change and accepting it, so keep confirmation out of the initial command paste.

When this applies

This runbook is for authorized changes on Junos OS devices that support confirmed commits. Record the device model, exact release, routing-engine arrangement, and configuration mode before adapting it. Check feature support and commit policy on that exact device before the maintenance window.

Confirm the syntax on the installed release. Junos OS 24.2R1 introduced mandatory commit comments; local commit policy may require comments on other releases too. Examples below include a short synthetic change reference and do not contain customer identifiers.

Define success before starting the timer

Write down the management address, access method, expected route, and one test of the service being changed. A VLAN modification needs an endpoint test; a management-access change needs a fresh authenticated connection. An existing terminal can stay alive while new logins fail.

Arrange a console or another independent recovery path. Confirm that the colleague watching it knows the deadline and the decision owner. Choose a timer long enough for the real checks, including authentication delays. Five minutes below is an example, not a universal maintenance-window budget.

Start with device identity and commit history in operational mode:

show version
show system commit

Open configuration mode, make only the approved edits, and inspect the candidate diff:

configure
show | compare
commit check

Stop on an unexpected diff or validation error. Shared candidate edits need explicit coordination; a timer cannot determine which operator intended a change.

Apply, inspect, then make the confirmation decision

From configuration mode, activate the reviewed candidate:

commit confirmed 5 comment "CHG-EXAMPLE controlled test"
run show system commit

Record the pending rollback and deadline shown by the device. Do not assume the timer started merely because a script sent the command. Keep the transcript open while a separate operator or connection performs the planned tests.

When all acceptance checks pass, confirm from configuration mode:

commit comment "CHG-EXAMPLE checks passed"
run show system commit

Confirm that the pending rollback is gone and the intended configuration remains active. Store the confirmation time with the change record.

Verification note: commit check can also confirm

On Junos, commit check can confirm an outstanding confirmed commit. A habitual validation command issued after activation can therefore remove the rollback protection before the service tests are complete. Run the preflight syntax check before commit confirmed; during the test window use operational inspection commands and keep other commit activity coordinated.

CheckAccept the changeKeep recovery active
Fresh loginNew authenticated connection succeedsOnly the old terminal works
Affected servicePredefined endpoint test passesReachability or behavior differs
Candidate reviewDiff matches the approved taskUnrelated edits are present
Timer statePending rollback visible until decisionState or deadline is uncertain

If the checks fail

Do not confirm a failed change just to clear the warning. Follow the agreed recovery plan and observe whether the timed rollback restores the baseline. If access does not return after the expected recovery interval, use the independent console path and collect the actual commit history before attempting another change. A configuration rollback does not repair a power failure, disconnected cable, or unrelated upstream outage.

Save identity, release, reviewed diff, activation time, test results, rollback or confirmation result, and unresolved exceptions. CliDeck Workspace can hold the session context and handoff notes alongside the maintenance-window checklist. Keep configuration evidence private and sanitize any excerpts shared outside the team.

Who this is for

This guide is for operations teams, incident responders, network engineers, and system administrators who need to prepare, run, verify, and document operational terminal work on approved network devices inside a planned change or lab scope.

When to use this

Use this guide when:

  • Several commands or checks must be repeated safely.
  • Another engineer, customer, onsite technician, or vendor may need context.
  • The work should produce notes, logs, verification, or a clear handoff.

When not to use this

Do not use this guide when:

  • You do not own or have authorization to work on the device.
  • The device is outside your approved change, recovery, or processing scope.
  • The task may expose customer data, secrets, licenses, or credentials that you are not allowed to view or store.
  • The work requires vendor-specific approval, legal approval, or a customer-specific procedure that is not covered here.

Practical runbook format

A runbook does not need to be a complex script. For many operations, it can be a plain command list with notes, expected output, stop conditions, verification steps, and rollback instructions.

What to include

  • Purpose
  • When to use it
  • When not to use it
  • Target system or device
  • Access path
  • Read-only checks
  • Change steps
  • Expected output
  • Stop conditions
  • Rollback steps
  • Verification steps
  • Handoff notes
  • Final summary format

Workflow

  • Define the purpose, target device, access path, and approved scope.
  • Run read-only checks first and record the expected healthy state.
  • Execute commands from the runbook or handoff plan while watching for stop conditions.
  • Verify the final state with independent checks.
  • Summarize commands run, outputs reviewed, exceptions, and handoff notes.

Verification checklist

  • The target device or system is correct.
  • Read-only checks were captured before the work.
  • Stop conditions and rollback notes were available before changes.
  • Final verification checks match the expected result.
  • Notes, logs, and handoff summary are stored where the team can find them.

Common mistakes

  • Starting commands before confirming the target device and scope.
  • Skipping read-only baseline checks.
  • Copying commands without expected output, stop conditions, or rollback notes.
  • Closing the work without a final verification summary.

CliDeck workflow fit

CliDeck Workspace is designed for this kind of operational workflow. Teams can keep terminals, notes, runbooks, logs, and shared sessions in one browser workspace instead of spreading work across terminal windows, chat messages, screenshots, and separate documents.

CliDeck runbooks can be plain command lists, one command per line. Operators can send commands with one click or use auto-run behavior that waits for the prompt before sending the next line where configured.

FAQ

Does a runbook need to be code?

No. A useful runbook can be a plain list of commands, checks, notes, expected output, stop conditions, and verification steps.

Why use a browser workspace for terminal work?

A browser workspace can keep terminals, notes, runbooks, logs, and shared sessions together, which helps during incidents, handoffs, maintenance windows, and remote support.

Can shared terminal sessions be safer than screen sharing?

Yes, when implemented with clear view/type permissions. The helper can see the relevant terminal context without taking over the operator’s entire desktop.

Can CliDeck help with this workflow?

Yes. CliDeck Workspace helps organize terminals, runbooks, notes, logs, and shared sessions. Console Server Go is useful when the workflow starts at a rack-side console port.

Related guides