- ripe-atlas - mailman.ripe.net

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

29 Dec '15

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

5 7

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

26 Dec '15

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

11 19

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

22 Dec '15

2 2

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

16 Dec '15

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

3 4

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

16 Dec '15

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

2 2

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

15 Dec '15

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

1 0

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

12 Dec '15

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

4 4

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

11 Dec '15

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

6 11

Probe Address Discovery
by Mike 10 Dec '15

10 Dec '15

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

1 0

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

09 Dec '15

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

2 2

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

09 Dec '15

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

1 0

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

08 Dec '15

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

3 2

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

08 Dec '15

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

7 9

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

07 Dec '15

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

1 1

Probe power down.
by Alistair Mackenzie 07 Dec '15

07 Dec '15

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

3 3

Dead probes
by Marty Strong 02 Dec '15

02 Dec '15

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

9 15

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

01 Dec '15

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

1 0

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

30 Nov '15

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

1 0

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

30 Nov '15

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

2 1

Problem with Map Tab of DNS Measurement
by Klaus Darilion 30 Nov '15

30 Nov '15

Hi! I did a one-off DNS measurement: https://atlas.ripe.net/measurements/3050168/ As long as the measurement was running, I could click on the map tab. But now as the measurement is finished, the "map" tab is gone. While loading the site I see for a short time the tabs General information, Probes, Map and Results. But as soon as the site is loaded completely the Map and Probes tab are gone. Calling the map explicitely using https://atlas.ripe.net/measurements/3050168/#!map does also not work. Is this a feature or a bug? Thanks Klaus

2 1

New on RIPE Labs: RIPE Atlas Tools Hackathon Results
by Vesna Manojlovic 30 Nov '15

30 Nov '15

Dear colleagues, The second RIPE Atlas hackathon took place 13-14 November 2015 in conjunction with the RIPE 71 meeting. Impressive results were hacked together by programmers and operators during an intensive weekend of work and fun in Bucharest. In this article we celebrate the hackathon achievements and report about the benefits for the community in detail: https://labs.ripe.net/Members/becha/ripe-atlas-tools-hackathon-results Regards, Vesna ps to bring you some spirit of the event... http://www.memes.com/meme/784389

1 0

Feature Request Web Interface
by Klaus Darilion 30 Nov '15

30 Nov '15

When viewing the "Map" results of a DNS measurement some details will be shown in a pop-up when clicking on the respective probe. It would be great if the NSID (if available) would be shown too (not only Response Time and Serial) thanks Klaus

1 0

Spoofing measurenments
by Pavel Odintsov 27 Nov '15

27 Nov '15

Hello, Community! I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some difficult ethical question. Could we detect probe hosts who do not deploy outgoing filtering and accept spoofed traffic? We need to know amount of they. It's really important for solving spoofing issue in Internet scale. -- Sincerely yours, Pavel Odintsov

14 20

[request]: probe timezone offsets
by Bajpai, Vaibhav 27 Nov '15

27 Nov '15

Hello, It would be nice to report a timezone offset for each probe via the probe API. Since measurements are reported in UTC, it's currently difficult to visualise a timeseries result in the local time of the probe. In order to do this, one has to turn the geolocations (currently reported in the probe API) of the probe to the corresponding timezone offset (which takes time) and then adjust the measurement timestamps by the timezone offset. It would be great if the timezone offsets of the probe are available via API. Thanks! PS: This is very low priority request. Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =====================================================

2 2

spread control (thank you)
by Bajpai, Vaibhav 27 Nov '15

27 Nov '15

Hello, > The new spread control, available via the API and the web interface, now > allows users to tailor this to their specific needs. In addition to specifying > the measurement frequency, users can also specify the duration of a time > interval within which the probes will be linearly distributed. This week got hit by the need to have ^ feature. Just wanted to say thank you to the RIPE team for implementing this! Best, Vaibhav > On 05 Nov 2015, at 10:32, Mirjam Kuehne <mir(a)ripe.net> wrote: > > Dear colleagues, > > There are a number of interesting new features and enhancements for RIPE > Atlas users. Learn how you can put them to use: > > https://labs.ripe.net/Members/kistel/ripe-atlas-update-http-measurements-cl… > > Kind regards, > Mirjam Kuehne > RIPE NCC ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =====================================================

1 0

Leftover budget? Consider a RIPE Atlas anchor
by Vesna Manojlovic 27 Nov '15

27 Nov '15

Dear all, The end of the year is coming closer, and you might be wondering, “What is the best way to spend some of the money still left in my budget, while at the same time contributing to the good of the Internet?” Why not consider hosting a RIPE Atlas anchor?! Investing in an anchor means you will: - Gain access to a wealth of measurement data (IPv4/IPv6 pings, trace routes) targeting your anchor from all the other anchors and hundreds of probes throughout the RIPE Atlas network, without spending credits - Earn 10 times more credits compared to hosing a regular probe that you can spend on your own customised measurements - HTTP measurements towards your anchor [1] - Have your logo included on the RIPE Atlas website [2] - Join a growing community that is providing great benefit to the Internet: there are currently 159 RIPE Atlas anchors around the world You can learn more about hosting an anchor here: https://atlas.ripe.net/get-involved/become-an-anchor-host/ Thanks, and happy holiday season! Vesna [1] https://labs.ripe.net/Members/kistel/ripe-atlas-update-http-measurements-cl… [2] https://atlas.ripe.net/get-involved/community/#!anchor-sponsors

1 0

Invitation: RIPE NCC Member Lunches in London & Manchester, mid-December 2015
by Vesna Manojlovic 26 Nov '15

26 Nov '15

Dear colleagues, We warmly invite you to join us for a RIPE NCC Member Lunches: - in London on Wednesday, 9 December. - in Manchester on Thursday, 10 December The lunch gives members an open-discussion format to exchange ideas and information among each other as well as with RIPE NCC staff. The goal of these lunches is to offer you an opportunity to meet up with our staff and discuss how we can better engage with the local technical community. Members may also use this opportunity to voice concerns as well as resolve any issues with resource requests or open tickets. I will be there to talk about RIPE Atlas and other measurements & statistics related topics; my colleagues will be there to answer any other questions. This is a free event, with capacity for around 30 people, so we would appreciate an indication of whether you or any of your colleagues wish to attend (up to two attendees from a single LIR). Please confirm your attendance by filling out the registration form below. All who register will be sent a further information sheet prior to the meeting. You can learn more about the services RIPE NCC provides for our members and the RIPE community at: http://www.ripe.net/lir-services/ncc/list-of-ripe-ncc-services We look forward to meeting you in December! Kind regards, Vesna Manojlovic Community Builder & Fergal Cunningham Membership Communications Officer RIPE NCC Details & registration: ======================= London ====== The lunch will be held on Wednesday, 9 December from 13:00-15:00 (arrival from 12:30) at: De Hems Dutch Cafe Bar Dutch-themed, traditional 19th-century pub serving Dutch and Belgian beers, British menu and snacks. Address: 11 Macclesfield St, London W1D 5BW Register: https://portal.ripe.net/meeting-pub/registration?meetingId=b1400c45-7b87-49… Manchester ========== The lunch will be held on Thursday, 10 December from 13:00-15:00 (arrival from 12:30) at: Address: The Lowry Hotel 50 Dearmans Pl, Chapel Wharf, Manchester M3 5LH, United Kingdom https://www.thelowryhotel.com/restaurants-and-bars/river-bar-and-grill Register: https://portal.ripe.net/meeting-pub/registration?meetingId=2d9ce8d0-46e7-43…

1 0

[Request] System tags for DNS resolution
by Stephane Bortzmeyer 18 Nov '15

18 Nov '15

[Is there a better way to record enhancement requests for Atlas? Atlas has no public issue tracker, if I'm correct?] It would be cool to have system (automatic) tags for DNS resolution because some probes are using broken DNS resolvers. For instance, system-dns-works (modeled on IPv6's system tag) would be fine. Or may be system-dns-resolver-works (longer but more accurate). For instance, probes 16659, 17072, 17620, 17854 use a resolver which yields a REFUSED for any request and probe 19948, 20065 one with systematic SERVFAIL. [Is the maintainer of the probe automatically notified when there is such an issue?]

4 6

Seven new RIPE Atlas anchors have joined the community
by Michela Galante 18 Nov '15

18 Nov '15

Dear RIPE Atlas users, Seven new RIPE Atlas anchors have been activated bringing the total number to 157. - Three anchors hosted by Leaseweb Network: us-mnz-as30633 in Manassas, Virginia, us-sfo-as7203 in San Francisco, California, and sg-sin-as59253 in Singapore. - jp-tyo-as13901, hosted by Afilias in Tokyo, Japan. - de-gaa-as56357, hosted by Technische Universität München in Garching, Germany. - cl-scl-as27678, hosted by NIC Chile in Santiago, Chile and sponsored by LACNIC. - pe-lim-as27843, hosted by Optical Technologies in Lima, Peru. 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

Probe with no firmware
by Anne Inapat 18 Nov '15

18 Nov '15

I registered my probe almost 2 days ago. when I check on the probe on your site, it is indicated no firmware. I am also unable to get an IP through DHCP. Kindly help.

1 0

Any way to select the probes from upstream AS (not origin AS)?
by Stephane Bortzmeyer 16 Nov '15

16 Nov '15

Is there an easy way to select probes, not on the origin AS, but on an AS upstream? Example: probe 23865, IP prefix announced by AS 56339 which currently has only one provider, AS 16080. Currently, Atlas tells me there are no probes in AS 16080...

4 4

Architecture and firmware version filter in probe selection
by Yang Yu 13 Nov '15

13 Nov '15

It would be nice to be able to set architecture and firmware version criteria when selecting probes, making the results more consistent and avoid unnecessary measurements in certain cases. Yang

2 1

Feature request for Traceroute in RIPE Atlas
by Yue LI 13 Nov '15

13 Nov '15

Dear all, So far, the Atlas traceroute is such that if there are 5 consecutive hops with only timeouts (denoted by a star "*"), traceroute will directly try hop 255 and then stop the measurement, which means that the number of total hops can not be obtained. An example can be found: https://atlas.ripe.net/measurements/2841001/#!probes (the probe #22341) Unfortunately, the number of hops is so important to be used as a metric to evaluate the performance of a new protocol. Thus, I propose to add a configuration option for the number of hops after which traceroute decides to call it quits. I wonder whether there are somebody else are also interested in this new feature please? Best regards, Yue -- Yue LI PhD student, Telecom ParisTech Tel: +33 (0)661091840 E-mail: yueli.cnfr(a)gmail.com

1 0

New on RIPE Labs: RIPE Atlas WiFi Measurements
by Robert Kisteleki 13 Nov '15

13 Nov '15

Dear colleagues, We're thinking about implementing WiFi measurements in RIPE Atlas, and we want to know what you think. There are several different ways we could do this - find out more on RIPE Labs and then take our poll to make your voice heard! https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-wifi-measure… Kind regards, Mirjam Kuehne & Robert Kisteleki RIPE NCC

2 1

edst 193.0.0.228 in traceroute results
by Yang Yu 13 Nov '15

13 Nov '15

Hello, In https://atlas.ripe.net/measurements/2928258, I did a UDP traceroute. "edst":"193.0.0.228" from first hop and second hop somehow showed up in the results after the last hop that responded to traceroute, which should have been a reply to buil-in measurement to tt01.ripe.net. And under maps tab the result is presented with the first 2 hops showing up after several non-responding hops. Is this a bug? I actually see it happening quite often in atlas traceroute results with firmware > 4680. Another example is https://atlas.ripe.net/measurements/2928262 >>> https://atlas.ripe.net/docs/bugs/ 2015-03-04 Before firmware 4680, traceroute could experience interference from other measurements. In general, periodic traceroutes did not interfere with other periodic traceroutes, but could experience interference from one-off traceroutes. Typically, this interference will show up in the 'edst' field. This problem was fixed in 4680. Thanks. Yang

1 0

Feature request for IP record route feature in RIPE Atlas
by Pavel Odintsov 11 Nov '15

11 Nov '15

Hello, dear Atlas Team! As host of RIPE Anchor #6111 I have some feedback about your awesome service! Thanks for your Great Job in measuring Internet! I would like to ask very important feature for measuring reverse trace route. I'm speaking about IP record route option which could track up to 9 hops of reverse path. I want to know path to my hosts from networks who haven't RIPE Atlas. Actually I could not implement this feature due to 9 hop restriction in IP header. But RIPE Atlas offer really huge coverage over the World and we could reach really any host with <7 hops. But we haven't this feature in RIPE Atlas. Finally with this feature we could build full adjacently map over all the World. I have checked implementation details here https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source… Looks like we need to build separate libevent based toolkit for this task or add this feature to ping tool. But unfortunately I could not find any docs about deploy of RIPE source code for development. Could you share some information? -- Sincerely yours, Pavel Odintsov

14 34

RIPE Atlas anchor self assembly
by Michela Galante 10 Nov '15

10 Nov '15

Hi everyone, Some people on this list have been asking about the possibility of purchasing hardware for a RIPE Atlas anchor by themselves and assembling it. This is indeed possible. However we do not recommend it because if the assembled hardware is not exactly to our specifications, we will not be able to use it as an anchor. If you still wish to assemble an anchor by yourself, you can find step by step instructions here: https://atlas.ripe.net/docs/anchor-installation/ Please, note that you do need more than the Soekris box. The anchor consists of: • Soekris Net6501-70 board • 1U 19-inch rack-mounted case • Intel SSD 525 or 530 series 240GB mSATA SSD More requirements are listed here: https://atlas.ripe.net/get-involved/become-an-anchor-host/ If you have more questions about anchors, please email to atlas(a)ripe.net and we will be very happy to help you. Best regards, Michela Galante Measurements Community Building RIPE NCC

5 4

Sharing credits with colleagues
by Oliver Haake 10 Nov '15

10 Nov '15

Hey there, I'm very curious if you guys have an ETA for the "Sharing credits with colleagues" feature. Any ideas? Cheers, Oliver

3 4

Read on RIPE Labs about the newest features & the community efforts
by Vesna Manojlovic 05 Nov '15

05 Nov '15

Dear colleagues, There are a number of interesting new features and enhancements for RIPE Atlas users. Learn how you can put them to use: https://labs.ripe.net/Members/kistel/ripe-atlas-update-http-measurements-cl… Regards, Vesna

3 2

ntp built-in measurements?
by Bajpai, Vaibhav 04 Nov '15

04 Nov '15

Dear RIPE Atlas, Do the probes not run (new) NTP measurements as built-in measurements? — I was glancing over the measurement data pushed by my probe, but I do not see any NTP measurement data. Although, when I try to provision a UDM, I do get an option to schedule an NTP measurement. Thanks! Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com =====================================================

3 4

Question about the hardware
by Micha Bailey 30 Oct '15

30 Oct '15

I just got my Probe, and I was wondering what the thought/planning process was when they were designed. Why use a $40 wireless router/access point? I would have thought that cheaper options would be available that provide the requirements (processor and a network port).

3 3

Next week: webinar on "Advanced RIPE Atlas Usage"
by Michela Galante 29 Oct '15

29 Oct '15

Dear colleagues, On Thursday 5 November, 1:30 PM Amsterdam time we are hosting, for the 4th time, 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/WEB20150046 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

'new set wizzard' broken?
by newsboonie 29 Oct '15

29 Oct '15

Hi, It seems the 'new set wizzard' for selecting probes is not working anymore. It does show the map but the input box is missing. Is it just me or is it broken? Thanks, Dave

2 2

Leaseweb Network (US, Manassas and San Francisco) have joined RIPE Atlas anchors
by Michela Galante 28 Oct '15

28 Oct '15

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 Leaseweb Network in United States, are: us-mnz-as30633, in Manassas (Virginia) us-sfo-as7203, in San Francisco (California) Congratulations to Leaseweb Network for their third and fourth 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, RIPE Atlas Team RIPE NCC atlas(a)ripe.net

1 0

GEMNET LLC (Ulaanbaatar, Mongolia) has joined RIPE Atlas Anchors
by Michela Galante 28 Oct '15

28 Oct '15

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

4 3

Probe not appearing in the Atlas
by Ismael Carmona 28 Oct '15

28 Oct '15

Hello, We have the probe #24142, it gets DHCP fine (91.123.100.8) and we can ping it and see with sflow that it perform requests to external servers but we cannot find it online in the atlas. We already tried rebooting it. Any idea how we can make it appear online in the atlas page? Thank you, Ismael

3 2

traceroute - view latest results
by gboonie 27 Oct '15

27 Oct '15

What should the blue 'i' do at the right side of a traceroute measurement? Hovering over it shows a 'view lastest results' message. For example in this measurement: https://atlas.ripe.net/measurements/2845726/#!probes I'm hoping it will soon display all the hops of a traceroute. Just like the traceroutes of the built-in measurements. Just like: Thanks, Dave

4 5

filter ping results by AS
by Sebastian Neuner 26 Oct '15

26 Oct '15

Hi there, I'm currently trying to figure out, how I can get all ping results to(/from) my AS within a certain time frame, to run some statistics. The REST-API documentation [0] states, that measurements can be filtered by dst_asn, but it doesn't seem to influence the results I'm getting: > filter: { > 'start_time__gt': 1445231337, > 'type': 'ping', > 'dst_asn': 553 > } > > dst_asn dst_name > -------------------------------------------- > 2607 sk-bts-as2607.anchors.atlas.ripe.net > 2602 lu-lux-as2602.anchors.atlas.ripe.net > 16154 88.213.204.251 > 1853 at-vie-as1853.anchors.atlas.ripe.net > 8608 195.18.114.5 > 32475 www.siteground.com > 12322 78.194.137.59 > None ch-zrh-as559.anchors.atlas.ripe.net Also, why do some measurements have no dst_asn? Regards, Sebastian [0] https://atlas.ripe.net/docs/rest/

2 7

Private Probes: What's the Point
by Jonathan Brewer 24 Oct '15

24 Oct '15

Hi All, I've run into a few probes marked private, and when I've found & asked the owners, they didn't realise they'd done anything restrictive or harmful to researchers by marking their probes private. Intrigued at this phenomena, I had a look at the probe metadata. Right now I think there are 1,534 Atlas probes that are active and connected to the network, but marked private. What's the point of having private probes in the network? Do their hosts still earn credits they can use on public probes? Should they be? Are private probe hosts helping the project? The FAQ says nothing about private probes, so I thought I would ask here. Thanks, Jon

8 12

Anchors and NTP back to the future
by Stephane Bortzmeyer 23 Oct '15

23 Oct '15

Some anchors appear to be reachable with NTP but most of them are not. I guess it means the anchor always has a NTP server (and I assume it is on purpose) but many networks filter it. What is the good recommanded practice? Specially in the light of the Back to the Future attack <http://www.cs.bu.edu/~goldbe/NTPattack.html>

1 0