[time-nuts] NTP pool reliability

[Steven Sommars]

NTP pool performance depends on several factors.  The primary pool monitor,
located in Newark, New Jersey, periodically polls each NTP server.   Based
on reachability and calculated offset each server is assigned a score.
See  https://www.ntppool.org/scores/192.36.143.151 for example.  If a
server's score is too low, it is excluded from  DNS responses to
N.pool.centos.pool.ntp.org <http://n.pool.centos.pool.ntp.org/> etc.  [I
can't provided details on the pool's DNS implementation .]

Many NTP clients do a DNS lookup only at startup and hence will not learn
that a particular server is no longer being advertised by the NTP pool.
The "pool" directive supported by some recent NTP clients may help.  See
https://kb.meinbergglobal.com/kb/time_sync/ntp/configuration/ntp_pool_usage#pool_directive_vs_server_lines


ISPs/IXPs have implementing "NTP filtering" in some (many?) network paths.
Filtering consists of rate limits and/or NTP size limits.  It seems that
the filtering was done in response to DDoS attacks in the mid 2010's that
used the mode 7 (private) NTP directive: monlist.  Monlist was used in UDP
port 123 for amplification attacks.

NTP filtering continues to cause problems for the NTP pool administrators
and the people who volunteer their servers.   The rate limits cause some
pool monitor periodic polls to fail which in turn lowers the scores of
those NTP servers.  The servers may be temporarily dropped from the active
pool list.   In troubleshooting issues with some European NTP servers I've
found that Telia is among those doing the filtering.    The forum
https://community.ntppool.org/ can be used for pool questions and has some
details of the filtering (timeout) problems.

NTP filtering can affect clients, of course.  60-80% of the NTP polls from
one of my Chicago-based clients towards the NIST Gaithersburg, Md NTP
servers fail.
CenturyLink is doing in the filtering in this case.

The ISP/IXP NTP filtering was implemented as a DDoS defense and viewed by
at least some of that community as still being necessary.



On Sat, Feb 15, 2020 at 12:01 PM paul swed <paulswedb at gmail.com> wrote:

> Yes. Not scientific but I noticed one of my servers drifting in time.
> Changed to another NTP source seems fine.
> Regards
> Paul
> WB8TSL
>
> On Sat, Feb 15, 2020 at 12:09 PM Steve Allen <sla at ucolick.org> wrote:
>
> > During the past week my monitors on several of our telescope control
> > machines started alerting me that their NTP quality was degrading.
> > The unhappy ones were using out of the box configurations of
> > N.pool.centos.pool.ntp.org
> > We surmised that the NTP packets were not reliably traversing the WAN,
> > and we have reconfigured the critical machines to use local servers.
> >
> > Has anyone else seen a degradation of reachability and delay to NTP pool?
> >
> > --
> > Steve Allen                    <sla at ucolick.org>              WGS-84
> (GPS)
> > UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat
> > +36.99855
> > 1156 High Street               Voice: +1 831 459 3046         Lng
> > -122.06015
> > Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m
> >
> > _______________________________________________
> > time-nuts mailing list -- time-nuts at lists.febo.com
> > To unsubscribe, go to
> > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
> >
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>