December 2018 - ripe-atlas - mailman.ripe.net

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

shared fate for my two probes
by Jay Borkenhagen 08 Feb '19

08 Feb '19

Hi, My two RIPE Atlas probes have been acting strangely over the past several months. Very frequently I receive automatic notices from the RIPE Atlas system that both of my probes have been "disconnected from the RIPE Atlas infrastructure" essentially simultaneously. Here's the history from 2018: probe 11171 2018-02-23 18:08:57 UTC. probe 11203 2018-02-23 18:10:23 UTC. probe 11171 2018-06-21 04:32:15 UTC. probe 11203 2018-06-21 04:30:59 UTC. probe 11171 2018-06-24 05:36:57 UTC. probe 11203 2018-06-24 05:37:04 UTC. probe 11171 2018-07-31 20:25:27 UTC. probe 11203 2018-07-31 20:25:32 UTC. probe 11171 2018-08-18 04:48:20 UTC. probe 11171 2018-09-15 02:31:26 UTC. probe 11203 2018-09-15 02:31:28 UTC. probe 11171 2018-10-15 23:03:50 UTC. probe 11203 2018-10-15 23:04:06 UTC. probe 11171 2018-11-16 14:42:28 UTC. probe 11203 2018-11-16 14:42:33 UTC. (Those last three events are eerily periodic.) Each time when I am finally able to visit inspect the probes (both are reported as "Firmware Version 4940 (1100)"), their LEDs are in the same state: --------------- Looking at the units with the on/off LED to the left: (1) the left-most (on/off) LEDs are on steadily. (2) the next LED is off. the next two LEDs are flashing at different frequencies: (3) the next flashes on approx. 48 times per minute (4) the next flashes on approx. 110 times per minute (5) the centers of the wide "WPS/RESET" LEDs are on steadily. --------------- Once these probes fail they remain offline until I try turning it off and on again. The probes are powered similarly: the RIPE-provided USB cable is plugged into an Apple iPhone USB power adapter, in turn plugged into a standard US 120v / 60 Hz AC receptacle. However, the AC power circuits feeding these receptacles come from two very different sources which should not share fate. Until today both probes have been plugged into ports on the same Cisco switch, but after today's disconnect I moved probe 11203 to a different physical switch that has the same VLANs. None of my other equipment experiences any troubles around the times when these events happen to my RIPE Atlas probes. In the past I have reported these events to atlas(a)ripe.net, but I doubt that the causes cited (e.g. "the problem is with your dns") have been accurate. (I do not blame the atlas(a)ripe.net folks who have responded. Something strange is happening here, and I haven't yet cracked it.) I'm curious whether anyone else sees similar behaviors, or has suggestions for ways to determine what is happening. Thanks! Jay B.

3 5

New on RIPE Labs: RIPE Atlas Probes: Delays in Distribution
by Mirjam Kuehne 08 Feb '19

08 Feb '19

Dear colleagues, The good news: RIPE Atlas is growing both in terms of geographical diversity and ASN coverage. What's more, RIPE Atlas is evolving, with a new generation of probe hardware having already passed the test phase and a pilot programme underway to assess the viability of VM anchors. The not so good news: With RIPE Atlas so much in demand, and with our current provider having ceased manufacturing the probe hardware, we've had to dramatically reduce the number of probes we're distributing. Please find more details on RIPE Labs: https://labs.ripe.net/Members/alun_davies/ripe-atlas-probes-delays-in-distr… Kind regards, Mirjam Kühne RIPE NCC

5 5

Data in the Internet Maps
by Davey Song(宋林健) 21 Dec '18

21 Dec '18

Hi Atlas people, <I did not receive mails from this list months ago. I hope it still works.> I’m writing to ask about the Data repo in the intnernet maps. For example I would like to study the DNS root RTT statistics in this page : https://atlas.ripe.net/results/maps/rtt-fixed/ Where and How should I get the access to this data. Best regards, Davey

3 6

testing DNS flag day compatibility
by Petr Špaček 19 Dec '18

19 Dec '18

Hello everyone, this is follow-up from RIPE 77 hallway discussion, sorry for delay. We are looking for ways to test DNS flag day [1] compatibility from client networks. Objective is to test hypothesis that most breakage happens on authoritative side of DNS. In other words, we would like to test that DNS recursive infrastructure and client networks do not significantly influence compatibility. That would help to provide precise information for network operators who will have to deal with DNS flag day. Problem here is that RIPE Atlas does not allow to send all types of queries [2] required for full test. It was discussed at length that Atlas team has its reasons for not sending random blobs to random IP addresses, which is understood. Question here is: Can we find a middle ground to allow greater variety of valid DNS queries without forcing Atlas team to reimplement everything? My notes from meeting mention two approaches for further dicussion: a) User provides command line arguments for well-known tool dig, which gets executed in controlled environment ("as part of RIPE Atlas infrastructure") and generates query packet/blob. This blob generated by dig is then used as payload so use cannot ship anything but syntactically valid DNS packet. b) User provides blob for payload, which is then analyzed by packet parser of choice (BIND/ldns/Knot DNS/all of them). The payload can be sent out only if packet parsers do not find out any problem/blob is syntactically valid. These two approaches can also be combined to guard again quirks in either component. c) <propose your own here> What do you think? Is there a way to allow greater flexibility to Atlas DNS? [1] https://dnsflagday.net/ [2] https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing/blob/master/genr… -- Petr Špaček @ CZ.NIC

2 4

Long response times using one-off measurements with old probes
by Moritz Muller 17 Dec '18

17 Dec '18

Hi, I would like to point you to a discussion on the DNS-OARC mailing list: https://lists.dns-oarc.net/pipermail/dns-operations/2018-December/018196.ht… One of the operators at .ca noticed that old probes report way higher response times using DNS CHAOS queries (300% or more) (see also [3]). After some digging, we came to the conclusion that this has to do with the fact that he is carrying out “one-off” measurements. When carrying out the same query for a longer time, we cannot observe this delay. The issues seems to be that one-off measurements are scheduled at probes using a different library than measurements that run for a longer period (“eooqd” instead of “eperd”). Some small additional delays have been documented before on the RIPE Atlas website and in research papers [1, 2], but the big delay with one off measurements was new to me. Also to others? Is our assumption correct that the scheduler is the culprit? Moritz [1] https://dl.acm.org/citation.cfm?doid=2805789.2805796 [2] https://clarinet.u-strasbg.fr/~pelsser/publications/Holterbach-ripe-atlas-s… [3] https://atlas.ripe.net/measurements/18086197/#!probes

2 3

API is sluggish
by Ponikierski, Grzegorz 11 Dec '18

11 Dec '18

Hi all! Did you notice that for last few days API is super slow to response. It takes something like few minutes to get reply. Do you observe any issue with Atlas infrastructure? What details I should provide to help with troubleshoot? Regards, Grzegorz

2 3