ntp confusion

[Charles Holland]

This weekend (when else other than a 3 day holiday weekend) we have done a MASSIVE change in our data center. Host names, IP's, converted a database, re-worked anything that wasn't nailed down. But I have a problem that just doesn't seem possible.

I only have 3 entries in my ntp.conf file. 2 servers and one peer, as shown below.

server 210.0.2.4
server 210.0.2.2
peer 210.0.2.1

Yet after a while, say 10 minutes, I get this kind of display from an ntpq -p command.....

remote refid st t when poll reach delay offset disp
==============================================================================
*210.0.2.4 192.5.41.41 2 u 447 512 377 0.24 4.838 0.79
+210.0.2.2 192.5.41.40 2 u 489 512 377 0.27 -4.934 0.49
+210.0.2.1 210.0.2.4 3 u 343 512 376 0.55 -5.641 4.20
+210.0.2.103 210.0.2.4 3 u 226 512 377 1.42 5.569 4.15
-210.0.2.7 210.0.2.2 3 u 445 512 376 1.31 -31.125 4.14
+210.0.2.6 210.0.2.4 3 u 274 512 377 0.38 -2.574 2.23
+210.0.2.5 210.0.2.4 3 u 271 512 377 0.61 0.583 2.47
+210.0.2.102 210.0.2.4 3 u 203 512 377 2.37 -4.137 3.98

Now the first 3 entries correspond to the 3 entries in the ntp.conf file. The other 5 entries are coming from I have no idea. They are all valid IP's on our private network that goes between machines, but they aren't in the ntp.conf file. So why they are showing really has me puzzled.

Of 10 machines 8 are working fine and two have the same symtoms as above. Any ideas would be appreciated.... Really strange. FYI the two are 2 of four systems running HPUX 11.11 and the other two are running fine. The other 6 are 5 HPUX 11.00 and one SuSE Linux. Like I said everyone else is happy.

[Andrew Cowan]

This looks to me as though the "other" machines listed are running ntp and broadcasting an invitation to sync from them. Have you checked how their "/etc/ntpd.conf" files are configured? You should pay particular attention to stratum levels as this server maybe set lower than the others.

The good news is that the ntpd is sync'd with your first preferred choice "0.2.4".

[Bharat Katkar]

Hi,
Refer this link.
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=550229
Hope that helps.
Regards,

[Bill Hassell]

This is most likely due to the use of the obsolete concept of peers. Back in the days of modem networks, peers made some sense but with LANs, just stay with the NTPclient -> NTPserver concept. A quick browse of www.ntp.org about peers caused brain-pain so I'd just take them out of you ntp.con files.

If you're looking for a fallback, a common way to do this is with the local clock. Just add this to your local NTP servers:

server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10 # backup clock (internal)

This tells NTP on this machine to resort to using the internal clock when all servers above startum 10 are unreachable.

[Rick Garland]

One option is to configure your /etc/ntp.conf file with only the ntp sources you want to communicate with.

Example, the only entries would be
server 210.0.2.4
server 210.0.2.2
peer 210.0.2.1

There would be no other entries in the file. You would not have the LOCAL clock, you would not be broadcasting, no driftfile, etc. But it will keep time.

[Charles Holland]

It has taken a while but I have been able to construct the attached docment.

Andrew:
Only one server broadcasting and it is to a "public" IP address range.

Bharat:
Deep link... but not much help

Bill:
It was my understanding that the purpose of "peers" was to maintain time between non-server machines should your machines that get the time from the internet are not available.

Rick:
Sounds good, except by broadcast is how we keep windows machines sync'd.

Hope the attachment isn't to confusing.

[Bill Hassell]

That's correct about peers but what you then have is a sort of consensus about time. What is really needed is a single source of time which can be your primary server that talks to the Internet. If the connection goes down, then the localclock becomes the source...it isn't going to drift very far over a few days.

The design of NTP is that it always ensures that there are 86400 seconds per day. So if a reference clocks go wacko and all say that the time is 25 minutes in the future or past, your server will ignore the reference clocks and freewheel to prevent any jump in time. Same with loss of the clocks. All your machines will sync on your server so that everyone has the same time. When the reference clocks are back, the local server will slowly adjust at fractions of a second until external sync is within 128ms. (note that you should have several external clock sources for reliability, somewhere between 3 and 6--see www.ntp.org for a bunch of sources. HP has one: ntp-cup.external.hp.com). Note also that your server should have the export NTPDATE_SERVER= setup. The reason is that on reboot, the time will be jumped to the correct time before anything important is started, something like: export NTPDATE_SERVER=tock.usno.navy.mil

[Rick Garland]

One more note to add.

Do sync with multiple stratum 1 servers. If for some reason the stratum 1 server goes down, you have another stratum 1 server you are sync'ing with.

I look at 3 different sources. If 1 source (stratum 1 server) goes down then I have 2 additional stratum 1 servers I am sync'ing with.

[Charles Holland]

To both Bill and Rick.... I can understand what you are saying.... realy. I have been running ntp on my servers for the last 4 years. After this last weekends massive change all of them are fine except for two.
I have shown in the attached file what is in the ntp.conf and netdaemons. But what comes out of ntpq -np is totally not what is in the files mentioned above. Still looking for ideas where to look to understand what went so wrong.

[david dalton_1]

Charles,

I think your "peers" configuration is not delivering any benefit to you, and it is almost certainly what is causing the strange output from ntpq.

You would be better off if all your stratum-2 machines had the same ntp.conf file:
==========
server 192.5.41.40
server 192.5.41.41
server time-a.timefreq.bldrdoc.gov
server time-c.timefreq.bldrdoc.gov
===========
Forget about the peering, it is obsolete when you have network connections. The above configuration with four stratum-1 servers protects you from the failure of any three (which is what you were trying to do with peering 2x2), and it will clear up your ntpq problems as well.

Peering was worth something when stratum-1 servers were accessed by a phone call or other point-to-point link (circa 1980), but today we have the internet and you can easily access three or more stratum-1 servers on each stratum-2 server of yours. Your entire campus only needs to have three stratum-2 servers, so the loading is reasonable.

[Charles Holland]

Long story made short........

It turns out that if server "A" does a peer TO (here repeat the word TO) server "B", server "B" gets an entry in the output of ntpq -p even if there is NO ENTRY for server "A" in the ntp.conf file.

Since server 4-8 were getting their time from server 2 and 3 because of peer, there were 5 unexpected entries whenever I did an ntpq -p function on either of them.

Took the peer out of 4-8, restarted xntp on server 2 and 3 and now everything looks like I origninally thought it should.

Thanks to all

[Charles Holland]

Done