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

Network Time Protocol (NTP) is used to synchronize the time between the Packet Forwarding Engine and the Routing Engine in a standalone device and between two devices in a chassis cluster. For more information, see the following topics:

NTP Time Synchronization on SRX Series Devices

In both standalone and chassis cluster modes, the primary Routing Engine runs the NTP process to get the time from the external NTP server. Although the secondary Routing Engine runs the NTP process in an attempt to get the time from the external NTP server, this attempt fails because of network issues. For this reason, the secondary Routing Engine uses NTP to get the time from the primary Routing Engine.

Use NTP to:

  • Send the time from the primary Routing Engine to the secondary Routing Engine through the chassis cluster control link.

  • Get the time from an external NTP server to the primary or a standalone Routing Engine.

  • Get the time from the Routing Engine NTP process to the Packet Forwarding Engine.

Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, configuring the NTP time adjustment threshold is supported on SRX300, SRX320, SRX340, SRX345, SRX1500, SRX1600, SRX2300, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and vSRX Virtual Firewall instances. This feature allows you to configure and enforce the NTP adjustment threshold for the NTP service and helps in improve the security and flexibility of the NTP service protocol.

See Also

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

This example shows how to simplify management by synchronizing the time between two SRX Series Firewalls operating in a chassis cluster. Using a Network Time Protocol (NTP) server, the primary node can synchronize time with the secondary node. NTP is used to synchronize the time between the Packet Forwarding Engine and the Routing Engine in a standalone device and between two devices in a chassis cluster. You need to synchronize the system clocks on both nodes of the SRX Series Firewalls in a chassis cluster in order to 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:

  • SRX Series Firewalls operating in a chassis cluster

  • Junos OS Release 12.1X47-D10 or later

Before you begin:

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

Overview

When SRX Series Firewalls are operating in chassis cluster mode, the secondary node cannot access the external NTP server through the revenue port. Junos OS Release 12.1X47 or later supports synchronization of secondary node time with the primary node through 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 LinkSynchronizing Time From Peer Node Through Control Link

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.

Synchronizing 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.

Verifying 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.

Verifying the 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

Release History Table
Release
Description
15.1X49-D70
Starting with Junos OS Release 15.1X49-D70 and Junos OS Release 17.3R1, configuring the NTP time adjustment threshold is supported on SRX300, SRX320, SRX340, SRX345, SRX1500, SRX1600, SRX2300, SRX4100, SRX4200, SRX5400, SRX5600, and SRX5800 devices and vSRX Virtual Firewall instances. This feature allows you to configure and enforce the NTP adjustment threshold for the NTP service and helps in improve the security and flexibility of the NTP service protocol.