pjhtech Tools
Juniper · Junos OS

Junos Logs, NTP and System Health Commands

Quick answer #

Start an incident capture with the current time, software version, alarms and the relevant log. Then check NTP state before comparing timestamps with another device. Two accurate-looking log lines can describe different moments if their clocks or time zones disagree.

Scope: Junos OS operational CLI on supported MX/EX/SRX. Log filenames depend on configuration and hardware alarm fields differ. Junos OS Evolved has platform-specific differences and is not covered by this baseline.

Commands #

Read-only operational commands:

Commands
Junos OS · Operational CLI

Read-only
show version
Read-only
show system uptime
Read-only
show system alarms
Read-only
show chassis alarms
Read-only
show ntp associations no-resolve
Read-only
show ntp status
Read-only
show log
Output may contain sensitive operational data.
Read-only
show log messages | last 100
Output may contain sensitive operational data.
Read-only
show log messages | match "RPD_BGP|OSPF|SNMP_TRAP_LINK"
Output may contain sensitive operational data.

messages is a common filename, not a mandatory universal log. Use show log to discover the files actually present. Match expressions are examples; the relevant process names and event text depend on the incident and logging configuration.

Read NTP state #

In the association output, * marks the selected synchronization peer and + marks a candidate in the final selection set. A configured server is not automatically the selected server. Read reachability, recent reception and offset together instead of treating the mere presence of an address as success.

The reach value is an octal register, not a percentage. A zero after startup has a different context from a server that remains unreachable throughout an incident. Offset is reported in milliseconds in this command. Compare repeated observations before concluding that a transient value is a persistent clock problem.

Separate alarms from history #

System alarms describe active software-related conditions; chassis alarms concern the device and its components. Neither is a complete historical log. An interface incident can be absent from the current alarm list after it recovers, while its event remains in a configured log.

Workflow #

Record the hostname, software release, current device time and your collection time. Note the timezone used by your ticket or monitoring platform. Save alarms and a bounded log window, then correlate the specific protocol or interface event with the user's symptom. Collect the peer's evidence using the same reference time.

If the clock is wrong, document the offset before correction so earlier evidence remains interpretable. This page intentionally does not provide an emergency clock-change command: scheduled tasks, authentication and change history deserve consideration before a large time step.

Pitfalls #

A filtered log can hide the lines that explain an event, so retain surrounding context. Absence of a message does not prove absence of a fault when the required severity or facility was never logged. Avoid posting full configurations or logs publicly without removing credentials and customer identifiers.

Continue with #

Junos Interface Errors and Optical Power Commands adds interface evidence, Junos BGP Troubleshooting: Neighbors and Advertised Routes adds BGP state, and Junos Compare, Commit Confirmed and Rollback Reference explains commit history. The Common TCP / UDP Ports Reference helps identify protocol ports when correlating a network capture with monitoring data. A port number alone does not establish which application generated the traffic.

Sources

Documentation reviewed: 8 October 2026