Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Simplifying Management by Synchronizing Network Time Protocol for Your Backup Routing Engine

Requirements

• SRX Series devices 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 devices are operating in chassis cluster mode, the backup Routing Engine cannot access the external NTP server through the revenue port. The following two examples synchronize the time from the peer Routing Engine or from the NTP server, both using the management port:

• Synchronizing Time from the Peer Routing Engine with the Management Port (fxp0)
• Synchronizing Time from the NTP Server with the Management Port (fxp0)

Topology

Figure 1 shows the time synchronization from the peer Routing Engine using the management port, fxp0.

Figure 1: Synchronizing Time from the Peer Routing Engine Using fxp0

With this configuration, both Routing Engines in a chassis cluster will have two NTP servers (one Routing Engine points to the external server, and the other Routing Engine points to the peer Routing Engine fxp0 address). In the primary Routing Engine, both NTP servers are reachable, and the NTP process selects the best server for synchronizing time. The secondary Routing Engine can reach only one NTP server (pointing to the peer fxp0 address), so this server is used for synchronizing time.

Figure 2 shows the time synchronization from the NTP server using the management port, fxp0.

Figure 2: Synchronizing Time from the NTP Server Using fxp0

In this configuration, the NTP server address is 10.208.0.50, which is reachable through the management port. The management ports of both Routing Engines in chassis cluster mode are enabled. In this configuration, both Routing Engines can access the NTP server to synchronize time.

Configuration

• Synchronizing Time from the Peer Routing Engine Using the Management Port (fxp0)
• Synchronizing Time from the NTP Server Using the Management Port (fxp0)
• Results

CLI Quick Configuration

To quickly configure this example, and synchronize the time from the peer Routing Engine using the management port, 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.

Note: 10.208.131.32 is the fxp0 IP address of node 0, and 10.208.131.31 is the fxp0 IP address of node 1.

To quickly configure this example, and synchronize the time from the NTP server using the management port, copy the following command, paste it 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 Peer Routing Engine Using the Management Port (fxp0)

Step-by-Step Procedure

1. Configure the NTP server.
   {primary:node0}[edit][edit system]user@host#set ntp server 1.1.1.121
2. Configure the NTP server address for node 0.
   {primary:node0}[edit][edit groups]user@host#set node0 system ntp server 10.208.131.32
3. Configure the NTP server address for node 1.
   {primary:node0}[edit][edit groups]user@host#set node1 system ntp server 10.208.131.31
4. Commit the configuration.
   user@host#commit

Synchronizing Time from the NTP Server Using the Management Port (fxp0)

Step-by-Step Procedure

1. Configure the NTP server address.
   {primary:node0}[edit][edit system]user@host#set ntp server 10.208.0.50
2. Commit the configuration.
   user@host#commit

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.

For brevity, this show command output includes only the configuration that is relevant to this example. Any other configuration on the system has been replaced with ellipses (...).

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
• Verifying the NTP Configuration on the Secondary Node

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:

 remote      refid      st t   when  poll  reach    delay    offset   jitter
==============================================================================
*1-1-1-121-dynami 10.208.0.50      4 -   63   64   65    4.909  -12.067   2.014
+10.208.131.32   129.96.0.1       6 -    1   64  377    0.251   -1.828   2.021

From operational mode, enter the show ntp status command:

status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
version="ntpd 4.2.0-a Fri Mar 21 00:50:30 PDT 2014 (1)",
processor="i386", system="JUNOS12.1I20140320_srx_12q1_x47.1-637245",
leap=00, stratum=5, precision=-20, rootdelay=209.819,
rootdispersion=513.087, peer=14596, refid=1.1.1.121,
reftime=d6dbb2f9.b3f41ff7  Tue, Mar 25 2014 15:47:05.702, poll=6,
clock=d6dbb47a.72918b20  Tue, Mar 25 2014 15:53:30.447, state=4,
offset=-6.066, frequency=-55.135, jitter=4.343, stability=0.042

Meaning

The output on the primary 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 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:

remote     refid    st  t     when  poll  reach  delay    offset   jitter
==============================================================================
 1-1-1-121-dynami .INIT.          16 -    - 1024    0    0.000    0.000  4000.00
+10.208.131.31   1.1.1.121         5 -   14   64  377    0.244   -0.929   1.510
*129.96.0.1      1.1.1.121         5 u   32   64  377    0.417    0.760   1.204

From operational mode, enter the show ntp status command:

status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
version="ntpd 4.2.0-a Thu Mar 13 01:53:03 PDT 2014 (1)",
processor="i386", system="JUNOS12.1I20140312_srx_12q1_x47.2-635305",
leap=00, stratum=12, precision=-20, rootdelay=2.408,
rootdispersion=892.758, peer=51948, refid=1.1.1.121,
reftime=d6d646bb.853d2f42  Fri, Mar 21 2014 13:03:55.520, poll=6,
clock=d6d647bc.e8f28b2f  Fri, Mar 21 2014 13:08:12.909, state=4,
offset=-1.126, frequency=-62.564, jitter=0.617, stability=0.002

Meaning

The output on the 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 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.