April 2015 - ripe-atlas - mailman.ripe.net

Wrong IP prefix values accepted?
by Stephane Bortzmeyer 05 Jul '15

05 Jul '15

It seems there is no protection against wrong prefixes? See measurement #1897909, which started with JSON: {'definitions': [{'query_class': 'IN', 'description': 'DNS resolution of jihadmin.com from prefix foobar', 'af': 4, 'query_argument': 'jihadmin.com', 'query_type': 'A', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': True, 'use_probe_resolver': True}], 'probes': [{'requested': 3, 'type': 'prefix', 'value': 'foobar'}]}

2 5

Geographic Selection of Probe
by Graham Beneke 28 Apr '15

28 Apr '15

Hi All Due to the huge number of probes in Europe there is always a heavy bias when selecting "whole world" for UDMs. In the past I could get around this by requesting numbers of probes from each region/continent. I can't figure out how to do this on the new interface. Using the wizard there does not seem to be a way to request a random subset of probes within the area selected. When using the manual probe selection I can't find what area codes I can use besides "WW" Am I missing something? -- Graham Beneke graham(a)apolix.co.za

2 1

New on RIPE Labs: Measuring Countries and IXPs in the SEE Region
by Vesna Manojlovic 24 Apr '15

24 Apr '15

Dear all, In this post we look at 10 countries in South East Europe and see how we can use RIPE Atlas to get a sense of routing and the interconnectedness of networks in these countries: https://labs.ripe.net/Members/emileaben/measuring-countries-and-ixps-in-the… Two prototype tools used here can benefit from your feedback & involvement: IXP-Jedi & OpenIPMap. Please take some time to play with the interactive grid (IXP-Jedi), e.g. for Romania: http://sg-pub.ripe.net/emile/ixp-country-jedi/RO-2015-04/ixpcountry/ Code: https://github.com/emileaben/ixp-country-jedi/ Or join the OpenIPMap to crowdsource geolocation of IP infrastructure: https://github.com/RIPE-Atlas-Community/openipmap Kind regards, Vesna

1 0

IPv6 auto-tagging failure?
by Bjørn Mork 21 Apr '15

21 Apr '15

Hello, I'm wondering a bit about the IPv6 auto-tagging. I recently reveived a v3 probe and connected it to a dual-stack enabled network. The probe was initially tagged as 2015-04-16 20:23 UTC Probe auto-tagged Your probe #22894 was automatically tagged as "system: IPv6 Capable" but then (on the next batch run?, after a couple of quick firmware upgrades (3.3.8 => 4650 => 4680): 2015-04-17 08:23 UTC Probe auto-untagged Your probe #22894 was automatically untagged as "system: IPv6 Capable" and there it has been since. This wouldn't worry me too much if it otherwise worked, but I noticed that the probe isn't listed with an "ASN v6" either. So I assume the missing tag prevents it from being used for v6 probing? AFAICS, the probe does take the announced prefix, and is actually *using* the provided IPv6 connectivity. The "Connection History" shows that it consistently uses its SLAAC address to connect to the controller. So why isn't it tagged as IPv6 capable/works etc? In desperation I tried different netwrok settings, static address, adding v6 DNS, and fiddling with the managed/other flags along with matching DHCPv6 config. Made no difference of course. If I understood correctly, the probe firmware won't currently do any DHCPv6, and v6 DNS is optional as long as there is a working v4 resolver available. Bjørn

3 2

RIPE Atlas accounting system renewal
by Robert Kisteleki 20 Apr '15

20 Apr '15

Dear Users, Today we're renewing our internal accounting system in RIPE Atlas. This change is almost exclusively internal, it hardly shows up on the public pages. If you see discrepancies regarding your credits tomorrow, then please let us know at atlas(a)ripe.net (ie. NOT this mailing list) so we can check. We'll privately contact the few users where we expect a more visible change. Regards, Robert & Johan & the rest of the team

1 0

Error when adding a measurement
by Edd Barrett 17 Apr '15

17 Apr '15

Hey, A friend offered me a v3 probe, and I am currently playing around with it, exploring what I can do. I think there may be a bug in the measurements setup process. When I try to add a measurement, I get a message: "AccBalance matching query does not exist." This is not a very user friendly message. Perhaps this is suggesting that I don't have enough credit? This leads me to another potential problem. On the landing page, after I login, there is a credit summary consisting of two icons and a kind of pie chart. If I mouseover "current balance" it says 0. If I click it, the resulting page says I have 50,000 credits (the welcome bonus). I suspect that I can't setup the measurement because some part of the system thinks I have no credit. Cheers -- Best Regards Edd Barrett http://www.theunixzoo.co.uk

2 1

Accounting switch
by Johan ter Beest 17 Apr '15

17 Apr '15

Dear Atlas users, We are in the middle of switching the accounting back-end. We expect this work to be finished by next week: Tuesday, April 21. There are two spots where you would be impacted: - Transferring credits Credits transferred will show up in the new system but not in the old. We have temporarily disabled the transferring of credits using the website. If you need to have some credits transferred urgently, you can email us at atlas-dev(a)ripe.net and we will make the transfer for you - When you register a new probe and are a first time probe host (ie, you have no credits at all) The 50.000 credits welcome bonus is applied to the new system while the measurements scheduling checks the old system resulting in an error. This is a fairly rare scenario as most of our hosts have credits already. When we spot this, we will contact the host and adjust his credits manually. There will be no danger of losing credits or measurements being stopped accidentally as a result of this switch. Thank you for your patience while we make this switch. Kind regards, Johan ter Beest RIPE Atlas Team

1 0

Anexia Internetdienstleistungs Gmbh, Klagenfurt, Austria has joined RIPE Atlas anchors
by Eamonn Lane 17 Apr '15

17 Apr '15

Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called at-klu-as42473 and is hosted by Anexia Internetdienstleistungs Gmbh in Klagenfurt, Austria. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas(a)ripe.net

1 0

NZ Registry Services, Aukland, New Zealand has joined RIPE Atlas anchors
by Eamonn Lane 17 Apr '15

17 Apr '15

Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called nz-lyj-as17746 and is hosted by NZ Registry Services in Aukland, New Zealand. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas(a)ripe.net

1 0

negative RTT?
by Paul Vlaar 17 Apr '15

17 Apr '15

Hi all, I noticed that one of my DNS UDMs gave back a negative RTT: {"af":4,"dst_addr":"199.19.57.1","from":"171.98.64.220","fw":4680,"group_id":1957244,"lts":39041,"msm_id":1957244,"msm_name":"Tdig","prb_id":22726,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":1,"ID":8401,"NSCOUNT":0,"QDCOUNT":1,"abuf":"INGEAAABAAEAAAABA29yZwAABgABwAwABgABAAADhAAzAmEwA29yZwthZmlsaWFzLW5zdARpbmZvAANub2PAKHfkW2sAAAcIAAADhAAJOoAAAVGAAAApEAAAAAAAACYAAwAibnMwMDBiLmFwcDI3LmlhZDEuYWZpbGlhcy1uc3QuaW5mbw==","answers":[{"MNAME":"a0.org.afilias-nst.info.","NAME":"org.","RNAME":"noc.afilias-nst.info.","SERIAL":2011454315,"TTL":900,"TYPE":"SOA"}],"rt":-14281.576,"size":133},"src_addr":"192.168.1.51","timestamp":1428948041,"type":"dns"} -14281.576ms was standing out like a sore thumb on the graph that I create out of the results from these UDMs. This is quite interesting, maybe messages from the future? :) Anyone else ran into one of these? ~paul

3 3