Synchronizing Time Periodically

Problem

You want to periodically resynchronize the time on the router to limit the effects of clock drift.

Solution

Configure the router to periodically get time updates from an NTP server:

	[edit system]
	aviva@router1#  
set ntp server 192.168.27.46
	aviva@router1# show
	system {
	 ntp {
	 server 192.168.27.46;
	 }
	}

 

Discussion

Setting the router's time by configuring a boot server provides a one-time method for the router to get time when it boots. However, once a router is up and stable, you will almost never have to reboot it, so if its time starts to drift from the time on your other network devices, you have to go into the router and manually reconfigure the time. To automatically keep the router in sync with the rest of the network, you can have it periodically get time updates from an NTP server. To do this, place the JUNOS NTP software into NTP server mode with the set ntp server command, specifying the IP address of the NTP server. The NTP server will then periodically send the correct time to the router, which then adjusts its system clock.

From a network-wide perspective, you generally want to have a local NTP server that is your main time server and that stays synchronized with a stratum 1 clock. You then have a number of redundant NTP peers that keep their time synchronized with this local NTP server. The remainder of the local routers on your network poll the NTP peers to get accurate time. The local routers that receive time from an NTP peer run in what is called NTP server mode. This terminology is a bit confusing, because the local router is passively accepting time from the remote NTP server. The term server mode applies to the NTP protocol software, which is running in server mode, not to the router, which is actually running as an NTP client. When the NTP software is in server mode, the clock on the router can be synchronized to a remote NTP server, but a remote server can never be synchronized to the local clock. Thus the time sharing is an asymmetric relationship; server mode is also called asymmetric mode.

For the routers on your network that are the NTP time servers, you configure them to run in NTP peer mode so that they actively keep their clocks synchronized. Peer mode is also called active symmetric mode, because the local and remote routers are willing to synchronize time with each other. If there is any time drift, the NTP synchronization process slowly corrects the routers' clocks so that they match up. To configure a router to run NTP peer mode, specify the address of the NTP peer:

	[edit system]
	aviva@router1# set ntp peer 192.168.1.16

If your network has multiple NTP peers, include additional addresses. You need to configure all the peer routers to operate in NTP peer mode.

In larger networks, you might have multiple NTP servers for redundancy to ensure that time in properly synchronized across the network even when a server or a part of the network goes down. To set up a backup NTP server for a router operating in NTP server mode, configure the address of the second server. To bias the selection toward a particular server, mark it as preferred:

	[edit system]
	aviva@router1# set ntp server 192.168.27.46 prefer
	aviva@router1# set ntp server 172.10.23.196

If you have multiple NTP servers, configure them in the same way:

	[edit system]
	aviva@router1# set ntp peer 192.168.1.16 prefer
	aviva@router1# set ntp peer 172.10.23.196

When you configure multiple servers and peers, an NTP relationship is established with all of them. The candidates are sorted by NTP stratum (the smallest stratum is always selected). If multiple candidates are at the smallest stratum, NTP chooses based on perceived accuracy, round-trip time, and jitter. The prefer keyword weights the selection, but does not guarantee that the said system will be selected. It is even possible for multiple systems to be selected and an integration of their times to be performed.

You can also have all the routers synchronize time (chime) with each other. This is only practical for relatively small networks of, say, less than 50 routers. (For larger networks, you may want to have all the routers in a region or POP chime with each other.) You still want to have some stratum 1 clocks someplace in the mix. This arrangement allows the entire network to keep reasonable time even if some or all of the stratum 1 clocks go down for a while.

Note that you can configure both server and peer statements on the same router.

NTP automatic time synchronization works only if the times on the two systems are very close. Very close means between 128 milliseconds and 128 seconds apart. Time differences less than 128 milliseconds are dealt with by slowly slewing the time (speeding up or slowing down the clock), which means that the time is always monotonically increasing. Between 128 milliseconds and 128 seconds, the time is stepped, which means that it may go backward. Above this, the time is not changed at all. If the time is more than 1,000 seconds off, NTP records a system log message:

	Mar 16 16:41:41 5htp-fxp0 xntpd[28243]: time error 4217 over 1000 seconds; set
	clock manually

If the time is this far off, you need to reset the clock manually:

	aviva@router1# set date ntp

This command uses the NTP servers that you have configured. You do not have to reboot the router for the new time to take effect.

On an operational note, one system will not synchronize to another that is not itself synchronized. Because the synchronization process is recursive, there must be an authoritative time source as the stratum 1 clock or all systems will be free running. An NTP purist will ensure that there are at least three or, better yet, four, independent sources of time available (traceable to three different stratum 1 servers) because this allows " false tickers" to be detected and discarded. At least two independent sources are needed for robustness, because if that one stratum 1 server goes down, the entire synchronization tree will basically come apart and all systems will free run in the mean time. Normally this isn't too serious, but if the stratum 1 server never comes back, there will be no time synchronization whatsoever.