From danny at danysek.cz Fri Aug 1 10:33:30 2014 From: danny at danysek.cz (Daniel Suchy) Date: Fri, 01 Aug 2014 10:33:30 +0200 Subject: [atlas] [ripe.net #1133019] Re: Your RIPE Atlas Probe (ID: 16784) is not connected to our network In-Reply-To: References: <20140718034027.4116.36417@janus.atlas.ripe.net> <53C8B106.4090607@danysek.cz> <53D7D9ED.7030206@danysek.cz> Message-ID: <53DB50DA.9030301@danysek.cz> It's surprising, that you can't manage probe remotelly when it isn't "connected" (even you can directly reach it on L3). Technically, probe runs on Linux, so you can have SSH daemon with restricted IP access running here (listenning daemon has minimal performance overhead) - by current "behavior" you simply loose any way to diagnose problem - and dependence of established tunnel is another layer, which can fail... As stated before - simple rebooting is just a *workaround* of any issue, not a solution (but it seems that's your basic recomendation). I think you should work on improvements on probe diagnostics in such cases - new hardware versions of probes seems to be more problematic compared to older probes, as I can see also on atlas mailing list. I remember, that I had to plug out/in USB flash as some step with probe before (also your recomended "solution"). Also on probe should run some kind of watchdog, which reboots probe in case of similar problem automatically - probably it doesn't run now... With regards, Daniel On 31.7.2014 17:31, Philip Homburg wrote: > Hi Daniel, > > On Tue Jul 29 19:29:20 2014, danny at danysek.cz wrote: >> What checks did you performed at your side before sending such email? >> You don't have any kind of "emenergency" probe management, like SSH >> shell access directly to the device? What do you see in *your* logs >> about affected probe before it was disconnected? > > The mail gets sent when the is not connected for some time. Nothing more. > > There are no open ports on the probes. The probe can only be controlled when it is connected. > > There is some evidence in the logs that there was already something wrong with the probe when it disconnected. Most likely there is something wrong with the filesystem on the USB flash drive, but that is hard to say. > > Philip > From rm at romanrm.net Fri Aug 1 10:41:18 2014 From: rm at romanrm.net (Roman Mamedov) Date: Fri, 1 Aug 2014 14:41:18 +0600 Subject: [atlas] [ripe.net #1133019] Re: Your RIPE Atlas Probe (ID: 16784) is not connected to our network In-Reply-To: <53DB50DA.9030301@danysek.cz> References: <20140718034027.4116.36417@janus.atlas.ripe.net> <53C8B106.4090607@danysek.cz> <53D7D9ED.7030206@danysek.cz> <53DB50DA.9030301@danysek.cz> Message-ID: <20140801144118.0c6feb6c@natsu> On Fri, 01 Aug 2014 10:33:30 +0200 Daniel Suchy wrote: > It's surprising, that you can't manage probe remotelly when it isn't > "connected" (even you can directly reach it on L3). Technically, probe > runs on Linux, so you can have SSH daemon with restricted IP access So do you suggest that everyone has to configure a port 22 portforward from their router/CPE to the probe? Or place the probe on its own dedicated public IP address? Nope, neither is going to happen, not feasible in perhaps 90+% of cases. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From philip.homburg at ripe.net Fri Aug 1 10:51:11 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 01 Aug 2014 10:51:11 +0200 Subject: [atlas] [ripe.net #1133019] Re: Your RIPE Atlas Probe (ID: 16784) is not connected to our network In-Reply-To: <53DB50DA.9030301@danysek.cz> References: <20140718034027.4116.36417@janus.atlas.ripe.net> <53C8B106.4090607@danysek.cz> <53D7D9ED.7030206@danysek.cz> <53DB50DA.9030301@danysek.cz> Message-ID: <53DB54FF.10208@ripe.net> Hi Daniel, On 2014/08/01 10:33 , Daniel Suchy wrote: > It's surprising, that you can't manage probe remotelly when it isn't > "connected" (even you can directly reach it on L3). Technically, probe > runs on Linux, so you can have SSH daemon with restricted IP access > running here (listenning daemon has minimal performance overhead) - by > current "behavior" you simply loose any way to diagnose problem - and > dependence of established tunnel is another layer, which can fail... Always having an ssh port open is a security risk. And it doesn't do anything for probes behind NAT. > As stated before - simple rebooting is just a *workaround* of any issue, > not a solution (but it seems that's your basic recomendation). Yes. Because the behavior of your probe is very rare. You can't just code for every special situation. > I think you should work on improvements on probe diagnostics in such > cases - new hardware versions of probes seems to be more problematic > compared to older probes, as I can see also on atlas mailing list. I > remember, that I had to plug out/in USB flash as some step with probe > before (also your recomended "solution"). Getting the probe to reflash its USB stick is a cost effective solution from our point of view. It usually solves problems without requiring any effort from our site. > Also on probe should run some kind of watchdog, which reboots probe in > case of similar problem automatically - probably it doesn't run now... The version 1 and 2 probes have a watchdog. That was an endless sort of trouble. Note, the probes are run in such a way that it takes a minimal amount of time to manage a network that consists of thousands of probes. If we spot any patterns that we try to accommodate that. However, some probes just behave in unexpected ways. We can't really do much about that. Philip From gert at space.net Fri Aug 1 11:05:56 2014 From: gert at space.net (Gert Doering) Date: Fri, 1 Aug 2014 11:05:56 +0200 Subject: [atlas] [ripe.net #1133019] Re: Your RIPE Atlas Probe (ID: 16784) is not connected to our network In-Reply-To: <53DB50DA.9030301@danysek.cz> References: <20140718034027.4116.36417@janus.atlas.ripe.net> <53C8B106.4090607@danysek.cz> <53D7D9ED.7030206@danysek.cz> <53DB50DA.9030301@danysek.cz> Message-ID: <20140801090556.GG51793@Space.Net> Hi, On Fri, Aug 01, 2014 at 10:33:30AM +0200, Daniel Suchy wrote: > It's surprising, that you can't manage probe remotelly when it isn't > "connected" (even you can directly reach it on L3). Technically, probe > runs on Linux, so you can have SSH daemon with restricted IP access > running here (listenning daemon has minimal performance overhead) - by > current "behavior" you simply loose any way to diagnose problem - and > dependence of established tunnel is another layer, which can fail... This is intentional and welcome. The probes are not devices that you talk to, secure against intrusions, etc. - they are satellites that are part of a measurement system. (The way the probes signal problems by issueing special DNS requests could be documented, though :) ). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From robert at ripe.net Fri Aug 1 11:10:33 2014 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 01 Aug 2014 11:10:33 +0200 Subject: [atlas] [ripe.net #1133019] Re: Your RIPE Atlas Probe (ID: 16784) is not connected to our network In-Reply-To: <20140801090556.GG51793@Space.Net> References: <20140718034027.4116.36417@janus.atlas.ripe.net> <53C8B106.4090607@danysek.cz> <53D7D9ED.7030206@danysek.cz> <53DB50DA.9030301@danysek.cz> <20140801090556.GG51793@Space.Net> Message-ID: <53DB5989.8060302@ripe.net> > (The way the probes signal problems by issueing special DNS requests > could be documented, though :) ). One can argue if we can/should do better, but in the meantime, the "network information" tab of the probe status page has the following: "SOS History (Showing only the last 25) This probe probably last rebooted on 2014-xxx The probe sends a message using DNS queries every time it tries to reconnect to the system. Below you can find a list of the most recent messages. The "power-up time" column shows the approximate "powered-up time" of the probe at the time of sending the message. " Cheers, Robert From alexsaroyan at gmail.com Fri Aug 1 11:17:40 2014 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Fri, 1 Aug 2014 13:17:40 +0400 Subject: [atlas] [ripe.net #1133019] Re: Your RIPE Atlas Probe (ID: 16784) is not connected to our network In-Reply-To: <53DB5989.8060302@ripe.net> References: <20140718034027.4116.36417@janus.atlas.ripe.net> <53C8B106.4090607@danysek.cz> <53D7D9ED.7030206@danysek.cz> <53DB50DA.9030301@danysek.cz> <20140801090556.GG51793@Space.Net> <53DB5989.8060302@ripe.net> Message-ID: Probes can request some https URL, asking for commands(say every 5 minutes), and if there is need to reboot the probe appropriate command can be replied to appropriate probe. This does not need an open SSH, or port forwarding. Does not affect security but accomplishes goal of rebooting probes remotely (either individually or by groups of probes) or sending to probes other commands. Regards. /Alex On Fri, Aug 1, 2014 at 1:10 PM, Robert Kisteleki wrote: > > > (The way the probes signal problems by issueing special DNS requests > > could be documented, though :) ). > > One can argue if we can/should do better, but in the meantime, the "network > information" tab of the probe status page has the following: > > "SOS History (Showing only the last 25) > > This probe probably last rebooted on 2014-xxx > > The probe sends a message using DNS queries every time it tries to > reconnect > to the system. Below you can find a list of the most recent messages. The > "power-up time" column shows the approximate "powered-up time" of the probe > at the time of sending the message. " > > > Cheers, > Robert > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Fri Aug 1 11:23:05 2014 From: gert at space.net (Gert Doering) Date: Fri, 1 Aug 2014 11:23:05 +0200 Subject: [atlas] [ripe.net #1133019] Re: Your RIPE Atlas Probe (ID: 16784) is not connected to our network In-Reply-To: <53DB5989.8060302@ripe.net> References: <20140718034027.4116.36417@janus.atlas.ripe.net> <53C8B106.4090607@danysek.cz> <53D7D9ED.7030206@danysek.cz> <53DB50DA.9030301@danysek.cz> <20140801090556.GG51793@Space.Net> <53DB5989.8060302@ripe.net> Message-ID: <20140801092305.GH51793@Space.Net> Hi, On Fri, Aug 01, 2014 at 11:10:33AM +0200, Robert Kisteleki wrote: > > > (The way the probes signal problems by issueing special DNS requests > > could be documented, though :) ). > > One can argue if we can/should do better, but in the meantime, the "network > information" tab of the probe status page has the following: > > "SOS History (Showing only the last 25) > > This probe probably last rebooted on 2014-xxx Oh, cool. Seems I need to check that stuff more often :-) - thanks for adding it. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From jonas at connect.ax Fri Aug 1 21:14:14 2014 From: jonas at connect.ax (=?iso-8859-1?Q?Jonas_Bystr=F6m?=) Date: Fri, 1 Aug 2014 21:14:14 +0200 Subject: [atlas] Static IPv6 problem Message-ID: <62A6CAA9-967D-45C1-A710-479ACE4EDB18@connect.ax> Hi, I have a problem when i try to set a Static IPv6 adress i get on my probe. I get: No more than 3 static DNS values may be used at any given time for either IPv4 or IPv6. I have set: 2001:4860:4860::8888 and 2001:4860:4860::8844 as DNS. What should i do to get this to work? Regards Jonas Bystr?m -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ondrej.Caletka at cesnet.cz Fri Aug 1 22:57:29 2014 From: Ondrej.Caletka at cesnet.cz (=?windows-1250?Q?Ond=F8ej_Caletka?=) Date: Fri, 01 Aug 2014 22:57:29 +0200 Subject: [atlas] Static IPv6 problem In-Reply-To: <62A6CAA9-967D-45C1-A710-479ACE4EDB18@connect.ax> References: <62A6CAA9-967D-45C1-A710-479ACE4EDB18@connect.ax> Message-ID: <53DBFF39.2040608@cesnet.cz> Dne 1.8.2014 21:14, Jonas Bystr?m napsal(a): > Hi, > > I have a problem when i try to set a Static IPv6 adress i get on my > probe. I get: > > * No more than 3 static DNS values may be used at any given time for > either IPv4 or IPv6. > > I have set: 2001:4860:4860::8888 and 2001:4860:4860::8844 as DNS. > What should i do to get this to work? > I think it means that the _total_ number of DNS servers, IPv4 and IPv6 must be no more than 3. It looks like C library limit. Perhaps there are already two IPv4 DNS servers set up. In case your probe is dual-stacked, there's no need to fill in any IPv6 DNS server. Regards, Ond?ej Caletka -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3248 bytes Desc: Elektronicky podpis S/MIME URL: From max+ratlml at grobecker.info Sat Aug 2 11:43:05 2014 From: max+ratlml at grobecker.info (Max Grobecker) Date: Sat, 02 Aug 2014 11:43:05 +0200 Subject: [atlas] Measurements can't be stopped Message-ID: <53DCB2A9.9080406@grobecker.info> Hi, I tried to stop a measurement, which was defined as "end never". In order to stop the measurement I opened it, clicked "Settings" and unchecked "End never". But regardless what I choose as "End at" time, it always gets refused with the hint that I need to enter a valid date. For example, [ 2014-08-03 ] [ 00:00 ] is refused as invalid date/time. Is there any option to stop this measurements? Thank you! -- Greetings from Wuppertal, Germany Max Grobecker From max+ratlml at grobecker.info Sat Aug 2 11:56:58 2014 From: max+ratlml at grobecker.info (Max Grobecker) Date: Sat, 02 Aug 2014 11:56:58 +0200 Subject: [atlas] Measurements can't be stopped In-Reply-To: References: <53DCB2A9.9080406@grobecker.info> Message-ID: <53DCB5EA.4090103@grobecker.info> Hi, YEAH! That did the trick ;-) I've never right-clicked on these items before... Thank you! Greetings from Wuppertal, Germany Max Grobecker Am 02.08.2014 um 11:52 schrieb I?igo Ortiz de Urbina: > Hi Max, > > On Sat, Aug 2, 2014 at 11:43 AM, Max Grobecker > wrote: >> Hi, >> >> I tried to stop a measurement, which was defined as "end never". >> >> In order to stop the measurement I opened it, clicked "Settings" and >> unchecked "End never". >> But regardless what I choose as "End at" time, it always gets refused with >> the hint that I need to enter a valid date. >> For example, [ 2014-08-03 ] [ 00:00 ] is refused as invalid date/time. >> >> Is there any option to stop this measurements? > > You can stop measurements by right-clicking on them, and then > selecting Stop. The options that you should see after right-clicking > are: Archive, Settings and Stop. > > HTH, > >> Thank you! >> >> -- >> Greetings from Wuppertal, Germany >> Max Grobecker >> > > > From Simon.Dickhoven at dg-i.net Fri Aug 1 23:30:45 2014 From: Simon.Dickhoven at dg-i.net (Simon Dickhoven) Date: Fri, 1 Aug 2014 21:30:45 +0000 Subject: [atlas] Static IPv6 problem In-Reply-To: <53DBFF39.2040608@cesnet.cz> References: <62A6CAA9-967D-45C1-A710-479ACE4EDB18@connect.ax>, <53DBFF39.2040608@cesnet.cz> Message-ID: The wording is ambiguous. I have the same problem. Unfortunately, you can't leave the IPv6 DNS servers blank. The UI complains that you should have at least one. But even if you only configure two IPv4 DNS servers, you can't configure one IPv6 DNS server (which would bring the total to 3). Apparently it's a bug in the UI that should be fixed after the next deployment on Wednesday. - Simon > On 01.08.2014, at 22:58, "Ond?ej Caletka" wrote: > > Dne 1.8.2014 21:14, Jonas Bystr?m napsal(a): >> Hi, >> >> I have a problem when i try to set a Static IPv6 adress i get on my >> probe. I get: >> >> * No more than 3 static DNS values may be used at any given time for >> either IPv4 or IPv6. >> >> I have set: 2001:4860:4860::8888 and 2001:4860:4860::8844 as DNS. >> What should i do to get this to work? > > I think it means that the _total_ number of DNS servers, IPv4 and IPv6 > must be no more than 3. It looks like C library limit. Perhaps there are > already two IPv4 DNS servers set up. > > In case your probe is dual-stacked, there's no need to fill in any IPv6 > DNS server. > > Regards, > Ond?ej Caletka > From davidp at preshweb.co.uk Wed Aug 6 12:02:17 2014 From: davidp at preshweb.co.uk (David Precious) Date: Wed, 6 Aug 2014 11:02:17 +0100 Subject: [atlas] Probe 2092 shown as offline for a month Message-ID: <20140806110217.6965ebe9@columbia> Hi there, My v1 probe #2092 has been showing as offline for a month, despite being powered up and pinging. Yesterday I power-cycled it, and it came back up and answers pings again, but the Atlas control panel still shows it as disconnected. Is there any troubleshooting I can do to get more information? I've verified that I can ping it from my internal network. There's no egress filtering which would be blocking it from talking outbound. I've just had my router log new outbound connections then power-cycled the probe again. I saw it successfully obtain an IP via DHCP (10:13:21), then 31 minutes later, connected to oneill.atlas.ripe.net (193.0.19.12) on port 443 (10:44:50) (UK times). I have verified that another box on the same network can connect to that IP & port: [davidp at columbia:~]$ telnet 193.0.19.12 443 Trying 193.0.19.12... Connected to 193.0.19.12. Escape character is '^]'. SSH-2.0-OpenSSH_5.3 Anything else I can do to provide more useful info? Cheers Dave P -- David Precious ("bigpresh") http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github From philip.homburg at ripe.net Wed Aug 6 12:24:45 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 06 Aug 2014 12:24:45 +0200 Subject: [atlas] Probe 2092 shown as offline for a month In-Reply-To: <20140806110217.6965ebe9@columbia> References: <20140806110217.6965ebe9@columbia> Message-ID: <53E2026D.4050009@ripe.net> Hi Dave, On 2014/08/06 12:02 , David Precious wrote: > I've just had my router log new outbound connections then power-cycled > the probe again. I saw it successfully obtain an IP via DHCP > (10:13:21), then 31 minutes later, connected to oneill.atlas.ripe.net > (193.0.19.12) on port 443 (10:44:50) (UK times). Any chance there might be an issue with the DNS resolver that is used by the probe? Philip From davidp at preshweb.co.uk Wed Aug 6 13:51:31 2014 From: davidp at preshweb.co.uk (David Precious) Date: Wed, 6 Aug 2014 12:51:31 +0100 Subject: [atlas] Probe 2092 shown as offline for a month In-Reply-To: <53E2026D.4050009@ripe.net> References: <20140806110217.6965ebe9@columbia> <53E2026D.4050009@ripe.net> Message-ID: <20140806125131.6faafa91@columbia> On Wed, 06 Aug 2014 12:24:45 +0200 Philip Homburg wrote: > On 2014/08/06 12:02 , David Precious wrote: > > I've just had my router log new outbound connections then > > power-cycled the probe again. I saw it successfully obtain an IP > > via DHCP (10:13:21), then 31 minutes later, connected to > > oneill.atlas.ripe.net (193.0.19.12) on port 443 (10:44:50) (UK > > times). > > Any chance there might be an issue with the DNS resolver that is used > by the probe? The DHCP server gives out the IP of my internal gateway/router (a Linux box) as the DNS server to use; that's the box all other devices on my network use, too, so if it had problems I'd certainly have noticed! Presumably the probe attemptign to connect that one observed time means it resolved that hostname, no? From philip.homburg at ripe.net Wed Aug 6 14:20:34 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 06 Aug 2014 14:20:34 +0200 Subject: [atlas] Probe 2092 shown as offline for a month In-Reply-To: <20140806125131.6faafa91@columbia> References: <20140806110217.6965ebe9@columbia> <53E2026D.4050009@ripe.net> <20140806125131.6faafa91@columbia> Message-ID: <53E21D92.9020902@ripe.net> On 2014/08/06 13:51 , David Precious wrote: > The DHCP server gives out the IP of my internal gateway/router (a Linux > box) as the DNS server to use; that's the box all other devices on my > network use, too, so if it had problems I'd certainly have noticed! > > Presumably the probe attemptign to connect that one observed time means > it resolved that hostname, no? I changed something in the probe setting to make it connect even if DNS resolving doesn't work. When that takes effect it will be possible to figure out what is going on exactly. Philip From davidp at preshweb.co.uk Wed Aug 6 14:24:17 2014 From: davidp at preshweb.co.uk (David Precious) Date: Wed, 6 Aug 2014 13:24:17 +0100 Subject: [atlas] Probe 2092 shown as offline for a month In-Reply-To: <53E21D92.9020902@ripe.net> References: <20140806110217.6965ebe9@columbia> <53E2026D.4050009@ripe.net> <20140806125131.6faafa91@columbia> <53E21D92.9020902@ripe.net> Message-ID: <20140806132417.5cb288f7@columbia> On Wed, 06 Aug 2014 14:20:34 +0200 Philip Homburg wrote: > On 2014/08/06 13:51 , David Precious wrote: > > The DHCP server gives out the IP of my internal gateway/router (a > > Linux box) as the DNS server to use; that's the box all other > > devices on my network use, too, so if it had problems I'd certainly > > have noticed! > > > > Presumably the probe attemptign to connect that one observed time > > means it resolved that hostname, no? > > I changed something in the probe setting to make it connect even if > DNS resolving doesn't work. When that takes effect it will be > possible to figure out what is going on exactly. I see a connection now. In digging around more to get more logs of what's going on, I think I found the culprit: for security, I'd denied the probe from talking to my home server/gateway (but maintaining forwarding to elsewhere) as it has no business talking to that box (or anything else internal). However - that also stops it doing DNS from that same box - d'oh! In other words, looks like I was being an idiot and the problem was at this end! Thanks for your assistance - will keep an eye on the Atlas control panel to see it appear online. -- David Precious ("bigpresh") http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github From Ondrej.Caletka at cesnet.cz Mon Aug 11 15:06:16 2014 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?B?T25kxZllaiBDYWxldGth?=) Date: Mon, 11 Aug 2014 15:06:16 +0200 Subject: [atlas] Probe suddenly lost IPv6 connectivity Message-ID: <53E8BFC8.1070107@cesnet.cz> Hi, strange thing happened today. My probe v2 #3467 suddenly lost IPv6 connectivity and reconnected to the control server using IPv4. The probe does not even respond to ping6 ff02::1%eth1 sent from the router. I wonder what could cause such behavior. I will try to reboot the probe once I'll reach it. -- Ond?ej Caletka -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5563 bytes Desc: Elektronicky podpis S/MIME URL: From Ondrej.Caletka at cesnet.cz Mon Aug 11 16:47:25 2014 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?B?T25kxZllaiBDYWxldGth?=) Date: Mon, 11 Aug 2014 16:47:25 +0200 Subject: [atlas] Probe suddenly lost IPv6 connectivity In-Reply-To: <53E8BFC8.1070107@cesnet.cz> References: <53E8BFC8.1070107@cesnet.cz> Message-ID: <53E8D77D.7050904@cesnet.cz> Dne 11.8.2014 15:06, Ond?ej Caletka napsal(a): > Hi, > > strange thing happened today. My probe v2 #3467 suddenly lost IPv6 > connectivity and reconnected to the control server using IPv4. The probe > does not even respond to ping6 ff02::1%eth1 sent from the router. > > I wonder what could cause such behavior. I will try to reboot the probe > once I'll reach it. Hi again, at 16:09, the probe started to respond to ping6 again. Strange. -- Ond?ej Caletka -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5563 bytes Desc: Elektronicky podpis S/MIME URL: From philip.homburg at ripe.net Mon Aug 11 17:02:19 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 11 Aug 2014 17:02:19 +0200 Subject: [atlas] Probe suddenly lost IPv6 connectivity In-Reply-To: <53E8D77D.7050904@cesnet.cz> References: <53E8BFC8.1070107@cesnet.cz> <53E8D77D.7050904@cesnet.cz> Message-ID: <53E8DAFB.60508@ripe.net> On 2014/08/11 16:47 , Ond?ej Caletka wrote: > Dne 11.8.2014 15:06, Ond?ej Caletka napsal(a): >> Hi, >> >> strange thing happened today. My probe v2 #3467 suddenly lost IPv6 >> connectivity and reconnected to the control server using IPv4. The probe >> does not even respond to ping6 ff02::1%eth1 sent from the router. >> >> I wonder what could cause such behavior. I will try to reboot the probe >> once I'll reach it. > > Hi again, > > at 16:09, the probe started to respond to ping6 again. Strange. According to our logs your probe lost its IPv6 address around 11:43 UTC and got it again around 14:10 UTC. The most likely cause is that the probe didn't receive and router advertisements during that period. The probe lost its default route around 10:19 UTC. There is however the issue that the Linux kernel on the v1 and v2 probes has a bug that it may get in a mode where it doesn't receive router advertisement multicasts anymore. So if it happens again, it may be worth replacing the probe with a v3 probe. Philip From BECHA at ripe.net Tue Aug 12 13:53:57 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 12 Aug 2014 13:53:57 +0200 Subject: [atlas] Upcoming "Measurements Tools" Workshop for LIRs: 19 September, in Amsterdam Message-ID: <53EA0055.3000608@ripe.net> Dear colleagues, Training Services, RIPEstat/RIPE Atlas developers and me will be giving a "Measurements Tools" Workshop on 19 September, in Amsterdam. Registration is possible for members of RIPE NCC via LIR Portal: https://lirportal.ripe.net/training/courses Below is the preliminary information about the workshop. If you know people who would be interested, please forward this to them. Regards, Vesna Target audience: LIRs (RIPE NCC members), network operators Goal of the Measurements Tools Workshop is to convey the benefits that the network operators can gain from using RIPE NCC tools, such as RIPEstat and RIPE Atlas - through practical exercises and hands-on approach. Prerequisites: RIPE NCC Access account; general knowledge about IP networking, DNS and BGP, as well as of one/any programming language. Workshop overview: RIPEstat topics: Basic: 1) finding the information about IP resources 2) comparing resources 3) finding anti-abuse information Advanced: embedding the widget using BGplay using command-line interface analysing events (examples of uses cases) personalizing RIPEstat RIPE Atlas topics: Basic: 1) creating a measurement 2) looking-up measurements data and analyzing the data 3) monitoring: setting-up status checks Advanced: member-specific services use cases by other people analysing information in Internet Traffic Maps take part in the community: share your code, distribute the probes, install anchors? From robert at ripe.net Wed Aug 13 15:09:24 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 13 Aug 2014 15:09:24 +0200 Subject: [atlas] Current crediting issues Message-ID: <53EB6384.4030309@ripe.net> Dear All, We have reports of the Atlas billing process doing strange things at the moment. We're investigating these and will get back to you with more information. Regards, Robert From james.sink at freedomvoice.com Wed Aug 13 18:15:45 2014 From: james.sink at freedomvoice.com (James Sink) Date: Wed, 13 Aug 2014 16:15:45 +0000 Subject: [atlas] atlas on a public subnet Message-ID: Hello all, I just received my atlas probe and am about to deploy it. However I have a question about the subnet I am going to place it it on. Is it safe to put it on an unfiltered public ip? If not what ACL should I place on the interface? Thanks --- James Sink Network Engineer P: 800-477-1477 x: 813 From robert at ripe.net Wed Aug 13 20:45:56 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 13 Aug 2014 20:45:56 +0200 Subject: [atlas] Current crediting issues In-Reply-To: <53EB6384.4030309@ripe.net> References: <53EB6384.4030309@ripe.net> Message-ID: <53EBB264.8000609@ripe.net> On 2014.08.13. 15:09, Robert Kisteleki wrote: > Dear All, > > We have reports of the Atlas billing process doing strange things at the > moment. We're investigating these and will get back to you with more > information. > > Regards, > Robert Update: we can confirm that there was an overcharging issue this afternoon. For many measurements the system billed (way) more than it should have and as a consequence some measurements have been stopped. We believe we've compensated for these losses -- but if you believe you have been overcharged and this was not corrected, then please let us know at the usual service address: atlas at ripe.net We'll look into restarting the billing procedure as well as the automatically stopped measurements tomorrow. Apologies for the inconvenience this may have caused. Regards, Robert From robert at ripe.net Thu Aug 14 09:27:04 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 14 Aug 2014 09:27:04 +0200 Subject: [atlas] atlas on a public subnet In-Reply-To: References: Message-ID: <53EC64C8.7050105@ripe.net> Hi, On 2014.08.13. 18:15, James Sink wrote: > > Hello all, > I just received my atlas probe and am about to deploy it. > However I have a question about the subnet I am going to place it it on. > Is it safe to put it on an unfiltered public ip? That depends on your definition of "safe" :-) The probe does not have any open ports, it only makes outgoing connections. This helps a lot being safe. > If not what ACL should I place on the interface? There's no problem with this. If you want to do this, then make sure all outgoing connections, as well as replies to these packets, can make it through. The probes work well behind NATs too, which have very similar effects in this regard. Regards, Robert > Thanks > > --- > > James Sink > Network Engineer > P: 800-477-1477 x: 813 > > > > From robert at ripe.net Thu Aug 14 14:43:47 2014 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 14 Aug 2014 14:43:47 +0200 Subject: [atlas] Current crediting issues In-Reply-To: <53EBB264.8000609@ripe.net> References: <53EB6384.4030309@ripe.net> <53EBB264.8000609@ripe.net> Message-ID: <53ECAF03.3040205@ripe.net> Dear RIPE Atlas users, Update: the system is back to normal again, and we believe all automatically stopped measurements have been restarted. Please let us know at the usual service address atlas at ripe.net if you have any further questions. Again, apologies for the inconvenience this may have caused. Regards, Robert From james.sink at freedomvoice.com Thu Aug 14 19:17:18 2014 From: james.sink at freedomvoice.com (James Sink) Date: Thu, 14 Aug 2014 17:17:18 +0000 Subject: [atlas] atlas on a public subnet In-Reply-To: <53EC64C8.7050105@ripe.net> References: <53EC64C8.7050105@ripe.net> Message-ID: <6edc7537ba604774931f7c6e7f38ab35@BL2PR08MB148.namprd08.prod.outlook.com> Thanks! -James -----Original Message----- From: Robert Kisteleki [mailto:robert at ripe.net] Sent: Thursday, August 14, 2014 12:27 AM To: James Sink; ripe-atlas at ripe.net Subject: Re: [atlas] atlas on a public subnet Hi, On 2014.08.13. 18:15, James Sink wrote: > > Hello all, > I just received my atlas probe and am about to deploy it. > However I have a question about the subnet I am going to place it it on. > Is it safe to put it on an unfiltered public ip? That depends on your definition of "safe" :-) The probe does not have any open ports, it only makes outgoing connections. This helps a lot being safe. > If not what ACL should I place on the interface? There's no problem with this. If you want to do this, then make sure all outgoing connections, as well as replies to these packets, can make it through. The probes work well behind NATs too, which have very similar effects in this regard. Regards, Robert > Thanks > > --- > > James Sink > Network Engineer > P: 800-477-1477 x: 813 > > > > From gboonie at gmail.com Thu Aug 14 19:39:31 2014 From: gboonie at gmail.com (gboonie) Date: Thu, 14 Aug 2014 19:39:31 +0200 Subject: [atlas] measurment with endtime - faulty date Message-ID: <53ECF453.4040900@gmail.com> Hi, I noticed the last few days that when I create a new measurement with a end date and time next week that I get a failure message on the next screen. --- Your measurement will start ASAP. Your measurement will end at: Y-8-16 0:i UTC. and in the next screen: Enter a valid date/time. --- What I selected was: 2014-08-16 00:45 Multiple tests on 2 different Win7 PCs give the same result. Regards, Dave From bjonglez at illyse.org Thu Aug 14 23:15:10 2014 From: bjonglez at illyse.org (Baptiste Jonglez) Date: Thu, 14 Aug 2014 23:15:10 +0200 Subject: [atlas] Probe on a /31 or /32 IPv4 network Message-ID: <20140814211510.GC1716@illyse.org> Hi, We would like to deploy our Atlas probe on a separate L2 network, but without having to spend 4 IPv4 addresses (i.e. a /30 network). Using a /31 would be nice, but the web UI doesn't allow it as static IPv4 configuration ("The Gateway address should be different from the ending network address"). Would it be possible to allow /31 in the web UI? I believe the probes themselves support it. Even nicer would be support for /32 networks, even though it is perhaps less usual. This can easily be done with iproute2 on Linux, assuming the probe is 192.0.2.48/32 and its gateway is 192.0.2.1: ip addr add 192.0.2.48/32 dev eth0 ip route add 192.0.2.1/32 dev eth0 ip route add default via 192.0.2.1 or even shorter: ip addr add 192.0.2.48/32 dev eth0 ip route add default via 192.0.2.1 onlink dev eth0 Using a gateway that is not on the same subnet doesn't sound very nice, but again, the goal is to avoid wasting precious IPv4 space. Thanks, Baptiste -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From philip.homburg at ripe.net Thu Aug 14 23:41:07 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 14 Aug 2014 23:41:07 +0200 Subject: [atlas] Probe on a /31 or /32 IPv4 network In-Reply-To: <20140814211510.GC1716@illyse.org> References: <20140814211510.GC1716@illyse.org> Message-ID: <53ED2CF3.8090606@ripe.net> On 2014/08/14 23:15 , Baptiste Jonglez wrote: > Even nicer would be support for /32 networks, even though it is perhaps > less usual. This can easily be done with iproute2 on Linux, assuming the > probe is 192.0.2.48/32 and its gateway is 192.0.2.1: Why not just fool the probe and tell it is on a /24? Philip From swmike at swm.pp.se Fri Aug 15 06:23:09 2014 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 15 Aug 2014 06:23:09 +0200 (CEST) Subject: [atlas] Probe on a /31 or /32 IPv4 network In-Reply-To: <20140814211510.GC1716@illyse.org> References: <20140814211510.GC1716@illyse.org> Message-ID: On Thu, 14 Aug 2014, Baptiste Jonglez wrote: > Using a gateway that is not on the same subnet doesn't sound very nice, > but again, the goal is to avoid wasting precious IPv4 space. What router platform are you using upstream from the probe? Doing a /32 per vlan(ie sharing a larger subnet between different vlans) is perfectly possible on several routing platforms. http://tools.ietf.org/html/rfc3069.html You can do this with Ciscos using static /32 route pointing to a vlan. http://www.gossamer-threads.com/lists/nsp/ipv6/25933 -- Mikael Abrahamsson email: swmike at swm.pp.se From bjonglez at illyse.org Fri Aug 15 09:06:44 2014 From: bjonglez at illyse.org (Baptiste Jonglez) Date: Fri, 15 Aug 2014 09:06:44 +0200 Subject: [atlas] Probe on a /31 or /32 IPv4 network In-Reply-To: References: <20140814211510.GC1716@illyse.org> Message-ID: <20140815070644.GD1716@illyse.org> On Fri, Aug 15, 2014 at 06:23:09AM +0200, Mikael Abrahamsson wrote: > On Thu, 14 Aug 2014, Baptiste Jonglez wrote: > > >Using a gateway that is not on the same subnet doesn't sound very nice, > >but again, the goal is to avoid wasting precious IPv4 space. > > What router platform are you using upstream from the probe? Doing a /32 per > vlan(ie sharing a larger subnet between different vlans) is perfectly > possible on several routing platforms. We're using Linux. Actually, we are already routing a /32 per VLAN on the router, but up to now, we were also setting up /32 "subnets" on the downstream routers or hosts. > http://tools.ietf.org/html/rfc3069.html Interesting read. It basically amounts to use /32 routes on the router, and a larger subnet (e.g. /24) on hosts, as Philip suggests. This is a bit of a hack when hosts want to talk to each other, but this is mostly ok for the probe (or we can use proxy ARP on the router if it becomes a problem). Thanks for the help, Baptiste -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vnaumov at ripe.net Fri Aug 15 12:14:57 2014 From: vnaumov at ripe.net (Viktor Naumov) Date: Fri, 15 Aug 2014 12:14:57 +0200 Subject: [atlas] measurment with endtime - faulty date In-Reply-To: <53ECF453.4040900@gmail.com> References: <53ECF453.4040900@gmail.com> Message-ID: <53EDDDA1.7080402@ripe.net> Hi Dave, Just tried and it works for me. Can you try to reset the cache and try again? What browser do you use? Cheers /vty On 8/14/14, 7:39 PM, gboonie wrote: > Hi, > > I noticed the last few days that when I create a new measurement with > a end date and time next week that I get a failure message on the next > screen. > > --- > Your measurement will start ASAP. > Your measurement will end at: Y-8-16 0:i UTC. > > and in the next screen: > > Enter a valid date/time. > --- > > What I selected was: > 2014-08-16 > 00:45 > > Multiple tests on 2 different Win7 PCs give the same result. > > Regards, > > Dave > > From gboonie at gmail.com Sat Aug 16 08:26:50 2014 From: gboonie at gmail.com (gboonie) Date: Sat, 16 Aug 2014 08:26:50 +0200 Subject: [atlas] measurment with endtime - faulty date In-Reply-To: <53ECF453.4040900@gmail.com> References: <53ECF453.4040900@gmail.com> Message-ID: <53EEF9AA.40406@gmail.com> Hi, I just tried but now I cannot reproduce the issue anymore. Not even on the exact same pc and browser. We'll call it 'issue disappeared during investigation' Thanks, Dave gboonie schreef op 14-8-2014 om 19:39: > Hi, > > I noticed the last few days that when I create a new measurement with > a end date and time next week that I get a failure message on the next > screen. > > --- > Your measurement will start ASAP. > Your measurement will end at: Y-8-16 0:i UTC. > > and in the next screen: > > Enter a valid date/time. > --- > > What I selected was: > 2014-08-16 > 00:45 > > Multiple tests on 2 different Win7 PCs give the same result. > > Regards, > > Dave > From gboonie at gmail.com Sat Aug 16 15:06:28 2014 From: gboonie at gmail.com (gboonie) Date: Sat, 16 Aug 2014 15:06:28 +0200 Subject: [atlas] measurment with endtime - faulty date In-Reply-To: <53EEF9AA.40406@gmail.com> References: <53ECF453.4040900@gmail.com> <53EEF9AA.40406@gmail.com> Message-ID: <53EF5754.7050804@gmail.com> Some more persistence lead to the insight on how to reproduce the issue. - Login - measurements (you should see the list of 'my measurements' - click on any of them which was a ping test. - close the newly opened tab - now try to set-up a new measurement with an end time and date. Or alternatively for the last step: right click on any measurement in 'my measurement' and change the end data or even the description. This was reproducible on a ubuntu laptop with firefox but also on win7 with chrome or firefox. I hope others can reproduce. By all these tests I found that logging out and back in solves the issue. Thanks, Dave >> >> I noticed the last few days that when I create a new measurement with >> a end date and time next week that I get a failure message on the >> next screen. >> >> --- >> Your measurement will start ASAP. >> Your measurement will end at: Y-8-16 0:i UTC. >> >> and in the next screen: >> >> Enter a valid date/time. >> --- >> >> What I selected was: >> 2014-08-16 >> 00:45 >> >> Multiple tests on 2 different Win7 PCs give the same result. >> >> Regards, >> >> Dave >> > From mgalante at ripe.net Mon Aug 18 10:33:08 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 18 Aug 2014 10:33:08 +0200 Subject: [atlas] S-IT Informationstechnologie Betreiber (DE) has joined RIPE Atlas anchors Message-ID: <0D4FFB28-0F8C-4889-8093-C4DDB830EB74@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called de-cal-as39702 and it is hosted by S-IT Informationstechnologie Betreiber in Calw, Germany. With this anchor we reached a total of 70 online. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From vnaumov at ripe.net Mon Aug 18 14:22:20 2014 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 18 Aug 2014 14:22:20 +0200 Subject: [atlas] measurment with endtime - faulty date In-Reply-To: <53EF5754.7050804@gmail.com> References: <53ECF453.4040900@gmail.com> <53EEF9AA.40406@gmail.com> <53EF5754.7050804@gmail.com> Message-ID: <53F1EFFC.1020409@ripe.net> Hi Dave, Thank you! I'm able to reproduce the bug now and we will fix it soon. /vty On 8/16/14, 3:06 PM, gboonie wrote: > Some more persistence lead to the insight on how to reproduce the issue. > > - Login > - measurements (you should see the list of 'my measurements' > - click on any of them which was a ping test. > - close the newly opened tab > - now try to set-up a new measurement with an end time and date. > > Or alternatively for the last step: right click on any measurement in > 'my measurement' and change the end data or even the description. > > This was reproducible on a ubuntu laptop with firefox but also on win7 > with chrome or firefox. > > I hope others can reproduce. > > By all these tests I found that logging out and back in solves the issue. > > Thanks, > > Dave > > > > >>> >>> I noticed the last few days that when I create a new measurement >>> with a end date and time next week that I get a failure message on >>> the next screen. >>> >>> --- >>> Your measurement will start ASAP. >>> Your measurement will end at: Y-8-16 0:i UTC. >>> >>> and in the next screen: >>> >>> Enter a valid date/time. >>> --- >>> >>> What I selected was: >>> 2014-08-16 >>> 00:45 >>> >>> Multiple tests on 2 different Win7 PCs give the same result. >>> >>> Regards, >>> >>> Dave >>> >> > > From james.sink at freedomvoice.com Mon Aug 18 20:38:11 2014 From: james.sink at freedomvoice.com (James Sink) Date: Mon, 18 Aug 2014 18:38:11 +0000 Subject: [atlas] Probe on a /31 or /32 IPv4 network In-Reply-To: <20140815070644.GD1716@illyse.org> References: <20140814211510.GC1716@illyse.org> <20140815070644.GD1716@illyse.org> Message-ID: "(or we can use proxy ARP on the router if it becomes a problem)." You're a braver man than I. Personally, the prospect of troubleshooting proxy-arp at 3 am doesn't sound like much fun. -James -----Original Message----- From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Baptiste Jonglez Sent: Friday, August 15, 2014 12:07 AM To: ripe-atlas at ripe.net Subject: Re: [atlas] Probe on a /31 or /32 IPv4 network On Fri, Aug 15, 2014 at 06:23:09AM +0200, Mikael Abrahamsson wrote: > On Thu, 14 Aug 2014, Baptiste Jonglez wrote: > > >Using a gateway that is not on the same subnet doesn't sound very > >nice, but again, the goal is to avoid wasting precious IPv4 space. > > What router platform are you using upstream from the probe? Doing a > /32 per vlan(ie sharing a larger subnet between different vlans) is > perfectly possible on several routing platforms. We're using Linux. Actually, we are already routing a /32 per VLAN on the router, but up to now, we were also setting up /32 "subnets" on the downstream routers or hosts. > http://tools.ietf.org/html/rfc3069.html Interesting read. It basically amounts to use /32 routes on the router, and a larger subnet (e.g. /24) on hosts, as Philip suggests. This is a bit of a hack when hosts want to talk to each other, but this is mostly ok for the probe (or we can use proxy ARP on the router if it becomes a problem). Thanks for the help, Baptiste From mgalante at ripe.net Tue Aug 19 15:03:00 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 19 Aug 2014 15:03:00 +0200 Subject: [atlas] DigitalOcean has joined RIPE Atlas anchors Message-ID: <9C1A406A-837D-4A0B-8639-DD748A07697E@ripe.net> Dear RIPE Atlas users, We're happy to announce that two RIPE Atlas anchors have joined the network and are now available as targets for probe hosts conducting their own user-defined measurements. The new anchors are uk-slo-as202109 located in Slough, United Kingdom and us-sfo-as14061 located in San Francisco, United States, both hosted by DigitalOcean. Congratulations to DigitalOcean for bringing their two anchors online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards these anchors from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From BECHA at ripe.net Mon Aug 25 13:41:53 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 25 Aug 2014 13:41:53 +0200 Subject: [atlas] The University of Waikato (NZ) has joined RIPE Atlas anchors In-Reply-To: <0D4FFB28-0F8C-4889-8093-C4DDB830EB74@ripe.net> References: <0D4FFB28-0F8C-4889-8093-C4DDB830EB74@ripe.net> Message-ID: <53FB2101.9030503@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called nz-hlz-as681 and it is hosted by the University of Waikato, Hamilton. This is the first RIPE Atlas anchor in New Zealand! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net