NTP. Server dropped: strata too high
From MyWiki
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