Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

NTP Time Synchronization on Chassis Cluster

This toipic explains how a Network Time Protocol (NTP) is used to synchronize time between the Routing Engine and the Packet Forwarding Engine on a standalone device, as well as between devices in a chassis cluster.

Use Feature Explorer to confirm platform and release support for specific features.

NTP Time Synchronization on Firewalls

In both standalone and chassis cluster modes, the primary Routing Engine runs the NTP process to obtain time from an external NTP server. Although the secondary Routing Engine also runs the NTP process, it cannot directly synchronize with the external NTP server due to network constraints. Instead, the secondary Routing Engine synchronizes its time with the primary Routing Engine using NTP.

NTP is used to:

  • Synchronize time from the primary Routing Engine to the secondary Routing Engine over the chassis cluster control link.

  • Obtain time from an external NTP server for the primary Routing Engine or a standalone Routing Engine.

  • Synchronize time from the Routing Engine's NTP process to the Packet Forwarding Engine.

Configure NTP time settings to define and enforce the NTP adjustment threshold, improving the security and flexibility of the NTP service.

See Also

Example: Simplify Network Management by Synchronizing the Primary and Backup Nodes with NTP

This example shows how to simplify management by synchronizing time between two Firewalls operating in a chassis cluster. Using a Network Time Protocol (NTP) server, the primary node's synchronizes time with the secondary node. NTP is also used to synchronize time between the Routing Engine and the Packet Forwarding Engine on a standalone device and between nodes in a chassis cluster. Synchronizing system clocks on both nodes of the chassis cluster is required to effectively manage the following items:

  • Real-time objects (RTO)

  • Licenses

  • Software updates

  • Node failovers

  • Analyzing system logs (syslogs)

Requirements

This example uses the following hardware and software components:

  • Firewalls operating in a chassis cluster

  • Junos OS Release 18.1R1 or later

Before you begin:

  • Understand the basics of the Network Time Protocol. See NTP Overview.

Overview

When Firewalls operate in chassis cluster mode, the secondary node cannot access an external NTP server through the revenue port. Junos OS supports synchronizing the secondary node's time with the primary node over the control link by configuring the NTP server on the primary node.

Topology

Figure 1 shows the time synchronization from the peer node using the control link.

Figure 1: Synchronizing Time From Peer Node Through Control Link Network topology diagram with Node 0 and Node 1 connected to NTP server 1.1.1.121. Primary node 10.208.131.31 and secondary node 10.208.131.32 linked for control and management purposes.

In the primary node, the NTP server is reachable. The NTP process on the primary node can synchronize the time from the NTP server, and the secondary node can synchronize the time with the primary node from the control link.

Configuration

CLI Quick Configuration

To quickly configure this example, and synchronize the time from the NTP server, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.

Synchronize Time from the NTP server

Step-by-Step Procedure

In this example, you configure the primary node to get its time from an NTP server at IP address 1.1.1.121. To synchronize the time from the NTP server:

  1. Configure the NTP server.

  2. Commit the configuration.

Results

From configuration mode, confirm your configuration by entering the show system ntp command. If the output does not display the intended configuration, repeat the configuration instructions in this example to correct it.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verify the NTP Configuration on the Primary Node

Purpose

Verify that the configuration is working properly.

Action

From operational mode, enter the show ntp associations command:

From operational mode, enter the show ntp status command:

Meaning

The output on the primary and secondary node shows the NTP association as follows:

  • remote—Address or name of the remote NTP peer.

  • refid—Reference identifier of the remote peer. If the reference identifier is not known, this field shows a value of 0.0.0.0.

  • st—Stratum of the remote peer.

  • t—Type of peer: b (broadcast), l (local), m (multicast), or u (unicast).

  • when—When the last packet from the peer was received.

  • poll—Polling interval, in seconds.

  • reach—Reachability register, in octal.

  • delay—Current estimated delay of the peer, in milliseconds.

  • offset—Current estimated offset of the peer, in milliseconds.

  • jitter—Magnitude of jitter, in milliseconds.

The output on the primary and secondary node shows the NTP status as follows:

  • status—System status word, a code representing the status items listed.

  • x events—Number of events that have occurred since the last code change. An event is often the receipt of an NTP polling message.

  • version—A detailed description of the version of NTP being used.

  • processor—Current hardware platform and version of the processor.

  • system—Detailed description of the name and version of the operating system in use.

  • leap—Number of leap seconds in use.

  • stratum—Stratum of the peer server. Anything greater than 1 is a secondary reference source, and the number roughly represents the number of hops away from the stratum 1 server. Stratum 1 is a primary reference, such as an atomic clock.

  • precision—Precision of the peer clock, how precisely the frequency and time can be maintained with this particular timekeeping system.

  • rootdelay—Total roundtrip delay to the primary reference source, in seconds.

  • rootdispersion—Maximum error relative to the primary reference source, in seconds.

  • peer—Identification number of the peer in use.

  • refid—Reference identifier of the remote peer. If the reference identifier is not known, this field shows a value of 0.0.0.0.

  • reftime—Local time, in timestamp format, when the local clock was last updated. If the local clock has never been synchronized, the value is zero.

  • poll—NTP broadcast message polling interval, in seconds.

  • clock—Current time on the local router clock.

  • state—Current mode of NTP operation, where 1 is symmetric active, 2 is symmetric passive, 3 is client, 4 is server, and 5 is broadcast.

  • offset—Current estimated offset of the peer, in milliseconds. Indicates the time difference between the reference clock and the local clock.

  • frequency—Frequency of the clock.

  • jitter—Magnitude of jitter, in milliseconds.

  • stability—Measurement of how well this clock can maintain a constant frequency.

Verify NTP Configuration on the Secondary Node

Purpose

Verify that the configuration is working properly.

Action

From operational mode, enter the show ntp associations command:

From operational mode, enter the show ntp status command:

Related Documentation