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

Solution Verified - Updated -

Environment

  • Red Hat Enterprise Linux 4, 5, 6, 7 with NTP
  • Red Hat Enterprise Linux 7 with Chrony

Issue

  • Can NTP 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

Redundancy

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

  • Note that this option defeats the purpose of NTP's timesource selection algorithms and allow 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 NTP

  1. Example /etc/ntp.conf specification:

    server 192.168.0.1 true  
    server 192.168.0.2
    
  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:

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

      # 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
      
    2. 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:

      # 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
      

Root Cause

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

Diagnostic Steps

For RHEL 4-7:

  • Check the number of clocks configured in the /etc/ntp.conf file using:

    grep -E '^(peer|server)' /etc/ntp.conf
    
  • Check the number of clocks ntpd is currently using:

    ntpq -p
    

For RHEL 7:

  • Check the number of clocks configured in the /etc/chrony.conf file using:

    grep -E '^(peer|server)' /etc/chrony.conf
    
  • Check the number of clocks chronyd is currently using:

    chronyc sources
    

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.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.