- ripe-atlas - mailman.ripe.net

DigitalOcean (SG) has joined RIPE Atlas anchors
by Michela Galante 10 Sep '14

10 Sep '14

Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called sg-sin-as133165 and it is hosted by DigitalOcean in Singapore City, Singapore. Congratulations to DigitalOcean for their third anchor online! 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, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

1 0

The Beta Version of the New DNSMON is Now Available
by Vesna Manojlovic 08 Sep '14

08 Sep '14

Dear colleagues, The DNS Monitoring Service (DNSMON) has been providing a comprehensive, objective and up-to-date overview of the quality of various global and regional DNS operators' services since 2003. We are in the process of integrating DNSMON within RIPE Atlas and the beta version of the new DNSMON is now publicly available: https://atlas.ripe.net/dnsmon We have also published a RIPE Labs article detailing what’s changed in the new DNSMON: https://labs.ripe.net/Members/fatemah_mafi/an-updated-dns-monitoring-service We invite you all to try the new service and provide your feedback. We’re confident that the new DNSMON will continue to meet your needs and hope that you'll be happy with the new features. Please send your comments and questions to the DNS Working Group Mailing List at dns-wg(a)ripe.net. Kind regards, Vesna Manojlovic Measurements Community Building RIPE NCC

7 10

S-IT Informationstechnologie Betreiber (DE) has joined RIPE Atlas anchors
by Michela Galante 25 Aug '14

25 Aug '14

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 de-cal-as39702 and it is hosted by S-IT Informationstechnologie Betreiber in Calw, Germany. With this anchor we reached a total of 70 online. 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, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

2 1

DigitalOcean has joined RIPE Atlas anchors
by Michela Galante 19 Aug '14

19 Aug '14

Dear RIPE Atlas users, We're happy to announce that two RIPE Atlas anchors have joined the network and are now available as targets for probe hosts conducting their own user-defined measurements. The new anchors are uk-slo-as202109 located in Slough, United Kingdom and us-sfo-as14061 located in San Francisco, United States, both hosted by DigitalOcean. Congratulations to DigitalOcean for bringing their two anchors online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards these anchors 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, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

1 0

Probe on a /31 or /32 IPv4 network
by Baptiste Jonglez 18 Aug '14

18 Aug '14

Hi, We would like to deploy our Atlas probe on a separate L2 network, but without having to spend 4 IPv4 addresses (i.e. a /30 network). Using a /31 would be nice, but the web UI doesn't allow it as static IPv4 configuration ("The Gateway address should be different from the ending network address"). Would it be possible to allow /31 in the web UI? I believe the probes themselves support it. Even nicer would be support for /32 networks, even though it is perhaps less usual. This can easily be done with iproute2 on Linux, assuming the probe is 192.0.2.48/32 and its gateway is 192.0.2.1: ip addr add 192.0.2.48/32 dev eth0 ip route add 192.0.2.1/32 dev eth0 ip route add default via 192.0.2.1 or even shorter: ip addr add 192.0.2.48/32 dev eth0 ip route add default via 192.0.2.1 onlink dev eth0 Using a gateway that is not on the same subnet doesn't sound very nice, but again, the goal is to avoid wasting precious IPv4 space. Thanks, Baptiste

4 4

measurment with endtime - faulty date
by gboonie 18 Aug '14

18 Aug '14

Hi, I noticed the last few days that when I create a new measurement with a end date and time next week that I get a failure message on the next screen. --- Your measurement will start ASAP. Your measurement will end at: Y-8-16 0:i UTC. and in the next screen: Enter a valid date/time. --- What I selected was: 2014-08-16 00:45 Multiple tests on 2 different Win7 PCs give the same result. Regards, Dave

2 4

atlas on a public subnet
by James Sink 14 Aug '14

14 Aug '14

Hello all, I just received my atlas probe and am about to deploy it. However I have a question about the subnet I am going to place it it on. Is it safe to put it on an unfiltered public ip? If not what ACL should I place on the interface? Thanks --- James Sink Network Engineer P: 800-477-1477 x: 813

2 2

Current crediting issues
by Robert Kisteleki 14 Aug '14

14 Aug '14

Dear All, We have reports of the Atlas billing process doing strange things at the moment. We're investigating these and will get back to you with more information. Regards, Robert

1 2

Upcoming "Measurements Tools" Workshop for LIRs: 19 September, in Amsterdam
by Vesna Manojlovic 12 Aug '14

12 Aug '14

Dear colleagues, Training Services, RIPEstat/RIPE Atlas developers and me will be giving a "Measurements Tools" Workshop on 19 September, in Amsterdam. Registration is possible for members of RIPE NCC via LIR Portal: https://lirportal.ripe.net/training/courses Below is the preliminary information about the workshop. If you know people who would be interested, please forward this to them. Regards, Vesna Target audience: LIRs (RIPE NCC members), network operators Goal of the Measurements Tools Workshop is to convey the benefits that the network operators can gain from using RIPE NCC tools, such as RIPEstat and RIPE Atlas - through practical exercises and hands-on approach. Prerequisites: RIPE NCC Access account; general knowledge about IP networking, DNS and BGP, as well as of one/any programming language. Workshop overview: RIPEstat topics: Basic: 1) finding the information about IP resources 2) comparing resources 3) finding anti-abuse information Advanced: embedding the widget using BGplay using command-line interface analysing events (examples of uses cases) personalizing RIPEstat RIPE Atlas topics: Basic: 1) creating a measurement 2) looking-up measurements data and analyzing the data 3) monitoring: setting-up status checks Advanced: member-specific services use cases by other people analysing information in Internet Traffic Maps take part in the community: share your code, distribute the probes, install anchors…

1 0

Probe suddenly lost IPv6 connectivity
by Ondřej Caletka 11 Aug '14

11 Aug '14

Hi, strange thing happened today. My probe v2 #3467 suddenly lost IPv6 connectivity and reconnected to the control server using IPv4. The probe does not even respond to ping6 ff02::1%eth1 sent from the router. I wonder what could cause such behavior. I will try to reboot the probe once I'll reach it. -- Ondřej Caletka

2 2

Probe 2092 shown as offline for a month
by David Precious 06 Aug '14

06 Aug '14

Hi there, My v1 probe #2092 has been showing as offline for a month, despite being powered up and pinging. Yesterday I power-cycled it, and it came back up and answers pings again, but the Atlas control panel still shows it as disconnected. Is there any troubleshooting I can do to get more information? I've verified that I can ping it from my internal network. There's no egress filtering which would be blocking it from talking outbound. I've just had my router log new outbound connections then power-cycled the probe again. I saw it successfully obtain an IP via DHCP (10:13:21), then 31 minutes later, connected to oneill.atlas.ripe.net (193.0.19.12) on port 443 (10:44:50) (UK times). I have verified that another box on the same network can connect to that IP & port: [davidp@columbia:~]$ telnet 193.0.19.12 443 Trying 193.0.19.12... Connected to 193.0.19.12. Escape character is '^]'. SSH-2.0-OpenSSH_5.3 Anything else I can do to provide more useful info? Cheers Dave P -- David Precious ("bigpresh") <davidp(a)preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github

2 4

Re: [atlas] Measurements can't be stopped
by Max Grobecker 02 Aug '14

02 Aug '14

Hi, YEAH! That did the trick ;-) I've never right-clicked on these items before... Thank you! Greetings from Wuppertal, Germany Max Grobecker Am 02.08.2014 um 11:52 schrieb Iñigo Ortiz de Urbina: > Hi Max, > > On Sat, Aug 2, 2014 at 11:43 AM, Max Grobecker > <max+ratlml(a)grobecker.info> wrote: >> Hi, >> >> I tried to stop a measurement, which was defined as "end never". >> >> In order to stop the measurement I opened it, clicked "Settings" and >> unchecked "End never". >> But regardless what I choose as "End at" time, it always gets refused with >> the hint that I need to enter a valid date. >> For example, [ 2014-08-03 ] [ 00:00 ] is refused as invalid date/time. >> >> Is there any option to stop this measurements? > > You can stop measurements by right-clicking on them, and then > selecting Stop. The options that you should see after right-clicking > are: Archive, Settings and Stop. > > HTH, > >> Thank you! >> >> -- >> Greetings from Wuppertal, Germany >> Max Grobecker >> > > >

1 0

Measurements can't be stopped
by Max Grobecker 02 Aug '14

02 Aug '14

Hi, I tried to stop a measurement, which was defined as "end never". In order to stop the measurement I opened it, clicked "Settings" and unchecked "End never". But regardless what I choose as "End at" time, it always gets refused with the hint that I need to enter a valid date. For example, [ 2014-08-03 ] [ 00:00 ] is refused as invalid date/time. Is there any option to stop this measurements? Thank you! -- Greetings from Wuppertal, Germany Max Grobecker

1 0

Static IPv6 problem
by Jonas Byström 01 Aug '14

01 Aug '14

Hi, I have a problem when i try to set a Static IPv6 adress i get on my probe. I get: No more than 3 static DNS values may be used at any given time for either IPv4 or IPv6. I have set: 2001:4860:4860::8888 and 2001:4860:4860::8844 as DNS. What should i do to get this to work? Regards Jonas Byström

3 2

Re: [atlas] [ripe.net #1133019] Re: Your RIPE Atlas Probe (ID: 16784) is not connected to our network
by Daniel Suchy 01 Aug '14

01 Aug '14

It's surprising, that you can't manage probe remotelly when it isn't "connected" (even you can directly reach it on L3). Technically, probe runs on Linux, so you can have SSH daemon with restricted IP access running here (listenning daemon has minimal performance overhead) - by current "behavior" you simply loose any way to diagnose problem - and dependence of established tunnel is another layer, which can fail... As stated before - simple rebooting is just a *workaround* of any issue, not a solution (but it seems that's your basic recomendation). I think you should work on improvements on probe diagnostics in such cases - new hardware versions of probes seems to be more problematic compared to older probes, as I can see also on atlas mailing list. I remember, that I had to plug out/in USB flash as some step with probe before (also your recomended "solution"). Also on probe should run some kind of watchdog, which reboots probe in case of similar problem automatically - probably it doesn't run now... With regards, Daniel On 31.7.2014 17:31, Philip Homburg wrote: > Hi Daniel, > > On Tue Jul 29 19:29:20 2014, danny(a)danysek.cz wrote: >> What checks did you performed at your side before sending such email? >> You don't have any kind of "emenergency" probe management, like SSH >> shell access directly to the device? What do you see in *your* logs >> about affected probe before it was disconnected? > > The mail gets sent when the is not connected for some time. Nothing more. > > There are no open ports on the probes. The probe can only be controlled when it is connected. > > There is some evidence in the logs that there was already something wrong with the probe when it disconnected. Most likely there is something wrong with the filesystem on the USB flash drive, but that is hard to say. > > Philip >

6 6

Re: [atlas] Paris-traceroute variations
by FANOU Roderick 31 Jul '14

31 Jul '14

Hi all, Just a quick question. What is the real difference between a TCP paris-traceroutes and an UDP paris-traceroute ? How do the probes perform each of them? Thanks, Best regards, Roderick On 26.06.2014 13:13, Philip Homburg wrote: > Hi Juan, > > On 2014/06/19 16:59 , Juan Antonio Cordero Fuertes wrote: >> Not sure this is the right place to ask this... sorry if it is not. >> >> I'm trying to configure Paris-traceroute measurements, and it is not >> clear for me what is the meaning of the /paris/ parameter. In >> https://atlas.ripe.net/docs/udm/ it is said that it corresponds, for >> values from 1 to 16, to "the number of variations to be used for a Paris >> traceroute <http://www.paris-traceroute.net/>". What is this? Does it >> correspond to the number of initial probes to be used by >> paris-traceroute? I am unable to figure it out from the RIPE Atlas >> docs... any indication would be appreciated. > > Paris-traceroute tries to make sure that all packets of a traceroute > take the same route through a load balancer. This in contrast to > traditional traceroute where packets from different hops typically take > different routes when load balancers are involved. > > However, in the case of paris-traceroute it is still interesting to find > out if there are multiple routes or not. For this reason, the traceroute > measurement creates different variations that may take a different route. > > Each interval, it will try one variation. So if you select 16 variations > then it will take 16 intervals before you get back to the first one. > > Philip

2 1

Re: [atlas] [ripe.net #1133019] Re: Your RIPE Atlas Probe is not connected to our network
by Daniel Suchy 29 Jul '14

29 Jul '14

There's no firewall / ACL, anything on the way, just pure L3 device. Probe worked properly, then disconnected without any logical reason with that notification received. Probe is pingable on both IPv4 and IPv6 from outside, proper (so there's no L3 issue on the way). Probe itself resets all incoming TCP connections from my IP address located in another ASN (probably due to firewall at the probe). On traffic mirrored from the probe I see ocasional NTP queries to some servers, so "something" on probe runs. Nothing else. You do not provide any access to probe for hosts to check anything directly, so I expect you can manage fully (as this is something running any kind of Linux?). As probe has public IPv4/IPv6 address, you should not have problem reach it. Unfortunatelly, probe is located on remote datacenter with limited physical access. Also this is not a solution of problem - with reboot you probably loose anything to diagnose causes of this problem. What checks did you performed at your side before sending such email? You don't have any kind of "emenergency" probe management, like SSH shell access directly to the device? What do you see in *your* logs about affected probe before it was disconnected? With regards, Daniel On 22.7.2014 11:17, Alastair Strachan wrote: > Hello Daniel, > > Thanks for your email. > > It would appear there is something on your network blocking the probe from connecting outside your network. Could I ask you to double check to ensure there is no security/firewall rule that has been updated or needs updating to allow the probe a clean connection outside your network. > > I would also recommend trying a complete power recycle on the probe. > > Thank you for taking the time to host a RIPE Atlas probe. > > If you have any further questions, please let me know > > Kind Regards, > > Alastair Strachan > > RIPE Atlas Team > > RIPE NCC Customer Satisfaction Survey > Tell us about your customer services experience by filling out the anonymous, three-question RIPE NCC customer satisfaction > > survey:https://www.ripe.net/contact/survey/satisfaction-cs/ > >> >> On 18.7.2014 05:40, RIPE Atlas wrote: >>> Dear RIPE Atlas probe host, >>> >>> Thank you for participating in RIPE Atlas! >>> >>> We have noticed that your probe is not connected to our infrastructure and has been >> disconnected since 2014-07-11 03:15 UTC. Could you please check >> whether everything is set up correctly on your side? If it is, and >> your probe is still reported as disconnected when you log in at >> https://atlas.ripe.net, please reply to this email so that we can >> follow up. >>> >>> You can review the instructions for setting up your probe at >> https://atlas.ripe.net/getting-started >>> >>> If you have any questions, please contact us at atlas(a)ripe.net >>> >>> Best regards, >>> >>> RIPE Atlas Team >>> >>> ********** >>> You are receiving this message because you applied for or were given >> a RIPE Atlas probe. We will only send messages when your probe >> becomes disconnected for an extended period of time. >>> >> > >

1 0

Fwd: Probe 2317 (home fibre) is disconnected
by Colin Johnston 29 Jul '14

29 Jul '14

strange, connectivity seems fine to me at least within BT network range and HSO network range ? Should I reset the probe or this is a bigger monitoring probe failure ? Colin Begin forwarded message: > From: RIPE Atlas <atlas(a)ripe.net> > Subject: Probe 2317 (home fibre) is disconnected > Date: 29 July 2014 12:30:05 BST > To: colin johnston <colinj(a)mx5.org.uk> > Delivered-To: colinj(a)mx5.org.uk > Received: by 10.70.41.145 with SMTP id f17csp332256pdl; Tue, 29 Jul 2014 04:30:32 -0700 (PDT) > Received: from koko.ripe.net (koko.ripe.net. [2001:67c:2e8:11::c100:1348]) by mx.google.com with ESMTPS id f10si19194016wic.74.2014.07.29.04.30.19 for <colinj(a)mx5.org.uk> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jul 2014 04:30:20 -0700 (PDT) > Received: from janus.atlas.ripe.net ([193.0.19.13]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from <atlas(a)ripe.net>) id 1XC5bZ-0004TU-Nf for colinj(a)mx5.org.uk; Tue, 29 Jul 2014 13:30:08 +0200 > Received: from localhost.localdomain ([127.0.0.1] helo=janus.atlas.ripe.net) by janus.atlas.ripe.net with esmtp (Exim 4.72) (envelope-from <atlas(a)ripe.net>) id 1XC5bZ-00004y-IA for colinj(a)mx5.org.uk; Tue, 29 Jul 2014 11:30:05 +0000 > X-Received: by 10.180.75.230 with SMTP id f6mr41435469wiw.5.1406633431897; Tue, 29 Jul 2014 04:30:31 -0700 (PDT) > Return-Path: <atlas(a)ripe.net> > Received-Spf: none (google.com: atlas(a)ripe.net does not designate permitted sender hosts) client-ip=2001:67c:2e8:11::c100:1348; > Authentication-Results: mx.google.com; spf=neutral (google.com: atlas(a)ripe.net does not designate permitted sender hosts) smtp.mail=atlas(a)ripe.net > Content-Type: text/plain; charset="utf-8" > Mime-Version: 1.0 > Content-Transfer-Encoding: 7bit > Message-Id: <20140729113005.32636.40047(a)janus.atlas.ripe.net> > X-Ripe-Spam-Level: / > X-Ripe-Spam-Report: Spam Total Points: 0.4 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 4.0 DCC_CHECK Detected as bulk mail by DCC (dcc-servers.net) > X-Ripe-Signature: 407c82a9d3629e01ca957e4b84b7f67191521e4a20cb459dafae86d3fab252b9 > > Dear colin, > > Your probe 2317 has been disconnected since 2014-07-29 10:38:01 UTC. > > This is an automatically generated email from RIPE Atlas. It was sent to you because you asked to be notified if your probe becomes disconnected for more than 30 minutes. > > If you want to change this, or disable this notification altogether, please go to https://atlas.ripe.net/probes/2317/, and click the "edit" button under "Notifications". > > Kind regards, > > RIPE Atlas Team

4 6

probe selection criteria on "WW" measurements
by Paul Vlaar 25 Jul '14

25 Jul '14

Hi, I have two questions regarding probe selection for UDMs. When I specify for example that I want to run an ongoing measurement on 250 probes in the "WW" region, will these probes remain the same throughout the lifecycle of the measurement (unlimited) or will these be somehow randomized every time the measurement is run? Secondly, I am wondering about even spread of probe location in doing such a measurement. For instance I am as much interested in results from regions that have only a few probes, as I am interested in results from those regions that are better served. When I look at the results so far of a test measurement, it appears that I'm receiving results from 35 probes in US, but only 3 from FI and none from NO. The latter surprises me a bit since there are 100 probes reported in NO, so why aren't there any results from those coming back? While I understand that countries with more probes will likely yield more results, I am wondering if there is any method to get a better "country-balanced" result for measurements ran in "WW". Thanks, ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar(a)afilias.info phone: +1-416-673-4078 mobile: +31-6-506-306-35 mobile USA: +1-602-410-4148

5 5

Support RIPE Atlas with RIPE NCC Board
by Daniel Karrenberg 25 Jul '14

25 Jul '14

The RIPE NCC Executive Board is discussing RIPE Atlas as documented in the latest meeting minutes that have been published recently. https://www.ripe.net/lir-services/ncc/executive-board/minutes/2014/minutes-… The relevant part is: --------- 3.3.1 ATLAS EB286 01/04/2014 AP The Board asked Axel to produce a break down of the costs for ATLAS over a period of  3 years and an outlook beyond 2014 to see the development on OPEX and CAPEX in the coming years. Furthermore the Board asked to see a comparison between the current figures and a case where TTM and DNSMON services were continued in their current form in 2014 and beyond. Status 19/06/2014: DONE There was discussion about the value of ATLAS to the various stakeholders and the associated maintenance cost. After discussion the Board asked for clear documentation of the results of the activities so that they could review and ultimately justify the cost of the project overall. The Board discussed the ongoing cost of the ATLAS project. The Board agreed that the value of the project needed to be packaged correctly. ATLAS now has many other projects wrapped into it and the activity needed proper and concise documentation as well as a solid marketing plan moving forward. ACTION EB295: The Board asked Axel to produce a value proposition for the ATLAS service in preparation for the September meeting. --------- It looks to me that the board needs to be re-assured that RIPE Atlas is valuable enough for the membership to justify the cost. Between the lines I read basic support but a desire to hear a consistent story and success stories of benefit to the membership. Of course the RIPE NCC staff will produce an answer to the board and I will do my best to help with that. But ultimately the board is responsible to the membership. So it would be very very helpful if we could get some users of RIPE Atlas to speak up both directly to the board and to help us prepare our answer to the board. Daniel

3 2

New on RIPE Labs: Midsummer Update for RIPE Atlas
by Vesna Manojlovic 24 Jul '14

24 Jul '14

Dear colleagues, in these hot and slow summer days, we give you an overview of the current status of RIPE Atlas, new features since the last update during RIPE68, and an insight into past and future community activities: https://labs.ripe.net/Members/fatemah_mafi/ripe-atlas-midsummer-update-2014 Regards, Vesna -- Measurements Community Building team <MCB(a)ripe.net>

2 1

some thoughts and question regrding probe "stability"
by Wilfried Woeber 22 Jul '14

22 Jul '14

Hi Folks, triggered by the discussion related to DNSMON, and an issue (power, resolved) with one of my V1 probes, I'd like to get some input or start a disussion or an investigation. To start with, I am not very clear what the term "stability" w/should mean in this context, as the probes are supposed to buffer measurment data locally, at least for a while (true?). So, here goes... Obviously, looking at some Atlas Stat pages, there are probes with a 100% uptime. Now, looking a the 3 under my supervision (2x V1, 1 Anchor), ref "Connected" and "Disconnected", there's no chance to get near that value, as all of them tend to topple over on a regular basis, mostly for a *short* period of time in the range of 0m(!) to some 30+m. With respct to the bahaviour of the Anchor, which is mounted in the same rack as the backbone router it connects to, in a Data Center, we tried to correlate the (reported) disconnection events with the router and interface logs for the probe. No luck there, also, no maint works or the like, so I presume the Anchor didn't reboot or that there were "real" network problems. Let's compare the most recent dis/connection logs for my 3 pets: ID 6009 2014-07-14 03:58:03 3d 8h 16m Still Connected 2014-05-27 03:03:54 48d 0h 46m 2014-07-14 03:50:47 0h 7m 2014-05-20 15:19:02 6d 11h 37m 2014-05-27 02:57:00 0h 6m 2014-05-14 21:16:56 5d 17h 59m 2014-05-20 15:16:22 0h 2m 2014-04-08 16:03:21 36d 5h 1m 2014-05-14 21:05:17 0h 11m ID 0466 2014-07-13 23:31:05 3d 12h 45m Still Connected 2014-07-09 23:05:40 3d 23h 54m 2014-07-13 22:59:49 0h 31m 2014-06-16 10:53:21 23d 11h 55m 2014-07-09 22:49:04 0h 16m 2014-05-25 09:03:06 22d 1h 38m 2014-06-16 10:42:00 0h 11m 2014-05-24 20:34:50 11h 54m 2014-05-25 08:29:12 0h 33m ID 0414 2014-07-07 23:41:23 9d 12h 35m Still Connected 2014-07-02 03:58:45 5d 19h 31m 2014-07-07 23:29:54 0h 11m 2014-06-13 09:37:50 18d 18h 7m 2014-07-02 03:45:08 0h 13m 2014-06-08 13:22:14 4d 20h 7m 2014-06-13 09:29:38 0h 8m 2014-05-21 08:29:23 18d 4h 45m 2014-06-08 13:15:11 0h 7m Again, I fail to see some obvious correlation, what am I missing? Does anyone else see a similar pattern? How to start debugging, if there's anythig that needs debugging? Thanks for your ideas and help! Wilfried

9 13

Actual public measurements
by Brian Rak 22 Jul '14

22 Jul '14

Is there any way to link someone to a public measurement, without requiring that they go and sign up for a RIPE account? It's an annoying extra step when I'm just trying to show someone the results of a measurement. I'm aware I could grab that raw data via the API, but then I'd have to re-implement the UI... which I don't have time for.

3 2

Questions about paris traceroute
by Thomas Holterbach 18 Jul '14

18 Jul '14

Hi all, I would like to start some Paris-traceroute measurements from RIPE Atlas probes, with a specific frequency and a control over the paris id. In particular, I am wondering if it is possible to start a traceroute measurement with all the 16 paris id at the same time. Because so far, I only find out how to start periodically a traceroute with a different paris id. I am also a little bit confused about the interval between two measurements. In the doc, it is written that the default value (900s) is the minimum, but when I create a UDM, the minimum interval seems to be 60s. I also tried 10 secondes with Restful API and the measurement started, but the real interval seems to be far upper than 10s. Can you give me more informations about this interval ? Thank you for your help, Thomas.

5 6

adding probes to UDM
by Jared Mauch 17 Jul '14

17 Jul '14

I have a few ongoing UDMs and there’s a few things that have occurred over the duration: 1) I requested 5 probes and only 3 were available (at the time). Is there a way to request the system consider more? 2) I requested 5 probes and 5 were available, but some have fallen out (and are now crossed out). I want to request 1 or 2 more to get back to the 5 threshold so I feel I have more accurate data. Are either of these possible, or do I need to stop these and create a new UDM with a larger number of probes to keep a more stable population over time? (They have been running for ~2 months so far). - jared

2 1

Three new Anchors have joined the RIPE Atlas network
by Lia Hestina 15 Jul '14

15 Jul '14

Dear RIPE Atlas users, We proudly announce three new RIPE Atlas anchors have joined the network and are now available as target for probe hosts conducting their own user-defined measurements. The new anchors are called: be-anr-as2611 is hosted by MOSAIC - University of Antwerp - iMinds uk-lon-as60157 is hosted by Antheus Telecom LTD us-wct-as7922 is hosted by Comcast Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards these anchors 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: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

1 0

Credit Usage math
by Jared Mauch 15 Jul '14

15 Jul '14

I am in the lucky position of earning more credits than I currently care to spend so have engaged in a bit of a 'share the wealth' campaign. (Yes, you can ask me for credits, but I am hoping something can be done to improve this as well, read on). I just sent 1 million credits to someone and now my credit "burn" rate is calculated as a large negative number. (I recently sent someone else 10x that and it caused odd math as well). It seems a few things happen: 1) E-Mail alerts go out based on credit consumption (including transfers) in past N hours. 2) Credit "earn rate" calculation includes transfers vs UDM samples. Currently I have income of almost 1M/day but shows -4k/hour due to UDM + transfer. This means when I sent 10m credits to someone, the system thought I was using 10m credits/day and emailed me a few times because it thought I would run out of credits when my UDMs gave me a few more weeks of time with my balance. I also have a large number of "small" UDMs which post quite often, so have 397 pages of the recent credit history. Are there plans to improve this display? - Jared

2 1

Local resolver for one off DNS measurement
by Rob Turner 15 Jul '14

15 Jul '14

Hi is it possible to perform a one off DNS A record test that uses each probes local resolver? I think this would be handy to test DNS propagation. Rob.

2 1

Solido Networks ApS has joined RIPE Atlas anchors
by Lia Hestina 14 Jul '14

14 Jul '14

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 dk-blp-as59469 and it is hosted by Solido Networks ApS in Ballerup, Denmark. Our congratulations to Solido Networks ApS! This is the first anchor in Denmark. In our announcement about last week's new anchor, there was a typo in the company name and we would like to apologise for this. The anchor, cz-prg-as2852, is hosted by CESNET, z. s. p. o. in Prague, Czech Republic. 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: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

1 0

Atlas nagios tools
by john 12 Jul '14

12 Jul '14

Hello all, i would like to introduce a tool[1] i have been developing on and off for a bit of time. its uses the atlas latest call[2] and sagan[3] to preform nagios checks based on measurement results. it supports checking a wide range of ssl, dns and http parameters which i have tried to document on github[1]. it also supports checking ping however i think it is better to use the atlas status checks[4][5] for this. The git hub repo contains some sample nagios configs which can be seen in action at https://icinga.johnbond.org/ (ripeatlas/ripeatlas). at $dayjob we dont use nagios/icinga so this is not well tested and one should expect some bugs. if you dare inspect the source you can definitely expect spelling mistakes and hacks. Thanks to Iñigo Ortiz de Urbina and Wolfgang Nagele for patches. Also thanks to Daniel Quinn and Philip Homburg for working with me integrating some changes to sagan. feedback, criticism and patches most welcome John *as http is a restricted measurement this has received little testing [1]https://github.com/b4ldr/atlas [2]https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-latest-res… [3]https://github.com/RIPE-NCC/ripe.atlas.sagan [4]https://labs.ripe.net/Members/suzanne_taylor_muzzin/introducing-ripe-atla… [5]https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib/blob…

1 0

CEZNET, z.s.p.o has joined RIPE Atlas anchors
by Lia Hestina 12 Jul '14

12 Jul '14

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 cz-prg-as2852 and it is hosted by CEZNET, z.s.p.o. in Prague, Czech Republic. 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, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

2 1

Fwd: Deleting/editing a UDM: Not Owner
by Hendrik Visage 08 Jul '14

08 Jul '14

Good day, I'm trying to delete/stop/edit an UDM, but I get this error: Not Owner when I click on the settings tab. Screen grab: https://www.dropbox.com/s/p0u2oiboct3ut23/Screenshot%202014-07-03%2021.21.1… Any advice ideas how to do that? Thanks HEndrik

3 7

Fwd: monitoring RFC1918 IPs
by Hendrik Visage 07 Jul '14

07 Jul '14

Hi there, I'd like to monitor a couple of internal routes from one of my probes, but I get this error: Ping: Field 'target' : Measurement target "10.23.0.1" is invalid. Is that a limit somewhere? possible to relax that for probes owned/operated by me? Thanks HEndrik

4 4

How to find the correct ASN of a probe?
by Eravuchira, Steffie Jacob 07 Jul '14

07 Jul '14

Hello, The RIPE Atlas probe API [1] says that the probe with ID 14468 belongs to the ASN 6871. As per the RIPE stat API [2], the holder for ASN 6871 is PlusNet PLC,GB. I run a traceroute measurement from the same probe (Probe ID 14468) and the IP address of the second hop ICMP response is "86.4.10.1". But the RIPE stat API [2] shows that "86.4.10.1" belongs to the prefix announced by ASN 5089, NTL Virgin Media Limited,GB. Could someone tell me how I can find the correct AS which the probe belongs to? [1] https://atlas.ripe.net/api/v1/probe/?id=14468 [2] https://stat.ripe.net/ Kind Regards, Steffie

2 1

Probe connectivity status update interval
by Ondřej Caletka 04 Jul '14

04 Jul '14

Hello list, yesterday, we've deployed IPv6 in the network probe #16666 is located. The probe obtained its address via SLAAC and is world-pingable, however the Atlas system still haven't recognized the probe has IPv6 connectivity. When scheduling IPv6 UDMs for this probe, they are stuck in state "Scheduling" - see UDM #1694838 or #1694575. I guess that the system avoids scheduling IPv6 measurements to probes without IPv6 connectivity. How often is the connectivity status updated? Should we replug the probe to update its status? Cheers, Ondřej Caletka

1 0

tracing from anchor nodes
by Klaus Darilion 02 Jul '14

02 Jul '14

Hi! According to DNSMON [1] r.ns.at IPv4 is not reachable from us-bos-as11488. Are there any tools available to analyse the problem from the anchor? E.g. performing a traceroute from the respective anchor node? Thanks Klaus [1] https://atlas.ripe.net/dnsmon/group/at.?dnsmon.session.color_range_pls=0-66…

3 3

Paris-traceroute variations
by Juan Antonio Cordero Fuertes 30 Jun '14

30 Jun '14

Not sure this is the right place to ask this... sorry if it is not. I'm trying to configure Paris-traceroute measurements, and it is not clear for me what is the meaning of the *paris* parameter. In https://atlas.ripe.net/docs/udm/ it is said that it corresponds, for values from 1 to 16, to "the number of variations to be used for a Paris traceroute <http://www.paris-traceroute.net/>". What is this? Does it correspond to the number of initial probes to be used by paris-traceroute? I am unable to figure it out from the RIPE Atlas docs... any indication would be appreciated. Thanks, Juan Antonio Cordero

5 8

IPv6 ICMP - denied packets
by Joachim Tingvold 24 Jun '14

24 Jun '14

Hi, I recently installed a probe at home, and now my router spits out loads of 'denied icmpv6'-messages. After going through the logs for the last two days, I have ~1900 entries of denies towards the probe -- all of them more or less like this (with different source); ### Jun 22 2014 22:30:22.863 CEST: %IPV6_ACL-6-ACCESSLOGDP: list ipv6-inbound/2100 denied icmpv6 2A01:4F8:130:24A4::13:76 (Po1.102) -> {PROBE-IPV6-ADDRESS} (1/4), 8 packets ### I've got an ACL applied ingress on the link to my ISP, and the relevant part is shown below; ### ipv6 access-list ipv6-inbound sequence 2000 permit icmp any any echo-reply sequence 2005 permit icmp any any echo-request sequence 2010 permit icmp any any packet-too-big sequence 2015 permit icmp any any time-exceeded sequence 2020 permit icmp any any destination-unreachable sequence 2025 permit icmp any any parameter-problem sequence 2100 deny icmp any any log-input ### This ACL conforms to RFC4890[1] (except the Mobile IPv6 part). Of the 1900 entries, all of them are ICMPv6 type 1. ~300 of them have the code bit[2] set to 1, and ~1600 of them are set to 4. These are the top sources; ### 367 2001:500:2::C 313 2001:500:2D::D 289 2A01:4F8:130:24A4::13:76 289 2001:500:3::42 196 2A01:4F8:121:30A4::78:15 161 2001:DC3::35 100 2001:7FE::53 67 2001:7FD::1 60 2001:500:2F::F ### All of these are DNS root servers (except those starting with 2A01:4F8, which are some Atlas-thingies). It seems to me that the Atlas-probe sends quite some amount of ICMPv6-packets to the root DNS-servers (and even Atlas' own boxes), that are being returned with errors. Why does the probe do this, and does it actually rely on these replies? [1] <http://www.ietf.org/rfc/rfc4890.txt> [2] <http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xml#icm…> -- Joachim

3 3

AFRINIC (MU) has joined RIPE Atlas anchors
by Michela Galante 18 Jun '14

18 Jun '14

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 mu-plu-as327681 and it is hosted by AFRINIC in Port Louis, Mauritius. This is the third anchor hosted by an RIR on behalf of the RIPE NCC. 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, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

1 0

Selecting only anchors for UDM
by Ondřej Caletka 12 Jun '14

12 Jun '14

Hello list, is there a way to run an UDM on Anchors only? I think it would be a good feature, especially for precise latency measurement. Cheers, Ondřej Caletka

10 18

Using RIPE Atlas to Debug Network Issues
by Vesna Manojlovic 12 Jun '14

12 Jun '14

Dear colleagues, Please find the use-case for RIPE Atlas in debugging network issues, in this RIPE Labs article written by Tim Kleefass from BelWü, who is hosting a RIPE Atlas anchor. (and who holds the record for the shortest time from purchasing the anchor to it going live!) https://labs.ripe.net/Members/tim_kleefass/how-fast-the-ripe-atlas-anchor-h… Regards, Vesna

1 0

Speed tests?
by Brian Rak 11 Jun '14

11 Jun '14

Are there any plans to allow testing download speed from the probes? I guess this could cause problems for people who have the probes on metered bandwidth plans.

12 12

Lemuria Communications (US) has joined RIPE Atlas anchors
by Michela Galante 10 Jun '14

10 Jun '14

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 us-dal-as7366 and it is hosted by Lemuria Communications in Dallas, United States. 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, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

1 0

Empty from feild
by john 06 Jun '14

06 Jun '14

Hello All, Quick question about the data format. What would cause a measurement to have an empty from field but contain data? An example would be probe_id 13663 from measurement 1672218[1]. A cursory glance seems to happens a lot more with V6 Thanks John [1]https://atlas.ripe.net/api/v1/measurement-latest/1672218/

3 4

NTT Communications (US, Seattle and Atlanta) have joined RIPE Atlas anchors
by Michela Galante 06 Jun '14

06 Jun '14

Dear RIPE Atlas users, We're happy to announce that two more RIPE Atlas anchors have joined the network and are now available as targets for probe hosts conducting their own user-defined measurements. The new anchors, both hosted by NTT Communications in United States, are: us-sea-as2914, in Seattle us-atl-as2914, in Atlanta Congratulations to NTT Communications for their third and forth anchor online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards these anchors 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, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

1 0

A collection of tools in Perl
by Stephane Bortzmeyer 04 Jun '14

04 Jun '14

https://github.com/pierdom/atlas-toolbox

3 2

RIPN (RU) has joined RIPE Atlas anchors
by Michela Galante 03 Jun '14

03 Jun '14

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 ru-mow-as15835 and it is hosted by RIPN in Moscow, Russia. 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, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

1 0

Changes to the Distribution Model for RIPE Atlas Probes
by Vesna Manojlovic 03 Jun '14

03 Jun '14

Dear colleagues, we have made some adjustments in the distribution model of RIPE Atlas probes to ensure wider topological and geographical probe coverage. Please read more in this RIPE Labs article: https://labs.ripe.net/Members/fatemah_mafi/changes-to-the-distribution-mode… Regards, Vesna

1 0

Probe not showing IPv6 ASN and subnet on map
by JC 02 Jun '14

02 Jun '14

Hi, We just setup our probe (id: 17328) and configured static IPv6 on it. Built-in measurements to IPv6 destinations seems to perform correctly from this probe. However, when we display detailed information about the probe on the coverage map https://atlas.ripe.net/results/maps/network-coverage/ we only see IPv4 information and no IPv6 subnet or ASN. Besides, searching for our IPv6 ASN (21538) in the filter field brings no results. Thanks for your help. Regards, JC

2 1

Where is "My probe" tab?
by Gilles Pion 28 May '14

28 May '14

Hello, Just received my probe today, Registered it, plugged it, all leds seem correct. I've followed the instruction on page https://atlas.ripe.net/get-involved/become-a-host/ where one can read: "Once we see that your probe is connected to the RIPE Atlas infrastructure, you'll be able to see it listed on the Public Probes page and, when you are logged in to the RIPE Atlas website, it will appear under the "My Probes" tab on that page. But, although logged on the web site I'm unable to find this "My Probes" tab on the "Public Probes" page Could someone help? -- Gilles

2 2