[ntp:questions] NTP driving me nuts!

[JCA]

On 12/28/06, Danny Mayer <mayer at ntp.isc.org> wrote:
> JCA wrote:
> > On 12/27/06, Danny Mayer <mayer at ntp.isc.org> wrote:
> >> JCA wrote:
> >> >    I have three Linux boxes, A, B and C, running ntpd. C gets its
> >> > synchronization from some external, stratum 2 server, whereas A and B
> >> > get their synchronization from C, as a stratum 3 server.
> >> >
> >> >    This setup has been working fine for months. A couple of days ago I
> >> > noticed that A and B did not seem to be in sync any more. I restarted
> >> > ntpd in A and B, making sure that A and B were synchronized with C by
> >> > hand before. They both started fine but, surely enough, they did not
> >> > seem to be keeping up with C - the local clocks on A and B started to
> >> > diverge as though ntpd were not running at all.
> >> >
> >> >    C is reachable from A and B without any problems. In turn, C stays
> >> > synchronized with the external server all right - always within 0.05
> >> > seconds. Nothing has changed in A, B and C within the last few months.
> >> > I just can't understand why, all of a sudden, A and B are no
> >> > synchronizing with C at all.
> >> >
> >> >   How can one even begin to diagnose this problem? ntpd on A and B is
> >> > not dumping any information to my logs. In particular, the "time
> >> > reset" messages are absent. For all practical purposes, it is as
> >> > though it were not running at all on those two boxes - however,
> >> > synchronizing by hand with C by means of ntpdate works fine on both A
> >> > and B.
> >> >
> >> >    Any ideas, anyone?
> >>
> >> Not without any information. post the output of ntpq -p A B C so we can
> >> see at least whether at least they are synchronized.
> >
> >    Here's the output from ntpq -p A B C as obtained when executed at A:
> >
> >
> > host                remote           refid           st t when poll
> > reach   delay   offset  jitter
> > =========================================================================================================
> >
> > A.mydomain.org   *LOCAL(0)        LOCAL(0)           10 l   58   64
> > 377    0.000    0.000   0.004
> > A.mydomain.org    C.mydomain 192.83.249.28            3 u  435 1024
> > 357    1.741  2646.98 562.826
> >
> > host                remote           refid           st t when poll
> > reach   delay   offset  jitter
> > =========================================================================================================
> >
> > B.mydomain.org    LOCAL(0)        LOCAL(0)           10 l   53   64
> > 377    0.000    0.000   0.004
> > B.mydomain.org   *gabe.kjsl.com   204.123.2.72        2 u   55  256
> > 377  226.316   34.622 239.653
> >
> > host                remote           refid           st t when poll
> > reach   delay   offset  jitter
> > =========================================================================================================
> >
> > C.mydomain.org    LOCAL(0)        LOCAL(0)           10 l   56   64
> > 377    0.000    0.000   0.008
> > C.mydomain.org   +gabe.kjsl.com   204.123.2.72        2 u   77  512
> > 377  812.788  -91.428  71.546
> > C.mydomain.org   *zorro.sf-bay.or 216.218.254.202     2 u   18  512
> > 357  539.809  -240.04  89.970
> > C.mydomain.org    165.227.227.1   0.0.0.0            16 u    -  256
> > 0    0.000    0.000 4000.00
> > C.mydomain.org   +zorac.sf-bay.or 204.123.2.5         2 u   19  512
> > 377  402.009  -310.04 671.127
> > C.mydomain.org    io.berkeley.net 0.0.0.0            16 u   72  256
> > 0    0.000    0.000 4000.00
> >
> >    There is one change with respect to the setup I described, in that
> > host B now gets its synchronization from the same external host as C,
> > whereas A still gets its synchronization from C.
> >
> >    When I obtained this data, both hosts B and C were staying in sync
> > reasonably well (always less than 0.5 seconds) with the external host,
> > whereas A had already drifted more than 3 seconds.
> >
>
> You also need to post your ntp.conf files. There is also something wrong
> with the output since there seems to be an extra entry at the beginning.

     The ntp.conf configuration files of A and B are identical:

server  127.127.1.0
fudge   127.127.1.0 stratum 10
server        192.168.0.1
# server reloj.kjsl.com

driftfile /etc/ntp/drift
multicastclient                 # listen on default 224.0.1.1
broadcastdelay  0.008

    192.168.0.1 is the IP address of C in my LAN. In the ntpq traces
above B's ntp.conf file was using

    server reloj.kjsl.com

rather than

   server 192.168.0.1

    C's ntp.conf configuration file:

server  127.127.1.0     # local clock
fudge   127.127.1.0 stratum 10

server reloj.kjsl.com
server ntp1.sf-bay.org

driftfile /var/run/ntp.drift

   If in A's and B's configuration files I use the line

   server reloj.kjsl.com

instead of

  server 192.168.0.1

then A and B keep the time all right. C keeps the time all right with
the configuration file above.

   Interestingly, I have another Linux box D in my LAN that seems to
be keeping in sync with C with the following ntp.conf file:

restrict default ignore
restrict 192.168.0.1 mask 255.255.255.255 nomodify notrap noquery

restrict 127.0.0.1

server 192.168.0.1
fudge   127.127.1.0 stratum 10

driftfile /var/lib/ntp/drift
broadcastdelay  0.008

authenticate yes
keys            /etc/ntp/keys

   I could of course change A's and B's ntp.conf files accordingly and
see what happens. However, were this to lead to A and B synchronizing
with C all right, it still would not explain why A and B had been
synchronizing with C with no problems until recently.

> And please don't send just to me personally, use the maiing list. I
> won't necessarily be the one to solve your problem.

   Oops! My mistake. Sorry.