CliDeck
PlatformLog in
Workspace

Arista EOS Configuration Sessions: Review, Timed Commit, and Confirmation

Runbooks
#arista-eos#configuration-recovery#runbooks#remote-operations#Runbooks#network-operations
← Back to Blog

Short answer

Use a named EOS configuration session to stage an approved change, inspect its diff, and apply it with commit timer when a rollback deadline is required. Confirm that same session only after management and service checks pass. Treat saving startup configuration as a separate decision, and coordinate other configuration writers throughout the transaction.

Scope and release checks

This is an authorized EOS configuration-change runbook. The command pattern uses named sessions and the hh:mm:ss timer format described in the EOS 4.36.2F command set. Older images can differ in session limits, merge behavior, status output, and persistence settings; inspect the installed release and available commands rather than assuming identical defaults.

This workflow is for controlled configuration edits. It does not recover an unbootable image, reset an appliance for resale, or guarantee that a physically disconnected management link can be recovered remotely.

Prepare the session and the recovery owner

Give the task a unique synthetic session name, such as CHG_EXAMPLE. Check current sessions before creating another. Do not reuse a colleague's pending session merely because it already exists.

From privileged EXEC mode:

show version
show configuration sessions detail
configure session CHG_EXAMPLE

Make only the reviewed edits within the session. At the session configuration prompt, inspect the proposed content:

show session-config
show session-config diff

Check the installed CLI help for the diff option before using it; status and inspection output vary by release. Separate these inspection commands from the actual change lines in the runbook. A pasted example should never contain an unreviewed interface shutdown, route removal, or authentication modification simply to demonstrate the timer.

Resolve concurrent edits before committing

A session is based on a configuration snapshot. With replacement-style session commits, changes made to running configuration by another writer after the snapshot can be overwritten. Arrange one coordinated change window and inspect the diff immediately before applying it.

Identify automation systems and other administrators that can write configuration. If a controller will immediately push a different desired state, reconcile that ownership first. A rollback timer cannot make two competing configuration owners agree.

Do not enable new merge or auto-save settings as an improvised fix during the window. Those options alter the operating assumptions and need separate review.

Apply with a deadline, then verify independently

From the named session's configuration mode:

commit timer 00:05:00

The example interval is five minutes. Choose a duration that covers the actual acceptance tests and communication delays. Record the activation response and inspect session status from privileged EXEC mode:

show configuration sessions detail

Verify that the intended session has a pending timed commit and a remaining interval where the release displays it. If the expected status is absent, inspect the error before proceeding.

Open a fresh authenticated connection through the required management path. Test the affected endpoint or forwarding behavior, not just a ping to a convenient interface. The operator owning confirmation should have the actual test results and enough time to act.

After all checks pass, confirm the original named session from privileged EXEC mode:

configure session CHG_EXAMPLE commit
show configuration sessions detail

Check that the timed-pending state has ended and the intended running settings remain active. A second terminal entering a differently named session does not identify the transaction that needs confirmation.

Verification note: pending, confirmed, and persistent are separate states

StageEvidence to captureStop condition
StagedCorrect session and reviewed diffUnexpected concurrent changes
Timed applicationPending commit and deadlineUnknown session or timer state
ConfirmationFresh login and affected service testsOnly the original terminal works
PersistenceApproved startup save resultAuto-save behavior is unresolved

If checks fail, do not confirm merely to clear the countdown. Observe the rollback through the independent console path and verify the prior baseline before rescheduling the change. Preserve error messages and avoid issuing further edits while recovery is underway.

Inspect the site's persistence policy and any configured auto-save behavior. Where a manual save is required, perform the approved save only after successful confirmation. Do not report reboot persistence from a running-config check alone.

Attach the session name, release, diff, deadline, acceptance results, rollback or confirmation outcome, and save decision to the task. CliDeck Workspace can keep that context together for a clear command handoff.

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