[ntp:questions] NTP shows all servers in condition "reject"
David Woolley
david at ex.djwhome.demon.co.uk.invalid
Tue Jun 10 20:59:31 UTC 2008
Steve Kostecke wrote:
> On 2008-06-09, Ronny Egner <Ronny.Egner at siv.de> wrote:
>
>> ntpq> peers
>> remote refid st t when poll reach delay offset jitter
>> ======================================================================
>> solaris-server 10.x.y.2 5 u 18 64 377 0.259 892.342 30.508
>> windows-dc-serverA 10.x.v.1 4 u 17 64 377 0.214 847.816 50.335
>> windows-dc-serverB 10.x.v.1 4 u 22 64 377 0.272 923.808 45.667
>
> There is a signifiant diference in offsets between those remote time
> servers. And the jitter is quite high. Are all of these server on the
> same LAN? Are any at remote sites or reached over a VPN?
The delay is too low for a VPN.
>
>> ntpq> rv 39492
>> assID=39492 status=9014 reach, conf, 1 event, event_reach,
>> srcadr=solaris-server, srcport=123, dstadr=10.x.y.z, dstport=123, leap=00,
>> stratum=5, precision=-18, rootdelay=31.601, rootdispersion=10316.483,
>
> The root dispersion suggests that this peer has not been synced to a
> real time source is quite a while. This needs to be fixed first.
The root dispersion is an order of magnitude too high for the server to
be acceptable. I thought W32Time was the only implementation that
didn't go to stratum 16 when the root distance exceeded 1 second, so I'm
not quite sure how a Solaris system could be reporting a valid stratum
but such a high root dispersion. However the precision is too good to
be W32Time. Could it be using some other alternative NTP implementation?
>
> Could you please post the solaris-server 'ntpq -p' billboard from (in a
> condensed format as shown above)?
I think you will find that its servers are the two windows domain
controllers. However, if it is running an alternative NTP
implementation it unlikely to respond to ntpq.
>
>> ntpq> rv 39493
>> assID=39493 status=9014 reach, conf, 1 event, event_reach,
>> srcadr=windows-dc-serverA, srcport=123, dstadr=10.x.y.z,
>> dstport=123, leap=00, stratum=4, precision=-6, rootdelay=31.250,
>> rootdispersion=10285.095, refid=10.x.v.1, reach=377, unreach=0,
>
> Same problem here, too.
But this could be W32Time, assuming that the recent versions aren't
still stuck at stratum 2.
The original article appears to have failed to make it to the newsgroup,
its not on groups.google as well as not in my feed, so I don't know if
there was an rv 0 and what the reference times were, but I'm not sure if
root dispersion is only the remote component, or whether it could be
generated locally with a very old reference time.
>
More information about the questions
mailing list