July 2024 - ripe-atlas - mailman.ripe.net

RIPE Atlas Anchor Operating System Upgrade
by Paul de Weerd 02 Sep '24

02 Sep '24

Dear colleagues, RIPE Atlas anchors are scheduled for an Operating System (OS) upgrade soon since the current OS will reach its end-of-life on 30 June 2024 [1]. We are currently implementing and testing the necessary changes to support a smooth transition to the new OS without service interruption. Consequently, all live anchors will be upgraded by 31 August 2024. During this period, anchors will run on an outdated OS for a couple of months, but we do not anticipate any security issues here. For the few outward-facing services or lower-level software (such as the kernel) running on anchors, we will provide backports of necessary packages. If needed, we will shut down affected services or the anchor until the upgrade is complete. Due to this upgrade process, we have now paused applications for new anchors. New applications will resume from 15 July 2024 with anchors that will be provisioned with the new OS. If you have any questions please email gii-requests(a)ripe.net. Kind regards, Paul de Weerd RIPE NCC [1] https://www.redhat.com/en/topics/linux/centos-linux-eol

3 4

[atlas]Recent UI changes
by Stephen Suess 08 Aug '24

08 Aug '24

Hello Atlas Users, We have released several updates to the UI over the past month. Here are some of the highlights: - Measurement overview tab: improved summary info for various measurement types and (in the case of dns) most observed answers filtering - Measurement results tab: multiple, non-modal, resizable traceroute popups, toggles for filtering of no reply and no report items, and better error messaging when there are multiple sub queries If you wish to consult an exhaustive list of changes, you can see everything at https://atlas.ripe.net/docs/releases/website.html We hope you find these changes useful and welcome any feedback or suggestions you have. Kind regards, Stephen Atlas UI

2 5

RIPE Atlas data backend maintenance on 29 July 2024
by Francesco Iannuzzelli 29 Jul '24

29 Jul '24

Dear RIPE Atlas users, On 29 July 2024, between 9:00-18:00 (CEST), we will carry out planned maintenance on the data storage backend of RIPE Atlas. During this time, RIPE Atlas will be available but will serve stale data until work will be completed. Results for existing measurements will still be collected and stored. Measurement scheduling will be available but new measurements will be executed after the maintenance window. Results streaming will continue unaffected. We apologise for the inconvenience this may cause. Best regards, Francesco RIPE Atlas Team

1 1

[atlas]Installing Software Probe
by Milad Afshari 22 Jul '24

22 Jul '24

Dear RIPE Atlas Team, I encountered the following error while trying to download the RIPE Atlas software probe from the RIPE NCC GitHub repository: fatal: remote error: upload-pack: not our ref d72872cc6bb9ed5da47dcf1dc726fd8a36c6058f fatal: Fetched in submodule path 'probe-busybox', but it did not contain d72872cc6bb9ed5da47dcf1dc726fd8a36c6058f. Direct fetching of that commit failed. Can you please assist me with this issue? Kind regards, Milad Afshari

3 4

[atlas]API Not Working
by MARC BOSCH MARTINEZ 21 Jul '24

21 Jul '24

Hi all! Is anyone having problems issuing SSL measurements from the API? Seems that issuing them via the website works fine, but I've been having issues lately with the ones that I created using the API, leading to measurements in which all or most probes state "No Report Available". Best, Marc

2 1

[atlas]results page empty
by Marco Moock 16 Jul '24

16 Jul '24

Hello! https://atlas.ripe.net/measurements/75882685/results If I try to access the results, the page is empty. I tried Pale Moon and MS Edge. In Tor Browser, I can access it. Is something faulty at my side or is that a general problem? -- kind regards Marco

3 2

[atlas]Can not target google.com with periodic measurement
by Malte Tashiro 15 Jul '24

15 Jul '24

Hi, there seems to be something wrong (?) with the measurement creation process, or maybe some rules have changed? I'm trying to schedule a toy measurement to google.com, however, as soon as I set the timing to periodic, I get the error message: "We do not allow more than 25 concurrent measurements to the same target: google.com" I am not running any measurements at the moment. This behavior is independent of the measurement type (ping, traceroute, SSL) and the number of probes (error appears with one probe requested). It seems to solely be a problem of the timing. So far this message only appears for google.com and 8.8.8.8, other targets work. If I schedule the measurement in the future, I can actually submit it, but get a "Scheduling denied" measurement, for example: https://atlas.ripe.net/measurements/75418006/details I don't know if this is related, but it seems like somebody is hammering Atlas with a large number of geolocation measurements (500 probes per measurement) and DNS lookups (1 probe) at the moment. In the last hour 5582 measurements were scheduled, which is 1.5 measurements per second! Best, Malte

5 7

New status field in probes API, probe archive API
by Johan ter Beest 13 Jul '24

13 Jul '24

Dear Atlas hosts, A while ago we introduced the option for hosts to write off their probes in case they were sure it was never going to be connected again. For instance if it was broken or lost in the mail, a software probe you only used for testing. etc. This written off status was recorded in the database and we show it on the current probe page but it was not reflected in the probe API or on the probe archive API. Starting today, this will change. There is now a new status ID: 4 in the probe API and after we create the probe archive for today, this will also be visible there. Sometime today we will update the status field on the previously written off probes. This will add roughly 5500 probes to this status and will lower the number of abandoned probes with the same amount. Please let us know if you notice any unexpected behaviour. We hope that this change will make the status of probes more clear to both hosts and users. Happy measuring! Johan ter Beest RIPE Atlas Team

3 4

Request RIPE Atlas Credit Donation
by Nishant Acharya 12 Jul '24

12 Jul '24

Hello All, I am Nishant, a PhD student at the University of California, Davis—apologies for spamming the mailing list. I am working on a measurement research project that requires longitudinal analysis of Internet exchange points which requires an active traceroute campaign that we plan to do via RIPE Atlas. I have some credits to start the measurement but, I would require around 50 million more credits to complete the measurements. Therefore, I am reaching out for help. It would be great if some of you could offer me some RIPE Atlas credits. My account at RIPE NCC is on this email: nacharya(a)ucdavis.edu Sincerely, Nishant Acharya

3 3

[atlas]New Probes | Angola Cables
by Inacio Jose 09 Jul '24

09 Jul '24

Dear RIPE, Kindly help us adding these new probes to my account (Angola Cables). 1. Probe ID:64207 2. Probe ID:65186 Regards, Atenciosamente / Best Regards [cid:0a27b96e-d1a9-4669-83f3-aaee42ad1508.jpg] [cid:barra1transaprente(1)_52615b8f-bb3f-4ceb-92b4-beb18ad7e375.png] Inacio Jose Analista I | Analyst I mob: +244927686227 inacio.jose(a)angolacables.co.ao [cid:barra2transparentenova_ef83f4cd-cee1-4937-bd3b-9911b5eb9df3.png] [cid:LOGO_AC-01_8efd9d25-4916-4057-9ad2-070a690665c2.png] [cid:QRbfe18fad-af5c-4a2a-8d42-f31c5794acbb.png] https://www.angolacables.com<https://www.angolacables.com/> | AS 37468 [cid:ICONES-05_e6989344-99c6-4ded-91b2-748e677220a3.png] <https://www.facebook.com/AngolaCables/> [cid:ICONES-04_5f25e789-1a24-4f5a-8aad-26c0930ba4f5.png] <https://www.linkedin.com/company/angola-cables/mycompany/> [cid:ICONES-03_e5b5ac42-6918-4aec-a29f-caac77f4e32c.png] <http://twitter.com/angola_cables> [cid:ICONES_Prancheta1_02073217-a9bc-45f0-8970-5790a23a3b0a.png] <https://www.instagram.com/angolacables/?hl=pt> [cid:ICONES-02_1c4e151a-ff45-4b93-9f4d-9d5d4ae45f04.png] <https://www.youtube.com/channel/UC5ePxWOmrAT-HYxBPr4dNfg> . <https://services.angolacables.co.ao/meet-angola-cables-at-capacity-middle-e…>[cid:assinatura-saplancamento_71020ae9-fdc6-4150-8cb1-4ee8d5ad16d3.jpg]<https://nivel-one.com/> Antes de imprimir esta mensagem, pense no meio ambiente. | Please consider the environment before printing this email. NOTA DE CONFIDENCIALIDADE: Esta mensagem (e eventuais ficheiros anexos) é confidencial e deverá ser lida apenas por aqueles a quem ela é dirigida. Se não é o destinatário da mesma, por favor, apague a mensagem do seu computador e destrua quaisquer cópias. É proibida a sua divulgação ou cópia sem a autorização da Angola Cables. DISCLAIMER NOTICE: This message (and any files attached) is confidential and should only be read by those to whom it is addressed. If you are not the intended recipient, please contact Angola Cables or delete the message from your computer and destroy any copies. Any distribution or copying without our prior permission is prohibited.

2 1

Bug reports about Atlas
by Stephane Bortzmeyer 05 Jul '24

05 Jul '24

It seems that writing to atlas(a)ripe.net does not go to the Atlas team, but to a generic RIPE-NCC helpdesk, which knows noting about Atlas and sends back funny, but unrelated answers. What is the preferred way to report bugs about Atlas?

2 1

Missing user tags
by Stephane Bortzmeyer 04 Jul '24

04 Jul '24

We all know that user tags are imperfect and there is not a lot we can do (except pinging from time to time the hosts, like ICANN does with "Keep your social data up-to-date for your domain", with mixed success). One of the problems is that people tag correctly (I hope so) but do not always tag when it would be useful. For instance, the tag "nat" is sometimes given to probes without NAT (see for instance probes 1000929, 1005290, 1008281 or 50663) but the opposite is much more common. When requesting a measurement withOUT tag "nat", 3/4 of the selected probes have a RFC 1918 IP address (see measurement #74862711) and are certainly NATted. It seems that for many hosts, "nat" is the default.

3 2

Re: [atlas] Atlas probes in non-production networks
by Ponikierski, Grzegorz 02 Jul '24

02 Jul '24

Since we talk about usage of public service, I think that there is nothing to hide. Let me answer all questions. Problem refers to these PCCW AS3491 probes: 7007 7010 7032 7079 7080 7172 7198 1002754 1002771 1002785 1002844 1003737 1005609 They are are virtual anchor and software probes. PCCW has more probes but according to my data they are fine. 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. As for now, these probes don’t have any tags or description that will allow you distinguish them from other, normal probes. Regards, Grzegorz From: ripe-atlas <ripe-atlas-bounces(a)ripe.net> on behalf of "Ponikierski, Grzegorz via ripe-atlas" <ripe-atlas(a)ripe.net> Reply to: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> Date: Tuesday, 2 July 2024 at 11:38 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Atlas probes in non-production networks Hi all! 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. 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. 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. Please share your thoughts and ideas how to deal with it. Regards, Grzegorz Ponikierski Senior Network Engineer Akamai Technologies AS20940

1 0

Atlas probes in non-production networks
by Ponikierski, Grzegorz 02 Jul '24

02 Jul '24

Hi all! 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. 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. 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. Please share your thoughts and ideas how to deal with it. Regards, Grzegorz Ponikierski Senior Network Engineer Akamai Technologies AS20940

5 4

FW: Ripe Atlas Speeds.
by Josseth Villacis 02 Jul '24

02 Jul '24

From: Josseth Villacis <Josseth.Villacis(a)detecon.com> Date: Monday, July 1, 2024 at 1:10 PM To: ripe-atlas(a)ripe.net <ripe-atlas(a)ripe.net> Subject: Ripe Atlas Speeds. Dear<mailto:ripe-atlas@ripe.net> Ripe Atlas community, We are Detecon an telecommunication consulting company and we would like to know what is the availability of data you have, and what is the cost of having that information ? Also, we would like to know for our network analysis from your data if: Is there a way to determine if a speed test is performed on a mobile network operator’s network in India? Specifically, do MNOs and fixed network operators use the same ASN (Autonomous System Number)? Reference: [MNO List with ASN](https://github.com/nitindermohan/multifaceted-starlink-performance/blo… If MNOs and fixed network operators do use the same ASN, is there an alternative method to distinguish fixed speeds from those on a wireless network? For example, see [Distinguishing Between Fixed and Mobile IP Addresses](https://www.linkedin.com/pulse/distinguishing-between-fixed-mobi….

1 0

Minor nit in first monthly probe report after registration
by ripe＠nurfuerspam.de 01 Jul '24

01 Jul '24

Resent, hopefully without HTML formatting this time (sorry for earlier) Hi, A minor nit with regards to the availability time in the monthly probe report for the month the probe was registered in: The total availability indicated is bogus as the whole month is taken as the calculation interval as its basis, rather than only the time since probe registration. Calculation interval : 2024-06-01 00:00:00 - 2024-07-01 00:00:00 Total Connected Time : 0d 14:40 Total Disconnected Time : 29d 09:19 Total Availability : 2.04% +------------------+---------------------+---------------+-----------------------+ | Disconnected for | Connected at (UTC) | Connected for | Disconnected at (UTC) | +------------------+---------------------+---------------+-----------------------+ | - | 2024-06-30 08:52:15 | 0d 00:36 | 2024-06-30 09:29:07 | | 0d 00:04 | 2024-06-30 09:33:30 | 0d 03:20 | 2024-06-30 12:54:07 | | 0d 00:01 | 2024-06-30 12:55:49 | 0d 00:04 | 2024-06-30 13:00:17 | | 0d 00:04 | 2024-06-30 13:04:44 | 0d 01:35 | 2024-06-30 14:39:54 | | 0d 00:01 | 2024-06-30 14:40:55 | 0d 00:32 | 2024-06-30 15:13:10 | | 0d 00:10 | 2024-06-30 15:23:30 | 0d 00:02 | 2024-06-30 15:26:26 | | 0d 00:05 | 2024-06-30 15:32:13 | 0d 08:27 | Still connected | +------------------+---------------------+---------------+-----------------------+ I guess just an optical issue rather than a problem, maybe a bit misleading. The UI seems to take the fractional aspect into account, which seems more relevant. Connection Information Probe's birthday: 2024-06-30 Time Connected Percent Last Week 21h 11m 97.87% Last Month 21h 11m 97.87% All Time 21h 11m 97.87% Kind regards, R.

2 1

Minor nit in first monthly probe report after registration
by ripe＠nurfuerspam.de 01 Jul '24

01 Jul '24

1 0