- ripe-atlas - mailman.ripe.net

REST API: Optional Fields for DNS Measurements
by Richter, Robert 03 Aug '24

03 Aug '24

Dear fellow RIPE Atlases, I am looking for the full definition of all optional field of the RIPE Atlas REST API for creating measurements. Especially the one for creating a DNS measurement. I only find the one defining the required attributes for a DNS measurement. But is there also a list constituting the optional fields? Best regards, Robert

2 1

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 01 Jul '24

01 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

[NTP measurements] Minimum offset if negative
by Stephane Bortzmeyer 28 Jun '24

28 Jun '24

Measurement #74488034 says on <https://atlas.ripe.net/measurements/74488034>: "Min Offset: -1 173,799". Since offsets can be positive or negative, I suggest it is not a good idea to take the minimum without first removing the sign. Here, the real minimum offset was -0.000345 (the closest from the server) and the maximum -1.173799 (the farthest from the server). (There is also a strange formatting on the Web, and a lack of units.)

3 5

[NTP measurements] Work with some servers but not all
by Stephane Bortzmeyer 27 Jun '24

27 Jun '24

I'm playing with NTP measurements and I observe that RIPE Atlas probes can talk to some public NTP servers but not all. See for instance measurements #74488034 (it works) and #74487872 (it fails). Testing with other NTP clients succeed with these two servers (ntp.nic.fr and ntp.netnod.se). I do not understand the reason for this difference. The servers which do work: ntp.nic.fr time.cloudflare.com time.google.com 0.pool.ntp.org ntp-p1.obspm.fr The servers which fail with RIPE Atlas probes but work otherwise: ntp.netnod.se time.nist.gov

1 0

[HTTP measurements] Units of timing?
by Stephane Bortzmeyer 27 Jun '24

27 Jun '24

When using "extended_timing" with HTTP measurements, in what units are tt*? I suspect that ttr is in seconds and the other two in milli-seconds but I want to be sure. (The Web interface does not display these values, it seems, but see measurement #74293060 if you want an example.)

2 2

[HTTP measurements] What is the use of query_string?
by Stephane Bortzmeyer 27 Jun '24

27 Jun '24

The documentation says that you can add a "query_string" parameter in a HTTP measurement but the anchor seems to ignore it?

2 3

IPv4 Built-ins fail while IPv6 work
by RIPE 26 Jun '24

26 Jun '24

Hi, My old hardware probe seems to have finally given up. So I installed a soft probe on my openwrt edgerouter-X, using the openwrt opkg packages. That seems to work except for all the IPv4 built-ins. I have a hurricane.net tunnel as my ISP ( Odido) is stuck in the past and does not provide IPv6. The IPv6 built-ins all show data but the IPv4 ones show ‘No data available for the period’ From the shell I can ping the addresses used by the built-ins, the names also resolve. Any idea what the cause could be ? Or how to find the cause. Probe ID = 1008458 Running OpenWrt 23.05.3, r23809-234f1a2efa Package: atlas-sw-probe Version: 5080-2 Regards, Paul

2 4

Atlas UI updated
by Stephen Suess 25 Jun '24

25 Jun '24

Hello Atlas fans, We have just released an update to the UI that includes: - NEW: download transactions in credit history - NEW: added toggles to allow hiding no reply/no report results in measurements details results - CHANGE: rework sorting in measurements results details (min to max rtt, no reply, no report) - CHANGE: map markers now sort from highest RTT on bottom to lowest RTT on top - CHANGE: added summary detail for RTT to DNS measurement detail overview If you want to see the full list of what has changed, you can check the release notes here: https://atlas.ripe.net/docs/releases/website/2024-06-25.html As always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

1 0

multiple probes down since Jun 24th?
by Andreas S. Kerber 25 Jun '24

25 Jun '24

Hi, our probe is reported down since yesterday: https://atlas.ripe.net/probes/7054/ Since I couldn't find a problem on our side and rebooting didn't change the status, I checked other probes (not mine) and they are reported down since the exact downtime as mine. Is there any kind of known problem at the moment? Other probes with the same downtime: https://atlas.ripe.net/probes/7040 https://atlas.ripe.net/probes/7052 https://atlas.ripe.net/probes/7063 https://atlas.ripe.net/probes/7067 https://atlas.ripe.net/probes/7068 -- Andreas Kerber (Senior IT-Engineer/Consultant) ask(a)idkom.de _______________________________________ IDKOM Networks GmbH Dieselstraße 1 * D-87437 Kempten (Allgäu) Tel.: 0831 59090-200 Fax: 0831 59090-90 www.idkom.de Registergericht: Amtsgericht Kempten (HRB 6359) Geschäftsführer: Benjamin Mayer * Klaus Giehl Diese E-Mail und alle mitgesendeten Dateien sind vertraulich und ausschließlich für den Gebrauch durch den Empfänger bestimmt!

6 5

repetitive 2fa authentication on every login
by ripe＠brite.cz 24 Jun '24

24 Jun '24

Hi team, https://atlas.ripe.net/probes/mine requires new login upon every browser open. It even requires 2FA every time. Is it possible to keep the session active for maybe a month, or at least do not ask 2FA every single time? I would think as services like gmail.com, portal.azure.com, account.synology.com, etc., do not require 2fa on every browser close and reopen, it may not be as crucial to perform 2fa every time I need to check if my probes are online? It becomes a bit annoying, especially me using mobile browser. Please consider. Thank you. Jiri

3 2

How long is a year?
by Edward Lewis 19 Jun '24

19 Jun '24

On my probe’s status page, there is an “All Time” “Time Connected” of 8y 343d 15h 30m. How many minutes are in a “y”? Context: in trying to illustrate uptime (number of 9’s) I wanted to show how long it would take to achieve different number of 9’s based on my probe’s history. (It’s only at one ‘9’ - 97%.)

3 4