- ripe-atlas - mailman.ripe.net

Long response times using one-off measurements with old probes
by Moritz Muller 17 Dec '18

17 Dec '18

Hi, I would like to point you to a discussion on the DNS-OARC mailing list: https://lists.dns-oarc.net/pipermail/dns-operations/2018-December/018196.ht… One of the operators at .ca noticed that old probes report way higher response times using DNS CHAOS queries (300% or more) (see also [3]). After some digging, we came to the conclusion that this has to do with the fact that he is carrying out “one-off” measurements. When carrying out the same query for a longer time, we cannot observe this delay. The issues seems to be that one-off measurements are scheduled at probes using a different library than measurements that run for a longer period (“eooqd” instead of “eperd”). Some small additional delays have been documented before on the RIPE Atlas website and in research papers [1, 2], but the big delay with one off measurements was new to me. Also to others? Is our assumption correct that the scheduler is the culprit? Moritz [1] https://dl.acm.org/citation.cfm?doid=2805789.2805796 [2] https://clarinet.u-strasbg.fr/~pelsser/publications/Holterbach-ripe-atlas-s… [3] https://atlas.ripe.net/measurements/18086197/#!probes

2 3

API is sluggish
by Ponikierski, Grzegorz 11 Dec '18

11 Dec '18

Hi all! Did you notice that for last few days API is super slow to response. It takes something like few minutes to get reply. Do you observe any issue with Atlas infrastructure? What details I should provide to help with troubleshoot? Regards, Grzegorz

2 3

DNS Measurement Grouping by NSID
by Klaus Darilion 30 Nov '18

30 Nov '18

Hi! IIRC, the map of the DNS measurement allowed to group the dataset by NSID. Was this feature removed? OR is it now somewhere else? I.e.: https://atlas.ripe.net/measurements/17175212/?filter=&diversity-picker=3&ag… Thanks Klaus

4 6

Minor change to Atlas anchor DNS resolver configuration
by Anand Buddhdev 28 Nov '18

28 Nov '18

Dear colleagues, Each RIPE Atlas anchor runs a DNS resolver. This resolver is configured as the primary resolver for the anchor, with the following directive at the top of the resolver configuration (/etc/resolv.conf): nameserver 127.0.0.1 For ease of configuration management, we are changing this directive to: nameserver ::1 This change will not affect DNS resolution on the anchors in any way. However, any measurement that does DNS lookups using the anchor's primary resolver will contain "::1" instead of "127.0.0.1" in "src_addr" field of results. If you're using any code to parse such results, and specifically looking for "127.0.0.1", you'll need to adjust your code to also look for "::1". Regards, Anand Buddhdev RIPE NCC

1 0

no measurements
by Teun Vink 20 Nov '18

20 Nov '18

Hi, Are there any problems with the Atlas backend? All requests are answered with {u'info': u'Something went wrong with our back-end', u'type': u'redis- fail'} I don't see any working measurements in our webportal as well. Best regards, -- Teun Vink BIT | teun(a)bit.nl | +31 318 648 688 KvK: 09090351 | GPG: 0xFC8B25D6 | RIPE: TEUN-RIPE

2 3

New on RIPE Labs: Announcing RIPE Atlas VM Anchors
by Alun Davies 12 Nov '18

12 Nov '18

Dear colleagues, We just this morning published an article announcing that, as of today, we are accepting applications for anyone interested in hosting RIPE Atlas VM anchors. The article points you to all the information you’ll need to apply for and install a virtual anchor: https://labs.ripe.net/Members/alun_davies/announcing-ripe-atlas-vm-anchors <https://labs.ripe.net/Members/alun_davies/ripe-atlas-anchor-vms> Kind regards, Alun Davies RIPE NCC

5 6

Temporary problem with RIPE Atlas measurement creation
by Chris Amin 01 Nov '18

01 Nov '18

Dear RIPE Atlas users, Due to a complication during a deploy, there was a problem scheduling RIPE Atlas measurements from approximately 12:50 to 14:14 UTC. Most new measurements created during this time will not have been scheduled properly. The issue is now fixed for new measurements, so if your measurements didn't work during this time you can try to create them again and it should work. Apologies for any inconvenience caused. Regard, Chris Amin RIPE NCC

1 0

Delays over the weekend
by Robert Kisteleki 29 Oct '18

29 Oct '18

Dear all, Some of you have noticed that there were delays in how RIPE Atlas behaved, starting on Saturday. This happened because of an issue deep in the bowels of the infrastructure which caused tasks (including measurement requests) to pile up. We believe the issue has been resolved by now, though we're still investigating the root cause of the issue. We apologise for the inconvenience this caused. Regards, Robert Kisteleki RIPE Atlas team

1 0

New set - wizard improvements suggestion
by Evgeniy S. 24 Oct '18

24 Oct '18

Dear All, finally we are using our ripe probes to monitor our resources from mobile networks. I found that current "new set - wizard" functionality is lacking some useful extra filters using: 1) "User tags" - then I can tag my mobile probes and select only mobile network probes from the list. 2) mine, favorites, sponsored, ambassadorships It will be also nice to request to tag mobile network probes for users who run them. Any feedback is appreciated. I'm also interesting for getting in touch with people who have probes installed in mobile networks to make tests / comparing to our setup. -- With regards, Eugene

1 0

Relocating a probe
by Gary Gapinski 20 Oct '18

20 Oct '18

Hello: I currently host a probe (#14102) at my residence. I will soon move to a new residence about 450 miles from the current location. Such a move will necessarily alter measurements obtained relative to past ones (as well as ASN, geolocation, etc.). Should the existing probe identity be retired in favor of a new identity? (And if so how might that be accomplished?) Regards, Gary

2 2

WG: Probe 1198 is disconnected (Keck.US)
by Cornelius Keck 08 Oct '18

08 Oct '18

Power outage. Repair ETA not yet available. Thx for the heads-up. Gesendet von meinem BlackBerry 10-Smartphone. Originalnachricht Von: RIPE Atlas (no reply) <no-reply(a)ripe.net> Gesendet: Sonntag, 7. Oktober 2018 16:30 An: ckeck(a)texoma.net Antwort an: RIPE Atlas (no reply) Betreff: Probe 1198 is disconnected (Keck.US) Dear Cornelius Keck, Your probe 1198 has been disconnected from the RIPE Atlas infrastructure since 2018-10-07 21:05:06 UTC. You may be able to learn more about the possible cause from the "Status" tab on your probe's information page: https://atlas.ripe.net/probes/1198/#!tab-status Probes are tagged with suspected problems every four hours, so if there is nothing listed under the Status tab and your probe has just gone offline, please check back in a few hours, as more information may be available. If you need further assistance or have any questions, please contact us at atlas(a)ripe.net. Kind regards, RIPE Atlas Team ********** This is an automatically generated email from RIPE Atlas. It was sent to you because you asked to be notified if your probe becomes disconnected for more than 15 minutes. If you want to change this, or disable this notification altogether, please go to https://atlas.ripe.net/probes/1198/, and click the "edit" button under "Notifications".

1 0

Definition of Commercial Use
by Mic Szillat 04 Oct '18

04 Oct '18

Hi folks, I have a discussion in my company about the definition of commercial use. Can we please get an official confirmation whether our typical usage of Atlas is covered by the terms of service? We occasionally use Atlas to debug network connectivity between our systems and those of our customers. We answer support requests and confirm or deny network issues based on the data collected. We do not give customers access to the measurement interface. Thanks, Mic

3 3

New on RIPE Labs: Measuring Anycast DNS Services Using RIPE Atlas
by Mirjam Kuehne 01 Oct '18

01 Oct '18

Dear colleagues, Please find this step-by-step guide contributed by Kenneth Finnegan on RIPE Labs on how to use RIPE Atlas to measure the world-wide performance of Anycast DNS services: https://labs.ripe.net/Members/kenneth_finnegan/measuring-anycast-dns-servic… Kind regards, Mirjam Kühne RIPE NCC

1 0

Extended CHAOS queries
by Moritz Muller 24 Sep '18

24 Sep '18

Hi all, I was wondering if it would be possible to extend the supported CHAOS TXT query arguments to trustanchor.unbound. and trustanchor.server? This would enable RIPE Atlas probes to measure which DNSSEC Trust Anchors Unbound and PowerDNS resolvers have configured (if they support this query). Cheers, Moritz

1 0

Is there a max running measurement number for a user
by Yihao Jia 30 Aug '18

30 Aug '18

Dear all, Is there a max running measurement number for a user? I try to launch about 800 measurements, but only about 150 of them succeed and keep running, while another 650 fail with the description "overlimited denied" one of the fail measurement is: https://atlas.ripe.net/measurements/15302198/ Do you know what's the reason I failed? (btw, I am wondering how to check the reason why a measurement is failed by the measurement id?) Many thanks, Yihao

3 2

Re: [atlas] Looking for advise and temporarily limits increment for research
by Alan Walker 30 Aug '18

30 Aug '18

https://www.ripe.net/participate/mail/forum/ripe-atlas/PENBTDZlRWUzUlR4ai1q… Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

The three generations of the Atlas probes : technical details
by BELLAFKIH hayat 30 Aug '18

30 Aug '18

Hi, I hope validate some details about the Atlas probes. I try to get these details by consulting the resources: 1. https://atlas.ripe.net/docs/probe-v1/ 2. https://atlas.ripe.net/docs/probe-v2/ 3. https://atlas.ripe.net/docs/probe-v3/ But no technical details given. By reading some presentations, I create the table bellow. Now, I hope if you can validate these details and complete the information about the CPU. It will be good if you can add the technical details for each generation of the probes. Thanks in advance. *Hayat BELLAFKIH*

3 3

need help in RIPE atlas credits
by Yihao Jia 28 Aug '18

28 Aug '18

Dear all, I am Yihao, a Ph.D. student at Tsinghua University. Right now I plan to start an experiment with the RIPE atlas, but I don't have enough credits to fulfill the whole process. I am writing this letter to inquire if anyone can share some credits with me. (like 1 Million) Appreciate! (My RIPE atlas account: yhjia.03(a)gmail.com) Many thanks, Yihao Tsinghua University

5 6

Getting More Traffic for Probe
by Eren Türkay 27 Aug '18

27 Aug '18

Hello, I am running a probe [0] at my home and I have 240Mbit connection from my provider. When I look at the graphs, this probe is basically sitting idle doing nothing! I can spare 20Mbit/s easily for measurements to keep the usage. However, I do not know how to achieve that. Is it possible to attract more traffic to my probe? I'm sure there is some algorithm involved to distribute the work so if you can please get me some more work, I'd be pleased [obviously more credits to spare :)] [0] https://atlas.ripe.net/probes/31252/ Regards, -- . 73! DE TA1AET http://erenturkay.com/

4 5

Probe for mobile network
by Evgeniy Sudyr 25 Aug '18

25 Aug '18

We have developed mobile application and we are interesting for making measurements from our customer''s networks using ripe atlas probes. I found no probes from interesting ASN, that's why I'm looking for a way to host own probes (we do have already) and connect it to interesting MNO networks using some USB sticks or even mobile phones (to use as 3G / LTE modem). Obviously we want to make less points of failure in between RIPE probe and mobile modem. Any luck to get USB sticks working with RIPE probe without some router in between? -- With regards, Eugene Sudyr

1 0

Looking for an AS8560 contact
by Robert Kisteleki 22 Aug '18

22 Aug '18

Hello, We're looking for a contact in the RIPE Atlas context from AS8560 (oneandone.net). There's a (probably runaway) script hammering our gates. Thank you, Robert Kisteleki for the RIPE Atlas team

1 0

Failled to get traceroute results from the id 5151
by BELLAFKIH hayat 16 Aug '18

16 Aug '18

Hi all, I am trying to get traceroute results for the measurements id 5151 ( https://atlas.ripe.net/measurements/5151/) by using python module : Python client for RIPE ATLAS API, for period october 2016. For many days ( eg : 19, 20) in this period, the operation is failled. I got Killed ! I found that the reason of having Killed when running a python script is related to the ressources limits. Any helps? *Hayat BELLAFKIH*

1 0

Probe limit per measurement
by Schomp, Kyle 08 Aug '18

08 Aug '18

Hi all, I'm trying to use Ripe Atlas for monitoring a production system. I've hit the 1k maximum probes per measurement limit, however. I realize I could just split up the task among multiple measurements to stay under the 1k probes max, but that seems sort of hack-ish and possibly less efficient for the platform. Is it possible to get the limits increased? Thanks! -kyle

2 1

Processing RIPE Atlas data as Big Data
by BELLAFKIH hayat 24 Jul '18

24 Jul '18

Dear RIPE Atlas users, I am studying the processing of the data collected by the probes as a Big Data problem. For instance, one hour of traceroute data count for 500 Mo (bzip2), so 7 Go of data in text format. Can you share with me how you deal with these data in practice. are you using a super machine, Big Data tools? best regards, Hayat

2 1

Looking for advise and temporarily limits increment for research
by Yihao Jia 22 Jul '18

22 Jul '18

To whom it may help, My name is Yihao. I am a Ph.D. student. Recently I am doing a research with RIPE Atlas. However, my research requires many measurements in a short period, which breaks several rules of the Rate Limits. Since I really like and in hurry to use Atlas to support my research, is there any advice I can get from this? I'd like to describe why it would be necessary for my research. And if possible, may I get a temporarily limit increment for 10 days? Many thanks, Yihao Jia

3 3

Re: [atlas] Need help: launching a periodical atlas measurement
by Stephane Bortzmeyer 19 Jul '18

19 Jul '18

On Thu, Jul 19, 2018 at 10:47:54AM -0500, Yihao Jia <yhjia03(a)gmail.com> wrote a message of 192 lines which said: > I am a little confused because all example on documents is one-off. I guess > error might happen around "is_oneoff", "interval", "spread". > source code for this test is below and in the attachment. "is_oneoff" is off by default. "interval" is documented as "In normal (not one-off) measurements, this value represents the number of seconds between measurements by a single probe." I never tried "spread". I don't know the exact JSON you sent but this one worked (5 minutes, 1 minute between each test): {'definitions': [{'target': 'fr-ilm-as57119.anchors.atlas.ripe.net', 'af': 4, 'interval': 60, 'packets': 1, 'type': 'ping', 'description': 'Ping fr-ilm-as57119.anchors.atlas.ripe.net'}], 'start_time': 1532026200, 'stop_time': 1532026500, 'probes': [{'requested': 1, 'type': 'area', 'value': 'WW'}]} And it gave this measurement: https://atlas.ripe.net/measurements/15297080/

1 0

Inquiry: RIPE Atlas credits M Fung
by Matthew Fung 19 Jul '18

19 Jul '18

Hello, My name is Matthew, I am an undergrad studying CS at University of British Columbia. I've recently discovered the work done by RIPE and I'm really interested in using Atlas for a research project. I am wondering if anyone is willing to share credits in order to make this possible. I aim to use no more than 1M credits. (My user info is included below) Thanks, Matthew Fung RIPE ID: y6c0b(a)ugrad.cs.ubc.ca

2 1

Global Traceroute
by Steve Gibbard 19 Jul '18

19 Jul '18

I wrote front-end to traceroute from the RIPE Atlas probes. It looks like a standard looking glass — you select a probe by location and AS number, enter a destination, and it does a traceroute. It’s on the web at https://www.globaltraceroute.com. If this looks useful, please check it out and tell me what you think. One of the things I've found frustrating when troubleshooting routing problems was the lack of information about inbound paths. Various measurement systems would tell me when performance was bad. Traceroutes from my own network would tell me what path traffic to a destination was taking outbound. Flow systems would tell me what interface inbound traffic was coming in on, and sometimes what peer it was coming through. But determining the full path inbound traffic was taking — why users of some ISP in Asia were having their traffic show up at one of my POPs in Europe, for instance, was much more difficult. I’ve been using looking glasses and commercial performance monitoring systems that allow traceroutes from their probes, but those often weren’t where the end users were. RIPE Atlas did have probes where a lot of my end users were, so I started configuring one time measurements on RIPE Atlas whenever I needed a traceroute from a simulated end user. But finding a suitable probe and configuring the measurement was too cumbersome to do when I wasn’t pretty desperate. This is my attempt to solve that problem. Thanks, Steve

6 7

For help: launching a periodical atlas measurement
by Yihao Jia 19 Jul '18

19 Jul '18

Dear all, I am so sorry for using a screenshot for my last email. And I'd like to redescribe the problem I have. I'd like to launch a periodic Ping measurement (with python). It starts at UTC-now to (for example) 5 minutes later. I'd like the probe do the Ping test in every 1 minute. Thus I can have 5 results in this measurement. I am a little confused because all example on documents is one-off. I guess error might happen around "is_oneoff", "interval", "spread". source code for this test is below and in the attachment. Could you help me in checking where I get wrong? Many thanks, Yihao ---------------------------------------------------------------------------------------------- from datetime import datetime, timedelta from ripe.atlas.cousteau import ( Ping, AtlasSource, AtlasCreateRequest ) ATLAS_API_KEY = "" source2 = AtlasSource( requested=1, type="probes", value="35704" ) ping = Ping( af=4, target="202.112.51.179", description="Test for periodic Ping test", packets=1, ) def request(): atlas_request = AtlasCreateRequest( start_time=datetime.utcnow(), stop_time=(datetime.utcnow() + timedelta(minutes=5)), key=ATLAS_API_KEY, measurements=[ping], sources=[source2], is_oneoff=False, interval=60, spread=60 ) (is_success, response) = atlas_request.create() return is_success, response if __name__ == '__main__': is_success, response = request()

1 0

Need help in launching a periodical atlas measurement
by Yihao Jia 19 Jul '18

19 Jul '18

Dear all, I am in trouble with launching a periodical Ping measurement. [image: image.png] my script is like this, but my measurement always fails. I tried several times with different modification on "interval" and "spread". [image: image.png] one failed example can be reviewed here: https://atlas.ripe.net/measurements/15282285/ It works well when I launch a one-off measurement, but every time I try to launch a periodic measurement with the setting above, it fails all the time. it probably because the "is_oneoff", "interval", "spread" is set wrong, but I can't find a good example for it. The idea of this test measurement is to start a Ping test every 1 minute, from UTC-now to 5 minutes later. Thus, I'd like to have 5-set result in this measurement. Could you help me check where I set wrong? Many thanks, Yihao

3 2

DNS measurement using the Probe's resolvers
by Rami Al-Dalky 18 Jul '18

18 Jul '18

Hi Everyone, I have a question about using the probe's list of resolvers when creating a DNS measurement. It is unclear to me whether the probe would send the query to all resolvers at the same time or not! Also, does the probe send the query to all resolvers in its list or to a subset of those resolvers? Is DNS eyeball implemented in the probes? Sincerely, Rami

3 2

Transfer Anchor ownership
by Clément Hertling (Wxcafé) 17 Jul '18

17 Jul '18

Hi, We have an anchor at the company I work for that has been associated with the wrong RIPE Atlas account. We're trying to move it from that (personal) atlas account to a shared netops account, but can't find a way to do this. Is there a way to do this ourselves, or can someone from RIPE Atlas do it for us? Cheers, -- Clément 'wxcafé' Hertling

2 1

Wrong TLSA for stat.ripe.net
by Alarig Le Lay 10 Jul '18

10 Jul '18

Hi, Since one week or so, I have a TLSA validation error for stat.ripe.net on TCP/443 at each time I visit https://atlas.ripe.net/ and I have the same result from the RIPE nlnog node: alarig@airmure ~ % echo '' | openssl s_client -connect atlas.ripe.net:443 2>/dev/null | openssl x509 -in /dev/stdin -fingerprint -sha256 | grep SHA256 | sed 's/://g' | cut -d '=' -f 2 8248E13AB5CA3BACAC63F15B831DA32F2CD54973EDF74E69B6A614B7295C02B4 alarig@airmure ~ % dig +short -t TLSA _443._tcp.atlas.ripe.net | awk '{ print $4 $5 }' 8248E13AB5CA3BACAC63F15B831DA32F2CD54973EDF74E69B6A614B7295C02B4 alarig@airmure ~ % echo '' | openssl s_client -connect stat.ripe.net:443 2>/dev/null | openssl x509 -in /dev/stdin -fingerprint -sha256 | grep SHA256 | sed 's/://g' | cut -d '=' -f 2 2A2B939449E847374121D4846E3117F23A0283C7B2818ED96C91D2808ABE4C0E alarig@airmure ~ % dig +short -t TLSA _443._tcp.stat.ripe.net | awk '{ print $4 $5 }' E3DC43427AA9F62D1E07BBE108AF62BEE84A454DB579FD57A4FFDFFD5A23E576 grifon@ripe01:~$ echo '' | openssl s_client -connect stat.ripe.net:443 2>/dev/null | openssl x509 -in /dev/stdin -fingerprint -sha256 | grep SHA256 | sed 's/://g' | cut -d '=' -f 2 2A2B939449E847374121D4846E3117F23A0283C7B2818ED96C91D2808ABE4C0E grifon@ripe01:~$ dig +short -t TLSA _443._tcp.stat.ripe.net | awk '{ print $4 $5 }' E3DC43427AA9F62D1E07BBE108AF62BEE84A454DB579FD57A4FFDFFD5A23E576 The commands are ugly but work on atlas.ripe.net. Could you please update it? Regards, -- Alarig Le Lay

1 0

New on RIPE Labs: Comparing Virtual and Metal RIPE Atlas Anchors
by Mirjam Kuehne 04 Jul '18

04 Jul '18

Dear colleagues, We compared performance between virtual and physical RIPE Atlas anchors. Please find the results on RIPE Labs: https://labs.ripe.net/Members/stephen_strowes/comparing-virtual-and-metal-r… Kind regards, Mirjam Kühne RIPE NCC

1 0

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