my ntp server not running as server

[Wessam Aly]

Hi,

I have searched the forums for anything relating to an issue like but have not found any.

I have configured an hpux 11iv2 ia server on my network to sync time from threee different stratum 1 servers.
I have also configured another linux server to do the same from the same 3 servers. both servers are configured as peers to each other.

all other servers on my network sync fine from the linux server (mercury) but when i try to sync them to the hp server (ntpdate servername) i get:
17 Feb 18:03:46 ntpdate[9346]: no server suitable for synchronization found

the ntp.conf config as follows:
server 10.7.107.101 version 3 prefer
server 10.7.107.102 version 3
server 10.7.107.103 version 3
peer mercury version 3
broadcastclient yes
authenticate no
broadcast 10.1.129.255 version 3

[Steven E. Protter]

Shalom,

Diagnostics:

ping ntp-server
# make sure there is connectivity basic.
telnet ntp-server 123
# make sure there is ntp connectivity.

On the Linux server, look for iptables -L output indicating a blocking of the ntp port 123 protocol.

SEP

[Fabian Briseño]

Hello Wessam.

Are there any messages in your /var/adm/syslog/syslog.log file relating to this problem.

Probably a port is blocked.

what command are you running in ht ehpux Server?

[Wessam Aly]

i'm currently trying to sync a server to my hpux ntp server (earth). that server i'm testing on is on the same vlan (reporter), so there are no possibilities of network port block issues.

here is the output of "ntpq -pn servername"

root@reporter:/> ntpq -pn earth
remote refid st t when poll reach delay offset disp
==============================================================================
10.7.107.101 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0
10.7.107.102 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0
10.7.107.103 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0
10.1.129.255 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0
10.11.99.30 0.0.0.0 16 - - 64 0 0.00 0.000 16000.0


the first 3 entries are correct, these are my stratum 1 servers (in sync only with mercury and earth)
the ip 10.11.99.30 belongs to mercury
the 10.1.129 belongs to earth (but its suppose to be the ip address 10.1.129.90, not the braodcast address 10.1.129.255).
why is it printing the braodcast address instead ?

[rick jones]

Your HP-UX system has been utterly unable to contact any of the stratum 1 servers. Since it has not been able to synchronize its time, it will not serve time to any other system.

[Brian Hackley]

Test reachability to NTP servers with: ntpdate -d 10.7.107.101
man ntpdate for details.
Hope that helps!

[Wessam Aly]

i guess its a network issue between my hp server and stratum 1 servers. I'll try to resolve and get back. thanks all

[BUPA IS]

Hello,

> why is it printing the braodcast address instead ?

This is because you said :
> broadcast 10.1.129.255 version 3
NTP now sends broadcast time packets using the broadcast address onto the network and it needs to have an association with that address in order to send them. The broadcast clinet yes will cause it to listen for broadcasts from other servers.

It is not related to you fault but I would remove the prefer option since it limits the way in which the algorithm decides which time server is more accurate.

One other thing most Linux severs now run NTP Verison 4.2 I would be inclined remove the version 3 directives and let NTP sort it out for itself .

I hope this of some use
Mike

[Wessam Aly]

sorry guys, its still not working, or so it seems on earth (hpux).

on server earth, when i run the below command on any of my stratum 1 servers (10.7.107.10x), this is what i get:

root@earth:/> ntpdate -d 10.7.107.102
transmit(10.7.107.102)
transmit(10.7.107.102)
transmit(10.7.107.102)
transmit(10.7.107.102)
transmit(10.7.107.102)
server 10.7.107.102, port 123
stratum 0, precision 0, leap 00, trust 000
refid [0.0.0.0], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Thu, Feb 7 2036 8:28:16.000
originate timestamp: 00000000.00000000 Thu, Feb 7 2036 8:28:16.000
transmit timestamp: cf38afaa.a78f4000 Wed, Mar 3 2010 11:51:38.654
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

3 Mar 11:51:39 ntpdate[11708]: no server suitable for synchronization found
=============================================

but in the syslog i see:

Feb 8 05:14:54 earth xntpd[2052]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
Feb 8 05:14:54 earth xntpd[2052]: precision = 6 usec
Feb 16 18:28:42 earth xntpd[23205]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
Feb 16 18:28:43 earth xntpd[23205]: precision = 6 usec
Feb 16 18:33:15 earth xntpd[26485]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
Feb 16 18:33:15 earth xntpd[26485]: precision = 6 usec
Feb 17 18:45:22 earth xntpd[13996]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
Feb 17 18:45:22 earth xntpd[13996]: precision = 6 usec
Feb 23 12:21:17 earth xntpd[24515]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
Feb 23 12:21:17 earth xntpd[24515]: precision = 6 usec
Mar 1 04:54:41 earth xntpd[2054]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
Mar 1 04:54:41 earth xntpd[2054]: precision = 6 usec
Mar 3 11:57:04 earth xntpd[12440]: tickadj = 625, tick = 10000, tvu_maxslew = 61875
Mar 3 11:57:04 earth xntpd[12440]: precision = 7 usec
==========================================

does that mean its synchronising or not ?

[Michael Steele_2]

No Server Suitable for synchronization found.
This message indicates that the NTP server is not responding for some reason. Packets were sent out, but no reply was returned. Perhaps the server is down, or the network link is broken or extremely congested. Or perhaps the NTP daemon died on the server and has not yet locked on to its time sources. NTP version 3.5 and above take between 5 and 15 minutes after starting up the daemon to synchronize, and it will not respond to client requests during this time.

I read this to be a poor network connection which you can test with ping, verify packet loss and transmit time, or a firewall which is block port udp/tcp 123, I believe both must be open, or the final comment about the NTP daemon in a start up un sync'd state.

http://docs.hp.com/en/B2355-90685/ch07s03.html