Can ntpd/chronyd be used with two NTP servers, specifying one as primary and another as backup?

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux (RHEL) 4, 5, 6, 7, 8
  • ntp
  • chrony

Issue

  • Can ntpd/chronyd be used with two NTP servers, specifying one as primary and another as backup?
  • How many upstream time servers should be configured in the NTP configuration file?

Resolution

Recommended Configuration

  • It is NOT recommended to use only two NTP servers.
  • If more than one NTP server is required, four NTP servers is the recommended minimum. Four servers protect against one incorrect timesource, or "falseticker". For more information refer to Best practices for NTP
  • Also refer to the upstream NTP documentation for additional detail: 5.3. Selecting Offsite NTP Servers. Especially the chapter 5.3.3. Upstream Time Server Quantity, it is well documented and clarified.

Redundancy

  • If two NTP servers are required for redundancy, one server can be assumed a truechimer by using the true option in ntp.conf, and trust option in chrony.conf. But the NTP client will not follow it blindly.

  • Note that this option defeats the purpose of NTP's timesource selection algorithms and allows the sources with this option to set the system clock. If the specified time source is unstable, the system will not be able to identify the problem.

Example for ntpd

  • Example /etc/ntp.conf specification:
server 192.168.0.1 true  
server 192.168.0.2
  • Then restart the ntpd service. Wait for about fifteen minutes to let NTP collect enough information to operate with accuracy. After that, the ntpq -pn command can be used to check the sync status. There are two possible results:

  • If both NTP servers are stable and sync with each other, there will be a * or + in front of both NTP servers. For example:

 [root@localhost ~]# ntpq -pn  
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+192.168.0.1     LOCAL(0)         6 u   10   16  377    0.154    4.200   2.416
*192.168.0.2     LOCAL(0)         6 u    1   16  377    0.981    0.982   0.400
  • If the time info provided by the two NTP servers which were sticking to their local time is not in-sync, ntpd will trust the server which has the true option and assume the other one is a falseticker. For example:
[root@localhost ~]# ntpq -pn  
remote           refid       st t when poll reach   delay   offset   jitter  
==============================================================================  
*192.168.0.1        LOCAL(0)     6  u 10   16   377     0.211   -16.920 2.562  
x192.168.0.2        LOCAL(0)     6  u 1    16   377     0.581    5.242  4.597

Example for chronyd

  • Example /etc/chrony.conf specification:
server 192.168.0.1 trust  
server 192.168.0.2

Root Cause

  • When ntpd/chronyd gets information from two time sources and the times provided do not fall into a small enough range, the ntpd/chronyd daemon cannot determine which timesource is correct and which is the falseticker.

Diagnostic Steps

For ntpd:

  • Check the number of clocks configured in the /etc/ntp.conf file using:
[root@localhost ~]# grep -E '^(peer|server)' /etc/ntp.conf
  • Check the number of clocks ntpd is currently using:
[root@localhost ~]# ntpq -p

For chronyd:

  • Check the number of clocks configured in the /etc/chrony.conf file using:
[root@localhost ~]# grep -E '^(peer|server)' /etc/chrony.conf
  • Check the number of clocks chronyd is currently using:
[root@localhost ~]# chronyc sources
  • From man ntp.conf:
       true    Mark the association to assume truechimer  status;  that  is,  always
               survive  the  selection and clustering algorithms. This option can be
               used with any association, but is most useful  for  reference  clocks
               with  large  jitter on the serial port and precision pulse-per-second
               (PPS) signals. Caution: this option defeats the  algorithms  designed
               to  cast out falsetickers and can allow these sources to set the sys-
               tem clock. This option is valid only with the server  and  peer  com-
               mands.
  • From man chrony.conf:
           trust
               Assume time from this source is always true. It can be rejected as a
               falseticker in the source selection only if another source with this
               option does not agree with it.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

7 Comments

Links seem to be broken does Redhat have an alternative source for those documents.

Not sure which link you mean, Grant - I know this is from a while back but as of January 2018 all three links on this page work.

Hope this helps,

Paul

Can we force the NTP to sync from a source by marking it true even if we have multiple sources mentioned in the /etc/ntp.conf or it works only when we have 2 ntp source servers?

The simple answer is: yes. You can mark any source as a truechimer by adding the 'true' parameter to its config line.

But the first question that occurs to me is... "why?". Why force all traffic to one NTP server? That to me would seem to create an artificial bottleneck and would increase the chance of failure. It would also leave you more vulnerable to variation in the clock of that server, because NTP is being told explicitly to not compensate for variations by using other time sources.

Red Hat always recommends the use of at least four clock servers and to let ntpd or chronyd work out independently which ones to trust and by how much. We would not recommend marking a server as a truechimer or as preferred in general usage.

Hope this helps,

Paul

Hi, I have the similar problem in chrony, is there any parameter like "true"as it's ntp ?

MS Name/IP address Stratum Poll Reach LastRx Last sample

^x 172.2x.7.x1 2 6 377 3 +29us[ +29us] +/- 16ms ^x 172.2x.7.x2 15 6 37 11 +43ms[ +43ms] +/- 12ms

Hello:

As it is said, "It is NOT recommended to use only two NTP servers.", may I know if this rule works for "PTP" on Azure or "Local Server" on AWS?

  • https://docs.microsoft.com/en-us/azure/virtual-machines/linux/time-sync

  • https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html

I mean, if TWO sources are used but one of them is PTP or Local server (of AWS), will it cause the "falseticker"?

Thanks.

Hi Xiangce,

The short answer is - yes. When you have two time sources, if they disagree then you have no third or fourth source to compare to in order to pick which is the 'truechimer' and which is the 'falseticker'.

With PTP on Azure and Local Servers on AWS, these are roughly the same as the 'true' or 'prefer' keyword on a server or peer in NTP - they can be treated as correct because the underlying infrastructure that provides that source of time has more 'guarantees' that it will be consistent, accurate and won't fail.

But what if the other source starts diverging? If ntpd or chronyd aren't told that a source is authoritative, then they can't decide which is the truechimer and which is the falseticker.

In the case of AWS or Azure, I'd be reasonably confident in the infrastructure to provide that time source, because we hope that large companies like Amazon and Microsoft have ensured that the underlying mechanism providing the time source to the virtual machine are accurate and highly available. So I think it would be reasonable to add the 'true' or 'prefer' keyword to a PTP or Local Server source in the ntpd or chronyd configuration.

But in that case, having a third and fourth source can't hurt either. That allows the guest OS to be confident that even in an unusual catastrophic failure of the host's time service provision it can still have a confidence in other sources.

Hope this helps,

Paul