02-23-2014 04:42 PM - last edited on 02-23-2014 10:07 PM by Maiko-I
I have a ntp server with HP-UX 11.00
and configured as below
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 188.8.131.52 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
02-24-2014 05:18 AM - edited 02-24-2014 05:24 AM
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 184.108.40.206 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.
03-08-2014 04:05 AM
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.