NTP. Server dropped: strata too high

From MyWiki

---

Revision as of 14:53, 11 October 2010

When I was trying to setup an NTP server inside of my infrastructure where all other machine would take correct time from, I was facing the error message from ntpdate utility.

My /etc/ntp.conf file would be nearly RedHat default one, with only server pool replaced to point to European pool, not the RedHat one:

# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.
restrict 127.0.0.1 
restrict -6 ::1

# Hosts on local network are less restricted.
restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 3.ie.pool.ntp.org
server 3.europe.pool.ntp.org
server 2.europe.pool.ntp.org

#broadcast 192.168.1.255 key 42		# broadcast server
#broadcastclient			# broadcast client
#broadcast 224.0.1.1 key 42		# multicast server
#multicastclient 224.0.1.1		# multicast client
#manycastserver 239.255.254.254		# manycast server
#manycastclient 239.255.254.254 key 42	# manycast client

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. 
server	127.127.1.0	# local clock
fudge	127.127.1.0 stratum 10	

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /var/lib/ntp/drift

# Key file containing the keys and key identifiers used when operating
# with symmetric key cryptography. 
keys /etc/ntp/keys

# Specify the key identifiers which are trusted.
#trustedkey 4 8 42

# Specify the key identifier to use with the ntpdc utility.
#requestkey 8

# Specify the key identifier to use with the ntpq utility.
#controlkey 8

On the "client" server /etc/ntp.conf looks like this (srv1 is the time server's hostname):

server srv1 iburst

When I have restarted ntpd on both servers to see the magic of synchronization happening, I saw nothing really on the "client":

# ntpq -n
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.1.1    ntpq> 
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 192.168.1.1    ntpq>

You can probably notice that the way it returned the information looks incomplete. Where is my server's IP there?!

Then I stopped ntpd on the client and run ntpdate to see a bit more details:

# ntpdate -d srv1
11 Oct 15:09:41 ntpdate[16231]: ntpdate 4.2.2p1@1.1570-o Thu Nov 26 11:35:07 UTC 2009 (1)
Looking for host srv1 and service ntp
host found : srv1
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
192.168.1.1: Server dropped: strata too high
server 192.168.1.1, port 123
stratum 16, precision -20, leap 11, trust 000
refid [192.168.1.1], delay 0.02571, dispersion 0.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  6:28:16.000
originate timestamp: d05d9925.71e34d20  Mon, Oct 11 2010 15:09:41.444
transmit timestamp:  d05d9925.7e3497b7  Mon, Oct 11 2010 15:09:41.492
filter delay:  0.02596  0.02571  0.02571  0.02573 
         0.00000  0.00000  0.00000  0.00000 
filter offset: -0.04811 -0.04817 -0.04817 -0.04818
         0.000000 0.000000 0.000000 0.000000
delay 0.02571, dispersion 0.00000
offset -0.048172

11 Oct 15:09:41 ntpdate[16231]: no server suitable for synchronization found
[root@buildforgetws ~]# ntpdate -d srv1
11 Oct 15:17:33 ntpdate[16440]: ntpdate 4.2.2p1@1.1570-o Thu Nov 26 11:35:07 UTC 2009 (1)
Looking for host srv1 and service ntp
host found : srv1
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
192.168.1.1: Server dropped: strata too high
server 192.168.1.1, port 123
stratum 16, precision -20, leap 11, trust 000
refid [192.168.1.1], delay 0.02573, dispersion 0.00014
transmitted 4, in filter 4
reference time:    00000000.00000000  Thu, Feb  7 2036  6:28:16.000
originate timestamp: d05d9aff.a396fceb  Mon, Oct 11 2010 15:17:35.639
transmit timestamp:  d05d9afd.73721d53  Mon, Oct 11 2010 15:17:33.450
filter delay:  0.02814  0.02573  0.02574  0.02573 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 2.189163 2.188005 2.187994 2.187992
         0.000000 0.000000 0.000000 0.000000
delay 0.02573, dispersion 0.00014
offset 2.188005

11 Oct 15:17:33 ntpdate[16440]: no server suitable for synchronization found

That was strange until I found the thread and the answer in it that pointed me in the right direction. I went back to my time server (srv1) and checked what's the status there:

# ntpq -n
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 89.234.64.77    193.120.142.71   2 u    3   64    1   36.389    3.167   0.001
 91.121.56.88    195.83.222.27    2 u    2   64    1   26.099    1.061   0.001
 85.17.133.31    .INIT.          16 u    -   64    0    0.000    0.000   0.000
 127.127.1.0     .LOCL.          10 l    -   64    0    0.000    0.000   0.001

Obviously, it hasn't synchronized yet. Until I saw this (note the asterisk next to 89.234.64.77, which means that the server is chosen during synchronization), I kept getting the same starta error message:

ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*89.234.64.77    193.120.142.71   2 u   42   64   17   34.346    4.182   0.966
 91.121.56.88    213.251.128.249  2 u   39   64   17   26.099    1.061   1.260
 85.17.133.31    .INIT.          16 u    -   64    0    0.000    0.000   0.000
 127.127.1.0     .LOCL.          10 l   39   64   17    0.000    0.000   0.001

Starta of the local srv1 itself is set to 10 (see the configuration file above), which is indeed too high to take time from.

When srv1 finally chose its reference server, the client was happy to synchronize to srv1:

# ntpdate -d srv1
11 Oct 15:24:27 ntpdate[16637]: ntpdate 4.2.2p1@1.1570-o Thu Nov 26 11:35:07 UTC 2009 (1)
Looking for host srv1 and service ntp
host found : srv1
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
receive(192.168.1.1)
transmit(192.168.1.1)
server 192.168.1.1, port 123
stratum 3, precision -20, leap 00, trust 000
refid [192.168.1.1], delay 0.02573, dispersion 0.00008
transmitted 4, in filter 4
reference time:    d05d9c93.b0b011a6  Mon, Oct 11 2010 15:24:19.690
originate timestamp: d05d9c9e.05b4437f  Mon, Oct 11 2010 15:24:30.022
transmit timestamp:  d05d9c9b.d570c564  Mon, Oct 11 2010 15:24:27.833
filter delay:  0.02747  0.02577  0.02573  0.02576 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 2.187758 2.188475 2.188450 2.188439
         0.000000 0.000000 0.000000 0.000000
delay 0.02573, dispersion 0.00008
offset 2.188450

11 Oct 15:24:27 ntpdate[16637]: step time server 192.168.1.1 offset 2.188450 sec

And after re-starting ntpd and few moment later, I saw what I wanted to see:

# ntpq -n
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*9.161.97.218    91.121.56.88     3 u   34   64  377    0.312    2.494   0.486

Final step was to make sure that ntpd starts on reboot (run on both server and "client"):

# chkconfig --level 2345 ntpd on