<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="en-PL" link="#467886" vlink="#96607D" style="word-wrap:break-word"> <div class="WordSection1"> Since we talk about usage of public service, I think that there is nothing to hide. Let me answer all questions.<o:p></o:p> <o:p> </o:p> Problem refers to these PCCW AS3491 probes:<o:p></o:p> <o:p> </o:p> 7007 7010 7032 7079 7080 7172 7198 1002754 1002771 1002785 1002844 1003737 1005609<o:p></o:p> <o:p> </o:p> They are are virtual anchor and software probes. PCCW has more probes but according to my data they are fine.<o:p></o:p> <o:p> </o:p> Problem is observed for IPv6 routing. You can check built-in IPv6 traceroutes towards F root server. You can see that everything is routed into link between PCCW and HE AS6939 in Kuala Lumpur, MY. If you check PCCW routing towards F root server using their looking glass (so their production network) everything will look normal and won’t be routed via HE.<o:p></o:p> <o:p> </o:p> As for now, these probes don’t have any tags or description that will allow you distinguish them from other, normal probes.<o:p></o:p> <o:p> </o:p> <div> <div> <div> Regards,<o:p></o:p> </div> </div> </div> Grzegorz<o:p></o:p> <o:p> </o:p> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: ripe-atlas <ripe-atlas-bounces@ripe.net> on behalf of "Ponikierski, Grzegorz via ripe-atlas" <ripe-atlas@ripe.net> Reply to: "Ponikierski, Grzegorz" <gponikie@akamai.com> Date: Tuesday, 2 July 2024 at 11:38 To: "ripe-atlas@ripe.net" <ripe-atlas@ripe.net> Subject: [atlas] Atlas probes in non-production networks<o:p></o:p> </div> <div> <o:p> </o:p> </div> Hi all!<o:p></o:p> <o:p> </o:p> I discovered a disturbing practice how RIPE Atlas probes are used by at least one major provider which significantly impacts measurement results and interpretation of these results. I want to share it with you to open discuss about how to deal with such cases.<o:p></o:p> <o:p> </o:p> I was doing traceroutes for one of Tier 1 provider which is very well covered by RIPE Atlas probes. I was surprised, that for some probes I got RTTs 100x worse than expected. After verification I discovered that routing for these probes is absurd and contact the provider to explain it. It turned out, that these probes are deployed in this part of their network that provide for some kind of internal service which is not provided for customers of this provider. In other words, these probes don't measure production network, but they measure some kind of hidden experimental network not available for the public.<o:p></o:p> <o:p> </o:p> In my private opinion, this practice is against the whole idea of RIPE Atlas, and it is a form of appropriation of the platform for solely private purpose disregarding interest of the RIPE Atlas community. As far I understand, RIPE Atlas supposed to be used to measure public Internet and it was not prepared to be used as internal/private measurement platform. RIPE Atlas probes are not tagged and separated into groups that can be used appropriately for public and internal/private measurements. Therefore, descripted practice creates another uncomfortable situation for RIPE Atlas user because there is no way to tell which probe is deployed in public/production part of the network and which one in the experimental/non-production one. I guess that most of us want to measure production networks and if there is somebody that want to play with experimental stuff then it should be clearly marked as experimental.<o:p></o:p> <o:p> </o:p> Please share your thoughts and ideas how to deal with it.<o:p></o:p> <o:p> </o:p> <div> Regards,<o:p></o:p> Grzegorz Ponikierski<o:p></o:p> Senior Network Engineer<o:p></o:p> Akamai Technologies<o:p></o:p> AS20940<o:p></o:p> </div> </div> </body> </html>