[ntp:questions] NTP shows all servers in condition "reject"

David Woolley david at ex.djwhome.demon.co.uk.invalid
Wed Jun 11 21:43:50 UTC 2008


Ronny Egner wrote:

This posting is broken because it has this header:

Content-Transfer-Encoding: quoted-printable

but doesn't actually quoted-printable encode the body.  That means that 
things go badly wrong whenever there is an "=" sign.  I'll therefore 
quote the message source here, which means I'll have to put the quote 
marks in by hand. For the benefit of other people with MIME capable 
newsreaders, I won't trim the quoting in the way I normally would. (More 
at foot - theory about gateway bug.)


 > Steve Kostecke schrieb:
 > > On 2008-06-09, Ronny Egner <Ronny.Egner at siv.de> wrote:

 > >> The problem i am facing occur on all my new 6 servers
 > >> which are all equally configured (Red Hat AS 4 U4, 64-bit).
 > >
 > > Are they VMs?

 > No, physical machines.


 > >> server solaris-server
 > >> server windows-dc-serverA
 > >> server windows-dc-serverB
 > >
 > > You can reduce the initial sync time from ~ 5 minutes to ~15-20
 > > seconds

 > > by appending 'iburst' to your server lines.

 > I will try that.

 > >> 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?

 > No they are not reacable over a VPN. They are routed through the network
 > (quite complicated; but there is no WAN part inbetween).

 > I dont know much about the windows servers. The customer told me i can
 > use them for time synchronization - so i did it because the network i
 > highly protected from the outside lan.


 > >> ntpq> rv 39492
 > >> assID=39492 status=9014 reach, conf, 1 event, event_reach,
 > >> srcadr=solaris-server, srcport=123, dstadr=10.x.y.z, dstport=1
23, leap=00,
 > >> stratum=5, precision=-18, rootdelay=31.601, rootdispersion=103
16.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.
 > >
 > Could you please post the solaris-server 'ntpq -p' billboard from (in a

 > > condensed format as shown above)?

 > This is from the solaris box:

 > ntpq> version
 > ntpq 3-5.93e Mon Sep 20 15:45:42 PDT 1999 (1)

 > (it is a Solaris 10)


 > ntpq> peer
 >       remote           refid      st t when poll reach   delay   offset
 >     disp
=========================
=========================
=========================
===
 > #windows-dc-serverA  10.x.v.1  4 u  215 1024  377     0.31    0.888    3.
 > 42
 > +windows-dc-serverB  10.x.v.1  4 u  509 1024  377     0.44   -1.445    2.
 > 61


 > Both windows server seem to get ther ntp data from the host 10.x.v.1.


 > ntpq> as
 > ind assID status  conf reach auth condition  last_event cnt
=========================
=========================
=========
 >    1 29028  9514   yes   yes  none dist.peer   reachable  1

Association 1 is being rejected because the root dispersion is too high.

 >    2 29029  9414   yes   yes  none   synchr.   reachable  1


 > status=9514 reach, conf, sel_sys.peer, hi_dist, 1 event, event_reach

Note the hi_dist flag.  That's telling you that the rootdispersion is 
too high, and the server is therefore unacceptable.

 > srcadr=windows-dc-serverA, srcport=123, dstadr=10.x.y.4,
 > dstport=123, keyid=0, stratum=4, precision=-6, rootdelay=31.25,

 > rootdispersion=10120.09, refid=10.x.v.1, delay=0.31, offset=0.89,

rootdispersion, and therefore root distance, is greater than the maximum 
allowed 1 second.

 > dispersion=3.42, reach=377, valid=8, hmode=3, pmode=4, hpoll=
 > 10,
 > ppoll=10, leap=00, flash=0x0<OK>,


 > status=9414 reach, conf, sel_sync, 1 event, event_reach
 > srcadr=windows-dc-serverB, srcport=123, dstadr=10.x.y.4,
 > dstport=123, keyid=0, stratum=4, precision=-6, rootdelay=31.25,

 > rootdispersion=10113.86, refid=10.x.v.1, delay=0.44, offset=-1.45
,

This root dispersion is also more than 9 seconds greater than permitted.

 > dispersion=2.61, reach=377, valid=8, hmode=3, pmode=4, hpoll=
 > 10,
 > ppoll=10, leap=00, flash=0x0<OK>,


Basically, you should never use W32Time to serve time to a real NTP 
client, although I still don't understand why Solaris isn't reporting 
stratum 16.  Did you do anything to force the use of that server?

In this context, W32Time reports a true root dispersion when 
unsychronised, including being "synchronised" to its local clock, 
whereas ntpd should go into alarm in the first case, and gives an 
extremely optimistic distance in the second case.


 > Thanks for your help.
 > --
 > Mit freundlichen Grüßen

 > Ronny Egner
 > Diplom-Ingenieur (BA)
 > Systeme & Service
 > Oracle DBA

 > Telefon: +49 381 2524-422
 > Telefax: +49 381 2524-399


 > SIV.AG - Service für Informationsverarbeitung AG
 > Hauptsitz: Konrad-Zuse-Str. 1, 18184 Roggentin
 > Handelsregister: Amtsgericht Rostock, HRB 8677, Ust.-IdNr.: DE 137477226
 > Vorstand: Jörg Sinnig (Vorsitzender), Andreas Lehmann, Arno Weichbrodt
 > Aufsichtsratsvorsitzender: Thomas Huth

 > *************************************************************************

 > Aus Rechtsgründen ist die in dieser E-Mail gegebene Information nicht
 > rechtsverbindlich. Eine rechtsverbindliche Bestätigung reichen wir
 > Ihnen auf Anforderung in schriftlicher Form nach. Diese Nachricht ist
 > ausschließlich für den Adressaten oder dessen Vertreter bestimmt.

 > The information contained in this email is not legally binding.
 > At your request, we will provide you with a legally binding confirmation
 > in written form. This message is intended solely for the addressee,
 > entity to which the email is addressed or the authorised agent.

The entity to which this is addressed, is, of course, the whole universe.

 > *************************************************************************


(The mail problem may well be with the gateway.  This list isn't really 
a mailing list; it is really a newsgroup, and the gateway provides a 
convenience for accessing the newsgroup where firewalls on unenlightened 
ISPs make accessing the group difficult.  On USENET discussion groups, 
binary attachments are strictly forbidden (they are abused to transmit 
large files, which often violate copyright), so, although cryptographic 
signatures are actually tolerated, the gateway has stripped the 
signature.  It is possible that, in doing so, it has failed to copy the 
rest of the message in a fully transparent manner.

I wonder if the reason that the original didn't make it onto USENET is 
related.)





More information about the questions mailing list