CliDeck
PlatformLog in
Workspace

Aruba CX checkpoint auto: A Recovery Window for Remote Configuration Changes

Runbooks
#aruba-cx#configuration-recovery#runbooks#remote-operations#Runbooks#network-operations
← Back to Blog

Short answer

On an Aruba CX 6200 running AOS-CX 10.13, start checkpoint auto before an approved configuration change when you need a timed path back to the starting running configuration. Confirm the checkpoint only after the required checks pass. If the interval expires without confirmation, the switch restores the configuration captured when auto mode began.

Establish the boundary of the change

This guide uses the CX 6200 AOS-CX 10.13 command workflow and Manager-level access. Check the exact software build and available CLI on the device before adapting it to another family. Aruba Instant AP, Instant On, and AOS-Switch are different operating environments.

Auto checkpointing protects a running-configuration experiment. Keep software upgrades, physical recabling, and hardware replacement in their own recovery procedures. Confirming a checkpoint also needs to be distinguished from saving startup configuration for the next boot.

Write down one narrow objective and the baseline to recover. Identify the management path, affected users or endpoints, and the operator who decides whether to accept the result. Avoid a broad cleanup task where nobody can explain what a successful test looks like.

Capture the baseline and arrange independent access

From the Manager prompt, record the installed version, running configuration, and saved checkpoint inventory:

show version
show running-config
show checkpoint

Store configuration captures privately. Label the record with the correct asset and collection time so a later handoff cannot confuse two similar switches.

Have console access available through a path independent of the management interface being changed. Agree on the recovery waiting period and escalation contact. Checkpoint restoration is still a device operation; allow it to finish before treating a temporary loss of access as permanent.

If a separately named baseline is needed, capture one before the experiment:

copy running-config checkpoint PRE_CHANGE
show checkpoint

Use a unique name for the actual task, check that creation succeeded, and handle name collisions deliberately. A named checkpoint is evidence of a baseline, not proof that auto mode has been armed.

Arm auto mode before entering change commands

At the Manager prompt:

checkpoint auto 5

The example reserves five minutes; the supported interval is 1–60 minutes. Select an interval that covers the planned tests. Record the response and the resulting deadline before entering configuration mode and applying the approved edits.

Keep the arming step separate from the confirmation step. Do not place both in a single unattended paste. Doing so removes the opportunity to reject a change after observing its effect.

Auto mode protects the running baseline from the point it starts. Coordinate other writers for the whole window. An unrelated change made by another operator during the experiment can complicate both acceptance and restoration.

Test before confirming

Use a new authenticated connection through the required management path. Check the affected service from a representative endpoint and compare the result with the pre-change criteria. An already open console or SSH window proves less than a successful fresh login.

When every acceptance check passes, confirm from the Manager prompt:

checkpoint auto confirm
show checkpoint

Capture the created AUTO checkpoint and the confirmation response. If persistence across boot is part of the approved change, save separately after successful confirmation:

copy running-config startup-config

Record the save response and review the intended startup state. Do not infer that startup configuration was updated simply because an AUTO checkpoint exists.

Verification note: observe restoration without adding new edits

If the deadline expires, watch the recovery output through the independent access path. When restoration is in progress, stop entering new configuration commands. After it completes, compare management access and affected services with the original baseline.

ResultRequired evidenceNext action
Change acceptedFresh login, service tests, confirmationSave only when authorized
Timer expiredRestoration result and baseline checksReview the failed change
State uncertainTranscript and current configurationEscalate through console

Do not keep extending an experiment that has no clear pass condition. Save the version, starting checkpoint, deadline, approved edits, tests, final state, and any exceptions. CliDeck Workspace supports the session record; the runbook preparation guide helps turn those checkpoints into a repeatable procedure.

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