- ripe-atlas - mailman.ripe.net

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