NTP. Server dropped: strata too high
From MyWiki
(Difference between revisions)
(Created page with '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. M…') |
m (Protected "NTP. Server dropped: strata too high" ([edit=sysop] (indefinite) [move=sysop] (indefinite))) |
Current 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
