NTP issues

[Wouter Jagers]

Hi,

Since a week or two I'm having troubles synchronizing NTP clients. Here's the situation:

The gateway machine on my local network acts as a 'local master': it syncs its time with some global ntp servers (out of my control), and all local machines sync their time with the gateway box.

(It's fair to mention that I suspect the problems to have started when this gateway machine had a crash.)

Now the clients will no longer sync, returning the well-known '27 Feb 14:55:01 ntpdate[1619]: no server suitable for synchronization found'.

A rundown from the current info I've gathered:

[client - root] ntpdate localmaster
27 Feb 15:31:27 ntpdate[1747]: no server suitable for synchronization found

--> hmmz.. the server is reachable and there's no firewall/router in between, so something must be wrong with the ntp service

[client - root] ntpdate -d localmaster
27 Feb 15:33:15 ntpdate[1760]: ntpdate version=3.5f; Thu Oct 23 13:37:24 PDT 1997 (6)
transmit(198.141.81.10)
receive(198.141.81.10)
transmit(198.141.81.10)
receive(198.141.81.10)
transmit(198.141.81.10)
receive(198.141.81.10)
transmit(198.141.81.10)
receive(198.141.81.10)
transmit(198.141.81.10)
server 198.141.81.10, port 123
stratum 16, precision -17, leap 11, trust 000
refid [0.0.0.0], delay 0.02675, dispersion 0.00014
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000
originate timestamp: c208a046.22987000 Thu, Feb 27 2003 15:33:42.135
transmit timestamp: c208a02b.aff2d000 Thu, Feb 27 2003 15:33:15.687
filter delay: 0.02791 0.02678 0.02675 0.02719
0.00000 0.00000 0.00000 0.00000
filter offset: 26.44726 26.44664 26.44664 26.44692
0.000000 0.000000 0.000000 0.000000
delay 0.02675, dispersion 0.00014
offset 26.446646

27 Feb 15:33:15 ntpdate[1760]: no server suitable for synchronization found

---> hmmz, the reference time seems to be all zero's, translating to februari 2036.. this is fishy !

[client - root] ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
localmaster.gcc.dhl. 0.0.0.0 16 u 15 64 0 0.00 0.000 16000.0

---> hmmz, stratum 16 ? this would mean the server thinks it's unreliable/not synced ?!

[client - root] ntpq -c as
ind assID status conf reach auth condition last_event cnt
===========================================================
1 22308 8000 yes no

---> So I guess there's a definate problem with our local master.

[client - root] ntpq -p localmaster
remote refid st t when poll reach delay offset disp
==============================================================================
globalntp1 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0
globalntp2 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0

---> If I'm right, this reports the global servers to be stratus 16, too. However, I got confirmation from their admins saying "stratum 1, offset 0.006895, synch distance 0.00545, refid 'GPS'"

Shouls anyone know what to do/check next, that would be greatly appreciated !!

Thanks

Wouter

[John Bolene]

sounds like your master cannot reach its time sources and has made itself unreliable

what does it show in syslog for localmaster? Is it OK with time sync?

I would cycle xntpd on the localmaster and check syslog to see if it connects with the globalmasters.

[Wouter Jagers]

that's the strange thing.. the local master doesn't seem to notice anything being wrong.

It can reach the global servers perfectly, and it doesn't complain about a lack of servers suitable for syncing..

Some more outputs:

[localmaster - root] ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
global1 0.0.0.0 16 u 13 64 0 0.00 0.000 16000.0
global2 0.0.0.0 16 u 13 64 0 0.00 0.000 16000.0

[localmaster - root] ntpq -p global1
remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(0) .GPS. 0 - 16 64 377 0.00 0.000 3.37
+global2 .GPS. 1 - 42 64 377 147.50 0.250 4.82
+global3 .GPS. 1 - 36 64 377 194.75 0.125 4.84

So I stop xntpd and run a quick ntpdate -d global1:

28 Feb 05:30:50 ntpdate[25009]: ntpdate version=3.5f; Mon Jun 9 14:50:06 PDT 1997 (2)
transmit(198.141.252.66)
receive(198.141.252.66)
transmit(198.141.252.66)
receive(198.141.252.66)
transmit(198.141.252.66)
receive(198.141.252.66)
transmit(198.141.252.66)
receive(198.141.252.66)
transmit(198.141.252.66)
server 198.141.252.66, port 123
stratum 1, precision -9, leap 00, trust 000
refid [GPS], delay 0.04649, dispersion 0.00021
transmitted 4, in filter 4
reference time: c209647a.026e978d Fri, Feb 28 2003 5:30:50.009
originate timestamp: c209647a.efced916 Fri, Feb 28 2003 5:30:50.936
transmit timestamp: c209647a.880a0000 Fri, Feb 28 2003 5:30:50.531
filter delay: 0.04733 0.04677 0.04691 0.04649
0.00000 0.00000 0.00000 0.00000
filter offset: 0.308496 0.308076 0.308150 0.308382
0.000000 0.000000 0.000000 0.000000
delay 0.04649, dispersion 0.00021
offset 0.308382

28 Feb 05:30:50 ntpdate[25009]: adjust time server 198.141.252.66 offset 0.308382 sec

And when I start xntpd again:
[localmaster - root] /sbin/init.d/xntpd start
28 Feb 05:30:58 ntpdate[25032]: step time server 10.1.5.2 offset 0.308173 sec

Strange, aye ?

[T G Manikandan]

Just check this doc

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000063204535

[Wouter Jagers]

Another strange thing: When I do an "ntpq -p" on my localmaster, I get this:

[localmaster - root] ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
global1 0.0.0.0 16 u 22 64 0 0.00 0.000 16000.0
global2 0.0.0.0 16 u 21 64 0 0.00 0.000 16000.0

And when I do a "ntpq -p global2":

[localmaster - root] ntpq -p global2
remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(0) .GPS. 0 - 30 64 377 0.00 0.000 3.35
+global1 .GPS. 1 - 11 64 377 147.50 0.250 4.82
+global3 .GPS. 1 - 20 64 377 208.25 -0.125 4.81

How come these global servers report stratus 16 to me and stratus 1 to other places ?

[John Bolene]

that last output says ntpdate when you restarted xntpd?

there should be a xntpd display in syslog

maybe your xntpd points to ntpdate or something else is starting ntpdate like cron

the 2 kinds of ntp updates should not be running at the same time

[Wouter Jagers]

If I'm right, xntpd always starts out by executing one ntpdate to step the time close enough to real time.
Then it starts using the daemon to make adjustments..

What I don't get is that my localmaster thinks global1 is at stratum 16, while global2 knows it's actually at stratum 1 ?!?

[Wouter Jagers]

T.G: thanks for the link also, however I've read about every ntp configuration and troubleshooting doc online, including the RFC :-)

But inthere I only learn that the outputs I get are contradictory..

[John Bolene]

-------
If I'm right, xntpd always starts out by executing one ntpdate to step the time close enough to real time.
Then it starts using the daemon to make adjustments..
--------


Not that I know of. If it is more than 1000 seconds off, it refuses to stay running.

On both my 10.20 and 11.0 machines when starting xntpd, I get

xntpd version=3.5f; Thu Oct 23 13:37:00 PDT 1997 (6)
tickadj = 625, tick = 10000, tvu_maxslew = 61875
precision = 10 usec

then after 5 minutes

synchronized to 172.20.4.82, stratum=4



What OS version are you running?

[Wouter Jagers]

The master is a 10.20 ..

By the way I checked, and the init script for xntp first does a ntpdate -b and then starts xntpd

[Wouter Jagers]

mine does all that, except getting synchronized after 5 minutes ;-)

[Edgar Avila]

Look at http://www.ntp.org/ntpfaq/NTP-s-config.htm , after 6.2.6.2 .
Maybe you have congestion on your network. That could be the reason for the lack of '*' on your ntpq's indicating no suitable or alternate server.

[Wouter Jagers]

Oops, did I not close up this one ? It was solved ages ago.. shame on me !

In short: I wrote the config file from scratch, and all problems were gone.

Thanks to all !