we have a problem with the ntp-client on several linux boxes. First of all, there three ntp servers in our network. On most of our boxes the synchronisation is fine. Since yesterday a handfull linux boxes has issues with synching.
The boxes are running Debian 8.7 with ntp 4.2.6.p5+dfsg-7+deb8u2 installed.
It look like this:
% sudo ntpq -pn
remote refid st t when poll reach delay offset jitter
==============================================================================
10.2.1.161 .INIT. 16 u - 64 0 0.000 0.000 0.000
10.2.1.159 .INIT. 16 u - 64 0 0.000 0.000 0.000
10.2.2.233 .INIT. 16 u - 64 0 0.000 0.000 0.000
I understand that the values for delay, offset and jitter are 0 because stratum is 16, so the ntp client refuses to sync with the servers.
What I don't understand is, why stratum is at 16. I talked to the firewall guys, nothing is dropped. So I did a tcpdump, but I can not see anything that would explain this behavior.
The client package is like this:
Network Time Protocol (NTP Version 4, client)
Flags: 0xe3, Leap Indicator: unknown (clock unsynchronized), Version number: NTP Version 4, Mode: client
Peer Clock Stratum: unspecified or invalid (0)
Peer Polling Interval: 6 (64 sec)
Peer Clock Precision: 0.000000 sec
Root Delay: 0 seconds
Root Dispersion: 0 seconds
Reference ID: (Initialization)
Reference Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Origin Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Receive Timestamp: Jan 1, 1970 00:00:00.000000000 UTC
Transmit Timestamp: Jul 26, 2017 08:20:14.664923929 UTC
And the server package is like this:
Network Time Protocol (NTP Version 4, server)
Flags: 0x24, Leap Indicator: no warning, Version number: NTP Version 4, Mode: server
Peer Clock Stratum: secondary reference (3)
Peer Polling Interval: 6 (64 sec)
Peer Clock Precision: 0.000000 sec
Root Delay: 0.0225830078125 seconds
Root Dispersion: 0.0608673095703125 seconds
Reference ID: 213.239.239.166
Reference Timestamp: Jul 26, 2017 08:05:26.414539267 UTC
Origin Timestamp: Jul 26, 2017 08:20:14.664923929 UTC
Receive Timestamp: Jul 26, 2017 08:20:14.664904341 UTC
Transmit Timestamp: Jul 26, 2017 08:20:14.664934357 UTC
The syslog entries don't show any error messages either:
Jul 26 10:55:10 servername systemd[1]: Starting LSB: Start NTP daemon...
Jul 26 10:55:10 servername ntpd[131489]: ntpd 4.2.6p5@1.2349-o Fri Jul 22 17:30:51 UTC 2016 (1)
Jul 26 10:55:10 servername ntpd[131490]: proto: precision = 0.101 usec
Jul 26 10:55:10 servername ntpd[131490]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Jul 26 10:55:10 servername ntp[131479]: Starting NTP server: ntpd.
Jul 26 10:55:10 servername systemd[1]: Started LSB: Start NTP daemon.
Jul 26 10:55:10 servername ntpd[131490]: Listen and drop on 1 v6wildcard :: UDP 123
Jul 26 10:55:10 servername ntpd[131490]: Listen normally on 2 lo 127.0.0.1 UDP 123
Jul 26 10:55:10 servername ntpd[131490]: Listen normally on 3 bond0 10.2.32.121 UDP 123
Jul 26 10:55:10 servername ntpd[131490]: Listen normally on 4 lo ::1 UDP 123
Jul 26 10:55:10 servername ntpd[131490]: Listen normally on 5 bond0 fe80::1618:77ff:fe33:2309 UDP 123
Jul 26 10:55:10 servername ntpd[131490]: peers refreshed
Jul 26 10:55:10 servername ntpd[131490]: Listening on routing socket on fd #22 for interface updates
Running ntpdate on the commandline works fine:
% ntpdate -u 10.2.1.161
26 Jul 11:00:05 ntpdate[132651]: adjust time server 10.2.1.161 offset 0.001240 sec
So maybe I don't see the wood for the trees. Anyway, any help would really be appreciated 🙂
Tank you guys!
Best Answer
I've found the reason :)
The configuration that was used on the boxes was made by a colleague, who is not working here anymore. Nobody knows anything about ntp here. So I change to the configuration file that is distributed with the ntp package and just change the servers to ours. After restarting the ntp service off course, the time sync was working!
Most of the parameters were analogue but the following ones were missing in our custom configuration:
I didn't have time to read about this parameters, so I can't tell anything about them. The most important thing is, it's working now :D