My server took a score dive as at 2019-07-10 02:23:23: https://www.pool.ntp.org/scores/150.101.186.48, yet the system is still getting many requests from external clients. IPv6 connectivity to the same server is still fine, though: https://www.pool.ntp.org/scores/2001:44b8:2100:3f00::7b
Anyone able to tell me what the monitoring IP is so I can work out where the problem lies?
Here’s a web page with more info:
https://dev.ntppool.org/monitoring/network-debugging/
Please be sure to keep us updated!
The IPv4 address listed on that page works fine, and the traceroute back to me works fine too. So it mustn’t be using the same path as the monitoring station.
I’m also experiencing issues getting to some ISPs in the London area, so I’m relatively confident this is a problem with one particular US/NA ISP reaching my ISP in AU.
It possibly could be an issue with your ISP (or even just one of the hops between) blocking / filtering NTP packets.
Maybe @Ask will have some insight?
Seems pretty unlikely to be a filtering issue, given that it only just started a couple of days ago.
Oh okay. I didn’t know if this was ongoing or a first-time thing.
Is your NTP server directly connected, or is there a router / firewall in front of it? Do you have a cable or DSL modem or similar?
A traceroute from the monitor doesn’t show anything unusual. Likewise I ran mtr from my server and no packet loss at or near your end… hmm…
No problems for IPv4 or IPv6 seen from my main monitoring client, reachability was good. I did notice that the reference ID changes at about 2019-07-10 10:00 UTC from an Apple NTP server to an RFC1918 address. At this time root delay dropped from ~18 msec to 1msec. Neither of these should hurt the score.
It looks like 150.101.186.48 does have problems sending packets to certain destinations.
For example, take a look at http://ping.pe/150.101.186.48
In limited testing from my own machines, some of my machines can ping 150.101.186.48, and some cannot. For those that cannot, the traceroute stops at ppp178-79.static.internode.on.net (150.101.178.79), which suggests to me that packets are likely getting to 150.101.186.48 but the responses are getting lost.
Routing seems to have magically fixed itself: https://www.pool.ntp.org/scores/150.101.186.48
Yeah - that was just me fixing my local stratum 1 server’s kernel, on which I broke the kernel a few days back. The Apple servers are there as backups for exactly this circumstance. 
You might want to compare my NTP server, also hosted on Internode, in Melbourne:
IPv4: https://www.pool.ntp.org/scores/150.101.217.196
IPv6: https://www.pool.ntp.org/scores/2001:44b8:41bd:c430::196
I’m not getting the routing problems you’ve described, but I’ve had them at another NTP pool member I have on the Telstra Business ASN, so I share your suspicions about the US monitoring station’s ability to reach Australia reliably.