September 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

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

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

Credits transfer no longer working?
by Stephane Bortzmeyer 30 Sep '13

30 Sep '13

Did anyone notice problems with credit transfers? I run a RIPE Atlas workshop tomorrow abnd I tried to transfer credits to attendants, people with a RIPE account, both in the same LIR and outside. Nothing is credited on their side.

4 4

finding a probe
by Randy Bush 27 Sep '13

27 Sep '13

remote hands plugged an old style probe in. i see it on the ether port they claimed, its mac is 00:80:a3:91:4b:0d (my others are all 00:20, hmmm) i plug the dhcp-issued address 198.180.152.27 into the page at https://atlas.ripe.net/register/ it tells me there is no probe there how to debug? randy

1 0

REST API Problems for DNS measurements with DO and TCP
by Klaus Darilion 26 Sep '13

26 Sep '13

Hi! I managed to create DNS measurements via the REST API, but fail to set the DO and protocol:TCP option. According to the documentation (https://atlas.ripe.net/doc/measurement-creation-api/) the relevant properties are use_EDNS0 and use_tcp. So I tried it with { "definitions": [ { "is_public": true, "is_oneoff" : false, "target": "194.0.25.13", "description": "a.dns.nic.versicherung_IP4_TCP_noDO", "type": "dns", "af": 4, "interval": 300, "use_EDNS0": false, "use_TCP": true, "use_probe_resolver": false, "use_NSID": true, "query_class": "IN", "query_type": "SOA", "query_argument": "versicherung", "udp_payload_size": 1024, "protocol": "TCP", "do": true } ], } but that does not work - the generated measurements do not use TCP and DO. When I create the measurement via the web interface and review the measurement via the REST API, I see that other properties are set: "do" and "protocol". E.g: # curl https://atlas.ripe.net/api/v1/measurement/1027747/ {"all_scheduling_requests_fulfilled": true, "can_visualise": false, "creation_time": 1380018470, "description": "TEST via WEB", "do": true, "dst_addr": "194.0.25.13", "dst_asn": "1921", "dst_name": "194.0.25.13", "interval": 240, "is_oneoff": true, "is_public": true, "msm_id": 1027747, "nsid": true, "participant_count": 1, "protocol": "TCP", "query": {"class": "IN", "type": "SOA", "value": "versicherung."}, "resolve_on_probe": false, "resolved_ips": ["194.0.25.13"], "result": "/api/v1/measurement/1027747/result/", "start_time": 1380018470, "status": {"id": 7, "name": "Failed"}, "stop_time": 1380018904, "type": {"id": 6, "name": "dns"}, "udp_payload_size": 512} So I tried to create measurements with the "do" and "protocol" properties, but these properties are again ignored. If I am doing something wrong, so please give me some hints. Otherwise the API documentation is wrong and these properties can not be set via REST, only via the web interface - and should be fixed. Thanks Klaus

3 6

IPv6, RA and static IPv6 assignment
by Mike. 19 Sep '13

19 Sep '13

Are there any plans to allow the probe's listening for RA to be disabled so that I can configure a static IPv6 address, router and DNS server without RA overwriting my values?

4 4

Add E-Mail notification when a probe is back up (for more than 60 minutes)
by Roman Mamedov 19 Sep '13

19 Sep '13

Hello, Got one of these: > Your probe 73 has been disconnected since 2013-09-19 09:26:19 UTC. > > 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 60 minutes. > > If you want to change this, or disable this notification altogether, please go to https://atlas.ripe.net/atlas/myprobes.html, click on "My Probes" and then on probe 73. In the opened tab, select "Probe's Settings" and then "Notifications" to change your settings. > > Kind regards, > > RIPE Atlas Team > What's unusual this time, is that I did not change anything in my network setup, and I can still ping the probe both on its local v4 and global v6 addresses. So one way of action would be to unplug and replug the probe in hope that it sorts out itself; 2nd course of action would be to simply wait and see if it reconnects on its own. If I choose this, I have to keep the Atlas website open in a browser tab, refreshing from time to time to see if the readings changed to "Connected". So what baffles me about this, why can't I get a simple E-Mail notification same way as "it went down", to tell me that "ok now it's back up"? -- With respect, Roman

1 0

"Spoofing" tests.
by Warren Kumari 18 Sep '13

18 Sep '13

Apologies if this has already been discussed enlist -- I took a quick look though the archives and didn't see it. I believe that the reason for not allowing things like tests that send spoofed packets is that it might violate the AUP that participants have with their ISPs / be viewed by participants ISPs as an attack. So, what about having a checkbox in the Probe Settings that says something like: "I have no AUP with my ISP or I'm fine to violate my AUP. Run intrusive or dangerous tests on this probe" ? This would create a subset of probes that could be used for more interesting tests, an d would allow for greater visibility into things. W --- It is a mistake to think you can solve any major problem just with potatoes. --Douglas Adams

11 17

RIPE Atlas anchors update
by becha 16 Sep '13

16 Sep '13

Dear RIPE Atlas users, we are happy to share with you the results of the pilot phase of RIPE Atlas anchors, and plans for the production service. Two recent RIPE Labs article give you the details: * technical results of virtualization testing: https://labs.ripe.net/Members/romeo_zwart/further-virtualisation-testing-fo… * "mesh" measurements between all anchors, moving to smaller box and different hardware platform, and making the service for all, not only members: https://labs.ripe.net/Members/becha/ripe-atlas-anchors-pilot-summary-and-ne… We are looking forward to see you at RIPE67, MAT-WG, and in the meantime, to your comments and feedback on this list. Kind regards, Vesna -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder @Ms_Measurements for Measurements Tools RIPE NCC http://ripe.net

1 0

No IPv6 Connection on Probe
by David Churchill 13 Sep '13

13 Sep '13

I've noticed that my probe (12070) has not had any IPv6 connectivity for the last several days. I've reset the probe a couple of times and verified that my internet service still has full IPv6 connectivity (@http://test-ipv6.comcast.net/). Is there anything I can do to restore the IPv6 connectivity? Thanks, David C. Churchill 5285 Vinings Springs Trl Mableton, GA 30126 770.819.5935 d_churchill(a)comcast.net

2 1

A small matter of terminology
by Stephane Bortzmeyer 10 Sep '13

10 Sep '13

A long time ago, there was only one sort of measurement. Then, one-off measurements were created. How do we call the other category? Periodic measurements? Repeated measurements?

1 0

New On RIPE Labs: The Seismograph And Other RIPE Atlas Features
by Michela Galante 09 Sep '13

09 Sep '13

Dear colleagues, We have added a couple of new RIPE Atlas features including the Seismograph, zoomable ping graphs and others. You can find the details in an article on RIPE Labs here: https://labs.ripe.net/Members/becha/seismograph-and-other-new-ripe-atlas-fe… Kind regards Michela Galante Project Coordinator RIPE NCC

1 0

Using Atlas for commercial services
by Stephane Bortzmeyer 05 Sep '13

05 Sep '13

Hello, happy Atlasers, After reading <https://labs.ripe.net/Members/kranjbar/future-of-ripe-ncc-technical-services> (specially the part about using Atlas to monitor reachability from Nagios), the ToS <https://atlas.ripe.net/service-rules/> and checking the FAQ <https://atlas.ripe.net/about/faq/>, I still have a question: Can I use Atlas as a basis for commercial services? Today, most Atlas uses seem to be for public research, or for "selfish" measurements (checking my network). But I see nothing forbidding people to sell services (monitoring, quality assessment) to other people, based on Atlas. Is it on purpose? [Yes, I have one or two business ideas and I would like to know before I continue developing them.]

11 15

Re: [atlas] Using Atlas for commercial services
by Hook 05 Sep '13

05 Sep '13

As already said, commercial usage would also mean that you have to earn credits in some way. As far as I know, it's only possible to earn credits by - hosting probes itself - sponsoring new probes - getting a LIR In either of the first two cases, the atlas project will benefit from it. The third one is a special case and isn't worth a discussion. So I think we should allow commercial usage of the Atlas project, if commercial usage still means to support the Atlas project itself because of the need for credits! Would be a win-win situation. Michael 2013/9/5 Daniel Karrenberg <daniel.karrenberg(a)ripe.net> > > On 05.09.2013, at 11:42 , Stephane Bortzmeyer <bortzmeyer(a)nic.fr> wrote: > > > On Thu, Sep 05, 2013 at 05:22:50PM +0800, > > Sanjeev Gupta <ghane0(a)gmail.com> wrote > > a message of 107 lines which said: > > > >> Adam Smith was right, the baker and the butcher feed me by being > selfish. > > > > So, apparently, there is no consensus among the Atlas community. An > > interesting discussion to have in Athens? > > It is a discussion we should have in the mat-wg. The working groups work > on the mailing lists; physical meetings are just focal points for the work. > > Daniel > > >

1 0

Disabling one measurement on my probe...
by Warren Kumari 02 Sep '13

02 Sep '13

Hi all, Due to much stupidity my probe lives behind 2 NATs (don't ask). Anyway, one of the NATs / firewalls is suddenly throwing hissyfits and logging a bunch of messages like: [00005] 2013-08-27 17:33:29 [Root]system-critical-00435: ICMP fragment! From 78.46.37.134 to 192.168.15.207, proto 1 (zone Untrust, int ethernet3). Occurred 2 times. I can see the Measurement IDs that are causing this (1019675, 1019728), but I have two questions: 1: is there a way to disable specific measurements from a specific probe and 2: did anything change recently with the "Ping" measurement, like the packet size for example? I *did* spend some time reading the list archives and documentation, but was not able to find an answer. W P.S: And yes, I will sometime remove the NATs, but cannot until there is another ISP available -- I live in a 3rd world country where any broadened is a luxury, and multiple providers is more than one can reasonably expect… -- "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." -- Terry Pratchett

4 4