Configuring Network Time

About the chronyd Daemon

The chrony package provides a chronyd service daemon and chronyc utility that enable mobile systems and virtual machines to update their system clock after a period of suspension or disconnection from a network.

The chronyd service is primarily designed to allow mobile systems and virtual machines to update their system clock after a period of suspension or disconnection from a network. However, you can also use it to implement a simple NTP client or a NTP server. When used as an NTP server, chronyd can synchronise with higher stratum NTP servers or it can act as a stratum 1 server using time signals received from the Global Positioning System (GPS) or radio broadcasts such as DCF77, MSF, or WWVB.

You can use the chronyc command to manage the chronyd service.

Note:

chronyd uses NTP version 3 (RFC 1305), whose features are compatible with NTP version 4 (RFC 5905). However, chronyd does not support several important features of NTP version 4 nor does it support the use of PTP.

Configuring the chronyd Service

To configure the chronyd service on a system:

Install the chrony package.
```
sudo yum install chrony
```
Edit /etc/chrony.conf to set up the configuration for chronyd.

Note:

The default configuration assumes that the system has network access to public NTP servers with which it can synchronise. The firewall rules for your internal networks might well prevent access to these servers but instead allow access to local NTP servers.

The following example shows a sample configuration for a system that can access three NTP servers:
```
server NTP_server_1
server NTP_server_2
server NTP_server_3
driftfile /var/lib/chrony/drift
keyfile /etc/chrony.keys
commandkey 1
generatecommandkey
```
The commandkey directive specifies the keyfile entry that chronyd uses to authenticate both chronyc commands and NTP packets. The generatecommandkey directive causes chronyd to generate an SHA1-based password automatically when the service starts.

To configure chronyd to act as an NTP server for a specified client or subnet, use the allow directive, for example:
```
server NTP_server_1
server NTP_server_2
server NTP_server_3
allow 192.168.2/24
driftfile /var/lib/chrony/drift
keyfile /etc/chrony.keys
commandkey 1
generatecommandkey
```
If a system has only intermittent access to NTP servers, the following configuration might be appropriate:
```
server NTP_server_1 offline
server NTP_server_2 offline
server NTP_server_3 offline
driftfile /var/lib/chrony/drift
keyfile /etc/chrony.keys
commandkey 1
generatecommandkey
```
If you specify the offline keyword, chronyd does not poll the NTP servers until it is told that network access is available. You can use the chronyc -a online and chronyc -a offline command to inform chronyd of the state of network access.
If remote access to the local NTP service is required, configure the system firewall to allow access to the NTP service in the appropriate zones, for example:
```
sudo firewall-cmd --zone=zone --add-service=ntp
```
```
success
```
```
sudo firewall-cmd --zone=zone --permanent --add-service=ntp
```
```
success
```
Start the chronyd service and configure it to start following a system reboot.
```
sudo systemctl start chronyd
sudo systemctl enable chronyd
```

You can use the chronyc command to display information about the operation of chronyd or to change its configuration, for example:

sudo chronyc -a

chrony version version
...
200 OK

chronyc> sources

210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^+ service1-eth3.debrecen.hp     2   6    37    21  -2117us[-2302us] +/-   50ms
^* ns2.telecom.lt                2   6    37    21   -811us[ -997us] +/-   40ms
^+ strato-ssd.vpn0.de            2   6    37    21   +408us[ +223us] +/-   78ms
^+ kvm1.websters-computers.c     2   6    37    22  +2139us[+1956us] +/-   54ms

chronyc> sourcestats

210 Number of sources = 4
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
service1-eth3.debrecen.hp   5   4   259     -0.394     41.803  -2706us   502us
ns2.telecom.lt              5   4   260     -3.948     61.422   +822us   813us
strato-ssd.vpn0.de          5   3   259      1.609     68.932   -581us   801us
kvm1.websters-computers.c   5   5   258     -0.263      9.586  +2008us   118us

Reference ID    : 212.59.0.2 (ns2.telecom.lt)
Stratum         : 3
Ref time (UTC)  : Tue Sep 30 12:33:16 2014
System time     : 0.000354079 seconds slow of NTP time
Last offset     : -0.000186183 seconds
RMS offset      : 0.000186183 seconds
Frequency       : 28.734 ppm slow
Residual freq   : -0.489 ppm
Skew            : 11.013 ppm
Root delay      : 0.065965 seconds
Root dispersion : 0.007010 seconds
Update interval : 64.4 seconds
Leap status     : Normal
chronyc> exit

chronyc> tracking

Reference ID    : 212.59.0.2 (ns2.telecom.lt)
Stratum         : 3
Ref time (UTC)  : Tue Sep 30 12:33:16 2014
System time     : 0.000354079 seconds slow of NTP time
Last offset     : -0.000186183 seconds
RMS offset      : 0.000186183 seconds
Frequency       : 28.734 ppm slow
Residual freq   : -0.489 ppm
Skew            : 11.013 ppm
Root delay      : 0.065965 seconds
Root dispersion : 0.007010 seconds
Update interval : 64.4 seconds
Leap status     : Normal

chronyc> exit

Using the -a option to chronyc is equivalent to entering the authhash and password subcommands, and avoids you having to specify the hash type and password every time that you use chronyc:

sudo cat /etc/chrony.keys

1 SHA1 HEX:4701E4D70E44B8D0736C8A862CFB6B8919FE340E
# chronyc
...
chronyc> authhash SHA1
chronyc> password HEX:4701E4D70E44B8D0736C8A862CFB6B8919FE340E
200 OK

For more information, see the chrony(1) and chronyc(1) manual pages, /usr/share/doc/chrony-version/chrony.txt, or use the info chrony command.

About the NTP Daemon

The ntpd daemon can synchronise the system clock with remote NTP servers, with local reference clocks, or with GPS and radio time signals. ntpd provides a complete implementation of NTP version 4 (RFC 5905) and is also compatibility with versions 3 (RFC 1305), 2 (RFC 1119), and 1 (RFC 1059).

You can configure ntpd to run in several different modes, as described at http://doc.ntp.org/4.2.6p5/assoc.html, using both symmetric-key and public-key cryptography, as described at http://doc.ntp.org/4.2.6p5/authopt.html.

Configuring the ntpd Service

To configure the ntpd service on a system:

Install the ntp package.
```
sudo yum install ntp
```
Edit /etc/ntp.conf to set up the configuration for ntpd.

Note:

The default configuration assumes that the system has network access to public NTP servers with which it can synchronise. The firewall rules for your internal networks might well prevent access to these servers but instead allow access to local NTP servers.

The following example shows a sample NTP configuration for a system that can access three NTP servers:
```
server NTP_server_1
server NTP_server_2
server NTP_server_3
server  127.127.1.0
fudge   127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
restrict default nomodify notrap nopeer noquery
```
The server and fudge entries for 127.127.1.0 cause ntpd to use the local system clock if the remote NTP servers are not available. The restrict entry allows remote systems only to synchronise their time with the local NTP service.

For more information about configuring ntpd, see http://doc.ntp.org/4.2.6p5/manyopt.html.
Create the drift file.
```
touch /var/lib/ntp/drift
```
If remote access to the local NTP service is required, configure the system firewall to allow access to the NTP service in the appropriate zones, for example:
```
sudo firewall-cmd --zone=zone --add-service=ntp
```
```
success
```
```
sudo firewall-cmd --zone=zone --permanent --add-service=ntp
```
```
success
```
Start the ntpd service and configure it to start following a system reboot.
```
sudo systemctl start ntpd
sudo systemctl enable ntpd
```

You can use the ntpq and ntpstat commands to display information about the operation of ntpd, for example:

sudo ntpq -p

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*ns1.proserve.nl 193.67.79.202    2 u   21   64  377   31.420   10.742   3.689
-pomaz.hu        84.2.46.19       3 u   22   64  377   59.133   13.719   5.958
+server.104media 193.67.79.202    2 u   24   64  377   32.110   13.436   5.222
+public-timehost 193.11.166.20    2 u   28   64  377   57.214    9.304   6.311

sudo ntpstat

synchronised to NTP server (80.84.224.85) at stratum 3 
   time correct to within 76 ms
   polling server every 64

For more information, see the ntpd(8), ntpd.conf(5), ntpq(8), and ntpstat(8) manual pages and http://doc.ntp.org/4.2.6p5/.

About PTP

PTP allows you to synchronise system clocks on a local area network to a higher accuracy than NTP. Provided that network drivers support either hardware or software time stamping, a PTP clock can use the time stamps in PTP messages to compensate for propagation delays across a network. Software time stamping allows PTP to synchronise systems to within a few tens of microseconds. With hardware time stamping, PTP can synchronise systems to within a few tenths of a microsecond. If you require high-precision time synchronization of systems, use hardware time stamping. Both the UEK R3 and RHCK kernels support PTP version 2 as defined in IEEE 1588.

A typical PTP configuration on an enterprise local area network consists of:

One or more grandmaster clock systems.

A grandmaster clock is typically implemented as specialized hardware that can use high-accuracy GPS signals or lower-accuracy code division multiple access (CDMA) signals, radio clock signals, or NTP as a time reference source. If several grandmaster clocks are available, the best master clock (BMC) algorithm selects the grandmaster clock based on the settings of their priority1, clockClass, clockAccuracy, offsetScaledLogVariance, and priority2 parameters and their unique identifier, in that order.
Several boundary clock systems.

Each boundary clock is backed up to a grandmaster clock on one subnetwork and relays PTP messages to one or more additional subnetworks. A boundary clock is usually implemented as a function of a network switch.
Multiple slave clock systems.

Each slave clock on a subnetwork is backed up to a boundary clock, which acts as the master clock for that slave clock.

A simpler configuration is to set up a single grandmaster clock and multiple slave clocks on the same network segment, which removes any need for an intermediate layer of boundary clocks.

Grandmaster and slave clock systems that use only one network interface for PTP are termed ordinary clocks.

Boundary clocks require at least two network interfaces for PTP: one interface acts a slave to a grandmaster clock or a higher-level boundary clock; the other interfaces act as masters to slave clocks or lower-level boundary clocks.

Synchronization of boundary and slave clock systems is achieved by sending time stamps in PTP messages. By default, PTP messages are sent in UDPv4 datagrams. It is also possible to configure PTP to use UDPv6 datagrams or Ethernet frames as its transport mechanism.

To be able to use PTP with a system, the driver for at least one of the system's network interfaces must support either software or hardware time stamping. To find out whether the driver for a network interface supports time stamping, use the ethtool command as shown in the following example:

sudo ethtool -T em1

Time stamping parameters for em1:
Capabilities:
	hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
	software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
	hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
	software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
	software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
	hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
...

The output from ethtool in this example shows that the em1 interface supports both hardware and software time stamping capabilities.

With software time stamping, ptp4l synchronises the system clock to an external grandmaster clock.

If hardware time stamping is available, ptp4l can synchronise the PTP hardware clock to an external grandmaster clock. In this case, you use the phc2sys daemon to synchronise the system clock with the PTP hardware clock.

Configuring the PTP Service

To configure the PTP service on a system:

Install the linuxptp package.
```
sudo yum install linuxptp
```
Edit /etc/sysconfig/ptp4l and define the start-up options for the ptp4l daemon.

Grandmaster clocks and slave clocks require that you define only one interface.

For example, to use hardware time stamping with interface em1 on a slave clock:
```
OPTIONS="-f /etc/ptp4l.conf -i em1 -s"
```
To use software time stamping instead of hardware time stamping, specify the -S option:
```
OPTIONS="-f /etc/ptp4l.conf -i em1 -S -s"
```
Note:

The -s option specifies that the clock operates only as a slave (slaveOnly mode). Do not specify this option for a grandmaster clock or a boundary clock.

For a grandmaster clock, omit the -s option, for example:
```
OPTIONS="-f /etc/ptp4l.conf -i em1"
```
A boundary clock requires that you define at least two interfaces, for example:
```
OPTIONS="-f /etc/ptp4l.conf -i em1 -i em2"
```
You might need to edit the file /etc/ptp4l.conf to make further adjustments to the configuration of ptp4l, for example:
- For a grandmaster clock, set the value of the priority1 parameter to a value between 0 and 127, where lower values have higher priority when the BMC algorithm selects the grandmaster clock. For a configuration that has a single grandmaster clock, a value of 127 is suggested.
- If you set the value of summary_interval to an integer value N instead of 0, ptp4l writes summary clock statistics to /var/log/messages every 2^N seconds instead of every second (2⁰ = 1). For example, a value of 10 would correspond to an interval of 2¹⁰ or 1024 seconds.
- The logging_level parameter controls the amount of logging information that ptp4l records. The default value of logging_level is 6, which corresponds to LOG_INFO. To turn off logging completely, set the value of logging_level to 0. Alternatively, specify the -q option to ptp4l.
For more information, see the ptp4l(8) manual page.
Configure the system firewall to allow access by PTP event and general messages to UDP ports 319 and 320 in the appropriate zone, for example:
```
sudo firewall-cmd --zone=zone --add-port=319/udp --add-port=320/udp
```
```
success
```
```
sudo firewall-cmd --permanent --zone=zone --add-port=319/udp --add-port=320/udp
```
```
success
```
Start the ptp4l service and configure it to start following a system reboot.
```
sudo systemctl start ptp4l
sudo systemctl enable ptp4l
```
To configure phc2sys on a clock system that uses hardware time stamping:
1. Edit /etc/sysconfig/phc2sys and define the start-up options for the phc2sys daemon.
  
  On a boundary clock or slave clock, synchronise the system clock with the PTP hardware clock that is associated with the slave network interface, for example:
```
OPTIONS="-c CLOCK_REALTIME -s em1 -w"
```
  Note:
  
  The slave network interface on a boundary clock is the one that it uses to communicate with the grandmaster clock.
  
  The -w option specifies that phc2sys waits until ptp4l has synchronised the PTP hardware clock before attempting to synchronise the system clock.
  
  On a grandmaster clock, which derives its system time from a reference time source such as GPS, CDMA, NTP, or a radio time signal, synchronise the network interface's PTP hardware clock from the system clock, for example:
```
OPTIONS="-c em1 -s CLOCK_REALTIME -w"
```
  For more information, see the phc2sys(8) manual page.
2. Start the phc2sys service and configure it to start following a system reboot.
```
sudo systemctl start phc2sys
sudo systemctl enable phc2sys
```

You can use the pmc command to query the status of ptp4l operation. The following example shows the results of running pmc on a slave clock system that is directly connected to the grandmaster clock system without any intermediate boundary clocks:

sudo pmc -u -b 0 'GET TIME_STATUS_NP'

sending: GET TIME_STATUS_NP
	080027.fffe.7f327b-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP 
		master_offset              -98434
		ingress_time               1412169090025854874
		cumulativeScaledRateOffset +1.000000000
		scaledLastGmPhaseChange    0
		gmTimeBaseIndicator        0
		lastGmPhaseChange          0x0000'0000000000000000.0000
		gmPresent                  true
		gmIdentity                 080027.fffe.d9e453

sudo pmc -u -b 0 'GET CURRENT_DATA_SET'

sending: GET CURRENT_DATA_SET
	080027.fffe.7f327b-0 seq 0 RESPONSE MANAGEMENT CURRENT_DATA_SET 
		stepsRemoved     1
		offsetFromMaster  42787.0
		meanPathDelay    289207.0

Useful information in this output includes:

gmIdentity: The unique identifier of the grandmaster clock, which is based on the MAC address of its network interface.
gmPresent: Whether an external grandmaster clock is available. This value is displayed as false on the grandmaster clock itself.
meanPathDelay: An estimate of how many nanoseconds by which synchronization messages are delayed.
offsetFromMaster: The most recent measurement of the time difference in nanoseconds relative to the grandmaster clock.
stepsRemoved: The number of network steps between this system and the grandmaster clock.

For more information, see the phc2sys(8), pmc(8), and ptp4l(8) manual pages, https://www.zhaw.ch/en/engineering/institutes-centres/ines/downloads/documents.html, and IEEE 1588.

Using PTP as a Time Source for NTP

To make the PTP-adjusted system time on an NTP server available to NTP clients, include the following entries in /etc/ntp.conf on the NTP server to define the local system clock as the time reference:

server    127.127.1.0
fudge     127.127.1.0 stratum 0

Note:

Do not configure any additional server lines in the file.

For more information, see Configuring the ntpd Service.