October 2013 - ripe-atlas - mailman.ripe.net

Atlas F.ROOT ping
by Peter Gervai 09 Jan '14

09 Jan '14

Hello, Atlas helped me today first to see a hard-to-detect bug: F-root anycast algo works fine for v4 but fails miserably for v6, as instead of AMSterdam it sends all traffic to some remote island in the pacific. ;-) Seems to be the reverse true for M-root: ipv4 sends me off to nowhere land while v6 is great. A-root follows the F-suit. (C-root is not a good avertisement valie for Cogent, with v4 only address and considerable ongoing pkt loss.) Thanks! Peter

4 5

HTTP/HTTPS probe
by Max Tulyev 22 Nov '13

22 Nov '13

Hi All, What about HTTP/HTTPS requests from Atlas probes? I hear it is technically possible. This test can provide statistics about quality and availability of certain websites, as well as the information about content is delivered unmodified, not blocked, correctly/incorrectly cached, etc. Is it possible to enable that kind of probes?

10 15

Replacing "ping RRDs" with "zoomable ping graphs"
by Robert Kisteleki 30 Oct '13

30 Oct '13

Dear RIPE Atlas users, As you may have read in the recent RIPE Labs article (https://labs.ripe.net/Members/becha/seismograph-and-other-new-ripe-atlas-fe…), we've replaced the old style, RRD based visualisation for built-in ping measurements with client side, zoomable graphs. Since then we've also changed the graphs that represent the probe's bandwidth usage. The new graphs have the benefit that they retain all details, even for longer time intervals. (These details were lost in the RRD based graphs over time.) Other reasons why we changed include that generating the RRD graphs did not scale well with the increasing number of RIPE Atlas probes, and making them required us to maintain a large set of backend servers, each being a single point of failure. With the new approach you still have visualisations for this information, with more details and interactivity (though it does require running JavaScript on the client side). We'll change the remaining RRDs to this new model as well in the coming period, and stop generating the RRD based images altogether. We expect to stop with the "built-in pings" and the probe traffic RRDs first, likely in the second week of October. If you would like to embed these new style visualisations into your pages (maybe because you used the RRD graphs before), then you'll have to embed a RIPEstat widget; see https://stat.ripe.net/widgets/demo/atlas_probe_widgets.html for details. Regards, Robert Kisteleki for the RIPE Atlas team

1 1

Strong doubts about the option "DNS recursion"
by Stephane Bortzmeyer 28 Oct '13

28 Oct '13

I fear that the option "recursion_desired" <https://atlas.ripe.net/doc/measurement-creation-api/> does not work as expected. Here was my experiment. I registered a new domain name which never appeared before, d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr. Because of its unreadability, there is zero chance it has ever been in a DNS cache. I then ask Atlas probes to dig it, with "recursion_desired" set to false: {'definitions': [{'query_class': 'IN', 'use_probe_resolver': True, 'af': 4, 'query_argument': 'd7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr', 'query_type': 'TXT', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': False, 'description': 'DNS resolution of d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr'}], 'probes': [{'requested': 10, 'type': 'area', 'value': 'WW'}]} But all the probes got the content of this TXT record! Measurement #1034372 if you want to check (unfortunately, this parameter is not displayed in <https://atlas.ripe.net/atlas/udm.html?msm_id=1034372>). It seems wrong, they should all have retrieved an empty answer (here, with dig, the behaviour I expected): % dig +norecurse @MYSERVER TXT d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norecurse @relay1 TXT d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33141 ;; flags: qr ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 21 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr. IN TXT ;; AUTHORITY SECTION: fr. 165392 IN NS d.ext.nic.fr. fr. 165392 IN NS d.nic.fr. ...

4 11

Huge credit debit
by Mike. 12 Oct '13

12 Oct '13

One of my measurements (that usually uses about 1000 credits per day) all of a sudden posted a credit usage of 2,293,788.00 credits for a single measurement. 2013-10-10 18:13 UTC UDM 764596 samples of msm #1013277 -2,293,788.00 -1,279,520.00 I don't know where or why the 764596 samples came from, usually only 90 samples are performed. Was there a proble in the measurement or credit system recently? Thanks.

3 6

Problems with one-off measurements
by Robert Kisteleki 07 Oct '13

07 Oct '13

Dear RIPE Atlas users, It has come to our attention that one-off measurements at the moment don't produce the expected number of results. So far our investigation shows that this is most likely a probe firmware issue. We'll let you know once we find the real cause and have a fix for this. In the meantime please accept our apologies for the reduced usefulness of this function. Regards, Robert Kisteleki for the RIPE Atlas team

1 1

Question about rt definition of DNS measurements
by Klaus Darilion 06 Oct '13

06 Oct '13

Hi! When doing DNS measurements I see that the average "rt" time is considerable higher when setting the DO bit. When I check my name servers manually with dig (with and without DO) I do not see any considerable differences. Thus, I wonder how "rt" is measured in the Atlas probes and if the probe does some DNS/DNSSEC relevant processing during the "rt" interval, or is it really just the time between sending and receiving of the packets on IP layer? Thanks Klaus

2 1

Announcing RIPE Atlas Service Terms Documentation for Anchor Hosts
by Vesna Manojlovic 03 Oct '13

03 Oct '13

Dear colleagues, In the process of transitioning RIPE Atlas anchors towards being a production service, we have developed two documents that describe the service terms: - Draft RIPE Atlas Service Terms and Conditions - Memorandum of Understanding - Hosting a RIPE Atlas Anchor Probe Please see the details in this RIPE Labs article: https://labs.ripe.net/Members/becha/ripe-atlas-anchors-terms-and-conditions If you are currently hosting an anchor, or if you are interested in hosting a RIPE Atlas anchor in the future, we would like to hear any feedback you have on these draft documents. Our goal is to finalise the documents by 11 October so that we can announce the production service at the upcoming RIPE 67 Meeting in Athens. Regards, Vesna -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net

1 0

Measurement of impact of the Russian censorship
by Max Tulyev 03 Oct '13

03 Oct '13

Hello Atlas, recently I found some of Websites was blocked in Ukraine with PutinWall outside Russia. These resources was not hosted in Russia as well. Further investigation shows that the trace to these resources are either through Russia, or (which is more interesting) through Russian-based carriers which are do filtering on their networks boundary which are outside Russia as well, for example, in Frankfurt. This is some impaced nets in Ukraine, but probably countries whole connected through Russia, like Kazakhstan, are more suffering. Is it possible to use Atlas probes to figure out impact of PutinWall to countries should not be impacted by Russian censorship? And may be the efficient of filtering inside Russia? That's the sample of censored URL: http://stervozzinka.dreamwidth.org/15580.html The task is to probe it from Atlas probes and put on map the mark is it accessible or not for the first result. The second stage is to figure out carriers do the filtering of trans-Russia connectivity. I believe it will be interesting for a lot of people. I see this test is possible, but possible only manually by the RIPE NCC staff.

1 0

Problems deleting measurements
by Klaus Darilion 03 Oct '13

03 Oct '13

Hi! I have problems with lots of measurements, I can not delete them. e.g: A) https://atlas.ripe.net/api/v1/measurement/1027747/ The status is "Failed" and in the web I can not Archive or Stop it. Also deletion via REST fails: curl -H 'Accept: application/json' -X DELETE https://atlas.ripe.net/api/v1/measurement/1027747/?key=01....6d {"error": {"code": 200, "message": "That measurement cannot be stopped."}} btw: is above REST call correct? Same problem for measurment 1012558 which is in status Stopped. B) Is "archive" in the web interface identical to "DELETE" via REST? E.g. the web interface offers me "Archive" for measurement 1029338 (and I am quite sure it would work), but the REST call fails with same result: curl -H 'Accept: application/json' -X DELETE https://atlas.ripe.net/api/v1/measurement/1029338/?key=01....d {"error": {"code": 200, "message": "That measurement cannot be stopped."}} Further, the web interface offers "Stop" and "Archive", but the REST call only offers "DELETE". So, how do I "Stop" via REST? For me it is confusing to have different terms in the web interface and REST API. C) 1031725: The measurement is currently (UTC 18:30) in status Ongoing. Start Time is UTC 19:45, Stop Time is 19:55. When I stop the measurement, the measurements stop time changes to the current time, but status is still Ongoing, and I can not Archive (not offered), but it still offers always Stop. But when I delete via REST, the measurement gets stopped (status Stopped in web interface). So does REST-DELETE is identical to "Stop" in web interface? If yes, how do I archive via REST? Further, DELETE a stopped message should not produce error "That measurement cannot be stopped.", but rather "That measurement is already stopped." D) For the web interface it would be cool to stop/archive/delete measurements more comfortable. Eg. select multiple measurements and then choose "stop and archive". Thanks Klaus Thanks Klaus

2 2

Probe uptime reporting issues
by Robert Kisteleki 01 Oct '13

01 Oct '13

Dear All, On 21 September we deployed a new software version on our core infrastructure components. Unfortunately this contained a bug that we didn't catch in time, which caused "probe uptime reports" not to be propagated properly. This affected the "monthly probe uptime reports" as well as -- in some cases -- the amount of credits received for a probe. We've fixed the bug and re-sent the missing uptime entries. Please let us know (in an email to atlas(a)ripe.net, mentioning your email address and probe ID) if you received less credits than you should have, and would like to receive compensation. In order to improve our process, we're working on an internal test suite that will help us catching these kind of errors in time. We aplogise for the inconvenience this issue may have casued. Regards, Robert Kisteleki for the RIPE Atlas team

1 0