Trace ntp sanity checks?
li...@stihl.de
we are having problems to synchronize linux & aix ntp-clients to a
ntp-broadcastserver.
ntp-broadcast-packets are received by the clients, but all servers are
rejected by the clients after a few minutes.
we found out, that the ntp-servers do not pass the sanity-checks on the
clients and get probably rejected because of that.
How can we further track down which of the sanity-checks fails and why...
Thanks in advance
Frank
___________________________________________________________________
This E-Mail is confidential. If you are not the intended recipient, you must
not copy, disclose or use its contents. If you have received it in error,
please inform us immediately by return E-Mail and delete the document.
Diese E-Mail ist vertraulich. Wenn Sie nicht der rechtmäßige Empfänge
r sind,
dürfen Sie den Inhalt weder kopieren, verbreiten noch benutzen. Sollten S
ie
diese E-Mail versehentlich erhalten haben, senden Sie sie bitte an uns
zurück und löschen sie anschließend.
Cet e-mail est confidentiel. Si vous n'etes pas le destinataire de ce
message, vous ne devez pas copier, divulguer ou utiliser le contenu. Si vous
avez recu cet e-mail par erreur, veuillez nous informer en retournant ce
message a l'expediteur et detruisez-le.
Esta mensagem, e qualquer de seus anexos, eh confidencial e privilegiada.
Caso voce nao seja o destinatario, nao esta autorizado a reproduzir ou
divulgar a terceiros o conteudo desta mensagem e de qualquer anexo da mesma
e deve apagar com os seus respectivos anexos.
___________________________________________________________________
ANDREAS STIHL AG & Co. KG
Kommanditgesellschaft mit Sitz in Waiblingen, HRA 260269, Amtsgericht Stutt
gart
Persönlich haftende Gesellschafter: Hans Peter Stihl und STIHL Aktiengese
llschaft
mit Sitz in Waiblingen, HRB 263722, Amtsgericht Stuttgart
Vorstand der STIHL AG: Dr. Bertram Kandziora (Vorstandsvorsitzender),
Dr. Peter Dürolf, Jürgen Steinhauser, Wolfgang Zahn
Vorsitzender des Aufsichtsrats der STIHL AG: Hans Peter Stihl
Martin Burnicki
li...@stihl.de wrote:
> Hello,
>
> we are having problems to synchronize linux & aix ntp-clients to a
> ntp-broadcastserver.
>
> ntp-broadcast-packets are received by the clients, but all servers are
> rejected by the clients after a few minutes.
>
> we found out, that the ntp-servers do not pass the sanity-checks on the
> clients and get probably rejected because of that.
>
> How can we further track down which of the sanity-checks fails and why...
If the NTP on the client has been compiled with debug option then you can
run ntpd with the -d option ans see what it prints on the console.
Otherwise, if the broadcast server is listed in the output of "ntpq -p" you
can see details of the server association using the following commands.
Print billboard of the associations:
# ntpq -p
remote refid st t when poll reach delay offset jitter
=========================================================================
*gateway.py.mein .GPSi. 1 u 34 64 377 0.148 -0.011 0.362
Find out the association IDs:
# ntpq -c as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 41266 9614 yes yes none sys.peer reachable 1
In this case the association ID is 41266. Use the ID to find more details on
the association:
# ntpq -c "rv 41266"
assID=41266 status=9614 reach, conf, sel_sys.peer, 1 event, event_reach,
srcadr=gateway.py.meinberg.de, srcport=123, dstadr=172.16.3.27,
dstport=123, leap=00, stratum=1, precision=-18, rootdelay=0.000,
rootdisp=0.580, refid=GPSi, reach=377, unreach=0, hmode=3, pmode=4,
hpoll=6, ppoll=6, flash=00 ok, keyid=0, ttl=0, offset=-0.659,
delay=0.163, dispersion=2.055, jitter=0.307,
reftime=cb00fb6b.000192a7 Wed, Dec 5 2007 11:26:51.000,
org=cb00fb71.b05ff1d8 Wed, Dec 5 2007 11:26:57.688,
rec=cb00fb71.b0814599 Wed, Dec 5 2007 11:26:57.689,
xmt=00000000.00000000 Thu, Feb 7 2036 7:28:16.000,
filtdelay= 0.18 0.19 0.16 0.23 0.20 0.23 0.19 0.21,
filtoffset= -0.42 -0.61 -0.66 -0.76 -0.88 -1.04 -1.14 -1.06,
filtdisp= 0.01 1.00 1.97 2.96 3.92 4.90 5.86 6.85
You should not interpret the output above. It's just a quick test to show
how to proceed.
If you post your output of the ntpq -p and ntpq -c "rv ..." commands here
then we may be able to help.
And, the versions of NTP on the server and on the clients might be
interesting ...
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
li...@stihl.de
i already recorded the output you asked me for some days ago:
ntpq -p
remote refid st t when poll reach delay offset
jitter
*LOCAL(0) LOCAL(0) 10 l 63 64 377 0.000 0.000
0.004
master1 10.212.70.11 4 - 32 64 377 0.447 547212. 69.790
master2 10.212.70.12 4 - 3 64 377 0.306 547235. 73.665
(the high offset is because the ntp-client lost synchronization a long
time ago)
ntpq> rv 8773
assID‡73 status 14 reach, 1 event, event_reach,
srcadrmaster1, srcport 3, dstadr0.0.0.0,
dstport 3, leap , stratum4, precision0, rootdelay0.000,
rootdispersion0.000, refid .248.128.74, reach77, unreach0,
hmode8, pmode5, hpoll6, ppoll6, flash ok, keyid0, ttl
0,
offsetT9217.462, delay0.447, dispersion™7.039, jitterX.874,
reftimeÊf7c1f0.7e353eeb Wed, Nov 28 2007 11:31:12.493,
orgÊf7c1f0.7e353eeb Wed, Nov 28 2007 11:31:12.493,
recÊf7bfcb.44055fbb Wed, Nov 28 2007 11:22:03.265,
xmtÊe54d0b.8746ed24 Wed, Nov 14 2007 11:31:39.528,
filtdelay 0.45 0.45 0.45 0.45 0.45 0.45 0.45
0.45,
filtoffset 549217. 549210. 549199. 549186. 549169. 549153. 549132.
549121.,
filtdisp 1000.48 1000.96 1001.44 1001.92 1002.40 1002.88 1003.36
1003.84
i already tried to interpret this, but the only thing i figured out is
that the zero in 1014 means that the client is rejected because of
failed sanity checks.
many clients showing the problem are running ntp-version 4.2...@1.1196-r
on linux.
i once heard that the server is a Tardis product for windows - but i
cannot supply details about that.
the ntp-server and the network are not managed by myself.
because of that i would like to have enough knowledge of ntp to analyze
such problems on the client side (as far as possible).
i had these problems quite frequently, sometimes often, sometimes not at
all...
is there a way to trace down which sanity-check failed?
thanks a lot
Frank
-----Original Message-----
From: DE/SYS Routing - Linux, Team
Sent: Wednesday, December 05, 2007 11:50 AM
To: D1/OBT-ho Hornung, Frank; D1/OBT-ha Harle, Christoph
Subject: FW: Trace ntp sanity checks?
-------------------------------------------
From: questions-bounc...@lists.ntp.org on behalf of Martin
Burnicki[SMTP:MARTIN....@MEINBERG.DE]
Sent: Wednesday, December 05, 2007 11:32:04 AM
To: ques...@lists.ntp.org
Subject: Re: Trace ntp sanity checks?
Auto forwarded by a Rule
Frank,
li...@stihl.de wrote:
> Hello,
>
> we are having problems to synchronize linux & aix ntp-clients to a
> ntp-broadcastserver.
>
> ntp-broadcast-packets are received by the clients, but all servers are
> rejected by the clients after a few minutes.
>
> we found out, that the ntp-servers do not pass the sanity-checks on
the
> clients and get probably rejected because of that.
>
> How can we further track down which of the sanity-checks fails and
why...
If the NTP on the client has been compiled with debug option then you
can
run ntpd with the -d option ans see what it prints on the console.
Otherwise, if the broadcast server is listed in the output of "ntpq -p"
you
can see details of the server association using the following commands.
Print billboard of the associations:
# ntpq -p
remote refid st t when poll reach delay offset
jitter
*gateway.py.mein .GPSi. 1 u 34 64 377 0.148 -0.011
0.362
Find out the association IDs:
# ntpq -c as
ind assID status conf reach auth condition last_event cnt
1 41266 9614 yes yes none sys.peer reachable 1
In this case the association ID is 41266. Use the ID to find more
details on
the association:
# ntpq -c "rv 41266"
assIDA266 status–14 reach, conf, sel_sys.peer, 1 event, event_reach,
srcadrgateway.py.meinberg.de, srcport 3, dstadr 2.16.3.27,
dstport 3, leap , stratum1, precision-18, rootdelay0.000,
rootdisp0.580, refidGPSi, reach77, unreach0, hmode3, pmode
4,
hpoll6, ppoll6, flash ok, keyid0, ttl0, offset-0.659,
delay0.163, dispersion2.055, jitter0.307,
reftimeË00fb6b.000192a7 Wed, Dec 5 2007 11:26:51.000,
orgË00fb71.b05ff1d8 Wed, Dec 5 2007 11:26:57.688,
recË00fb71.b0814599 Wed, Dec 5 2007 11:26:57.689,
xmt 000000.00000000 Thu, Feb 7 2036 7:28:16.000,
filtdelay 0.18 0.19 0.16 0.23 0.20 0.23 0.19
0.21,
filtoffset -0.42 -0.61 -0.66 -0.76 -0.88 -1.04 -1.14
-1.06,
filtdisp 0.01 1.00 1.97 2.96 3.92 4.90 5.86
6.85
You should not interpret the output above. It's just a quick test to
show
how to proceed.
If you post your output of the ntpq -p and ntpq -c "rv ..." commands
here
then we may be able to help.
And, the versions of NTP on the server and on the clients might be
interesting ...
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
ques...@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Harlan Stenn
linux> ntpq -p
remote refid st t when poll reach delay offset jitter
==========================================================================
*LOCAL(0) LOCAL(0) 10 l 63 64 377 0.000 0.000 0.004
master1 10.212.70.11 4 - 32 64 377 0.447 547212. 69.790
master2 10.212.70.12 4 - 3 64 377 0.306 547235. 73.665
You are sync'd to your local machine, and your 2 "master" machines are now
far enough out that your local ntpd will not talk to them.
You have been thru:
http://support.ntp.org/bin/view/Support/DesigningYourNTPNetwork
and
http://support.ntp.org/bin/view/Support/ConfiguringNTP
right?
H
--
http://ntpforum.isc.org - be a member!
David Woolley
li...@stihl.de wrote:
> *LOCAL(0) LOCAL(0) 10 l 63 64 377 0.000 0.000
> 0.004
One would normally not serve time from a machine synchronised by
broadcasts. Defining a local clock driver serves no useful purpose
on a pure client (and should only be done with full understanding on
a server). Too many packaging of ntpd configure a local clock driver
in their sample configuration.
Problems arise if the local clock is seen as the best available time source,
locally, or downstream. Both locally and downstream, the clock failure
will never be detected.
The software clock will retain is last known phase and frequency corrections,
even if ntpd fails to get valid replies. Local clock is only used if it
is important that downstream clients see the same, free running, time, rather
than slowly diverge from each other.
> master1 10.212.70.11 4 - 32 64 377 0.447 547212. 69.790
Note that you are halfway to the drop dead error. If ntpd accepts an
offset less than twice this, it will commit suicide.
Hal Murray
>in their sample configuration.
Does anybody know why that got started?
What urban legend do we have to stomp out before that practice will go away?
--
These are my opinions, not necessarily my employer's. I hate spam.
Richard B. Gilbert
> Too many packaging of ntpd configure a local clock driver
>
>>in their sample configuration.
>
>
> Does anybody know why that got started?
>
> What urban legend do we have to stomp out before that practice will go away?
>
>
It's no worse than the people who just want to "synchronize clocks to
each other" without regard to what time it is. The local clock driver
is harmless as long as people configure it to stratum 10!
Steve Kostecke
>ATTRIBUTION DELETED wrote:
>
>>Too many packaging of ntpd configure a local clock driver in their
>>sample configuration.
>
> Does anybody know why that got started?
The sample configuration files attempt to include as many configuration
options as possible. Unfortunately there is often insufficient, or just
plain misleading, explanation of what these options should be used for.
> What urban legend do we have to stomp out before that practice will go
> away?
The problem is that the distribution does not contain good sample
configuration files. There should be sample configurations for:
Pool client
Leaf node
unicast
broadcast
multicast
manycast
LAN server
unicast
broadcast
multicast
manycast
and so on.
--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/
David Woolley
Richard B. Gilbert <rgilb...@comcast.net> wrote:
> The local clock driver
> is harmless as long as people configure it to stratum 10!
This very thread demonstrates a case where it wasn't harmless!
What has happened here appears to be that it has provided a much more
attractive indication of the time than proper time sources. I'm not
exactly sure why that is in this case, but, in other cases people have
had more local clock derived sources than real sources, and, because
the reference implementation claims zero root delay and zero root
dispersion (because it assumes that the local clock is being disciplined
by some other means, rather than free running), an upstream local clock can
have a very low apparent error band, so it can be quite difficult for other
sources to fall within the same cluster.
The other basic problem is that downstream nodes don't receive any indication
that they are disconnected from real time, whereas an alarm condition
would be signalled by a server without a local clock driver.
Note that using stratum 10 doesn't prevent these problems, it simply
stops nodes that more than about 2 hops downstream from having problems
from that particular local clock driver; it limits the area subject to
harm.
As to the urban myth. Whilst a lot of it is simply copy and paste
programming, I think there is a significant myth that, without the local
clock driver, the software clock will revert to its natural frequency,
when it loses all time sources.
li...@stihl.de
Hi,
thank you very much for your responses.
summary:
you see no reason, why a ntp-client that does not serve its time to
someone else should have a local clock configured?
did i get this right?
i will change my configuration and try that.
does anyone of you have details regarding my original question:
How can i find out which of the sanity-checks failed?
regards
Frank
-----Original Message-----
From: DE/SYS Routing - Linux, Team
Sent: Friday, December 07, 2007 9:16 AM
To: D1/OBT-ho Hornung, Frank; D1/OBT-ha Harle, Christoph
Subject: FW: Trace ntp sanity checks?
-------------------------------------------
From: questions-bounc...@lists.ntp.org on behalf of
da...@ex.djwhome.demon.co.uk.invlid[SMTP:DA...@EX.DJWHOME.DEMON.CO.UK.IN
VLID]
Sent: Friday, December 07, 2007 8:56:31 AM
To: ques...@lists.ntp.org
Subject: Re: Trace ntp sanity checks?
Auto forwarded by a Rule
In article <4758C2A7...@comcast.net>,
> The local clock driver
_______________________________________________
Steve Kostecke
> you see no reason, why a ntp-client that does not serve its time to
> someone else should have a local clock configured?
> did i get this right?
The only reason to use the Undisciplined Local Clock (127.127.1.x) is on
an ntpd which must be able to serve time to others even when there are
no real time sources available.
The Undiciplined Local Clock is not a time source and does nothing to
keep ntpd synchronised.
> does anyone of you have details regarding my original question:
> How can i find out which of the sanity-checks failed?
I don't think you can.
> -----Original Message-----
> [---=| TOFU protection by t-prot: 100 lines snipped |=---]
Oh, that's what you were replying to.
Danny Mayer
>> does anyone of you have details regarding my original question:
>> How can i find out which of the sanity-checks failed?
>
> I don't think you can.
if the sanity-checks failed it should put out a hex value containing the
errors detected. You then have to look at the code to see what those
bits mean. We shoulf be making this easier. What was the error that you
got? Sorry but I haven't been following this.
Danny
Martin Burnicki
Shouldn't this be visible via the flash bits displayed by
ntpq -c "rv <assId>" ?
I had asked the OP to post the output of the command. However, the output
was truncated. Here's a quote:
> ntpq> rv 8773
> assID?73 status 14 reach, 1 event, event_reach,
> srcadrmaster1, srcport 3, dstadr0.0.0.0,
> dstport 3, leap
The rest of the output which should be including the "flash" bits is missing
here.
li...@stihl.de
flash-value says:
flash ok
here again, the output:
ntpq> rv 8773
assID‡73 status 14 reach, 1 event, event_reach,
srcadrmaster1, srcport 3, dstadr0.0.0.0,
dstport 3, leap , stratum4, precision0, rootdelay0.000,
rootdispersion0.000, refid .248.128.74, reach77, unreach0,
hmode8, pmode5, hpoll6, ppoll6, flash ok, keyid0, ttl
0,
offsetT9217.462, delay0.447, dispersion™7.039, jitterX.874,
reftimeÊf7c1f0.7e353eeb Wed, Nov 28 2007 11:31:12.493,
orgÊf7c1f0.7e353eeb Wed, Nov 28 2007 11:31:12.493,
recÊf7bfcb.44055fbb Wed, Nov 28 2007 11:22:03.265,
xmtÊe54d0b.8746ed24 Wed, Nov 14 2007 11:31:39.528,
filtdelay 0.45 0.45 0.45 0.45 0.45 0.45 0.45
0.45,
filtoffset 549217. 549210. 549199. 549186. 549169. 549153. 549132.
549121.,
filtdisp 1000.48 1000.96 1001.44 1001.92 1002.40 1002.88 1003.36
1003.84
thanks in advance.
regards
Frank
-----Original Message-----
From: DE/SYS Routing - Linux, Team
Sent: Monday, December 10, 2007 10:17 AM
To: D1/OBT-ho Hornung, Frank; D1/OBT-ha Harle, Christoph
Subject: FW: Trace ntp sanity checks?
-------------------------------------------
From: questions-bounc...@lists.ntp.org on behalf of Martin
Burnicki[SMTP:MARTIN....@MEINBERG.DE]
Sent: Monday, December 10, 2007 9:52:56 AM
To: ques...@lists.ntp.org
Subject: Re: Trace ntp sanity checks?
Auto forwarded by a Rule
Danny Mayer wrote:
Martin
--
Martin Burnicki
_______________________________________________
Steve Kostecke
> flash-value says:
> flash
>
> here again, the output:
>
> ntpq> rv 8773
> assID..73 status..14 reach, 1 event, event_reach,
> srcadr=master1, srcport..3, dstadr=0.0.0.0,
> dstport..3, leap
> rootdispersion=0.000, refid...248.128.74, reach77, unreach=0,
> hmode=8, pmode=5, hpoll=6, ppoll=6, flash=0,
Actually, the flash value is 0. It was wrapped to the next line.
BTW: the data that you pasted is a bit garbled: it contains
non-printable characters in place of some of the information.
li...@stihl.de
i tried removing the local clock driver from my configuration but it did
not help.
The time servers are rejected after a few minutes...
> Actually, the flash value is 0. It was wrapped to the next line.
>
> BTW: the data that you pasted is a bit garbled: it contains
> non-printable characters in place of some of the information.
sorry for the garbled text. I do not understand how this could happen.
this time i checked that this mail is txt-only and that everything i
paste has a planintext-source...
again the output:
ntpq> rv 8773
assID‡73 status 14 reach, 1 event, event_reach,
srcadrmaster1, srcport 3, dstadr0.0.0.0,
dstport 3, leap , stratum4, precision0, rootdelay0.000,
rootdispersion0.000, refid .248.128.74, reach77, unreach0,
hmode8, pmode5, hpoll6, ppoll6, flash ok, keyid0, ttl
0,
offsetT9217.462, delay0.447, dispersion™7.039, jitterX.874,
reftimeÊf7c1f0.7e353eeb Wed, Nov 28 2007 11:31:12.493,
orgÊf7c1f0.7e353eeb Wed, Nov 28 2007 11:31:12.493,
recÊf7bfcb.44055fbb Wed, Nov 28 2007 11:22:03.265,
xmtÊe54d0b.8746ed24 Wed, Nov 14 2007 11:31:39.528,
filtdelay 0.45 0.45 0.45 0.45 0.45 0.45 0.45
0.45,
filtoffset 549217. 549210. 549199. 549186. 549169. 549153. 549132.
549121.,
filtdisp 1000.48 1000.96 1001.44 1001.92 1002.40 1002.88 1003.36
1003.84
does this give any hints which sanity-check failed?
regards
Frank
Martin Burnicki
li...@stihl.de wrote:
> again the output:
>
> ntpq> rv 8773
> assID 73 status 14 reach, 1 event, event_reach,
> srcadrmaster1, srcport 3, dstadr0.0.0.0,
> dstport 3, leap
You see, it's garbage again. It's hard to keep up under this circumstances.
Your domain name let's me assume you are located in Germany. Maybe you can
give me a phone call tomorrow so we may have a better chance to see what's
going wrong.
I'll send you my phone number via private mail.
Per Hedeland
<martin....@meinberg.de> writes:
>
>li...@stihl.de wrote:
>> again the output:
>>
>> ntpq> rv 8773
>> assID‡73 status 14 reach, 1 event, event_reach,
>> srcadrmaster1, srcport 3, dstadr0.0.0.0,
>> dstport 3, leap
>
>You see, it's garbage again. It's hard to keep up under this circumstances.
Actually, his raw text isn't garbled, it's just that his headers falsely
claim that the message is quoted-printable-encoded, so your reader
software (and mine, unless I tell it not to) kindly takes all the =xx
sequences and translates them into some random binary byte.
--Per Hedeland
p...@hedeland.org
Hal Murray
>> assID‡73 status 14 reach, 1 event, event_reach,
>> srcadrmaster1, srcport 3, dstadr0.0.0.0,
>> dstport 3, leap
>
>You see, it's garbage again. It's hard to keep up under this circumstances.
My copy wasn't garbled.
It looked like this:
assID=8773 status=1014 reach, 1 event, event_reach,
srcadr=master1, srcport=123, dstadr=0.0.0.0,
dstport=123, leap=00, stratum=4, precision=0, rootdelay=0.000,
But this header line looks interesting:
Content-Transfer-Encoding: quoted-printable
I'm reading the usenet side. My newsreader is probably dumb enough
to ignore that line. I don't know if it's even legal in usenet headers
or just got passed through by the email=>usenet gateway.
Martin Burnicki
FYI, I've had a phone call with the OP and he told me that the broadcasting
server is in turn a broadcast client of a Windows machine running Tardis.
We've agreed this is a poor setup and the hierarchy should be redesigned.