- ripe-atlas - mailman.ripe.net

Re: Notification on removal of system-ipv4-works && system-ipv6-works tags while connected
by Antony Gollan 03 Sep '25

03 Sep '25

Hello all, We use Brevo to send these emails primarily because it ensures deliverability and allows people to easily unsubscribe. This is important because big email providers have recently increased their penalties for potential spam, so we track bounces and unsubscribes to make sure the RIPE NCC stays within acceptable limits. It is not possible for us to turn off the tracking pixel in Brevo on our end, but we use it only to view the status of delivery, opens and unsubscribes. We are aware this tracking is not 100% accurate, but it gives us a general view of whether emails are reaching their recipients, which helps us to stay below the spam threshold. If you’d rather get a plaintext version of these emails from Brevo, some email clients provide an option to switch to the plaintext view. This will also block the tracking pixel. Regards, Antony Gollan Communications Team Manager RIPE NCC

2 1

Massive uptick in number of flows to/from probe
by Jenisch Ewald 03 Sep '25

03 Sep '25

Hi, Maybe coincidence with the update of the UI rolled out today, but we've seen a massive uptick in the number of flows going out from our probe up to a range of 120k flows/sec starting around 15:00 local time (CEST) Anybody else experiencing the same thing? Any ideas as to what's going on here? Thanks in advance for any clue, -ewald eingeschränkt/restricted

5 6

Atlas UI update 2025-09-02
by Stephen Suess 02 Sep '25

02 Sep '25

Hello Atlas friends, We just released a rather significant update to the UI that includes the following new features (in addition to other changes and fixes): - NEW: Khipu visualisation (beta) - NEW: Use Cases: Path Analysis (Khipu - beta) and Reachability Testing (QuickLook - beta) - NEW: Probe detail pages results tab: Timed out measurements display - NEW: Measurements advanced search: number of probes - NEW: Measurement detail pages: show destination IPs if target is domain and resolved on probe For the full list of what has changed, you can check out the release notes here: https://atlas.ripe.net/docs/releases/website_index/2025-09-02 As always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

1 0

New RIPE Atlas Traceroute Visualisation Tool
by Stephen Suess 29 Aug '25

29 Aug '25

Hello Atlas friends, Recently we have been working on a new traceroute visualisation tool, and although we are still in early development, we wanted to release this version to the community to solicit feedback and opinions about it. This will help us focus on the items that are most important to the community as we work to finish it. You can test out this new visualisation on our beta-ui site <https://beta-ui.atlas.ripe.net/>, from any traceroute measurement detail page. Just look for the "TRACEVIS" link at the top of the page and click to access it. There is a labs article that describes the tool in some detail: https://labs.ripe.net/author/stephen_suess_1/new-prototype-ripe-atlas-trace… As always, we hope you find these features useful and we encourage your feedback. Kind regards, Stephen RIPE Atlas UI

3 6

Comparison of HW and SW Probes
by Richter, Robert 28 Aug '25

28 Aug '25

Hello everybody! Currently, I am investigating the possibilities of measurements using RIPE Atlas. Is there information about differences in the measurement results of HW and SW probes? My advisor said that I should rather not use SW probes, but I am not sure what the actual difference is, especially as SW probes often run on better hardware, compared to the HW probes. Could you point me to some resources on that topic? Best regards, Robert

8 7

Anchoring measurements from 7106 appear to be affected by a local proxy
by William Kanieski 28 Aug '25

28 Aug '25

Hi, all. I am a computer networks PhD student analyzing RIPE anchoring measurements for research purposes. While I was looking at traceroutes originating from specific anchors, I noticed that all traceroutes from Anchor #7106 only contained one hop, with no silent hops present. Upon further inspection, these singleton hops were actually the destination IP addresses themselves, and they had extremely short (<1ms) RTTs from 7106 even when they were supposed to be located on the other side of the globe. On the other hand, ping and traceroute measurements directed *toward* 7106 all seemed normal, with regular hop counts and RTTs that seemed to agree with reported geographical distance. I strongly suspect that 7106 is connected to a local proxy that is responding to outgoing ping and traceroute traffic on behalf of its intended destinations. As such, I wanted to bring some attention to this anchor so that other researchers might be aware of its status before trying to use it to conduct measurements. Regards, William Kanieski

3 3

Any problems with the registration servers?
by Tore Anderson 25 Aug '25

25 Aug '25

I have recently have had three probes «die» on me in ways the hardware actually seems fine, but the problem is with connectivity with the Atlas infrastructure. I am therefore starting to wonder if my probes were all OK after all, and that the problems are with the Atlas registration servers or infrastructure in general. Here's the timeline: First problem was with V1 probe #138 back in January. It reported through SOS messages that it could not connect on HTTPS, error code «firewall issues suspected» or something like that. However, observing the network traffic in/out of the probe revealed that the probe did successfully establish a TCP three-way handshake with reg01/reg02.atlas.ripe.net, only to immediately close the connection with a FIN packet, without actually sending any payload. There was no firewall blocking any traffic. RIPE NCC support essentially shrugged and said V1 probes aren't really supported nowadays, so I gave up and recycled the probe. Second problem was with another V1 probe (#433), in May. That one was left disconnected for an extended period of time, transitioning to "abandoned" status. As it did not reconnect after I fixed the network, I proceeded to write it off and re-connect it, then re-registered it with my personal account. It too connected fine with the network, and the event log showed a «Registration» event every time I power-cycled the probe, but it never went further and the status was stuck at «No Controller Connection». The written off status never cleared. RIPE NCC support could confirm that the written off status should have cleared after reconnection, but otherwise weren't able to help, so this probe went in the bin as well. Third problem is with a V3 probe (#10667), ongoing as I write this. It was working perfectly fine up until last week, when I moved it from a data centre to my home network. The probe had static IP configuration in the data centre, and with no way of configuring it to back to using DHCP, I thought I'd just re-install firmware by booting it up without the USB in and plugging it back in after a while. It connected fine and reported «NO-USB» SOS messages, and after plugging in the USB stick «Registration» events with the hardware details of the USB stick appeared (curiously enough, most of these events report an IP of 172.17.0.1). At that point the process gets stuck, the «Registration» events with the USB stick details keep repeating approx. every 65 minutes, and there's a warning banner at the top of the page «Flash Drive Filesystem Corrupted». So I have re-tried this with several different USB sticks, all from reputable brands, and all passing whole-device read/write tests to identify bad blocks when connected to my laptop. I have also tried replacing the power supply – nothing helps, it always ends up in the same «Registration» loop. During the process, a partition table with three 1 GiB large partitions is created on the USB stick, containing data/filesystems that my Linux laptop does not recognise as anything familiar. I could be persuaded that the two V1 probes did indeed have hardware problems. However the V3 probe clearly does not, at least not with its USB stick, and since its failure mode is rather similar to how #433 failed (process getting stuck after «Registration» events), I am starting to wonder if at least #433 was fine all along. Anyway, i am curious to hear if it is just me being very unlucky with my probes this year or if anyone else have had similar problems recently? Another issue, probably unrelated but I thought I'd mention it anyway, is that when I try to change the ownership of the V3 probe to my personal account, the web page just displays a red pop-up with the unhelpful message «An error occurred», and the ownership change does not happen. Tore

1 0

Discrepancy between built-in test and my own test
by Ernst J. Oud 22 Aug '25

22 Aug '25

Hi, I have a probe (probe ID 1005229) running on a VM in the Oracle Cloud. On that probe I have a ping test (measurement ID 85299016) to Google. Thus, an Atlas controller instructs my probe to do a latency test every 5 minutes. The result of that test is fairly consistent at around 7 ms. However, there is also a built-in measurement running on all Atlas probes to Google, every probe automatically performs this measurement every 10 minutes. The results of that test is fairly consistent at around 1 ms. Why is there such a difference between these two equal measurements? Both to Google, both from the same probe. Any clues? Regards, Ernst J. Oud

2 3

re-adopting
by Randy Bush 20 Aug '25

20 Aug '25

Probe 25918 may have come back to life some months after i abandomed it. how can i re-adopt it? thanks. randy

5 7

Re: Need RIPE Atlas Credits for measurements
by Carsten Schiefner 14 Aug '25

14 Aug '25

2 3