- ripe-atlas - mailman.ripe.net

*-capable ≠ *-works + *-doesnt-work
by Bajpai, Vaibhav 20 Apr '16

20 Apr '16

Hello, I am looking at the probe API data for connected probes (status = 1) for day = 20160418 system-ipv6-capable = 3556 system-ipv6-works = 2995 system-ipv6-doesnt-work = 710 Why is system-ipv6-works + system-ipv6-doesnt-work > system-ipv6-capable? system-ipv4-capable = 9336 system-ipv4-works = 9187 system-ipv4-doesnt-work = 67 Why is system-ipv4-works + system-ipv4-doesnt-work < system-ipv4-capable? Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany ===================================

2 2

Question
by Anthony 19 Apr '16

19 Apr '16

Hello, I would have wanted to know if my graphs probe appears well is how well does the measures not? For you everything is ok or not? : https://atlas.ripe.net/probes/27379/ thank you in advance

2 2

RIPE Atlas CLI Toolset now available on NLNOG RING
by Vesna Manojlovic 19 Apr '16

19 Apr '16

Dear colleagues, in the spirit of cooperation between the monitoring & measuring platforms, I am happy to announce: RIPE Atlas CLI Toolset have been installed on RING! If you are already participating in NLNOG RING, now you can use RIPE Atlas CLI Toolset for "quick & dirty" access to RIPE Atlas measurements & probes. More info about RING: https://ring.nlnog.net RING nodes are also available as targets through RIPE Atlas web interface for measurements creation: https://atlas.ripe.net/targets/ringnodes/list/ https://atlas.ripe.net/targets/ringnodes/map/ Regards, Vesna Reminder about CLI tools: Source: https://github.com/RIPE-NCC/ripe-atlas-tools/ Documentation: https://ripe-atlas-tools.readthedocs.org/ In addition to "raw install", tools are also packaged in many distros: OpenBSD, FreeBSD, Gentoo, Arch, Debian and Ubuntu (in progress: Fedora, Windows). Examples of usage of RIPE Atlas CLI tools on RING: ripe@ripe01:~$ ripe-atlas report 1001 --probes 1 20 bytes from probe #1 212.238.160.244 to 193.0.14.129 (193.0.14.129): ttl=59 times:6.658, 6.591, 6.298, ripe@ripe01:~$ ripe-atlas measurements --af 6 --status ongoing --limit 15 --search nlnog Filters: Search: nlnog Af: 6 Status in: (2,) Id Type Description Status ================================================================================ 1027844 traceroute Jump Ongoing 1027846 traceroute Clara DE Ongoing 1037103 ping tenet01.ring.nlnog.net Ongoing 1404594 ping RedpillLinpro-v6 Ongoing 1596748 ping world4you01.ring.nlnog.net Ongoing 1688325 ping ping6 on amazon03 Ongoing 3678270 traceroute Traceroute measurement to bluezonejordan01 Ongoing ================================================================================ Showing 7 of 7 total measurements ripe@ripe01:~$ ripe-atlas configure --setauthorisation.create=7b4c-xxxx ripe@ripe01:~$ ripe-atlas measure ping --target ping.xs4all.nl Looking good! Your measurement was created and details about it can be found here: https://atlas.ripe.net/measurements/3671547/ Connecting to stream... 48 bytes from probe #6174 217.10.140.74 to 194.109.6.8 (194.109.6.8): ttl=56 times:8.849, 8.781, 8.78, 48 bytes from probe #26941 88.85.47.152 to 194.109.6.8 (194.109.6.8): ttl=55 times:74.372, 74.487, 74.748, 48 bytes from probe #24596 176.144.180.224 to 194.109.6.8 (194.109.6.8): ttl=57 times:45.418, 45.249, 45.5, 48 bytes from probe #6187 196.10.54.135 to 194.109.6.8 (194.109.6.8): ttl=56 times:155.65, 155.58, 155.668, 48 bytes from probe #3207 37.49.102.93 to 194.109.6.8 (194.109.6.8): ttl=50 times:24.4, 27.627, 21.95, 48 bytes from probe #6186 82.195.72.11 to 194.109.6.8 (194.109.6.8): ttl=58 times:7.087, 7.101, 7.052, ... Read more about it on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/announcing-the-cli-tool…

1 0

API filtering for looking at measurements?
by Baptiste Jonglez 18 Apr '16

18 Apr '16

Hi, I would like to find measurements matching some specific conditions, so I tried to use the measurement API documented here: https://atlas.ripe.net/docs/rest/ However, filters don't seem to have the intended effect. For instance, I tried to restrict to a specific range of starting time: https://atlas.ripe.net/api/v1/measurement/?start_time__gte=1443654000&start… but looking at the first result (measurement ID 1411440), its start time is 1564618500, which is way outside of the requested range. Similarly when filtering by type: https://atlas.ripe.net/api/v1/measurement/?type=2 type=2 is supposed to be IPv4 traceroute, but the first result is measurement ID 1001, which is an IPv4 ping. Am I using the API incorrectly, or is there a bug somewhere? Thanks, Baptiste

2 2

Open ports?
by Anthony 15 Apr '16

15 Apr '16

Hello, I received my probe today and I had to disable the firewall for my box that appears connected to the site. I reactivated and after all the work area, but I would have liked to know what need had to open? How to know if everything is ok? Sorry for my English, thank you in advance

4 5

Incorrect probe connection information?
by Max Mühlbronner 13 Apr '16

13 Apr '16

Hi, I think there is a small bug/issue with the statistics of the probe (Tab : "Network") : Connection Information Time Connected Percent Last Week 9d 10h 2m 100.00% Last Month 55d 10h 2m 100.00% How could it be that Last Month my probe was connected for 55 days? (It's only a single probe) Any idea? Best Regards Max M.

3 3

Introducing the RIPE Forum
by Vesna Manojlovic 12 Apr '16

12 Apr '16

Dear colleagues, There’s a new way to participate on the RIPE Atlas mailing list! We are introducing the RIPE Forum, a web-based interface for reading and sending emails on RIPE community mailing lists. We developed the RIPE Forum in-house based on feedback we received from members of the RIPE community who wanted the option to interact and share information in a more modern way. But it’s important to note that this new interface is completely optional – those who like using the established mailing list system can continue on as they always have, and won’t notice any difference. RIPE Atlas mailing list will be the first one. We have plans to make the RIPE Forum available for other RIPE Community mailings lists after the RIPE 72 Meeting in May. If you’re interested, you can start using it here: https://www.ripe.net/participate/mail/forum/ We created a special mailing list for testing purposes, so that any conversations about the platform itself can be contained there without disrupting the regular flow of discussions on the RIPE Atlas mailing list. Feel free to send test messages and try out the RIPE Forum on this special list: https://www.ripe.net/participate/mail/forum/ripe-forum-test Learn more how the forum works and the background of the project: https://labs.ripe.net/Members/marco_schmidt/introducing-the-ripe-forum The forum is still in "beta" status – there are likely still some bugs and we are continuously working to improve things, so please keep that in mind while exploring the forum. You can give your feedback by clicking on the “Report a bug” button on the forum, or leave a comment on the above RIPE Labs article. We hope you’ll enjoy the RIPE Forum, and look forward to your feedback! Kind regards, Vesna Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 2

change stop date?
by gboonie 11 Apr '16

11 Apr '16

Hi, In the past, when you scheduled a measurement for some weeks, you could change the end date. This does not seem possible any more. Is that intentional? Could that be changed please? Also, can't we change measurements to private anymore? The field is there to show that it is public, but changing does not seem possible anymore. Thanks, Dave

1 0

Local network checks
by Alison Wheeler 11 Apr '16

11 Apr '16

Recently my probe stopped responding to RIPE even though it was pingable through the local network. Putting aside what the cause might have been* is there any way to 're-awaken' or cycle in some way a probe without physical access to it? (* sfaict it didn't restart when the USB socket on the server it takes power from was remotely restarted) Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 9

Failing 4GB USB on v3 probes?
by Phillip Remaker 11 Apr '16

11 Apr '16

So far, I have had two of the SanDisk Cruzer 4GB drives (SDCZ33) fail, and I think I have two other ML-3020 (v3) devices with the same fate. Case #1, the drive fell into read only one. Case #2, the drive identifies to the USB, but read of block 0 (capacity) fails. The first time I called SanDisk and jumped through their hundred hoops to replace it.They were reluctant since I couldn't produce a receipt. This time, I just grabbed an old 8GB USB and dropped it in. Looks like it only uses 3GB. Does Atlas plan to pursue warranty claim, or is this an acceptable failure level for the probes?

2 1

Flow-id of built-in traceroute measurement
by Wenqin SHAO 08 Apr '16

08 Apr '16

Dear list, I have some questions concerning the flow-id of built-in traceroute measurements and are seeking for your help. As many of you may have already noticed, the flow-id of the built-in traceroute measurement periodically varies form 0 to 15, in a circular manner. With this behaviour, it is supposed to reveal the diversity of underlying IP paths. In the case that there are more than 16 unique IP paths between a source and destination pair, could this scheme reveal all of these IP paths? If it can, which leads to more than one IP paths per flow-id? Is it normal, from a load balancer point of view? If it can not, then why not a wider range of flow-id (more nuances in header hash results), say [0, 63]? Is it related to common realisation of load balancer? Many thanks in advance. Best regards, Wenqin ==== Wenqin SHAO PhD Candidate Telecom ParisTech

2 2

Scheduling a test for all probes?
by Jared Mauch 06 Apr '16

06 Apr '16

Is there a way to schedule a one-off test on all the probes to be run “at a leisurely pace”, eg: looking up a specific DNS QNAME? (I’ll call it a lazy query/scheduling). - Jared

3 2

Research using RIPE Atlas probes: How Pingable are the Pingables?
by Vesna Manojlovic 05 Apr '16

05 Apr '16

Dear colleagues, take a look at how the "pingable:" and "ping-hdl:" attributes have been adopted in the last five years and how reachable the pingable addresses registered in the RIPE Database are when pinged from RIPE Atlas. Spoiler alert: It could be better. Please find the details on RIPE Labs: https://labs.ripe.net/Members/wilhelm/how-pingable-are-the-pingables Kind regards, Vesna

1 0

Credits sharing and other new features
by Vesna Manojlovic 04 Apr '16

04 Apr '16

Dear colleagues, many of you have been asking for the credits sharing options, and now we have added two new ways that you can go about it: - standing orders - share access - and the transfers are still possible too All about credits: https://atlas.ripe.net/docs/credits/ In addition to that, in the past few months, we've added some other new features and functionality to RIPE Atlas, including making the DNSMON code available on GitHub for personal use, displaying IPv4 vs IPv6 comparisons in LatencyMON, and new limits on probes per measurement and results per day. Learn more about the latest updates on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-altas-update-dnsmo… Regards, Vesna

2 1

Re: [atlas] [ripe.net #1204062] request to add three more ccTLDs to, DNSMON: CR, SG, and TW
by Romeo Zwart 04 Apr '16

04 Apr '16

Hi Peter, You have recently requested to have three ccTLD zones be added to DNSMON. Unfortunately, since the zones do not fall into the RIPE service region and the zone owners are not members of the RIPE NCC, the request does not qualify according to ripe-661. If the zone owners do wish their zones to be monitored by DNSMON we need to ask them to become members of the RIPE NCC. Alternatively they could argument an exception for their case with the DNS working group. Apologies for the confusion. Feel free to contact us if you have further questions. Kind regards, Romeo -------- Forwarded Message -------- Subject: Re: [ripe.net #1204062] request to add three more ccTLDs to DNSMON: CR, SG, and TW Date: Mon, 04 Apr 2016 10:39:21 +0200 From: pk(a)denic.de <atlas(a)ripe.net> Reply-To: atlas(a)ripe.net CC: becha(a)ripe.net, mgalante(a)ripe.net Hi Alastair, On Thu, Mar 31, 2016 at 11:40:48AM +0200, Alastair Strachan wrote: > Could you please provide me with the points of contact who gave you their consent for an independent verification? sure, we'll dig it out of our ticketing system. Regards, Peter

1 0

probe tagged as "system: Firewall problem suspected"
by sarah.wassermann＠student.ulg.ac.be 02 Apr '16

02 Apr '16

Hi, I have (once again) problems with my probe (probeID: 24102). This time, it got tagged as "system: Firewall problem suspected". The strange thing is that I did not touch anything on my router when this happened and did not change any other configuration... This probe is located in Luxembourg. I now brought it to Belgium and plugged it into the router I have here. Nothing changed. Furthermore, here in Belgium, its 3rd light is slowly blinking, which let's suppose that it gets tuck in the network-testing phase. Anybody knows how to fix this? (I already had some problems with that probe ("system: Hardware problem suspected") but I could solve them thanks to a hint given by a user.) My worst problem is that, due to this issue, we have difficulties earning enough credits for our research... So I would be really happy if this problem could be solved easily :( Thanks! Sarah

4 8

Implementing structured error reports ("Problem Details for HTTP APIs")?
by Stephane Bortzmeyer 01 Apr '16

01 Apr '16

Hello, IETF approved the future RFC draft-ietf-appsawg-http-problem "Problem Details for HTTP APIs" which standardize structured error reports (in JSON) to add machine-readable information to HTTP error codes. Would it be a good idea to convert current Atlas reports ({"error":{"status":400,"code":104,"detail":"__all__: Your selected prefix is not covered by our network.","title":"Bad Request"}}) to the new and standard format?

3 4

IPv6 working
by gboonie 30 Mar '16

30 Mar '16

Hi, This seems to be an anchor that has Ipv6 connectivity but probably connected to a network with a incomplete routing table. https://atlas.ripe.net/probes/6149/#!tab-builtins It cannot reach a lot of the internet so I'm wondering what causes the system to flag it as "ipv6 works". Also, I've done a few hundred pings and found that probes get their "ipv6 works" only taken away after it has been failing for a few hours. Could that please be changed to something short like 10 minutes? And if possible, some stability tests so that if connectivity comes and goes that if does not get back it's "works" status. Thanks, Dave

4 4

Re: [atlas] Probe not flagged as "IPv4 works"
by gboonie 24 Mar '16

24 Mar '16

Hi Philip, A powercycle did not help. I did a reboot without USB stick and formated it in my laptop. Then plugged it back and after some minutes it started working again. Some googeling showed that the stick can be replaced by a 4GB stick but the one that it currently has seemed to be only 1GB. What is your view on this? The other strange thing is that the probe did somehow earn credits. That seems to contradict that it was down. On the other hand the "Connection and traffic" graph clearly shows that it is up after been down. Thanks, Dave Op 23-3-2016 om 16:29 schreef Philip Homburg: > On 2016/03/23 16:27 , Dave . wrote: >> Dit you remotely order a reboot?I did get the mail that the probe is >> down now. > Yes, I did. It is now connected again, but doesn't really work. > >> I'll power cycle when I get home and if it does not help, I'll do te >> delayed plug in trick. > That would be nice. > > Philip >

2 1

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