Can ntpd/chronyd be used with two NTP servers, specifying one as primary and another as backup?
Environment
- Red Hat Enterprise Linux (RHEL)
- 6
- 7
- 8
- 9
- 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, andtrust
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, 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 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.
Comments