- ripe-atlas - mailman.ripe.net

Small downtime expected
by Robert Kisteleki 02 Mar '16

02 Mar '16

Dear All, Due to operational reasons we will have a short downtime of the main RIPE Atlas website at 11:00 (CET). We expect this to last less than 15 minutes. The system will continue to collect results in the meantime, so no data loss is expected. Regards, Robert Kisteleki

1 0

Ping option DF
by dave 29 Feb '16

29 Feb '16

Hi, It seems atlas sends out ping with fragmentation allowed. Why is there no option to enable DF? Thanks, Dave.

2 1

Thirteen new RIPE Atlas anchors have joined the community
by Michela Galante 18 Feb '16

18 Feb '16

Dear RIPE Atlas users, 13 new RIPE Atlas anchors have been activated during the last month and a half bringing the total number to 177. - id-jkt-as10208, hosted by PT. Millenium Internetindo in Jakarta, Indonesia and sponsored by APNIC. - ar-bue-as4270, hosted by ARIU in Buenos Aires, Argentina and sponsored by LACNIC. - de-nue-as60574, hosted by net-manager UG in Nuremberg, Germany. - uk-boh-as196745, hosted by Datacenta Hosting in Bournemouth, United Kingdom. - at-vie-as30971, hosted by nic.at in Vienna, Austria. - uk-lon-as6908, hosted by Six Degrees Group in London, United Kingdom. - nl-utc-as1103, second anchor hosted by SURFnet, in Utrecht, Netherlands. - Two anchors hosted by INX-ZA/Internet Service Providers' Association of South Africa: za-jnb-as37474 in Johannesburg and za-umr-as37668 in Umhlanga, South Africa. - ru-led-as43317, hosted by Fishnet Communications in Saint Petersburg, Russia. - nl-dro-as12414, hosted by Solcon Internetdiensten N.V. in Dronten, Netherlands - de-drs-as42699, hosted by managedhosting.de GmbH in Dresden, Germany. - fo-hyv-as15389, hosted by P/F Telefonverkid in Hoyvik, Faroe Islands. The map of all anchor locations is available at: https://atlas.ripe.net/anchors/map/ You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ And here are the logos and links to hosting companies: https://atlas.ripe.net/get-involved/community/#!tab-anchor-sponsors We are still accepting new applications from organisations interested in hosting a RIPE Atlas anchor. We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa, in order to add more geographical diversity to the measurement data. There are more organisations that want to host a RIPE Atlas anchor but don’t have the necessary funding. To learn more about sponsoring an anchor, please contact us at mcb(a)ripe.net To apply for your own RIPE Atlas anchor: https://atlas.ripe.net/get-involved/become-an-anchor-host/ For any other questions, please contact us at atlas(a)ripe.net Regards, Michela Galante Measurements Community Building RIPE NCC

1 0

Detecting additional information from the probes
by Christoph Rauterberg 15 Feb '16

15 Feb '16

Ahoi everyone, I am currently trying to asses the behaviour of DNS queries between clients and authentication servers - and I would love to trace some DNS pakets between the probes and my server. I was wondering, if there is some way to get the information about the Authentication Bit of DNSSEC specified in the DNS query headers. A.f.a.i.k., the probes do something similiar/do a /dig/ lookup. /dig/ does provide information about the DNSSEC-section - and furthermore it has a very handy /+trace/ option. Can anyone maybe tell me, if there are possibilities to access the AUTH bith or even something like a trace function via the probes? Or should I open a feature request for that? Help much appreciated! :-) Best regards, Chris

2 3

can help me increase speed
by mostafa shahdadi 13 Feb '16

13 Feb '16

% This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '2.189.88.0 - 2.189.95.255' % Abuse contact for '2.189.88.0 - 2.189.95.255' is 'R.javidi(a)tci.ir' inetnum: 2.189.88.0 - 2.189.95.255 netname: DABCO descr: Dadeh Pardazan Avaye Bandar Company country: IR admin-c: PA8248-RIPE tech-c: PA8248-RIPE status: ASSIGNED PA mnt-by: AS12880-MNT created: 2015-05-25T06:22:46Z last-modified: 2015-05-25T06:31:59Z source: RIPE # Filtered person: POURIYA ARGHASH address: No 2,first Floor,Daryanavard Building,Delgosha Conjunction, address: Emam Khomeyni Street,Bandar Abbas,Hormozgan,Iran phone: +98 761 222 54 90 fax-no: +98 761 222 54 90 nic-hdl: PA8248-RIPE mnt-by: AS12880-MNT created: 2015-05-25T06:31:59Z last-modified: 2015-05-25T06:31:59Z source: RIPE # Filtered % Information related to '2.189.0.0/16AS12880' route: 2.189.0.0/16 descr: Information Technology Company (ITC) origin: AS12880 mnt-by: AS12880-MNT mnt-routes: mohsenrahimimaintainer created: 2011-07-13T14:32:16Z last-modified: 2015-03-04T10:05:36Z source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.85.1 (DB-1) Sent from my iPad

2 1

Triggering traces from probes in specific cities
by Anurag Bhatia 10 Feb '16

10 Feb '16

Hello everyone, I was looking at possible command line tool to trigger traces from Atlas from given city or that area. The closest I can see is RIPE Atlas Tools - https://github.com/RIPE-NCC/ripe-atlas-tools but these let to only put source country or region. 1. Is anyone aware of how one can trigger traces via CLI from specific cities? *(I would love to do trace from a nearby city if specific city does not have Atlas coverage)* 2. In the Ripe Atlas Tools I see in documentation it refers to an argument "[--paris paris]". Is anyone aware of what does it mean? It seems to be asking for an integer value. Thanks in advance! -- Anurag Bhatia anuragbhatia.com

2 2

Feature request - externalize packet loss in ping measurement UI
by Gil Bahat 10 Feb '16

10 Feb '16

Hi, looking at the JSON data, there is a field for the amount of received packets vs the requested, but at the measurement UI it is not reflected. it'd be great if this can be displayed (e.g. 'x% packet loss' as one of the columns). Regards, Gil Bahat, Director of Online Operations, Magisto Ltd.

2 1

List of my measurements via API
by Luke Overend 09 Feb '16

09 Feb '16

Hi all, I have searched the docs and tried everything I can think of but I cannot get a list of my measurements via the API. Can anyone provide me details on how to do this? If it is not currently possible how do I go about requesting the feature? Thanks Luke Overend -------------------------------------- CloudFlare - AS13335 Network Engineer luke(a)cloudflare.com +442038136383 +447795328022 http://www.peeringdb.com/view.php?asn=13335

2 1

Revamped RIPE Atlas website launched today
by Robert Kisteleki 04 Feb '16

04 Feb '16

Dear all, We’re excited to announce that a revamped RIPE Atlas website launches today, so you can expect to see some changes when you visit atlas.ripe.net. We know that it can take some time to get used to change, but we think the new site is a big improvement over the old one and that you’ll find it quicker and easier to access the information you want. Some of the main features include proper landing pages for each section with quick links to the most relevant information, a restructured menu that includes a few new sections, including “Measurements, Maps and Tools”, “Probes and Anchors” and “Resources”, an improved dashboard overview of all of your probes and measurements under “My Atlas”, and faster data tables that you can now search. You can learn more about the revamped site and the reasons behind the change in this RIPE Labs article: https://labs.ripe.net/Members/suzanne_taylor_muzzin/the-revamped-ripe-atlas… Take some to look around and let us know what you think. We hope you’ll like what you see. Of course, we’ve done our best to ensure that all links are working properly, but if you happen to spot anything that looks wrong or broken, please let us know at atlas(a)ripe.net. Regards, Robert

1 0

API (v1) querying probes by ID
by Wenqin SHAO 03 Feb '16

03 Feb '16

Dear list, I have the impression that querying probes by ID returns unexpected results. An example is: https://atlas.ripe.net/api/v1/probe/?id=1 <https://atlas.ripe.net/api/v1/probe/?id=1> As a result, I get the entire probe list: "meta": { "total_count": 16973, "use_iso_time": false, "next": "/api/v1/probe/?id=1&limit=100&offset=100", "limit": 100, "offset": 0, "previous": null }, And ID 1 is an valid ID, which corresponds to the first entry of results: "id": 1, "type": "Probe", "is_public": false, "first_connected": "2010-10-29T15:53:03Z", "last_connected": "2016-02-03T10:02:28.407276Z", "is_anchor": false, "address_v4": null, "address_v6": null, "asn_v4": 3265, "asn_v6": 3265, "country_code": "NL", "prefix_v4": "212.238.0.0/16", "prefix_v6": "2001:980::/29", Regards, wenqin

3 4

Probe uptime?
by Max Mühlbronner 01 Feb '16

01 Feb '16

Hi, i suspect that there is a problem with my atlas probe, sometimes it is just gone / offline for ~10 minutes (more or less) although there is clearly no issue on the network. Other checks and monitoring works fine at the same time and shows about 100% uptime... I am not sure how to investigate, is there any chance to check the uptime of the probe and not just connection time? Maybe the device is hanging or rebooting? Internet Address Controller Connected (UTC) Connected for Disconnected (UTC) Disconnected for xxx.xxx.xxx.xx ctr-nue19, DE 2016-01-06 17:03:27 5d 22h 40m 2016-01-12 15:44:09 0h 5m xxx.xxx.xxx.xx ctr-nue19, DE 2016-01-01 00:29:44 5d 16h 16m 2016-01-06 16:46:33 0h 16m xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 23:47:35 0h 38m 2016-01-01 00:25:40 0h 4m xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 22:59:18 0h 41m 2015-12-31 23:40:32 0h 7m xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 22:35:12 0h 20m 2015-12-31 22:56:08 0h 3m Best Regards Max M.

2 2

API (v1) querying probes--does stats_name field count and possibility of negative selection
by Wenqin SHAO 28 Jan '16

28 Jan '16

Dear list, I encountered some unexpected results when selecting probes with status_name filed. An example is given below: https://atlas.ripe.net/api/v1/probe/?country_code=BG&tags=system-v3,datacen… <https://atlas.ripe.net/api/v1/probe/?country_code=BG&tags=system-v3,datacen…> 8 results were returned containing probes that are abandoned, as well disconnected and connected. To nail down the problematic field, I tried following queries: https://atlas.ripe.net/api/v1/probe/?status_name=Connected https://atlas.ripe.net/api/v1/probe/?status_name=Abandoned https://atlas.ripe.net/api/v1/probe/?status_name=Disconnected https://atlas.ripe.net/api/v1/probe/?status_name=Haha Exactly same number of probes, 16889, are return with each of these quests, which makes me wonder whether the status_name filed is actually taken into consideration? One other issue, is to negatively select probes according to some fields, especially tags filed, for example, probes do not contain home tag. I’d like to know if such selection logic is supported by v1 API? If yes, how to compose the query? If not, would it be considered in v2 API? A bunch of thanks in advance. Regards, Wenqin Telecom ParisTech

1 0

No Ethernet activity on new probe
by Marat Khalili 28 Jan '16

28 Jan '16

Dear All, I have received my probe yesterday morning (V3, like shown on https://atlas.ripe.net/docs/probe-v3/ ), connected and registered it. Unfortunately, not only no measurements or IP address information appeared in my profile after waiting several hours, but there's no Ethernet activity from probe at all, even in the packet trace. Things I tried: * 3 different switches (Fast and Gigabit types); in all cases a notebook running either Windows or Ubuntu when connected into the same socket acquires IP address just fine and can browse the Internet. * 3 different LAN cables; in all cases switches detect 100 Mbps physical wire but nothing more. * 2 different DHCP servers as well as wireshark on direct connection. * 3 different power sources (1A phone charger, notebook 2xUSB, PC USB). * Removing and re-inserting the USB flash key that came with the device, dd'ing its contents to a different USB flash and inserting it instead (dd finished successfully). Every time after the boot sequence ends first light glows steadily and adjacent one blinks slowly, like it is supposed to be according to https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-pro… . Looks like the interface just isn't up in the device OS. Is there anything else I can check? Should I request another probe? (it took more than month to receive first one by post) -- With Best Regards, Marat Khalili

3 6

500 Probe limit
by Marco Slater 27 Jan '16

27 Jan '16

Hello, I’ve been doing some tests on anycasted networks, and I’ve been hitting an error which doesn’t allow me to assign more then 500 probes to a measurement, is there a way to have this unlocked? I presume it is a default protection to not cause issues to hosts being probed? Thank you. :) - Marco

3 2

HTTP measurements at willing targets / protocol suggestion
by Gil Bahat 27 Jan '16

27 Jan '16

Hi, We are interested (like many others, I guess) in the ability to perform HTTP measurements at our own non-anchored network. Understanding the potential for abuse, I would like to suggest the following authentication protocol, which is based on best practices exhibited by other services with such potential (abuse or privacy implications). 1. Confirm control of the domain registration: * This is usually done by mailing the technical contact for the relevant WHOIS entry with a confirmation email containing a unique hash, thus validating ownership. 2. Confirm control of the DNS servers: * This is usually done by editing the root TXT record with a unique hash or publishing a CNAME with unique hash. 3. Confirm control of the Web servers: * This is usually done by placing a uniquely-hashed file in the webserver root directory, a unique hash in the meta-tags for the index html file or a unique value in a file such as robots.txt. I believe this protocol is sufficient to ensure that a web site owner agrees to the implications of allowing free HTTP measurements against their servers and that no unwilling server will ever be probed. At most during the protocol, the only resource that can be hit is a static file or robots.txt specifically, which has very little capability to overwhelm a web server, especially if negative responses are cached for a considerable amount of time / validation is done via a few nodes and propagated across the network. thoughts/ideas welcome. Regards, Gil Bahat, DevOps Engineer, Magisto Ltd.

3 3

LLDP Support for RIPE Probes
by Annika Wickert 27 Jan '16

27 Jan '16

Hi everybody, I would like to see LLDP support in the future on the RIPE probes. It would be a really helpful feature, to see on what Port the RIPE Probe resides at the moment. Cheers, Annika

9 11

Probe downtime notification
by Micha Bailey 26 Jan '16

26 Jan '16

I got an email 20 minutes ago telling me that my probe (#25346) is down, and apparently it's been down since 2016-01-24 15:11:10 UTC -- almost 24 hours. My settings are such that I should be getting an email within 15 minutes. Does anyone know why it's not emailing me right away? Has this happened to anyone else?

2 1

probe tagged as "Hardware problem suspected"
by sarah.wassermann＠student.ulg.ac.be 25 Jan '16

25 Jan '16

Hi, My probe (probeID: 24102) got tagged as "Hardware problem suspected" 2 weeks ago (and has also been disconnected since 2 weeks) and I am unable to bring it back to life again... (I am not an expert regarding hardware problems, so I will not be able to address the issue; restarting the router and plugging it out/back in didn't help). This probe behaved a bit strangely since the beginning: it disconnected itself for a few minutes per day without any reason, but I didn't pay much attention to that. Unfortunately, I need credits to conduct my research. Is it possible to order a new probe and to send this probe to RIPE? Maybe they can fix the problem and send the probe to someone who is interested in hosting a one? Thanks! Sarah Wassermann

3 6

Possible changes to the V1 REST API
by Chris Amin 22 Jan '16

22 Jan '16

Dear RIPE Atlas users, Over the past few days we have been making some changes behind the scenes in preparation for an upcoming version of the RIPE Atlas REST API. We identified and resolved several problems that these changes caused to the existing version of the API. The problems have now been fixed and you should not notice anything different with the existing API. If you continue to see anything strange, do please let us know. Kind regards, Chris Amin RIPE NCC

1 0

Display issues on the RIPE Atlas measurements listing
by Chris Amin 20 Jan '16

20 Jan '16

Dear RIPE Atlas users, Some of you may be noticing issues displaying measurements on the RIPE Atlas UI if you look at Public measurements or have lots of measurements of your own. We're currently working on this issue and apologise for any inconvenience caused. Kind regards, Chris Amin RIPE NCC

1 1

RIPE Atlas webinar recording and new dates
by Lia Hestina 18 Jan '16

18 Jan '16

Dear colleagues, We are happy to let you know that a recording of the Advance RIPE Atlas Usage webinar is now available on YouTube: https://www.youtube.com/watch?v=oJMFGuM0kMo <https://www.youtube.com/watch?v=oJMFGuM0kMo> <https://www.youtube.com/watch?v=oJMFGuM0kMo <https://www.youtube.com/watch?v=oJMFGuM0kMo>> If you would like to participate in a live webinar, we have two sessions available on the following dates: February 9 2016 March 17 2016 The Advanced RIPE Atlas Usage webinar teaches network operators how to use RIPE Atlas to monitor and troubleshoot their own networks. Learn more about the webinar and the necessary prerequisites: https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-a… <https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-a…><https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-a… <https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-a…>> RIPE NCC members can register online at: https://lirportal.ripe.net/training/register/courseCode/WEB20150046 <https://lirportal.ripe.net/training/register/courseCode/WEB20150046><https://lirportal.ripe.net/training/register/courseCode/WEB20150046 <https://lirportal.ripe.net/training/register/courseCode/WEB20150046>> Non-members can email training(a)ripe.net <mailto:training@ripe.net> <mailto:training@ripe.net <mailto:training@ripe.net>> and be manually registered. Kind regards, RIPE Atlas Team

1 0

Error on multi-probe measurement creation
by Matt Calder 15 Jan '16

15 Jan '16

Starting on Jan 6th, I started getting this error when creating new measurements. "Your selection of probes contains at least one probe that is unavailable. Error 104." These measurements had been running with no issues for the last year. I tried checking through the API that all probe's status' are Connected and are Public but it doesn't seem to make a difference. I am specifying a list of specific probes to be used which is needed for the specific experiment. Small number of probes like 1, 2, or 3 usually work. Larger numbers like 10 - 75, work occasionally. 300 - 400 probes per measurement never seem to work. Appreciate any help. Matt

1 1

What is 'iwantbcp38compliancetesting' user tag?
by Geert Jan de Groot 13 Jan '16

13 Jan '16

When revisiting the settings of my probe, I found this 'iwantbcp38compliancetesting' user tag. I know what BCP38 is, but what is the meaning of the tag? Is it a poll? Geert Jan

8 11

integrity checks for the Atlas software?
by Wilfried Woeber 12 Jan '16

12 Jan '16

While thinking about options or mechanisms to make virtual probes "tamper-proof" I had this question coming up: Is the probe software capable to "verify" (check-sum or digital sig) the bootstrap kit and then, during run-time, verify that the code in memory is still genuine? Thanks, Wilfried

6 5

Atlas probe offline
by Steve Hill 11 Jan '16

11 Jan '16

My Atlas probe (ID 14587) has been showing as offline since December 16th. I can see DHCP requests/replies, it ARPs for the gateway and I can see DNS requests and pings from the probe, and successful replies to all of this traffic being sent back to the probe. e.g.: 12:13:38.790096 IP 192.168.0.115.35404 > 217.146.115.154.53: 2+ AAAA? ctr-nue15.atlas.ripe.net. (42) 12:13:38.797337 IP 217.146.115.154.53 > 192.168.0.115.35404: 2 1/6/12 AAAA 2a01:4f8:120:14ee::2 (482) 12:13:38.798179 IP 192.168.0.115.57785 > 217.146.115.154.53: 3+ A? ctr-nue15.atlas.ripe.net. (42) 12:13:38.799649 IP 217.146.115.154.53 > 192.168.0.115.57785: 3 1/6/12 A 78.46.87.51 (470) 12:14:58.990977 IP 192.168.0.115.37934 > 217.146.115.154.53: 2+ AAAA? IUSB-READONLY.U36.M6466B3B0EC98.sos.atlas.ripe.net. (68) 12:14:59.060132 IP 217.146.115.154.53 > 192.168.0.115.37934: 2 1/1/2 AAAA 2001:67c:2e8:11::c100:1337 (164) 12:14:59.060983 IP 192.168.0.115.57523 > 217.146.115.154.53: 3+ A? IUSB-READONLY.U36.M6466B3B0EC98.sos.atlas.ripe.net. (68) 12:14:59.114915 IP 217.146.115.154.53 > 192.168.0.115.57523: 3 1/1/2 A 193.0.19.55 (152) 12:14:59.115925 IP 192.168.0.115 > 193.0.19.55: ICMP echo request, id 954, seq 0, length 64 12:14:59.142586 IP 193.0.19.55 > 192.168.0.115: ICMP echo reply, id 954, seq 0, length 64 12:15:00.116800 IP 192.168.0.115 > 193.0.19.55: ICMP echo request, id 954, seq 1, length 64 12:15:00.143773 IP 193.0.19.55 > 192.168.0.115: ICMP echo reply, id 954, seq 1, length 64 I can't see any other IPv4 traffic, but I do see IPv6 HTTPS traffic. I'm not sure where to go next with figuring out why the probe seems to have vanished. Any ideas would be greatly appreciated. Many thanks. -- - Steve

6 8

Examination of ARM based Atlas telemetry nodes
by Michael Schloh von Bennewitz 10 Jan '16

10 Jan '16

Hello developers, I'm scheduled to talk at the forthcoming MINIX conference, and was hoping to have the chance to examine your ARM based Atlas telemetry system. I only know of the Raspberry Pi devices loaned to the Tor project, and this could be relevant to my IoT work (leveraging IPv6 and ARM.) Andrew Tanenbaum recommended I write to Philip, is he here? Cheers, Michael -- Michael Schloh von Bennewitz Software Development Engineer Europalab Networks R&D, Munich Office: +49(89)44239885 UTC+2 Mobile: Same as 'Office' VoIP: sips:michael@schloh.com Web: http://michael.schloh.com/

3 2

Availability report accuracy
by Lorenzo Colitti 03 Jan '16

03 Jan '16

Hi, mostly out of curiosity: what sort of accuracy are the numbers in the monthly availability report? For example: the report says that my probe was "connected" 99.95% of the time (down for 20 seconds) in December. What does that mean? That the SSH control connection was not up? That the probe didn't have link? That it couldn't reach any targets? Something else? Cheers, Lorenzo

4 4

Seven new RIPE Atlas anchors have joined the community
by Michela Galante 31 Dec '15

31 Dec '15

Dear RIPE Atlas users, Since the previous announcement, seven new RIPE Atlas anchors have been activated bringing the total number to 164. - nc-nou-as56055, hosted by Micro Logic Systems (MLS) in Nouméa, New Caledonia. - bg-sof-as47872, hosted by Sofia Connect in Sofia, Bulgaria. - bg-sls-as198228, hosted by Silistra Telecom Solutions in Silistra, Bulgaria. - fr-ysd-as201958, hosted by Claranet in Saint-Denis, France. - de-erl-as680, hosted by Friedrich-Alexander-Universität Erlangen-Nürnberg in Erlangen, Germany. - cr-sjo-as263779, hosted by NIC Costa Rica in San José, Costa Rica and sponsored by LACNIC. - nl-roo-as43350, hosted by NFOrce Entertainment in Roosendaal, Netherlands. The map of all anchor locations is available at: https://atlas.ripe.net/anchors/map/ You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ And here are the logos and links to hosting companies: https://atlas.ripe.net/get-involved/community/#!tab-anchor-sponsors We are still accepting new applications from organisations interested in hosting a RIPE Atlas anchor. We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa, in order to add more geographical diversity to the measurement data. There are more organisations that want to host a RIPE Atlas anchor but don’t have the necessary funding. To learn more about sponsoring an anchor, please contact us at mcb(a)ripe.net To apply for your own RIPE Atlas anchor: https://atlas.ripe.net/get-involved/become-an-anchor-host/ For any other questions, please contact us at atlas(a)ripe.net We’d like to thank all the anchor hosts and the organisations sponsoring anchors for their support in 2015. Thanks to you it was possible to expand the coverage and reach this amazing goal. Wishing all of you the best for 2016. Michela Galante on behalf of the RIPE Atlas Team RIPE NCC

1 0

How to deal with inaccurate geocoding of probes
by Klaus Darilion 30 Dec '15

30 Dec '15

Hi! Inspired by https://perso.telecom-paristech.fr/~drossi/index.php?n=Dataset.Anycast I wanted to detect my Anycast locations using the Atlas probes. The problem is, that my results are only as accurate as the geocoding of the Atlas probes. For example probe #19273 is reported to be somewhere in Kansas. Bit the probe is only 5ms away from my LAX server and also traceroute indicates the probe is in LAX (traceroute to 63.84.150.1). So, now I am seeking some advice how to handle such problems. Is there some tag that indicates "verified location"? Any other ideas? Thanks Klaus

2 1

Ticket response times
by Micha Bailey 30 Dec '15

30 Dec '15

Hi, what's the average time for responses to atlas(a)ripe.net tickets? I've been waiting almost 2 months to hear back on 1193254, and was wondering if that's a typical wait time or if it fell between the cracks...

3 2

Anchor probes with broken lat/lon
by Klaus Darilion 29 Dec '15

29 Dec '15

https://atlas.ripe.net/api/v1/probe/6155/ "latitude": 2228.7695, "longitude": -4412.6105, https://atlas.ripe.net/api/v1/probe/6166/ "latitude": 2840.3705, "longitude": 631.8105, regards Klaus

2 1

Exploring the Idea of RIPE Atlas Virtual Probes
by Vesna Manojlovic 29 Dec '15

29 Dec '15

Dear colleagues, Some of you have asked about Virtual Probes on this list. Although we don't plan to make virtual probes available in 2016, we do plan to investigate this idea and develop some prototypes. Please find more details on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/exploring-the-idea-of-r… Kind regards, Vesna Manojlovic RIPE NCC

5 7

Support for arbitrary DNS queries
by Shumon Huque 26 Dec '15

26 Dec '15

I'd like to request the ability to have RIPE Atlas probes be able to issue DNS queries for arbitrary record types, and have that capability exposed in the API. I'm particularly interested in newer DANE record types like TLSA, OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful. Is this feasible? Are others interested in this capability? Thanks! Shumon Huque

11 19

13 new zones added to DNSMON
by Vesna Manojlovic 22 Dec '15

22 Dec '15

2 2

DNS measurement failed
by Maciej Andziński 16 Dec '15

16 Dec '15

Hi, Since yesterday I've been encountering a problem, many of the DNS measurements end with "failed" status. It happens for every measurement that tries to query 8.8.8.8, 8.8.4.4 or when using "Use the Probe's Resolver(s)" feature. However, everything works fine when querying a-dns.pl (194.181.87.156) server. Sample measurements: 3082732 3083505 3083581 Do you observe any issues related to the lack of available probes / exceeded limits? Many greetings, Maciej Andziński, NASK

3 4

Number of packets now ignored for ICMP tests?
by Stephane Bortzmeyer 16 Dec '15

16 Dec '15

I asked just one packet: {'definitions': [{'description': 'Ping 2001:67c:217c:6::2 from AS #3215', 'af': 6, 'packets': 1, 'type': 'ping', 'is_oneoff': True, 'target': '2001:67c:217c:6::2'}], 'probes': [{'requested': 500, 'type': 'asn', 'value': '3215', 'tags': {'include': ['system-ipv6-works']}}]} But, for the nine probes that were selected, I got 27 tests, which is the default of 3 packets per probe. Strange. Measurement #3083491

2 2

[request] AD bit in DNS query
by Maciej Andziński 15 Dec '15

15 Dec '15

Hi, Apropos of the discussion about arbitrary QTYPE in DNS measurement, I would like to make a request for another small improvement. It would be nice if a probe had the ability to send a DNS query with AD bit set. Such query would be useful in some cases (for instance when using "Use the Probe's Resolver(s)" feature) and would reduce data volume. According to RFC6840 section 5.7: 5.7. Setting the AD Bit on Queries The semantics of the Authentic Data (AD) bit in the query were previously undefined. Section 4.6 of [RFC4035] instructed resolvers to always clear the AD bit when composing queries. This document defines setting the AD bit in a query as a signal indicating that the requester understands and is interested in the value of the AD bit in the response. This allows a requester to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit. Many greetings, Maciej Andziński, NASK

1 0

more than 10 concurrent measurements to the same target
by Klaus Darilion 12 Dec '15

12 Dec '15

Hi! When scheduling checks I often get the error: "We do not allow more than 10 concurrent measurements to the same target." Imo this is not correct. Yes, I do schedule more then 10 measurements to the same target, but they are not concurrent. They are sequential - one ofter the other. Thus, it would be great if this check could be fixed to consider start and stop times. Thanks Klaus

4 4

DNSmon "not indicative of what happens to normal traffic" claims the root ops
by Stephane Bortzmeyer 11 Dec '15

11 Dec '15

http://root-servers.org/news/events-of-20151130.txt

6 11

Probe Address Discovery
by Mike 10 Dec '15

10 Dec '15

On the Network tab for my probe, there is a section named, "Probe Address Discovery". It shows the addresses on my probe, placing a green check mark next to the one(s) it thinks are the public address(es) for the probe. For my probe, the IPv4 address shown in the IP Echo Service row has a green check mark. Unfortunately, that IPv4 address was replaced about a month ago by another IPv4 address, and it can no longer be considered to be an address for my probe. Additionally, the IPv6 address for the IP Echo Service is also incorrect, but that one doesn't have a green check mark next to it. Is it a problem that these addresses are incorrect? Is there a way to refresh them, or have them refreshed, with the correct IP addresses? thanks.

1 0

What is the Aggregator on Map of DNS Measurements
by Klaus Darilion 09 Dec '15

09 Dec '15

Hi! The MAP of DNS Measurements contains an "Aggregator" option. Unfortunately the online help (Enter a regular expression ....) does not help much. Is this feature somewhere described in detail? I do not understand it. Thanks Klaus

2 2

CAIDA BGP Hackathon 6-7 Feb 2016 -- Call for Participation
by Vesna Manojlovic 09 Dec '15

09 Dec '15

Hi everyone, as a continuation of our own successful RIPE Atlas events, we are now taking part in CAIDA's BGP "live" hackahton, by providing data, measurements platform, expertise -- and you ;-) RIPE NCC's services, such as RIS & RIPE Atlas, will be "remixed" with other BGP-related data sources & tools, to create wonderful new hacks. As participants in RIPE Atlas community, you are very much invited to take part in this event. Details are below. Regards, Vesna -------- Forwarded Message -------- Subject: [mat-wg] CAIDA BGP Hackathon 6, 7 Feb 2016 -- Call for Participation Date: Tue, 8 Dec 2015 20:37:49 -0800 From: Alberto Dainotti <alberto(a)caida.org> To: mat-wg(a)ripe.net What: CAIDA BGP Hackathon, Call for Participation (CFP) When: Feb 6-7, 2016 Where: the San Diego Supercomputer Center (SDSC) on the University of California at San Diego (UCSD) campus. Who: Parties interested in hacking on live BGP data. Inquiries: bgp-hackathon-info(a)caida.org Important Deadline: Dec 22, 2015 for travel grant requests Apply to attend: http://www.caida.org/workshops/bgp-hackathon/1602/ CAIDA, in cooperation with CSU, USC, UFMG, FORTH, Route Views, RIPE NCC, will host a BGP Hackathon on the 6-7th of February 2016 at UC San Diego (La Jolla, CA, USA). The theme of the hackathon is “live BGP measurements and monitoring”. We will provide participating teams with access to data sources and a toolbox: live streaming of BGP data, the new BGPMon interface, BGP processing tools and APIs such as the opensource BGPStream software framework, the PEERING testbed, RIPE RIS, visualization tools, and data-plane active measurement platforms such as CAIDA Ark and RIPE Atlas. Participating teams will work on "challenges" that extend, integrate and demonstrate the utility of these platforms/data for understanding or solving practical problems (e.g., detecting BGP prefix hijacking, evaluating anycast performance, effectively visualizing phenomena). The hackathon will be held in San Diego the weekend immediately preceding the NANOG conference and the AIMS academic Internet measurement workshop. The hackathon aims to: - bring together these different communities, e.g., to discuss problems operators face that academics may want to research; - advertise tools (e.g., PEERING peering.usc.edu, BGPStream bgpstream.caida.org) to the communities and get people familiar with using them, and encourage further use in the future; - get people working together on interesting/important problems, hopefully spurring further collaboration on these problems; - provide extra incentive for students to attend NANOG. ### FORMAT Each team of 2-4 people will work on a "challenge". The organization committee will propose a set of challenges to bootstrap feedback and refinement based on community input: participants can propose totally new challenges, modifications to existing ones, and express their preferences. The set of potential challenges is described in the event website at https://github.com/CAIDA/bgp-hackathon/wiki/List-of-Challenges and will continuously evolve in the days preceding the hackathon. On Saturday morning, participants will very briefly introduce their interests and ideas and teams will be officially formed. On Saturday and Sunday, participants will work together in teams to hack and develop their ideas, culminating in very short presentations to the jury on Sunday evening and a party to announce the winning teams and celebrate everyone's participation. During the event, domain-experts will provide support to the teams. Participants are free to work on drafted challenges and on their own ideas in the days preceding the hackathon. A mailing list and documentation will provide support on the platforms/tools/data used in the hackathon. However, for the teams to compete in the hackathon for prizes, they will have to demonstrate that substantial work was done during the two-day event. ### PARTICIPATION AND TRAVEL GRANTS Application to participate in the hackathon is open from December 8, 2016. Application does not guarantee participation. There is no application fee, and no participation fee. We will accept applications until one week before the hackathon, or until capacity is reached. However, the deadline to apply for a travel grant (through the hackathon application form) is 22 December 2015. Travel grants reimburse flights and hotel expenses. Food and drinks will be provided throughout the two-day event. http://www.caida.org/workshops/bgp-hackathon/1602/

1 0

Map-based visualisations for Atlas data
by Baptiste Jonglez 08 Dec '15

08 Dec '15

Hi, Is there a way to reuse and adapt the code for the maps available here? https://atlas.ripe.net/results/maps/ It could be interesting to have a generic map-based visualisation, where all probes matching a certain set of conditions would be displayed. Possible applications include: - monitor IPv6 deployment for an AS, by displaying all probes matching "asn_v6 = XX". It would probably be useful to also display probes matching "asn_v4 = XX", as a baseline, using a different color - monitor DNS resolver outage geographically, by matching on system tags like "resolving A doesn't work". - match on user tags, like "IXP" or "core", to monitor deployment of Atlas at specific locations/types of networks. In all those examples, the "time slider" functionality would be extremely useful, to see the evolution over time. It could be even nicer if the slider could move automatically, so as to provide nice animations. Is all this currently feasible, and if not, would it be hard to implement? Thanks, Baptiste

3 2

Turris Omnia as probe Platform?
by Kessler, Thomas 08 Dec '15

08 Dec '15

Dear all, some of you are probably aware of the Turris Omnia project by CZ.NIC ( https://www.indiegogo.com/projects/turris-omnia-hi-performance-open-source-… ). This might be an interesting platform for running an VM probe?! Just thought it might be worth brining it up here for discussion. Cheers Thomas

7 9

New on RIPE Labs: DomainMON in RIPE Atlas
by Chris Amin 07 Dec '15

07 Dec '15

Dear colleagues, A few weeks ago we gave you a heads up about a new visualisation tool in RIPE Atlas called DomainMON, and we're pleased to announce that this is now available for all RIPE Atlas users with available credits. Please find more details on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-domainmon-is… Kind regards, Chris Amin RIPE NCC

1 1

Probe power down.
by Alistair Mackenzie 07 Dec '15

07 Dec '15

Hi all, I'm currently moving house and expect my probe to be offline for approximately one week, Is there any formal channels that I must notify ripe of this other than the location change once it's back online? Thanks, Alistair

3 3

Dead probes
by Marty Strong 01 Dec '15

01 Dec '15

Hi, I've got 1 or 2 dead probes, they power on but I see no mac address from them. They have the first 2 lights on, but none of the others. I don't see this combination listed on https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-pro… Has anybody else come across this issue? Anybody know what the light combination means? Marty

9 15

location field in probe API
by Bajpai, Vaibhav 01 Dec '15

01 Dec '15

Hello, TL;DR: The probe API does not expose the probe location even if I explicitly ask for it. location: A human readable location for this probe, either explicitly specified by the probe owner, or derived from the longitude and latitude. It appears the 'location' field in the probe API is hidden by default and it must be explicitly set in the request parameters to expose location field values. However, even if I do set it, I still don't get location entries. I made multiple permutations of query requests and also tried the usage example on the API documentation webpage [1]: Get the IPv4 addresses and the usually hidden human readable location string for public probes in Germany: https://atlas.ripe.net/api/v1/probe/?country_code=de&is_public=true&fields=… What could be wrong? -- Thanks! PS: It seems, this field is also missing in the probe archive API. [1] https://atlas.ripe.net/docs/rest/#probe Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =====================================================

1 0

Fwd: Re: Measurements delete and ping issue
by Daniel Karrenberg 30 Nov '15

30 Nov '15

I did not copy the list on this message and then realised that it is a generic answer that deserves to be seen and archived here. Daniel -------- Forwarded Message -------- Subject: Re: [atlas] Measurements delete and ping issue To: Andrea Consadori <andrea.consadori(a)hotmail.it> References: <DUB126-W888F5B62064D1CE913A99DE0000(a)phx.gbl> From: Daniel Karrenberg <daniel.karrenberg(a)ripe.net> Message-ID: <565C9760.2050704(a)ripe.net> Date: Mon, 30 Nov 2015 19:37:20 +0100 On 30.11.15 15:42 , Andrea Consadori wrote: > > > Hi all, > i just start using proble atlas and i found is not possible to delete > Stopped measurements from web, it's normal? > i try to search on old mailing list messages and seems to be and old > issue but i still cannot delete stopped masurements > (for example ids: 3050379 > <https://atlas.ripe.net/measurements/3050379/>, 3034900 > <https://atlas.ripe.net/measurements/3034900/>) > ... Andrea, An important idea behind RIPE Atlas is that all results are re-useable. Therefore we store the results of *all* measurements as long as we possibly can because those results can be useful for other researchers even if they did not run the measurements themselves. Each result says something about the packet flow in the Internet at the particular time it was obtained. There is no way we can foresee how these results can help to answer interesting research questions and help us to understand the Internet packet layer better than we do now. For a recent example of this, please see https://labs.ripe.net/Members/becha/ripe-atlas-tools-hackathon-results "ASN Tryst". Therefore we do not provide the functionality of deleting measurements. The only way we foresee that results can be deleted is if we run out of storage space. Of course that one has to be careful to select the measurements one wants to re-use according to the question one wants to answer. Your measurement shows this very well. I do not recommend using your results unless the question is about reachability with RTTs under 6ms. I hope this answers your question Daniel (co-inventor of RIPE Atlas)

1 0

Measurements delete and ping issue
by Andrea Consadori 30 Nov '15

30 Nov '15

Hi all, i just start using proble atlas and i found is not possible to delete Stopped measurements from web, it's normal? i try to search on old mailing list messages and seems to be and old issue but i still cannot delete stopped masurements (for example ids: 3050379, 3034900) Another issue i see, if i create a ping measurement (id 3034899) under probes i see RTT column unreachable for every raw... but the public ip is pingable form everywhere.. maybe there's simple solutions i cannot found, if so can someone show me a good link where to found how to fix this two issues? Regards Andrea Consadori

2 1