- ripe-atlas - mailman.ripe.net

Probe not flagged as "IPv4 works"
by gboonie 23 Mar '16

23 Mar '16

Hi, I have 3 probes in different networks. This one probe is not selected for tests when I do a test on multiple probes that I select op probe ID or ASN. This is the troubling probe: https://atlas.ripe.net/probes/24645/ It is connected via a 4G LTE router. The router is up and everything else works. I could just reboot the modem and the probe but I'm wondering why it fails to get flagged with "IPv4 works". The "built in" test seem to work fine. What could be the issue? Is there something I could do to debug? Or just reboot and forget about it? Thanks, Dave

2 1

Fwd: New on RIPE Labs: Support for Elliptic Curve Cryptography (ECC) in DNS Resolvers as Seen by RIPE Atlas
by Vesna Manojlovic 21 Mar '16

21 Mar '16

Dear colleagues, Please find this new article on RIPE Labs contributed by Maciej Andzinski: The Elliptic Curve Cryptography (ECC) is becoming increasingly popular in DNSSEC. While it is sometimes considered to be a remedy for the low DNSSEC adoption rate, there is also a lot of controversy around it. One of the main concerns is that DNSSEC-validating resolvers don't always make use of ECC. We used RIPE Atlas to measure the support for ECC in DNS resolvers. https://labs.ripe.net/Members/maciej_andzinski_2/support-for-elliptic-curve… Kind regards, Vesna Manojlovic RIPE NCC

1 0

Eleven new RIPE Atlas anchors have joined the community
by Vesna Manojlovic 18 Mar '16

18 Mar '16

Dear colleagues, 11 new RIPE Atlas anchors have been activated during the last month, bringing the total number to 188: - uk-lba-as33920, hosted by aql in Leeds, United Kingdom - de-ber-as62310, hosted by managedhosting.de GmbH in Berlin, Germany - bt-thi-as38740, hosted by Tashi InfoComm Limited in Thimpbu, Bhutan and sponsored by APNIC - cz-prg-as52130, hosted by Livesport s.r.o. in Prague, Czech Republic - de-dar-as8365, hosted by TU Darmstadt - Secure Mobile Networking Lab/ DFG Collaborative Research Center in Darmstadt, Germany - one more anchor hosted by INX-ZA/Internet Service Providers' Association of South Africa: za-cpt-as37663 in Cape Town, South Africa - ee-tll-as51349, by Estonian Internet Foundation in Tallinn, Estonia - two anchors hosted by Sky UK Limited: uk-lon-as5607 in London and uk-slo-as5607 in Slough, United Kingdom - sixth anchor for Leaseweb Network B.V.: hk-hkg-as133752 in Hong Kong - fi-hel-as3274, hosted by Cygate Oy in Helsinki, Finland. 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, Vesna Manojlovic Measurements Community Building RIPE NCC

1 0

Webinar "Advanced RIPE Atlas Usage" on Thursday 17 March
by Michela Galante 15 Mar '16

15 Mar '16

Dear colleagues, On Thursday 17 March, 12:30 UTC, we are hosting the webinar on "Advanced RIPE Atlas Usage", aiming to teach network operators how to use RIPE Atlas measurements for network monitoring and troubleshooting. Register now at: https://lirportal.ripe.net/training/register/courseCode/WEB20160011 Web-registration is *only* possible for LIRs (RIPE NCC members). Non-members of RIPE NCC (people who do not have "Reg-ID") can email training(a)ripe.net and be manually registered. More details below. -------------------------- https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-a… This is part of the series of interactive on-line learning sessions, that give you the opportunity to learn and interact with trainers without leaving your desk, as well as for hands-on practice, and to get your questions answered by developers. Learn how to: - Use RIPE Atlas measurements for network monitoring and troubleshooting - Use API calls for measurement creation - Integrate RIPE Atlas with existing monitoring systems Webinars start at 12:30 UTC, and take about one hour. ----------------------------- We look forward to seeing you online. Kind regards, Michela Galante and Vesna Manojlovic RIPE NCC

1 0

Travel funding for RIPE Atlas Interface Hackathon
by Michela Galante 10 Mar '16

10 Mar '16

Dear colleagues, We’re excited to announce that travel funding is now available for the RIPE Atlas Interface Hackathon! As a reminder, the hackathon takes place 21-22 May in Copenhagen, the weekend before the RIPE 72 Meeting. We're looking for creative thinkers to help us develop new interfaces for RIPE Atlas - and we can now help cover the cost of travel and accommodation for a number of successful applicants, thanks to the generous financial support of our sponsor, Comcast. All of the event details and application form are available online: https://atlas.ripe.net/hackathon/Interface/?pk_campaign=hackathon&pk_kwd=li… *The application deadline is 23 March* We hope to see you there! Michela and the RIPE Atlas Team

1 0

DNS64 system tag using RFC7050
by Pier Carlo Chiodi 09 Mar '16

09 Mar '16

Hello, I would like to recall this short conversation that appeared in ipv6-wg: https://www.ripe.net/ripe/mail/archives/ipv6-wg/2015-November/002747.html I was wondering if it is worth adding a new system tag to probes: something like system-dns64. >From a quick analysis that I made using RFC7050 [1] I noticed that only a handful of probes are behind a DNS64 box, but I think it would be useful to have them tagged, to avoid spending credits to detect them every time. Or perhaps the game is not worth the candle... In that case, you can find my results as of yesterday there on GitHub. Bests, 1] https://gist.github.com/pierky/e5ec5c8f8f926bff3ef3#file-ripe-atlas-rfc7050… -- Pier Carlo Chiodi

1 0

Querying your own measurements
by Sebastian Castro 09 Mar '16

09 Mar '16

Hi: I'm currently testing the API to get a list of my own measurements. The API here reports ----------- Querying for Your Own Measurements In order to limit the results to your measurements only, just add a mine=true argument. For example: /api/v1/measurement/?mine=true Note that this only works if you're logged in, otherwise the result is the same as for any unauthenticated user. ----------- This seems to imply you need to manage a session within your code to get your own measurements, which I think violates the principle of a REST API. If you have the API key that provides you with access, shouldn't be reasonable to run the call as /api/v1/measurement/?mine=true&key=API_KEY and get a list of your own measurements? Thoughts? Am I reading the documentation in the wrong way? Thanks in advance -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535

9 17

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