- ripe-atlas - mailman.ripe.net

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

[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

Software probe keeps going to disconnected
by vom513 19 Jun '24

19 Jun '24

Hello all, I have 2 software probes. One is on a datacenter VPS and the other at home (runs on Proxmox). The one at home keeps going to disconnected. The probe is Debian 12. Probe version is 5080-1. This machine has v6 as well - so I was thinking maybe something with temp/privacy addresses getting reaped but no, I only have one good old EUI-64 address on there. (Knock on wood) - no other VMs on my Proxmox machine have any issues like this. The only thing that looks remotely related (and this happened a bit before Nagios sent out an alert) is this: Jun 17 12:34:41 atlas-probe ATLAS[123749]: /usr/local/atlas/bin/ATLAS: 99: kill: No such process Jun 17 12:34:41 atlas-probe ATLAS[123749]: no ssh client matching . cleanup state files. for next restart Jun 17 12:34:41 atlas-probe ATLAS[123749]: RESULT 9006 done 1718642081 bc2411ca94c6 no reginit.vol start registration Jun 17 12:34:41 atlas-probe ATLAS[123749]: /var/atlas-probe/status/reginit.vol does not exist try new reg Jun 17 12:34:45 atlas-probe ATLAS[123749]: Ping works Jun 17 12:34:45 atlas-probe ATLAS[123749]: /usr/local/atlas/bin/ATLAS: 92: kill: No such process Jun 17 12:34:45 atlas-probe ATLAS[123749]: start reg Jun 17 12:34:45 atlas-probe ATLAS[144349]: ATLAS registration starting Jun 17 12:34:45 atlas-probe ATLAS[144349]: REREG_TIMER 1718416507 expired now is 1718642085 Jun 17 12:34:45 atlas-probe ATLAS[144349]: REREG_TIMER_EXPIRED go re register REREG_TIMER 1 , now is 1718642085 Jun 17 12:34:45 atlas-probe ATLAS[144349]: REGHOSTS reg03.atlas.ripe.net 193.0.19.246 2001:67c:2e8:11::c100:13f6 reg04.atlas.ripe.net 193.0.19.247 2001:67c:2e8:11::c100:13f7 Jun 17 12:34:45 atlas-probe ATLAS[144349]: ssh -p 443 atlas(a)reg03.atlas.ripe.net INIT Jun 17 12:34:48 atlas-probe ATLAS[144349]: Got good controller info Jun 17 12:34:48 atlas-probe ATLAS[144349]: check cached controller info from previous registration Jun 17 12:34:48 atlas-probe ATLAS[144349]: NO cached controller info. NO REMOTE port info Jun 17 12:34:48 atlas-probe ATLAS[144349]: Do a controller INIT Jun 17 12:34:48 atlas-probe ATLAS[144349]: Controller init -p 443 atlas(a)ctr01.atlas-prod.aws.ripe.net INIT I believe I should see an persistent ssh outbound ? The only ESTAB is me ssh’ing in, and a 443 to RIPE: root@atlas-probe:/home/vom# ss -planto | grep ESTAB ESTAB 0 0 192.168.69.111:22 192.168.64.21:65409 users:(("sshd",pid=145083,fd=4),("sshd",pid=145059,fd=4)) timer:(keepalive,115min,0) ESTAB 0 0 [2603:6011:6300:1f02:be24:11ff:feca:94c6]:37176 [2a13:27c0:1c:d01:cc61:f3a3:920d:cd88]:443 users:(("ssh",pid=144380,fd=3)) timer:(keepalive,103min,0) Let me know what else I can look at. I assume there is some debug I can crank up ? Just going to reboot this for now to get it happy and get Nagios to shut up. Thanks.

2 2

[ anchor] Quota on the usage of an anchor in measurement.
by Huseyn Gambarov 19 Jun '24

19 Jun '24

Hello. In my research, I am conducting multiple RTT measurements against different targets. During the measurement process, a single anchor stops getting scheduled for a requested measurement after some number of times or returns -1 as a result. I want to ask if there is a limit on how many times a single anchor can participate in a measurement. And what is its cooldown period if such a limit exists? With regards, Huseyn Gambarov Research Assistant PhD Student in Computer Science Case Western Reserve University

2 1

Atlas UI updated
by Stephen Suess 10 Jun '24

10 Jun '24

Hi Atlas Users, Along with the aforementioned removal of old measurement detail page links, we have just released an update to the UI that includes: - NEW: Pref for using local time (vs UTC) everywhere - NEW: Added local toggle to QuickLook for using probes close to user location - CHANGE: Add traceroute table to msm overview map marker popups - CHANGE: Make clearer the difference between no report (yet) vs no reply (from target) - CHANGE: Map now resizes on larger screens in measurement 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-10.html As always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

1 0

Removing links to legacy measurement detail pages
by Stephen Suess 07 Jun '24

07 Jun '24

Dear Atlas Users, Now that we have been up and running with the new measurement detail pages for a few weeks, we plan to remove the banner and links to the legacy pages next week. Please let us know if you still have any need for the old detail pages and why, and we will do our best to address any concerns. Kind regards, Stephen Atlas UI

1 0

RIPE Atlas infrastructure maintenance on 11 June 2024
by Robert Kisteleki 07 Jun '24

07 Jun '24

Dear RIPE Atlas users, On 11 June 2024, between 8:30-11:30 (CEST) we will carry out maintenance of the central RIPE Atlas infrastructure. The UI, APIs, access to stored results and metadata, as well as measurement scheduling will be unavailable. During this time results will still be still collected and stored. We apologise for the inconvenience this may cause. Regards, Robert Kisteleki, for the RIPE Atlas team

1 0

How to be more helpful...
by Mike 01 Jun '24

01 Jun '24

OK, here's my "problem." For starters I think the Atlas project is a great thing for the Internet, and I thank my local ISP, Comcast (USA), for encouraging me to sign up. But here's the thing for me. I have so many millions of points accumulated. When I see a message on this message list about someone asking for, say 20 million points, by the time I see that message, the requester has already received, typically, more than twice the number of points requested. (and I will say right now, private requests for points will be ignored) So my question becomes... I participate in this amazing project with a measurement device. But I also want to participate in the project by helping others, I guess I am asking, is there a way I can contribute points without having to check the list every hour or so?

2 1