Force Rhel to sync with NTP server?
I have a rhel 6 host that I am trying to point to a juniper ssg firewall as an ntp server. It isnt working quite right and I found the below article from Juniper which details the exact issue I am seeing. Question for you all is there a way to force it to sync and remain synced with this firewall?
https://kb.juniper.net/InfoCenter/index?page=content&id=KB24784
Responses
"A person with a clock will know the time. A person with two clocks will be uncertain."
I just extracted the source RPM of the latest RHEL 6 NTP package: ntp-4.2.6p5-12.el6_9.1.src.rpm.
The only place the reference ID "LOCL" is mentioned is in file refclock_local.c is in file ntp-4.2.6p5/ntpd/refclock_local.c, which is the NTP reference clock driver used if server 127.127.1.0 is listed in /etc/ntp.conf.
There is no mention of the reference ID "LOCL" anywhere else in the code. In particular, I couldn't find anything that would make the ntpd/ntpdate toolset identify that reference ID and reject it when acting as a client. As a result, I believe the Juniper KB article to be either incorrect or simply an overgeneralization of a special case encountered at some point.
The Juniper KB article mentioned above has this ntpq output:
remote refid st t when poll reach delay offset jitter
============================================================
pns.pv9.nox.co. .LOCL. 1 u 20 64 1 0.570 -97.876 0.001
tusntp.tus.ac.j .GPS. 1 u 19 64 1 59.421 7.740 0.001
Although there are two timesources with minimal jitter and good stratum, there is no asterisk in the leftmost column of the listing on any line, so ntpd is not in sync with either timesource. The reason for this is that the "reach" value is 1 for both sources - i.e. this ntpd is probably only just started and doesn't use the iburst option.
Since jitter is minimal for both timesources, the delay is not a problem: the low jitter indicates the delay is very predictable, so ntpd can easily compensate for it. With both timesources having stratum 1, both these timesources are claiming to be extremely good. However, the different offset values indicate that the timesources' clocks are not in full agreement with each other.
In this situation, ntpd attempts to sync with the timesource that most closely matches the local system's own clock, because it has no way of knowing which of the two timesources would be "better". But since both the system's local clock and the clock of the first timesource are regular computer clocks and not super-accurate atomic clocks, they will drift in relation to the second timesource, whose refid indicates it claims to be a GPS time receiver of some sort. For the sake of explanation, I'm assuming here that the claim is true and the time of the GPS timesource is accurate; however, ntpd makes no such assumptions.
Since both the first timesource and the system's local clock will drift, this local ntpd will see first one timesource and then the other as being the "best" for it. Because of this random drifting, if it gets in sync with one timesource, sooner or later it will see the other one as being "better" and switch to it. Because both timesources claim stratum 1, ntpd has no way of knowing that the GPS receiver's time is more likely to be closer to the ideal "real UTC time". So, ntpd ends up ping-ponging between the two equal-stratum timesources. And because syncing itself (without iburst) takes several polling cycles, it may end up spending most of its time in unsynchronized state, unable to stick with either of the two timesources.
With just one timesource, there would be no doubt; with three or more timesources, ntpd could exclude the worst outliers and then follow the majority. But with exactly two timesources that are not synchronized with each other in any way, ping-ponging is a common occurrence.
Brian, along with what Matti wrote, here's some additional background on NTP.
1) This Red Hat solution https://access.redhat.com/solutions/778603 dated 2014, an oldie, but a good one.
2) This Red Hat Solution for virtual systems https://access.redhat.com/solutions/27865
Lastly, this is a link to previous Red Hat discussions on NTP
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
