- ripe-atlas - mailman.ripe.net

Missing module
by Jacques Lav!gnotte. 26 Aug '15

26 Aug '15

Hello, I am trying to run Stephane's B. resolv-name.py and I get : import RIPEAtlas ImportError: No module named RIPEAtlas I can't figure out where to get this module. Any help ? Jacques -- GnuPg : C8F5B1E3 WeUsePGP Because privacy matters http://weusepgp.info/

3 3

X.509 certificate monitoring
by Stephane Bortzmeyer 25 Aug '15

25 Aug '15

I do not find a lot of examples of X.509 certificate retrieving and analysis? I just committed <https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib/blob/m…> which is useful for me when watching certificate expiration for anycasted sites (where the cert retrieved depends on the probe). Any other examples? And by the way, do not hesitate to submit your scripts to <https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib> (fork and pull request, or open an issue with the attached script).

1 0

Re: [atlas] Question about "location setting" of RIPE Atlas
by Tomáš Hetmer 23 Aug '15

23 Aug '15

Hi, I'd use the simplest logical interpretation and enter the actual physical location no matter if the actual interconnect is right there, 900 km away or transmitted from a satellite. Also, if you placed it to that location 900km away you wouldn't skew the results for your own town, but anyone measuring the latency there would see a +20ms difference from reality, so that doesn't improve anything. Many networks are large and complex, such as an ADSL for a whole country being connected to the net via a local MPLS network via a central point at one main location - should you use that one for all the probes in the country? Of course not, you enter wherever the endpoint is. If you'd like however, you can mention your specific configuration in the probe details. That's my personal view on this, others might differ. Regards Tomáš Hetmer 2015-08-22 23:42 GMT+02:00 Anurag Bhatia <me(a)anuragbhatia.com>: > I have been hosting one of RIPE probes and recently I have switched over my > ISP. > > > Basically my previous ISP provider was regular ISP network with full L3 PoPs > nearby but in my new setup I have got a point to point to a city 900km away > and getting IP transit over there. > > > Now under such case, I am "technically" customer of that network. Should I > still keep my location as I have current one or better update it to that new > location 900km away? > > > The latency of course is low (as it is provisioned on fiber and hence just > 20ms roundtrip) but I think it will confuse off stats if anyone considers to > use this probe for any data in my region. > > > What you all think? Can someone recommend on correct location? > > > > Thanks. > > -- > > > Anurag Bhatia > anuragbhatia.com > > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2

1 0

Afilias, Los Angeles, CA, United States has joined RIPE Atlas anchors
by Eamonn Lane 21 Aug '15

21 Aug '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 us-lax-as63403 and is hosted by Los Angeles, CA, 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, RIPE Atlas Team RIPE NCC atlas(a)ripe.net

1 0

: Afilias, Ashburn, VA 20147, United States has joined RIPE Atlas anchors
by Eamonn Lane 21 Aug '15

21 Aug '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 us-qas-as393246 and is hosted by Afilias, Ashburn, VA 20147, 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, RIPE Atlas Team RIPE NCC atlas(a)ripe.net

1 0

Afilias (US, Ashburn and Los Angeles) have joined RIPE Atlas anchors
by Michela Galante 20 Aug '15

20 Aug '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 Afilias in United States, are: us-qas-as393246, in Ashburn (Virginia) us-lax-as63403, in Los Angeles (California) Congratulations to Afilias for their second and third 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

Case sensitive DNS queries from the probe
by Yang Yu 19 Aug '15

19 Aug '15

Hello, Looking through DNS queries log I saw tons of queries from the probe for case sensitive names. Can someone please enlighten me what the possible use cases are? query: wWw.FacebOOK.COm IN A query: wWW.Wikia.COM IN A query: WwW.wIkIA.cOM IN A query: POOl.NTP.ORg query: Www.wikiA.CoM IN A query: wWW.FacebOoK.COM IN A query: wWw.faCeBOoK.cOM IN A Yang

7 15

Excluding probes by user defined tag not working
by Yang Yu 14 Aug '15

14 Aug '15

Hello, When I use New Set - wizard to select probes, the exclusion by tag does not work with user tags. Even though the user tag was recognized (I chose it from the drop down menu), the particular probe was still selected. For example, I excluded user tag SDFJLKFWEO from measurement 2312281, but probe 10240 was still selected. Thanks. Yang

3 2

Promote the use of IRC
by Daniel Baeza (Red y Sistemas TVT) 14 Aug '15

14 Aug '15

Hi all, Yesterday, I've started a discussion in the member list about promoting the use of IRC instead of Mail List for some kind of discussions, chit chat, etc. Not much members answered, but all who did said yes. The goal is to have, at least, one channel per mail list, but not limited to only that. For this list, an #atlas channel will be created and administrated by the WG Chairs. We want to use the actual RIPE IRC Server plus Network Services and some more irc servers linked to the Ripe one. What do you think? Regards, --Daniel

8 8

one-off UDMs more expensive?
by Paul Vlaar 10 Aug '15

10 Aug '15

As I go through the web interface to setup a UDM I notice the following: For the same DNS measurement, when I specify an interval of 24 hours between samples, the total daily cost comes to 10. When however I specify this to be a one-off sample, the cost then doubles to 20. This doesn't seem to make sense to me. Is there a special reason for one-off measurements to be twice as expensive? ~paul

2 2

selecting probes based on place/city?
by Paul Vlaar 08 Aug '15

08 Aug '15

Hi all, I was wondering if anyone managed to come up with a method of getting a probe selection via the API that is based on city. The web interface allows this, by searching for "place", which is subsequently handled by the Google Maps API (I think), and which then comes back with a number of probes on the map, in that given place. However I need this in the API, which only allows to select probes based on "area, country, prefix, asn". What I'm currently trying to come up with is a way to map, more or less, onto the list of ICANN specified probing locations for their DNS tests. This list is published here: https://tld-monitor.icann.org/nodes.csv I've been trying to go by the ASNs that the listed locations have their IP space in, but that frequently gives me a negative result (no probes present). The same for the prefixes themselves, of course. And just going by the enclosing country code is fine for a small place like Luxembourg, but not for a big country like Canada. So if anyone has any ideas on how to achieve this in a dynamic way (so as not to have to manually build and maintain a list of probes), I'd be very interested in hearing about that. Thank you, Paul Vlaar

4 6

I root server - IPv6
by Daniel Baeza (Red y Sistemas TVT) 07 Aug '15

07 Aug '15

Hello all! Do you guys have problems reaching i.root-servers.net on IPv6? https://stat.ripe.net/m/widget/atlas-ping-measurements#w.mode=condensed&w.m… Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Red y Sistemas Television Costa Blanca S.L. Telf. 966.190.847 | Fax. 965.074.390 http://www.tvt.es | http://www.tvt-datos.es Correo: d.baeza(a)tvt-datos.es -- [Atención] La información contenida en este e-mail es confidencial, privilegiada y está dirigida exclusivamente a su destinatario. Cualquier revisión, difusión, distribución o copiado de este mensaje sin autorización del propietario está prohibido. Si ha recibido este e-mail por error por favor bórrelo y envíe un mensaje al remitente. [Disclaimer] The information contained in this e-mail is privileged and confidential and is intended only for its addressee. Any review, dissemination, distribution or copying of this e-mail is prohibited. If you have received it in error please delete the original message and e-mail us. (!) El medio ambiente es responsabilidad de todos. Imprime este mail si es absolutamente necesario.

3 2

DNS over IPv6
by Brzozowski, John 06 Aug '15

06 Aug '15

Apologies if this is documented some where. Does the RIPE atlas probes explicitly measure/test DNS over IPv6? Also do DNS measurements look at recursion over IPv6 as well? Specifically I am interested in hearing more about how authoritative DNS servers (including root) behave with regards to DNS over IPv6. Thanks, John ========================================= John Jason Brzozowski Comcast Cable p) 484-962-0060 w) www.comcast6.net e) john_brzozowski(a)cable.comcast.com =========================================

2 2

ViewQwest, (Singapore) has joined RIPE Atlas Anchors
by Alastair Strachan 06 Aug '15

06 Aug '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 sg-sin-as18106 and is hosted by ViewQwest in Singapore 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/ <https://atlas.ripe.net/anchors/list/> Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ <https://atlas.ripe.net/about/anchors/> Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas(a)ripe.net <mailto:atlas@ripe.net>

1 0

Re: [atlas] Your RIPE Atlas Probe (ID: 17523) is not connected to our network
by Joachim Tingvold 05 Aug '15

05 Aug '15

On 3 Aug 2015, at 1:40, RIPE Atlas wrote: > We have noticed that your probe (#17523 with description SHL46-jocke) > is not connected to our infrastructure and has been disconnected since > 2015-07-26 23:39 UTC. Hi, Having some issues getting my probe to work in an v6-only environment. Doing only SLAAC (and no v4) made it unable to connect (which makes kinda sense). Made it connect temporarily via v4 so that I could set static v6-address and DNS. Waited a while, then removed v4. I could see it on the ND-table of my router, and it even replied to ping on the static v6 address I assigned it. However, it still showed up as "offline" on the Atlas portal. After some mocking around, it now seems to be in some kind of stale status (the switchport doesn't even learn the MAC address of the probe). Any takers? (-: -- Joachim

2 1

[User Defined Measurements] status settings
by sarah.wassermann＠student.ulg.ac.be 04 Aug '15

04 Aug '15

Hi, In the context of a research internship, I am automatising tools to check whether measurements have finished or not. Could you please tell me what the different status settings are? In the docs, only "scheduled", "ongoing" and "stopped" are indicated, but for 2 of my measurements I came across the status "failed" and "no suitable probes". Thank you very much in advance for your help! Sarah Wassermann

2 1

Strange certificates at probe 17009
by Stephane Bortzmeyer 01 Aug '15

01 Aug '15

Probe #17009, located in Bangkok, when asked to perform a "sslcert" measurement, always retrieve a certificate whose expiration date is 2024-10-31, whatever the target is. There is probably a man-in-the-middle before the probe...

4 3

[UDM] Consistency in the timeout parameter
by Stephane Bortzmeyer 31 Jul '15

31 Jul '15

If I read correctly <https://atlas.ripe.net/docs/measurement-creation-api/>, traceroute and NTP measurements have a "timeout" parameter but not ping or DNS. Why?

2 3

ASN-information on Network tab
by Joachim Tingvold 29 Jul '15

29 Jul '15

Hi, Any reason as to why the ASN numbers isn't displayed on the "Network" tab of a probe that is public? The ASN numbers is available on the probes list, so it would be practical to show it on the "Network" tab as well. -- Joachim

2 3

APIs for accessing DNSMON data
by Brett Carr 29 Jul '15

29 Jul '15

Hello, last year there was a discussion on this list regarding API’s for accessing DNSMON data, I believe the intention was to discuss this at the Warsaw meeting, unfortunately I was not able to attend that meeting so I’m not really sure what the outcome of that discussion was. Nominet use DNSMON on a daily basis and would be very interested in using an API to access the data held in DNSMON. Thanks Brett -- Brett Carr Senior DNS Engineer Nominet UK

3 2

New on RIPE Labs: Extending RIPE atlas' Reach
by Vesna Manojlovic 24 Jul '15

24 Jul '15

Dear colleagues, we are about to start experimenting with new outreach methods, in an effort to increase the growth rate of connected RIPE Atlas probes and achieve better coverage across the globe. Read more in this RIPE labs article: https://labs.ripe.net/Members/becha/extending-ripe-atlas-reach Regards, Vesna Manojlovic Measurements Community Building

2 1

1msec RTT to ipv6.google.com?
by Abreu, Alexandre, Vodafone Portugal 22 Jul '15

22 Jul '15

Hi all Anyone had any issues with wrong RTTs on IPv6 probes? I've setup a ping probe (ID#2143865) to ipv6.google.com and it's consistently giving 1msec RTT on the seismograph and the json file. It is physically impossible. This is the RTT I get on the CPE the probe is connected to: SEQ HOST SIZE TTL TIME STATUS 0 2a00:1450:4003:806::200e 56 59 12ms echo reply 1 2a00:1450:4003:806::200e 56 59 12ms echo reply 2 2a00:1450:4003:806::200e 56 59 12ms echo reply 3 2a00:1450:4003:806::200e 56 59 12ms echo reply 4 2a00:1450:4003:806::200e 56 59 12ms echo reply 5 2a00:1450:4003:806::200e 56 59 12ms echo reply Regards, Alexandre Abreu

5 7

Probe downtime alert for IPv6?
by Jeroen van der Ham 21 Jul '15

21 Jul '15

Hi, The portal offers a notification option for down time. I have a probe that is connected both over IPv4 and IPv6. The latter is through an IPv6 tunnel, which seems a bit flaky at times. I was hoping that the downtime notification would also hold for IPv6, but it turns out it doesn’t. Would it be possible that that be added? Thanks, Jeroen.

2 1

atlas.ripe.net site 302 redirect loop
by Yang Yu 20 Jul '15

20 Jul '15

I have been having this issue with every feature that requires logging in on https://atlas.ripe.net. For instance, when I try to create an API key, HTTP POST to /keys/create/ gets a 302 to https://atlas.ripe.net/login?next=/keys/create/, then the new GET results in another 302 to https://atlas.ripe.net/keys/create/ and back to https://atlas.ripe.net/login?next=/keys/create/ until the browser gives up on redirecting and throws an error. Tested on Chrome/Firefox with Ubuntu trusty and Windows 7. Tried on a different computer from a different continent, still the same issue.

3 2

BDIX (Bangladesh) has joined RIPE Atlas anchors
by Michela Galante 16 Jul '15

16 Jul '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 bd-dac-as24122 and it is hosted by BDIX in Dhaka, Bangladesh, and sponsored by APNIC. 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

1 0

Problem in stopping measuraments
by Elverton Fazzion 14 Jul '15

14 Jul '15

Hello, I've got a issue trying to stop a measurament. I used the RIPE normally last year and I started to use it again two weeks ago. I realized that one experiment was still running since last year and I tried to stop it by using the REST API as described in the documentation. Unfortunately, it did not work. Thus, I tried to stop in the web interface and it did not work either. I do not know how to proceed in order to stop it. The credits got negative even I denied this kind of situation in my profile. Anyone had the same problem? The measurament ID of my experiment is 1791052. Thank you, Elverton.

2 1

unable to delete measurements
by Александр 08 Jul '15

08 Jul '15

Hi devs! I just created a few measurements through web browser and now I can't stop them (red button). In the browser debug I see server response after i click on the button is 403 Forbidden. Measurement ids: 2072826 <https://atlas.ripe.net/measurements/2072826/>, 2072825 <https://atlas.ripe.net/measurements/2072825/>, 2072816 <https://atlas.ripe.net/measurements/2072816/>. -- Best regads, Alexander

2 2

Upcoming change to DNS IN/TXT query result
by Philip Homburg 07 Jul '15

07 Jul '15

Hi, This is to inform you about a change in a future release of the RIPE Atlas firmware that changes how 'IN TXT' records get decoded in DNS measurements. Currently, the JSON generated by the probe for TXT query looks like this: { "fw" : -1 , "time" : 1436282373 , "lts" : -1 , "name" : "stereo.hq.phicoh.net" , "dst_addr" : "130.37.15.35" , "af" : 4 , "src_addr" : "193.0.10.226" , "proto" : "UDP" ,"result" : { "rt" : 12.172,"size" : 219 , "ID" : 45298 , "ANCOUNT" : 1 , "QDCOUNT" : 1 , "NSCOUNT" : 2 , "ARCOUNT" : 2,"abuf" : "sPKEAAABAAEAAgACB2RyYWdvbnMEYWlveQJldQAAEAABB2RyYWdvbnMEYWlveQJldQAAEAABAAAOEABPJUhlcmUgYmUg/yBkcmFnb25zISBXaXRoIFwgYW5kICIgYW5kIH8IYXMgd2VsbC4fVGhyb3dpbmcgaW4ggCBmb3IgZ29vZCBtZWFzdXJlLsApAAIAAQAADhAABgNuczHAKcApAAIAAQAADhAABgNuczLAKcCXAAEAAQAADhAABIIlDyPAqQAcAAEAAA4QABAgAQRw0WoAEAKgyf/+nxep","answers" : [ {"TYPE" : "TXT" , "NAME" : "dragons.aioy.eu" , "RDATA" : "Here be \u00FF dragons! With \\ and \" and \u0008as well.\u001FThrowing in \u0080 for good measure."} ] } } Note that the '\u' escape sequence is used escape characters outside the safe ASCII range and that the code fails to support more than one string (the actual reply contains 3 strings). The '\u' notation seemed like a good idea at the time, but because it is valid JSON it is not always transparent and it triggered bugs in other software. The plan is to move to the following format: { "fw" : -1 , "time" : 1436282575 , "lts" : -1 , "name" : "stereo.hq.phicoh.net" , "dst_addr" : "130.37.15.35" , "af" : 4 , "src_addr" : "193.0.10.226" , "proto" : "UDP" ,"result" : { "rt" : 13.186,"size" : 219 , "ID" : 45298 , "ANCOUNT" : 1 , "QDCOUNT" : 1 , "NSCOUNT" : 2 , "ARCOUNT" : 2,"abuf" : "sPKEAAABAAEAAgACB2RyYWdvbnMEYWlveQJldQAAEAABB2RyYWdvbnMEYWlveQJldQAAEAABAAAOEABPJUhlcmUgYmUg/yBkcmFnb25zISBXaXRoIFwgYW5kICIgYW5kIH8IYXMgd2VsbC4fVGhyb3dpbmcgaW4ggCBmb3IgZ29vZCBtZWFzdXJlLsApAAIAAQAADhAABgNuczHAKcApAAIAAQAADhAABgNuczLAKcCXAAEAAQAADhAABIIlDyPAqQAcAAEAAA4QABAgAQRw0WoAEAKgyf/+nxep","answers" : [ {"TYPE" : "TXT" , "NAME" : "dragons.aioy.eu" , "RDATA" : [ "Here be \\255 dragons! With \\092 and \\034 and \\127", "as well.", "Throwing in \\128 for good measure." ] } ] } } Here the escape sequence is similar to the one in DNS zone files. Except that the backslash has to be doubled in JSON. Furthermore, after RDATA comes a list of strings instead of a single string directly. For anyone who parses the JSON output directly, the change from a single string to a list of strings is probably the biggest change. Similar changes will be made in the Sagan package. There, python tricks may hide the list if the result is used in a string context. Philip

1 0

Get the list of all probes?
by Stephane Bortzmeyer 07 Jul '15

07 Jul '15

For a project (testing the randomness of probe selection), I need a list of all probes. The only solution I find is a loop over <https://atlas.ripe.net/api/v1/probe/?limit=100&offset=N> Is there a simpler way? <https://atlas.ripe.net/docs/api/#public-probes-list> seems to say there is a JSON file with all probes but it yields a 404 (reported to the RIPE-NCC, ticket [ripe.net #1179513])

2 3

LLDP / LLDP-MED support?
by Pekka Järvinen 07 Jul '15

07 Jul '15

Hi, Would there be any idea to add LLDP support to probes? -- Pekka Järvinen

3 2

Fwd: Your RIPE Atlas Probe (ID: 22769) is not connected to our network
by Jonathan Brewer 07 Jul '15

07 Jul '15

Hi There, My probe 22769 appears to be malfunctioning, and I'm not sure what to do in terms of diagnostics. >From the router nearest it on the network: https://www.dropbox.com/s/ghe4e3tz69u1kvc/Screenshot%202015-07-07%2011.30.1… Looks to me as if it's rebooting frequently, but I have no way to check without an in-person visit. Do you have any suggestions as to how to troubleshoot? I have access to the network it's on. Thanks, Jon ---------- Forwarded message ---------- From: RIPE Atlas <no-reply(a)ripe.net> Date: 6 July 2015 at 07:40 Subject: Your RIPE Atlas Probe (ID: 22769) is not connected to our network To: jon.brewer(a)gmail.com Dear RIPE Atlas probe host, Thank you for participating in RIPE Atlas! We have noticed that your probe (#22769 with description MDC) is not connected to our infrastructure and has been disconnected since 2015-06-28 22:42 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

API to get information about a probe?
by Stephane Bortzmeyer 06 Jul '15

06 Jul '15

I cannot find an API to retrieve information about a probe. I would like to get the information I can see on, for instance, <https://atlas.ripe.net/probes/10644/> but from a REST + JSON API. Does it exist? Do you think it would be a nice addition? (My current use case is that I find some probes failing to ping a target and I would like to quickly check if they share something, such as ASn or some tags.)

2 3

Wrong IP prefix values accepted?
by Stephane Bortzmeyer 05 Jul '15

05 Jul '15

It seems there is no protection against wrong prefixes? See measurement #1897909, which started with JSON: {'definitions': [{'query_class': 'IN', 'description': 'DNS resolution of jihadmin.com from prefix foobar', 'af': 4, 'query_argument': 'jihadmin.com', 'query_type': 'A', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': True, 'use_probe_resolver': True}], 'probes': [{'requested': 3, 'type': 'prefix', 'value': 'foobar'}]}

2 5

Fwd: [mat-wg] New on RIPE Labs: Improving RIPE Atlas Coverage. What Networks are Missing?
by Robert Kisteleki 02 Jul '15

02 Jul '15

Dear all, The following article might be of interest to you. Regards, Robert -------- Forwarded Message -------- Subject: [mat-wg] New on RIPE Labs: Improving RIPE Atlas Coverage. What Networks are Missing? Date: Thu, 02 Jul 2015 12:18:55 +0200 From: Mirjam Kuehne <mir(a)ripe.net> To: mat-wg(a)ripe.net Dear colleagues, In this article we compare RIPE Atlas deployment against user population estimates provided by APNIC to see what eyeball networks are missing out on RIPE Atlas probes: https://labs.ripe.net/Members/emileaben/improving-ripe-atlas-coverage-what-… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Probe and measurement archives vs. the APIs
by Robert Kisteleki 02 Jul '15

02 Jul '15

Dear All, We've observed recently that some users are using scripts to "crawl" through all the metadata provided by the probe and measurement APIs. This means that some people out there download basically the entire probe and/or measurement meta data set the system provides. As you can imagine, this is highly inefficient and keeps our servers busy. We believe that there could be better solutions. We have been providing the downloadable archive for probe metadata for some time now, and recently we've added the measurement metadata too. You can now reach these at http://ftp.ripe.net/ripe/atlas/ This way one can even get complete sets of metadata as far back as January 2015 for measurement specifications and March 2014 for probe data. Given the existence of these archives, we will apply a sane limit on how much metadata can be reached via the APIs. In practice this means that the API will not allow fetching results beyond, say, 10.000 (i.e. 500 pages of 20) entries. This is after the application of filters, so for example with no filters at all you could still access metadata of the 10k newest measurements, while if you filter for DNS measurements only, you could get the 10k newest of those, and so on. We believe this keeps the metadata API useful for the majority of the users, while the existence of the archive serves the remaining cases. Our plan is to make this change around the end of July. Regards, Robert Kisteleki

1 0

RIPE Atlas traceroute visualisation - use cases
by Massimo Candela 01 Jul '15

01 Jul '15

Hello, We are creating a tool to visualise traceroute results coming from the RIPE Atlas measurement network. The tool will of course be available to everyone. To help make this tool as useful as possible, I’m gathering use cases of day-to-day operations and research activities that use traceroute measurements. I hope you can spend a few minutes to answer this email and tell me how you use traceroute measurements or what you would like to have in such a tool. For each use case you have in mind, please describe it briefly. Keep in mind our system can collect measurements from multiple sources to a single target repeatedly (e.g. every 60 seconds). Don’t focus only on traceroute data, but also on correlations among traceroutes and BGP, RTT, geolocations, DNS, and registry information (feel free to expand the list to other datasets). Thanks for your time. Your help is invaluable. Ciao, Massimo RIPE NCC

2 1

DHIRAAGU (Maldives) has joined RIPE Atlas anchors
by Michela Galante 30 Jun '15

30 Jun '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 mv-mle-as7642 and it is hosted by DHIRAAGU in Male, Maldives, and sponsored by APNIC. 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

1 0

Re: [atlas] vm image for ripe atlas probe ?
by Colin Johnston 30 Jun '15

30 Jun '15

low vm disk use is priority low vm memory is priority colin Sent from my iPhone > On 30 Jun 2015, at 11:15, RIPE Atlas <atlas(a)ripe.net> wrote: > >> On 2015-06-22 15:03, Colin Johnston wrote: >> any news on vm image for ripe atlas probe ? >> would be great to use as could monitor vm farms much better ? >> >> Colin. > > Dear all, > > We understand that some people asked for this feature. At the moment we're > evaluating it, and plan to come back to the community with a plan of action > before the end of August. It's possible that we'll post a couple of > clarification questions in the meantime. > > Regards, > Robert

1 0

vm image for ripe atlas probe ?
by Colin Johnston 30 Jun '15

30 Jun '15

any news on vm image for ripe atlas probe ? would be great to use as could monitor vm farms much better ? Colin.

5 4

Active probes
by Ben O'Hara 25 Jun '15

25 Jun '15

Hi, We currently pull https://atlas.ripe.net/contrib/active_probes.json as part of some analysis of atlas data, this seems to have gone missing since yesterday and now returns a 404. Is this known? Should it work? Will it come back? Cheers Ben BEN O'HARA Senior Network and Systems Engineer P +61 9866 3710 [Bombora Technologies Logo]<http://www.bomboratech.com.au/> www.bomboratech.com.au<http://www.bomboratech.com.au/> Follow us on Twitter<https://twitter.com/BomboraTech> The Bombora Technologies group of companies includes AusRegistry, ARI Registry Services, AusRegistry International and ZOAK Solutions. The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately.

2 2

Probe update
by Laurent Dumont 23 Jun '15

23 Jun '15

Hi gents, Small update on the probe status. I've tried a 2A usb power adapter and no dice. The Power and WPS led come on and a ethernet link seems to be active between the probe and the switch. Unfortunately, there is no DHCP discover or any kind of network activity from the probe. Anything else I can try to troubleshoot this? Is there a LED guide somewhere? -- Laurent Dumont coldnorthadmin.com

2 1

Probe question - Issue
by Laurent Dumont 23 Jun '15

23 Jun '15

Hi gents, After some delay, I'm trying to setup the probe I received. Unfortunately, it seems that something is not quite working. Once it's plugged in and powered, there is no activity. There is no DHCP request for the probe so I can't see anything on the network side. Could something be wrong with the usb key? Is there a way I could reflash the usb key with the OS files? Thanks Laurent Dumont -- Laurent Dumont coldnorthadmin.com

3 4

Netzwerge Hamburg eK, Hamburg, Germany has joined RIPE Atlas anchors
by Eamonn Lane 23 Jun '15

23 Jun '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 de-ham-as201709 and is hosted by Netzwerge Hamburg eK, Hamburg, Germany. 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 RIPE NCC atlas(a)ripe.net

1 0

FHE3 Gmbh, Frankfurt Am Main, Germany has joined RIPE Atlas anchors
by Eamonn Lane 23 Jun '15

23 Jun '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 de-fra-as49024 and is hosted by FHE3 Gmbh, Frankfurt Am Main, Germany. 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 RIPE NCC atlas(a)ripe.net

1 0

Enabling Data Compression in RIPE Atlas
by Vesna Manojlovic 19 Jun '15

19 Jun '15

Dear colleagues, We’d like to enable gzip compression on all of RIPE Atlas' measurement API calls — but thanks to the BREACH vulnerability, doing so could mean that some enterprising individual with an obscene amount of time on their hands might be able read the contents of the responses. This means measurement results as well as metadata for measurements — including the small number of measurements not marked as “public”. We believe the drawbacks are negligible, but we’re looking for community support. Find out more in this RIPE Labs article: https://labs.ripe.net/Members/daniel_quinn_39/enabling-data-compression-in-… Regards, Vesna Manojlovic

1 0

atlas anchor DANE records
by Bjørn Mork 17 Jun '15

17 Jun '15

Hello, I just noticed "We also generate a DANE record for each anchor" in the docs and became instantly curious. There aren't that many DANE records out there in the wild :) The records seem to be pointing to a self signed certificate (as documented), but with 'usage' = 1 instead of 3 as expected. At least the two records I looked at had this - I assume they are all created the same way. Is this intentional? It makes 'normal' verification fail: bjorn@canardo:~$ tlsa --debug --verify nl-ams-as3333.anchors.atlas.ripe.net Received the following record for name _443._tcp.nl-ams-as3333.anchors.atlas.ripe.net.: Usage: 1 (End-Entity Constraint + chain to CA) Selector: 0 (Certificate) Matching Type: 1 (SHA-256) Certificate for Association: 88422d55424ca8f6f74e165016851cb195fc0919f82f8762574a4d71868964e9 This record is valid (well-formed). Attempting to verify the record with the TLS service... Got the following IP: 193.0.19.107 FAIL (Usage 1): Certificate offered by the server matches the one mentioned in the TLSA record but the following error was raised during PKIX validation: X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT The matched certificate has Subject: /C=nl/ST=ams/L=ams/O=as3333/CN=nl-ams-as3333.anchors.atlas.ripe.net Got the following IP: 2001:67c:2e8:11::c100:136b FAIL (Usage 1): Certificate offered by the server matches the one mentioned in the TLSA record but the following error was raised during PKIX validation: X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT The matched certificate has Subject: /C=nl/ST=ams/L=ams/O=as3333/CN=nl-ams-as3333.anchors.atlas.ripe.net bjorn@canardo:~$ tlsa --debug --verify se-sto-as8674.anchors.atlas.ripe.net Received the following record for name _443._tcp.se-sto-as8674.anchors.atlas.ripe.net.: Usage: 1 (End-Entity Constraint + chain to CA) Selector: 0 (Certificate) Matching Type: 1 (SHA-256) Certificate for Association: 2d92e341d2181011c520ad92229155e1350fc4f7b9e628198be1f9589ec7a53f This record is valid (well-formed). Attempting to verify the record with the TLS service... Got the following IP: 185.42.136.158 FAIL (Usage 1): Certificate offered by the server matches the one mentioned in the TLSA record but the following error was raised during PKIX validation: X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT The matched certificate has Subject: /O=AS8674/L=STO/C=SE/CN=se-sto-as8674.anchors.atlas.ripe.net Got the following IP: 2a01:3f0:0:60::5 FAIL (Usage 1): Certificate offered by the server matches the one mentioned in the TLSA record but the following error was raised during PKIX validation: X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT The matched certificate has Subject: /O=AS8674/L=STO/C=SE/CN=se-sto-as8674.anchors.atlas.ripe.net What is the intended use of these records? And why doesn't https://atlas.ripe.net/ have a DANE record as well? :) Bjørn

1 0

HTTP Measurements with RIPE Atlas
by Vesna Manojlovic 17 Jun '15

17 Jun '15

Dear colleagues, After a discussion with the community about HTTP measurements, RIPE NCC will start implementing this as a publicly available measurement type. Please find some more information on RIPE Labs: https://labs.ripe.net/Members/kistel/http-measurements-with-ripe-atlas Kind regards, Vesna Manojlovic RIPE NCC

3 2

Atlas Anchors and LogJam
by Ben O'Hara 15 Jun '15

15 Jun '15

Hi, We host an Atlas Anchor, but our network monitoring still shows it being vulnerable to Logjam. Can you please let us know when this will be upgraded to fix the vulnerability? Cheers BEN O'HARA Senior Network and Systems Engineer P +61 9866 3710 [Bombora Technologies Logo]<http://www.bomboratech.com.au/> www.bomboratech.com.au<http://www.bomboratech.com.au/> Follow us on Twitter<https://twitter.com/BomboraTech> The Bombora Technologies group of companies includes AusRegistry, ARI Registry Services, AusRegistry International and ZOAK Solutions. The information contained in this communication is intended for the named recipients only. It is subject to copyright and may contain legally privileged and confidential information and if you are not an intended recipient you must not use, copy, distribute or take any action in reliance on it. If you have received this communication in error, please delete all copies from your system and notify us immediately.

2 1

Notifications for unreachable probes
by Peter Eckel 10 Jun '15

10 Jun '15

Hi, I have set up a notification if my probe 10293 is down for more than 15 minutes. Since my main mail address is located on a server likely to be unavailable if the probe is down, the notification was set to a different mail address not in the same network. Unfortunately it seems that the notification address is ignored, and the notification is sent to the reporting address instead. Does anyone else see that problem as well? Regards, Peter.

2 1

ADP, Saint-Denis, France has joined RIPE Atlas anchors
by Eamonn Lane 08 Jun '15

08 Jun '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 fr-ysd-as201958 and is hosted by : ADP, Saint-Denis, in France. 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 RIPE NCC atlas(a)ripe.net

1 0