[ntp:questions] NTP driving me nuts!

JCA 1.41421 at gmail.com
Sun Dec 31 22:41:33 UTC 2006


On 12/31/06, Danny Mayer <mayer at ntp.isc.org> wrote:
> JCA wrote:
> >> >     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
> >>
> >> Does DNS resolve this to the same address?
> >
> >   Yes.
> >
> >> >
> >> > 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
>
> If this is pointing to itself why is this here?

   I misunderstood your question. See below.

> >> > 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.
> >> >
> >>
> >> Is reloj.kjsl.com on that address or a different address?
> >
> >    reloj.kjsl.com is an external server - nothing to to with my LAN.
> > 192.168.0.1 is the IP address of C in my LAN - nothing to do with
> > reloj.kjsl.com.
> >
>
> This contradicts what you just said above. So which is it?\

    What I said in this paragraph here - reloj.kjsl.com is external,
while C (resolving as 192.168.0.1) is internal.

> >> If it's the
> >> same address as C then you need to remove that line from C's
> >> configuration.
> >>
> >> >
> >> >    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.
> >>
> >> You network may have changed or a firewall may have been added or DNS
> >> has changed.
> >
> >   I don't know what my ISP does with the network, but I know that my
> > setup is the same as before.
> >
>
> Are A, B and C all on your ISP's network or are they local to your LAN?

    A and B are local to my LAN. C has two NICs - one connected to my
LAN, the other to the external world. A and B have access to the
external world through C, which is doing IP masquerading for them.

> >   The problem seems to be in C. C keeps in sync with the external
> > server all right. If either A or B take their synchronization from C,
> > they stay in sync for some time - hours, maybe a day. After that, they
> > don't seem to get any synchronization ticks from C anymore, and their
> > clocks start to drift big time.
> >
> >   If, on the other hand, either A or B get their synchronization from
> > the same external host as C does, then they keep in sync indefinitely
> > all right. C keeps in sync with the external clock all right.
> >
>
> C is not synching so A and B cannot synchronize with it.

    What do you mean? As I wrote above, C is synching with the
external clock. A and B are supposed to get their synching from C,
which initially they do. But, after a while, they don't anymore.

>
> >   I am totally puzzled by this behavior. Might it be that a dying
> > clock battery in one or more of my PCs could be the cause. I mean, is
> > it not the case that when a battery is losing power the clock becomes
> > more and more erratic, so much so that ntpd might altogether refuse to
> > adjust it? Can this possibility be explored with the NTP software?
> >
>
> No, you need to figure out what's wrong with C.

    These are the facts:

    1) C is getting its synching from external clocks, and keeping it
fine, never drifting more than 0.5 seconds either way with respect to
those clocks.

    2) A and B keep in synch fine with respect to the same external
clocks as C, when they get their synching directly from such clocks.

    3) A and B keep in synch fine with respect to C for a while (from
several hours to one or two days) when they get their synching
directly from C. Then the clocks in both A and B start drifting away
from C's and from each other. I can see no ntp related traces in any
of A, B and C.  For all practical purposes, A and B just seem to stop
receiving synch adjustments from C.

    4) Network connectivity is always fine between A, B and C, and
between them all and the external world.

     I do agree that the problem seems to be in C's ntp daemon. The
question is, why is it happening all of a sudden, when it has been
working fine for months, of not years? Nothing has changed in C. How
do I go about to diagnosing the ntp problem in C?



More information about the questions mailing list