IPv4 -v- IPv6 monitoring

I’ve worked on a number of NTP loss problems. Tools like mtr and traceroute can sometimes identify where packets are being dropped. Tracing the NTP request or response may be needed, depending on which is lost. For NTP request losses those tools should be run from the NTP client. For NTP response losses those tools should be run from the NTP server.

I typically run traceroute towards two different target UDP ports, e.g., 123 and 53. Comparing the two may show evidence of blockage / rate limits.

The bigger question is “what next?” I’ve seen NTP filtering problems with CenturyLink, Telia, Zayo and others. They don’t respond to my emails. The people doing the deliberate NTP filtering (rate limiting) feel that it is a necessary DDoS mitigation. There seems to be no dialogue with the NTP community to lessen the time transfer impact.

Note. Using the “–udp --port 123” options mtr version 0.92 worked as expected. An older version, 0.85, did not use UDP port 123 probes. I don’t know when the behavior changed.

It’s not that hard to answer. There need to be more monitors.
Newark is a good monitor for some but terribly bad for others like me.

1 Like

Sounds very sensible. Maybe it’s time to update the automated email that goes out when the monitor can’t reach a server. The current one is a bit finger pointy that it’s the server that’s got a problem rather than either the link or the server and it’s a bit light on what steps to take to diagnose the problem and try to fix it.

Aye. We seem to know what a (the?) cause of the issue is, but not having much joy fixing the underlying cause. Is there a trade body that represents ISPs that we could talk to to get the message out across all ISPs? Rate limit port 123 seems to be the current default ISP position. Not sure what’s needed to change their mind?

I guess adding more monitors would work around the issue as long as the end user NTP<-> pool traffic stays local to the monitor doesn’t cross any of the rate limiting ISPs…

Thanks for the advice everyone.

Like others have said checking mtr isn’t great since it’s a case of catching it. Traceroutes appear to point to Zayo dropping connections too. Funnily enough, on the beta site both Amsterdam and L.A both report accurately yet Newark is inconsistent. Any idea what command the monitor is running to perform the checks?

1 Like

Hi. Not sure what you mean by what command? You can watch the packets come in with tcpdump…

Sorry, early morning brain. I was just wondering if the server in Newark is running some ntp specific command for the polling (how many checks to perform, how often etc)

Does anyone have any idea what the IP addresses are for the servers in L.A and Amsterdam in the beta pool?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.