I understand the issue is _not_ that packets NTP aren't getting through. The issue is that the probes don't report on the results of the measurement ("no report available"), which they should do even when they don't get a response (which they should report with "no reply", or potentially an error message they got back). It's not only in the UI, but the data retrievable from the API is also lacking those reports. 12.07.2025 13:43:27 Max Grobecker <max.grobecker@ml.grobecker.info>:
Hi Marco, Hi Giovane,
do you know if this only affects ntp0.testdns.nl or could it be a problem with NTP packets in general? Also, did you do traceroutes/MTRs to the affected probes to see, if there are similarities in routing – like the same transit carrier? In the past, some carriers (CenturyLink, as an example) had traffic filter rules in place on their edges to prevent NTP reflection or amplification attacks, that killed regular NTP traffic as well, so I assume this could be the case here, too, not necessarily with CenturyLink/Colt as the transit.
You could try doing a traceroute with port 123/UDP as the source towards these probes to see, if the packets get eaten on some network demarcation:
traceroute -U --sport 123 <ip-of-the-probe>
You will likely not get an answer on the last 1-2 hops (because NAT and stateful firewalls), but if there's a carrier in between that discards traffic, the traceroute is noticeable shorter.
If it helps, you can try with my server ntp2.301-moved.de as well – I have access to sflow data from that host, so I can precisely tell if there have been answer packets coming from that system.
Greetings, Max ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
