- ripe-atlas - mailman.ripe.net

Time difference between results and update of measurement status
by Vasileios Giotsas 25 Feb '19

25 Feb '19

I've seen that the status of a measurement is updated much later than when the measurement results become available. For instance, while the RTTs of a ping measurement are returned the status is still Ongoing for up to 3 minutes. Is there anything (such as sanity checks) that intervenes between the update of the results and and update of the measurement status, which may change the results? Or is it safe to assume that once the results are out the measurement status will eventually change to 'Stopped', just a bit later? Thanks! Vasileios

2 1

Issue with RIPE Atlas HTTP measurements
by Philip Homburg 19 Feb '19

19 Feb '19

We recently discovered an issue with RIPE Atlas HTTP measurements. In trying to fix an issue that caused the HTTP body size to be reported incorrectly, we inadvertently introduced a bug that prevents the measurement from working under certain conditions. This bug affects firmware release 4940 and the upcoming releases 4950 and 4960. The combination that fails is a recurring measurement after the first run with an HTTP server that returns the body as chunks. This means that one-off measurements are fine. Unfortunately, HTTP measurements that are part of anchoring measurements are affected. We will work to fix this issue in the first firmware release after 4960, which can be expected in the next couple of months. We apologise for the ongoing issue and will keep you informed as we work to resolve it. Philip

1 0

Re: [atlas] "Cannot resolve" tag on IPv6-only network?
by ripe＠brite.cz 14 Feb '19

14 Feb '19

https://atlas.ripe.net/about/faq/#i-have-an-ipv6-only-network-will-the-prob… says I have an IPv6-only network. Will the probe work on it? Yes. All probes can be configured statically with an IPv6 address, default router, DNS resolvers, etc. through the web UI. In addition, version 3 probes can be fully configured through router advertisements (support for RFC 6106 was added in firmware release 4680). There is at the moment no support for DHCPv6 (RFC 3315). Version 1 and 2 probes can obtain addresses and default routers through router advertisements, but cannot obtain DNS resolvers that way. For those probes, the DNS resolvers will have to be configured statically through the web UI. ______________________________________________________________ > Od: "Lorenzo Colitti" <lorenzo(a)google.com> > Komu: "Anand Buddhdev" <anandb(a)ripe.net> > Datum: 14.02.2019 12:47 > Předmět: Re: [atlas] "Cannot resolve" tag on IPv6-only network? > > CC: <ripe-atlas(a)ripe.net> >On Sat, Feb 9, 2019 at 7:47 PM Lorenzo Colitti <lorenzo(a)google.com> wrote: > >> IPv6-only networks are certainly supported, but if the probe isn't aware >>> of any DNS resolver, then it's not going to be able to do any of its own >>> DNS lookups, and that's why it's been tagged with the "cannot resolve" >>> tags. >>> >> >> Hmm. The network announces IPv6 DNS servers via RDNSS, and as far as I >> know, they work. Does the probe support RDNSS? >> > >I turned on IPv4 on that subnet and things started working again. That >makes me think that the probe doesn't support RDNSS. Can anyone confirm or >deny? Should I file a bug? > >

2 1

"Cannot resolve" tag on IPv6-only network?
by Lorenzo Colitti 14 Feb '19

14 Feb '19

My probe v1 is on an IPv6-only network with NAT64 and DNS64. In the web UI I see it's tagged with "cannot resolve A" and "cannot resolve AAAA". Are IPv6-only networks supported? Is this because the network doesn't have a DHCP server? Something else?

2 3

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

Re: [atlas] New on RIPE Labs: RIPE Atlas Probes: Delays in Distribution
by Gert Doering 08 Feb '19

08 Feb '19

Hi, On Fri, Feb 08, 2019 at 03:32:38PM +0100, Philip Homburg wrote: > On 2019/02/08 13:45 , Micha Bailey wrote: > > Interesting. This seems like a much higher power device. What are the > > actual power requirements? So far my probe has been powered from the USB > > port on the router, and I???m concerned that this may make the > > installation of future probes more difficult. > > The power requirements are quite reasonable when used as an Atlas probe. > There should be no problem powering a v4 probe from a USB port. My v4 probe is fed from an USB port on an older Mac Mini, with no adverse effects I can see. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

New RIPE Atlas measurement details page
by Alun Davies 31 Jan '19

31 Jan '19

Dear colleagues, We have made the switch to the new and improved user interface for RIPE Atlas measurement details. To see the new interface right now, simply click on any measurement ID on the RIPE Atlas measurement listing page: https://atlas.ripe.net/measurements/ <https://atlas.ripe.net/measurements/> Please note that, for a limited time, you will still be able to revert back to the old interface via the yellow banner at the top of the measurement details page. For further details on exactly what changes have been made and why, please see the following article on RIPE Labs: https://labs.ripe.net/Members/jasper_den_hertog/new-design-and-functionalit… <https://labs.ripe.net/Members/jasper_den_hertog/new-design-and-functionalit…> Kind regards, Alun Davies RIPE NCC

2 1

EDNS Client Subnet
by Rami Al-Dalky 31 Jan '19

31 Jan '19

Hello, I was exploring the possibility of using RIPE Atlas probes to do some study on EDNS Client Subnet (ECS), however, the way it is implemented on the probes makes it less interesting. When I tried to create a DNS measurement, I found that the only way to send DNS query with option is to set default_client_subnet to True. However, by setting this option, a DNS query will be sent with 0.0.0.0/0 as client subnet. According to the RFC, a compliant resolver which receives such content SHOULD NOT forward the client IP to the Auth. DNS server (which the same behavior when you set the flag to False). That's make it impossible to study the protocol from Auth. DNS perspective. Is there a reason why ECS is implemented that way? If it for privacy issue, the RFC recommends to sent the client IP with /24 prefix for IPv4 and /56 for IPv6 to preserve the privacy. Thanks in advance! Rami

3 3

Columns in Web UI for measurement results can't be sorted
by Evgeniy S. 31 Jan '19

31 Jan '19

Hi, I can't sort by any column in measurement results for traceroute (worked before by mouse click). [image: Screen Shot 2019-01-31 at 2.14.52 PM.png] There is my measurement results page short link https://goo.gl/iQrxWC -- -- With regards, Eugene Sudyr

1 0

Bug in DNS client subnet measurement
by Philip Homburg 31 Jan '19

31 Jan '19

Hi, We got a bug report that using the DNS client subnet option in a measurement results in a form error. It turns out that probe firmware version 4940 will send a malformed DNS query. Code cleanup related to other changes fixes this issue in the upcoming firmware. We expect to release the new firmware in about one month from now. Philip

1 0

Probe v1 disconnecting every 2 hours
by Hugh Saunders 30 Jan '19

30 Jan '19

Hey All, My probe v1 (id:65[1]) has started disconnecting roughly every 2 hours. I read a previous post[2] that said this may be related to power, so changed the USB power supply to one that provides 1A (the FAQ says the need 500ma) but no improvement. I don't notice connectivity issues every couple of hours with any other devices on the same switch. Any suggestions welcome :) Thanks. [1] https://atlas.ripe.net/probes/65/ [2] https://www.ripe.net/participate/mail/forum/ripe-atlas/PDI1MDc1YjM1LTA5MTct… -- Hugh Saunders

5 5

DNSEC Tag for Probes
by Philippe Mächler 28 Jan '19

28 Jan '19

Hello RIPE Atlas Users I’d like to some measurements about DNSSEC with RIPE Atlas and need a way to check if the probe does DNSSEC validation The docs mention the system-tags e.g resolvs A and resolvs AAAA. Is there something like “system: does DNSSEC validation” if not, is there any other way or is this on the roadmap? 😊 Freundliche Grüsse / best regards Philippe Mächler

1 0

Making a bunch of tests/measurements to a single destination is 'tedious'
by Christopher Morrow 24 Jan '19

24 Jan '19

howdy! So, if I have a dns server somewhere and I want to make a bunch of measurements: "how does NYC see my dns?" (pick N probes near NYC) "How does DEN see my dns?" (pick N probes near DEN) "How does LHR see my dns?" (pick N probes near LHR) "how does ...." ...you get the idea... I'm trying to characterize my service from a 'user' perspective by large Metropolis, well within N km of that metropolis anyway :) but across ~70 or so metros, in v4 and v6 and with authoritative and non-authoritative queries with each test running for 4 days so i can see some daily cycles in traffic patterns/etc. The number of measurements is large in total, breaking up by 3-4 metropolis chunks is super tedious :( Can I request an API key (or some other thing) which can make that sort of request happen for all my measurements in one go? The thing I'm probing is very able to handle a few extra thousand queries per second.. and I'd only be hurting myself i get my estimate wrong :) thanks! -chris

3 4

New on RIPE Labs: RIPE Atlas Anchors 400+
by Alun Davies 24 Jan '19

24 Jan '19

Dear colleagues, We have published an article looking at how the quick uptake in RIPE Atlas VM anchors and other developments have helped us hit 400 connected anchors. https://labs.ripe.net/Members/alun_davies/ripe-atlas-anchors-400 <https://labs.ripe.net/Members/alun_davies/ripe-atlas-anchors-400> Kind regards, Alun Davies RIPE NCC

1 0

Probe questions - reporting clearly busticated probe configs?
by Christopher Morrow 23 Jan '19

23 Jan '19

Howdy! I've been running a few measurements over the last while and looked at the raw results like: [{"dst_name":"2001:4860:4860::8844","error":{"socket":"connect failed Network is unreachable"},"from":"fd84:d527:5183:0:a2f3:c1ff:fec4:63a8","fw":4940,"group_id":18903906,"lts":21,"msm_id":18903906,"msm_name":"Tdig","prb_id":13635,".... "from":"2001:db8:4447:0:eade:27ff:fec9:7134","fw":4940,"group_id":18903906,"lts":7,"msm_id":18903906,"msm_name":"Tdig","prb_id":26725,"...] I'm curious if/how atlas reports back to probe owners: "Hey, your ipv6 connectivity is implausible/impossible" since, at least for: https://atlas.ripe.net/probes/26725/#!tab-network and: https://atlas.ripe.net/probes/13635/#!tab-network there's no way their v6 addresses can work... (one is documentation prefix the other is ULA I think?) I suppose test requestors should check the ipv6 prefix to see if it's at least plausibly correct until some signal back to the owners can be attempted?

5 8

Re: [atlas] IPv6 Doesn't Work
by ripe＠brite.cz 22 Jan '19

22 Jan '19

Hi, you pointed me to the right way. I enabled IPv6 on my Windows Laptop and it show the same symptoms - it receives an IPv6 address but is not able to reach any IPv6 target. My setup looks like this: Atlas Probe > Ubiquiti airRouter > provider's WIFI AP When I connect my laptop stright to the provider's WIFI AP then IPv6 works all fine. When I connect to LAN port of my airRouter, it receives an IPv6 address but is not able to reach any IPv6 target. So the point of failure seems to be my router. It is set to Bridge mode with WIFI as a client, connected to provider's AP. Per the Manual: ---------------------------------------------------------- Bridge In Bridge mode, the AirRouter forwards all network management and data packets from one network interface to the other without any intelligent routing. For simple applications this provides an efficient and fully transparent network solution. WLAN (wireless) and LAN (Ethernet) interfaces belong to the same network segment and share the same IP address space. WLAN and LAN interfaces form the virtual bridge interface while acting as the bridge ports. The bridge has assigned IP settings for management purposes. ---------------------------------------------------------- The Bridge management interface shows following addresses assigned: 10.0.0.29 2A00:1028:8D1C:90DA:DE9F:DBFF:FE5C:632B/64 FE80::DE9F:DBFF:FE5C:632B/64 I would think the Bridge mode should not interfere the traffic in any way. I have read only access to the provider's AP - it is cheap router with IPv4 NAT and IPv6 interfaces. It shows an IPv6 address [starting with 2a00:1028:] on its WAN IPv6, LAN IPv6, IPv6 Default Gateway, IPv6 DNS server, etc. As I said, when I connect laptop stright to the provider's AP, IPv6 works. I'm unable to to setup my airRouter for IPv6 to work. It supports IPv6, but in bridge mode it has no settings available. I tried multiple factory resets, with various settings, and also tried to switch the airRouter to SOHO Router mode, then there is IPv6 Enable checkbox. While it is checked, I tried various settings, such as SLAAC, DHCPv6, etc. No go. Looks the IPv6 support in this router is broken. It's a pity I cannot connect Atlas Probe v3 stright to the provider's WIFI eventhough it has WIFI hardware onboard. There is no way I could connect stright by LAN cable to the provider. It looks for now I have to leave the Probe live with IPv6 broken. Cheers Jiri ______________________________________________________________ > Od: "Stephen D. Strowes" <sds(a)ripe.net> > Komu: ripe(a)brite.cz, ripe-atlas(a)ripe.net > Datum: 22.01.2019 10:51 > Předmět: Re: [atlas] IPv6 Doesn't Work > >Hi, > >On 19/01/2019 17:26, ripe(a)brite.cz wrote: >> Traceroute to 2001:503:ba3e::2:30 (2001:503:ba3e::2:30), 40 byte packets >> 1 * 2a00:1028:8d1c:90da:220:4aff:fee0:2026 dynamic-2a00-1028-8d1c-90da-0220-4aff-fee0-2026.ipv6.broadband.iol.cz AS5610 2191.889ms !H 3010.564ms !H > > From `man traceroute6`: > > > !H Address unreachable > > The host address is not reachable for some other reasons, >particularly a link- > > layer failure (e.g. Neighbor discovery failure). > >Obviously that's not great! > >The probe has a v6 address, so it's solicited and received some network >config when it was booted or when your network config changed a couple >days ago. Question is, what happened next. > >Guessing around the symptoms, if it's not receiving subsequent periodic >RAs (either the router isn't sending them or something is preventing the >probe from receiving them), then its local routing state will expire. > >Questions I'd try and answer are: when you connect a device to the same >network, does it a) receive a v6 network & generate an address, then b) >does v6 work immediately after that, and c) does it fail after a while? > > >S. > > > > >> >> ______________________________________________________________ >>> Od: ripe(a)brite.cz >>> Komu: ripe-atlas(a)ripe.net >>> Datum: 19.01.2019 17:23 >>> Předmět: Re: [atlas] IPv6 Doesn't Work >>> >>> No filtering here. Furthermore it seems the Atlas Probe is not able to get anywhere out via IPv6 too. >>> I'm wondering is the Gateway setting correct? [Gateway(s) fe80::1] >>> >>> --------------------------------- >>> Peter Eckel lists at eckel-edv.de >>> Sat Jan 19 11:26:33 CET 2019 >>> >>> Hi Jiri, >>> >>> for me it looks like you're not reachable indeed: >>> >>>> pete at charon.net.hindenburgring.com> traceroute inet6 2a00:1028:8d1c:90da:220:4aff:fee0:2026 >>>> traceroute6 to 2a00:1028:8d1c:90da:220:4aff:fee0:2026 (2a00:1028:8d1c:90da:220:4aff:fee0:2026) from <xxx>, 64 hops max, 12 byte packets >>>> [...] >>>> 3 2a00:19e0:ffff:fffc::1 (2a00:19e0:ffff:fffc::1) 23.579 ms 23.308 ms 23.495 ms >>>> 4 2a00:19e0:ffff:ffff::3 (2a00:19e0:ffff:ffff::3) 29.521 ms 29.738 ms 29.822 ms >>>> 5 ae0-401.fra10.core-backbone.com (2a01:4a0:1338:2::1) 30.063 ms 29.215 ms 36.436 ms >>>> 6 ae2-2001.nbg30.core-backbone.com (2a01:4a0:0:2001::1) 32.540 ms 31.789 ms 51.790 ms >>>> 7 ae1-2053.prg10.core-backbone.com (2a01:4a0:0:2053::22) 37.175 ms 36.355 ms 35.141 ms >>>> 8 nix4-ipv6.pater.iol.cz (2001:7f8:14::29:1) 39.033 ms 36.891 ms 37.997 ms >>>> 9 dynamic-2a00-1028-0001-0160-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:160::2) 38.403 ms 41.560 ms 37.239 ms >>>> 10 dynamic-2a00-1028-0001-02a5-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:2a5::2) 37.214 ms 50.273 ms 51.604 ms >>>> 11 * * * >>>> 12 dynamic-2a00-1028-8d1c-90d8-0000-0000-0000-0001.ipv6.broadband.iol.cz (2a00:1028:8d1c:90d8::1) 44.291 ms 58.819 ms 49.810 ms >>>> 13 * * * >>>> 14 * * * >>>> 15 * * * >>>> 16 * * * >>>> 17 * * * >>>> 18 * * * >>>> 19 * * * >>>> [...] >>> Are you by any chance filtering ICMPv6 on your ingress router? >>> >>> Regards, >>> >>> Peter. >>> >>> >>> >> > >

1 0

Re: [atlas] IPv6 Doesn't Work
by ripe＠brite.cz 22 Jan '19

22 Jan '19

all the IPv6 traceroutes go like this: Latest Traceroute Result for Measurement #2009 2019-01-19 15:25 UTC Traceroute to 2001:503:ba3e::2:30 (2001:503:ba3e::2:30), 40 byte packets 1 * 2a00:1028:8d1c:90da:220:4aff:fee0:2026 dynamic-2a00-1028-8d1c-90da-0220-4aff-fee0-2026.ipv6.broadband.iol.cz AS5610 2191.889ms !H 3010.564ms !H ______________________________________________________________ > Od: ripe(a)brite.cz > Komu: ripe-atlas(a)ripe.net > Datum: 19.01.2019 17:23 > Předmět: Re: [atlas] IPv6 Doesn't Work > >No filtering here. Furthermore it seems the Atlas Probe is not able to get anywhere out via IPv6 too. >I'm wondering is the Gateway setting correct? [Gateway(s) fe80::1] > >--------------------------------- >Peter Eckel lists at eckel-edv.de >Sat Jan 19 11:26:33 CET 2019 > >Hi Jiri, > >for me it looks like you're not reachable indeed: > >> pete at charon.net.hindenburgring.com> traceroute inet6 2a00:1028:8d1c:90da:220:4aff:fee0:2026 >> traceroute6 to 2a00:1028:8d1c:90da:220:4aff:fee0:2026 (2a00:1028:8d1c:90da:220:4aff:fee0:2026) from <xxx>, 64 hops max, 12 byte packets >> [...] >> 3 2a00:19e0:ffff:fffc::1 (2a00:19e0:ffff:fffc::1) 23.579 ms 23.308 ms 23.495 ms >> 4 2a00:19e0:ffff:ffff::3 (2a00:19e0:ffff:ffff::3) 29.521 ms 29.738 ms 29.822 ms >> 5 ae0-401.fra10.core-backbone.com (2a01:4a0:1338:2::1) 30.063 ms 29.215 ms 36.436 ms >> 6 ae2-2001.nbg30.core-backbone.com (2a01:4a0:0:2001::1) 32.540 ms 31.789 ms 51.790 ms >> 7 ae1-2053.prg10.core-backbone.com (2a01:4a0:0:2053::22) 37.175 ms 36.355 ms 35.141 ms >> 8 nix4-ipv6.pater.iol.cz (2001:7f8:14::29:1) 39.033 ms 36.891 ms 37.997 ms >> 9 dynamic-2a00-1028-0001-0160-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:160::2) 38.403 ms 41.560 ms 37.239 ms >> 10 dynamic-2a00-1028-0001-02a5-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:2a5::2) 37.214 ms 50.273 ms 51.604 ms >> 11 * * * >> 12 dynamic-2a00-1028-8d1c-90d8-0000-0000-0000-0001.ipv6.broadband.iol.cz (2a00:1028:8d1c:90d8::1) 44.291 ms 58.819 ms 49.810 ms >> 13 * * * >> 14 * * * >> 15 * * * >> 16 * * * >> 17 * * * >> 18 * * * >> 19 * * * >> [...] > >Are you by any chance filtering ICMPv6 on your ingress router? > >Regards, > > Peter. > > >

2 1

Probe firmware source code
by Evgeniy S. 21 Jan '19

21 Jan '19

Dear community let me ask if probe os and services (aka firmware) source code available in public? Where I find it if yes, and why it's not public if not available? -- -- With regards, Eugene S

3 3

Re: [atlas] IPv6 Doesn't Work
by ripe＠brite.cz 19 Jan '19

19 Jan '19

No filtering here. Furthermore it seems the Atlas Probe is not able to get anywhere out via IPv6 too. I'm wondering is the Gateway setting correct? [Gateway(s) fe80::1] --------------------------------- Peter Eckel lists at eckel-edv.de Sat Jan 19 11:26:33 CET 2019 Hi Jiri, for me it looks like you're not reachable indeed: > pete at charon.net.hindenburgring.com> traceroute inet6 2a00:1028:8d1c:90da:220:4aff:fee0:2026 > traceroute6 to 2a00:1028:8d1c:90da:220:4aff:fee0:2026 (2a00:1028:8d1c:90da:220:4aff:fee0:2026) from <xxx>, 64 hops max, 12 byte packets > [...] > 3 2a00:19e0:ffff:fffc::1 (2a00:19e0:ffff:fffc::1) 23.579 ms 23.308 ms 23.495 ms > 4 2a00:19e0:ffff:ffff::3 (2a00:19e0:ffff:ffff::3) 29.521 ms 29.738 ms 29.822 ms > 5 ae0-401.fra10.core-backbone.com (2a01:4a0:1338:2::1) 30.063 ms 29.215 ms 36.436 ms > 6 ae2-2001.nbg30.core-backbone.com (2a01:4a0:0:2001::1) 32.540 ms 31.789 ms 51.790 ms > 7 ae1-2053.prg10.core-backbone.com (2a01:4a0:0:2053::22) 37.175 ms 36.355 ms 35.141 ms > 8 nix4-ipv6.pater.iol.cz (2001:7f8:14::29:1) 39.033 ms 36.891 ms 37.997 ms > 9 dynamic-2a00-1028-0001-0160-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:160::2) 38.403 ms 41.560 ms 37.239 ms > 10 dynamic-2a00-1028-0001-02a5-0000-0000-0000-0002.ipv6.broadband.iol.cz (2a00:1028:1:2a5::2) 37.214 ms 50.273 ms 51.604 ms > 11 * * * > 12 dynamic-2a00-1028-8d1c-90d8-0000-0000-0000-0001.ipv6.broadband.iol.cz (2a00:1028:8d1c:90d8::1) 44.291 ms 58.819 ms 49.810 ms > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > [...] Are you by any chance filtering ICMPv6 on your ingress router? Regards, Peter.

1 0

IPv6 Doesn't Work
by ripe＠brite.cz 19 Jan '19

19 Jan '19

Hi, I have Probe #2413 here, it shows label " IPv6 Doesn't Work". It has IPv6 address assigned: IPv6 Current Configuration Addresses 2a00:1028:8d1c:90da:220:4aff:fee0:2026/64 ASN 5610 Gateway(s) fe80::1 I'm not sure what's the issue. My provider provides IPv6, but I personally don't use IPv6 on any of my devices. I read https://atlas.ripe.net/about/faq/#i-have-an-ipv6-only-network-will-the-prob… but in this case it is not IPv6 only. I tried to give it static config but I couldn't find out what config to use. Any idea? Thanks Jiri

2 1

credit differences between probes?
by Christopher Morrow 18 Jan '19

18 Jan '19

howdy! (long time listener, first time caller...) I have some probes deployed, and for some period of time I was accruing credits at about the same rate per day per probe. Recently (last week or so?) I noticed that I now accrue at one rate for 1 device and a different rate for 2 other devices. The devices have been up for at least the last 24hrs: morrowc-fios 4 days, 5 hours 21.6k morrowc-comcast 1 week, 2 days 65.7k Atlas@deteque-IAD 3 weeks 21.6k (unsure why the fios one bobbled...but it's still be up for ~4days) Is this expected? or maybe I'm just in some wonky space with the accruals anyway?

3 6

New on RIPE Labs: Redesigning the RIPE Atlas Measurement Details Page
by Alun Davies 17 Jan '19

17 Jan '19

Dear colleagues, Today we published an article on some of the changes we’ve made to the RIPE Atlas measurement details page. The redesign follows work we’ve been doing to move over to a new back-end storage solution for RIPE Atlas measurement metadata. Click the link to find out more: https://labs.ripe.net/Members/jasper_den_hertog/new-design-and-functionalit… <https://labs.ripe.net/Members/jasper_den_hertog/new-design-and-functionalit…> Kind regards, Alun Davies RIPE NCC

1 0

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

DNS Measurement Grouping by NSID
by Klaus Darilion 30 Nov '18

30 Nov '18

Hi! IIRC, the map of the DNS measurement allowed to group the dataset by NSID. Was this feature removed? OR is it now somewhere else? I.e.: https://atlas.ripe.net/measurements/17175212/?filter=&diversity-picker=3&ag… Thanks Klaus

4 6

Minor change to Atlas anchor DNS resolver configuration
by Anand Buddhdev 28 Nov '18

28 Nov '18

Dear colleagues, Each RIPE Atlas anchor runs a DNS resolver. This resolver is configured as the primary resolver for the anchor, with the following directive at the top of the resolver configuration (/etc/resolv.conf): nameserver 127.0.0.1 For ease of configuration management, we are changing this directive to: nameserver ::1 This change will not affect DNS resolution on the anchors in any way. However, any measurement that does DNS lookups using the anchor's primary resolver will contain "::1" instead of "127.0.0.1" in "src_addr" field of results. If you're using any code to parse such results, and specifically looking for "127.0.0.1", you'll need to adjust your code to also look for "::1". Regards, Anand Buddhdev RIPE NCC

1 0

no measurements
by Teun Vink 20 Nov '18

20 Nov '18

Hi, Are there any problems with the Atlas backend? All requests are answered with {u'info': u'Something went wrong with our back-end', u'type': u'redis- fail'} I don't see any working measurements in our webportal as well. Best regards, -- Teun Vink BIT | teun(a)bit.nl | +31 318 648 688 KvK: 09090351 | GPG: 0xFC8B25D6 | RIPE: TEUN-RIPE

2 3

New on RIPE Labs: Announcing RIPE Atlas VM Anchors
by Alun Davies 12 Nov '18

12 Nov '18

Dear colleagues, 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 <https://labs.ripe.net/Members/alun_davies/ripe-atlas-anchor-vms> Kind regards, Alun Davies RIPE NCC

5 6

Temporary problem with RIPE Atlas measurement creation
by Chris Amin 01 Nov '18

01 Nov '18

Dear RIPE Atlas users, Due to a complication during a deploy, there was a problem scheduling RIPE Atlas measurements from approximately 12:50 to 14:14 UTC. Most new measurements created during this time will not have been scheduled properly. The issue is now fixed for new measurements, so if your measurements didn't work during this time you can try to create them again and it should work. Apologies for any inconvenience caused. Regard, Chris Amin RIPE NCC

1 0

Delays over the weekend
by Robert Kisteleki 29 Oct '18

29 Oct '18

Dear all, Some of you have noticed that there were delays in how RIPE Atlas behaved, starting on Saturday. This happened because of an issue deep in the bowels of the infrastructure which caused tasks (including measurement requests) to pile up. We believe the issue has been resolved by now, though we're still investigating the root cause of the issue. We apologise for the inconvenience this caused. Regards, Robert Kisteleki RIPE Atlas team

1 0

New set - wizard improvements suggestion
by Evgeniy S. 24 Oct '18

24 Oct '18

Dear All, finally we are using our ripe probes to monitor our resources from mobile networks. I found that current "new set - wizard" functionality is lacking some useful extra filters using: 1) "User tags" - then I can tag my mobile probes and select only mobile network probes from the list. 2) mine, favorites, sponsored, ambassadorships It will be also nice to request to tag mobile network probes for users who run them. Any feedback is appreciated. I'm also interesting for getting in touch with people who have probes installed in mobile networks to make tests / comparing to our setup. -- With regards, Eugene

1 0

Relocating a probe
by Gary Gapinski 20 Oct '18

20 Oct '18

Hello: I currently host a probe (#14102) at my residence. I will soon move to a new residence about 450 miles from the current location. Such a move will necessarily alter measurements obtained relative to past ones (as well as ASN, geolocation, etc.). Should the existing probe identity be retired in favor of a new identity? (And if so how might that be accomplished?) Regards, Gary

2 2

WG: Probe 1198 is disconnected (Keck.US)
by Cornelius Keck 07 Oct '18

07 Oct '18

Power outage. Repair ETA not yet available. Thx for the heads-up. Gesendet von meinem BlackBerry 10-Smartphone. Originalnachricht Von: RIPE Atlas (no reply) <no-reply(a)ripe.net> Gesendet: Sonntag, 7. Oktober 2018 16:30 An: ckeck(a)texoma.net Antwort an: RIPE Atlas (no reply) Betreff: Probe 1198 is disconnected (Keck.US) Dear Cornelius Keck, Your probe 1198 has been disconnected from the RIPE Atlas infrastructure since 2018-10-07 21:05:06 UTC. You may be able to learn more about the possible cause from the "Status" tab on your probe's information page: https://atlas.ripe.net/probes/1198/#!tab-status Probes are tagged with suspected problems every four hours, so if there is nothing listed under the Status tab and your probe has just gone offline, please check back in a few hours, as more information may be available. If you need further assistance or have any questions, please contact us at atlas(a)ripe.net. Kind regards, RIPE Atlas Team ********** This is an automatically generated email from RIPE Atlas. It was sent to you because you asked to be notified if your probe becomes disconnected for more than 15 minutes. If you want to change this, or disable this notification altogether, please go to https://atlas.ripe.net/probes/1198/, and click the "edit" button under "Notifications".

1 0

Definition of Commercial Use
by Mic Szillat 04 Oct '18

04 Oct '18

Hi folks, I have a discussion in my company about the definition of commercial use. Can we please get an official confirmation whether our typical usage of Atlas is covered by the terms of service? We occasionally use Atlas to debug network connectivity between our systems and those of our customers. We answer support requests and confirm or deny network issues based on the data collected. We do not give customers access to the measurement interface. Thanks, Mic

3 3

New on RIPE Labs: Measuring Anycast DNS Services Using RIPE Atlas
by Mirjam Kuehne 01 Oct '18

01 Oct '18

Dear colleagues, Please find this step-by-step guide contributed by Kenneth Finnegan on RIPE Labs on how to use RIPE Atlas to measure the world-wide performance of Anycast DNS services: https://labs.ripe.net/Members/kenneth_finnegan/measuring-anycast-dns-servic… Kind regards, Mirjam Kühne RIPE NCC

1 0

Extended CHAOS queries
by Moritz Muller 24 Sep '18

24 Sep '18

Hi all, I was wondering if it would be possible to extend the supported CHAOS TXT query arguments to trustanchor.unbound. and trustanchor.server? This would enable RIPE Atlas probes to measure which DNSSEC Trust Anchors Unbound and PowerDNS resolvers have configured (if they support this query). Cheers, Moritz

1 0

Is there a max running measurement number for a user
by Yihao Jia 30 Aug '18

30 Aug '18

Dear all, Is there a max running measurement number for a user? I try to launch about 800 measurements, but only about 150 of them succeed and keep running, while another 650 fail with the description "overlimited denied" one of the fail measurement is: https://atlas.ripe.net/measurements/15302198/ Do you know what's the reason I failed? (btw, I am wondering how to check the reason why a measurement is failed by the measurement id?) Many thanks, Yihao

3 2

Re: [atlas] Looking for advise and temporarily limits increment for research
by Alan Walker 30 Aug '18

30 Aug '18

https://www.ripe.net/participate/mail/forum/ripe-atlas/PENBTDZlRWUzUlR4ai1q… Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

The three generations of the Atlas probes : technical details
by BELLAFKIH hayat 30 Aug '18

30 Aug '18

Hi, I hope validate some details about the Atlas probes. I try to get these details by consulting the resources: 1. https://atlas.ripe.net/docs/probe-v1/ 2. https://atlas.ripe.net/docs/probe-v2/ 3. https://atlas.ripe.net/docs/probe-v3/ But no technical details given. By reading some presentations, I create the table bellow. Now, I hope if you can validate these details and complete the information about the CPU. It will be good if you can add the technical details for each generation of the probes. Thanks in advance. *Hayat BELLAFKIH*

3 3

need help in RIPE atlas credits
by Yihao Jia 28 Aug '18

28 Aug '18

Dear all, I am Yihao, a Ph.D. student at Tsinghua University. Right now I plan to start an experiment with the RIPE atlas, but I don't have enough credits to fulfill the whole process. I am writing this letter to inquire if anyone can share some credits with me. (like 1 Million) Appreciate! (My RIPE atlas account: yhjia.03(a)gmail.com) Many thanks, Yihao Tsinghua University

5 6

Getting More Traffic for Probe
by Eren Türkay 26 Aug '18

26 Aug '18

Hello, I am running a probe [0] at my home and I have 240Mbit connection from my provider. When I look at the graphs, this probe is basically sitting idle doing nothing! I can spare 20Mbit/s easily for measurements to keep the usage. However, I do not know how to achieve that. Is it possible to attract more traffic to my probe? I'm sure there is some algorithm involved to distribute the work so if you can please get me some more work, I'd be pleased [obviously more credits to spare :)] [0] https://atlas.ripe.net/probes/31252/ Regards, -- . 73! DE TA1AET http://erenturkay.com/

4 5

Probe for mobile network
by Evgeniy Sudyr 25 Aug '18

25 Aug '18

We have developed mobile application and we are interesting for making measurements from our customer''s networks using ripe atlas probes. I found no probes from interesting ASN, that's why I'm looking for a way to host own probes (we do have already) and connect it to interesting MNO networks using some USB sticks or even mobile phones (to use as 3G / LTE modem). Obviously we want to make less points of failure in between RIPE probe and mobile modem. Any luck to get USB sticks working with RIPE probe without some router in between? -- With regards, Eugene Sudyr

1 0

Looking for an AS8560 contact
by Robert Kisteleki 22 Aug '18

22 Aug '18

Hello, We're looking for a contact in the RIPE Atlas context from AS8560 (oneandone.net). There's a (probably runaway) script hammering our gates. Thank you, Robert Kisteleki for the RIPE Atlas team

1 0

Failled to get traceroute results from the id 5151
by BELLAFKIH hayat 16 Aug '18

16 Aug '18

Hi all, I am trying to get traceroute results for the measurements id 5151 ( https://atlas.ripe.net/measurements/5151/) by using python module : Python client for RIPE ATLAS API, for period october 2016. For many days ( eg : 19, 20) in this period, the operation is failled. I got Killed ! I found that the reason of having Killed when running a python script is related to the ressources limits. Any helps? *Hayat BELLAFKIH*

1 0

Probe limit per measurement
by Schomp, Kyle 08 Aug '18

08 Aug '18

Hi all, I'm trying to use Ripe Atlas for monitoring a production system. I've hit the 1k maximum probes per measurement limit, however. I realize I could just split up the task among multiple measurements to stay under the 1k probes max, but that seems sort of hack-ish and possibly less efficient for the platform. Is it possible to get the limits increased? Thanks! -kyle

2 1

Processing RIPE Atlas data as Big Data
by BELLAFKIH hayat 24 Jul '18

24 Jul '18

Dear RIPE Atlas users, I am studying the processing of the data collected by the probes as a Big Data problem. For instance, one hour of traceroute data count for 500 Mo (bzip2), so 7 Go of data in text format. Can you share with me how you deal with these data in practice. are you using a super machine, Big Data tools? best regards, Hayat

2 1

Looking for advise and temporarily limits increment for research
by Yihao Jia 22 Jul '18

22 Jul '18

To whom it may help, My name is Yihao. I am a Ph.D. student. Recently I am doing a research with RIPE Atlas. However, my research requires many measurements in a short period, which breaks several rules of the Rate Limits. Since I really like and in hurry to use Atlas to support my research, is there any advice I can get from this? I'd like to describe why it would be necessary for my research. And if possible, may I get a temporarily limit increment for 10 days? Many thanks, Yihao Jia

3 3