- ripe-atlas - mailman.ripe.net

4 probes on different networks suddenly down?
by Ernst J. Oud 30 Jan '24

30 Jan '24

Hi, At noon today 4 of my probes disconnected. 1005229 61071 55795 1005072 These are on different ISP’s and one of these is in Oracle’s cloud. So this is not a problem on my side. Restarted the 61071 since that one is nearby and easily restarted since it is a hardware probe, but that does not work. Flashing red LED. What is going on? Regards, Ernst J. Oud

3 5

Atlas weather report: bad day
by Stephane Bortzmeyer 25 Jan '24

25 Jan '24

As reported by <https://atlas.ripe.net/>, indeed, measurements timeout today.

1 0

destination_ip_responded field in traceroute measurements
by Malte Tashiro 24 Jan '24

24 Jan '24

Hi, to my delight I discovered that there is now a "destination_ip_responded" field contained in traceroute measurement results. I often want to know this and had to handle it myself until now so I'm very happy that this seems to be a built-in field now. I only wonder if this is a feature to stay (since it's not in the documentation yet), and if it is server side, i.e., always available independent of the probe firmware? Best, Malte

2 3

built-in measurement id 12023
by Xiao Song 23 Jan '24

23 Jan '24

Hi all, Hope this email finds you well. The document says that this built-in measurement #12023 requires all available probes to send http requests to the target every 900s, but actually it seems like all probes send requests once a day. I was wondering if there exists inconsistency between the document and the actual measurements? Any suggestions would be appreciated. Thank you! Best, Xiao

2 1

mesures prices
by POULET Benoit 19 Jan '24

19 Jan '24

Hello, we tried to build some monitoring with the Atlas ripe network but we were blocked because of the measure's prices. Our goal is to ping an IP address every 5 minutes, with 3 packets from 3 countries in EU. The UI of Atlas give theses cost : ######################################### One-off mesure : Costs PER PROBE 6 credits for each result of a single probe 6 credits per day per probe FOR ALL PROBES 18 credits for 3 probes in total ######################################### 5 min interval mesure : Costs PER PROBE 3 credits for each result of a single probe 864 credits per day per probe FOR ALL PROBES 2592 credits for 3 probes in total per day ######################################### We have 3 Atlas probes, connected 24/24, 7/7, theses probes provide us 34 944 credits / day. With theses credits we do : * 6 One-off mesures, done every 5 mins * 13 Regular mesures, 5 min interval We were surprised at how few measures we could afford we 3 Atlas probes. Are we missing something ? Perhaps we are miss understanding what is Atlas for. Regards.

1 0

Fwd: Your credits are decreasing dramatically!
by Lukas Tribus 12 Jan '24

12 Jan '24

Hello, the "Your credits are decreasing dramatically!" emails have always been a mystery to me. I always get them a few days after a "troubleshooting session" with a number of one-off measurements. Here's the latest one; on January 6th, between 14:00 and 16:00 UTC I made a number of one-off Atlas measurements. The youngest (latest) Requested Stop Time which matches Systems Stop Time is: 2024-01-06T14:35:02Z I did not request any other measurements, and I have no "continuous" measurements running currently. And yet, on January 10th 00:48 UTC I get an warning: > Our records show that you've consumed 40500 RIPE Atlas credits in the last 48 hours, or approximately 14.06 credits/minute. On January 11th, 01:56 UTC I get the same exact warning again: > Our records show that you've consumed 40500 RIPE Atlas credits in the last 48 hours, or approximately 14.06 credits/minute. The data in those emails is just wrong, I did not use any credits for at least 72 hours (first email) and at least 96 hours (second email). It looks like already stopped one-off measurements are used for predictions not only of the future but for the past 48 hours as well? This is not a first, I got many of those erroneous messages in the past. Thanks, Lukas ---------- Forwarded message --------- From: RIPE Atlas <no-reply(a)ripe.net> Date: Thu, 11 Jan 2024 at 02:56 Subject: Your credits are decreasing dramatically! To: Lukas Tribus <lukas(a)ltri.eu> Dear RIPE Atlas probe host, Our records show that you've consumed 40500 RIPE Atlas credits in the last 48 hours, or approximately 14.06 credits/minute. We're pleased that you find the user-defined measurements useful and encourage you to keep conducting them! However, we'd like to give you a heads up that you have 2d 16h 6m before you will run out of credits at this rate. We recommend you stop some of your current measurements before this happens. If you do run out of credits, we will have to automatically stop running some of your measurements so that you do not reach a negative balance. If you would like to continue running a large number of user-defined measurements, you might want to consider applying for another probe or sponsoring a block of probes in order to earn more credits. Learn more about sponsoring probes at https://atlas.ripe.net/get-involved/become-a-sponsor/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team

3 3

Open positions at HPI, Potsdam
by Vaibhav Bajpai 05 Jan '24

05 Jan '24

Dear colleagues, I am looking for Postdocs and PhD students to bootstrap a research group on data-intensive Internet computing at the Hasso Plattner Institute. These are full-time positions in the Berlin metropolitan area. We do systems research, and publish papers at the intersection of Internet measurements, security and privacy. For instance, we actively use RIPE atlas in our measurement projects. The work place is in Potsdam, Germany. Interested candidates, please feel welcome to send me your application directly via E-mail (vaibhav.bajpai(a)hpi.de) Kind regards, -- Vaibhav ------------------------ Prof. Dr. Vaibhav Bajpai, www.vaibhavbajpai.com

1 0

Thanks!
by Ernst J. Oud 04 Jan '24

04 Jan '24

Hi, I know I was a bit harsh commenting about the degraded performance of Atlas the last couple of days. Therefore herewith also kudos now that the problems appears to be solved. I guess a number of people have worked hard on the issue. Appreciated! Ernst J. Oud

4 3

"Thinking About Internet History"
by Stephane Bortzmeyer 02 Jan '24

02 Jan '24

Among the things to preserve for future studies of Internet infrastructure and connectivity, this interesting article mentions Atlas measurements. https://content.cooperate.com/post/internet_history/

1 0

RIPE Atlas Quarterly Planning Q1 2024
by Adonis Stergiopoulos 20 Dec '23

20 Dec '23

Dear colleagues, We have published our next quarterly plans for RIPE Atlas on our website: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas This quarter, we'll continue discussing the five proposals for changing the RIPE Atlas behaviour and working on renewing the big data backend. If you have any input on our plans or want to let us know what you would like to see us work on, please let us know. Kind regards, Adonis Stergiopoulos Senior Marketing & Communications Officer RIPE NCC

1 0

auto probe renewal
by POULET Benoit 13 Dec '23

13 Dec '23

Hello, When I start a never-ending ping measurement with several probes like 20. What happened if several probes are going off-line ? Will Atlas remove the probes who are dead, and assign new to the measurement ? Or will the measurement die slowly ? I tried to find the answer in the documentation, without success. Thanks.

3 4

Anchor reprovision
by Andrew Asciutto 05 Dec '23

05 Dec '23

Atlas mailing list, Back in September I noticed my Ripe Atlas software probe corrupted itself after an unscheduled DC power outage. I reinstalled the Ripe Atlas anchor software, and left all network settings the same as last time but it doesn't look like it connected back up to RIPE. Any ideas? Anyone with a similar experience? Thanks, Andrew Asciutto Network Engineer https://www.as1003.net <https://www.as1003.net>

3 3

The role of aggregators in RIPE Atlas
by Robert Kisteleki 01 Dec '23

01 Dec '23

Dear all, We've just published a proposal about recognising the role of "aggregators" in RIPE Atlas: https://labs.ripe.net/author/kistel/the-role-of-aggregators-in-ripe-atlas/ We would be very happy to see discussions about this here on the mailing list, on the RIPE NCC Forum, or live at RIPE87. Regards, Robert Kisteleki RIPE NCC

3 2

BADMD-APP error for v3 probe #25855
by Hans Kuhn 23 Nov '23

23 Nov '23

Hi, I'm trying to resurrect a v3 probe that had a status of "Bad Firmware". I did the usual: Unplug the probe from its power source Remove the USB stick from the probe Plug in the probe WITHOUT the USB stick Wait for ten minutes Insert the USB stick I've tried 3 different 8G USB drives and they all give the same result, which is the BADMD-APP-5080 and BADMD-KERNEL-1110 error in the SOS log. Is there anything that I can do to resurrect this probe? I'm not afraid to TFTP... Thanks! Hans

4 6

RIPE NCC measurement data retention
by Robert Kisteleki 22 Nov '23

22 Nov '23

Dear all, We've just published a proposal about establishing principles around how the RIPE NCC retains and publishes Internet measurement data, specifically in RIS and RIPE Atlas: https://labs.ripe.net/author/kistel/ripe-ncc-measurement-data-retention-pri… We would be very happy to see discussions about this here on the mailing list, on the RIPE NCC Forum, or live at RIPE87. Regards, Robert Kisteleki RIPE NCC

1 0

Disconnect notification
by Ernst J. Oud 21 Nov '23

21 Nov '23

Hi, One of my ISP’s had an outage today, which made my probe on that connection report the disconnect by email. Fine, but the question popped up why a probe cannot be configured to send an email when it is able to connect again. Could this be implemented in the future perhaps? Regards, Ernst J. Oud

4 4

sharing access
by Randy Bush 20 Nov '23

20 Nov '23

how can i share access to the probe management page(s) with someone? randy

1 1

New coverage and statistics page
by Stephen Suess 16 Nov '23

16 Nov '23

Hi Atlas Friends, As part of our continuing improvements to the Atlas UI, we have just pushed a major reworking of the coverage and statistics page. Among the improvements: - Cleaner, simpler interface - Vastly improved loading time - Single map integrates layer toggles for connected, disconnected and percent coverage - Top ASNs / Prefixes / Countries section are now clickable pie charts allowing you to see items in relation to each other or the entirety - Reworked line charts for users, probes, anchors - As with other Atlas improvements, this is now completely client side (except for the API getting data) You can find the new page at https://atlas.ripe.net/coverage/ Hope you enjoy, please let us know what you think. Thanks! Stephen RIPE Atlas UI

6 9

New Atlas app Beta UI
by Stephen Suess 16 Nov '23

16 Nov '23

Hello Atlas fans, For quite some time we have been working towards a plan to separate Atlas into three distinct components: 1. The Atlas “app” 2. The Atlas promotional pages 3. The Atlas (technical) documentation The idea with this scheme was to make each more useful on their own, and not to get in the way of or confuse the others, because they each serve different purposes. This structure has been applied over several apps and services at RIPE NCC, and has been something that many teams have slowly been working towards over the past few years. The Atlas technical documentation has been in production for quite some time now (and you can check it out at https://atlas.ripe.net/docs/) And the promotional pages are being worked on and will hopefully roll out in the new year. That leaves the app. By Atlas “app”, we mean a simplified interface for interacting with the main functions of Atlas. This includes measurements, probes, anchors, credits as well as some stats. We are starting to build this simplified interface, and there is an early beta that we are releasing that we would very much like your feedback on as we develop it. Here are some of the highlights: 1. A much simplified menu structure that hopefully makes it easy to find what you need 2. A personalised dashboard that will show you cards of information related to you and your role(s). 3. On the dashboard will also be some utilities that we are developing, the first of which is an early quicklook measurement tool. You enter your target and will see a live streamed map of responses as they arrive. 4. For those of you with the Ambassador role, the dashboard contains a card that will allow you to manage the probes you have given out, and message hosts. 4. The app aims to be fully client side at launch. Many of our recent page changes on the production site have been with this in mind, and they are at the forefront of the beta interface 5. Although not yet active, there will soon be a personal preferences page that you can use to configure several aspects of the interface to your liking You can visit the beta at https://beta-ui.atlas.ripe.net/ We are very early days here (and there will definitely be bugs), but we wanted to release this beta to the public to start a conversation about what the Atlas app can and should be. Many things will change on the site over the coming weeks, and we welcome your feedback and suggestions on how to make this better and more useful to you. If possible please provide your feedback in the forum post created specifically for this purpose (https://forum.ripe.net/t/new-ripe-atlas-app-beta-ui-feedback/747) Thanks! Stephen RIPE Atlas UI

1 0

Re: [atlas] Probe with ever changing upstreams/ASs?
by stephane＠mouton.com 12 Nov '23

12 Nov '23

+ripe-atlas Regards, Grzegorz From: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> Date: Thursday, 3 August 2023 at 17:49 To: Carsten Schiefner <carsten(a)schiefner.de> Subject: Re: [atlas] Probe with ever changing upstreams/ASs? Hi! It depends on use case. For me, such probe would be fine for one-off measurements but for continuous measurements I would filter out such probe to avoid noise in data. However, when I looked on freifunk.net map I noticed that this network span across Germany, Switzerland, and Austria so even for one-off measurements usage of such probe is questionable because I never know where remote end of the tunnel is. If I understand correctly it can jump from country to country every day. In other words, such probe would be tricky to handle and user will have to be aware how such probe behave to properly handle data generated by it. Probably new system tag would be needed to mark such exotic probe. Regards, Grzegorz From: Carsten Schiefner <carsten(a)schiefner.de> Date: Thursday, 3 August 2023 at 15:07 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Probe with ever changing upstreams/ASs? All - I wonder whether this is a good idea or rather a really bad one... I have a free port on a Freifunk router where I could plug in a RIPE Atlas probe. Freifunk is a community where you - amongst other things - can offer a bit of your bandwidth to "the world". This connectivity sharing however is set up as a tunnel to various ISPs (for-profit companies and non-profit associations) as these would enjoy the "provider privilege": that in short is not to be held accountable for e.g. copy right infringements etc. ("Störerhaftung"). Anyhow: as part of this tunnel setup, the other end of the tunnel changes every 24 to 48 hours - and so does the upstream and therefore also the AS of the upstream provider. And now I am asking myself: a probe with ever changing upstreams/ASs - shall such an addition to the RIPE Atlas network be considered a fault or a feature? Any comments, anybody? Cheers, -C. -- ripe-atlas mailing list ripe-atlas(a)ripe.net https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-at… [1] -- ripe-atlas mailing list ripe-atlas(a)ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas -- ripe-atlas mailing list ripe-atlas(a)ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas Links: ------ [1] https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atl…

1 0

Re: [atlas] Probe with ever changing upstreams/ASs?
by stephane＠mouton.com 12 Nov '23

12 Nov '23

+ripe-atlas Regards, Grzegorz From: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> Date: Thursday, 3 August 2023 at 17:49 To: Carsten Schiefner <carsten(a)schiefner.de> Subject: Re: [atlas] Probe with ever changing upstreams/ASs? Hi! It depends on use case. For me, such probe would be fine for one-off measurements but for continuous measurements I would filter out such probe to avoid noise in data. However, when I looked on freifunk.net map I noticed that this network span across Germany, Switzerland, and Austria so even for one-off measurements usage of such probe is questionable because I never know where remote end of the tunnel is. If I understand correctly it can jump from country to country every day. In other words, such probe would be tricky to handle and user will have to be aware how such probe behave to properly handle data generated by it. Probably new system tag would be needed to mark such exotic probe. Regards, Grzegorz From: Carsten Schiefner <carsten(a)schiefner.de> Date: Thursday, 3 August 2023 at 15:07 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Probe with ever changing upstreams/ASs? All - I wonder whether this is a good idea or rather a really bad one... I have a free port on a Freifunk router where I could plug in a RIPE Atlas probe. Freifunk is a community where you - amongst other things - can offer a bit of your bandwidth to "the world". This connectivity sharing however is set up as a tunnel to various ISPs (for-profit companies and non-profit associations) as these would enjoy the "provider privilege": that in short is not to be held accountable for e.g. copy right infringements etc. ("Störerhaftung"). Anyhow: as part of this tunnel setup, the other end of the tunnel changes every 24 to 48 hours - and so does the upstream and therefore also the AS of the upstream provider. And now I am asking myself: a probe with ever changing upstreams/ASs - shall such an addition to the RIPE Atlas network be considered a fault or a feature? Any comments, anybody? Cheers, -C. -- ripe-atlas mailing list ripe-atlas(a)ripe.net https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-at… [1] -- ripe-atlas mailing list ripe-atlas(a)ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas Links: ------ [1] https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atl…

1 0

decommission of virtual probes
by ripe.net＠toppas.net 07 Nov '23

07 Nov '23

Hello folks, dear Atlas team, I would like to discuss the case, where a virtual probe is decommissioned because the place where you ran it will no longer be available. For example, a VPS which you have rented somewhere, but you've decided to cancel that service. Does it make sense to create and keep a backup of the virtual probe, so that you can re-deploy it later (with another AS)? Or is it better to delete the virtual probe and create a new one? Also: is there an official way to decommission a virtual probe permanently? I felt like this could be interesting for other people too, so i decided to discuss this question publicly. BR, Simon

2 1

Re: [atlas] decommission of virtual probes
by ripe.net＠toppas.net 06 Nov '23

06 Nov '23

My bad. non-hardware probes are called "software probes" non-hardware anchors are called "virtual anchors" I mixed that up. I meant software probes. BR, Simon On 06.11.23 21:16, Ernst J. Oud wrote: > Define “virtual probe” please? Do you mean a SW probe? To me a SW probe is as real as a HW probe. > > Or do you mean an abandoned probe? > > Regards, > > Ernst J. Oud > >> On 6 Nov 2023, at 20:53, Simon Brandt via ripe-atlas<ripe-atlas(a)ripe.net> wrote: >> >> Hello folks, dear Atlas team, >> >> I would like to discuss the case, where a virtual probe is decommissioned because the place where you ran it will no longer be available. For example, a VPS which you have rented somewhere, but you've decided to cancel that service. >> >> Does it make sense to create and keep a backup of the virtual probe, so that you can re-deploy it later (with another AS)? Or is it better to delete the virtual probe and create a new one? >> >> Also: is there an official way to decommission a virtual probe permanently? >> >> I felt like this could be interesting for other people too, so i decided to discuss this question publicly. >> >> BR, >> Simon >> >> -- >> ripe-atlas mailing list >> ripe-atlas(a)ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas

1 0

Customs value of Atlas Probe
by Christopher Munz-Michielin 06 Nov '23

06 Nov '23

Hi All, I'm fighting a bit of a battle over the value of the ripe atlas probe for the purposes of taxation (they are insisting it's value is more then $300 CAD and over $50 in taxes is owed to import it) and in order to fight this I need to provide proof of value, however, I obviously don't have a purchase receipt to show them. Is there any form that RIPE provides which shows the value of the Atlas probes for customs/import purposes that I can include with my case? Thanks!

2 2

New measurements listing page
by Stephen Suess 24 Oct '23

24 Oct '23

Hello Atlas friends, As part of our continuing improvements to the Atlas UI, we have just pushed a major update to the measurements listing page. Among the improvements: - Cleaner, simpler interface - Improved filtering and sorting - Views are sharable with all params - Improved paging - Favourite and Hide actions - and quite a bit more You can find the new page at https://atlas.ripe.net/measurements/ or in the menu under "Measurements", and the old page will remain available for a few weeks at https://atlas.ripe.net/measurements/legacy/. Your input and feedback is highly appreciated, you can reply to this message or directly to me or in the forum at https://forum.ripe.net/t/new-ripe-atlas-measurement-listing-page/725 Thanks! Stephen RIPE Atlas UI

1 0

Delays in web interface
by Ernst J. Oud 21 Oct '23

21 Oct '23

Hi, I experience that lots of graphs in the web interface don’t display, sometimes when clicking on the built-ins tab the “loading” never finishes etc. Measurements appear to run fine. Any performance problems in the back end or ripe stat? Regards, Ernst J. Oud

1 1

Questions with regard to the measurement status and running time
by Jerome Mao 20 Oct '23

20 Oct '23

Hi RIPE Atlas Team and Community, I would like to know more about the status of measurements - I have scheduled a one-off ping measurement which utilized 15 anchors. I polled the measurement status and results from my local desktop to the restful API through cousteau Python lib. The results were returned to me in less than a minute, but it took around 13 minutes for the measurement to transition from "ongoing" to "stopped." On the other side, the time delta between the "requested start time" and "requested stop time" on the RIPE Atlas portal is 9 minutes. My questions are: 1. Why is the measurement "ongoing" even if the results have already been made available? 2. What is the meaning of the "requested start time" and "requested stop time" on the RIPE Atlas portal? 3. Will a one-off measurement release one slot from the measurement rate limit once its result becomes available even if it’s still in "ongoing" state? Thanks! Best, Jerome

3 3

HE "Supertraceroute" exposes ATLAS traceroute functionality to the public
by me＠natha.info 19 Oct '23

19 Oct '23

Hi all, As mentioned by Lukas, NLNOG Ring is also used in the "supertraceroute" project from HE. The NLNOG Board just published a statement regarding this on the NLNOG mailing list: http://mailman.nlnog.net/pipermail/nlnog/2023-October/003099.html Kind regards, Nathalie Trenaman (also on the NLNOG Board)

2 1

HE "Supertraceroute" exposes ATLAS traceroute functionality to the public
by Lukas Tribus 19 Oct '23

19 Oct '23

Hello, FYI HE's new "supertraceroute" exposes ATLAS traceroute functionality to the public: https://bgp.he.net/traceroute/ Other sources are (NLNOG) RING nodes and other projects. Interesting approach, not sure if I should be happy about this, but I guess HE is paying for it with Atlas credits. Lukas

2 1

NTP empty results ('result': [{'x': '*'}])
by Giovane C. M. Moura 12 Oct '23

12 Oct '23

Hi folks, I am getting some NTP results in the following format: 'result': [{'x': '*'}], Does anyone know waht is this supposed to mean? is it like the measurement did not run? See blob below: {'fw': 5080, 'mver': '2.6.2', 'lts': 20, 'dst_name': '186.155.28.147', 'dst_addr': '186.155.28.147', 'src_addr': '10.10.31.19', 'proto': 'UDP', 'af': 4, 'result': [{'x': '*'}], 'msm_id': 47867316, 'prb_id': 33745, 'timestamp': 1671799154, 'msm_name': 'Ntp', 'from': '85.238.41.3', 'type': 'ntp', 'group_id': 47867316, 'stored_timestamp': 1671799249}] thanks, /giovane

2 1

New measurement form is now live (and default)
by Stephen Suess 12 Oct '23

12 Oct '23

Hello Atlas Community, We have just pushed the release version of the new measurement form (that was formerly in beta) to production. It is now the default (and lives at the same url as the old form) and the old one has been renamed legacy and will remain available for a few weeks in the menu and linked from the new form. Please check it out and let us know if you find any issues. We really appreciate the feedback given by the community during the beta, it helped us evolve and improve the form significantly. You can find the new form at https://atlas.ripe.net/measurements/form/ Thanks! Stephen RIPE Atlas UI

1 0

Changes to RIPE Atlas API keys
by Robert Kisteleki 04 Oct '23

04 Oct '23

Dear RIPE Atlas users, We'd like to update you on some upcoming changes regarding API keys in RIPE Atlas. TL;DR nothing changes regarding how you can use your API keys in the short term - as long as you're actually using them. However, we'll change how unused or forgotten keys are handled as well as remove the less secure in-URL use of them. At the moment RIPE Atlas users can query their existing API keys via the UI and API, including the possibility to retrieve old keys. In order to improve the security of how we handle these, we'll introduce the following changes in October 2023: * The listing (retrieval) of keys will only reveal parts of the keys (enough to identify them) in the API as well as in the UI. * We'll add the ability to "regenerate" an API key, which will replace the secret UUID of the key while keeping exactly the same permissions. * Unused API keys will automatically be frozen after 1 year of not being used. Active keys (i.e. the ones that have been used at least once) will not be frozen. You still have the ability to save your keys until these changes are done and, as written above, you will be able to regenerate them later. We'll notify this list when the changes are about to be done. In addition, in order to further increase the security of our system, in the long run we'll make changes about how these API keys are communicated to the API: * At the moment the API accepts these either in HTTP headers ("Authorization" header) or in the URL (?key=xyz), although the Authorization header version has been documented as the preferred version for some time. * We'll deprecate and remove the ability to use the URL form in about a year (around October 2024). * We plan to send further reminders about this change over time, as well as reaching out to heavy users of the to-be-removed format. Regards, Robert Kisteleki RIPE Atlas team

1 1

RIPE Atlas Quarterly Planning Q4 2023
by Robert Kisteleki 04 Oct '23

04 Oct '23

Dear colleagues, We have published our next quarterly plans for RIPE Atlas on our website: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas This quarter, we'll continue discussing the five proposals for changing the RIPE Atlas behaviour and working on renewing the big data backend. If you have any input on our plans or want to let us know what you would like to see us work on, please let us know. Kind regards, Robert Kisteleki Principal Engineer RIPE NCC

1 0

Changes to RIPE Atlas API auth status codes on 2 Oct
by Chris Amin 02 Oct '23

02 Oct '23

Dear colleagues, Currently the RIPE Atlas REST API (https://atlas.ripe.net/api/v2/) returns a 403 Forbidden status code in two cases: * When a request requires authentication but the user has not provided any credentials, or has provided incorrect credentials * When a user has authenticated correctly, but they or their API key lacks the permissions needed for a particular request Distinguishing between these two cases is important because in the first case the client can potentially get access by authenticating, and in the second case there is no point in retrying authentication with the same credentials. In order to enable this distinction, and to generally conform to web standards and best practices, on Monday, 2nd October we will change the REST API so that a completely unauthenticated request will receive a response with a 401 Unauthorized status code. The 403 Forbidden status code will still be returned for users and API keys that are authenticated but lack the necessary permissions for the request. As a temporary migration measure, the API will keep the same behaviour (always return 403) if either: * The "Referer" header contains "RIPE Atlas Tools" and a version string <= 3.1.1, or * An "X-Compat" header is set and contains the string "auth-2022" This temporary measure is guaranteed to work for the rest of 2022, after which it will be removed and the API will always make the 401/403 distinction. Kind regards, Chris Amin RIPE Atlas team

2 4

Will probes catch up?
by Ernst J. Oud 21 Sep '23

21 Sep '23

Hi, Some of my probes, all on different providers, (for instance: https://atlas.ripe.net/probes/1005104/#tab-builtins) have not catched up after the recent disruption. Will this happen automatically? They are connected, streaming results are ok., so I guess I don’t need to restart them? Regards, Ernst J. Oud

2 1

Atlas fully down..
by Ernst J. Oud 20 Sep '23

20 Sep '23

Considering the fact that all of Atlas is completely down for more than 24 hrs., I find the silence a bit deafening. No status updates, nothing. Weird. Not up to RIPE standards. Regards, Ernst J. Oud

7 16

One-off measurements stopped after 5-6 minutes without results
by Gerdriaan Mulder 20 Sep '23

20 Sep '23

Hi list, A few hours ago (around 15:00Z), I launched some one-off measurements[1][2][3] on the platform for a select number of probes (based on ASN and region). The target in all three cases was 2a02:1807:1020:700::1 (no hostname, purely the address). Although the number of requested and participating probes varied a bit, it seems none of the measurements yielded any results. At the time I didn't look at recent posts on this mailing list, nor was I aware of this ongoing incident[4] on the Atlas backend. It seems like that incident might be the cause of the (current) unavailability of these results. It would be great if anyone can confirm that (viewing results of) user-defined measurements are affected as well. Aside, I suppose the following messages on "My RIPE Atlas Dashboard" are also caused by the mentioned incident[4]? --->8--- 2023-09-18 16:40 UTC Your probe #11nnn was automatically untagged as "system: Resolves AAAA Correctly" 2023-09-18 16:40 UTC Your probe #11nnn was automatically untagged as "system: Resolves A Correctly" 2023-09-18 16:20 UTC Your probe #11nnn was automatically untagged as "system: IPv6 Works" 2023-09-18 16:20 UTC Your probe #11nnn was automatically untagged as "system: IPv4 Works" ---8<--- Perhaps the incident page[4] can include a few lines of the current (estimated) impact, as well. Best regards, Gerdriaan Mulder [1] https://atlas.ripe.net/frames/measurements/60161706/ (default IPv6 traceroute) [2] https://atlas.ripe.net/frames/measurements/60162230/ (IPv6 traceroute, paris=0) [3] https://atlas.ripe.net/frames/measurements/60162753/ (default IPv6 ping) [4] https://status.ripe.net/incidents/wfd7qywz3v68

3 4

Issues with Atlas back-end
by Ernst J. Oud 19 Sep '23

19 Sep '23

Hi, From September 18th there is an issue with the Atlas back-end, already 9 hours delay. Built-ins show data until around 14:00 UTC. It is now midnight. I am confused, the status page (https://status.ripe.net/) at the bottom says: “Resolved - The backend team could restore the service level and with that issues in RIPEstat stopped as well. Sep 18, 15:11 UTC” It clearly is not resolved. On the top of that status page it says: “Investigating - We are experiencing issues with the RIPE Atlas backend and currently are investigating this issue. Sep 18, 2023 - 14:07 UTC” So what is the status? Regards, Ernst J. Oud

2 1

New Atlas Measurement Creation Form (BETA)
by Stephen Suess 18 Sep '23

18 Sep '23

Hello Atlas fans, As part of our ongoing User Interface renewal activity we've been working on a redesign of the measurement creation form. Today, we're excited to announce the release of this new form in beta, and we would love your feedback and suggestions as we continue to develop it. Notable improvements include: - A simplified and cleaner user interface. - Client-side functionality, eliminating the need for external libraries, websites, or APIs (except for cost calculations and final submit). - Enhanced performance. - Mobile-friendly design. - Clearer probe selection information. - Presentation of API specification with and without the cURL command. You can find the new form at https://atlas.ripe.net/mform or in the menu under "Measurements -> Create Measurement (BETA)". Your input and feedback is highly appreciated, you can reply to this message or directly to me or in the forum at https://forum.ripe.net/t/new-measurement-form-beta/678 Thanks! Stephen RIPE Atlas UI

1 0

Built-ins tab in Atlas web interface does not respond
by Ernst J. Oud 11 Sep '23

11 Sep '23

Hi, In the web interface clicking the tab “Built-ins” does not work, it shows “loading” and nothing happens. Tried different browsers. Regards, Ernst J. Oud

2 3

Fwd: Questions with regard to the measurement status and running time
by Ernst J. Oud 08 Sep '23

08 Sep '23

> From: "Ernst J. Oud" <ernstoud(a)gmail.com> > Date: 7 September 2023 at 20:46:53 CEST > To: Jerome Mao <jxm959(a)case.edu> > Subject: Re: [atlas] Questions with regard to the measurement status and running time > > My 0.02 euro; did you get the results of all 15 probes in that short period? I use Magellan to get results and after a minute sometimes not all results are in. Magellan has two options in the latest version; a timeout to stop streaming results after for instance 30 seconds or stop after a specified number of results have been received. > > I believe probes get instructions from controllers and ofcourse they don’t receive those all at the same time. Also probes might be busy I guess doing their default measurements (every 4 minutes). So it might take a while, I have seen results coming in after a couple of minutes. > > Not sure the above is correct, just my thoughts. > > Regards, > > Ernst J. Oud

2 1

Verdien 3.0.3
by Ernst J. Oud 07 Sep '23

07 Sep '23

Hi, @Chris Amin: Yes, commit c999953, version 3.0.3 completely solves this. My gratitude is larger than the losses Mr. Musk is making now that Twitter is going down the drain :-) Thanks! Regards, Ernst J. Oud

5 4

Probe issues - now recovered
by Nigel Metheringham 04 Sep '23

04 Sep '23

Probe Id 22680 This v3 probe started playing up a couple of months back but I had not had a chance to properly investigate until this weekend. Symptoms were that it disconnected and reconnected every minute or so - my August availability report was nearly 14K lines long! Packet trace showed that it was connecting to the RIPE atlas hosts on port 433 (but talking ssh), and after a minute or so was sent a FIN from the RIPE end. Tried a few things without success, so replaced the USB stick this morning, and so far (only a few hours in) that appears to have fixed the issue... The replaced USB stick was the original I got with the hardware something over 8 years back. Nigel.

2 1

Link-Local ICMP messages for Atlas probe
by Daryl Morse 03 Sep '23

03 Sep '23

I used WireShark on the WAN interface and I can confirm that the messages are all ping requests. Further, I can confirm that all of the addresses have been mangled. They are logged as fe80:5::, but the correct addresses are fe80::. I created a bug report. -----Original Message----- From: Michel Stam <mstam(a)ripe.net> Hi Daryl, Can't say I've seen it before, can the firewall be a bit too strict? I read ICMP messages, but I don't see this in the log you post. Do you have any idea what sort of ICMP messages? Regards, Michel

2 1

Link-Local ICMP messages for Atlas probe
by Daryl Morse 18 Aug '23

18 Aug '23

I've been hosting an Atlas probe since February 2019. I have native dual-stack gigabit fibre internet service and my router is pfSense. Recently, I noticed that there are hundreds of messages in the log of the router like the following: Aug 12 22:38:54 kernel cannot forward src fe80:5::1cce:5fff:fe02:61b6, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 22:36:06 kernel cannot forward src fe80:5::e65d:370f:fc45:b5ba, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 22:11:31 kernel cannot forward src fe80:5::3c01:20ff:fee5:f601, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 17:45:08 kernel cannot forward src fe80:5::2a0:a50f:fcdb:db7c, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 15:47:09 kernel cannot forward src fe80:5::2a0:a50f:fcb9:c28e, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 08:13:04 kernel cannot forward src fe80:5::2a0:a50f:fc8a:8134, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 06:55:33 kernel cannot forward src fe80:5::bac2:530f:fc39:164a, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 03:39:05 kernel cannot forward src fe80:5::2a0:a50f:fc8a:85c0, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 01:17:54 kernel cannot forward src fe80:5::e6fc:820f:fcea:2016, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 00:55:09 kernel cannot forward src fe80:5::ee9e:cd0f:fc0d:79d4, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 11 15:47:11 kernel cannot forward src fe80:5::4271:830f:fce5:7fa, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 11 15:25:42 kernel cannot forward src fe80:5::bac2:530f:fcd4:fdd2, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 11 07:33:53 kernel cannot forward src fe80:5::cd08:c204:cc63:2d32, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 11 06:17:19 kernel cannot forward src fe80:5::fe33:420f:fcdc:5932, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 11 04:49:00 kernel cannot forward src fe80:5::7e25:860f:fc44:6742, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 22:41:25 kernel cannot forward src fe80:5::9ca0:15ff:fe87:842e, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 14:38:59 kernel cannot forward src fe80:5::c80a:daff:fe92:b8b7, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 10:55:07 kernel cannot forward src fe80:5::2a0:a50f:fc8a:6ea0, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 08:57:19 kernel cannot forward src fe80:5::46aa:500f:fceb:ad66, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 05:47:09 kernel cannot forward src fe80:5::b68a:5f0f:fcb2:1040, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 03:24:58 kernel cannot forward src fe80:5::2a0:a50f:fcb6:5ea2, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 03:08:55 kernel cannot forward src fe80:5::2a0:a50f:fc90:9d4, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 00:17:07 kernel cannot forward src fe80:5::e65d:370f:fc44:15ba, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 00:07:07 kernel cannot forward src fe80:5::2a0:a50f:fcb7:7c, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 The messages occur in groups of three, spaced a few seconds apart. All of the messages start with fe80:5. Even if I strip off the "5", none of them seem to convert into MAC addresses, so I can't use that to figure out what type of device is pinging the probe. There are no entries in the NDP table corresponding to these messages. I have no idea how long this has been happening. I only noticed it when I was setting up a new server to host pfsense. My probe is RIPE-Atlas-Probe-52209. I'm interested to know if anyone else has experienced this.

5 9

repeating v2 probe usb failure
by Randy Bush 16 Aug '23

16 Aug '23

probe 25898 had a usb failure. i did the unplug usb, power cycle, wait, replug usb. it worked for most of a day and then failed again. rinse repeat. oops, this last time, it has yet to return. can i just order a usb off the net and replace it? or do i just replace the unit? randy

5 6

Probe with ever changing upstreams/ASs?
by Carsten Schiefner 04 Aug '23

04 Aug '23

All - I wonder whether this is a good idea or rather a really bad one... I have a free port on a Freifunk router where I could plug in a RIPE Atlas probe. Freifunk is a community where you - amongst other things - can offer a bit of your bandwidth to "the world". This connectivity sharing however is set up as a tunnel to various ISPs (for-profit companies and non-profit associations) as these would enjoy the "provider privilege": that in short is not to be held accountable for e.g. copy right infringements etc. ("Störerhaftung"). Anyhow: as part of this tunnel setup, the other end of the tunnel changes every 24 to 48 hours - and so does the upstream and therefore also the AS of the upstream provider. And now I am asking myself: a probe with ever changing upstreams/ASs - shall such an addition to the RIPE Atlas network be considered a fault or a feature? Any comments, anybody? Cheers, -C.

3 3

System tag
by Ernst J. Oud 04 Aug '23

04 Aug '23

I noticed that the system tag “IPv4 stable 1d” is gone from my probe at: https://atlas.ripe.net/probes/1005104/ I use that tag as a criteria to select active orobes for measurements. But I noticed that my own probe was not included in my measurements. Which is weird since my probe has been online for 2.5 days (normally it is more stable, but my ISP had a small downtime). So my question is what triggers this tag? The tag is self explanatory but what does “stable” mean? Regards, Ernst J. Oud

3 3

Re: [atlas] Probe with ever changing upstreams/ASs?
by Ponikierski, Grzegorz 03 Aug '23

03 Aug '23

+ripe-atlas Regards, Grzegorz From: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> Date: Thursday, 3 August 2023 at 17:49 To: Carsten Schiefner <carsten(a)schiefner.de> Subject: Re: [atlas] Probe with ever changing upstreams/ASs? Hi! It depends on use case. For me, such probe would be fine for one-off measurements but for continuous measurements I would filter out such probe to avoid noise in data. However, when I looked on freifunk.net map I noticed that this network span across Germany, Switzerland, and Austria so even for one-off measurements usage of such probe is questionable because I never know where remote end of the tunnel is. If I understand correctly it can jump from country to country every day. In other words, such probe would be tricky to handle and user will have to be aware how such probe behave to properly handle data generated by it. Probably new system tag would be needed to mark such exotic probe. Regards, Grzegorz From: Carsten Schiefner <carsten(a)schiefner.de> Date: Thursday, 3 August 2023 at 15:07 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Probe with ever changing upstreams/ASs? All - I wonder whether this is a good idea or rather a really bad one... I have a free port on a Freifunk router where I could plug in a RIPE Atlas probe. Freifunk is a community where you - amongst other things - can offer a bit of your bandwidth to "the world". This connectivity sharing however is set up as a tunnel to various ISPs (for-profit companies and non-profit associations) as these would enjoy the "provider privilege": that in short is not to be held accountable for e.g. copy right infringements etc. ("Störerhaftung"). Anyhow: as part of this tunnel setup, the other end of the tunnel changes every 24 to 48 hours - and so does the upstream and therefore also the AS of the upstream provider. And now I am asking myself: a probe with ever changing upstreams/ASs - shall such an addition to the RIPE Atlas network be considered a fault or a feature? Any comments, anybody? Cheers, -C. -- ripe-atlas mailing list ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-at…<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atl…>

1 0

Requesting Credits for Research
by Alex Gamero-Garrido 29 Jul '23

29 Jul '23

Hi folks, My name is Alexander Gamero-Garrido and I'm a 5th year PhD student at CAIDA, UC San Diego. We're soon launching a large traceroute campaign for research and could use your generous donation of credits. We'll need about 150 million credits, but any partial amount that gets us closer to that goal is welcome and greatly appreciated. My account is agamerog at eng.ucsd.edu Thank you, Alex -- *Alex Gamero-Garrido* *PhD Student, Computer Science* Web: cseweb.ucsd.edu/~agamerog Center for Applied Internet Data Analysis (CAIDA) San Diego Supercomputer Center UC San Diego Pronouns: He/Him/His <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> I'm using Inbox When Ready <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> to protect my focus.

13 15