- ripe-atlas - mailman.ripe.net

Atlas V5 - Rack-Mounting Solution
by Johannes Schiemer 19 Feb '23

19 Feb '23

Dear all, As I have just received my Atlas V5 Probe and wanted to mount it in my Rack, I've decided to 3d-Print a holder for the probe. I've also decided to share it with all of you in the hopes that some of you might find it useful. This is the link to thingiverse: https://www.thingiverse.com/thing:5864347 Thanks! Greetings, Johannes

1 0

Missing ping and traceroute dumps for 2023-01-23
by Maxime Mouchet 15 Feb '23

15 Feb '23

Hi, I noticed that there is no ping and traceroute dumps for 2023-01-23: https://data-store.ripe.net/datasets/atlas-daily-dumps/2023-01-23/ The other days are fine though. Is there any chance to get these dumps? Or are they just lost? Thanks! Maxime

2 3

Measurement question
by roberto.lucignani＠caleidos.it 08 Feb '23

08 Feb '23

I’m doing some measurement from one of my software probes, the measure is a traceroute to a destination. The results I get are completely different from what I see doing the same traceroute directly on host where the probe is installed. I configured the measure to sue the DNS resolution on the probe.. >From the Atlas portal I get a traceroute with 7 hops, doing it directly on the host returns 28 hops, for the same destination. Why this difference ? Regards, Roberto -- Mail sent with Outlook for Mac This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this message from your system. E-mail transmission cannot be guaranteed to be secure or error-free, because information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission.

1 0

New ripe-atlas-tools and ripe-atlas-cousteau
by Chris Amin 07 Feb '23

07 Feb '23

Dear colleagues, I'm pleased to announce the release of version 3.1.0 of the RIPE Atlas command-line tools, which allow you to use RIPE Atlas from the comfort of your shell: https://github.com/RIPE-NCC/ripe-atlas-tools/ The changes for this release include: * Improved probe-search and measurement-search, including machine-readable "csv" and "tab" output formats * --stream-timeout and --stream-limit added to measure command In addition, this release depends on the new ripe-atlas-cousteau==2.0.0, which uses the new WebSocket-based RIPE Atlas streaming API. Regards, Chris Amin RIPE NCC

1 0

Rate limiting on the APIs
by Robert Kisteleki 06 Feb '23

06 Feb '23

Dear all, We have seen in the past that even with the best intentions, every now and then some users are using excessive amounts of requests to the RIPE Atlas APIs, in some cases resulting in degraded performance to all users. An example for the curious: some AWS account asking the probe API for live queries once a day at 8am like clockwork; over a million queries for probe statuses (note: we don't have a million probes - every query is repeated hundreds or thousands of times) [1] We will apply rate limiting to protect from (some of) these. In particular: * The API in general will impose a limit of no more than 300 queries/second (if done over multiple connections) * The measurement API in particular will impose a limit of 150 queries/second (if done over multiple connections) * When reaching the limit, an HTTP response code of 429 (Too Many Requests; https://www.rfc-editor.org/rfc/rfc6585#section-4) will be given. According to our logs these limits will in general not be visible to users. Users going over these limits will see the 429 response code; client libraries should be able to handle this. We will observe the effect of these measures to determine if we need to tighten further - or perhaps relax them. We plan to apply these changes sometime next week; I'll let you know once they are in place. Regards, Robert [1] a much better way of doing this is to use the probe archive (https://ftp.ripe.net/ripe/atlas/probes/archive/); this is one-time fetch of 2MB or so and probe statuses are pretty stable in general

1 1

Fwd: Deprecating failed prefixes in the host
by Brian E Carpenter 02 Feb '23

02 Feb '23

FYI -------- Forwarded Message -------- Subject: Re: Deprecating failed prefixes in the host Date: Thu, 2 Feb 2023 17:14:22 +1300 From: Brian E Carpenter <brian.e.carpenter(a)gmail.com> To: IPv6 Operations <v6ops(a)ietf.org> Answering some of the comments made, the new version now at https://github.com/becarpenter/misc/blob/main/deprecator.py picks a random RIPE Atlas anchor probe as its ping target (unless the user supplies their own ping target). Thanks to the RIPE Atlas community for not shooting me down in flames. (An even better approach would be choose a new random ping target every hour or so, it's easy enough to code that too.) On my Windows host, I have noticed some odd behaviour of the source selection logic if a ULA is active. No such problem on Linux. For personal reasons I have no time to track that down right now. Again, there's no pretence that this is an operational solution; it's just a proof of half-baked concept. Regards Brian On 24-Jan-23 15:20, Brian E Carpenter wrote: > Hi, > > We keeping falling over the same issue with multi-provider multi-homing: routing magic can keep traffic away from the link to/from a failing provider, but hosts don't know about this and keep sending traffic *from* addresses within the failing provider's prefix. > > As Eduard Vasilenko has pointed out, source address selection at the host is the root cause of this, and RFC6724 doesn't specify a way to change source address selection automatically. Also, we don't currently have a mechanism for rapidly withdrawing a failing prefix. > > To be clear, a typical user program acting as a client uses getaddrinfo() to choose a destination address, but does not use bind() to set a source address - instead it uses connect() and the system chooses a source address. So the need is to avoid choosing a source address that lies within the prefix of a failing provider. > > This message suggests a host-only mechanism to achieve this. If you want a name for it, > consider "unhappy eyeballs". I'm not claiming originality, because it seems obvious to me. > > The mechanism is brutal: have a program running continuously on the host that regularly tests the liveness of each assigned source address, e.g., once a minute. The liveness test is simply a ping to some target address somewhere in the Internet, sourced from the address being tested (i.e., it *does* use bind()). If the ping fails several times in a row, deprecate the source address in question, i.e. set its preferred lifetime to zero. RFC6724 will then ignore it, so no new sessions will use it. Keep the deprecated address in the liveness test, and if it starts to work again, un-deprecate it (i.e. restore its lifetime). > > This is brutal because it does nothing for sessions that are already in progress when a source address fails. They will just time out. I'm sure that solutions such as TAPS is proposing will be much more elegant. It's also brutal because it doesn't know anything about prefixes, it just detects failing /128 addresses. (I don't know if there is a userland mechanism for deprecating a whole prefix.) But this works for legacy client code that simply uses connect(). > > Sounds horrible? Yes. It's also very hard to test; I don't have a setup that allows a proper test. But simulating a ping failure isn't so hard. > > You can find a quick and nasty Python version for Windows 10 and Linux at > https://github.com/becarpenter/misc/blob/main/deprecator.py > This is experimental software that might disturb network access; if you run it, it is entirely at your own risk. It needs sudo or Administrator privilege. > > There's an associated and harmless test program at > https://github.com/becarpenter/misc/blob/main/deptest.py > > (By the way, there seems to be an unexpected interaction between the RFC6724 source-selection algorithm and the presence of a ULA on Windows 10: under investigation.) > > Regards > Brian Carpenter

1 0

Encouraging people to upgrade software probe versions
by Seth David Schoen 01 Feb '23

01 Feb '23

Hi, I recently posted two threads ultimately related to the same question, where it turned out that a feature I wanted to use was present in the current software probe release, but not in the old version that I had installed. It was indeed relatively easy to upgrade (as a reply on this list predicted, the upgrade didn't break anything or require any reconfiguration). But I'd still say "relatively easy", because, on the other hand, the upgrade wasn't managed through my OS package manager like the rest of the software on my VPS server. It appears to me that a lot of software probes (like mine was until recently!) are still running whichever software probe version was current when they were first deployed. After all, I don't believe there's automatic software upgrade functionality in the methods that most people are using to deploy these. Is that true from the point of view of the rest of the Atlas community? Is there anything that might usefully be done to encourage people to upgrade periodically? (For example, either sending some kind of e-mail reminder, or distributing probe software via OS package managers, or even including a mechanism in the probe client itself by which it could upgrade itself -- even if as an opt-in feature?)

10 28

Notification of brief downtime for anchor - ie-dub-as1213
by Mick O'Donovan 31 Jan '23

31 Jan '23

Hi all, I just wanted to give you a brief proactive notification that we, HEAnet, shall be taking our RIPE Atlas anchor called ie-dub-as1213 offline for a brief period as per the below to perform a network maintenance on the edge device it connects to. Date - 8th February 2023 Time - UTC 08:00 - 09:00 Regards, Mick -- Mick O’Donovan Senior Network Engineer HEAnet CLG Ireland's National Education and Research Network 1st Floor | 5 George's Dock | IFSC | Dublin D01 X8N7 | Ireland +353 1 6609040 | mick.odonovan(a)heanet.ie | www.heanet.ie Registered in Ireland, No. 275301 | CRA No. 20036270

1 0

Notification of brief downtime for anchor - ie-dub-as1213
by Mick O'Donovan 31 Jan '23

31 Jan '23

Hi all, I just wanted to give you a brief proactive notification that we, HEAnet, shall be taking our RIPE Atlas anchor called ie-dub-as1213 offline for a brief period as per the below to perform a network maintenance on the edge device it connects to. Date - 8th February 2023 Time - UTC 08:00 - 09:00 Regards, Mick -- Mick O’Donovan Senior Network Engineer HEAnet CLG Ireland's National Education and Research Network 1st Floor | 5 George's Dock | IFSC | Dublin D01 X8N7 | Ireland +353 1 6609040 | mick.odonovan(a)heanet.ie | www.heanet.ie Registered in Ireland, No. 275301 | CRA No. 20036270

1 0

Atlas anchors as ping targets
by Brian E Carpenter 30 Jan '23

30 Jan '23

Hi, I have a question about using Atlas anchors for a special purpose. Is the following acceptable, or would people have objections to the following idea? TL;DR: Is it OK to use Atlas anchors as random ping targets? Over in IETF-land we are (again) debating how to make IPv6 multi-provider multihoming work properly. There's a scenario description and picture at https://github.com/becarpenter/book6/blob/main/6.%20Management%20and%20Oper… One unsolved problem is that if one provider fails, many client applications may continue to use a source address belonging to that provider, instead of switching to a source address belonging to the other provider. One approach to solving this without any changes except in the host is to magically deprecate failing source addresses until they work again. One approach to that is a pure hack - a program that runs in the background pinging a remote target from various source addresses, to deprecate and undeprecate them as appropriate. There's code at https://github.com/becarpenter/misc/blob/main/deprecator.py. This is experimental software that might disturb network access. Would it be OK to choose the probe target by picking an Atlas anchor at random? (I have running code for that, but will not post it to github if there are objections.) I am quite sure that this code is only of interest to a few IPv6 geeks. It could of course be instrumented for measurement purposes, but multihomed sites of this kind are so rare that I don't think there would be much to measure. Regards Brian Carpenter

3 4