- ripe-atlas - mailman.ripe.net

Probe seems DoA
by Benoit Lelievre 03 Jul '18

03 Jul '18

Yesterday I received two v3 probes. While the first one took a while to update and connect the second one is showing a different behaviour. When I plug it in the reset light flashes for about 10 second but then the second LED lights up solid and it seems like the probe is frozen. It doesn't even request an IP address from my DHCP server. The FAQ doesn't list what only having LEDs 1 and 2 on solid means and I'm concerned that this probe is bricked. Any advice on what I should do with this probe? Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 3

New on RIPE Labs: Outcome of the RIPE Atlas Anchor VMs Pilot
by Mirjam Kuehne 02 Jul '18

02 Jul '18

Dear colleagues, The pilot we ran to assess the feasibility of involving virtual machines in the pool of RIPE Atlas anchors is complete and the results are good. Please find more details on RIPE Labs: https://labs.ripe.net/Members/kistel/outcome-of-the-ripe-atlas-anchor-vms-p… Kind regards, Mirjam Kühne RIPE NCC

1 0

Probe connection not holding
by Andre Heinrichs 01 Jul '18

01 Jul '18

Hi everyone, Another day, another weird effect. My probe (29384) keeps losing its connection to the Atlas systems. That seems to happen since the backend problems from Saturday were fixed. I also noticed that my probe switched from ctr-nue13 which it was always connected with to ctr-ams15 after 18 June and yesterday it got connected to ctr-ams14 but lost that connection again quite fast. My questions again: is that (probes getting disconnected all the time) something anyone else sees? Is there something on Atlas‘ side wrong or has my probe somehow lost the ability to stay connected for periods of more than a couple of minutes? There are again no obvious problems with my internet connection. TIA, Andre

2 2

Problems with the RIPE Atlas backend systems
by Anand Buddhdev 30 Jun '18

30 Jun '18

Hi folks, We have some problems with the RIPE Atlas back-end systems. I don't yet know the cause, or when things will be fixed, but this is just to let you know that we're working on it. Regards, Anand Buddhdev RIPE NCC

2 1

Re: [atlas] again: Probe offline, network appears okay
by Steffen Scholz 30 Jun '18

30 Jun '18

Hi, just to confirm, I seem to be having the same problem. My probe was shown as disconnected while the LEDs on the device indicated otherwise. After performing a power cycle it's not reconnecting anymore. Regards, Steffen Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 2

Re: [atlas] again: Probe offline, network appears okay
by Michael H 30 Jun '18

30 Jun '18

Hi. I've had the same problems from time to time. Mostly after a power loss or power disconnect. In the end I had to replace the drive to end this frequent behaviour. This article brought me to success: https://atlas.ripe.net/docs/troubleshoot-probe-issues/ Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

again: Probe offline, network appears okay
by Andre Heinrichs 29 Jun '18

29 Jun '18

Ho everyone, I'm again seeing the problem that Atlas doesn't see my probe as connected although my network shows no problems. I just tried restarting the probe and now the probe sees itself unable to connect. Is there a known problem somewhere, anyone else seeing this behavior or is it something weird on my end? TIA, Andre

1 0

More probes with incorrect location
by Ponikierski, Grzegorz 29 Jun '18

29 Jun '18

Hi! I was making some measurements for Comcast and found 3 probes with incorrect location. Can we fix it? ;) Probe #25030 - probe description and traceroute from this probe suggests California but Atlas map shows Florida. I think it should be California. Traceroute from 25030 towards something in California. ----------------- 1 - 192.168.2.1 NA None NA 0.454ms 2 - 96.120.88.149 7922 None COMCAST-7922 - Comcast Cable Communications, LLC, US 9.291ms 3 - 68.87.196.117 7922 be-20022-rur02.santaclara.ca.sfba.comcast.net COMCAST-7922 - Comcast Cable Communications, LLC, US 8.880ms [...] Probe #32240 - probe description suggests Caribean, map the same but traceroute suggest something in North-East of US. I think that traceroute is right. Traceroute from 32240 towards something in Ashburn. ----------------- 1 - 192.168.109.1 NA None NA 0.446ms 2 - 10.0.0.1 NA None NA 1.670ms 3 - 96.120.64.153 7922 None COMCAST-7922 - Comcast Cable Communications, LLC, US 9.171ms 4 - 96.108.56.17 7922 None COMCAST-7922 - Comcast Cable Communications, LLC, US 9.776ms 5 - 68.85.106.69 7922 be-50-ar01.needham.ma.boston.comcast.net COMCAST-7922 - Comcast Cable Communications, LLC, US 10.496ms 6 - 68.86.90.173 7922 be-1003-pe02.onesummer.ma.ibone.comcast.net COMCAST-7922 - Comcast Cable Communications, LLC, US 9.908ms [...] Probe #22575 - probe description and map suggests UK but traceroute clearly shows it's in Seattle. I think that traceroute is right. Traceroute from 22575 towards something in Seattle. ----------------- 1 - 10.20.30.1 NA None NA 0.519ms 2 - 96.120.100.81 7922 None COMCAST-7922 - Comcast Cable Communications, LLC, US 11.700ms 3 - 68.87.206.221 7922 po-118-rur201.bellevue.wa.seattle.comcast.net COMCAST-7922 - Comcast Cable Communications, LLC, US 9.210ms [...] Regards, Grzegorz

1 0

Error: Only anchors may be targeted.
by Mozafary Mohammad 28 Jun '18

28 Jun '18

Hello I've got "Only anchors may be targeted." on HTTP measurement creation.Any body can advise what the problem is? Thanks

8 9

Re: [atlas] Probe offline, Network appears okay
by Andi Meuli 18 Jun '18

18 Jun '18

Oh, nice. After several reboots and switching to a different USB power device it finally works again!? :-) Don't know what's different, but at least here in my company's network it is running well. -Andi Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 3

Re: [atlas] Probe offline, Network appears okay
by Andi Meuli 18 Jun '18

18 Jun '18

Same here with probe 31884. Interestingly I have a Fritzbox at home as well. I discovered no problems with the network at home, the services worked as expected and as a test I changed the DNS from the provider to 8.8.8.8 and 8.8.4.4. Which did not helped. As a last step, I transferred the probe temporarily to the company network and have the same issue. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 2

Probe offline, Network appears okay
by Andre Heinrichs 18 Jun '18

18 Jun '18

Hi everyone. It looks like my Probe 29384 is offline since my Fritzbox went through the disconnect every 24 hours. This time the probe‘s LEDs (blinking number 3 and 4) tell me thatvthe Probe sees itself as not connected. My internet acces otherwise looks okay, so I’m guessing that it might be something on the other side. I can’t check the SOS requests as the current doesn’t seem to send any after the USB is initialized. TIA, Andre Heinrichs. PS: I tried rebooting the Probe already. That didn’t help.

1 0

Detecting open resolvers with atlas
by Eduardo Duarte 15 Jun '18

15 Jun '18

Hello all, I was wondering if anyone as done any work using Atlas probes to detect open resolvers on the network? I try to find in the RIPE Labs articles works around this problematic but didn't find anything. Thank you, -- Eduardo Duarte Direção de Infraestruturas e Sistemas l Systems and Infrastructure Director *DNS.PT* Rua Latino Coelho, n.º 13, 5.º piso | 1050-132 Lisboa | Portugal Tel: (+351) 211 308 200 Fax: (+351) 211 312 720 dns.pt <http://www.dns.pt> | dnssec.pt <http://www.dnssec.pt> | 3em1.pt <https://www.3em1.pt> | facebook.com/dns.pt <https://www.facebook.com/dns.pt> | pt.linkedin.com/in/dnspt <http://pt.linkedin.com/in/dnspt> Aviso de Confidencialidade/Disclaimer: Este e-mail foi escrito de acordo com o novo acordo ortográfico. Esta mensagem é exclusivamente destinada ao seu destinatário, podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via devendo apagar o seu conteúdo de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail and delete it immediately. [ Antes de imprimir esta mensagem pense no ambiente. Before printing this message, think about environment ]

2 1

New on RIPE Labs: 2018 Campaign to Sponsor 10 RIPE Atlas Anchors
by Alun Davies 15 Jun '18

15 Jun '18

Dear colleagues, This morning we published an article looking at the RIPE NCC’s 2018 campaign to sponsor ten RIPE Atlas anchors. This is a repeat of the successful campaign we ran last year. The article contains all the details on criteria for applicants and how to apply: https://labs.ripe.net/Members/alun_davies/2018-campaign-to-sponsor-10-ripe-… <https://labs.ripe.net/Members/alun_davies/2018-campaign-to-sponsor-10-ripe-…> Best regards, Alun Davies

2 1

No probes working today?
by Stephane Bortzmeyer 14 Jun '18

14 Jun '18

DNS measurements don't start today, no probes are selected for a long time. See for instance <https://atlas.ripe.net/measurements/14367678/> (long delay) or <https://atlas.ripe.net/measurements/14369565> (no probes)

3 4

Running a probe behind a NAT66
by Roman Mamedov 13 Jun '18

13 Jun '18

Hello, I am trying to run a probe (#73) behind an IPv6 NAT. The probe gets an IP in a non-standard prefix 66:113::/64, which is then NATed to a single GUA IPv6. This used to work fine for a few months, but then in April-2018 problems started: the probe would connect to Atlas for 5-10 minutes, then disconnect for about 20 minutes, then connect again; this alternates over and over again. However -- if IPv6 RAs are enabled some time after the probe is powered-on (i.e. the controller connection already got established over IPv4), things seem to go on fine, i.e. the controller is connected over IPv4 for days, but various measurements are performed on IPv6 too. So it seems that only the controller connection is the problem. I fully expect that you didn't account for such a setup in the controller infrastructure or possibly various "local IP is valid" checks and whatnot, but why this used to work fine before? Has there been any change on your side in April that would break this kind of setup? -- With respect, Roman

5 8

Probe #32536 with incorrect location
by Ponikierski, Grzegorz 11 Jun '18

11 Jun '18

Hi! Probe #32536 according to Atlas is located in India but its description, ASN and traceroutes suggest that in fact it's located Slovakia. Please verify. Regards, Grzegorz

2 1

New on RIPE Labs: Sketching Connectivity Between Users
by Mirjam Kuehne 04 Jun '18

04 Jun '18

Dear colleagues, We've been looking at user-to-user connections, based on RIPE Atlas measurements and ISP market share estimates provided by the APNIC. Please see some interesting graphs and a more detailed description in this new article on RIPE Labs: https://labs.ripe.net/Members/emileaben/sketching-connectivity-between-users Kind regards, Mirjam Kühne RIPE NCC

2 3

CLI
by Milad Afshari 03 Jun '18

03 Jun '18

Hi all, It's more than a month that I have a lot of issues with running measurements through CLI here from IRAN, the measurements starts correctly but the results will not be displayed. Do you have any idea to fix this or anyone else have the same problem? Many thanks Milad Afshari

2 5

Probe name rules
by Daniel AJ Sokolov 03 Jun '18

03 Jun '18

Hello, I would like to suggest a naming convention for probes that excludes names referring to features or networks which are not present/supported. For example, I see a probe that contains in its name a large network, although the probe is actually connected to competitor networks. (I assume the probe's host changed their ISP and forgot to update the probe's name.) Such naming is misleading for Atlas users, but also opens a can of worms in relation to trade mark law. Similarly, a prove with "IPv6" in its name that doesn't support IPv6 could be confusing. BR Daniel AJ

2 1

Probe #595 invalid location
by Ponikierski, Grzegorz 27 May '18

27 May '18

Hi! I cannot open page for probe #595 (question is why, it's private?) but from what I see this probe is marked as US probe: [cid:image001.jpg@01D3F5BB.36A72710] But AS 29422 is Finish ISP and when you check traceroute from this probe you will see that's for sure it's more Finland than US. Traceroute: 595 ----------------- 1 - 192.168.0.254 NA None NA 1.614ms 2 - 83.150.126.202 29422 None NBLNETWORKS-AS Nebula Oy, FI 15.026ms 3 - 188.117.15.250 29422 rtr1-te4-3.lau.hel.fi.nblnet.com NBLNETWORKS-AS Nebula Oy, FI 14.762ms <- Finland 4 - 80.239.132.5 1299 hls-b2-link.telia.net TELIANET Telia Carrier, SE 15.005ms <- Finland 5 - 80.91.245.214 1299 s-bb4-link.telia.net TELIANET Telia Carrier, SE 22.251ms <- Sweden 6 - 80.91.249.219 1299 s-b5-link.telia.net TELIANET Telia Carrier, SE 21.888ms 7 - 62.115.36.166 1299 akamai-ic-310810-s-b5.c.telia.net TELIANET Telia Carrier, SE 22.332ms <- Sweden 8 - 23.216.52.2 21342 a23-216-52-2.deploy.static.akamaitechnologies.com AKAMAI-ASN2, US 22.111ms Can you double check location of this probe? Regards, Grzegorz

1 0

Aggregator for TXT record
by Ponikierski, Grzegorz 24 May '18

24 May '18

Hi! I wanted to use Aggregator feature for DNS measurement but looks like it doesn't work with TXT record. Anybody has experience with this feature? Does Aggregator support TXT record? Regards, Grzegorz

1 0

New on RIPE Labs: Update on the RIPE Atlas Anchor VM pilot
by Alun Davies 14 May '18

14 May '18

Dear colleagues, We recently published an update on our pilot programme to assess the feasibility of introducing virtual machines to the pool of RIPE Atlas anchors. Read all about it in this RIPE Labs article from Robert Kisteleki: https://labs.ripe.net/Members/kistel/update-on-the-ripe-atlas-anchor-vm-pil… <https://labs.ripe.net/Members/kistel/update-on-the-ripe-atlas-anchor-vm-pil…> Best regards, Alun Davies RIPE NCC

1 0

Probe #33346 invalid location
by Ponikierski, Grzegorz 11 May '18

11 May '18

Hi! Found another probe assigned to incorrect country: https://atlas.ripe.net/probes/33346/#!tab-network Probe is located in Hong Kong but Atlas things it's China ;) Can you fix it? Regards, Grzegorz

1 0

Atlas #50012 handed over..
by Geert Jan de Groot 09 May '18

09 May '18

Hi, Lia just handed over probe 50012 (that's the new hardware version), and I plugged it into the AIS/AfriNIC network here in Dakar. Can you please make this probe "mine" so I can administer it? For the next few days, will try a few things (and please do so yourself!) My existing probe is 16233. Currently it is powered through the USB port of another device, I will try PoE later (it will switch to 100 mbit then). Currently it seems to do 1gbit. Will make notes and share with you. GJ

2 1

Probe #27786 invalid location
by Ponikierski, Grzegorz 07 May '18

07 May '18

Hi RIPE team! Probe #27786 is located UK but Atlas see it as US probe. It make measurements incorrect. Can you verify it? Regards, Grzegorz

2 1

Firmware version 4660
by BELLAFKIH hayat 07 May '18

07 May '18

Dear Atlas users I am using data collected by RIPE Atlas probes, I found data with a firmware *4660*, but I can't find definition of the structure related to this firmware here <https://atlas.ripe.net/docs/data_struct/> . Any help? Regards *Hayat BELLAFKIH*

2 1

Minor change in the API Participation Requests endpoint
by Agustin Formoso 03 May '18

03 May '18

Dear Atlas users, We're planning to roll-out a minor change in the API Participation Requests endpoint. We'll be changing the response that gets sent out when a Participation Request is submitted. Although minor, the change may break your code if you are making use of the response. Current response example: [35878] Future response example after roll-out: { 'request_ids': [35878] } We plan to put this change into production two weeks from now. For those who don't know what Participation Requests are, they allow you to add or remove probes from a pre-existing measurement. You can find more information in https://atlas.ripe.net/docs/api/v2/manual/participation_requests.html Regards — Agustín Formoso RIPE NCC

1 1

RIPE Atlas probe status issues
by Chris Amin 26 Apr '18

26 Apr '18

Dear RIPE Atlas users, There were various issues relating to the recorded status of RIPE Atlas probes over the weekend. This was brought to our attention by internal monitoring and information provided by users on the mailing list. Throughout this period most probes did actually remain connected to controllers, and measurement results were collected as normal. The side effects included: * the number of probes reported as connected by the system was lower than it should have been * the status (connected/disconnected) of many probes was incorrect * new measurements took longer than usual to start * fewer probes than usual were available for new measurements, leading in some cases to “no suitable” probes messages when trying to schedule new measurements * various system tags were incorrectly applied, including many probes being marked as having USB problems when this was not the case * temporary discrepancies with crediting/debiting of RIPE Atlas credits for the connected time of probes The issues were caused by a bug fix deployment at Friday 9AM UTC where a package was accidentally downgraded causing a regression to an old bug in the task handling of the central system. This bug caused a backlog of messages to build, slowing down or stopping the registering of various status messages in the system. Problems built up gradually as the backlog increased, until the root cause was identified on Sunday morning. The issue was then fixed and the system stabilized completely by about 10AM UTC. We have identified procedural and technical solutions that will stop this problem happening again, and are looking at ways to improve our monitoring of these kinds of issues. We apologise for any inconvenience or confusion caused by this event and would like to thank all of you who took the time to notify us of what you were seeing. Kind regards, Chris Amin RIPE NCC

2 1

Hidden measurements
by Marty Strong 25 Apr '18

25 Apr '18

Does anybody else find that measurements you’ve marked as hidden by clicking on the eye next to it disappear as expected, but don’t show up on the hidden tab (https://atlas.ripe.net/measurements/?page=1#tab-hidden)? Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty(a)cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335

2 9

measurements "Forbidden"
by Marc Anthony Warrior 25 Apr '18

25 Apr '18

All of my RIPE Atlas measurement requests (pings in this case) are suddenly failing with a status "title" field value "Forbidden". Why is this happening?

4 6

paris traceroute output
by Radim Hrazdil 23 Apr '18

23 Apr '18

Hello all! I'm struggling to understand how is the number of paris variations reflected in the merasurement output. If I run paris-traceroute on my machine, the output of a single hop looks something like this: 6 P(16, 16) HOSTNAME (IP):0,1,2,3,4,9,10 4.534/6.072/15.130/2.957 ms HOSTNAME (IP):5,6,7,8 7.641/10.282/13.119/1.965 ms What I'm reffering to is this part: (IP):0,1,2,3,4,9,10, which says which probe packets 'visited' this particular router. I don't understand, how is this reflected in the measurement output. I have never encountered situaton in which 'from' fields within one hop would differ. This would suggest that no load balancing has been encountered, but that seems unlikely to me. Thanks for any replies, Radim Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

dnssec validating system tag?
by Tapio Sokura 23 Apr '18

23 Apr '18

Hello, I was looking at the probe system tags at https://atlas.ripe.net/docs/probe-tags/ when dnssec validating resolvers came to mind. Has there been thoughts about making the probes do dnssec resolver statistics gathering? I.e. how many / which probes are configured with dns resolvers that do / don't do dnssec validation? Tapio

2 1

TLS error when the certificate is expired?
by Stephane Bortzmeyer 23 Apr '18

23 Apr '18

I'm reasonably certain that it has been possible to use 'sslcert' measurements even when the certificate is expired. Today, I try to use 'sslcert' with trigger-happy.eu and it fails: "alert": { "description": 40, "level": 2 }, And no certificate in the JSON output (this is measurement #12166428) 40 is the very general "handshake failure" of TLS. <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-pa…> Was there a change in Atlas recently? The TLS server does reply: % gnutls-cli trigger-happy.eu Processed 167 CA certificate(s). Resolving 'trigger-happy.eu:443'... Connecting to '51.254.210.94:443'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `CN=trigger-happy.eu', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x0359a66c5eb5da799afe079f87416f8d9641, RSA key 2048 bits, signed using RSA-SHA256, activated `2018-01-13 10:46:26 UTC', expires `2018-04-13 10:46:26 UTC', key-ID `sha256:8216c7a7f221f3efcf7e7c3eb1760275d6ebf38d153b74992ee7864147b54435' Public Key ID: sha1:668c4506a393d9bb633590b68c05d878734d7ffe sha256:8216c7a7f221f3efcf7e7c3eb1760275d6ebf38d153b74992ee7864147b54435 Public key's random art: +--[ RSA 2048]----+ | +. o++ | | o +*.=.. | | .=o* . . . | | * B o | | . = S . | | = . . | | + E | | . . | | | +-----------------+ - Certificate[1] info: - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x0a0141420000015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', key-ID `sha256:60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18' - Status: The certificate is NOT trusted. The certificate chain uses expired certificate. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** handshake has failed: Error in the certificate.

2 3

18774 is abandoned definitively ?
by Freddy BULOW 23 Apr '18

23 Apr '18

Hello, Is the status abandoned and definitive, or will it return to status online at its reconnection? If the usb key is new so with a FAT32 partition, the probe will do the necessary to restore the usb key? Thanks for your help. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 1

Request to RIPE Atlas probe hosts in Russia
by Roman Mamedov 23 Apr '18

23 Apr '18

Hello, Given the recent censorship events in Russia [1], some start using the Atlas probes to measure the impact of Roskomnadzor's imposed subnet and IP filtering on end users. For that to be as precise as possible, can you please ensure that your Atlas probe is plugged into the same network as your customers, i.e. subject to all the same filtering and blocking that the customers experience. (I guess this might not be the case if you simply plug it in into some switch next to your server infrastructure, which may be not going through the filters.) Thanks! [1] https://usher2.club/en/ -- With respect, Roman

1 0

Re: [atlas] Probe claimed to be offline
by Andre Heinrichs 22 Apr '18

22 Apr '18

Hi again, I'll add another weird experience from just now. When I last looked at the probe website it claimed the probe had been offline for over 1 day. But just half an hour ago when I looked the website said the probe had been online for 1day 6 hours (which is also not right seing how I've rebooted everything here less than 24 hours ago. And to add even more weirdness just as the hour switched I got the mail that my probe had been disconnected for more than 30 minutes. So right now the probe is offline for 13 hours and 41 minutes. So, basically there's something weird going on inside the Atlas system. Hopefully someone can correct whatever is causing it soon. TIA, Andre. Totally not keeping on refreshing the probe website.

1 0

Probe claimed to be offline
by Andre Heinrichs 22 Apr '18

22 Apr '18

Hi, my probe #29384 is reported as offline since the last network reconnect last night. According to the probe LEDs all looks okay (nothing is blinking, in the order of the FAQ they are On, off, on, on, on). But the website reports the probe as offline. Just the data plot ("Connection & Traffic") shows that the probe sends something out. I've already tried several reboots, did the USB reinitialization (twice, I tried a different USB storage as well) and I've also rebooted my FritzBox. All to no success. BTW: I've not been seeing SOS requests since I last reinitialized the USB in January when the probe was reported as offline as well. At least the USB-less boot showed up there. Is anyone else seeing this kind of problem? Is it a known problem somewhere? Or is there something else I could still try? TIA, Andre.

5 4

Re: [atlas] Paris-traceroute variations
by Radim Hrazdil 21 Apr '18

21 Apr '18

Hello all! I'm struggling to understand how is the number of paris variations reflected in the merasurement output. If I run paris-traceroute on my machine, the output of a single hop looks something like this: 6 P(16, 16) HOSTNAME (IP):0,1,2,3,4,9,10 4.534/6.072/15.130/2.957 ms HOSTNAME (IP):5,6,7,8 7.641/10.282/13.119/1.965 ms What I'm reffering to is this part: (IP):0,1,2,3,4,9,10, which says which probe packets 'visited' this particular router. I don't understand, how is this reflected in the measurement output. Moreover, I have never encountered situaton in which 'from' fields within one hop would differ. This would suggest that no load balancing has been encountered, but that seems unlikely to me. Thanks for any replies, Radim Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

No suitable probes error, and inconsistency between results and measurement status
by Vasileios Giotsas 20 Apr '18

20 Apr '18

Hi all, I have a number of traceroute measurements that end-up with status "No suitable probes". The documentation explains that this error is quite rare, the quote below is from https://atlas.ripe.net/docs/udm/ "No suitable probes: The measurement cannot currently be executed as defined due to a lack of available probes. This may be because you asked to use probes that don't exist (for example, probes in an AS in which there are no probes) or because all of the probes you requested were too busy to take on new jobs. This latter scenario is very rare however." In my case happens in all of my latest measurement request that ask for different probes. It also happens when I use the wizard in the web interface which selects the probes automatically. Even weirder, some of these measurements appear to have been completed when I check the API. For instance, measurement 12244352 has status 6 (No suitable probes), and the web interface doesn't show any results. But the API endpoint shows that it has been executed and returned results: https://atlas.ripe.net/api/v2/measurements/12244352/ I'd appreciate some pointers on how to resolve this issue. Thanks, Vasileios

1 0

how to mark probe as dormant
by Randy Bush 18 Apr '18

18 Apr '18

i have a probe, 2283, which has unplugged from its old home and is in suspended animation in a suitcase until it reaches its new home in a month or two. the location map will not let me pur it in the middle of the pacific. and i can not see how to mark it as dormant/down. clue bat please. randy

4 7

New on RIPE Labs: Creating One-off Measurements with Blaeu, by Stéphane Bortzmeyer
by Vesna Manojlovic 17 Apr '18

17 Apr '18

Dear colleagues, Yesterday we published an article by Stéphane Bortzmeyer, where he presents Blaeu, a set of tools to create one-off measurements, mostly to debug temporary issues. Please find more details on RIPE Labs: https://labs.ripe.net/Members/stephane_bortzmeyer/creating-ripe-atlas-one-o… Kind regards, Vesna Manojlovic RIPE NCC

1 0

New on RIPE Labs: RIPE Atlas Measurement Tagging
by Mirjam Kuehne 12 Apr '18

12 Apr '18

Dear colleagues, The new RIPE Atlas measurement tagging feature is now available. Please find more details in this new RIPE Labs article: https://labs.ripe.net/Members/chris_amin/ripe-atlas-measurement-tagging Kind regards, Mirjam Kühne RIPE NCC

1 0

Join Network Operators' Tools Hackathon 23-24. June 2018 in Dublin; organised by: iNOG & RIPE NCC
by Vesna Manojlovic 10 Apr '18

10 Apr '18

Dear colleagues, The seventh RIPE NCC hackathon will take place on Saturday and Sunday, 23-24 June 2018 in Dublin -- co-hosted by iNOG (Irish Network Operators Group), whose 16th edition is happening on Thursday, 21st June. The topic this time is: tools for network operators. Find out more in this RIPE Labs article: https://labs.ripe.net/Members/becha/join-network-operators-tools-hackathon RIPE NCC hackathons are cooperative, and all source code developed during the event will be publicly licensed and available on GitHub, and will be free for the entire community to use. -------------------- How to Apply -------------------- Interested? Learn more and apply online today! https://www.ripe.net/participate/forms/apply/dublin-hackathon/ *The first application deadline is 1st May* We look forward to seeing you there! Regards, Vesna Manojlovic Community Builder RIPE NCC

1 0

Result streaming lacking results
by Tim Wattenberg 14 Mar '18

14 Mar '18

Hi everyone, I'm working on a project where I create a measurement via API and immediately subscribe to the result stream as well as the metadata stream ( https://atlas.ripe.net/docs/api/v2/manual/measurements/result-streaming.html ). socket.emit("atlas_subscribe", {stream_type: "result", msm: mid, sendBacklog: true}); socket.emit("atlas_subscribe", {stream_type: "metadata", msm: mid}); Now even with (and also without) the sendBacklog option enabled, I rarely get even close to receive all results (the measurement produces max. 10 in total, I received max. 4-5, often only one or even none). Same goes for metadata, where I sometimes get the action: creation event, but never a notification when the measurement is stopped. Another question in this context: When does a one-off measurement gets stopped? I also subscribed to (dis)connect, atlas_error and atlas_subscribed but they give no hint what could be going wrong. I also tried the replay feature, which did not work at all for me either: socket.emit("atlas_subscribe", {stream_type: "result", msm: mid, startTime: <Time of creation>}); What am I doing wrong? Thanks, Tim Tim Wattenberg mail(a)timwattenberg.de +49 1578 8248731

2 1

API Keys problem?
by Daniel Ankers 09 Mar '18

09 Mar '18

Hi, Has there been a change in the way that API keys work for the measurement results API? I've got an API key which is granted permission to get results from a non-public measurement. When I do: curl -H "Authorization: Key $KEY" " https://atlas.ripe.net/api/v2/measurements/$MEASUREMENT/results/?start= 1520510400" (Replacing $KEY with the key and $MEASUREMENT with the measurement ID) I get: {"error":{"status":400,"errors":[{"source":{"pointer":""},"detail":"Your keys has no grants"}],"code":102,"detail":"There was a problem with your request","title":"Bad Request"}} This was previously working, but I'm not sure exactly when it stopped. I've checked that getting the data through my browser works while I'm logged into the site, and that if I request https://atlas.ripe.net/api/v2/measurements/$MEASUREMENT/latest using the API key I get data returned. Regards, Dan

4 5

New on RIPE Labs: Announcing Daily RIPE Atlas Data Archives
by Mirjam Kuehne 02 Mar '18

02 Mar '18

Dear colleagues, In this article we present a new way to access the dataset on the RIPE Atlas platform. Instead of fetching individual results from measurements using the available APIs, you can now download files containing public measurements for a given day. Please find more details on RIPE Labs: https://labs.ripe.net/Members/petros_gigis/announcing-daily-ripe-atlas-data… Kind regards, Mirjam Kühne RIPE NCC

9 12

New on RIPE Labs: OpenIPmap - A Collaborative Approach to Mapping Internet Infrastructure
by Mirjam Kuehne 14 Feb '18

14 Feb '18

Dear colleagues, OpenIPmap, the RIPE NCC’s tool for geolocating core Internet infrastructure, has undergone a full architectural overhaul. With a new set of APIs and interfaces designed to cater to the needs of all users, the system integrates various methods for estimating the geographical locations of IXPs, core routers and other components of Internet infrastructure. In this, the first of two RIPE Labs articles on the topic, we look at the evolution of OpenIPmap from its inception to today: https://labs.ripe.net/Members/jasper_den_hertog/openipmap-a-collaborative-a… Kind regards, Mirjam Kühne RIPE NCC

1 0

Re: [atlas] multiple measurements failed on probe 15861
by ripe＠brite.cz 12 Feb '18

12 Feb '18

Please disregard. The measurements eventually delivered at 2018-02-10, while measurement was created and all other probes delivered their results at 2018-02-07. Thats weird, but at eventually it works. Thank you Jiri ______________________________________________________________ > Od: <ripe(a)brite.cz> > Komu: <ripe-atlas(a)ripe.net> > Datum: 09.02.2018 16:42 > Předmět: multiple measurements failed on probe 15861 > > >Hi team, >it seems traceroute measurements fail on Probe 15861: > >-following measurements created only for Probe 15861: >https://atlas.ripe.net/measurements/11204846/ >https://atlas.ripe.net/measurements/11204847/ >both ended up with "Failed" result > > >-following measurements contain multiple probes together with Probe 15861, and whereas other probes give results as expected, for this probe the result show "No recent report available": >https://atlas.ripe.net/measurements/11194845/ >https://atlas.ripe.net/measurements/11194846/ > >Built-in measurements look fine though. > >Any idea? Am I doing something wrong? >The probe is located at my home, connected to switch where all other devices work fine. > >Thank you > >Jiri > >

1 0

multiple measurements failed on probe 15861
by ripe＠brite.cz 09 Feb '18

09 Feb '18

Hi team, it seems traceroute measurements fail on Probe 15861: -following measurements created only for Probe 15861: https://atlas.ripe.net/measurements/11204846/ https://atlas.ripe.net/measurements/11204847/ both ended up with "Failed" result -following measurements contain multiple probes together with Probe 15861, and whereas other probes give results as expected, for this probe the result show "No recent report available": https://atlas.ripe.net/measurements/11194845/ https://atlas.ripe.net/measurements/11194846/ Built-in measurements look fine though. Any idea? Am I doing something wrong? The probe is located at my home, connected to switch where all other devices work fine. Thank you Jiri

1 0