Re: [atlas] RIPE Atlas Software Probes
Hi Jordi, On Wed, Feb 12, 2020 at 11:02:36AM +0100, JORDI PALET MARTINEZ wrote: > Nice, thanks a lot for this! > > Do you have interest in people having actual hardware probes in places where > they also host VMs, to install also the software probes, in order to be able > to "compare" them? I mean for your own stats, or to be able to debug issues, > etc. > > Do you also have any info (overall) about impact on CPU/memory/other > consumption of the software probe and if there are important differences > among different platforms? > > By the way, it will be nice to have also a version for OpenWRT! Apparently the CZ.NIC people did most of the work already, because Turris is based on OpenWrt: https://wiki.turris.cz/doc/en/howto/atlas-probe That being said, nothing seems to have been submitted to the OpenWrt packages repository so far: https://github.com/openwrt/packages I agree, it would be nice to have this in the official OpenWrt repositories! > El 12/2/20 10:53, "ripe-atlas en nombre de Philip Homburg" > escribió: > > Dear colleagues, > > We are glad to announce that, after several months of development and > testing, we are now accepting applications for RIPE Atlas software > probes. With several different installation options to choose from, > software probes provide future hosts a whole new way to get involved > with RIPE Atlas. > > For more details, see our new article on RIPE Labs: > > https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes > > Kind regards, > Philip > > > > > > ** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of the > individual(s) named above and further non-explicilty authorized disclosure, > copying, distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited and will be > considered a criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > > > > -- Baptiste Jonglez PhD student / ATER Univ. Grenoble Alpes <https://www.univ-grenoble-alpes.fr/> Grenoble INP - Ensimag <https://ensimag.grenoble-inp.fr> LIG lab <https://www.liglab.fr/> Drakkar team <http://drakkar.imag.fr/> | Polaris team at INRIA <https://team.inria.fr/polaris/> signature.asc Description: PGP signature
Re: [atlas] Trying to measure Quad9 latency
Hi, On 22-11-17, Eduardo Duarte wrote: > Hi all, > > After the recent launch of the Quad9 service I try to discover if it had > a best response time them my actual resolver, that is google public DNS. > > To do this I launch a comparing measurement using atlas that would run > during one day to the same address from the probes in my ISP. > The address that I was trying has a very high TTL so I was expecting to > always hit the cache of the servers and them get a good comparison base. > I know that there are other factors involve in server response time but > to my home connection I fill that this where enough. Instead of asking for a regular name, you can query a special name like "version.bind" in the CHAOS class. These queries are always answered directly, so it simulates a 100% cache hit and allows you to measure the RTT towards a resolver. To test with dig: $ dig @9.9.9.9 CH version.bind TXT See https://atlas.ripe.net/measurements/9740262/ for a real measurement using this technique. Baptiste > > When I got the results from the measurement they were not what I > expected The measurements to Quad9 had high value of REFUSAL. > > Does any one as a clue why??? > > The measurement result is available at > https://atlas.ripe.net/measurements/10269508 > > Best regards, signature.asc Description: PGP signature
[atlas] What is the meaning of 127.0.0.1 as probe resolver?
Hi, While looking at the result of built-in DNS measurements that use the probe resolvers, I noticed that a significant fraction of probes have "127.0.0.1" as a resolver. And the results are strange: performance is really bad, for instance measurement 30002 gives a median resolution time of 300 ms for these probes! What could be the meaning of this? It almost looks like a recursive resolver with no cache at all is running on the probes themselves. I was looking at this measurement: https://atlas.ripe.net/measurements/30002/ And here are some example probes that exhibit this "127.0.0.1" symptom: 6001, 6087, 6162, 6235, 6308. Any reasonable explanation is welcome! Thanks, Baptiste signature.asc Description: PGP signature
[atlas] List of Atlas probes subjected to DNS traffic interception (MITM)
Hi, I am looking for a list of Atlas probes that suffer from DNS traffic interception, to exclude them from my measurements. What I mean by "traffic interception" is that DNS queries from the probe to a third-party DNS server do not reach the server, but are intercepted and answered by a middle-box instead. I started building this list myself, but it's a long and potentially error-prone process. It seems that the "DNS Root Instances" map could be used for that purpose, because DNS traffic interception shows up as if the probe was contacting an "Unknown" root instance. To get the list of probes, I ended up using an URL like the following, showing probes for all possible "unknown" root instance hostnames: https://atlas.ripe.net/results/maps/root-instances/?server=1=10300=4=_only=dns1.com2com.ru%2Cnl1.dnscrypt.eu ... However, there seems to be a limit on the size of the URL so I cannot get all probes, and they are just displayed on the map without any obvious way to get the raw list of probes instead. Is there a way to get the raw list of probes from this map? Or has anybody already done this classification work independently? I also looked for DNS-related tags on probes, but could not find anything useful. Thanks, Baptiste signature.asc Description: PGP signature
Re: [atlas] API filtering for looking at measurements?
Hi Jasper, On Mon, Apr 18, 2016 at 09:18:49AM +0200, Jasper den Hertog wrote: > > On 15 Apr 2016, at 18:11, Baptiste Jonglez <bjong...@illyse.org> wrote: > > > > I would like to find measurements matching some specific conditions, so I > > tried to use the measurement API documented here: > > > > https://atlas.ripe.net/docs/rest/ > > > > However, filters don't seem to have the intended effect. For instance, I > > tried to restrict to a specific range of starting time: > > > > > > https://atlas.ripe.net/api/v1/measurement/?start_time__gte=1443654000_time_lte=1446336000 > There is small type in your start_time__lte query-parameter. It should have > double underscores between `start_time` and `lte`. It will work then > > > but looking at the first result (measurement ID 1411440), its start time > > is 1564618500, which is way outside of the requested range. > > > > Similarly when filtering by type: > > > > https://atlas.ripe.net/api/v1/measurement/?type=2 > type should be the name of the type as a string `?type=tracertoue` You're right, with the corrected parameters, it works fine... I guess it's bad luck that I made a mistake in each of my two attempts. > Also, I would like to advise you to use the v2 API from now on, we’re going > to deprecate v1. > > There is a manual for V2 at https://atlas.ripe.net/docs/api/v2/tutorial/ > <https://atlas.ripe.net/docs/api/v2/tutorial/> and there is reference > documentation at https://atlas.ripe.net/docs/api/v2/reference/ > <https://atlas.ripe.net/docs/api/v2/reference/>. This is till in beta, url’s > for the documentation will change but it will be available then be linked > from https://atlas.ripe.net/docs/ <https://atlas.ripe.net/docs/> Ok, thank you for the links. By the way, even the new API does not complain when passing invalid parameters (for instance "type=2" above). Shouldn't it return an error when a parameter is incorrect? Thanks, Baptiste signature.asc Description: PGP signature
[atlas] API filtering for looking at measurements?
Hi, I would like to find measurements matching some specific conditions, so I tried to use the measurement API documented here: https://atlas.ripe.net/docs/rest/ However, filters don't seem to have the intended effect. For instance, I tried to restrict to a specific range of starting time: https://atlas.ripe.net/api/v1/measurement/?start_time__gte=1443654000_time_lte=1446336000 but looking at the first result (measurement ID 1411440), its start time is 1564618500, which is way outside of the requested range. Similarly when filtering by type: https://atlas.ripe.net/api/v1/measurement/?type=2 type=2 is supposed to be IPv4 traceroute, but the first result is measurement ID 1001, which is an IPv4 ping. Am I using the API incorrectly, or is there a bug somewhere? Thanks, Baptiste signature.asc Description: PGP signature
