Network Time Protocol

The Network Time Protocol (NTP) service on TNSR synchronizes the host clock with reference sources, typically remote servers. It also acts as an NTP server for clients.

See also

To set the local time zone, see Basic System Information.

NTP Configuration Examples

NTP Client Example

Configure the NTP Service as a client from configuration mode (Configuration Mode). This example uses 2.pool.ntp.org in pool mode so that multiple DNS results are used as reference servers and so that the NTP daemon will attempt to contact both IPv4 and IPv6 servers.

tnsr(config)# ntp server
tnsr(config-ntp)# driftfile /var/lib/chrony/chrony.drift
tnsr(config-ntp)# maxupdateskew 100.00
tnsr(config-ntp)# enable monitor
tnsr(config-ntp)# enable rtcsync
tnsr(config-ntp)# enable leapsectz
tnsr(config-ntp)# logdir /var/log/chrony
tnsr(config-ntp)# server 2.pool.ntp.org
tnsr(config-ntp-server)# iburst
tnsr(config-ntp-server)# operational-mode pool
tnsr(config-ntp-server)# maxsources 4
tnsr(config-ntp-server)# exit
tnsr(config-ntp)# maxchange offset 1000.00 start 1 ignore 2
tnsr(config-ntp)# makestep threshold 1.00 limit 3
tnsr(config-ntp)# exit
tnsr(config)# ntp enable
tnsr(config)#

Note

When acting as a client, the NTP daemon may run in either the host or dataplane namespace. The choice is decided by the location of the NTP servers and how the NTP daemon must route to reach those servers.

NTP Server Example

To act as an NTP server, start with the client example above (NTP Client Example) and then configure the additional parts from this section.

First, to serve clients connected to TNSR interfaces, the NTP instance must run in the dataplane namespace:

tnsr(config)# ntp namespace dataplane
tnsr(config)# ntp server
tnsr(config-ntp)#

Now add access rules to allow peers from local subnets:

tnsr(config-ntp)# access sequence 10 allow 10.2.0.0/24

Repeat the access directive for each local subnet for which the NTP daemon will act as a time server. When finished, exit out of config-ntp mode.

NTP Best Practices

Use a minimum of three servers, either as three separate server entries or a pool containing three or more servers. This is to ensure that if the clock on any one server becomes skewed, the remaining two sources can be used to determine that the skewed server is no longer viable. Otherwise, NTP would have to guess which one is accurate and which is skewed.

There are numerous public NTP servers available under pool.ntp.org. The pool.ntp.org DNS entry will return a number of randomized servers in each DNS query response. These can be used individually or as pools. The easiest way is to use the pool operational mode, which uses all returned servers as if they were specified individually.

When using entries as individual server entries, these responses can be subdivided into mutually exclusive pools of peers to avoid overlap. For example, if a configuration specifies pool.ntp.org multiple times for server entries, the same IP address could accidentally be selected twice. In this case, use 0.pool.ntp.org, 1.pool.ntp.org, 2.pool.ntp.org, and 3.pool.ntp.org. When queried in this way, the responses will be unique for each number.

Note

At this time only the 2.pool.ntp.org pool returns IPv6 servers. If TNSR has IPv6 connectivity, use that pool even if only using a single server definition.

Furthermore, there are also pools available for regional and other divisions. For example, to only receive responses for servers in the United States, use us.pool.ntp.org as a pool or <n>.us.pool.ntp.org as servers. For more information, see https://www.ntppool.org/en/