[ntp:questions] NTP reply packets unreliable or rare

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Fri Jan 20 15:09:47 UTC 2017


On 2017-01-19 21:47, Charles wrote:
> 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.
> That's what I thought but, if I understand you correctly, the tcpdump
> output shows it is not so. Here it is again:
> 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?"

Change peers to sync quicker and unrestricted with: 
	peer ntp?.iciti.av iburst minpoll 4
	restrict ntp?.iciti.av
Drop local clock.
Open up local subnet for testing: 
	restrict 192.168.0.0 mask 255.255.0.0
Ensure all servers are close to truechimers by using ntpdate on each 
against a known good close source before starting ntp services.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada


More information about the questions mailing list