[ntp:questions] NTP reply packets unreliable or rare

Charles c at charlesmatkinson.org
Fri Jan 20 04:47:42 UTC 2017


On 20/01/17 05:33, questions-request at lists.ntp.org wrote:
> Date: Thu, 19 Jan 2017 16:12:28 -0700 From: Brian Inglis
> <Brian.Inglis at SystematicSw.ab.ca> To: questions at lists.ntp.org Subject:
> Re: [ntp:questions] NTP reply packets unreliable or rare Message-ID:
> <82201d1b-5bb8-cab0-614f-ae34d7d6ffc4 at SystematicSw.ab.ca> Content-Type:
> text/plain; charset=utf-8 On 2017-01-19 00:43, Charles wrote:
>> We have four NTP servers, configured to fall back to their local
>> clocks and to peer each other.
>> The arrangement is important for us because only rarely does any of
>> them synchronize with servers from pool europe.pool.ntp.org and then
>> it does not last long. tcpdump on the edge router shows requests are
>> sent to europe.pool.ntp.org servers but replies are not received.
>> We suspected networking but the same situation has arisen in house
>> where we can watch packets at both requesting and replying servers.
>> tcpdump shows:
>> * Requests are sent
>> * Requests are received
>> * Replies are not always sent, in some cases are rarely sent.
>> * Replies are received.
>> ntpq -p output is consistent with tcpdump. Currently none of our four
>> NTP servers shows reach 377 with all the other three. Current reach
>> figures are 377, 376, 354, 176, 40, 20 and 0
>> To make that more concrete, 192.168.4.11 and storage1.iciti are two
>> of our four NTP servers. Here is storage1.iciti replying rarely to
>> requests from 192.168.4.11:
>> Could it be that the request packets are received as mangled and
>> silently ignored?
>> All our NTP servers are running:
>> * Directly on hardware, that is are not VMs
>> * Debian Jessie with latest updates.  Two are Xen servers
>> * ntp package 4.2.6.p5+dfsg-7+deb8u2 from the Debian repos
> Sounds more like inbound NTP traffic is filtered some place(s)
> in your network.
> You need conf statement
> 	restrict    192.168.0.0 mask 255.255.0.0
> perhaps with some qualifications later, to allow inbound NTP from your
> local net and on your NTP host firewalls and network routers filter
> rules to allow port 123 in/out.
> Most filters allow most traffic out, but block most traffic in.
>
> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

Thanks Brian.

That's what I thought but, if I understand you correctly, the tcpdump 
output shows it is not so.  Here it is again:

20:43:43.765732 IP storage1.iciti.av.ntp > 192.168.4.11.ntp: NTPv4,
symmetric active, length 48
20:43:54.900974 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
20:44:56.071253 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
20:46:01.071170 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
20:47:05.071071 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
20:48:12.070961 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
20:49:17.070881 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
20:50:23.070749 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
20:51:30.070622 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
20:52:35.070534 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
20:53:39.070409 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
20:54:46.070315 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
20:56:56.070087 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
21:01:00.765738 IP storage1.iciti.av.ntp > 192.168.4.11.ntp: NTPv4,
symmetric active, length 48
21:01:22.069672 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
21:02:28.069545 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
21:03:33.069432 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
21:04:37.069299 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48
21:05:43.069185 IP 192.168.4.11.ntp > storage1.iciti.av.ntp: NTPv4,
symmetric active, length 48

It shows our NTP server storage1.iciti receiving NTP requests (inbound 
NTP traffic?) and rarely sending NTP replies.

The behaviour cannot be caused by the network (router firewalls etc) 
because the NTP replies are seen before they leave the server for the 
network.

If the behaviour were caused by storage1.iciti's firewall it would block 
all NTP replies, not most and anyway storage1.iciti has no firewall:

root at storage1.iciti:~# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination

Chain OUTPUT (policy ACCEPT 1 packets, 133 bytes)
  pkts bytes target     prot opt in     out     source 
destination

Similarly the behaviour should not be caused by storage1.iciti's conf 
because the conf is unchanging an the behaviour is intermittent.  Here's 
the conf:

root at storage1.iciti:~# grep -E -v '^[[:space:]]*(#|^//|;|$)' /etc/ntp.conf
driftfile /var/lib/ntp/ntp.drift
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
peer ntp1.iciti.av
peer ntp2.iciti.av
peer ntp4.iciti.av
pool europe.pool.ntp.org
restrict -4 default limited kod nomodify notrap
restrict 127.0.0.1
server 127.127.1.0
fudge 127.127.1.0 stratum 13

Which leaves the question "Why would ntpd receive requests and not send 
replies?"

Best

Charles




More information about the questions mailing list