Red Hat Training

A Red Hat training course is available for RHEL 8

Chapter 32. Achieving some settings previously supported by NTP in chrony

Some settings that were in previous major version of Red Hat Enterprise Linux supported by ntp, are not supported by chrony. The following sections list such settings, and describe ways to achieve them on a system with chrony.

32.1. Monitoring by ntpq and ntpdc

chronyd cannot be monitored by the ntpq and ntpdc utilities from the ntp distribution, because chrony does not support the NTP modes 6 and 7. It supports a different protocol and chronyc is the client implementation. For more information, see the chronyc(1) man page.

To monitor the status of the system clock sychronized by chronyd, you can:

  • Use the tracking command
  • Use the ntpstat utility, which supports chrony and provides a similar output as it used to with ntpd

Example 32.1. Using the tracking command

$ chronyc -n tracking
Reference ID    : 0A051B0A (
Stratum         : 2
Ref time (UTC)  : Thu Mar 08 15:46:20 2018
System time     : 0.000000338 seconds slow of NTP time
Last offset     : +0.000339408 seconds
RMS offset      : 0.000339408 seconds
Frequency       : 2.968 ppm slow
Residual freq   : +0.001 ppm
Skew            : 3.336 ppm
Root delay      : 0.157559142 seconds
Root dispersion : 0.001339232 seconds
Update interval : 64.5 seconds
Leap status     : Normal

Example 32.2. Using the ntpstat utility

$ ntpstat
synchronised to NTP server ( at stratum 2
   time correct to within 80 ms
   polling server every 64 s

32.2. Using authentication mechanism based on public key cryptography

In Red Hat Enterprise Linux 7, ntp supported Autokey, which is an authentication mechanism based on public key cryptography. Autokey is not supported in chronyd.

On a Red Hat Enterprise Linux 8 system, it is recommended to use symmetric keys instead. Generate the keys with the chronyc keygen command. A client and server need to share a key specified in /etc/chrony.keys. The client can enable authentication using the key option in the server, pool, or peer directive.

32.3. Using ephemeral symmetric associations

In Red Hat Enterprise Linux 7, ntpd supported ephemeral symmetric associations, which can be mobilized by packets from peers which are not specified in the ntp.conf configuration file. In Red Hat Enterprise Linux 8, chronyd needs all peers to be specified in chrony.conf. Ephemeral symmetric associations are not supported.

Note that using the client/server mode enabled by the server or pool directive is more secure compared to the symmetric mode enabled by the peer directive.

32.4. multicast/broadcast client

Red Hat Enterprise Linux 7 supported the broadcast/multicast NTP mode, which simplifies configuration of clients. With this mode, clients can be configured to just listen for packets sent to a multicast/broadcast address instead of listening for specific names or addresses of individual servers, which may change over time.

In Red Hat Enterprise Linux 8, chronyd does not support the broadcast/multicast mode. The main reason is that it is less accurate and less secure than the ordinary client/server and symmetric modes.

There are several options of migration from an NTP broadcast/multicast setup:

  • Configure DNS to translate a single name, such as, to multiple addresses of different servers

    Clients can have a static configuration using only a single pool directive to synchronize with multiple servers. If a server from the pool becomes unreacheable, or otherwise unsuitable for synchronization, the clients automatically replace it with another server from the pool.

  • Distribute the list of NTP servers over DHCP

    When NetworkManager gets a list of NTP servers from the DHCP server, chronyd is automatically configured to use them. This feature can be disabled by adding PEERNTP=no to the /etc/sysconfig/network file.

  • Use the Precision Time Protocol (PTP)

    This option is suitable mainly for environments where servers change frequently, or if a larger group of clients needs to be able to synchronize to each other without having a designated server.

    PTP was designed for multicast messaging and works similarly to the NTP broadcast mode. A PTP implementation is available in the linuxptp package.

    PTP normally requires hardware timestamping and support in network switches to perform well. However, PTP is expected to work better than NTP in the broadcast mode even with software timestamping and no support in network switches.

    In networks with very large number of PTP slaves in one communication path, it is recommended to configure the PTP slaves with the hybrid_e2e option in order to reduce the amount of network traffic generated by the slaves. You can configure a computer running chronyd as an NTP client, and possibly NTP server, to operate also as a PTP grandmaster to distribute synchronized time to a large number of computers using multicast messaging.