- ripe-atlas - mailman.ripe.net

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