- ripe-atlas - mailman.ripe.net

Erroneous data in measurement 7000
by Filip Dobrev 07 Oct '25

07 Oct '25

Dear RIPE Team, I am a Master's student at TU Delft, currently working on a tool that uses RIPE data to reliably detect network outages. While analyzing the measurements, I noticed what appears to be incorrect data being reported. In particular, when counting the number of disconnected probes per country, I observed that many countries show a major outage on 23 April 2025, where nearly all probes were marked as disconnected for about an hour and a half before recovering. For example, in Spain (ES): 2024-09-10 12:58:10 UTC – 16:37:15 UTC (Duration: 3:39:05, Peak offline probes: 154) Happened across many(40+) countries 2024-09-17 10:37:04 UTC – 12:50:56 UTC (Duration: 2:13:52, Peak offline probes: 129) Happened across many(40+) countries 2025-04-23 09:39:27 UTC – 11:11:59 UTC (Duration: 1:32:32, Peak offline probes: 210) Happened across many(90+) countries The timing and duration of the April 23 outage are consistent across many countries. I’ve compiled more examples and raw data in this editable online notepad https://shrib.com/#Asa3ZLP3Xe. It seems that a large portion of probes were marked as disconnected, even though the raw measurement data indicates they were still actively sending and receiving information. It is important to note that such errors can be observed at other times for short periods of less than a minute - 20-05-2025, again across many countries. I would greatly appreciate your clarification on a few points: 1. What could explain this discrepancy? Is it a measurement issue or something related to RIPE’s internal systems? 1. Are all measurements potentially affected by this? For example, measurement 10310, during an outage in NMK on May 18, some probes showed no responses for a 30-minute window(possibly still timing out). Similarly, during the outage in Portugal on April 28, several probes had no data for multiple hours. 1. How trustworthy are the results from the measurements? 1. How long does it typically take for RIPE to detect and reflect a disconnected probe (or other events) in the API? 1. Different requests to root measurements take the same time, even though one is requesting 30 minutes and another is requesting 4 minutes of data. Is the overhead on Ripe's side the reason for this? Looking forward to your response! Best regards, Filip Dobrev

4 3

Fwd: Updated RIPE Atlas Terms & Conditions
by Ernst J. Oud 03 Oct '25

03 Oct '25

3 3

Atlas UI updates 2025-09-26
by Stephen Suess 26 Sep '25

26 Sep '25

Hello Atlas friends, We have just released an update to the UI that includes (among other items): - NEW: Measurement form: auto-top-up settings - NEW: Measurement details manage tab: auto-top-up settings and manual top-up (when possible) - CHANGES: Khipu (beta): Horizontal layout mode, much improved RTT mode with anomaly notes, country filter dropdown, country view lookup/scoring, IP labels in IP view For the full list of what has changed, please see the release notes here: https://atlas.ripe.net/docs/releases/website_index/2025-09-26 Please let us know what you think! Kind regards, Stephen Atlas UI

1 0

FreeBSD/MacOS probe
by Jared Mauch 22 Sep '25

22 Sep '25

I’m looking for people to test out my attempted FreeBSD/MacOS changes to shift a few calls to POSIX compliant and other tweaks to make it build on other operating systems. You can try to build from this git repo: https://github.com/jaredmauch/ripe-atlas-software-probe I would request comments go here: https://github.com/RIPE-NCC/ripe-atlas-software-probe/pull/135 Or possibly in this issue which originated from someone else, but the recent note from Randy had me look at the codebase. https://github.com/RIPE-NCC/ripe-atlas-software-probe/issues/123 Hopefully this is useful and might be able to be merged back in, but I know this may cause some troubles due to the busy box parent as well. - Jared

7 29

Debian trixie support for s/w probes?
by Andrew Elwell 16 Sep '25

16 Sep '25

Hi folks, Is there a plan to support debian stable 'soon' for the software probes? I know I could build from the git repo, but I'm lazy and would rather apt-get install it, but https://ftp.ripe.net/ripe/atlas/software-probe/debian/dists/ only has bullseye & bookworm. Hat tip to all involved tho, #1009903 seems to be chugging along happily (well, except that the hypervisor's due for an update & reboot shortly) Andrew

3 2

Atlas UI, Khipu and docs updates
by Stephen Suess 15 Sep '25

15 Sep '25

Hi All, Since the last update on 2 September, we have updated the Atlas UI 3 times (including today). Among the highlights: - Khipu visualisation -- Country view -- DNS multi target view -- Smart popup placement -- Improved path filter -- Docs: https://atlas.ripe.net/docs/tools-and-code/khipu - DomainMON improved error messaging - LatencyMON url param fixes - Legal accordion new sections - Clarify member benefits in the Use Cases menu You can see all the recent changes here: https://atlas.ripe.net/docs/releases/website_index/ And as always we welcome any and all feedback and suggestions. Kind regards, Stephen RIPE Atlas UI

1 0

Notification on removal of system-ipv4-works && system-ipv6-works tags while connected
by Lukas Tribus 15 Sep '25

15 Sep '25

Hello, currently notifications are configurable for the event when a probe is disconnected; however when a probes remains connected but stops working (loosing or no having either system-ipv4-works and system-ipv6-works tags), we are blind. I have written a monitor script to query the API for this, to get this notification but I'm wondering if it would be possible to implement this at RIPE. The system-<AF>-works tags are already there. Software bugs and I guess HW issues can trigger hung probes that remain connected. It's hard to find out, unless one is specifically looking for it or specifically expecting the result of a single probe in a measurement. Lukas

15 29

tracemon false join
by Randy Bush 13 Sep '25

13 Sep '25

looking at TraceMON (for 128292864), it appears as if the traces for a bunch of sources converge at a common node before failing. but they do not. they fail at different points as one can see if one looks at the result details or at khipu. what am i misunderstanding here? this is very misleading to a novice. i see one madly clicking at the apparent point of failure desperately wanting its ip address. of course, i would never make that mistake :) randy

1 0

traffic graph
by Hans Mayer 05 Sep '25

05 Sep '25

Dear All, Based on the conversation about traffic here some days ago I took a look into my statistics. I looked at the dashboard from RIPE Atlas and I looked at netflow from the router for my probe. Both from the last 24 hours. This is the dashboard and this comes from netflow it is summarised for IPv4 in and out and IPv6 in and out. Not to be confused netflow shows bits and the dashboard bytes. There is another difference, netflow has 10 minutes intervals and it seem the dashboard has 3 minutes. But independent of that, the graphs should have some similarities. I am not worried about that because the traffic is below any perception. But is there any explanation ? It becomes funny when I switch to "Last Week" All the traffic is below the 0 KB line. Maybe it should be 10 KB and the "1" is not visible for some reason. Kind regards Hans

2 1

Suggestion to change "next" field in the result of a probes REST API query
by Shane Kerr 05 Sep '25

05 Sep '25

Hello, The REST API query to get probes is documented here: https://atlas.ripe.net/docs/apis/rest-api-reference/probes If you do a lookup which would return too many results, it sets the "next" field in the return, like this: -------------------------------------------------------------------- { "count": 55125, "next": "https://atlas.ripe.net/api/v2/probes/?page=2", "previous": null, ... -------------------------------------------------------------------- The idea is the REST API client will then make a call to the "next" URL and get the next batch of data; this is basic paging. There is no kind of transaction or anything, so the status of the probes can change between each call. This is fine since the status of the probes changes independently and you cannot count on their status really. One problem is that using "page" for this means it is possible to get the same probe twice. For example, if you are looking for "Connected" probes, and returning the probes in order of probe ID, and a probe that you have already returned becomes "Connected", then the answers will all shift up by one, and you will see the last probe twice. This can be avoided by instead of using "page" for the "next" field using whatever the sorting is for the returned values in the query. I think by default this is probe ID, so the "next" field could be: -------------------------------------------------------------------- { "count": 55125, "next": "https://atlas.ripe.net/api/v2/probes/?id__gt=101", "previous": null, ... -------------------------------------------------------------------- I suspect this would be faster on the back-end too. I ended up doing this logic on the client side and it works fine, although that is for a specific sorting order. It would be more complicated to do this for all orderings on the server side. Cheers, -- Shane

2 1