- ripe-atlas - mailman.ripe.net

DNS issue with Atlas or with the ISP?
by Stephane Bortzmeyer 09 Sep '19

09 Sep '19

RIPE Atlas Web site displays a lot of "undefined" for the tests in AS 3125. See for instance <https://atlas.ripe.net/measurements/22766270/#!probes> or <https://atlas.ripe.net/measurements/22766942/#!probes> But the DNS resolution from this AS seems to work. Checking the raw results in JSON, I see that we have a lot of failures on one IPv6 resolver: "dst_name": "fe80::a63e:51ff:fe77:e26", "error": { "socket": "connect failed Invalid argument" }, We do not see such IPv6 problem in other AS (see for instance <https://atlas.ripe.net/measurements/22766995#!probes>) I assume that the "connect failed Invalid argument" is the fault of the ISP, which advertises a wrong DNS resolver? Or is the Atlas probe unable to query link-local addresses for DNS resolution? Even if it is so, is it a good idea for the Atlas Web site to display "undefined" where the raw results show that other resolvers worked?

3 5

SSL Certificates for ripe anchors
by Jóhann B. Guðmundsson 04 Sep '19

04 Sep '19

Hi Has there been any dialog about moving the anchors away from using self signed certificates to Let's Encrypt? Regards Jóhann B.

14 32

Apply for next RIPE NCC hackathons, in six locations!
by Vesna Manojlovic 04 Sep '19

04 Sep '19

Dear colleagues, as our tenth event, we are hosting our first IoT-themed hackathon (Internet of Things) on the weekend of 12-13 October in Rotterdam: https://labs.ripe.net/Members/becha/iot-hackathon-at-ripe-79-in-rotterdam This is planned for the weekend just before RIPE 79: http://ripe79.ripe.net You can apply at: https://www.ripe.net/participate/forms/apply/iot-hackathon-rotterdam-2019/ The application deadline is *9 September 2019*. Shortly after that, for the first time ever, we are holding the hackathon simultaneously in five connected 'nodes' across Europe: Delft, Dublin, Padua, Paris and Sarajevo! Topic is Quantum Internet, and dates 5 & 6 November. The first application deadline is *15 September 2019*. This will probably be extended due to the summer & academic holidays. You can find more information about the event on RIPE Labs: https://labs.ripe.net/Members/ulka_athale_1/take-part-in-pan-european-quant… You can apply at: https://www.ripe.net/participate/forms/apply/peqi/ Warm regards, Vesna Manojlovic Community Builder RIPE NCC

1 0

Measurement with msm probe type isn't working
by Hugo Salgado 02 Sep '19

02 Sep '19

Dear Atlas team. I have a script to launch a new measurement using an old measurement list of probes ids, using type:msm. This script worked ok several times (last time like 1 month ago), but now it gives me the error: {"error":{"detail":"There was a problem with your request","status":400,"title":"Bad Request","code":102,"errors":[{"source":{"pointer":"/probes/0/value"},"detail":"The measurement you selected for your probe request does not exist"}]}} However I still can see the old measurement on the web page! I solved it downloading the list of probes using a GET to https://atlas.ripe.net/api/v2/measurements//<OLD_MEASUREMENT_ID>?fields=probes' and then giving the complete probes list to my script. Is there any recent change with the type:msm call? Thanks, Hugo

2 2

"Anchor Details" on the probe pages
by Alexey Troshchanovich 30 Aug '19

30 Aug '19

Hello team, Is it normal that the probe pages contain an empty "Anchor Details" section? <section id="anchor-measurements" class="anchor_measurements"> > <h4 class="wide">Anchor Details</h4> > ... > </section> > Thank you. Alexey

2 1

Network name missing at http://sg-pub.ripe.net/petros/population_coverage/country.html?name=CZ
by ripe＠brite.cz 01 Aug '19

01 Aug '19

Hi team, RIPE Atlas Population Coverage tool ( http://sg-pub.ripe.net/petros/population_coverage/country.html?name=CZ ) is missing Network Names (column "Network Name") in more than half rows. It seems it is the same for multiple/all countries. Please have a look. Thank you Jiri

2 1

Feature Request to consider: DNS response IP header
by Jen Linkova 22 Jul '19

22 Jul '19

Hello, I have a number of use cases when it would be very useful to have access to the IP header of the measurement response packets. In my scenario I'd like to see TTL/Hop Limit of packets received in DNS measurements. So I'm curious if anyone else think it would be a useful feature and if there is some demand for such a feature - maybe the Atlas team could consider implementing it? Thanks! -- SY, Jen Linkova aka Furry

4 4

Question about built-in first/second hop latency measurements
by Joel Sommers 22 Jul '19

22 Jul '19

Hello all, For the built-in latency measurements to first/second hops, my assumption has pretty much always been that these are done with hop-limited probes (i.e., with TTL or hop limit set to 1 or 2). Is that true, or are these measurements taken using “direct” pings? Thanks! Joel

2 1

Scheduled work on RIPE Atlas
by Robert Kisteleki 18 Jul '19

18 Jul '19

Dear RIPE Atlas users, We have planned maintenance on the main RIPE Atlas backend database tomorrow (Tuesday, 16 July) starting at 08:00 UTC, 10:00 Amsterdam local time. We expect complete unavailability of the service for a short while and further intermittent delays during the day. During this time the website (UI and APIs) will not be responding (properly). This also means that requests for new measurements will be denied or delayed. Data from existing measurements will still be collected normally, though access to them will be impacted. Our apologies for the inconvenience. Regards, Robert Kisteleki

3 4

Re: [atlas] how to earn credits com236.294.813
by kiran.gunana＠colruytgroup.com 11 Jul '19

11 Jul '19

Hello Johan, My probe ID is 32256, It is registered and reachable from last 3 weeks, can you please check if I still need to do something to earn my credits. rg, kiran. ----- Original Message: com236.291.250 --------------------------------- From: Johan ter Beest (jterbeest(a)ripe.net) To: kiran.gunana(a)colruytgroup.com Copy: ripe-atlas(a)ripe.net Subject: Re: [atlas] how to earn credits com236.259.148 Date: 11 July 2019 (12:07) Hi Kiran, You earn credits for the uptime of a probe and the delivered results for measurements that other hosts run towards your probe. Everything is explained here: https://atlas.ripe.net/docs/credits/ If your probe is not earning you any credits then there are two possible reasons: - your probe is not connected - you have not registered your probe so we don’t know who to give the credits to. I don’t know your probe ID so I. Cannot check but it’s most likely that it’s not registered. You can do that here: https://atlas.ripe.net/register/ If you send me a private email with your probe ID, I will give you the credits you should have earned in the last three weeks. Kind regards, Johan ter Beest RIPE Atlas. Team On 11 Jul 2019, at 09:10, kiran.gunana(a)colruytgroup.com wrote: Hello Michael, Thanks alot for the good gesture, me too got some good number of credits for now however just wondering after 3 months I will loose them all if I keep doing the same measurments. So looking for a way to earn some credits. rg, kiran ----- Original Message: com236.253.880 --------------------------------- From: Michael J. Oghia (mike.oghia(a)gmail.com) To: kiran.gunana(a)colruytgroup.com Copy: ripe-atlas(a)ripe.net Subject: Re: [atlas] how to earn credits com236.252.126 Date: 11 July 2019 (08:34) Can we just transfer you some credits? Most of us have a massive surplus. Let us know your preferred email address. Best, -Michael On Thu, Jul 11, 2019, 8:16 AM <kiran.gunana(a)colruytgroup.com> wrote: Hello, I am running my probe since 3 weeks and I spent almost 1milion credits for measuring some metrics, however I am not able to earn any credits. Can some give me the steps to enable me earning some credits as well. rg, kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

1 0

Re: [atlas] how to earn credits com236.259.148
by kiran.gunana＠colruytgroup.com 11 Jul '19

11 Jul '19

Hello Michael, Thanks alot for the good gesture, me too got some good number of credits for now however just wondering after 3 months I will loose them all if I keep doing the same measurments. So looking for a way to earn some credits. rg, kiran ----- Original Message: com236.253.880 --------------------------------- From: Michael J. Oghia (mike.oghia(a)gmail.com) To: kiran.gunana(a)colruytgroup.com Copy: ripe-atlas(a)ripe.net Subject: Re: [atlas] how to earn credits com236.252.126 Date: 11 July 2019 (08:34) Can we just transfer you some credits? Most of us have a massive surplus. Let us know your preferred email address. Best, -Michael On Thu, Jul 11, 2019, 8:16 AM <kiran.gunana(a)colruytgroup.com> wrote: Hello, I am running my probe since 3 weeks and I spent almost 1milion credits for measuring some metrics, however I am not able to earn any credits. Can some give me the steps to enable me earning some credits as well. rg, kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

3 2

how to earn credits com236.252.126
by kiran.gunana＠colruytgroup.com 11 Jul '19

11 Jul '19

Hello, I am running my probe since 3 weeks and I spent almost 1milion credits for measuring some metrics, however I am not able to earn any credits. Can some give me the steps to enable me earning some credits as well. rg, kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

2 1

Re: [atlas] DNS RTT over TCP: twice as long than UDP?
by Ponikierski, Grzegorz 11 Jul '19

11 Jul '19

Just to confirm I verified what exactly dig measures. For example, this dig takes 8ms (which is always rounded): [gponikie@krk-mptoy atlas_day68_step1]$ dig +tcp example.com @1.1.1.1 ; <<>> DiG 9.14.3 <<>> +tcp example.com @1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14416 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1452 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 5212 IN A 93.184.216.34 ;; Query time: 8 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Tue Jul 09 13:17:55 CEST 2019 ;; MSG SIZE rcvd: 56 If you check it with wireshark it looks like this: No. Time Source Destination Protocol Length Window size value Shift count Info 1 13:17:55.014898 192.168.1.83 1.1.1.1 TCP 78 65535 6 53593 → 53 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=676915370 TSecr=0 SACK_PERM=1 2 13:17:55.029784 1.1.1.1 192.168.1.83 TCP 74 29200 10 53 → 53593 [SYN, ACK] Seq=0 Ack=1 Win=29200 Len=0 MSS=1412 SACK_PERM=1 WS=1024 3 13:17:55.029883 192.168.1.83 1.1.1.1 TCP 54 4096 53593 → 53 [ACK] Seq=1 Ack=1 Win=262144 Len=0 4 13:17:55.030041 192.168.1.83 1.1.1.1 DNS 108 4096 Standard query 0x3850 A example.com OPT 5 13:17:55.038351 1.1.1.1 192.168.1.83 TCP 68 29 53 → 53593 [ACK] Seq=1 Ack=55 Win=29696 Len=0 6 13:17:55.038572 1.1.1.1 192.168.1.83 DNS 120 29 Standard query response 0x3850 A example.com A 93.184.216.34 OPT 7 13:17:55.038624 192.168.1.83 1.1.1.1 TCP 54 4095 53593 → 53 [ACK] Seq=55 Ack=59 Win=262080 Len=0 8 13:17:55.039580 192.168.1.83 1.1.1.1 TCP 54 4096 53593 → 53 [FIN, ACK] Seq=55 Ack=59 Win=262144 Len=0 9 13:17:55.047201 1.1.1.1 192.168.1.83 TCP 68 29 53 → 53593 [FIN, ACK] Seq=59 Ack=56 Win=29696 Len=0 10 13:17:55.047273 192.168.1.83 1.1.1.1 TCP 54 4096 53593 → 53 [ACK] Seq=56 Ack=60 Win=262144 Len=0 From this traffic looks like dig measures time between packets 4 (DNS query) and 6 (DNS response) which is precisely 8.5ms and matches what dig shows. Including TCP handshake it takes 23.7ms, 2.8x longer which is expected . RTT can be measured on different layers for the same communication stream. In case of DNS over UDP we just ignores UDP overhead because it doesn't add any packets. With TCP additional packets are added which significantly increase time that end-user have to wait from first packet to get information that he/she needs. IMO RTT should always be measured from 1st packet to packet which has information that you have actual data. If we want to measure raw DNS performance without overhead then it must be explicitly market it measurement description. Regards, Grzegorz From: Giovane Moura <giovane.moura(a)sidn.nl> Date: Friday 2019-07-05 at 14:34 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] DNS RTT over TCP: twice as long than UDP? Folks, This page at Atlas provides a great visualization on the RTT of DNS queries over TCP/UDP to the Root DNS servers: https://atlas.ripe.net/results/maps/root-server-performance/ We can see that the RTT of TCP queries is at least twice as long than UDP ones (which, according to the page " TCP is expected to be 2-3 times " longer. I cannot replicate these results in my setup, even in large scale from various vantage points: I always get very similar results for either TCP or UDP. Example: UDP: * $ dig example.nl @ns1.dns.nl Query time: 8 msec TCP: * $dig +tcp example.nl @ns1.dns.nl Query time: 9 msec I think there might be something with the definition of RTT. My hypothesis is that the field *rtt* on DNS queries on Atlas[1], for TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP handshake, and the RTT of query/response itself. By definition, however, RTT is "the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgement of that signal to be received."[2]. So if DNS TCP measurements starts measuring from the SYN packet, that', in fact, be two RTTs. Is this the case with Atlas? I know it may sound a bit like nitpicking, but I just want to be sure of what's exactly being measured. thanks a lot, /giovane [1] https://atlas.ripe.net/docs/data_struct/#v4750_dns [2] https://en.wikipedia.org/wiki/Round-trip_delay_time

2 2

New on RIPE Labs: Internet Tools BoF Discovers Common Challenges for Network Operators
by Michela Galante 09 Jul '19

09 Jul '19

Dear colleagues, Here is a great summary provided by Sofia Silva Berenguer (APNIC) of the outcomes of the Internet Tools BoF organised at the recent LACNIC 31 meeting: https://labs.ripe.net/Members/sofia_silva_berenguer/internet-tools-bof-disc… Kind regards, Michela Galante RIPE NCC

1 0

DNS RTT over TCP: twice as long than UDP?
by Giovane Moura 05 Jul '19

05 Jul '19

Folks, This page at Atlas provides a great visualization on the RTT of DNS queries over TCP/UDP to the Root DNS servers: https://atlas.ripe.net/results/maps/root-server-performance/ We can see that the RTT of TCP queries is at least twice as long than UDP ones (which, according to the page " TCP is expected to be 2-3 times " longer. I cannot replicate these results in my setup, even in large scale from various vantage points: I always get very similar results for either TCP or UDP. Example: UDP: * $ dig example.nl @ns1.dns.nl Query time: 8 msec TCP: * $dig +tcp example.nl @ns1.dns.nl Query time: 9 msec I think there might be something with the definition of RTT. My hypothesis is that the field *rtt* on DNS queries on Atlas[1], for TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP handshake, and the RTT of query/response itself. By definition, however, RTT is "the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgement of that signal to be received."[2]. So if DNS TCP measurements starts measuring from the SYN packet, that', in fact, be two RTTs. Is this the case with Atlas? I know it may sound a bit like nitpicking, but I just want to be sure of what's exactly being measured. thanks a lot, /giovane [1] https://atlas.ripe.net/docs/data_struct/#v4750_dns [2] https://en.wikipedia.org/wiki/Round-trip_delay_time

3 2

Atlas problems this morning?
by Stephane Bortzmeyer 01 Jul '19

01 Jul '19

#22170557, #22171022 and #22171068 terminate but no results are available. Is there some problem going on?

2 1

Search for Probe
by Sascha Groetzner 01 Jul '19

01 Jul '19

Hello, I would like to take part at the ripe atlas grip. I applied already for a probe and still waiting for delivery since a long time. Does anyone have a probe which isn`t in use or would like to transfer? best regards Sascha Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 1

Streaming API Losses
by Marcel Flores 28 Jun '19

28 Jun '19

Hi all, We've been exploring the use of the Streaming API to collect result stream data for a set of user defined measurements, in particular using the interface available in Cousteau. However, we've found that the Streaming API seems to be "lossy", with only a fraction of the results reported through the usual system making their way into the stream. I've not been able to find any sort of pattern on what does and doesn't make it through. Does anyone else have experience with this? Are there known limitations with the Streaming API? If so, has anyone worked out any clever workflows to accommodate? Thanks very much! -- *Marcel Flores, PhD* | Sr. Research Scientist research.verizondigitalmedia.com | AS15133 <https://www.peeringdb.com/asn/15133> p: +1 310.593.6880 e: marcel.flores(a)verizondigitalmedia.com 13031 W Jefferson Blvd. Building 900, Los Angeles, CA 90094

1 0

Filter for all results of a probe within a given timeintervall
by Lars Prehn 28 Jun '19

28 Jun '19

Hi everyone, I'm currently trying to retrieve ping and/or traceroute results for a specific probe in a given time interval via cousteau and/or the measurement API directly. It seems like I'm not clever enough to get it done. Is there a possibility to achieve this goal without iterating over each and every measurement to check whether or not the probes and the time match? Best regards, Lars

1 0

raspbian.net/raspbian.org ipv6 peering problems
by Thomas Schäfer 25 Jun '19

25 Jun '19

Hello, I am not sure if I am right here with my question. Does someone measurements to the server of "raspbian"? Their hoster (bytemark, iomart, zayo?) seems not to be able to establish correct peerings. At least the peering to AS3320 is broken. I already contacted 3320. They say zayo doesn't fulfill the minimum security requirements. Are more peerings broken? Regards, Thomas

4 5

When to consider a measurement finished
by Wouter de Vries 25 Jun '19

25 Jun '19

Hi all, I am currently trying to do some measurements according to the following steps: 1. create a one-off measurement 2. wait for it to finish, by periodically polling the msmid and checking the status. 3. fetch the results However, the system takes a pretty long time to set the status to finished, even when all results are already in (maybe 10 minutes?). What heuristics/method do you recommend to determine whether to consider a measurement as finished? One option I consider is to periodically fetch all results for a given msmid and checking if the number of results matches the number of probes assigned to the measurement. However, I suspect that causes a much higher load on the infrastructure. Best regards, Wouter de Vries

3 2

Probe off-line for 6 days due to bad firmware signature
by Novak Jirka 25 Jun '19

25 Jun '19

Hello, my probe 22424 is off-line due to bad firmware signature error. I try to boot it without USB stick many times, then i change the USB stick (replace the old one with new one), but it doesnt solve my problem. Could you help me? This is the information from my status page: Bad Firmware Signature What does this mean? The probe's firmware signature is wrong. How can I fix this? Power-cycle the probe and wait for a couple of hours. If probe doesn't come online you should try to reinitialise or even replace your flash drive. Please use the following procedure: 1. Unplug the probe from its power source 2. Remove the USB stick from the probe 3. Plug in the probe WITHOUT the USB stick 4. Wait for ten minutes 5. Insert the USB stick If it didn't help repeat these steps using another working USB stick that is at least 4GB in size. NOTE: This must be done on a network with working DHCP! It will NOT work if you have configured your probe to use a static IP address, because this mini-operating system does not have access to any statically configure IP addresses or DNS resolvers. If you have configured your probe to use a static IP address, the only thing you can do is move it to a network with working DHCP. When the probe is listed as "connected" again, it is safe to move the probe back to its original location. However, please note that we advise configuring your probe to use a static IP address only if you feel it is truly necessary to do so. Thx, Jiri

3 5

any clue rtt unreachable packet loss 100% com234.476.249
by kiran.gunana＠colruytgroup.com 25 Jun '19

25 Jun '19

Hello, Can some one help me with the reason behind me always getting RTT unreachable and packet loss 100% for every probe I choose to monitor one our service from internet in belgium. Is there something I am not doing right or can guid me a better way of doing it. Even though there is 100% packet loss , my credit balance is still being consumed. Kiran Gunana Network Engineer kiran.gunana(a)colruytgroup.com T +32 2 363 55 45 (Ext : 55711) Colruyt Group Edingensesteenweg 196 - 1500 Halle www.colruytgroup.com LinkedIn Twitter Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

4 3

prometheus exporter atlas_exporter ripe atlas com234.553.762
by kiran.gunana＠colruytgroup.com 24 Jun '19

24 Jun '19

Hello, Is any body out there using "https://github.com/czerwonk/atlas_exporter" promethues exporter for exporting metrics from ripe atlas, started using it , wanted to know experience or best practices before spending more time on it. Only exporting ping metrics for now as explained in the article, any other metrics were tried and how were the results, any such help is appreciated :) Kind Regards, Kiran. Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

1 0

Re: [atlas] any clue rtt unreachable packet loss 100% com234.553.190
by kiran.gunana＠colruytgroup.com 24 Jun '19

24 Jun '19

gboonie, Indeed you are right, I had the impression some thing else is breaking it, I did modify and got my results. rg, kiran ----- Original Message: com234.484.306 --------------------------------- From: Dave . (gboonie(a)gmail.com) To: kiran.gunana(a)colruytgroup.com Copy: ripe-atlas(a)ripe.net Subject: Re: [atlas] any clue rtt unreachable packet loss 100% com234.476.249 Date: 24 June 2019 (09:35) Hi, Your destination is not responding to ICMP (ping/traceroute). This is not an Atlas issue. Dave Op ma 24 jun. 2019 om 08:50 schreef <kiran.gunana(a)colruytgroup.com>: Hello, Can some one help me with the reason behind me always getting RTT unreachable and packet loss 100% for every probe I choose to monitor one our service from internet in belgium. Is there something I am not doing right or can guid me a better way of doing it. Even though there is 100% packet loss , my credit balance is still being consumed. Kiran Gunana Network Engineer kiran.gunana(a)colruytgroup.com T +32 2 363 55 45 (Ext : 55711) Colruyt Group Edingensesteenweg 196 - 1500 Halle www.colruytgroup.com LinkedIn Twitter Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

1 0

delete old measurements from ripe com234.474.800
by kiran.gunana＠colruytgroup.com 24 Jun '19

24 Jun '19

Hello , Is there a way we can delete old measurements in ripe atlas measurements tab. Thes one's which are marked should be deleted for me. Kiran Gunana Network Engineer kiran.gunana(a)colruytgroup.com Colruyt Group Edingensesteenweg 196 - 1500 Halle www.colruytgroup.com LinkedIn Twitter Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

1 0

Mailing list unsubscribe
by Christian Seifert 23 Jun '19

23 Jun '19

Hi, please unsubscribe me from the [atlas] mailing list. thanks

1 0

Mailing subscription
by Noe Manapo 23 Jun '19

23 Jun '19

Hi team, Please I want to join the ripe-atlas mailing list. Thank you Best regard Noe Manapo

2 2

RIPE Atlas anchor resolver update
by Anand Buddhdev 19 Jun '19

19 Jun '19

Dear colleagues, All the RIPE Atlas anchors run a caching DNS resolver. This resolver is used to look up names when a measurement requests name resolution using a probe's resolver. We have been running an older version of BIND for this service. In the coming days, we will be upgrading the version of BIND to the latest stable version (9.14). This version has dropped many work-arounds for various forms of brokenness in other DNS implementations. The effect of this is that a small number of domains hosted on broken DNS implementations cannot be looked up by this newer version of BIND. If you are running a measurement that uses an anchor's local resolver, and you find that some domain names are failing to resolve, it may be caused by this upgrade. Regards, Anand Buddhdev RIPE NCC

1 0

Periodic Probes Outage
by Milad Afshari 17 Jun '19

17 Jun '19

Dear all, Hi Within past days I am experiencing some periodic outage of many probes here in Iran, since I have checked all my probes and their network connections status, I guess they have some issue for connecting to the RIPE Atlas infrastructure. https://atlas.ripe.net/probes/?public=4&status=&country=IR&search=&… please let me know your thoughts and opinions. Many thanks Milad

4 3

RIPE Atlas Software Probes Survey
by Alun Davies 17 Jun '19

17 Jun '19

Dear colleagues, We are working on making the RIPE Atlas measurement software available as an installable package so you can run RIPE Atlas probes entirely in software without the need of a dedicated physical device. We are interested in your feedback regarding this feature, and we are also looking for volunteers willing to partner with us and help package the software for various operating systems and platforms. Please send your feedback and let us know if you can support RIPE Atlas software probes by filling in this short survey: https://www.ripe.net/participate/forms/apply/atlas-probes/ <https://www.ripe.net/participate/forms/apply/atlas-probes/> Kind regards, Alun Davies RIPE NCC

1 0

Web interface for Create New Measurements does not work for me
by ripe＠brite.cz 11 Jun '19

11 Jun '19

https://atlas.ripe.net/measurements/form/ when I click Traceroute and enter an IP address, then "Create My Measurements" button on the bottom does not do anything, no error message. Tried various settings and Firefox, Edge, Chrome. Is it error on my side? Any idea? Thank you Jiri

3 3

RFC1918 probes
by Mayer Hans 22 May '19

22 May '19

Dear All, Looking at the result of a traceroute measurement I see very often that first hop has a RFC1918 address. These days a found a result where the first 3 hops are showing something like 192.168.x.y Of course this could falsify the result especially for response time. Is there a way to select only Atlas probes which are located in non RFC1918 networks ? If not it would be nice to have such a possibility. Kind regards Hans -- Ing. Dipl.-Ing. Hans Mayer Systems Administrator Information and Communication Technologies (ICT) International Institute for Applied Systems Analysis (IIASA) Schlossplatz 1 A-2361 Laxenburg, Austria Phone: +43 2236 807 Ext 215 Mobile: +43 676 83 807 215 Web: http://www.iiasa.at E-Mail: mayer(a)iiasa.ac.at Atlas probe: 35603 Note: If there is a disclaimer or other legal boilerplate in the above message, it is NULL AND VOID. You may ignore it.

3 5

New probe tags proposal
by Antonios Chariton 18 May '19

18 May '19

Hello everyone, I believe it would be of interest to have system-assigned tags to probes based on whether their network is performing RPKI validation or not. This can be two new tags, “rpki-validating” and “no-rpki-validation”, or similar. The tags should be assigned per probe, using RIPE’s RIS Routing Beacons [1], by running system ping checks every hour / day. What do you think? Would this be something that you would find useful? Thanks, Antonis 1: https://www.ripe.net/analyse/internet-measurements/routing-information-serv… <https://www.ripe.net/analyse/internet-measurements/routing-information-serv…>

2 1

Re: [atlas] [WARNING! RECEIVED FROM EXTERNAL SENDER] Incorrect location of probe #6422
by Ponikierski, Grzegorz 09 May '19

09 May '19

BTW it's an anchor. I guess that location of anchors should be double-checked as they play important role. Regards, Grzegorz From: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> Date: Tuesday 2019-05-07 at 17:37 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [WARNING! RECEIVED FROM EXTERNAL SENDER] [atlas] Incorrect location of probe #6422 Hi all! According to Atlas probe #6422 is located in Los Angeles but from measurements it's clear that probe is in Miami. Can somebody relay this information to probe owner to fix location? Regards, Grzegorz

2 1

Incorrect location of probe #6422
by Ponikierski, Grzegorz 07 May '19

07 May '19

Hi all! According to Atlas probe #6422 is located in Los Angeles but from measurements it's clear that probe is in Miami. Can somebody relay this information to probe owner to fix location? Regards, Grzegorz

1 0

Communication with probes' owners
by Ponikierski, Grzegorz 02 May '19

02 May '19

Hi all! From time to time I find probes which has incorrect country in their description. For example #10333 supposed to be in US but from my measurements it looks like it is somewhere nearby Amsterdam. If something has 10ms RTT to target in Amsterdam, has hops with `nl-ams14a-ri1-ae8-0.aorta.net<https://stat.ripe.net/nl-ams14a-ri1-ae8-0.aorta.net>` description and has ASN for LibertyGlobal then this probe is rather in Europe. It takes some time to resolve such issue via RIPE team so maybe we can get a form to send direct and short message to probe owner to let him/her know that something is wrong with his/her probe and we ask for verification. What do you think about that? Regards, Grzegorz

9 13

Probes fluctuation
by Rami Al-Dalky 30 Apr '19

30 Apr '19

Hello, I am running a number of one-off measurements and all what I request is 200 probes. However, I see a fluctuation in the number of participating probes (sometimes I get 198 and sometimes as low as 175). Any idea what is the issue? Thanks a lot, Rami

4 3

All our atlas probes have reverted to DHCP
by Sebastian Wiesinger 24 Apr '19

24 Apr '19

Hi, all of our four atlas probes have reverted from their fixed network configuration to DHCP which is a shame because there is no DHCP at their present locations. Also this not the first time it happend. Can someone explain why this happens and how to prevent this? This wastes a lot of time and effort every time it happens. Regards Sebastian

2 1

Re: [atlas] contacing probe owner.
by Geert Jan de Groot 20 Apr '19

20 Apr '19

> Quite the opposite IMHO, understanding that the anticipated means of > communication will be email and that the email address of a probe's host > will be generic, eg. <ripe-atlas-probe-[number](a)atlas.ripe.net>, > redirecting all incoming emails to a final address. The redirection > would be configured via the portal then. Using an address as described above would allow enumeration attacks. If it would use a hash instead it would be safer. The hash for probe XXX would be obtainable via the portal, where you would need to look up probe's details anyway. Geert Jan

2 1

Measurement result issues for some RIPE Atlas anchors
by Philip Homburg 18 Apr '19

18 Apr '19

In April, we started investigating a strange traceroute result reported by one of the RIPE Atlas anchors. The conclusion of our investigation is that the probe upgrade process for the v3 anchor firmware has been leaving old measurement daemons running as well as starting new ones. This means that a gradually increasing number of measurements from the affected anchors have been performed multiple times more or less simultaneously. Because those processes were writing to the same file, this resulted in a lot of garbled results. Purely by chance, the weird result that triggered the investigation had the first part of one result and the last part of another result in a way that generated syntactically correct JSON. The net result is that for the last few months, measurements done by anchors may have resulted in multiple results at roughly the same time or no results because the results were rejected as invalid. For those who wish to check whether results for specific measurements were affected, the following links will direct you to lists of probe IDs for the affected anchors: https://atlas.ripe.net/api/v2/probes/?is_anchor=true&tags=system-virtual&fi… (VM anchors) https://atlas.ripe.net/api/v2/probes/?is_anchor=true&tags=system-v3-pc-engi… (v3 hardware anchors) We are working to resolve the issue and will keep you updated as and when we have more to report. We apologise for any inconvenience this might cause. Philip

1 0

DNS-over-TLS and DNS-over-HTTPS measurement
by Petr Špaček 10 Apr '19

10 Apr '19

Hello, could you share plans for DNS-over-TLS and DNS-over-HTTPS measurements? I had impression that DNS-over-TLS is already supported but now I cannot find it in the UI so I'm probably wrong. Thank you for information! -- Petr Špaček @ CZ.NIC

3 3

Scheduled RIPE Atlas maintenance 2019-04-10 09:00 UTC
by Chris Amin 10 Apr '19

10 Apr '19

Dear RIPE Atlas users, We are planning on making a behind-the-scenes change to the RIPE Atlas database tomorrow in order to make the system more robust. Measurements scheduled during this time may be either rejected or delayed. Probes will continue to carry out measurements as usual so there won't be a gap in scheduled measurement results. The window for the maintenance is 2019-04-10 09:00 UTC until 12:00 UTC. We hope that it will be quicker than this and will keep you updated. Kind regards, Chris Amin RIPE NCC

1 1

DNS measurements broken today?
by Stephane Bortzmeyer 05 Apr '19

05 Apr '19

It seems all DNS measurements (not just mine, checked on <https://atlas.ripe.net/measurements/?page=1#tab-dns> return only an empty array today... % curl -s https://atlas.ripe.net/api/v2/measurements/20566896/results/ []%

1 0

Responsive Probe Fluctuations
by Marcel Flores 05 Apr '19

05 Apr '19

Hi All, Noticed a funny little swing in probe responsiveness. It seems to have returned to normal, but was curious if anyone else had seen it. We do one-off measurement where we select all probes, usually the responsiveness rates look something like: 12743 Requested / 10147 Actually Participated (Taken from 18 March) But on 19 March we started seeing rates more like: 12914 Requested / 7852 Actually Participated Which continued until about 28 March, when it returned to about the previous levels: 12916 Requested / 9943 Actually Participated Something funny happen with the dispatching? Did anybody else see? -- *Marcel Flores, PhD* | Sr. Research Scientist research.verizondigitalmedia.com | AS15133 <https://www.peeringdb.com/asn/15133> p: +1 310.593.6880 e: marcel.flores(a)verizondigitalmedia.com 13031 W Jefferson Blvd. Building 900, Los Angeles, CA 90094

2 2

Probe not coming online anymore after firmware upgrade
by Annika Wickert 25 Mar '19

25 Mar '19

Hi everyone, I bought a new USB Stick for this probe as the old one was tagged as readonly etc.. https://atlas.ripe.net/probes/23913/ <https://atlas.ripe.net/probes/23913/> In the panel it says: 2019-03-21 14:50:02 UTC Probe firmware upgraded Your probe #23913 <https://atlas.ripe.net/probes/23913/> upgraded its firmware from version 3.3.8 to version 4960 But for some reason it is not coming online at all :(. Any idea what could be the issue? I also see no network traffic at all originating from the probe. Best, Annika

5 5

Fwd: credit request
by Michael Rabinovich 22 Mar '19

22 Mar '19

(I previously subscribed to this list using the same mail alias as used for my RIPE Atlas account, and the mail below was held up for moderation since it came from a non-matching email address. I now changed my subscription and am re-sending that email. I apologize in advance if the moderator releases the original mail and you see a duplicate. — Michael) > Begin forwarded message: > > From: Michael Rabinovich <michael.rabinovich(a)case.edu> > Subject: credit request > Date: March 21, 2019 at 2:45:45 PM EDT > To: ripe-atlas(a)ripe.net > > Folks, > > I teach computer science at Case Western Reserve University. I have a group of students working on a research project to characterize certain aspects of DNS and HTTP interactions on the Web. To get a representative measurement, we need to resolve hostnames from top-1M websites from a large number of widely dispersed probes. So we need a large amount of credits and I was wondering if I could ask folks for help. My back of the envelop calculations suggest we are short of ~200M credits. I realize it’s a large amount, but we would take any help we can get and will conduct as credible measurement as we can with the credits we assemble! Please note that my RIPE Atlas account is associated with mail alias misha(a)case.edu <mailto:misha@case.edu> (not the default email address I am sending from), so please use “misha(a)case.edu <mailto:misha@case.edu>” for credit transfer if you can help. > > Many thanks in advance! > Regards, > Michael Rabinovich > > >

4 4

Request RIPE Atlas Credit for Research
by 陆超逸 07 Mar '19

07 Mar '19

Dear all, Greetings! I'm a PhD student at Tsinghua University, China. Recently a large-scale measurement via RIPE Atlas is needed for my research. However, as a new user I don't have any credit to proceed, and unfortunately the time doesn't allow me to earn them by myself. So I'm here to ask for help. Is it possible for anyone generous enough to offer me some RIPE Atlas credits (like, a million)? My account at RIPE NCC is lcy17(a)mails.tsinghua.edu.cn. Many thanks for your help! Sincerely, Chaoyi Lu

26 27

Re: [atlas] ripe-atlas Digest, Vol 91, Issue 4
by Markus heptner 06 Mar '19

06 Mar '19

500.000 sent :) Markus

1 0

Graphing packet loss
by Steve Hill 01 Mar '19

01 Mar '19

I've got some ping measurements set up and am trying to find a good way to visualise outages. The Latencymon tool obviously shows red shaded sections on the graphs for an outage, but they vanish when zoomed out a long way. A graph of average packet loss seems the obvious way of doing it, but it doesn't look like there's any way to get this from the Atlas website, sort of downloading the data and building my own tool to analyse it. Am I missing something obvious? :) -- - Steve

1 0