Can NTP be used with two NTP servers, specifying one as primary and another as backup?
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
- 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 protects 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: http://support.ntp.org/bin/view/Support/SelectingOffsiteNTPServers. 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. 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
-
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, thentpq -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 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
-
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.
5 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