CliDeck
PlatformLog in
Workspace

Arista EOS NTP Checks: Status and Associations

Runbooks
#eos-ntp#operational-evidence#runbooks#remote-operations#Runbooks
← Back to Blog

Short answer

Check both show ntp status and show ntp associations in EOS EXEC mode. The first describes the switch's reported synchronization state; the second shows its connections to time servers. Preserve both outputs together. Reported synchronization does not independently prove absolute clock accuracy or the authenticity of every timestamp in a transcript.

Scope and prerequisites

This workflow follows Arista's EOS 4.36.2F command documentation. Verify support on the installed release and device model. Earlier Knowledge guidance covers older EOS documentation, so the current official reference supplies the command and output details here.

Use an authorized session and the approved time-service inventory. This procedure does not configure NTP servers, keys, routing, ACLs or the local clock. Changing time services during evidence collection would create a different task with separate impact and verification requirements.

1. Capture synchronization status

At the EXEC prompt, run:

show ntp status

Record the capture time and the device's actual release. Preserve whether EOS reports synchronization, the reported system peer, stratum and any precision or polling information. If the output reports unsynchronized status, carry that condition into the incident timeline instead of quietly normalizing timestamps.

Version matters when interpreting the peer field. Before EOS 4.23.2, an IPv6 system peer could be represented by a reference ID derived from its address. Later releases display the system peer's IP address. Do not search an inventory for an older reference ID as though it were necessarily the peer's address.

2. Capture the association table

Run immediately afterward:

show ntp associations

Keep every row and the original headings. The table includes the remote endpoint, reference ID, stratum, transmission type, time since reception, polling, reach, delay, offset and jitter. The reference ID describes the configured server's time source; it is not always the same identifier as the remote endpoint.

Arista describes reach as an octal representation of the last eight messages, with 377 indicating receipt of all eight. This is bounded history, not a lifetime availability measure. Preserve its printed form instead of converting it to a decimal percentage.

Do not compare delay, offset or jitter from different captures without retaining their context. One small value can be a temporary observation. A table row being present does not by itself establish that the switch is synchronized to that row.

3. Reconcile the two views

Compare the system peer reported by status with the association evidence and your approved server inventory. If the identifiers differ in presentation, investigate naming, address family and release behavior before declaring a mismatch.

Avoid treating stratum as a certificate of quality. A source can be close to a reference clock in the protocol hierarchy while still failing an operational requirement. Whether the selected service meets your timing requirement belongs to the time-service design and its monitoring.

If status and associations appear inconsistent, preserve both outputs and take another bounded capture after an agreed interval. Record an unresolved result rather than choosing whichever output looks healthier. Do not restart the NTP service to manufacture a clean baseline.

4. Keep timeline claims bounded

Attach the observed synchronization state to the period of the capture. Do not backdate a later synchronized result onto earlier incident events. A clock step, restart or source change can break assumptions about ordering across systems.

For timestamp interpretation, see UTC without false precision. For evidence collection, organize the read-only checks in the CliDeck workspace and keep time-service changes outside this capture procedure.

Verification note: acceptance criteria

For the actual switch and EOS release, verify that both commands complete, their outputs and capture context are retained, the reported system peer is reconciled with the approved inventory and uncertainty is explicit. Unsynchronized status, an unidentified peer or inconsistent repeated captures remain exceptions requiring investigation. These are verification criteria, not a claim of tested hardware or measured clock accuracy.

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 SSH, serial, browser terminal, and infrastructure operations workflows.

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