From jandrewartha at ccgs.wa.edu.au Mon Jul 3 07:01:08 2017 From: jandrewartha at ccgs.wa.edu.au (James Andrewartha) Date: Mon, 3 Jul 2017 13:01:08 +0800 Subject: [atlas] Monthly probe report says it was down for the entire month In-Reply-To: <20170701015021.9977.13170@worker2.atlas.ripe.net> References: <20170701015021.9977.13170@worker2.atlas.ripe.net> Message-ID: Hi, I got my monthly probe report and oddly it says my probe was down for the entire month, rather than the 14d 6h 55m (47.63%) the website says. I've only just been able to reboot the probe (it didn't respond to ping at all), and it has come up with a new IP, but hasn't connected to the controller. Some things have updated with the new IP, eg p29530.probes.atlas.ripe.net but others like the local address are still showing the old IP. Should I try doing the recovery procedure? Thanks, James -------- Forwarded Message -------- Subject: Monthly probe report for CCGS Perth (#29530) Date: Sat, 1 Jul 2017 01:50:21 +0000 From: RIPE Atlas Reply-To: RIPE Atlas To: linuxadmin at ccgs.wa.edu.au Dear James Andrewartha, This is your monthly availability report for probe 29530 (CCGS Perth). Calculation interval : 2017-06-01 00:00:00 - 2017-07-01 00:00:00 Total Connected Time : 0d 00:00 Total Disconnected Time : 30d 00:00 Total Availability : 0.00% This is an automatically generated email from RIPE Atlas. It was sent to you because you asked to receive reports about probe availability. If you would like to change this, or disable this reporting altogether, please go to https://atlas.ripe.net/probes/29530/, click the "Edit" button next to "Notifications", and use the form there to define what you want. Kind regards, RIPE Atlas Team From vnaumov at ripe.net Mon Jul 3 11:18:45 2017 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 3 Jul 2017 11:18:45 +0200 Subject: [atlas] Monthly probe report says it was down for the entire month In-Reply-To: References: <20170701015021.9977.13170@worker2.atlas.ripe.net> Message-ID: <227b0feb-a4db-b382-ae74-2f7c06fa886a@ripe.net> Hi James, We are in the slow process of changing the logs data storage layer and it could be possible that something went not as expected :) I'm investigating what could go wrong with your up-times. Thank you for letting us know! wbr /vty On 7/3/17 7:01 AM, James Andrewartha wrote: > Hi, > > I got my monthly probe report and oddly it says my probe was down for > the entire month, rather than the 14d 6h 55m (47.63%) the website says. > > I've only just been able to reboot the probe (it didn't respond to ping > at all), and it has come up with a new IP, but hasn't connected to the > controller. Some things have updated with the new IP, eg > p29530.probes.atlas.ripe.net but others like the local address are still > showing the old IP. Should I try doing the recovery procedure? > > Thanks, > > James > > -------- Forwarded Message -------- > Subject: Monthly probe report for CCGS Perth (#29530) > Date: Sat, 1 Jul 2017 01:50:21 +0000 > From: RIPE Atlas > Reply-To: RIPE Atlas > To: linuxadmin at ccgs.wa.edu.au > > Dear James Andrewartha, > > This is your monthly availability report for probe 29530 (CCGS Perth). > > Calculation interval : 2017-06-01 00:00:00 - 2017-07-01 00:00:00 > Total Connected Time : 0d 00:00 > Total Disconnected Time : 30d 00:00 > Total Availability : 0.00% > > > This is an automatically generated email from RIPE Atlas. It was sent to > you because you asked to receive reports about probe availability. > > If you would like to change this, or disable this reporting altogether, > please go to https://atlas.ripe.net/probes/29530/, click the "Edit" > button next to "Notifications", and use the form there to define what > you want. > > Kind regards, > > RIPE Atlas Team > From mir at ripe.net Tue Jul 4 16:51:19 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 4 Jul 2017 16:51:19 +0200 Subject: [atlas] New on RIPE Labs: Next Five Sponsored RIPE Atlas Anchors Message-ID: Dear colleagues, The second phase of the RIPE NCC?s campaign to sponsor 15 RIPE Atlas anchors has been completed, with another five anchor hosts selected for sponsorship. We want to tell you about the new anchor hosts and also take a look at some related developments here at the RIPE NCC: https://labs.ripe.net/Members/alun_davies/next-five-sponsored-ripe-atlas-anchors Kind regards, Mirjam K?hne RIPE NCC From bortzmeyer at nic.fr Wed Jul 5 15:10:17 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 5 Jul 2017 15:10:17 +0200 Subject: [atlas] [ripe-atlas-tools] Anyone had success with renderer aggregate_ping? Message-ID: <20170705131017.pvkvrysrofs54cwc@nic.fr> I cannot make the renderer aggregate_ping work: https://github.com/RIPE-NCC/ripe-atlas-tools/issues/186 From mir at ripe.net Thu Jul 6 16:12:39 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 6 Jul 2017 16:12:39 +0200 Subject: [atlas] New on RIPE Labs: Anchoring Measurements - Bringing Back the Balance Message-ID: <747244ef-b50f-c1c3-0af9-45586e43078c@ripe.net> Dear colleagues, Please read on RIPE Labs how we're striking a balance between probes and anchors in RIPE Atlas anchoring measurements: https://labs.ripe.net/Members/alun_davies/balancing-act Kind regards, Mirjam K?hne RIPE NCC From bios at bios.name Tue Jul 11 11:54:01 2017 From: bios at bios.name (Mikhail Okhotin) Date: Tue, 11 Jul 2017 11:54:01 +0200 Subject: [atlas] Probe does not request IPv4 address via DHCP In-Reply-To: Message-ID: Hello, It seems, I have absolutely same problem with probe #24361. Probe has disconnected on 2017-07-10, and now (on IPv6 network, with address 2001:470:1f0b:527:16cc:20ff:fe48:be04) it remains silent, except short communication with woolsey.ipv6.atlas.ripe.net via SSL. May I ask for doing this trick again for this probe? Mikhail. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From ripe-atlas at herrb.eu Wed Jul 12 21:44:15 2017 From: ripe-atlas at herrb.eu (Matthieu Herrb) Date: Wed, 12 Jul 2017 21:44:15 +0200 Subject: [atlas] half dead v1 probe ? Message-ID: <20170712194415.GB19034@nebraska.herrb.net> Hi, Here at Tetaneutral.net we're hosting a V1 Atlas probe since 2012 or so. A few weeks ago it started beeing marked as unconnected on the ripe atlas page : https://atlas.ripe.net/probes/523/ Since it's a v1 probe, I can only power cycle it to try to reconnect it, which I've done a number of times now, without success. It's still answering to ping requests, both on its v4 and v6 addresses and I can see some traceroute-like trafic going out of it. It's marked as "firewall problems suspected", but we don't do any firewalling on it. On IPv4 it's on a 1:1 NAT, all ports are open and forwarded in both directions, and on V6 it's routed without any filtering. Also we haven't changed anything on our infrastructure around the time it became disconnected. I'm starting to suspect a firmware upgrade problem as the one mentionned by Alun Davis in https://www.ripe.net/ripe/mail/archives/ripe-atlas/2017-June/003329.html Any suggestion before I send it back and ask for a new one ? Thanks in advance, -- Matthieu Herrb From robert at ripe.net Thu Jul 13 09:53:04 2017 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 13 Jul 2017 09:53:04 +0200 Subject: [atlas] half dead v1 probe ? In-Reply-To: <20170712194415.GB19034@nebraska.herrb.net> References: <20170712194415.GB19034@nebraska.herrb.net> Message-ID: <116a2958-bd5b-3cff-c4e1-3aa970158780@ripe.net> Hello, This mail may be of help: https://www.ripe.net/ripe/mail/archives/ripe-atlas/2017-June/003329.html Background info: slide 6 of https://ripe74.ripe.net/presentations/74-ripe74-mat-atlas-update_v2.pdf Regards, Robert Kisteleki On 2017-07-12 21:44, Matthieu Herrb wrote: > Hi, > > Here at Tetaneutral.net we're hosting a V1 Atlas probe since 2012 or > so. > A few weeks ago it started beeing marked as unconnected on the ripe > atlas page : https://atlas.ripe.net/probes/523/ > > Since it's a v1 probe, I can only power cycle it to try to reconnect > it, which I've done a number of times now, without success. > > It's still answering to ping requests, both on its v4 and v6 addresses > and I can see some traceroute-like trafic going out of it. > > It's marked as "firewall problems suspected", but we don't do any > firewalling on it. On IPv4 it's on a 1:1 NAT, all ports are open > and forwarded in both directions, and on V6 it's routed without any > filtering. Also we haven't changed anything on our infrastructure > around the time it became disconnected. > > I'm starting to suspect a firmware upgrade problem as the one > mentionned by Alun Davis in > https://www.ripe.net/ripe/mail/archives/ripe-atlas/2017-June/003329.html > > Any suggestion before I send it back and ask for a new one ? > > Thanks in advance, > From ms at uakom.sk Thu Jul 13 14:12:50 2017 From: ms at uakom.sk (Martin Stanislav) Date: Thu, 13 Jul 2017 14:12:50 +0200 Subject: [atlas] half dead v1 probe ? In-Reply-To: <20170712194415.GB19034@nebraska.herrb.net> References: <20170712194415.GB19034@nebraska.herrb.net> Message-ID: <20170713121250.GA14755@moon.uakom.sk> Hi Matthieu, On Wed, Jul 12, 2017 at 09:44:15PM +0200, Matthieu Herrb wrote: > > Here at Tetaneutral.net we're hosting a V1 Atlas probe since 2012 or > so. > A few weeks ago it started beeing marked as unconnected on the ripe > atlas page : https://atlas.ripe.net/probes/523/ > > Since it's a v1 probe, I can only power cycle it to try to reconnect > it, which I've done a number of times now, without success. > > It's still answering to ping requests, both on its v4 and v6 addresses > and I can see some traceroute-like trafic going out of it. > > It's marked as "firewall problems suspected", but we don't do any > firewalling on it. On IPv4 it's on a 1:1 NAT, all ports are open > and forwarded in both directions, and on V6 it's routed without any > filtering. Also we haven't changed anything on our infrastructure > around the time it became disconnected. All of this is similar to my past experience with v1 probe ID 114 including the reported FW version 4770 (according to the RIPE Atlas portal) at time of the outage. > I'm starting to suspect a firmware upgrade problem as the one > mentionned by Alun Davis in > https://www.ripe.net/ripe/mail/archives/ripe-atlas/2017-June/003329.html > > Any suggestion before I send it back and ask for a new one ? I've tried only a few (two?) power cycles to no avail. Finally, I've got myself to snoop and check the probe's network activity on reboot. Following the last power cycle the v1 probe 114 has: - acquired a public v4 IP address (DHCP) & v6 IP address (SLAAC), recursive name server IPs, etc.; - requested a translation of ntp.atlas.ripe.net getting back responses (CNAME ntp.ripe.net., A 193.0.0.229); - synced time from ntp.ripe.net/193.0.0.229.123 (NTPv3); - requested a translation of U19.M${probe-mac-address}.sos.atlas.ripe.net. (both AAAA an A records) getting back v4 & v6 address in response (2001:67c:2e8:11::c100:1337 & 193.0.19.55); - sent an ICMP echo request to the SOS host (193.0.19.55) getting back a reply; - requested a translation of ctr-ams07.atlas.ripe.net getting back an answer (v6 2001:67c:2e8:11::c100:1373) - talked to the controller 2001:67c:2e8:11::c100:1373 at tcp port 443 likely initiating a new FW dowload; - successfully rebooted into the newest FW 4790. Luckily, that was the end of outage for ID 114. Hope your 523 can get back online as well. I hope v1 probes will keep on running at least until the v4 version is available as a replacement. Kind regards, Martin From jterbeest at ripe.net Thu Jul 13 17:19:05 2017 From: jterbeest at ripe.net (Johan ter Beest) Date: Thu, 13 Jul 2017 17:19:05 +0200 Subject: [atlas] Caching issues on the latest call Message-ID: Dear all, Today we became aware of some caching issues on the latest API call (https://atlas.ripe.net/docs/api/v2/reference/#!/measurements/Latest_GET). In certain corner cases it was possible that an incomplete set of results for a logged-in user was cached for up to 24 hours. This did not apply to non logged-in users as the results are not cached in that case. A fix for this issue has been deployed and going forward the latest call will have a 1 minute cache regardless of whether the user is logged in or not. As caching is always tricky, we kindly ask that users will let us know if they experience anything out of the ordinary that might be related to this change. Kind regards, Johan ter Beest RIPE Atlas Team From adavies at ripe.net Mon Jul 17 15:50:18 2017 From: adavies at ripe.net (Alun Davies) Date: Mon, 17 Jul 2017 15:50:18 +0200 Subject: [atlas] New RIPE Atlas Measurement Options Message-ID: Dear all, The RIPE Atlas team have added a number of new measurement options on RIPE Atlas. Here?s an overview of the changes: DNS measurements timeout: allows the user to specify a custom timeout in milliseconds after which probes will stop waiting for a response from the DNS server use_macros: allows the use of special macro strings in the "query_argument" field, to create unique or easily distinguishable queries. The allowed macros are: $p the (integer) ID of the probe carrying out the measurement $r a random 16-digit hexadecimal string $t a Unix timestamp of the time that the probe carries out the DNS query SSLcert measurements hostname: specifies a hostname to send as a Server Name Indication (SNI), which is necessary for web servers which host multiple TLS domains on the same IP address. Ping measurements include_probe_id: include the probe ID as an ASCII string within the payload of ping measurements. Note: this is included in addition to other payload data. The changes are all included in the RIPE Atlas API reference: https://atlas.ripe.net/docs/api/v2/reference/#!/measurements/Measurement_List_POST If you have any questions whatsoever about the new measurement options, do let us know. As always, we welcome suggestions for new features from RIPE Atlas users. Best regards, Alun Davies RIPE NCC Communications Department -------------- 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 tore at fud.no Tue Jul 18 07:48:54 2017 From: tore at fud.no (Tore Anderson) Date: Tue, 18 Jul 2017 07:48:54 +0200 Subject: [atlas] Link aggregation for anchors? Message-ID: <20170718074854.1470a1bd@echo.ms.redpill-linpro.com> Hi, I was wondering if it is possible to connect our anchor in a fault tolerant fashion using 802.3ad link aggregation? This would allow us to perform serialised maintenance on the upstream switches without ever offlining the anchor. Tore From ripe at brite.cz Tue Jul 18 15:38:40 2017 From: ripe at brite.cz (ripe at brite.cz) Date: Tue, 18 Jul 2017 15:38:40 +0200 Subject: [atlas] =?utf-8?q?Trace_and_Ping_measurements_fail_on_Probe_15861?= Message-ID: <20170718153840.82B98CFC@centrum.cz> Hi team, recently I'm not able to run measurements on probe 15861 I am hosting at home. When I create a measurement with only this probe, it ends up in Failed status [measurements 9193416 9193417 9199824 for example]. When there is multiple probes in the measurement, probe 15861 ends up showing "No recent report available" [9193406 9192883]. Otherwise the probe has been online and does not show any anomalies. Any idea? Thank you Jiri From robert at ripe.net Wed Jul 19 14:35:14 2017 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 19 Jul 2017 14:35:14 +0200 Subject: [atlas] Link aggregation for anchors? In-Reply-To: <20170718074854.1470a1bd@echo.ms.redpill-linpro.com> References: <20170718074854.1470a1bd@echo.ms.redpill-linpro.com> Message-ID: <5da54e53-55e9-a6e1-9477-b2377e944624@ripe.net> On 2017-07-18 7:48, Tore Anderson wrote: > Hi, > > I was wondering if it is possible to connect our anchor in a fault > tolerant fashion using 802.3ad link aggregation? > > This would allow us to perform serialised maintenance on the upstream > switches without ever offlining the anchor. > > Tore Hi Tore, Thanks for the suggestion; we'll look into this to see how easy or difficult it would be. In the meantime, it'd be useful to know if others are interested in this as well...? Just to be able to check the expected amount of work against the demand. Cheers, Robert From gert at space.net Wed Jul 19 14:49:11 2017 From: gert at space.net (Gert Doering) Date: Wed, 19 Jul 2017 14:49:11 +0200 Subject: [atlas] Link aggregation for anchors? In-Reply-To: <5da54e53-55e9-a6e1-9477-b2377e944624@ripe.net> References: <20170718074854.1470a1bd@echo.ms.redpill-linpro.com> <5da54e53-55e9-a6e1-9477-b2377e944624@ripe.net> Message-ID: <20170719124911.GF45648@Space.Net> Hi, On Wed, Jul 19, 2017 at 02:35:14PM +0200, Robert Kisteleki wrote: > In the meantime, it'd be useful to know if others are interested in this > as well...? Just to be able to check the expected amount of work against > the demand. *second* (active/passive linux bonding would work well for us, while LACP wouldn't due to conscious design decision to de-couple control planes of primary/secondary switches) 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From adavies at ripe.net Wed Jul 19 14:54:08 2017 From: adavies at ripe.net (Alun Davies) Date: Wed, 19 Jul 2017 14:54:08 +0200 Subject: [atlas] New on RIPE Labs: The Next Generation of RIPE Atlas Anchors Message-ID: <6E72FFE7-C4CD-40DD-BDE9-82B1E7940076@ripe.net> Dear Colleagues, The RIPE NCC is in the process of testing hardware for the next generation of RIPE Atlas anchors. Here?s a detailed overview of the process: https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas-anchors Best regards, Alun Davies RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2607 bytes Desc: not available URL: From colinj at mx5.org.uk Wed Jul 19 15:02:04 2017 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 19 Jul 2017 14:02:04 +0100 Subject: [atlas] New on RIPE Labs: The Next Generation of RIPE Atlas Anchors In-Reply-To: <6E72FFE7-C4CD-40DD-BDE9-82B1E7940076@ripe.net> References: <6E72FFE7-C4CD-40DD-BDE9-82B1E7940076@ripe.net> Message-ID: <8EE49F57-313C-4D3B-80FB-8512A74BBCB6@mx5.org.uk> How about a vmware image solution as well ? Colin > On 19 Jul 2017, at 13:54, Alun Davies wrote: > > Dear Colleagues, > > The RIPE NCC is in the process of testing hardware for the next generation of RIPE Atlas anchors. Here?s a detailed overview of the process: > > https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas-anchors > > Best regards, > Alun Davies > RIPE NCC From tore at fud.no Thu Jul 20 07:44:46 2017 From: tore at fud.no (Tore Anderson) Date: Thu, 20 Jul 2017 07:44:46 +0200 Subject: [atlas] Link aggregation for anchors? In-Reply-To: <20170719124911.GF45648@Space.Net> References: <20170718074854.1470a1bd@echo.ms.redpill-linpro.com> <5da54e53-55e9-a6e1-9477-b2377e944624@ripe.net> <20170719124911.GF45648@Space.Net> Message-ID: <20170720074446.0661b2b5@echo.ms.redpill-linpro.com> * Gert Doering > (active/passive linux bonding would work well for us, while LACP > wouldn't due to conscious design decision to de-couple control planes > of primary/secondary switches) Active/passive fail-over ? la Linux bonding would work for me too. The biggest disadvantage of that is that you waste half your available bandwidth, but that probably isn't a big deal for the Atlas Anchors. It is quite possible to create a setup that does 802.3ad if an LACP neighbour is detected, falling back on active/passive fail-over if not. That said, you do lose most of the error detection capabilities of LACP that way. Quite possibly not worth the engineering effort if it's not already implemented in whatever software you're using. I'd rather you spent that time implementing LLDP support, come to think of it. (That would be useful on the non-Anchor probes as well.) Tore From gert at space.net Thu Jul 20 07:52:30 2017 From: gert at space.net (Gert Doering) Date: Thu, 20 Jul 2017 07:52:30 +0200 Subject: [atlas] Link aggregation for anchors? In-Reply-To: <20170720074446.0661b2b5@echo.ms.redpill-linpro.com> References: <20170718074854.1470a1bd@echo.ms.redpill-linpro.com> <5da54e53-55e9-a6e1-9477-b2377e944624@ripe.net> <20170719124911.GF45648@Space.Net> <20170720074446.0661b2b5@echo.ms.redpill-linpro.com> Message-ID: <20170720055230.GJ45648@Space.Net> Hi, On Thu, Jul 20, 2017 at 07:44:46AM +0200, Tore Anderson wrote: > * Gert Doering > > > (active/passive linux bonding would work well for us, while LACP > > wouldn't due to conscious design decision to de-couple control planes > > of primary/secondary switches) > > Active/passive fail-over ? la Linux bonding would work for me too. The > biggest disadvantage of that is that you waste half your available > bandwidth, but that probably isn't a big deal for the Atlas Anchors. Not really, given a GigE uplink and just a few mbits in use :-) > It is quite possible to create a setup that does 802.3ad if an LACP > neighbour is detected, falling back on active/passive fail-over if not. > That said, you do lose most of the error detection capabilities of LACP > that way. Quite possibly not worth the engineering effort if it's not > already implemented in whatever software you're using. Linux bonding can do ARP probing on both member interfaces, which does the most important "real world" part of the error detection - "will this port work for me to reach the default gateway?" (so you can even failover on an uplink outage). > I'd rather you spent that time implementing LLDP support, come to think > of it. (That would be useful on the non-Anchor probes as well.) Minimalistic LLDP support would also be nice ("device, port"). 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: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From tore at fud.no Thu Jul 20 08:24:42 2017 From: tore at fud.no (Tore Anderson) Date: Thu, 20 Jul 2017 08:24:42 +0200 Subject: [atlas] Link aggregation for anchors? In-Reply-To: <20170720055230.GJ45648@Space.Net> References: <20170718074854.1470a1bd@echo.ms.redpill-linpro.com> <5da54e53-55e9-a6e1-9477-b2377e944624@ripe.net> <20170719124911.GF45648@Space.Net> <20170720074446.0661b2b5@echo.ms.redpill-linpro.com> <20170720055230.GJ45648@Space.Net> Message-ID: <20170720082442.00efd258@echo.ms.redpill-linpro.com> * Gert Doering > Linux bonding can do ARP probing on both member interfaces, which does > the most important "real world" part of the error detection - "will > this port work for me to reach the default gateway?" (so you can even > failover on an uplink outage). I've seen, but it seems a bit of a hack to me, one that I'd be reluctant to see implemented in all the Anchors. I'd rather go without those X pps of extra broadcast traffic on my network, to be honest. There's also the risk that some networks rate-limit ARP and/or broadcast traffic in general which would make the approach unreliable. Further, it is a layering violation. In particular, if there's an IPv4 outage and ARPs go unanswered on one or more interfaces, that shouldn't have any impact on IPv6 whatsoever. Active/passive (using link down events to trigger fail-over) is probably the way to go. KISS and all that. Tore From philip.homburg at ripe.net Thu Jul 20 10:48:21 2017 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 20 Jul 2017 10:48:21 +0200 Subject: [atlas] Link aggregation for anchors? In-Reply-To: <20170720074446.0661b2b5@echo.ms.redpill-linpro.com> References: <20170718074854.1470a1bd@echo.ms.redpill-linpro.com> <5da54e53-55e9-a6e1-9477-b2377e944624@ripe.net> <20170719124911.GF45648@Space.Net> <20170720074446.0661b2b5@echo.ms.redpill-linpro.com> Message-ID: <48ec31cc-5ff3-aa9b-d456-fafe3c134b28@ripe.net> On 2017/07/20 7:44 , Tore Anderson wrote: > I'd rather you spent that time implementing LLDP support, come to think > of it. (That would be useful on the non-Anchor probes as well.) I have a ticket open for LLDP on regular probes. Though no time frame is assigned when it should be done. I assume the same code would work for anchors, but I haven't looked into that. From jterbeest at ripe.net Thu Jul 20 12:19:24 2017 From: jterbeest at ripe.net (Johan ter Beest) Date: Thu, 20 Jul 2017 12:19:24 +0200 Subject: [atlas] Update on the anchoring measurements change Message-ID: Dear all, As described in the labs article here: https://labs.ripe.net/Members/alun_davies/balancing-act we have split the anchoring measurements. We are currently in the process of adding more probes to the new 'probe' anchoring measurements. We expect this to be completed by the end of this week. Please let us know if you notice anything out of the ordinary. Kind regards, Johan ter Beest RIPE Atlas Team From camin at ripe.net Thu Jul 20 15:25:34 2017 From: camin at ripe.net (Chris Amin) Date: Thu, 20 Jul 2017 15:25:34 +0200 Subject: [atlas] NSID option on the RIPE Atlas SOA measurements of the root servers Message-ID: <0ec0d5b3-babf-c31b-44c1-5840e875b747@ripe.net> Dear colleagues, RIPE Atlas is currently running a series of DNS SOA built-in measurements* towards all of the root servers from all probes. During the recent DNS measurements hackathon** it became apparent that for some use cases it would be useful to have SOA queries from all probes with the NSID EDNS option set, in order to be able to match up responses with the particular responding instances in an anycasted (or load balanced) setup. We would like to ask for feedback on two alternative options for implementing this change. They are: 1) Enable the NSID option for the existing built-in measurements towards the nine root servers which support it. 2) Start a new set of built-in measurements towards the nine root servers which support NSID. The advantages of option (1) are that it will be possible to compare and contrast the two sets of results, and that historical data for the existing built-ins will remain consistent with the current results. A very simple analysis shows that there is no overall increase in query error rates through enabling NSID, but there are bound to be individual marginal cases where queries fail or produce different results with NSID set but succeed without it. The advantages of option (2) are that there will be no increase in result storage usage -- the current IPv4+IPv6 UDP SOA built-ins towards the nine supporting root servers adds up to about 80 results per second (~1.5% of the total results in the system). This could potentially be mitigated by reducing the frequency for these new measurements, but perhaps more important than the slightly increased load is the potential user confusion caused by generating and providing two very similar sets of measurements. Please let us know if you have any preference for which way we go on this, particularly if you have a (current or future) use case for this kind of data. Kind regards, Chris Amin RIPE NCC * https://atlas.ripe.net/docs/built-in/ ** https://labs.ripe.net/Members/becha/results-dns-measurements-hackathon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jm at poure.com Fri Jul 21 08:53:36 2017 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Fri, 21 Jul 2017 08:53:36 +0200 Subject: [atlas] New on RIPE Labs: The Next Generation of RIPE Atlas Anchors In-Reply-To: <6E72FFE7-C4CD-40DD-BDE9-82B1E7940076@ripe.net> References: <6E72FFE7-C4CD-40DD-BDE9-82B1E7940076@ripe.net> Message-ID: <1500620016.2967.5.camel@poure.com> Le mercredi 19 juillet 2017 ? 14:54 +0200, Alun Davies a ?crit?: > Dear Colleagues, > > The RIPE NCC is in the process of testing hardware for the next > generation of RIPE Atlas anchors. Here?s a detailed overview of the > process: You should go with the APU2.? PC Engines lead engineer used to work for Soekeris. Pc Engines hardware rocks. The APU2 is a marvelous platform and frankly you don't even need to rack it is 1U, as it looks like a embedded platform but is in fact a full Quad-code computer with up to 4Gb of RAM. It is also very stable, designed in Europe. It is relatively open, as hardware plans are available, so you know what is inside. Please also ask network card firmwares. I asked them to Pc Engines but was never able to get them (as Pc Engines might not have them, or shall not be able to distribute them). >From my memory (this has to be verified), the APU serial port is hard- wired on the motherboard itself. So you cannot disable the serial port. Everyone with access to the hardware may be able to hack it without user or password. You should also look into the posibility to make signed kernel boot and signed partitions, so that we are sure that RIPE is not altered during shipment from your premisses to the user client. PC Engines will probably never go bust as they only produce on demand. On their website, they receive orders and only build the required platforms. So it is defenitely a good solution. Kind regards, Jean-Michel From nick at inex.ie Fri Jul 21 12:25:32 2017 From: nick at inex.ie (Nick Hilliard) Date: Fri, 21 Jul 2017 11:25:32 +0100 Subject: [atlas] New on RIPE Labs: The Next Generation of RIPE Atlas Anchors In-Reply-To: <1500620016.2967.5.camel@poure.com> References: <6E72FFE7-C4CD-40DD-BDE9-82B1E7940076@ripe.net> <1500620016.2967.5.camel@poure.com> Message-ID: <5971D69C.9000101@inex.ie> Jean-Michel Pour? wrote: > You should go with the APU2. do PC engines provide a rack-mounting kit for their enclosures? Nick From job at instituut.net Fri Jul 21 12:44:51 2017 From: job at instituut.net (Job Snijders) Date: Fri, 21 Jul 2017 10:44:51 +0000 Subject: [atlas] New on RIPE Labs: The Next Generation of RIPE Atlas Anchors In-Reply-To: <5971D69C.9000101@inex.ie> References: <6E72FFE7-C4CD-40DD-BDE9-82B1E7940076@ripe.net> <1500620016.2967.5.camel@poure.com> <5971D69C.9000101@inex.ie> Message-ID: Not sure if pcengines themselves produces those - but there are a number of options for rackmounting these from third parties. Kind regards, Job On Fri, 21 Jul 2017 at 12:26, Nick Hilliard wrote: > Jean-Michel Pour? wrote: > > You should go with the APU2. > > do PC engines provide a rack-mounting kit for their enclosures? > > Nick > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Mon Jul 24 10:12:26 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 24 Jul 2017 11:12:26 +0300 Subject: [atlas] Wifi measurements? Message-ID: <34763cf0-28c0-3562-456b-0c9cb14d0980@efes.iucc.ac.il> When I start a new measurement, in addition to the standard measurements like ping and traceroute, I see a "wifi" measurement that appears for about 2 seconds at the end of the list and then auto-disappears. See attached screenshot. Explanations? Thanks, Hank -------------- next part -------------- A non-text attachment was scrubbed... Name: atlas-wifi.jpg Type: image/jpeg Size: 95955 bytes Desc: not available URL: From jterbeest at ripe.net Mon Jul 24 11:29:22 2017 From: jterbeest at ripe.net (Johan ter Beest) Date: Mon, 24 Jul 2017 11:29:22 +0200 Subject: [atlas] Wifi measurements? In-Reply-To: <34763cf0-28c0-3562-456b-0c9cb14d0980@efes.iucc.ac.il> References: <34763cf0-28c0-3562-456b-0c9cb14d0980@efes.iucc.ac.il> Message-ID: <6c9932f3-7667-5dfe-3e10-05dec5be82fd@ripe.net> Hi Hank, On 24/07/2017 10:12, Hank Nussbacher wrote: > When I start a new measurement, in addition to the standard measurements > like ping and traceroute, I see a "wifi" measurement that appears for > about 2 seconds at the end of the list and then auto-disappears. See > attached screenshot. > > Explanations? The plan to introduce wifi measuements was first communicated with the community in November 2015. See the RIPE Labs article here: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-wifi-measurements An update to our plans was published in January 2016: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-wifi-measurements-part-2 As outlined in the article, steady work has been done on the WiFi feature and it's been made available to some users in our production environment as a Beta feature. The latest update can be found in Kaveh Ranjbar's Technical Services Report over 2017: https://labs.ripe.net/Members/kranjbar/ripe-ncc-technical-services-2017-part-one-focus-on-ripe-atlas As for the user interface issue,users who cannot create WiFi measurements should not see the WiFi measurement option. So you should not be seeing that option at all. I have discussed this with one of our front-end developers and this will be fixed in the near future. Kind regards, Johan ter Beest RIPE Atlas Team > Thanks, > Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From cs at fnx.li Mon Jul 24 16:50:39 2017 From: cs at fnx.li (=?UTF-8?Q?Christian_Schr=c3=b6tter?=) Date: Mon, 24 Jul 2017 16:50:39 +0200 Subject: [atlas] SOS History empty since 2017-07-20 Message-ID: Hi, the last entry in my SOS History is from 2017-07-19, see screenshot [1]. My probe is still connected and working, but there should be two items per day at minimum, for each reconnect of my DSL connection after 24 hours. Looks like something is broken at the Atlas system. Could someone confirm this bug? -- Regards, Christian [1]: https://happytec.at/r/Xfaab From gil at magisto.com Thu Jul 27 16:28:16 2017 From: gil at magisto.com (Gil Bahat) Date: Thu, 27 Jul 2017 17:28:16 +0300 Subject: [atlas] Probe recovery does not work Message-ID: Hi, I've finally managed to get a few USB drives to recover at least a few of my probes (I've spread about 3 dozen and only 2 are still online). But the stated recovery procedure does not work for me, with brand new 8GB keys. Is there any good way to see what's really going on with the recovery? the probes register themselves with the right addresses so I know connectivity and DHCP is ok, and yet they never recover. can the dhcp firmware be modified to try more aggressive recovery or better reporting of its state? Regards, Gil -------------- next part -------------- An HTML attachment was scrubbed... URL: From astrikos at ripe.net Mon Jul 31 16:39:54 2017 From: astrikos at ripe.net (Andreas Strikos) Date: Mon, 31 Jul 2017 16:39:54 +0200 Subject: [atlas] SOS History empty since 2017-07-20 In-Reply-To: References: Message-ID: Hi Christian, Indeed an update on BIND changed the log format, which caused our parser to fail. We have fixed that now and we will try to recover as many SOS messages as we can soon. Sorry for any inconvenience this might have caused. Regards, Andreas Strikos RIPE NCC On 24/07/2017 16:50, Christian Schr?tter wrote: > Hi, > > the last entry in my SOS History is from 2017-07-19, see screenshot [1]. > > My probe is still connected and working, but there should be two items > per day at minimum, for each reconnect of my DSL connection after 24 hours. > > Looks like something is broken at the Atlas system. Could someone > confirm this bug? > > -- > Regards, > Christian > > [1]: https://happytec.at/r/Xfaab >