[ntp:questions] NTPD silently not tracking

[E-Mail Sent to this address will be added to the BlackLists]

Magnus Danielson wrote:
> We had another incident where a node configured with multiple NTP
> sources had an NTPD which when asked with ntpdc have peers, looks like
> things are all OK, but with offsets less than a second, while the node
> in fact was 6 days off the mark. Only on a number of ntpdc querries did
> some of the peers expose a gigantic offset. Everything looked OK, but
> time was off such that normal remote login did not work.
>
> The error was way to non-obvious and felt like a Heisenbug in that only
> when we looked more carefully at it, it started to see itself that it
> was out of touch with reality.
>
> ii  ntp   1:4.2.6.p5+d i386   Network Time Protocol daemon and

What ntpdc commands did you issue, and what results did you get?

Did you also try ntpq commands, did you see differing results?
ntpq -n -c "rv 0 leap"
ntpq -n -c "rv 0 stratum"
ntpq -n -c "rv 0 refid"
ntpq -n -c "rv 0 offset"
ntpq -n -c "rv 0 rootdisp"


Have you tried a newer version of NTP ?
<http://www.ntp.org/downloads.html>
<http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/>
<http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p385.tar.gz>


Don't use Undisciplined Local Clock 27.127.1.0
 Try Orphan instead is you need LAN NTP clients to stick together
  while LAN and/or Internet NTP servers become unavailable.
 ...
 keys "/etc/ntp.keys" # e.g. contains: 123 M LAN_MD5_KEY , 321 M Corp_MD5_KEY , ...
 trustedkey 123 321
 tos cohort 1 orphan 10
 restrict source nomodify
 manycastserver  224.0.1.1
 manycastclient  224.0.1.1 key 123 preempt
 ...


-- 
E-Mail Sent to this address <BlackList at Anitech-Systems.com>
  will be added to the BlackLists.