About ntp(association ID 20354 unknown to server)

[bangu00]

Dear all

I have a ntp server with HP-UX 11.00

and configured as below

ntpserver>#/var/adm]ntpq -p
     remote           refid      st t when poll reach   delay   offset    disp
==============================================================================
*time.nuri.net   192.168.18.6     2 u   19   64  377     4.67    1.777    0.60
+time.bora.net   61.106.28.84     3 u   40   64  377     6.88   -5.199    4.03

sometimes, we got the message  from cisco switch.

(please refer to  atached a image : switch_ntp.jpg)

and then ntp server side message via ntpq -p.

(please refer to  atached a image : ntpq-p.jpg)

what's the problem?

please let me know...

have a good time.

p.S. This thread has been moved from HP-UX > System Administration to HP-UX > networking. - Hp forum Moderator

[Bill Hassell]

For the HP-UX server:

ntpserver>#/var/adm]ntpq -p
      remote        refid        st t when poll reach   delay   offset    disp
================================================================================
*time.nuri.net   192.168.18.6     2 u   19   64  377     4.67    1.777    0.60
+time.bora.net   61.106.28.84     3 u   40   64  377     6.88   -5.199    4.03

 All appears to be working OK. The 192.168 address is local to your internal network while the 61. address is external, that is, on the open Internet. From the man page, the * in column 1 indicates that the 192.168 source is selected for sync and the + for 61. shows it is included in the current selection as a valid times source. The poll is at 64 seconds which means that ntp does not see stability in the statistics. Normally, after several hours, a stable source path for an ntp server will allow the poll rate to drop from once every 64 seconds to as much as 1024 seconds (17 minutes).

However, it is unclear how the question about the Cisco switch is related to the HP-UX system. There is not enough information about the switch configuration to provide any answers.

[bangu00]

Thank you for Your replay.

Your answer was help to me . But I don't know how to solve it.

[Matti_Kurkela]

Your "ntpq-p.jpg" screenshot seems to indicate that your NTP server has picked up a lot of extra timesources instead (or in addition of) the time.nuri.net and time.bora.net you mentioned. All of those have quite poor values in the "reach" field, indicating that they have been unreachable for two or more latest polls. The zeroes in the "delay" and "offset" fields also indicate that these servers are currently unreachable, like the value of 16000 in the "disp" field.

The "reach" field in ntpq -p output is an octal number, describing a 8-bit binary value. The value is actually a string of bits, describing the success or failure of the latest 8 polls. The most recent poll result is always in the least significant bit.

So, the best possible "reach" value would be 377, meaning 11 111 111 in binary = all 8 latest polls of this time server have been successful.
A "reach" value of 10 means 00 001 000 = a single successful poll, then the three polls after that have failed.

Similarly, a value of 4 means 00 000 100 = a single successful poll, then the two polls after that have failed.

None of the lines in the screenshot include time.nuri.net nor time.bora.net. If none of the ntpq -p output lines include an asterisk (*) in the first column, then the NTP server does not have a valid source of time information at the moment. That also means it won't give time information to other NTP clients that may ask. (For example, the switch.)

The important question is: where are these extra 10.50.*.* timeserver lines coming from? Does your /etc/ntp.conf file include a "broadcastclient yes" setting, or a lot of extra "server" or "peer" lines? Or are there NTP keys configured to allow remote configuration of xntpd?

(If it includes "broadcastclient yes", comment it out.)

It almost looks like your NTP configuration is being flooded with bad timeserver entries... perhaps accidentally, perhaps maliciously, in order to make it lose track of the good ones.

Please show the output of this command:

grep -v '^#' /etc/ntp.conf

 (You can replace the IP addresses or hostnames in the output with generic placeholders if you wish.)

Remember that HP-UX 11.00 has been unsupported for a long time, and its NTP implementation is by now likely to contain unfixed security weaknesses.