This problem is associated with the NTP request's UDP src port. By convention a client sends a NTP request to a server listening to UDP port 123. The client's UDP port is not specified in the NTP RFCs. [I've omitted some details.]
Some enterprises and also apparently some ISPs block NTP requests that do not come from UDP port 123. I won't debate the merits of such restrictions in this email. >From my home computer when I poll one of the netwrx1 servers(108.76.168.145) using ntpd (the reference NTP time server) those requests are sent from client UDP source port=123. Responses are reliable. >From the same home computer when I poll the same netwrx1 NTP server using the ntpdate command, those requests are sent from client UDP source port=dynamic/variable (e.g., source port=59624). No response arrives. Intermittently ICMP messages such as this are received. 18:47:13.013762 IP 12.122.162.5 > a.b.c.d : ICMP host 108.76.168.145 unreachable - admin prohibited filter, length 76 The router 12.122.162.5 is intentionally blocking the NTP request. The ISP port blockage may prevent NTP monitoring clients and clients running behind NAT from accessing certain NTP servers. Whether the blockage occurs may also depend on the client->server IP path. On Tue, Jul 5, 2016 at 2:05 PM, John Poznicek <[email protected]> wrote: > I have been having odd issues like this as well.. Where according to stats > my server is not available and score drops. But not having any issues with > wan connectivity, and no devices internally are having issues with the ntp > server. > > I keep meaning to setup a box outside to sync to it and log to see if it > loses any packets.. I too sent an email to ask, but haven't gotten > anything back. I think its something with the monitoring or their network > connection. > > What points me to something in their connectivity vs mine is that while > they will show problems with the ipv4 server, the ipv6 which is just a he > tunnel over the same ipv4 network shows no problems at the same time. If I > had a problem with my server or my ipv4 the ipv6 should fail as well. > > On Tue, Jul 5, 2016 at 1:32 PM, George R. Kasica <[email protected]> > wrote: > > > Starting on about 6/14/16 at around 0400 local time (Central Daylight > Time > > US UTC-6) all 5 of our time servers here can't be reached by the Status > > polling servers apparently. Yes if I put up tcpdump on the Linux hosts > and > > do a packet capture on port 123 I can see traffic from many other hosts > > coming into all 5 of the systems here and no one is reporting any outages > > (including where I'm employed that used them and monitors them - they > were > > unreachable we'd have pages going off within 5-10 minutes). > > > > There is no firewalling that would block by IP or port for port 123 and > > nothing has changed here for set up at that time to cause them to > suddenly > > drop out. > > > > Is there some way I can see what the Pool Status polling is looking like > > from the NTP Pool end to get more of a clue as to why this has suddenly > > started to fail? I've sent email to Ask but haven't yet received a reply. > > > > George > > _______________________________________________ > > pool mailing list > > [email protected] > > http://lists.ntp.org/listinfo/pool > > > _______________________________________________ > pool mailing list > [email protected] > http://lists.ntp.org/listinfo/pool > _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
