From mir at ripe.net Fri Jun 1 16:19:02 2018 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 1 Jun 2018 16:19:02 +0200 Subject: [atlas] New on RIPE Labs: Sketching Connectivity Between Users Message-ID: 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 From randy at psg.com Sat Jun 2 16:43:29 2018 From: randy at psg.com (Randy Bush) Date: Sat, 02 Jun 2018 07:43:29 -0700 Subject: [atlas] New on RIPE Labs: Sketching Connectivity Between Users In-Reply-To: References: Message-ID: > We've been looking at user-to-user connections, based on RIPE Atlas > measurements and ISP market share estimates provided by the APNIC. /// eyeball randy From randy at psg.com Sat Jun 2 16:57:29 2018 From: randy at psg.com (Randy Bush) Date: Sat, 02 Jun 2018 07:57:29 -0700 Subject: [atlas] New on RIPE Labs: Sketching Connectivity Between Users In-Reply-To: References: Message-ID: >> We've been looking at user-to-user connections, based on RIPE Atlas >> measurements and ISP market share estimates provided by the APNIC. > /// eyeball btw, sorry to be picky. but those apnic data are mislabeled too often. the article is a nice piece. an intuitive visualisation randy From listclient at sokolov.eu.org Sun Jun 3 11:37:23 2018 From: listclient at sokolov.eu.org (Daniel AJ Sokolov) Date: Sun, 3 Jun 2018 02:37:23 -0700 Subject: [atlas] Probe name rules Message-ID: <00b1b146-b586-c80c-43a7-b7865f342865@sokolov.eu.org> 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 From gponikie at akamai.com Sun Jun 3 13:53:05 2018 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Sun, 3 Jun 2018 11:53:05 +0000 Subject: [atlas] Probe name rules In-Reply-To: <00b1b146-b586-c80c-43a7-b7865f342865@sokolov.eu.org> References: <00b1b146-b586-c80c-43a7-b7865f342865@sokolov.eu.org> Message-ID: <2F1BF6B5-76D2-421D-80DA-1DE07095578D@akamai.com> Hi Daniel! In my case I don't even look at probe description. I create my measurements mostly via REST API so I use 'asn_v4' and 'asn_v6' to get probes from network(s) that I need. For probes which have set 'asn_v6' I can also verify system tag 'system-ipv6-works' to see if it really works. Web interface also allow you to get probes from given 'asn_v4' and 'asn_v6' and to include only probes with specific system tag. Good thing about these values is that they are generated and updated automatically by RIPE Atlas infrastructure. AFAIK probe description field is only for probe owner to make it easier for him/her to manage probes. Notice that a lot of probes have generic format "Probe #12345" as many people have only one probe so there is no need to change it. Regards, Grzegorz From: Daniel AJ Sokolov Date: Sunday 2018-06-03 at 11:37 To: "ripe-atlas at ripe.net" Subject: [atlas] Probe name rules 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From afshar.milad89 at gmail.com Sun Jun 3 14:23:36 2018 From: afshar.milad89 at gmail.com (Milad Afshari) Date: Sun, 3 Jun 2018 16:53:36 +0430 Subject: [atlas] CLI In-Reply-To: <20180530065248.n3rpy5utft25xema@sources.org> References: <20180529113624.g5f5nmj35nduotob@nic.fr> <20180530065248.n3rpy5utft25xema@sources.org> Message-ID: Hi Stephane, Thanks for your suggestion, I have installed the " blaeu" and It is working better now. On Wed, May 30, 2018 at 11:22 AM, Stephane Bortzmeyer wrote: > On Wed, May 30, 2018 at 11:13:11AM +0430, > Milad Afshari wrote > a message of 97 lines which said: > > > Exception in thread Thread-1 (most likely raised during interpreter > shutdown): > > Traceback (most recent call last): > > File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner > > File "/usr/lib/python2.7/dist-packages/socketIO_client/heartbeats.py", > line 27, in run > > File "/usr/lib/python2.7/dist-packages/socketIO_client/__init__.py", > line 192, in _ping > > File "/usr/lib/python2.7/dist-packages/socketIO_client/transports.py", > line 159, in send_packet > > : 'NoneType' object is not callable > > Unhandled exception in thread started by > > sys.excepthook is missing > > lost sys.stderr > > It seems a bug in the tool, to me, may be triggered by some MiTM TLS > interceptor. In the case it is specific to the streaming interface, > you may try a tool which does not use this interface (weaknesses can > be strengths :-) > creating-ripe-atlas-one-off-measurements-with-blaeu>: > > % blaeu-reach --probes 33717 9.9.9.9 > 1 probes reported > Test #13596250 done at 2018-05-30T06:46:37Z > Tests: 3 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), > average RTT: 130 ms > > Or with your measurement (which indeed worked): > > % blaeu-reach --measurement-ID 13595420 --probes 33717 9.9.9.9 > Warning: --probes ignored since we use probes from a previous measurement > Test #13595420 done at 2018-05-30T06:29:04Z > Tests: 3 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), > average RTT: 130 ms > > If you have time to test, tell me if it works better. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Sun Jun 3 14:46:22 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 3 Jun 2018 14:46:22 +0200 Subject: [atlas] CLI In-Reply-To: References: <20180529113624.g5f5nmj35nduotob@nic.fr> <20180530065248.n3rpy5utft25xema@sources.org> Message-ID: <20180603124622.4tk2ym4pb26mvhfm@sources.org> On Sun, Jun 03, 2018 at 04:53:36PM +0430, Milad Afshari wrote a message of 115 lines which said: > Thanks for your suggestion, I have installed the " blaeu" and It is working > better now. Since many people use the streaming interface without problems, I suspect a local MiTM TLS interceptor doing something nasty. From mir at ripe.net Mon Jun 4 11:48:20 2018 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 4 Jun 2018 11:48:20 +0200 Subject: [atlas] New on RIPE Labs: Sketching Connectivity Between Users In-Reply-To: References: Message-ID: <8c3065b1-36e2-e40f-f745-89a7b446e86d@ripe.net> On 02/06/2018 16:57, Randy Bush wrote: >>> We've been looking at user-to-user connections, based on RIPE Atlas >>> measurements and ISP market share estimates provided by the APNIC. >> /// eyeball > > btw, sorry to be picky. but those apnic data are mislabeled too often. fixed. > the article is a nice piece. an intuitive visualisation Thanks, Randy. Mirjam From gponikie at akamai.com Wed Jun 6 02:19:08 2018 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Wed, 6 Jun 2018 00:19:08 +0000 Subject: [atlas] Probe #32536 with incorrect location Message-ID: <362B2473-4179-44D1-BC1E-D450DF3BF1EB@akamai.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jterbeest at ripe.net Mon Jun 11 10:26:18 2018 From: jterbeest at ripe.net (Johan ter Beest) Date: Mon, 11 Jun 2018 10:26:18 +0200 Subject: [atlas] Probe #32536 with incorrect location In-Reply-To: <362B2473-4179-44D1-BC1E-D450DF3BF1EB@akamai.com> References: <362B2473-4179-44D1-BC1E-D450DF3BF1EB@akamai.com> Message-ID: <6060b661-ffc7-5f6f-065b-7871d75bd590@ripe.net> Hi Grzegorz, On 06/06/2018 02:19, Ponikierski, Grzegorz wrote: > > 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. > Thanks for reporting, I have checked the probe and based on what I found, changed the location to Bratislava, Slovakia. Kind regards, Johan ter Beest RIPE Atlas Team > > ? > > Regards, > > Grzegorz > > ? > > ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rm at romanrm.net Mon Jun 11 20:42:15 2018 From: rm at romanrm.net (Roman Mamedov) Date: Mon, 11 Jun 2018 23:42:15 +0500 Subject: [atlas] Running a probe behind a NAT66 Message-ID: <20180611234215.42000391@natsu> 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 From lorenzo at google.com Tue Jun 12 04:41:11 2018 From: lorenzo at google.com (Lorenzo Colitti) Date: Tue, 12 Jun 2018 11:41:11 +0900 Subject: [atlas] Running a probe behind a NAT66 In-Reply-To: <20180611234215.42000391@natsu> References: <20180611234215.42000391@natsu> Message-ID: On Tue, Jun 12, 2018 at 3:42 AM Roman Mamedov wrote: 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? Many would argue that the setup is already broken in many ways and that this is just one bit of breakage that you happened to notice. From jandrewartha at ccgs.wa.edu.au Tue Jun 12 04:43:58 2018 From: jandrewartha at ccgs.wa.edu.au (James Andrewartha) Date: Tue, 12 Jun 2018 10:43:58 +0800 Subject: [atlas] Running a probe behind a NAT66 In-Reply-To: References: <20180611234215.42000391@natsu> Message-ID: <87e1450f-b91f-2215-f85d-ce4afe75a3fe@ccgs.wa.edu.au> On 12/06/18 10:41, Lorenzo Colitti wrote: > On Tue, Jun 12, 2018 at 3:42 AM Roman Mamedov wrote: > 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? > > Many would argue that the setup is already broken in many ways and > that this is just one bit of breakage that you happened to notice. So what is your recommendation for IPv6 multi-homing without BGP? -- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877 From lorenzo at google.com Tue Jun 12 04:47:40 2018 From: lorenzo at google.com (Lorenzo Colitti) Date: Tue, 12 Jun 2018 11:47:40 +0900 Subject: [atlas] Running a probe behind a NAT66 In-Reply-To: <87e1450f-b91f-2215-f85d-ce4afe75a3fe@ccgs.wa.edu.au> References: <20180611234215.42000391@natsu> <87e1450f-b91f-2215-f85d-ce4afe75a3fe@ccgs.wa.edu.au> Message-ID: On Tue, Jun 12, 2018 at 11:44 AM James Andrewartha wrote: > > Many would argue that the setup is already broken in many ways and > > that this is just one bit of breakage that you happened to notice. > > So what is your recommendation for IPv6 multi-homing without BGP? For the home, homenet protocols. For small enterprises, draft-ietf-v6ops-conditional-ras, which is about to become an RFC. For larger enterprises, draft-ietf-rtgwg-enterprise-pa-multihoming . From jandrewartha at ccgs.wa.edu.au Tue Jun 12 05:13:24 2018 From: jandrewartha at ccgs.wa.edu.au (James Andrewartha) Date: Tue, 12 Jun 2018 11:13:24 +0800 Subject: [atlas] Running a probe behind a NAT66 In-Reply-To: References: <20180611234215.42000391@natsu> <87e1450f-b91f-2215-f85d-ce4afe75a3fe@ccgs.wa.edu.au> Message-ID: On 12/06/18 10:47, Lorenzo Colitti wrote: > On Tue, Jun 12, 2018 at 11:44 AM James Andrewartha > wrote: >>> Many would argue that the setup is already broken in many ways and >>> that this is just one bit of breakage that you happened to notice. >> >> So what is your recommendation for IPv6 multi-homing without BGP? > > For the home, homenet protocols. RFC7368? > For small enterprises, draft-ietf-v6ops-conditional-ras, which is > about to become an RFC. > For larger enterprises, draft-ietf-rtgwg-enterprise-pa-multihoming And what's the implementation support for these protocols like? Hmm, let's read draft-ietf-rtgwg-enterprise-pa-multihoming: > How a host should make good decisions about source address selection > in a multihomed site is not a solved problem. We do not attempt to > solve this problem in this document. Followed by a discussion on possible ways it might work if the routers can react to network changes by sending new RAs, which I love would to know if there are any implementations that can do this. -- James Andrewartha Network & Projects Engineer Christ Church Grammar School Claremont, Western Australia Ph. (08) 9442 1757 Mob. 0424 160 877 From lorenzo at google.com Tue Jun 12 05:19:57 2018 From: lorenzo at google.com (Lorenzo Colitti) Date: Tue, 12 Jun 2018 12:19:57 +0900 Subject: [atlas] Running a probe behind a NAT66 In-Reply-To: References: <20180611234215.42000391@natsu> <87e1450f-b91f-2215-f85d-ce4afe75a3fe@ccgs.wa.edu.au> Message-ID: On Tue, Jun 12, 2018 at 12:13 PM James Andrewartha < jandrewartha at ccgs.wa.edu.au> wrote: > Followed by a discussion on possible ways it might work if the routers > can react to network changes by sending new RAs, which I love would to > know if there are any implementations that can do this. > The more customers ask for it, the sooner and more widely it will be deployed. The alternative is increase costs to application developers by requiring them to implement complex and brittle NAT traversal code, and impose on users the resulting burden of flakier connectivity and the battery impact due to NAT keepalives. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Tue Jun 12 15:02:51 2018 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 12 Jun 2018 15:02:51 +0200 Subject: [atlas] Running a probe behind a NAT66 In-Reply-To: <20180611234215.42000391@natsu> References: <20180611234215.42000391@natsu> Message-ID: <5a5d3a7c-f390-61cc-00f2-773e749cae0e@ripe.net> On 2018/06/11 20:42 , Roman Mamedov wrote: > 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? > I started a TCP traceroute on your probe toward it's controller, but it consistently fails after hop 2. I have no idea if that is related to your NAT box. https://atlas.ripe.net/measurements/14364300/ In general it is worth noting that Atlas has support for IPv4 NAT, such as keeping track of the public address of a probe. This support in not implemented for IPv6. So if you put a probe behind some kind of IPv6 NAT, the results may be confusing to other Atlas users. Philip From bortzmeyer at nic.fr Tue Jun 12 15:06:45 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 12 Jun 2018 15:06:45 +0200 Subject: [atlas] No probes working today? Message-ID: <20180612130645.ywq5jel5ssmw7gsn@sources.org> DNS measurements don't start today, no probes are selected for a long time. See for instance (long delay) or (no probes) From robert at ripe.net Tue Jun 12 15:50:25 2018 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 12 Jun 2018 15:50:25 +0200 Subject: [atlas] No probes working today? In-Reply-To: <20180612130645.ywq5jel5ssmw7gsn@sources.org> References: <20180612130645.ywq5jel5ssmw7gsn@sources.org> Message-ID: On 2018-06-12 15:06, Stephane Bortzmeyer wrote: > DNS measurements don't start today, no probes are selected for a long > time. > > See for instance (long > delay) or > (no probes) Dear Stephane, The data storage backend had a few hickups today, meaning results were queued and served with a delay around 10:00, 11:30 and 13:30-15:00. No results were lost. The backend team is still investigating the cause for these. Sorry for the inconvenience this caused! Regards, Robert From bortzmeyer at nic.fr Tue Jun 12 15:54:44 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 12 Jun 2018 15:54:44 +0200 Subject: [atlas] No probes working today? In-Reply-To: References: <20180612130645.ywq5jel5ssmw7gsn@sources.org> Message-ID: <20180612135444.ncdp6xamj2vjvkjd@nic.fr> On Tue, Jun 12, 2018 at 03:50:25PM +0200, Robert Kisteleki wrote a message of 21 lines which said: > The data storage backend had a few hickups today, meaning results > were queued and served with a delay around 10:00, 11:30 and > 13:30-15:00. No results were lost. I confirm it now works. Thanks. From bortzmeyer at nic.fr Tue Jun 12 17:35:08 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 12 Jun 2018 17:35:08 +0200 Subject: [atlas] No probes working today? In-Reply-To: <20180612135444.ncdp6xamj2vjvkjd@nic.fr> References: <20180612130645.ywq5jel5ssmw7gsn@sources.org> <20180612135444.ncdp6xamj2vjvkjd@nic.fr> Message-ID: <20180612153508.hyrjgzlzmtgd3d77@nic.fr> On Tue, Jun 12, 2018 at 03:54:44PM +0200, Stephane Bortzmeyer wrote a message of 9 lines which said: > > The data storage backend had a few hickups today, meaning results > > were queued and served with a delay around 10:00, 11:30 and > > 13:30-15:00. No results were lost. > > I confirm it now works. Thanks. It seems it happens again "Total responsive: 0 Total allocated: 2 Total requested: 2" Good thing is that it forced me to make my code less brittle :-) From rm at romanrm.net Tue Jun 12 18:23:29 2018 From: rm at romanrm.net (Roman Mamedov) Date: Tue, 12 Jun 2018 21:23:29 +0500 Subject: [atlas] Running a probe behind a NAT66 In-Reply-To: <20180611234215.42000391@natsu> References: <20180611234215.42000391@natsu> Message-ID: <20180612212329.4828d92f@natsu> Hello, Sorry for the noise, it appears the issue was due to a local misconfiguration after all, the GUA IP used for NAT66 was getting removed and instantly readded back to its interface every time DHCPv6 client renewed its lease from the ISP, which was every 30 minutes. Not surprisingly that breaks all NAT66 mappings made from/to that IP. As also noted in my private E-Mail to Stephen, one issue highlighted here is the lack of notification about such issues with the probe. For instance I didn't notice that anything is wrong until almost a month later (and by then it was already difficult to pinpoint these issues to the configuration changes that I made earlier), as there is no E-Mail notification for probe connection flapping, only for 60+ minutes periods of disconnection. So perhaps it would be a good idea to consider adding more kinds of E-Mail notifications to Atlas in the future. If anyone is curious as to why NAT66 setup in the first place, my ISP only provides a /64, and that's already "spent" on my main primary VLAN. I don't want to subnet the /64 further and have to run DHCPv6 everywhere. For security reasons I want to place the probe into its own separate VLAN. So that one, as well as numerous other guest/VM/untrusted VLANs get their own 66:xxxx:/64s and are then NAT'ed into the router's own IPv6. Let me know if you have any better suggestions for these network conditions, aside from "Get a Different ISP" (only one ISP in my area provides IPv6) or "Demand More IPs" from the current ISP (very unlikely to be successful, they even allocate only /64s to business-class connections, and on residential those are also *dynamic*). -- With respect, Roman From robert at ripe.net Wed Jun 13 09:38:53 2018 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 13 Jun 2018 09:38:53 +0200 Subject: [atlas] Running a probe behind a NAT66 In-Reply-To: <20180612212329.4828d92f@natsu> References: <20180611234215.42000391@natsu> <20180612212329.4828d92f@natsu> Message-ID: Dear Roman, > As also noted in my private E-Mail to Stephen, one issue highlighted here is > the lack of notification about such issues with the probe. For instance I > didn't notice that anything is wrong until almost a month later (and by then > it was already difficult to pinpoint these issues to the configuration changes > that I made earlier), as there is no E-Mail notification for probe connection > flapping, only for 60+ minutes periods of disconnection. So perhaps it would > be a good idea to consider adding more kinds of E-Mail notifications to Atlas > in the future. You can set a pretty aggressive (down to 10 minutes) notification threshold on the probe status page. I do not recommend this in general, since it's going to be way too noisy, but it may come handy if you're testing something. Regards, Robert From romeo.zwart at ripe.net Thu Jun 14 17:20:15 2018 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Thu, 14 Jun 2018 17:20:15 +0200 Subject: [atlas] No probes working today? In-Reply-To: <20180612153508.hyrjgzlzmtgd3d77@nic.fr> References: <20180612130645.ywq5jel5ssmw7gsn@sources.org> <20180612135444.ncdp6xamj2vjvkjd@nic.fr> <20180612153508.hyrjgzlzmtgd3d77@nic.fr> Message-ID: Hi Stephane and all, As Robert mentioned here before, we have been seeing some issues on the Atlas backend systems these past days. It's an intermittent problem so finding the root cause has proven to be a bit of a challenge and we are still investigating it. We have a notice up where we will post updates: https://www.ripe.net/support/service-announcements/delays-in-ripe-atlas-measurement-result-processing To reassure you, there is no data lost because of these issues, but the delays are of course quite annoying, so we are investigating this problem actively at the moment. Apologies for the inconvenience. Romeo On 18/06/12 17:35 , Stephane Bortzmeyer wrote: > On Tue, Jun 12, 2018 at 03:54:44PM +0200, > Stephane Bortzmeyer wrote > a message of 9 lines which said: > >>> The data storage backend had a few hickups today, meaning results >>> were queued and served with a delay around 10:00, 11:30 and >>> 13:30-15:00. No results were lost. >> >> I confirm it now works. Thanks. > > It seems it happens again "Total responsive: 0 Total allocated: 2 > Total requested: 2" > > Good thing is that it forced me to make my code less brittle :-) > > > From adavies at ripe.net Fri Jun 15 11:11:09 2018 From: adavies at ripe.net (Alun Davies) Date: Fri, 15 Jun 2018 11:11:09 +0200 Subject: [atlas] New on RIPE Labs: 2018 Campaign to Sponsor 10 RIPE Atlas Anchors Message-ID: <1A0203B4-DFF4-4A37-AE50-926C0B53412A@ripe.net> 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-atlas-anchors Best regards, Alun Davies -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2607 bytes Desc: not available URL: From gdmr at inf.ed.ac.uk Fri Jun 15 11:48:49 2018 From: gdmr at inf.ed.ac.uk (George Ross) Date: Fri, 15 Jun 2018 10:48:49 +0100 Subject: [atlas] New on RIPE Labs: 2018 Campaign to Sponsor 10 RIPE Atlas Anchors In-Reply-To: Your message of "Fri, 15 Jun 2018 11:11:09 +0200." <1A0203B4-DFF4-4A37-AE50-926C0B53412A@ripe.net> Message-ID: <201806150948.w5F9mnfT008902@farg.inf.ed.ac.uk> > 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. As one of the recipients last year, can I just add that the whole process was extremely straightforward, and network traffic levels have basically been down in the noise, as you can see from the attached graph. Go for it. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -------------- next part -------------- A non-text attachment was scrubbed... Name: core3_79-0.png Type: image/png Size: 19254 bytes Desc: core3_79-0.png URL: -------------- next part -------------- George D M Ross MSc PhD CEng MBCS CITP University of Edinburgh, School of Informatics, Appleton Tower, 11 Crichton Street, Edinburgh, Scotland, EH8 9LE Mail: gdmr at inf.ed.ac.uk Voice: 0131 650 5147 PGP: 1024D/AD758CC5 B91E D430 1E0D 5883 EF6A 426C B676 5C2B AD75 8CC5 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From amreesh at afrinic.net Fri Jun 15 15:36:08 2018 From: amreesh at afrinic.net (Amreesh Phokeer) Date: Fri, 15 Jun 2018 17:36:08 +0400 Subject: [atlas] Detecting open resolvers with atlas In-Reply-To: References: Message-ID: <9E90471B-8E2E-418D-9908-0966F782E996@afrinic.net> Hi Eduardo, > On 2 Apr 2018, at 02:33, Eduardo Duarte wrote: > > I try to find in the RIPE Labs articles works around this problematic but didn't find anything. There was a work done by Luuk Hendriks so time back on IPv6 https://labs.ripe.net/Members/luuk_hendriks/finding-open-dns-resolvers-on-ipv6 Regards, Amreesh From compyblog at gmail.com Mon Jun 18 02:18:50 2018 From: compyblog at gmail.com (Andre Heinrichs) Date: Mon, 18 Jun 2018 02:18:50 +0200 Subject: [atlas] Probe offline, Network appears okay Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andi.meuli at gmail.com Mon Jun 18 08:40:52 2018 From: andi.meuli at gmail.com (Andi Meuli) Date: Mon, 18 Jun 2018 08:40:52 +0200 Subject: [atlas] Probe offline, Network appears okay In-Reply-To: Message-ID: 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 From jterbeest at ripe.net Mon Jun 18 08:52:35 2018 From: jterbeest at ripe.net (Johan ter Beest) Date: Mon, 18 Jun 2018 08:52:35 +0200 Subject: [atlas] Probe offline, Network appears okay In-Reply-To: References: Message-ID: <60c640aa-e2ec-0bbd-87b9-375a97512879@ripe.net> Hi Andi, On 18/06/2018 08:40, Andi Meuli wrote: > 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. If you look at the Status tab: https://atlas.ripe.net/probes/31884/#!tab-status you will see that the probe reports that the USB drive is corrupted. Hopefully, if you follow the procedure on that page, you can get the probe connected again. Kind regards, Johan ter Beest RIPE Atlas Team > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > From andi.meuli at gmail.com Mon Jun 18 11:10:44 2018 From: andi.meuli at gmail.com (Andi Meuli) Date: Mon, 18 Jun 2018 11:10:44 +0200 Subject: [atlas] Probe offline, Network appears okay In-Reply-To: <60c640aa-e2ec-0bbd-87b9-375a97512879@ripe.net> Message-ID: Hi Johan Ups, this is looking differently now. This morning, I saw on the status tab a hint about DNS resolving. Which caused me to switch the DNS server to 8.8.8.8 temporarily. Additionally the probe does not behave the same as it did this morning / yesterday evening. The LED indicating that it's running persistently from internal flash (1:on, 2:blink, 3-4: off, 5:on). This morning at least 3 was blinking. I tried this with a different external USB stick without success. Any other idea? Did my probe died? Is it possible to get a new one? Cheers, Andi Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From andi.meuli at gmail.com Mon Jun 18 11:27:08 2018 From: andi.meuli at gmail.com (Andi Meuli) Date: Mon, 18 Jun 2018 11:27:08 +0200 Subject: [atlas] Probe offline, Network appears okay In-Reply-To: Message-ID: 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 From the.lists at mgm51.com Mon Jun 18 16:22:48 2018 From: the.lists at mgm51.com (Mike) Date: Mon, 18 Jun 2018 10:22:48 -0400 Subject: [atlas] Probe offline, Network appears okay In-Reply-To: References: Message-ID: My probe went offline a bit after 13:00 EDT yesterday. It was back online this morning when I woke up. My home network was working fine. I suspect something else that resided beyond my control had issues. About the same time, the DNS server on my home network was logging DNS query errors for DNS servers on nlnetlabs.nl and rootcanary.net. Whether those errors were related or remarkably coincidental, I do not know. On 6/18/2018 5:27 AM, Andi Meuli wrote: > 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 > > From vnaumov at ripe.net Mon Jun 18 16:50:27 2018 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 18 Jun 2018 16:50:27 +0200 Subject: [atlas] Probe offline, Network appears okay In-Reply-To: References: Message-ID: <5bae441f-016d-7ff4-f9d8-0c7d9fb24439@ripe.net> Hi Mike, We had an firewall maintenance yesterday noon and it hit the probes with the resolver problem. Around 0800CEST the probes started reconnecting back. Sorry for the inconvenience and thanks a lot for reporting! wbr /vty On 6/18/18 4:22 PM, Mike wrote: > > My probe went offline a bit after 13:00 EDT yesterday. It was back > online this morning when I woke up. > > My home network was working fine. I suspect something else that resided > beyond my control had issues. > > About the same time, the DNS server on my home network was logging DNS > query errors for DNS servers on nlnetlabs.nl and rootcanary.net. > > Whether those errors were related or remarkably coincidental, I do not know. > > > > > On 6/18/2018 5:27 AM, Andi Meuli wrote: >> 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 >> >> > From the.lists at mgm51.com Mon Jun 18 17:23:19 2018 From: the.lists at mgm51.com (Mike) Date: Mon, 18 Jun 2018 11:23:19 -0400 Subject: [atlas] Probe offline, Network appears okay In-Reply-To: <5bae441f-016d-7ff4-f9d8-0c7d9fb24439@ripe.net> References: <5bae441f-016d-7ff4-f9d8-0c7d9fb24439@ripe.net> Message-ID: <4606b371-0bd4-53d7-88c7-dd2351cf0bb9@mgm51.com> Thank-you for the follow-up. :) On 6/18/2018 10:50 AM, Viktor Naumov wrote: > Hi Mike, > > We had an firewall maintenance yesterday noon and it hit the probes with > the resolver problem. Around 0800CEST the probes started reconnecting back. > > Sorry for the inconvenience and thanks a lot for reporting! > > wbr > /vty > > > On 6/18/18 4:22 PM, Mike wrote: >> >> My probe went offline a bit after 13:00 EDT yesterday. It was back >> online this morning when I woke up. >> >> My home network was working fine. I suspect something else that resided >> beyond my control had issues. >> >> About the same time, the DNS server on my home network was logging DNS >> query errors for DNS servers on nlnetlabs.nl and rootcanary.net. >> >> Whether those errors were related or remarkably coincidental, I do not know. >> >> >> >> >> On 6/18/2018 5:27 AM, Andi Meuli wrote: >>> 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 >>> >>> >> > > From guido.iaquinti at gmail.com Wed Jun 20 15:21:24 2018 From: guido.iaquinti at gmail.com (Guido Iaquinti) Date: Wed, 20 Jun 2018 15:21:24 +0200 Subject: [atlas] Error: Only anchors may be targeted. In-Reply-To: <670C3512-617B-4DCA-A195-6FE39488443C@bartelmess.io> Message-ID: +1 to all the above. With proper safeguards we could make the ATLAS network (and service) way more useful and interesting to use. I volunteer for any work necessary to make this happening. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From guido.iaquinti at gmail.com Mon Jun 25 15:10:07 2018 From: guido.iaquinti at gmail.com (Guido Iaquinti) Date: Mon, 25 Jun 2018 15:10:07 +0200 Subject: [atlas] Error: Only anchors may be targeted. In-Reply-To: <54f29c64-0f4a-ed5e-c1eb-1f99f101ff2c@greenweb.ir> Message-ID: I was discussing the above with a few friends and I understand that there might be some security related concerns but I think with a proper user policy and technical implementation they could be easily mitigated: - allow HTTP(s) queries only on '/' and without any args - global rate limit on Atlas based on domain. Example: top 1000 domains can get 100 req/s globally while everything else is throttled to 10 req/s (optional: site owners can override this value via `robots.txt` or something similar) Feedback and ideas are welcome! Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From bortzmeyer at nic.fr Mon Jun 25 15:32:00 2018 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 25 Jun 2018 15:32:00 +0200 Subject: [atlas] Error: Only anchors may be targeted. In-Reply-To: References: <54f29c64-0f4a-ed5e-c1eb-1f99f101ff2c@greenweb.ir> Message-ID: <20180625133200.vyw263rhf5hdxlhp@nic.fr> On Mon, Jun 25, 2018 at 03:10:07PM +0200, Guido Iaquinti wrote a message of 16 lines which said: > I was discussing the above with a few friends and I understand that > there might be some security related concerns but I think with a > proper user policy and technical implementation they could be easily mitigated: It is not purely technical. There is also an ethics problem as well Basically, in places where you can have trouble for your Internet activity, HTTP is often actually monitored (which is not the case with ICMP and DNS). > - allow HTTP(s) queries only on '/' and without any args > - global rate limit on Atlas based on domain. Example: top 1000 > domains can get 100 req/s globally while everything else is > throttled to 10 req/s (optional: site owners can override this > value via `robots.txt` or something similar) It solves the "RIPE Atlas probes as a dDoS botnet" issue (at the price of some complexity for Atlas) but not the ethical one. Imagine people asking a saudi probe to access From BECHA at ripe.net Thu Jun 28 16:11:57 2018 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 28 Jun 2018 16:11:57 +0200 Subject: [atlas] Error: Only anchors may be targeted. In-Reply-To: <20180625133200.vyw263rhf5hdxlhp@nic.fr> References: <54f29c64-0f4a-ed5e-c1eb-1f99f101ff2c@greenweb.ir> <20180625133200.vyw263rhf5hdxlhp@nic.fr> Message-ID: <6f160d3c-31a1-8f5f-bb46-0af26c68c798@ripe.net> Hi all, On 25/06/2018 15:32, Stephane Bortzmeyer wrote: > On Mon, Jun 25, 2018 at 03:10:07PM +0200, > Guido Iaquinti wrote > a message of 16 lines which said: > >> I was discussing the above with a few friends and I understand that >> there might be some security related concerns but I think with a >> proper user policy and technical implementation they could be easily mitigated: > > It is not purely technical. There is also an ethics problem as well > > Basically, in places where you can have trouble for your Internet > activity, HTTP is often actually monitored (which is not the case with > ICMP and DNS). Thanks Stephane! In addition to this , we have come up with a workaround: https://labs.ripe.net/Members/wilhelm/measuring-your-web-server-reachability-with-tcp-ping Please take a look, and see if this is useful for some of the items on your "wish list". Vesna From gponikie at akamai.com Fri Jun 29 18:57:30 2018 From: gponikie at akamai.com (Ponikierski, Grzegorz) Date: Fri, 29 Jun 2018 16:57:30 +0000 Subject: [atlas] More probes with incorrect location Message-ID: <2006C096-23EF-444B-B5AF-53A6F7AD5238@akamai.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From compyblog at gmail.com Fri Jun 29 20:19:45 2018 From: compyblog at gmail.com (Andre Heinrichs) Date: Fri, 29 Jun 2018 20:19:45 +0200 Subject: [atlas] again: Probe offline, network appears okay Message-ID: 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 From alcor at mailbox.org Fri Jun 29 23:56:17 2018 From: alcor at mailbox.org (Steffen Scholz) Date: Fri, 29 Jun 2018 23:56:17 +0200 Subject: [atlas] again: Probe offline, network appears okay In-Reply-To: Message-ID: 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 From afshar.milad89 at gmail.com Sat Jun 30 10:55:24 2018 From: afshar.milad89 at gmail.com (Milad Afshari) Date: Sat, 30 Jun 2018 08:55:24 +0000 Subject: [atlas] again: Probe offline, network appears okay In-Reply-To: References: Message-ID: Hi all, Just to confirm, I also have same problem. Probe ID: 32909 Regards Milad On Fri, Jun 29, 2018 at 9:56 PM Steffen Scholz wrote: > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dermh at web.de Sat Jun 30 11:52:38 2018 From: dermh at web.de (Michael H) Date: Sat, 30 Jun 2018 11:52:38 +0200 Subject: [atlas] again: Probe offline, network appears okay In-Reply-To: Message-ID: 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 From anandb at ripe.net Sat Jun 30 11:59:34 2018 From: anandb at ripe.net (Anand Buddhdev) Date: Sat, 30 Jun 2018 11:59:34 +0200 Subject: [atlas] Problems with the RIPE Atlas backend systems Message-ID: 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 From jterbeest at ripe.net Sat Jun 30 12:52:38 2018 From: jterbeest at ripe.net (Johan ter Beest) Date: Sat, 30 Jun 2018 12:52:38 +0200 Subject: [atlas] again: Probe offline, network appears okay In-Reply-To: References: Message-ID: <633f16d9-1666-1c24-0dff-c0331bc63cdd@ripe.net> Hi, On 30/06/2018 10:55, Milad Afshari wrote: > Hi all, > Just to confirm, I also have same problem. > Probe ID: 32909 > > Regards > Milad > > On Fri, Jun 29, 2018 at 9:56 PM Steffen Scholz > wrote: > > 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 > We're having some issues with our backend system? which explains these problems. We're currently processing the backlog of messages and your status should hopefully soon(ish) be correct again. As always, no data is being lost, it's just processing more slowly. Kind regards, Johan ter Beest RIPE Atlas Team > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at gim.li Sat Jun 30 13:19:06 2018 From: ripe at gim.li (Benoit Lelievre) Date: Sat, 30 Jun 2018 13:19:06 +0200 Subject: [atlas] Probe seems DoA Message-ID: 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 From cpetrie at ripe.net Sat Jun 30 16:33:08 2018 From: cpetrie at ripe.net (Colin Petrie) Date: Sat, 30 Jun 2018 16:33:08 +0200 Subject: [atlas] Problems with the RIPE Atlas backend systems In-Reply-To: References: Message-ID: <15a48b80-9034-2d76-07a6-eedc6625cfb4@ripe.net> Hello, We are currently experiencing data delays in RIPE Atlas - new measurement results may not be visible via the API until we finish processing the message backlogs. https://www.ripe.net/support/service-announcements/data-delays-in-ripe-atlas/ Apologies for any incovenience. Regards, Colin Petrie RIPE NCC On 30/06/2018 11:59, Anand Buddhdev wrote: > 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 >