[ntp:questions] Reachable and rejected

Richard B. Gilbert rgilbert88 at comcast.net
Fri Sep 12 20:48:16 UTC 2008


Dave Close wrote:
> David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:
> 
>> Dave Close wrote:
> 
>>> What I haven't found while reading is how it is possible for a server to
>>> be both reachable and rejected. Note that the reject condition is not
> 
>> That's quite easy, but I can't see a case which applies here (using a 
>> not recently synchronised w32time server (NAT would make no difference), 
>> kiss of death because of the excess query rate from the router (I think 
>> the refid would be special); the two servers have error bands that do 
>> not overlap (I can't remember whether this would produce a special flag 
>> in the ntpq output))
> 
>>> constant; the servers are accepted occasionally, but not for very long.
> 
>> That does sound like kiss of death, except for the refid.
> 
>> What would help is the result of running rv against each association ID, 
>> to get the detailed state for the association.
> 
> Ok, here goes. I hope this means something to someone else...
> 
> # ntpq -p
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  server1         172.16.2.5       2 u   24   64  377    2.159  -51835.   8.729
>  server2         172.16.2.5       2 u   46   64  377    2.200  -51822.  19.581
> # ntpq -c as
> ind assID status  conf reach auth condition  last_event cnt
> ===========================================================
>   1 20192  9024   yes   yes  none    reject   reachable  2
>   2 20193  9024   yes   yes  none    reject   reachable  2
> # ntpq
> ntpq> rv 20192
> assID=20192 status=9024 reach, conf, 2 events, event_reach,
> srcadr=taus-idc2.dom1.taus.us.thales, srcport=123,
> dstadr=192.168.58.250, dstport=123, leap=00, stratum=2, precision=-7,
> rootdelay=0.000, rootdispersion=14089.050, refid=172.16.2.5, reach=377,
> unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist,
> keyid=0, ttl=0, offset=-51835.943, delay=2.159, dispersion=9.549,
> jitter=10.021, reftime=cc74ddf3.bd083558  Fri, Sep 12 2008  5:24:19.738,
> org=cc754432.c147ae14  Fri, Sep 12 2008 12:40:34.755,
> rec=cc754466.9b66e174  Fri, Sep 12 2008 12:41:26.607,
> xmt=cc754466.9ad85a70  Fri, Sep 12 2008 12:41:26.604,
> filtdelay=     2.17    2.20    2.16    3.68    4.14    2.25    4.47    2.24,
> filtoffset= -51850. -51846. -51835. -51848. -51831. -51832. -51829. -51846.,
> filtdisp=      7.81    8.80    9.75   10.72   11.70   12.66   13.65   14.59
> ntpq> rv 20193
> assID=20193 status=9024 reach, conf, 2 events, event_reach,
> srcadr=taus-idc1.dom1.taus.us.thales, srcport=123,
> dstadr=192.168.58.250, dstport=123, leap=00, stratum=2, precision=-7,
> rootdelay=0.000, rootdispersion=14089.630, refid=172.16.2.5, reach=377,
> unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=6, flash=400 peer_dist,
> keyid=0, ttl=0, offset=-51822.970, delay=2.200, dispersion=12.060,
> jitter=24.499, reftime=cc7533f1.d8de6ddf  Fri, Sep 12 2008 11:31:13.847,
> org=cc754459.c0418937  Fri, Sep 12 2008 12:41:13.751,
> rec=cc75448d.9bb36a6e  Fri, Sep 12 2008 12:42:05.608,
> xmt=cc75448d.9b19fbd7  Fri, Sep 12 2008 12:42:05.605,
> filtdelay=     2.34    2.64    4.18    3.24    2.71    2.40    2.93    2.20,
> filtoffset= -51856. -51847. -51849. -51851. -51844. -51838. -51840. -51822.,
> filtdisp=      7.81    8.76    9.72   10.69   11.65   12.63   13.59   14.56

The offset is large enough that ntpd would need several DAYS to work it off.

Try setting your clock to a reasonable approximation of the correct time 
before starting ntpd.  ntpd -g should do the job if you are running a 
reasonably recent version.  If your version is too old to support -g, 
then use ntpdate to set the clock before starting ntpd.




More information about the questions mailing list