Chapter 19. Configuring NTP Using ntpd

19.1. Introduction to NTP

The Network Time Protocol (NTP) enables the accurate dissemination of time and date information in order to keep the time clocks on networked computer systems synchronized to a common reference over the network or the Internet. Many standards bodies around the world have atomic clocks which may be made available as a reference. The satellites that make up the Global Position System contain more than one atomic clock, making their time signals potentially very accurate. Their signals can be deliberately degraded for military reasons. An ideal situation would be where each site has a server, with its own reference clock attached, to act as a site-wide time server. Many devices which obtain the time and date via low frequency radio transmissions or the Global Position System (GPS) exist. However for most situations, a range of publicly accessible time servers connected to the Internet at geographically dispersed locations can be used. These NTP servers provide "Coordinated Universal Time" (UTC). Information about these time servers can found at www.pool.ntp.org.

Accurate time keeping is important for a number of reasons in IT. In networking for example, accurate time stamps in packets and logs are required. Logs are used to investigate service and security issues and so time stamps made on different systems must be made by synchronized clocks to be of real value. As systems and networks become increasingly faster, there is a corresponding need for clocks with greater accuracy and resolution. In some countries there are legal obligations to keep accurately synchronized clocks. See www.ntp.org for more information. In Linux systems, NTP is implemented by a daemon running in user space. The default NTP user space daemon in Red Hat Enterprise Linux 7 is chronyd. It must be disabled if you want to use the ntpd daemon. See Chapter 18, Configuring NTP Using the chrony Suite for information on chrony.

The user space daemon updates the system clock, which is a software clock running in the kernel. Linux uses a software clock as its system clock for better resolution than the typical embedded hardware clock referred to as the "Real Time Clock" (RTC). See the rtc(4) and hwclock(8) man pages for information on hardware clocks. The system clock can keep time by using various clock sources. Usually, the Time Stamp Counter (TSC) is used. The TSC is a CPU register which counts the number of cycles since it was last reset. It is very fast, has a high resolution, and there are no interrupts. On system start, the system clock reads the time and date from the RTC. The time kept by the RTC will drift away from actual time by up to 5 minutes per month due to temperature variations. Hence the need for the system clock to be constantly synchronized with external time references. When the system clock is being synchronized by ntpd, the kernel will in turn update the RTC every 11 minutes automatically.

19.2. NTP Strata

NTP servers are classified according to their synchronization distance from the atomic clocks which are the source of the time signals. The servers are thought of as being arranged in layers, or strata, from 1 at the top down to 15. Hence the word stratum is used when referring to a specific layer. Atomic clocks are referred to as Stratum 0 as this is the source, but no Stratum 0 packet is sent on the Internet, all stratum 0 atomic clocks are attached to a server which is referred to as stratum 1. These servers send out packets marked as Stratum 1. A server which is synchronized by means of packets marked stratum n belongs to the next, lower, stratum and will mark its packets as stratum n+1. Servers of the same stratum can exchange packets with each other but are still designated as belonging to just the one stratum, the stratum one below the best reference they are synchronized to. The designation Stratum 16 is used to indicate that the server is not currently synchronized to a reliable time source.

Note that by default NTP clients act as servers for those systems in the stratum below them.

Here is a summary of the NTP Strata:

Stratum 0

Atomic Clocks and their signals broadcast over Radio and GPS

  • GPS (Global Positioning System)
  • Mobile Phone Systems
  • Low Frequency Radio Broadcasts WWVB (Colorado, USA.), JJY-40 and JJY-60 (Japan), DCF77 (Germany), and MSF (United Kingdom)

    These signals can be received by dedicated devices and are usually connected by RS-232 to a system used as an organizational or site-wide time server.

Stratum 1
Computer with radio clock, GPS clock, or atomic clock attached
Stratum 2
Reads from stratum 1; Serves to lower strata
Stratum 3
Reads from stratum 2; Serves to lower strata
Stratum n+1
Reads from stratum n; Serves to lower strata
Stratum 15
Reads from stratum 14; This is the lowest stratum.

This process continues down to Stratum 15 which is the lowest valid stratum. The label Stratum 16 is used to indicated an unsynchronized state.

19.3. Understanding NTP

The version of NTP used by Red Hat Enterprise Linux is as described in RFC 1305 Network Time Protocol (Version 3) Specification, Implementation and Analysis and RFC 5905 Network Time Protocol Version 4: Protocol and Algorithms Specification

This implementation of NTP enables sub-second accuracy to be achieved. Over the Internet, accuracy to 10s of milliseconds is normal. On a Local Area Network (LAN), 1 ms accuracy is possible under ideal conditions. This is because clock drift is now accounted and corrected for, which was not done in earlier, simpler, time protocol systems. A resolution of 233 picoseconds is provided by using 64-bit time stamps. The first 32-bits of the time stamp is used for seconds, the last 32-bits are used for fractions of seconds.

NTP represents the time as a count of the number of seconds since 00:00 (midnight) 1 January, 1900 GMT. As 32-bits is used to count the seconds, this means the time will "roll over" in 2036. However NTP works on the difference between time stamps so this does not present the same level of problem as other implementations of time protocols have done. If a hardware clock that is within 68 years of the correct time is available at boot time then NTP will correctly interpret the current date. The NTP4 specification provides for an "Era Number" and an "Era Offset" which can be used to make software more robust when dealing with time lengths of more than 68 years. Do not confuse this with the Unix Year 2038 problem.

The NTP protocol provides additional information to improve accuracy. Four time stamps are used to allow the calculation of round-trip time and server response time. In order for a system in its role as NTP client to synchronize with a reference time server, a packet is sent with an "originate time stamp". When the packet arrives, the time server adds a "receive time stamp". After processing the request for time and date information and just before returning the packet, it adds a "transmit time stamp". When the returning packet arrives at the NTP client, a "receive time stamp" is generated. The client can now calculate the total round trip time and by subtracting the processing time derive the actual traveling time. By assuming the outgoing and return trips take equal time, the single-trip delay in receiving the NTP data is calculated. The full NTP algorithm is much more complex than presented here.

When a packet containing time information is received it is not immediately responded to, but is first subject to validation checks and then processed together with several other time samples to arrive at an estimate of the time. This is then compared to the system clock to determine the time offset, the difference between the system clock’s time and what ntpd has determined the time should be. The system clock is adjusted slowly, at most at a rate of 0.5 ms per second, to reduce this offset by changing the frequency of the counter being used. It will take at least 2000 seconds to adjust the clock by 1 second using this method. This slow change is referred to as slewing and cannot go backwards. If the time offset of the clock is more than 128 ms (the default setting), ntpd can "step" the clock forwards or backwards. If the time offset at system start is greater than 1000 seconds then the user, or an installation script, should make a manual adjustment. See Chapter 3, Configuring the Date and Time. With the -g option to the ntpd command (used by default), any offset at system start will be corrected, but during normal operation only offsets of up to 1000 seconds will be corrected.

Some software may fail or produce an error if the time is changed backwards. For systems that are sensitive to step changes in the time, the threshold can be changed to 600 s instead of 128 ms using the -x option (unrelated to the -g option). Using the -x option to increase the stepping limit from 0.128 s to 600 s has a drawback because a different method of controlling the clock has to be used. It disables the kernel clock discipline and may have a negative impact on the clock accuracy. The -x option can be added to the /etc/sysconfig/ntpd configuration file.

19.4. Understanding the Drift File

The drift file is used to store the frequency offset between the system clock running at its nominal frequency and the frequency required to remain in synchronization with UTC. If present, the value contained in the drift file is read at system start and used to correct the clock source. Use of the drift file reduces the time required to achieve a stable and accurate time. The value is calculated, and the drift file replaced, once per hour by ntpd. The drift file is replaced, rather than just updated, and for this reason the drift file must be in a directory for which the ntpd has write permissions.

19.5. UTC, Timezones, and DST

As NTP is entirely in UTC (Universal Time, Coordinated), Timezones and DST (Daylight Saving Time) are applied locally by the system. The file /etc/localtime is a copy of, or symlink to, a zone information file from /usr/share/zoneinfo. The RTC may be in localtime or in UTC, as specified by the 3rd line of /etc/adjtime, which will be one of LOCAL or UTC to indicate how the RTC clock has been set. Users can easily change this setting using the checkbox System Clock Uses UTC in the Date and Time graphical configuration tool. See Chapter 3, Configuring the Date and Time for information on how to use that tool. Running the RTC in UTC is recommended to avoid various problems when daylight saving time is changed.

The operation of ntpd is explained in more detail in the man page ntpd(8). The resources section lists useful sources of information. See Section 19.20, “Additional Resources”.

19.6. Authentication Options for NTP

NTPv4 NTPv4 added support for the Autokey Security Architecture, which is based on public asymmetric cryptography while retaining support for symmetric key cryptography. The Autokey protocol is described in RFC 5906 Network Time Protocol Version 4: Autokey Specification. Unfortunately, it was found later that the protocol has serious security issues, and thus Red Hat strongly recommends to use symmetric keys instead. The man page ntp_auth(5) describes the authentication options and commands for ntpd.

An attacker on the network can attempt to disrupt a service by sending NTP packets with incorrect time information. On systems using the public pool of NTP servers, this risk is mitigated by having more than three NTP servers in the list of public NTP servers in /etc/ntp.conf. If only one time source is compromised or spoofed, ntpd will ignore that source. You should conduct a risk assessment and consider the impact of incorrect time on your applications and organization. If you have internal time sources you should consider steps to protect the network over which the NTP packets are distributed. If you conduct a risk assessment and conclude that the risk is acceptable, and the impact to your applications minimal, then you can choose not to use authentication.

The broadcast and multicast modes require authentication by default. If you have decided to trust the network then you can disable authentication by using disable auth directive in the ntp.conf file. Alternatively, authentication needs to be configured by using SHA1 or MD5 symmetric keys, or by public (asymmetric) key cryptography using the Autokey scheme. The Autokey scheme for asymmetric cryptography is explained in the ntp_auth(8) man page and the generation of keys is explained in ntp-keygen(8). To implement symmetric key cryptography, see Section 19.17.12, “Configuring Symmetric Authentication Using a Key” for an explanation of the key option.

19.7. Managing the Time on Virtual Machines

Virtual machines cannot access a real hardware clock and a virtual clock is not stable enough as the stability is dependent on the host systems work load. For this reason, para-virtualized clocks should be provided by the virtualization application in use. On Red Hat Enterprise Linux with KVM the default clock source is kvm-clock. See the KVM guest timing management chapter of the Red Hat Enterprise Linux 7 Virtualization Deployment and Administration Guide.

19.8. Understanding Leap Seconds

Greenwich Mean Time (GMT) was derived by measuring the solar day, which is dependent on the Earth’s rotation. When atomic clocks were first made, the potential for more accurate definitions of time became possible. In 1958, International Atomic Time (TAI) was introduced based on the more accurate and very stable atomic clocks. A more accurate astronomical time, Universal Time 1 (UT1), was also introduced to replace GMT. The atomic clocks are in fact far more stable than the rotation of the Earth and so the two times began to drift apart. For this reason UTC was introduced as a practical measure. It is kept within one second of UT1 but to avoid making many small trivial adjustments it was decided to introduce the concept of a leap second in order to reconcile the difference in a manageable way. The difference between UT1 and UTC is monitored until they drift apart by more than half a second. Then only is it deemed necessary to introduce a one second adjustment, forward or backward. Due to the erratic nature of the Earth’s rotational speed, the need for an adjustment cannot be predicted far into the future. The decision as to when to make an adjustment is made by the International Earth Rotation and Reference Systems Service (IERS). However, these announcements are important only to administrators of Stratum 1 servers because NTP transmits information about pending leap seconds and applies them automatically.

19.9. Understanding the ntpd Configuration File

The daemon, ntpd, reads the configuration file at system start or when the service is restarted. The default location for the file is /etc/ntp.conf and you can view the file by entering the following command:

~]$ less /etc/ntp.conf

The configuration commands are explained briefly later in this chapter, see Section 19.17, “Configure NTP”, and more verbosely in the ntp.conf(5) man page.

Here follows a brief explanation of the contents of the default configuration file:

The driftfile entry

A path to the drift file is specified, the default entry on Red Hat Enterprise Linux is:

driftfile /var/lib/ntp/drift

If you change this be certain that the directory is writable by ntpd. The file contains one value used to adjust the system clock frequency after every system or service start. See Understanding the Drift File for more information.

The access control entries

The following line sets the default access control restriction:

restrict default nomodify notrap nopeer noquery
  • The nomodify options prevents any changes to the configuration.
  • The notrap option prevents ntpdc control message protocol traps.
  • The nopeer option prevents a peer association being formed.
  • The noquery option prevents ntpq and ntpdc queries, but not time queries, from being answered.

    Important

    The ntpq and ntpdc queries can be used in amplification attacks, therefore do not remove the noquery option from the restrict default command on publicly accessible systems.

    See CVE-2013-5211 for more details.

    Addresses within the range 127.0.0.0/8 are sometimes required by various processes or applications. As the "restrict default" line above prevents access to everything not explicitly allowed, access to the standard loopback address for IPv4 and IPv6 is permitted by means of the following lines:

    # the administrative functions.
    restrict 127.0.0.1
    restrict ::1

    Addresses can be added underneath if specifically required by another application.

    Hosts on the local network are not permitted because of the "restrict default" line above. To change this, for example to allow hosts from the 192.0.2.0/24 network to query the time and statistics but nothing more, a line in the following format is required:

    restrict 192.0.2.0 mask 255.255.255.0 nomodify notrap nopeer

    To allow unrestricted access from a specific host, for example 192.0.2.250/32, a line in the following format is required:

    restrict 192.0.2.250

    A mask of 255.255.255.255 is applied if none is specified.

    The restrict commands are explained in the ntp_acc(5) man page.

The public servers entry

By default, the ntp.conf file contains four public server entries:

server 0.rhel.pool.ntp.org iburst
server 1.rhel.pool.ntp.org iburst
server 2.rhel.pool.ntp.org iburst
server 3.rhel.pool.ntp.org iburst
The broadcast multicast servers entry
By default, the ntp.conf file contains some commented out examples. These are largely self explanatory. See Section 19.17, “Configure NTP” for the explanation of the specific commands. If required, add your commands just below the examples.
Note

When the DHCP client program, dhclient, receives a list of NTP servers from the DHCP server, it adds them to ntp.conf and restarts the service. To disable that feature, add PEERNTP=no to /etc/sysconfig/network.

19.10. Understanding the ntpd Sysconfig File

The file will be read by the ntpd init script on service start. The default contents is as follows:

# Command line options for ntpd
OPTIONS="-g"

The -g option enables ntpd to ignore the offset limit of 1000 s and attempt to synchronize the time even if the offset is larger than 1000 s, but only on system start. Without that option ntpd will exit if the time offset is greater than 1000 s. It will also exit after system start if the service is restarted and the offset is greater than 1000 s even with the -g option.

19.11. Disabling chrony

In order to use ntpd the default user space daemon, chronyd, must be stopped and disabled. Issue the following command as root:

~]# systemctl stop chronyd

To prevent it restarting at system start, issue the following command as root:

~]# systemctl disable chronyd

To check the status of chronyd, issue the following command:

~]$ systemctl status chronyd

19.12. Checking if the NTP Daemon is Installed

To check if ntpd is installed, enter the following command as root:

~]# yum install ntp

NTP is implemented by means of the daemon or service ntpd, which is contained within the ntp package.

19.13. Installing the NTP Daemon (ntpd)

To install ntpd, enter the following command as root:

~]# yum install ntp

To enable ntpd at system start, enter the following command as root:

~]# systemctl enable ntpd

19.14. Checking the Status of NTP

To check if ntpd is running and configured to run at system start, issue the following command:

~]$ systemctl status ntpd

To obtain a brief status report from ntpd, issue the following command:

~]$ ntpstat
unsynchronised
 time server re-starting
  polling server every 64 s
~]$ ntpstat
synchronised to NTP server (10.5.26.10) at stratum 2
  time correct to within 52 ms
  polling server every 1024 s

19.15. Configure the Firewall to Allow Incoming NTP Packets

The NTP traffic consists of UDP packets on port 123 and needs to be permitted through network and host-based firewalls in order for NTP to function.

Check if the firewall is configured to allow incoming NTP traffic for clients using the graphical Firewall Configuration tool.

To start the graphical firewall-config tool, press the Super key to enter the Activities Overview, type firewall and then press Enter. The Firewall Configuration window opens. You will be prompted for your user password.

To start the graphical firewall configuration tool using the command line, enter the following command as root user:

~]# firewall-config

The Firewall Configuration window opens. Note, this command can be run as normal user but you will then be prompted for the root password from time to time.

Look for the word "Connected" in the lower left corner. This indicates that the firewall-config tool is connected to the user space daemon, firewalld.

19.15.1. Change the Firewall Settings

To immediately change the current firewall settings, ensure the drop-down selection menu labeled Configuration is set to Runtime. Alternatively, to edit the settings to be applied at the next system start, or firewall reload, select Permanent from the drop-down list.

Note

When making changes to the firewall settings in Runtime mode, your selection takes immediate effect when you set or clear the check box associated with the service. You should keep this in mind when working on a system that may be in use by other users.

When making changes to the firewall settings in Permanent mode, your selection will only take effect when you reload the firewall or the system restarts. To reload the firewall, select the Options menu and select Reload Firewall.

19.15.2. Open Ports in the Firewall for NTP Packets

To permit traffic through the firewall to a certain port, start the firewall-config tool and select the network zone whose settings you want to change. Select the Ports tab and then click the Add button. The Port and Protocol window opens.

Enter the port number 123 and select udp from the drop-down list.

19.16. Configure ntpdate Servers

The purpose of the ntpdate service is to set the clock during system boot. This was used previously to ensure that the services started after ntpdate would have the correct time and not observe a jump in the clock. The use of ntpdate and the list of step-tickers is considered deprecated and so Red Hat Enterprise Linux 7 uses the -g option to the ntpd command and not ntpdate by default.

The ntpdate service in Red Hat Enterprise Linux 7 is beneficial if it is used without the ntpd service or when the -x option is specified for the ntpd command. If ntpd is used with -x but without the ntpdate service enabled, the clock is corrected by step only if the time difference is larger than 600 seconds. With a smaller offset than 600 seconds, the clock is adjusted slowly, approximately 2000 seconds for every corrected second.

To check if the ntpdate service is enabled to run at system start, issue the following command:

~]$ systemctl status ntpdate

To enable the service to run at system start, issue the following command as root:

~]# systemctl enable ntpdate

In Red Hat Enterprise Linux 7 the default /etc/ntp/step-tickers file contains 0.rhel.pool.ntp.org. To configure additional ntpdate servers, using a text editor running as root, edit /etc/ntp/step-tickers. The number of servers listed is not very important as ntpdate will only use this to obtain the date information once when the system is starting. If you have an internal time server then use that host name for the first line. An additional host on the second line as a backup is sensible. The selection of backup servers and whether the second host is internal or external depends on your risk assessment. For example, what is the chance of any problem affecting the first server also affecting the second server? Would connectivity to an external server be more likely to be available than connectivity to internal servers in the event of a network failure disrupting access to the first server?

19.17. Configure NTP

To change the default configuration of the NTP service, use a text editor running as root user to edit the /etc/ntp.conf file. This file is installed together with ntpd and is configured to use time servers from the Red Hat pool by default. The man page ntp.conf(5) describes the command options that can be used in the configuration file apart from the access and rate limiting commands which are explained in the ntp_acc(5) man page.

19.17.1. Configure Access Control to an NTP Service

To restrict or control access to the NTP service running on a system, make use of the restrict command in the ntp.conf file. See the commented out example:

# Hosts on local network are less restricted.
#restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

The restrict command takes the following form:

restrict option

where option is one or more of:

  • ignore — All packets will be ignored, including ntpq and ntpdc queries.
  • kod — a "Kiss-o'-death" packet is to be sent to reduce unwanted queries.
  • limited — do not respond to time service requests if the packet violates the rate limit default values or those specified by the discard command. ntpq and ntpdc queries are not affected. For more information on the discard command and the default values, see Section 19.17.2, “Configure Rate Limiting Access to an NTP Service”.
  • lowpriotrap — traps set by matching hosts to be low priority.
  • nomodify — prevents any changes to the configuration.
  • noquery — prevents ntpq and ntpdc queries, but not time queries, from being answered.
  • nopeer — prevents a peer association being formed.
  • noserve — deny all packets except ntpq and ntpdc queries.
  • notrap — prevents ntpdc control message protocol traps.
  • notrust — deny packets that are not cryptographically authenticated.
  • ntpport — modify the match algorithm to only apply the restriction if the source port is the standard NTP UDP port 123.
  • version — deny packets that do not match the current NTP version.

To configure rate limit access to not respond at all to a query, the respective restrict command has to have the limited option. If ntpd should reply with a KoD packet, the restrict command needs to have both limited and kod options.

The ntpq and ntpdc queries can be used in amplification attacks (see CVE-2013-5211 for more details), do not remove the noquery option from the restrict default command on publicly accessible systems.

19.17.2. Configure Rate Limiting Access to an NTP Service

To enable rate limiting access to the NTP service running on a system, add the limited option to the restrict command as explained in Section 19.17.1, “Configure Access Control to an NTP Service”. If you do not want to use the default discard parameters, then also use the discard command as explained here.

The discard command takes the following form:

discard average value minimum value monitor value
  • average — specifies the minimum average packet spacing to be permitted, it accepts an argument in log2 seconds. The default value is 3 (23 equates to 8 seconds).
  • minimum — specifies the minimum packet spacing to be permitted, it accepts an argument in log2 seconds. The default value is 1 (21 equates to 2 seconds).
  • monitor — specifies the discard probability for packets once the permitted rate limits have been exceeded. The default value is 3000 seconds. This option is intended for servers that receive 1000 or more requests per second.

Examples of the discard command are as follows:

discard average 4
discard average 4 minimum 2

19.17.3. Adding a Peer Address

To add the address of a peer, that is to say, the address of a server running an NTP service of the same stratum, make use of the peer command in the ntp.conf file.

The peer command takes the following form:

peer address

where address is an IP unicast address or a DNS resolvable name. The address must only be that of a system known to be a member of the same stratum. Peers should have at least one time source that is different to each other. Peers are normally systems under the same administrative control.

19.17.4. Adding a Server Address

To add the address of a server, that is to say, the address of a server running an NTP service of a higher stratum, make use of the server command in the ntp.conf file.

The server command takes the following form:

server address

where address is an IP unicast address or a DNS resolvable name. The address of a remote reference server or local reference clock from which packets are to be received.

19.17.5. Adding a Broadcast or Multicast Server Address

To add a broadcast or multicast address for sending, that is to say, the address to broadcast or multicast NTP packets to, make use of the broadcast command in the ntp.conf file.

The broadcast and multicast modes require authentication by default. See Section 19.6, “Authentication Options for NTP”.

The broadcast command takes the following form:

broadcast address

where address is an IP broadcast or multicast address to which packets are sent.

This command configures a system to act as an NTP broadcast server. The address used must be a broadcast or a multicast address. Broadcast address implies the IPv4 address 255.255.255.255. By default, routers do not pass broadcast messages. The multicast address can be an IPv4 Class D address, or an IPv6 address. The IANA has assigned IPv4 multicast address 224.0.1.1 and IPv6 address FF05::101 (site local) to NTP. Administratively scoped IPv4 multicast addresses can also be used, as described in RFC 2365 Administratively Scoped IP Multicast.

19.17.6. Adding a Manycast Client Address

To add a manycast client address, that is to say, to configure a multicast address to be used for NTP server discovery, make use of the manycastclient command in the ntp.conf file.

The manycastclient command takes the following form:

manycastclient address

where address is an IP multicast address from which packets are to be received. The client will send a request to the address and select the best servers from the responses and ignore other servers. NTP communication then uses unicast associations, as if the discovered NTP servers were listed in ntp.conf.

This command configures a system to act as an NTP client. Systems can be both client and server at the same time.

19.17.7. Adding a Broadcast Client Address

To add a broadcast client address, that is to say, to configure a broadcast address to be monitored for broadcast NTP packets, make use of the broadcastclient command in the ntp.conf file.

The broadcastclient command takes the following form:

broadcastclient

Enables the receiving of broadcast messages. Requires authentication by default. See Section 19.6, “Authentication Options for NTP”.

This command configures a system to act as an NTP client. Systems can be both client and server at the same time.

19.17.8. Adding a Manycast Server Address

To add a manycast server address, that is to say, to configure an address to allow the clients to discover the server by multicasting NTP packets, make use of the manycastserver command in the ntp.conf file.

The manycastserver command takes the following form:

manycastserver address

Enables the sending of multicast messages. Where address is the address to multicast to. This should be used together with authentication to prevent service disruption.

This command configures a system to act as an NTP server. Systems can be both client and server at the same time.

19.17.9. Adding a Multicast Client Address

To add a multicast client address, that is to say, to configure a multicast address to be monitored for multicast NTP packets, make use of the multicastclient command in the ntp.conf file.

The multicastclient command takes the following form:

multicastclient address

Enables the receiving of multicast messages. Where address is the address to subscribe to. This should be used together with authentication to prevent service disruption.

This command configures a system to act as an NTP client. Systems can be both client and server at the same time.

19.17.10. Configuring the Burst Option

Using the burst option against a public server is considered abuse. Do not use this option with public NTP servers. Use it only for applications within your own organization.

To increase the average quality of time offset statistics, add the following option to the end of a server command:

burst

At every poll interval, when the server responds, the system will send a burst of up to eight packets instead of the usual one packet. For use with the server command to improve the average quality of the time-offset calculations.

19.17.11. Configuring the iburst Option

To improve the time taken for initial synchronization, add the following option to the end of a server command:

iburst

When the server is unreachable, send a burst of eight packets instead of the usual one packet. The packet spacing is normally 2 s; however, the spacing between the first and second packets can be changed with the calldelay command to allow additional time for a modem or ISDN call to complete. For use with the server command to reduce the time taken for initial synchronization. This is now a default option in the configuration file.

19.17.12. Configuring Symmetric Authentication Using a Key

To configure symmetric authentication using a key, add the following option to the end of a server or peer command:

key number

where number is in the range 1 to 65534 inclusive. This option enables the use of a message authentication code (MAC) in packets. This option is for use with the peer, server, broadcast, and manycastclient commands.

The option can be used in the /etc/ntp.conf file as follows:

server 192.168.1.1 key 10
broadcast 192.168.1.255 key 20
manycastclient 239.255.254.254 key 30

See also Section 19.6, “Authentication Options for NTP”.

19.17.13. Configuring the Poll Interval

To change the default poll interval, add the following options to the end of a server or peer command:

minpoll value and maxpoll value

Options to change the default poll interval, where the interval in seconds will be calculated by raising 2 to the power of value, in other words, the interval is expressed in log2 seconds. The default minpoll value is 6, 26 equates to 64 s. The default value for maxpoll is 10, which equates to 1024 s. Allowed values are in the range 3 to 17 inclusive, which equates to 8 s to 36.4 h respectively. These options are for use with the peer or server. Setting a shorter maxpoll may improve clock accuracy.

19.17.14. Configuring Server Preference

To specify that a particular server should be preferred above others of similar statistical quality, add the following option to the end of a server or peer command:

prefer

Use this server for synchronization in preference to other servers of similar statistical quality. This option is for use with the peer or server commands.

19.17.15. Configuring the Time-to-Live for NTP Packets

To specify that a particular time-to-live (TTL) value should be used in place of the default, add the following option to the end of a server or peer command:

ttl value

Specify the time-to-live value to be used in packets sent by broadcast servers and multicast NTP servers. Specify the maximum time-to-live value to use for the "expanding ring search" by a manycast client. The default value is 127.

19.17.16. Configuring the NTP Version to Use

To specify that a particular version of NTP should be used in place of the default, add the following option to the end of a server or peer command:

version value

Specify the version of NTP set in created NTP packets. The value can be in the range 1 to 4. The default is 4.

19.18. Configuring the Hardware Clock Update

The system clock can be used to update the hardware clock, also known as the real-time clock (RTC). This section shows three approaches to the task:

Instant one-time update

To perform an instant one-time update of the hardware clock, run this command as root:

~]# hwclock --systohc
Update on every boot

To make the hardware clock update on every boot after executing the ntpdate synchronization utility, do the following:

  1. Add the following line to the /etc/sysconfig/ntpdate file:

    SYNC_HWCLOCK=yes
  2. Enable the ntpdate service as root:

    ~]# systemctl enable ntpdate.service

    Note that the ntpdate service uses the NTP servers defined in the /etc/ntp/step-tickers file.

    Note

    On virtual machines, the hardware clock will be updated on the next boot of the host machine, not of the virtual machine.

Update via NTP

You can make the hardware clock update every time the system clock is updated by the ntpd or chronyd service:

Start the ntpd service as root:

~]# systemctl start ntpd.service

To make the behavior persistent across boots, make the service start automatically at the boot time:

~]# systemctl enable ntpd.service

or

Start the chronyd service as root:

~]# systemctl start chronyd.service

To make the behavior persistent across boots, make the service start automatically at the boot time:

~]# systemctl enable chronyd.service

As a result, every time the system clock is synchronized by ntpd or chronyd, the kernel automatically updates the hardware clock in 11 minutes.

Warning

This approach might not always work because the above mentioned 11-minute mode is not always enabled. As a consequence, the hardware clock does not necessarily get updated on the system clock update.

To check the synchronization of the software clock with the hardware clock, use the ntpdc -c kerninfo or the ntptime command as root:

~]# ntpdc -c kerninfo

The result may look like this:

pll offset:      0 s
pll frequency:    0.000 ppm
maximum error:    8.0185 s
estimated error:   0 s
status: 2001 pll nano
pll time constant:  6
precision:      1e-09 s
frequency tolerance: 500 ppm

or

~]# ntptime

The result may look like this:

ntp_gettime() returns code 0 (OK)
 time dcba5798.c3dfe2e0 Mon, May 8 2017 11:34:00.765, (.765135199),
 maximum error 8010000 us, estimated error 0 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
 modes 0x0 (),
 offset 0.000 us, frequency 0.000 ppm, interval 1 s,
 maximum error 8010000 us, estimated error 0 us,
status 0x2001 (PLL,NANO),
 time constant 6, precision 0.001 us, tolerance 500 ppm,

To recognize whether the hardware clock is synchronized to the system clock, see the status line in the output. If the line contains the word unsync or UNSYNC, the hardware clock is not synchronized to the system clock.

The hardware clock is synchronized to the system clock.

status 0x2001 (PLL,NANO)

The hardware clock is not synchronized to the system clock.

status 0x41 (PLL,UNSYNC)

19.19. Configuring Clock Sources

To list the available clock sources on your system, issue the following commands:

~]$ cd /sys/devices/system/clocksource/clocksource0/
clocksource0]$ cat available_clocksource
kvm-clock tsc hpet acpi_pm
clocksource0]$ cat current_clocksource
kvm-clock

In the above example, the kernel is using kvm-clock. This was selected at boot time as this is a virtual machine. Note that the available clock source is architecture dependent.

To override the default clock source, append the clocksource directive to the end of the kernel’s GRUB 2 menu entry. Use the grubby tool to make the change. For example, to force the default kernel on a system to use the tsc clock source, enter a command as follows:

~]# grubby --args=clocksource=tsc --update-kernel=DEFAULT

The --update-kernel parameter also accepts the keyword ALL, or a comma separated list of kernel index numbers.

See Chapter 26, Working with GRUB 2 for more information on making changes to the GRUB 2 menu.

19.20. Additional Resources

The following sources of information provide additional resources regarding NTP and ntpd.

19.20.1. Installed Documentation

  • ntpd(8) man page — Describes ntpd in detail, including the command-line options.
  • ntp.conf(5) man page — Contains information on how to configure associations with servers and peers.
  • ntpq(8) man page — Describes the NTP query utility for monitoring and querying an NTP server.
  • ntpdc(8) man page — Describes the ntpd utility for querying and changing the state of ntpd.
  • ntp_auth(5) man page — Describes authentication options, commands, and key management for ntpd.
  • ntp_keygen(8) man page — Describes generating public and private keys for ntpd.
  • ntp_acc(5) man page — Describes access control options using the restrict command.
  • ntp_mon(5) man page — Describes monitoring options for the gathering of statistics.
  • ntp_clock(5) man page — Describes commands for configuring reference clocks.
  • ntp_misc(5) man page — Describes miscellaneous options.
  • ntp_decode(5) man page — Lists the status words, event messages and error codes used for ntpd reporting and monitoring.
  • ntpstat(8) man page — Describes a utility for reporting the synchronization state of the NTP daemon running on the local machine.
  • ntptime(8) man page — Describes a utility for reading and setting kernel time variables.
  • tickadj(8) man page — Describes a utility for reading, and optionally setting, the length of the tick.

19.20.2. Useful Websites

http://doc.ntp.org/
The NTP Documentation Archive
http://www.eecis.udel.edu/~mills/ntp.html
Network Time Synchronization Research Project.
http://www.eecis.udel.edu/~mills/ntp/html/manyopt.html
Information on Automatic Server Discovery in NTPv4.