[ntp:questions] Remaining synced on an unsynchronised peer?
Michael Butow
michael.buetow at comsoft.de
Mon Nov 30 19:08:45 UTC 2009
Hello,
I am seeing behaviour with RHEL5.3 (ntp-4.2.2p1-9.el5) which I have a
question about, and am wondering whether someone knows an answer (or can
tell me that it's a bug):
I have 2 machines, call them host1 and host2, which both get their time
from the same external NTP servers ntp1 and ntp2.
Host1 and host2 are also peered. In short, each of their ntp.conf looks
like (with the partner host as "peer"):
server ntp1 version 4 iburst prefer
server ntp2 version 4 iburst 5
peer <partner> version 4 iburst
When I disconnect the LAN that connects host1/host2 to the external
servers ntp1 and ntp2, I see something that I do not understand:
After both host1 and host2 lose reachability to their external servers,
one of them will become synchronised on its peer, ie. ntpq -p will show a
'*' on the peer, despite the peer not having any '*' (no external clocks).
The reachability of the peers to each other will fluctuate between 376
and 377.
There will be a message in /var/log/messages on the host that has no '*'
that it has lost sychronisation, however, on the other one there is no
such message (this conforms to what is visible using ntpq -p).
I waited more than 77 minutes, but the machine with the '*' did not
become unsynchronised, even though it's peer had no more reliable time
source.
I was expecting both host1 & host2 to become unsynchronised after a short
time - our application depends on it and it was a test that was
successful on a prior version (running on RHEL3.8, ntp-4.1.2-4.EL3.1).
Am I seeing a bug, or do I have a wrong expectation/understanding?
Any insights would be appreciated.
Regards,
Michael
P.S. Detail that I omitted: we use minpoll=maxpoll=5 (for historic
reasons in our system).
More information about the questions
mailing list