[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