- ripe-atlas - mailman.ripe.net

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

29 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 1

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

Request for RIPE Atlas credits - CS student at ETH Zürich
by Nikolas Kühnlein 30 Mar '26

30 Mar '26

Hi all, My name is Nikolas Kühnlein and I am a computer science student at ETH Zürich, currently taking a course on computer networks. As part of my studies I have been exploring traceroute analysis and IP geolocation using latency triangulation — specifically trying to verify the physical location of intermediate hops using RTT measurements from distributed vantage points, rather than relying on WHOIS or commercial geolocation databases. I recently discovered RIPE IPmap and was impressed by how accurately it placed a Google border router in Zürich (contradicting a WHOIS record pointing to Mountain View, CA). I would like to run my own ping measurements from European probes to a small set of hop IPs from my traceroutes, to understand the triangulation method hands-on. As a new user I have no credits, and I am looking for a small donation to get started — a few million credits would be more than enough for what I have in mind. My RIPE Atlas account is registered under: nikshop(a)takuu.de I am happy to share my findings with the community. Thank you in advance for any help. Best regards, Nikolas Kühnlein ETH Zürich

5 5

CfP: Workshop on Negative results in Network measurements (NetNet)
by Alexandrina Ioana Livadariu 26 Mar '26

26 Mar '26

Hello all, We are organizing a workshop on Negative results in Network measurements (NetNet) this year. The workshop is part of ACM SIGCOMM’26 and will take place in Denver, Colorado, USA. The workshop invites submissions that report and reflect negative results in network measurement studies. The main goal is to foster a constructive discussion on lessons learned from studies in which methods, datasets or experimental designs did not yield the expected results. Submissions should focus on fundamental issues related to measurement approaches, methodology, and underlying assumptions, rather than on non-fundamental issues such as implementation bugs or misconfigurations. Focusing on the critical parts of the experiment, the workshop aims to strengthen rigor, promote transparency and improve methodology practices in network measurement research. We are planning to open the workshop for short papers (two and six pages) focusing on one problem where the authors dealt with negative results. Submissions must be original, unpublished work, and not under consideration at another conference or journal. Important dates: Submission deadline: May 1, 2026 (AoE) Acceptance deadline: June 5, 2026 Camera ready: June 20, 2026 Workshop date: August 17, 2026 (co-located with ACM SIGCOMM’26) Submission: https://netneg26.hotcrp.com/ Full Call for Papers: https://conferences.sigcomm.org/sigcomm/2026/netneg/ We look forward to your submissions and participation! Best regards, Ioana Livadariu & Mattijs Jonker

1 0

Request for access to RIPE Atlas HTTP measurements with full URL support
by Andrey Validenko 19 Mar '26

19 Mar '26

Hi RIPE Atlas team, I would like to request access to HTTP measurements with full URL/path support. I am currently developing a project focused on monitoring domain availability and detecting potential network interference (DNS, IP, HTTP-level) across different countries and ISPs using RIPE Atlas. At the moment, standard measurements allow testing domains at a basic level, but for my use case it is important to test specific URLs and paths (e.g. https://domain.com/path) as blocking or filtering often happens on particular endpoints rather than the root domain. Additionally, I am working on applying these measurements to anti-phishing and malware detection use cases. Many phishing campaigns rely on specific URL paths, and being able to measure HTTP responses (status codes, headers, response size) for those paths across different networks would significantly improve detection accuracy. Concretely, this capability would allow me to: - detect selective blocking or filtering of specific URLs rather than entire domains - identify abnormal HTTP responses (e.g. block pages, injected content) on targeted paths - compare behavior across ISPs and regions to detect network-level anomalies - improve heuristics for early identification of malicious or compromised infrastructure I understand that this feature may require special permissions due to resource usage, and I am committed to using it responsibly with a limited and controlled number of measurements. I would be happy to provide more details about my use case if needed. Thank you for considering my request. Best regards, Andrew Validenko Andrew_CrushPhish

1 0

Latest RIPE Atlas web update kills older browsers
by Ernst J. Oud 17 Mar '26

17 Mar '26

Hi, I just noticed that atlas.rip.net has apparently been updated. Slightly older browsers now only give a blank page, for instance Safari on iPadOS 18.1 and Opera 78 on Windows 10. Not a huge problem, currently updating my trusty iPad… always holding this off until Apple updates are reported as more stable. Regards, Ernst J. Oud

3 3