Re: [atlas] RIPE Atlas VM Anchors IPv6 only support?
On Mon, 13 Dec 2021 at 10:18, Johan ter Beest wrote: > It is however in our plans to support an IPv6-only option. > > The biggest changes needed are in our monitoring, the installation > process and our deploy as anchor process. > > Technically, AFAIK, there are no roadblocks anymore. > > We could make this a higher priority if more people indicate they would > want to see this option. Personally, I am happy knowing it is on your roadmap. Would you be willing to share which quarterly roadmap you are _planning_ to add "v6-only option" to? Or at which time in the future you are likely to announce updates regarding this bullet point? /Chriztoffer
[atlas] RIPE Atlas VM Anchors IPv6 only support?
Hello, On Thu, 8 Nov 2018 at 15:35, Alun Davies wrote: > We just this morning published an article announcing that, as of today, we > are accepting applications for anyone interested in hosting RIPE Atlas VM > anchors. The article points you to all the information you’ll need to apply > for and install a virtual anchor: > > https://labs.ripe.net/Members/alun_davies/announcing-ripe-atlas-vm-anchors I was reading through the list of requirements for hosting RIPE Atlas VM Anchors as of Nov 2021. • https://atlas.ripe.net/docs/anchor-installation-vm/ • https://atlas.ripe.net/legal/anchors/memorandum/ > Network-wise, RIPE Atlas VM anchors have the following requirements: > • The anchor must have native IPv4 and IPv6 (if IPv6 is announced in the host > ASN) > • Static IPv4 and IPv6 addresses need to be unfiltered (not firewalled) > • The VM anchor may require up to 10 Mbit bandwidth (it currently requires > much less) >From the requirements, I glean if a network is not able to provide an unfiltered/non-firewalled IPv6 address to the VM. IPv6 is not a requirement if not used within the applying host ASN. Only an unfiltered public IPv4 address is. What about the reverse situation? ↪ I.e. the host ASN applying for hosting a VM Anchor is an IPv6-only ASN. Not utilizing IPv4 in the ASN. Therefore not able to provide an unfiltered IPv4 address to the VM? To my current understanding, the latter example is an instant disqualification if applying for hosting a RIPE Atlas VM Anchor? /Chriztoffer
Re: [atlas] Removing virtual RIPE Atlas probe
On Sat, 17 Jul 2021 at 16:14, Milad Afshari wrote: > I am curious to know if there is any way to remove a virtual RIPE Atlas probe > from my panel? See this earlier thread in the ripe forum. Should answer your question. https://www.ripe.net/participate/mail/forum/ripe-atlas/PDgyMDdhZTQwLWZiZTYtNzM1ZS1lYzc1LTE0ZWU5MGVkMzZhYUBzYWtrYXMuZXU+#PDk1OWU2MzM5LWUwMGItYzlkZi1jZWQwLWUxYTU1ZGUzMzYzZkByaXBlLm5ldD4=
Re: [atlas] IPv6-renew
On Mon, 21 Jun 2021 at 08:20, Marco Davids (IETF) via ripe-atlas wrote: > Whenever my network get's a different IPv6-prefix from my provider > (which happens every now and then), the probe is flagged down in the > dashboard. Does the delegated v6 prefix only change when your router power-cycles the wan facing (upstream) interface? Or is the pfx change scheduler based (i.e. timer/scheduler based)? -- Chriztoffer
Re: [atlas] Is there a procedure to move a software probe to a new device
On Sun, 20 Jun 2021 at 17:26, Peter Garner (iPad) wrote: > Noob question. I set up my software probe on a Debian 10 box which has quite > a few small servers on it. However, I intend to move it onto a Raspberry Pi, > so I was wondering if there's a specific procedure to follow to preserve > existing settings? Only the internal IP address will change; the external > remains the same. 1. Install Atlas SW Probe on the new host and update the SSH key in the RIPE Atlas portal. 2. Install Atlas SW Probe on the new host and restore the existing SSH key from the old host, restart atlas software. -- Chriztoffer
Re: [atlas] What to do with broken v1 probe?
On Sun, 21 Mar 2021 at 08:18, Lorenzo Colitti via ripe-atlas wrote: > After more than 10 years (!) of 99% uptime (see below), my probe v1 appears > to have given up the ghost. When connected to power, the lights still come > on, but after a few seconds link bounces, and it never sends any packets. > > Any idea what to do? Should I just apply for a new probe? Are new probes > being given out these days? You can apply for a new probe online on this page. https://atlas.ripe.net/get-involved/become-a-host/ If you supply a reason along with the (re-)application. I have little doubt RIPE NCC (should?) be reasonably willing to support your request for a new probe. Alternatively, RIPE Atlas - also - now supports software probes. Host one from a Raspberry PI or similar credit card-sized microcomputers? https://github.com/RIPE-NCC/ripe-atlas-software-probe https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes -- Cheers, Chriztoffer
Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses
On Thu, 18 Feb 2021 at 12:06, Philip Homburg wrote: > For a binary install of the CentOS RPM it should be automatic. For > debian based, it is a matter of compiling a new .deb and upgrading > (manually). An idea for a system-tag in the RIPE Atlas system? I.e. based on the (client) atlas probe software revision. Restrict which probes/anchers would be permitted/allowed to run tests for IP's in e.g. 240/4 space... -- Chriztoffer
Re: [atlas] [mat-wg] RIPE Atlas testing of reserved IPv4 addresses
On Tue, 16 Feb 2021 at 17:40, Bengt Gördén wrote: > I don't agree. This is a measurement tool. Whatever people think about > extending > or not extending the lifetime of ipv4 is irrelevant. It shouldn't hinder > measurements of said networks. If there's networks out there that pass 0/8 and > 240/4 it's VERY relevant to measure it. Just because you can't see it it > doesn't > mean it's not there. I support this notion, too - Avoinding the part about if it's stupid or "brilliant" to expand the public v4 space - Focusing on the RIPE Atlas part. Knowing the current extent to which e.g. 240/4 is deployed in the wild from a measurement perspective I find an interesting object to read "research results" on. Putting this in as a future [feature request] for the software development of the RIPE Atlas probe software (for the developer team to evaluate) I do not see an issue with it at all. Thou, all feature requests (regarding the RIPE Atlas software) should of course be objectively analyzed. How "expensive" the feature request will be factually implemented in the end. I.e. the "usual" impact analysis. -- Chriztoffer
Re: [atlas] Updating probe ssh pub keys via API PUT/PATCH requests
Hi RIPE Atlas, Was reading through the documentation yesterday... Is there a specific reason why it is NOT possible to update probe (ssh) pub keys via authenticated API PUT/PATCH requests? https://beta-docs.atlas.ripe.net/apis/metadata-reference/ -- Best regards, Chriztoffer Hansen
Re: [atlas] Is there a way to de-register a long dead probe?
Kyriacos, On Mon, 8 Feb 2021 at 13:49, Kyriacos Sakkas wrote: > It's not a big deal, more a mild irritation to have that probe listed. I > mostly just get reminded about it once a month when the summary email comes. If you are referring to the per-probe summary Email... Why not disable this for the "dead" probes? 1. https://atlas.ripe.net/probes// → Section "Notifications" → Hit "edit" button" → Set "Notification Target" to "disable notifications" 2. https://atlas.ripe.net/probes// → Section "Notifications" → Hit "edit" button" → Set "Report Target" to "disable reports" ... or did you refer to another notification that cannot be configured on per-probe basis? -- Chriztoffer
Re: [atlas] [RIPE-NCC/ripe-atlas-software-probe] Software probes only connect to one controller? (#45)
On Mon, 3 Aug 2020 at 12:14, Philip Homburg wrote: > This is not an ideal place to discuss how atlas works. It would be better to > use the atlas mailing list > (https://lists.ripe.net/mailman/listinfo/ripe-atlas). > > In any case, we have 2 controllers for software probes. Those controllers are > kept separate from controllers for hardware probes. We placed both > controllers at Hetzner and unfortunately, Hetzner seems to have some issues > recently (or at least more than I remember). Typically a controller handles > about 500 probes, so it will take some time before we will get controllers in > other places in the world. > > Quite a bit of atlas backend logic depends on probes having just one > controller at a time, so this is unlikely to change soon. > > Sending probes to different controllers happens automatically, but it happens > on a time scale of around 6 hours. It seems that the issue at Hetzner was > less than 2 hours. However, with all controllers for software probes at > Hetzner, a long failure at Hetzner would indeed impact all software probes. In this case, why not have the software probes set up with a fall-back RIPE Atlas Anchor (controller)? E.g. - Setup a list of 2 or more Anchors in a hierarchical order, - If the software probe cannot reach the primary Anchor for more than 10-20 minutes., fall-back to the next Anchor reachable, - Retest connectivity to all configured anchors every 6 hours, - Revert to use the first reachable anchor in the locally configured list (a hierarchical order). * The above idea assumes an Anchor being able to temp. handle more than the default ~500 probes per Anchor, plus co-location diversity of >= 2 providers and >= 3 anchors. -- Chriztoffer
Re: [atlas] Notifications
On Wed, 17 Jun 2020 at 21:02, Thomas Schäfer wrote: > is there a possibility to get notified if the probe has lost IPv6 connectivity? +1 > At the moment it seems to me, notification only works if the connection is down > with both protocols. ... Inginious! (wonder if this question has been asked before... 樂) Chriztoffer
Re: [atlas] RIPE Atlas Software Probes
On Sun, 16 Feb 2020 at 17:00, Jared Mauch wrote: > Wondering if it makes sense to have a Debian and raspbian repo stood up for > this. I could easily add this to my clusters of raspi to make the coverage > broader. Even if the RIPE NCC team only provided pre-compiled binaries as downloadable files [0]. It will the process more accessible at bare minimum, also for a wider audience not comfortable with needing to compile the binaries themself. [0]: https://github.com/RIPE-NCC/ripe-atlas-software-probe/issues/27 -- CHRIZTOFFER
