Trouble with NTPD on client-side

Question

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!

Don't connect to the servers as peers. Peers would be the same stratum level as your host, but the servers should be a stratum level higher The servers should probably be something like stratum level 7, and your hosts would be stratum level 8. — Ron Maupin, Jul 26 '17 at 09:08
Thank you for your answer! I'm pretty new to NTP so I don't exactly know what you mean. Can you explain it more detailed, please? Do you want me to post my ntp.conf of the clients? — audioslave, Jul 26 '17 at 10:14
my entries in the ntp.conf are of the type server. Like this one: `server ntp1.local iburst` — audioslave, Jul 26 '17 at 10:31

score 1 · Answer 1 · answered Jul 26 '17 at 12:51

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:

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

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

stats lines probably would not change the connection behavior, unless you happened to fix other syntax errors while doing your edit. Note the polling interval, you may have had to wait literally a minute for the first sample. — John Mahowald, Jul 26 '17 at 13:02

Trouble with NTPD on client-side

1 Answers1