April 2026 - ripe-atlas - mailman.ripe.net

Rollout of software probe anti farming measures
by Francesco Iannuzzelli 30 Apr '26

30 Apr '26

Dear RIPE Atlas users, Some of you may remember earlier discussions about this topic. We’re now ready to enable a feature to address this issue. Supporting each probe requires resources from the system; at the same time having too many probes in the same network and location does not provide much new information (that is, more probes in the same location or network would provide similar measurement results). Therefore we have controls in place to limit the amount of /software/ probes that are connecting from particular networks: 1. Each probe host can connect up to 2 software probes from the same IP address. 2. Each probe host can connect up to 4 software probes from the same IP prefix (as seen in BGP). 3. At most 32 (or 64) probes from the same IPv4 (or IPv6) prefix (as seen in BGP), regardless of the host. Software probes that connect from networks beyond these limits will not be allowed to connect, unless and until other software probes drop out. Note that we may also adjust the particular maximums over time. We realise that in some cases multiple probes belonging to the same user can come seemingly from the same network, violating rule 2 (mostly), yet they arguably still provide enough value for the community. This may be for example because they are in fact geographically widely distributed. In such a case the host can reach out to us via atlas(a)ripe.net with an explanation and we will consider relaxing this limit. While in the past we observed surprising corner cases, the particular limits described above are set partially taking into account the current software deployment. Therefore only a handful of probe hosts should be impacted by this (as I write this, 71 probes from 13 hosts). As I mentioned above, we’re open to adjust the limits if needed. Regards, Francesco Iannuzzelli

2 2

Atlas UI updates for 2026-04-29
by Stephen Suess 29 Apr '26

29 Apr '26

Hello Atlas fans, We have just updated the UI with a new fullscreen view for the Region Meshes use case, as well as some under the hood changes related to the system used to log in to Atlas. In addition, we are deprecating TraceMon (in favour of Khipu) and will be removing it from Atlas after the upcoming RIPE meeting. If there is functionality that you use in TraceMon that is not available to you elsewhere within Atlas, please let us know and we will evaluate. Kind regards, Stephen Atlas UI

1 0

Requesting Credits for research
by Anugya Sharma 25 Apr '26

25 Apr '26

Hello, I am a grad student at UC Davis. I am trying to research starlink satellite users in developing countries and if their traffic is unnecessarily routed through the US. I am measuring traceroute, DNS, ping and have identified Starlink-connected RIPE Atlas probes (AS14593) in Kiribati, the Marshall Islands, Madagascar, and Guam. I would be so thankful for any credits you can provide so that I can get my measurements going. -Anugya Sharma Department of computer science, UC,Davis

4 3

RIPE Atlas: From Core Concepts to Use Cases (upcoming RIPE NCC Open House Event)
by Stephen Suess 24 Apr '26

24 Apr '26

Hi everyone, We would like to invite you to a two-part RIPE NCC Open House event on RIPE Atlas, with a particular focus on the UI. I will be giving demos and talking about numerous tools and visualisations that are available to help you understand and make sense of Atlas data. Session 1 takes place Thursday, 30 April at 13:00 (UTC+2) Session 2 takes place Tuesday, 12 May at 13:00 (UTC+2) Full details and registration: https://www.ripe.net/meetings/open-house/ripe-atlas-from-core-concepts-to-u… We look forward to seeing you there! Kind regards, Stephen Atlas UI

1 0

Atlas UI updates 2026-04-15
by Stephen Suess 15 Apr '26

15 Apr '26

Hello Atlas friends, We have just released an update to the Atlas frontend. The most notable new feature is the Region Meshes use case, which is a new RIPE Atlas tool that visualises intra-region routing paths, showing where traffic stays local, where it leaves, and how IXPs are being used. You can read about it here: https://labs.ripe.net/author/stephen_suess_1/introducing-region-meshes-visu… And you can link directly to the tool here: https://atlas.ripe.net/use-cases/region-meshes/ Additionally, you can see the full list of what has changed or been fixed in the release notes: https://atlas.ripe.net/docs/releases/website_index/2026-04-15 As always, we welcome your feedback and would love to know what you think. Kind regards, Stephen Atlas UI

1 0

Atlas ping measurement with include_probe_id
by Yi Zhou 07 Apr '26

07 Apr '26

Hi All, I’m having issues with how the payload of a ping measurement is constructed. In a recent experiment, I found that not all probes correctly embed the probe ID into the payload. For example, the following payload is a correct example. [4, 255, 0, 1, 0, 25, 253, 117, 26, 85, 207, 174, 0, 0, 0, 0, 192, 94, 125, 241, 173, 37, 232, 44, 82, 73, 80, 69, 32, 65, 116, 108, 97, 115, 32, 112, 114, 111, 98, 101, 32, 49, 48, 50, 50, 49, 0, 0, 0, 0, 0, 0] Includes “[82, 73, 80, 69, 32, 65, 116, 108, 97, 115, 32, 112, 114, 111, 98, 101, 32]” as the ASCII of “RIPE Atlas probe ”, and “[32, 49, 48, 50, 50, 49]” as probe ID “10221” However, in a randomized sample of 50 probes, 34 of them do not have the probe ID following “RIPE Atlas probe" [82, 0, 0, 1, 113, 214, 8, 0, 0, 0, 0, 0, 129, 197, 72, 49, 0, 0, 0, 0, 0, 0, 0, 0, 171, 144, 68, 164, 87, 28, 143, 103, 0, 0, 0, 0, 82, 73, 80, 69, 32, 65, 116, 108, 97, 115, 32, 112, 114, 111, 98, 101] While considering the chance that older firmware versions do not recognize the configuration option, I disabled the ‘include_probe_id’ option. None of the payloads in this experiment includes the “RIPE Atlas probe” part. Does anyone have experience with this issue? I do notice that there are about 8 bytes shared between packets from the same probe and the same measurement, but it seems more like a randomized identifier. Thanks, Yi

1 0