August 2020 - ripe-atlas - mailman.ripe.net

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

Probe DHCPv6 support
by Aleksi Pirttimaa 19 May '23

19 May '23

Hi! I recently received my v4 probe and I'm very happy with it. But unfortunately it doesn't support DHCPv6. I present a practical reason for implementing a DHCPv6 client on the probe. You see, my ISP doesn't send router advertisements with the prefix for stateless autoconfiguration set, and instead DHCPv6 must be used. I believe their decision could have something to do with the fact that the regulating body here requires ISP's to prevent IP address spoofing in consumer plans. And to meet that requirement my ISP may be using a feature similar to Cisco's IP source guard, where switch ports and/or mac addresses are passively associated to leased ip's or prefixes, breaking SLAAC. Unfortunately they hate letting consumers talk with their engineers so it's difficult to speculate this further. For now, I've put a stateful firewall appliance in front of the probe which provides SLAAC, it works just fine. Do you think a DHCPv6 client should be implemented?

8 13

Meta-information dumps for built-in measurements?
by Vasileios Giotsas 09 Nov '20

09 Nov '20

Is there any repository like https://ftp.ripe.net/ripe/atlas/measurements/ that contains meta-information about built-in RIPE Atlas measurements (the above repository contains meta-information only for public measurements)? I couldn't find anything similar in the new FTP repository at https://data-store.ripe.net/datasets/atlas-daily-dumps/ I guess using the API is an alternative but it would be more convenient to have such dumps Thanks, Vasileios

15 24

RIPE Atlas usage webinar (and software probe installation demo)
by Lia Hestina 02 Sep '20

02 Sep '20

Dear all, The RIPE NCC will host a two day RIPE Atlas webinar with two RIPE Atlas ambassadors as guest trainers, Anurag Bhatia and Swapneel Patnekar. If you are interested in learning to use RIPE Atlas for network monitoring and troubleshooting, and also learning how to install a RIPE Atlas software probe, please join us tomorrow. More information is available here: https://atlas.ripe.net/resources/training-and-materials/innog-webinar/ <https://atlas.ripe.net/resources/training-and-materials/innog-webinar/> If you would like to participate, please send an email to e-learning(a)ripe.net <mailto:e-learning@ripe.net>. Thank you, Lia Hestina

7 11

Disabling TLS 1.0 and 1.1 on RIPE Atlas anchors
by Robert Kisteleki 01 Sep '20

01 Sep '20

Dear RIPE Atlas users, We received reports that the availability of TLS 1.0 and 1.1 on RIPE Atlas anchors triggers some security alarms for some anchor hosts. Since the anchors don't host anything sensitive, and the measurment code is not expected to be affected by this, we will stop supporting these protocols on the anchors (*) as of *1 September*. We'll carry on with supporting TLS 1.2 (*) the RIPE Atlas website/UI will be unchanged for the time being although we expect similar changes in the near future Regards, Robert Kisteleki RIPE NCC

3 5

RIPE Atlas Remote Learning session in September 2020
by Lia Hestina 31 Aug '20

31 Aug '20

Dear all, The RIPE NCC will organise a remote learning session for RIPE Atlas. Monitor your network and troubleshoot it with RIPE Atlas. Create specific tailor-made measurements that suit your exact needs using API calls or the command line interface. After this session, you will be able to: Monitor your network using RIPE Atlas measurements Troubleshoot your network using measurements from RIPE Atlas Use the RIPE Atlas command line interface and the API to create tailor-made measurements Pre-requisites: Basic knowledge of networks How the Internet works Basic knowledge of IP, ASN, domains Familiarity with pings and traceroutes Thursday, 17 September 2020, Timezone in UTC 08:00-10:00 <https://www.timeanddate.com/worldclock/converter.html?iso=20200917T080000&p…> Registration: RIPE NCC member, register here: https://lirportal.ripe.net/training/register/courseCode/MET20200006 <https://lirportal.ripe.net/training/register/courseCode/MET20200006> For non members please send an email with your name and email address to training(a)ripe.net <mailto:training@ripe.net> If you have any question about the event, please send email to training(a)ripe.net Kind regards, RIPE Atlas team _________

1 0

WARNING - was Re: Trying to measure Quad9 latency
by Robert Kisteleki 14 Aug '20

14 Aug '20

Dear All, The email below made it to the mailing list, but it seems it so had an attachment which contains a virus. It may be useful to say it explicitly: DO NOT OPEN THE ATTACHMENT Regards, Robert On 2020-08-12 09:09, ripe-atlas wrote: > Re: [atlas] Trying to measure Quad9 latency > > ripe-atlas > ripe-atlas-bounces(a)ripe.net > > [snip]

1 0

[Moderated]
by ripe-atlas 12 Aug '20

12 Aug '20

This message was removed from the archive because it contained malware.

1 0

Re: [atlas] [RIPE-NCC/ripe-atlas-software-probe] Software probes only connect to one controller? (#45)
by Chriztoffer Hansen 10 Aug '20

10 Aug '20

On Mon, 3 Aug 2020 at 12:14, Philip Homburg <notifications(a)github.com> 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

2 1