October 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

Request for credits for research
by Mohan, Nitinder 20 Apr '21

20 Apr '21

Dear RIPE community, I hope you are all safe and sound. I am a Postdoctoral fellow at the Technical University of Munich, Germany. We are currently working on an ongoing research project which aims to analyze the availability and reachability of cloud data centers globally. The first work of our work will appear in ACM HotNets 2020 titled "Pruning Edge Research with Latency Shears" (http://conferences.sigcomm.org/hotnets/2020/program.html). We are currently preparing the camera-ready version of the paper and will share it with the community by hosting it (and the associated dataset) publicly soon. We are currently planing to submit the second leg of our work to a conference with submission deadline a month. In order to complete all set of measurements for required analysis, we are scheduling very large-scale measurements over the platform which has burned through almost all our credits and left us in need. I have always found the RIPE Atlas community to be helpful and generous towards research and I am hoping that you could support our research by donating us some of your spare credits. Your help will be highly appreciated. My RIPE account is nitinder.mohan(a)helsinki.fi Thanks and Regards Nitinder Mohan Postdoctoral Fellow Technical University of Munich, Germany <http://www.cs.helsinki.fi/u/nmohan/>https://www.nitindermohan.com/

15 18

Planned changes to "measurement archive"
by Robert Kisteleki 12 Nov '20

12 Nov '20

Dear RIPE Atlas users, You may be aware that we publish "measurement metadata dumps" on "FTP" (https://ftp.ripe.net/ripe/atlas/measurements/) every week. These are meant to make the complete measurement metadata downloadable for those who are interested. Even though there is still a point in publishing our metadata in a downloadable format, the current method is not sustainable: as it is defined it'll grow forever - which is not realistic. Currently *every* dump contains *all* the measurements we *ever* had in the system. We plan to change that to "everything that's running now + everything that was running in the last two weeks". This has about 200k items currently. If we published this every day instead of once a week, we will still only produce 10% of the output we do today - by virtue of eliminating 90% of redundancy and repeated work. The syntax and semantics of the content will not change. We will keep the existing dumps as they are mostly because there's no reason to remove them. What this means for users is: * if you care about "current / recent" measurements, you can just use the last dump from yesterday * if you really need all (or a large part of) history, you can fetch one dump per 2 weeks or so and combine them * you can still use the API for random, finite searches We plan to implement the above change just after RIPE 81 (i.e. early November). Please be aware of this change if you rely on these dumps. Regards, Robert

1 1

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

DoH / DoT test in Atlas Probes
by Imre Tuskes 02 Nov '20

02 Nov '20

Hello, Is there any plan to measure DNS over HTTPs (or TLS). We are interested in the performance of this kind of service. Regards, Imre

2 1

Re: [atlas] measurements not starting
by Viktor Naumov 29 Oct '20

29 Oct '20

Sorry, my bad. I didn't rub my eyes enough. Indeed the reason is different. What I can see from the logs is that the scheduler couldn't find any probe in AS4771 that would be capable of doing v6 measurement. wbr /vty On 10/29/20 8:35 AM, Povl Ole Haarlev Olsen wrote: > On Thu, 29 Oct 2020, Viktor Naumov wrote: >> The times shown on the page are in UTC. So your measurement should >> start in about 1h 15 minutes from the current moment. > > 2020-10-28 was yesterday. > >> On 10/29/20 7:12 AM, Yang Yu wrote: >>> SCHEDULED from >>> 2020-10-28T08:41:35Z >>> to >>> 2020-11-11T00:35:07Z >>> every 900s >

2 3

measurements not starting
by Yang Yu 29 Oct '20

29 Oct '20

Hi, I created 2 measurements with start time now, but neither started after 1 day https://atlas.ripe.net/measurements/27881135/ https://atlas.ripe.net/measurements/27881134/ > SCHEDULED from 2020-10-28T08:41:35Z to 2020-11-11T00:35:07Z every 900s >none of requested probes got scheduled SCHEDULED None yet Number of probes actually scheduled for this measurement What am I missing here? Thanks. Yang

3 2

RIPE Atlas Deployathon - 25 November 2020
by Lia Hestina 27 Oct '20

27 Oct '20

Dear colleagues, As part of the 10th anniversary of RIPE Atlas, we're organising a virtual RIPE Atlas software probe deployathon. Join us on 25 November 2020 to help us celebrate 10 years of RIPE Atlas by adding 10x10 software probes over 10 hours! You can get much more information about the event in this RIPE Labs article: https://labs.ripe.net/Members/becha/lets-deploy-together-ripe-atlas-softwar… Feel free to share it with your local communities and hopefully we’ll see you all on 25 November! Kind regards, Lia Hestina RIPE NCC _________

1 0

Result processing glitch
by Robert Kisteleki 12 Oct '20

12 Oct '20

Dear RIPE Atlas users, Today one of our controllers (a component that handles probes and deals with their submitted results) was updated to run a new version of result processing code. Unfortunately this code had a bug that caused results to be mixed up. As a result, some of the results that were delivered by this controller were of the wrong type / syntax, which may result in errors in processing this data. We reverted this change as soon as we detected the error. This issue likely affected results delivered by about 2% of our probes, between 13:30 and 15:15 (CEST). We apologise for the inconvenience. Regards, Robert Kisteleki RIPE NCC

1 0