Hi Lucas, > [...] > As far as the claim that the problem inherently resides with the monitoring > node because of RIPE Atlas probes goes, that would be foolish to say the > least. Peering issues are a very real thing. Only the windows desktop had a > missed probe on one of the hops (timed out) and the hop before and after it > were with the same network (Comcast, who is my ISP).
Well, as far as I understand from the conversation so far, nobody blamed the monitoring node for the problems. I completely agree with you that a peering/routing issue is most probably the root cause of it. However that's just an educated guess, the only thing we can tell for sure is that the monitoring incorrectly states many servers as being unreachable. > I'm really inclined to suspect transatlantic issues at this time. If someone > has > a server they can probe over into the UK from somewhere like Ashburn, > Virginia: please probe with a traceroute over IPv6. North America Peering > seems solid at the moment. ntplax7.ntppool.net resolves to 2607:f238:2::17, which belongs to AS7012. Unfortunately, that AS does not seem to host any (public) Atlas probes. I created two more measurements pinging and tracerouting the monitoring system only from probes located within the US: https://atlas.ripe.net/measurements/8759687/#!probes https://atlas.ripe.net/measurements/8759888/#!probes Apparently not only transatlantic connections are affected, but also peerings within the USA. Whatever the reason is, I hope somebody takes care of this ASAP. Cheers, marco _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
