CliDeck
PlatformLog in
Workspace

Junos NTP Checks: Peers, Reach and Synchronization State

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

Short answer

Capture both the Junos NTP peer table and the system status before using device timestamps to correlate an incident. Keep the selected peer, reach register and synchronization state separate. A reachable server is not necessarily the selected source, and a selected source does not certify the accuracy of every historical log timestamp.

This read-only workflow produces a timing-context handoff before maintenance or recovery. It does not change the clock or NTP configuration.

Scope and prerequisites

Use an authorized Junos OS operational session with view permission. The command references cover Junos NTP behavior across releases; confirm your exact hardware, installed release and supported output fields. The guidance is not a hardware validation for every device running 23.4, and it is not an EOS or IOS command sequence.

Prepare the device identity, installed release, expected time sources and collection time with timezone. Open a CliDeck workspace capture and keep the original output. If a ticket compares events across several devices, give each capture its own identity and timestamp rather than assuming their clocks agree.

Step 1: collect the peer table

show ntp associations no-resolve

The no-resolve option suppresses symbolic addressing. Preserve the peer markers, headings and complete rows. Juniper defines the asterisk as a selected synchronization peer; candidate and discarded peers have different markers. Record the actual marker instead of treating every listed server as an active source.

The reach field is an octal reachability register, not a percentage. Keep it exactly as displayed with that meaning. Preserve when and poll alongside it, and retain the units on timing measurements. Peer delay and offset are documented in milliseconds.

For the ticket, use separate entries for the selected peer observation, the reach value and any unexpected candidate or discarded rows. If there is no selected marker, record that fact and continue with system status rather than choosing the most familiar server name yourself.

Step 2: collect system synchronization status

show ntp status no-resolve

Keep the status words and the complete variable output. Juniper documents sync_ntp as an NTP synchronization source and sync_alarm or sync_unspec as unsynchronized indications. Preserve the reported state even if the peer table contains apparently reachable servers.

Retain refid, reftime, stratum and offset when present. Do not assign values to missing fields or silently replace the status with your expected configuration. The status reference documents rootdelay and rootdispersion in seconds, while offset is in milliseconds; a worksheet must retain those field-specific units.

These queries run sequentially. If the selected peer changes between them, retain both outputs and their order. Take another timestamped pair if the owner needs a current comparison; do not merge different snapshots into a single apparently consistent state.

Step 3: decide what the evidence supports

Compare the observed source and state with the owner's intended timing design. An unexpected source, an unsynchronized state or conflicting outputs should become a named follow-up item. Request the release-specific NTP investigation from the platform owner instead of changing servers, authentication or clock settings during collection.

A currently synchronized indication supports a statement about this observation. It does not establish the device's clock state at the time of an older event. If an incident record depends on historical ordering, preserve that uncertainty and seek timing evidence from the relevant period.

Do not infer service health from an NTP result. A clock check and a forwarding or application check have different acceptance criteria. Similarly, a stratum value alone should not become an accuracy guarantee for a maintenance report.

Step 4: attach timing context to the handoff

Include the queried device, capture timestamps and timezone, exact commands, selected-peer observation, raw reach value, system state, measurements with units and unresolved differences. Keep server addresses private where they identify customer infrastructure.

The Junos uptime context guide provides a separate view of boot and protocol timing. Use both records when useful, while keeping uptime, clock synchronization and event timestamps distinct. If a later approved change occurs, collect a fresh baseline and retain the earlier evidence.

Verification note: acceptance criteria

The reviewer should be able to identify the selected peer or its absence, interpret reach as octal, locate the system synchronization state and trace every extracted value to its original field and units. Missing or conflicting evidence should remain explicit, with a responsible owner.

Any claim about historical timestamp accuracy needs additional evidence for that period. These are operator acceptance criteria derived from documentation; no physical device test, observed production synchronization or historical clock accuracy is claimed here.

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