From gert at space.net Sun Dec 1 13:38:05 2013 From: gert at space.net (Gert Doering) Date: Sun, 1 Dec 2013 13:38:05 +0100 Subject: [atlas] Six new RIPE Atlas anchors are now active In-Reply-To: <529B2C7E.6090001@fud.no> References: <20131129170944.GX81676@Space.Net> <529B2C7E.6090001@fud.no> Message-ID: <20131201123805.GC81676@Space.Net> Hi, On Sun, Dec 01, 2013 at 01:33:02PM +0100, Tore Anderson wrote: > * Gert Doering > > > On Fri, Nov 29, 2013 at 05:51:08PM +0100, Michela Galante wrote: > >> We would like to thank Job, Paul and Salim who put in a lot of effort to become the first anchor hosts! > > > > *second*!!! > > ITYM seventeenth? > > (or something close to that) > > Tore Anderson > RIPE Atlas Anchor host since Nov 23, 2012 > ?You are the first one, congratulations!? -- Vesna, Dec 3 2012 Hehe, indeed. And your Anchor is also way bigger than mine! 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: 826 bytes Desc: not available URL: From tore at fud.no Sun Dec 1 13:33:02 2013 From: tore at fud.no (Tore Anderson) Date: Sun, 01 Dec 2013 13:33:02 +0100 Subject: [atlas] Six new RIPE Atlas anchors are now active In-Reply-To: <20131129170944.GX81676@Space.Net> References: <20131129170944.GX81676@Space.Net> Message-ID: <529B2C7E.6090001@fud.no> * Gert Doering > On Fri, Nov 29, 2013 at 05:51:08PM +0100, Michela Galante wrote: >> We would like to thank Job, Paul and Salim who put in a lot of effort to become the first anchor hosts! > > *second*!!! ITYM seventeenth? (or something close to that) Tore Anderson RIPE Atlas Anchor host since Nov 23, 2012 ?You are the first one, congratulations!? -- Vesna, Dec 3 2012 From mgalante at ripe.net Tue Dec 3 16:33:37 2013 From: mgalante at ripe.net (Michela Galante) Date: Tue, 3 Dec 2013 16:33:37 +0100 Subject: [atlas] A new RIPE Atlas anchor is now online Message-ID: <3B951D3C-8F22-4DB8-B1F5-3EE5C5AE0753@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 gr-ath-as5408 and is hosted by GRNET in Athens, Greece. 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: 2626 bytes Desc: not available URL: From warwick at nlnetlabs.nl Wed Dec 4 13:21:07 2013 From: warwick at nlnetlabs.nl (warwick) Date: Wed, 04 Dec 2013 13:21:07 +0100 Subject: [atlas] Measurements at an interval Message-ID: <529F1E33.1000604@nlnetlabs.nl> Hello again, I stumbled upon something peculiar when submitting measurements with an interval via the API. It seems when submitting a measurement with a specific interval the maximum number of probes I could use was 50, but through the web interface the exact measurement is acceptable with many more probes. Kind regards, Warwick Louw From warwick at nlnetlabs.nl Wed Dec 4 13:13:23 2013 From: warwick at nlnetlabs.nl (warwick) Date: Wed, 04 Dec 2013 13:13:23 +0100 Subject: [atlas] Credits System Message-ID: <529F1C63.9090401@nlnetlabs.nl> Hello, I was wondering if you please explain how the credit system works, specifically traceroute measurements. I performed 2 measurements yesterday using large packets(1500) and targeted 500 probes per experiment. When the bill came it was rather shocking. I realize this is a tall order, but is the amount correct? The measurements I'm referring to are : 1043292 and 1043293. They each totaled to 1M credits, should it not be half of that? Kind regards, Warwick Louw -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Wed Dec 4 13:45:04 2013 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 04 Dec 2013 13:45:04 +0100 Subject: [atlas] Credits System In-Reply-To: <529F1C63.9090401@nlnetlabs.nl> References: <529F1C63.9090401@nlnetlabs.nl> Message-ID: <529F23D0.5060208@ripe.net> On 2013.12.04. 13:13, warwick wrote: > Hello, > > I was wondering if you please explain how the credit system works, > specifically traceroute measurements. I performed 2 measurements yesterday > using large packets(1500) and targeted 500 probes per experiment. When the > bill came it was rather shocking. I realize this is a tall order, but is the > amount correct? The measurements I'm referring to are : 1043292 and 1043293. > They each totaled to 1M credits, should it not be half of that? > > Kind regards, > Warwick Louw Hello, The system (at the moment) is sensitive to the size of outgoing packets; the bigger packet size you ask for, the more it costs (this is explained in https://atlas.ripe.net/docs/credits/). I suspect we'll need to review that, as this seems to be a recurring issue for users and there's not that much difference between a 100 byte and a 1000 byte outgoing packet. The costs should be more related to the number of packets and less to their size. Regards, Robert From BECHA at ripe.net Wed Dec 4 15:41:10 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 04 Dec 2013 15:41:10 +0100 Subject: [atlas] Looking for more beta testers Message-ID: <529F3F06.4050108@ripe.net> Dear RIPE Atlas users, we are currently testing one new feature -- alerting functionality that would enable you to incorporate results from RIPE Atlas into your nagios (or similar). There is a closed list for beta-testers, where we announce these kind of small tests, to smooth out worst bugs before enabling the feature for all the users. We would like to invite few more brave users who are willing to give us feedback on these early prototypes. If interested, please subscribe to this list: https://www.ripe.net/mailman/listinfo/atlas-testers Your applications need to be approved, so please allow several days until you get a confirmation from us. Thanks! Vesna From mgalante at ripe.net Wed Dec 11 15:15:06 2013 From: mgalante at ripe.net (Michela Galante) Date: Wed, 11 Dec 2013 15:15:06 +0100 Subject: [atlas] Spectrum Internet Ltd (UK) has joined RIPE Atlas anchors Message-ID: <684B0041-1414-46B1-88AE-61ACEC73FCD6@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 uk-cdf-as48294 and is hosted by Spectrum Internet Ltd in Cardiff, United Kingdom. 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: 2626 bytes Desc: not available URL: From dquinn at ripe.net Fri Dec 13 11:46:03 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Fri, 13 Dec 2013 11:46:03 +0100 Subject: [atlas] Measurements at an interval In-Reply-To: <529F1E33.1000604@nlnetlabs.nl> References: <529F1E33.1000604@nlnetlabs.nl> Message-ID: <52AAE56B.7020104@ripe.net> Hi, I'll do what I can to help you out with this, and see if there are in fact any inconsistencies between the UI and API methods for measurement creation. If you can email me off-list with the specs for a measurement that works in the UI but not in the API, I'll do what I can to track down and fix the problem, or just explain the situation better if it's not a bug. From warwick at nlnetlabs.nl Fri Dec 13 12:53:28 2013 From: warwick at nlnetlabs.nl (warwick) Date: Fri, 13 Dec 2013 12:53:28 +0100 Subject: [atlas] Measurements at an interval In-Reply-To: <529F2845.7070305@nlnetlabs.nl> References: <529F2845.7070305@nlnetlabs.nl> Message-ID: <52AAF538.402@nlnetlabs.nl> Hi Daniel, I sent an email (included below.) outlining a measurement with a specific interval done through the API and listed the response, please look at the email below. As for the Web UI measurement here is an example: /{u'result': u'/api/v1/measurement/1044471/result/', u'status': {u'id': 4, u'name': u'Stopped'}, u'msm_id': 1044471, u'interval': 1200, u'description': u'', u'participant_count': 50, u'can_visualise': False, u'resolve_on_probe': False, u'start_time': 1386161734, u'af': 6, u'creation_time': 1386161734, u'is_oneoff': False, u'stop_time': 1386165633, u'all_scheduling_requests_fulfilled': True, u'resolved_ips': [u'2001:7b8:40:1:d0e1:0:0:1'], u'dst_asn': u'12859', u'query': {u'type': u'AAAA', u'class': u'IN', u'value': u'nlnetlabs.nl.'}, u'is_public': True, u'type': {u'id': 7, u'name': u'dns'}, u'dst_addr': u'2001:7b8:40:1:d0e1:0:0:1', u'dst_name': u'2001:7b8:40:1:d0e1::1'}// / Robert Kisteleki suggested I send it through to atlas at ripe.net which I did and it has been listed as: [ripe.net #1113749] I received a response from Robert Kisteleki (which is the very last email included below), he said it might be a week or later until this gets investigated so he was right on the money :-) . Thank you for your response and we hope to see this bug(or whatever it is) get squashed :D P.S. If you could, please include Willem Toorop(Willem at nlnetlabs.nl) in the response as he was the one to mention this limitation to me and the one who suggested I email about this. He also sent an email outlining this issue but heard no response so I'm sure he would like to hear when a resolution to this limitation/bug/whatever has been found. P.P.S. At the bottom of the first included email is our work around which is get the probes specific to our needs (ipv6/4 etc..) and the chunk them into sizable chunks(50 probes work). Kind regards, Warwick Louw -------- Original Message -------- Subject: Re: [atlas] Measurements at an interval Date: Wed, 04 Dec 2013 14:04:05 +0100 From: warwick To: atlas at ripe.net Hello, Regarding the previous email: Measurements at an interval, below is the Json constructed for the measurement: / / /{'definitions': [{'description': '', 'use_probe_resolver': False, 'af': 6, 'query_argument': 'nlnetlabs.nl', 'query_type': 'AAAA', 'interval': 1200, 'query_class': 'IN', 'type': 'dns', 'is_oneoff': False, 'recursion_desired': False, 'target': '2001:7b8:40:1:d0e1::1'}], 'stop_time': 1386168052, 'probes': [{'requested': 100, 'type': 'area', 'value': 'WW'}]}/ And below is the response: /{"error": {"code": 104, "message": "You do not have enough credit to schedule this measurement."}}/ It seems as though it's a trivial mistake, that I might actually not have enough credits to perform this measurement but I'm sure I do since it's a simple DNS query with only 100 probes. With 50 probes: /{'definitions': [{'description': '', 'use_probe_resolver': False, 'af': 6, 'query_argument': 'nlnetlabs.nl', 'query_type': 'AAAA', 'interval': 1200, 'query_class': 'IN', 'type': 'dns', 'is_oneoff': False, 'recursion_desired': False, 'target': '2001:7b8:40:1:d0e1::1'}], 'stop_time': 1386168333, 'probes': [{'requested': 50, 'type': 'area', 'value': 'WW'}]}/ This request is executed as expected. With the following response: /{u'measurements': [...]}/ (measurement id removed.) To get past this problem we have been chunking our probes in groups of 50. I just thought you might be interested. Kind regards, Warwick Louw -------- Original Message -------- Subject: [ripe.net #1113749] Re: [atlas] Measurements at an interval Date: Wed, 4 Dec 2013 15:24:32 +0100 From: Robert Kisteleki Reply-To: atlas at ripe.net To: warwick at nlnetlabs.nl Hi, Got it, we'll look into this (probably early next week when the best person for this is back). Regards, Robert On 2013-12-04 14:09:08, warwick at nlnetlabs.nl wrote: > Hello, > > Regarding the previous email: Measurements at an interval, below is the > Json constructed for the measurement: > / > / > > /{'definitions': [{'description': '', 'use_probe_resolver': False, > 'af': 6, 'query_argument': 'nlnetlabs.nl', 'query_type': 'AAAA', > 'interval': 1200, 'query_class': 'IN', 'type': 'dns', 'is_oneoff': > False, 'recursion_desired': False, 'target': > '2001:7b8:40:1:d0e1::1'}], 'stop_time': 1386168052, 'probes': > [{'requested': 100, 'type': 'area', 'value': 'WW'}]}/ > > > And below is the response: > > /{"error": {"code": 104, "message": "You do not have enough credit > to schedule this measurement."}}/ > > > It seems as though it's a trivial mistake, that I might actually not > have enough credits to perform this measurement but I'm sure I do since > it's a simple DNS query with only 100 probes. > > With 50 probes: > > /{'definitions': [{'description': '', 'use_probe_resolver': False, > 'af': 6, 'query_argument': 'nlnetlabs.nl', 'query_type': 'AAAA', > 'interval': 1200, 'query_class': 'IN', 'type': 'dns', 'is_oneoff': > False, 'recursion_desired': False, 'target': > '2001:7b8:40:1:d0e1::1'}], 'stop_time': 1386168333, 'probes': > [{'requested': 50, 'type': 'area', 'value': 'WW'}]}/ > > > This request is executed as expected. With the following response: > > /{u'measurements': [...]}/ (measurement id removed.) > > > To get past this problem we have been chunking our probes in groups of > 50. I just thought you might be interested. > > Kind regards, > Warwick Louw > -- Robert Kisteleki, R&D Manager, RIPE NCC RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Fri Dec 13 16:43:26 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 13 Dec 2013 16:43:26 +0100 Subject: [atlas] Enjoy the holiday season with photos of RIPE Atlas probes Message-ID: <52AB2B1E.9040005@ripe.net> Dear colleagues, we have uploaded lots of pretty photos to the Community page: https://atlas.ripe.net/get-involved/community/#!tab-actionshots I am attaching the screenshot and one, most colorful photo. Please upload your own photos, and enjoy the holiday season. Share and Enjoy :) Vesna -------------- next part -------------- A non-text attachment was scrubbed... Name: holiday season.png Type: image/png Size: 719520 bytes Desc: not available URL: From robert at ripe.net Mon Dec 16 15:11:37 2013 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 16 Dec 2013 15:11:37 +0100 Subject: [atlas] Emergency RIPE Atlas firmware upgrade Message-ID: <52AF0A19.7090904@ripe.net> Dear RIPE Atlas users, We want to let you know about a recent issue in the RIPE Atlas system involving an open port on the latest generation (v3) probes. Due to an issue with the latest firmware release, a subset of the v3 probes were listening to incoming connections on an open port that should not have been left open. As a secondary measure, however, access to this port required credentials only available to the RIPE Atlas probe developers. It therefore never presented open access to the probes. This port (SSH) is used for development purposes in our internal development environment. We upgraded the v3 probes to a new, corrected firmware version, and improved the checks in our firmware release process. We would like to thank ZeelandNet for reporting the issue to us. We want to assure you that the security of the RIPE Atlas system is important to us. We are continually improving the controlling infrastructure as well as the probes themselves in order to prevent vulnerabilities. We apologise for this issue and want to stress that no probes were actually affected in any way. You can learn more about the security of the RIPE Atlas system on our dedicated security page at: https://atlas.ripe.net/docs/security/ Thank you for your continuing support of RIPE Atlas. Regards, Robert Kisteleki RIPE NCC From gert at space.net Mon Dec 16 15:36:58 2013 From: gert at space.net (Gert Doering) Date: Mon, 16 Dec 2013 15:36:58 +0100 Subject: [atlas] management access...? In-Reply-To: <52AF0A19.7090904@ripe.net> References: <52AF0A19.7090904@ripe.net> Message-ID: <20131216143658.GC81676@Space.Net> Hi, On Mon, Dec 16, 2013 at 03:11:37PM +0100, Robert Kisteleki wrote: > Due to an issue with the latest firmware release, a subset of the v3 probes > were listening to incoming connections on an open port that should not have > been left open. As a secondary measure, however, access to this port > required credentials only available to the RIPE Atlas probe developers. It > therefore never presented open access to the probes. This port (SSH) is used > for development purposes in our internal development environment. ... actually, it would be great to have some sort of local "tell me if you are fine?" port to connect to... One of my probes is being difficult (it has network, it connects to the NCC, but it claims to not have an USB stick - which requires an on-site visit) and the lack of basic local diagnostic besides "run tcpdump and see what is happening" has already caused me two on-site visits, and now a third one for "replace the USB stick" (and/or find a USB port with more power). Two of those trips could have been saved by being able to just connect to some sort of status port... Better diagnostics at the atlas dashboard would have helped me, too, but for cases like "I think I have network by my DNS isn't working" or "I think I have network but can't connect to my controllers" errors, local data might still be beneficial. 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: 826 bytes Desc: not available URL: From robert at ripe.net Mon Dec 16 16:13:37 2013 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 16 Dec 2013 16:13:37 +0100 Subject: [atlas] management access...? In-Reply-To: <20131216143658.GC81676@Space.Net> References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> Message-ID: <52AF18A1.1010603@ripe.net> Hi Gert, > Better diagnostics at the atlas dashboard would have helped me, too, > but for cases like "I think I have network by my DNS isn't working" or > "I think I have network but can't connect to my controllers" errors, > local data might still be beneficial. This is reasonable, but it leads to a place where probes *do* run services that are open to "all". I guess it's possible to redefine "all" to be "my local network" or "the same /24 or /64 as the probe" or such, but that adds complexity and I'd be reluctant to go that way. What we're trying to do is what you describe above -- based on signals sent by the probe we're trying to give useful clues to the hosts about what's going on. We can look at the current diagnostics and see if we already squeeze out as much diagnostics as possible. We also plan to include IPv6 PMTU problems, broken local resolvers and such in an upcoming iteration. Regards, Robert From nigel.titley at easynet.com Mon Dec 16 16:23:25 2013 From: nigel.titley at easynet.com (Nigel Titley) Date: Mon, 16 Dec 2013 15:23:25 +0000 Subject: [atlas] management access...? In-Reply-To: <52AF18A1.1010603@ripe.net> References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> Message-ID: Speaking with my Board hat on at the moment, I do not want to wake up one morning and read the headline "RIPE NCC deploys world's largest botnet" Keep them simple, keep them safe Nigel -----Original Message----- From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Robert Kisteleki Sent: 16 December 2013 15:14 To: Gert Doering Cc: ripe-atlas at ripe.net Subject: Re: [atlas] management access...? Hi Gert, > Better diagnostics at the atlas dashboard would have helped me, too, > but for cases like "I think I have network by my DNS isn't working" or > "I think I have network but can't connect to my controllers" errors, > local data might still be beneficial. This is reasonable, but it leads to a place where probes *do* run services that are open to "all". I guess it's possible to redefine "all" to be "my local network" or "the same /24 or /64 as the probe" or such, but that adds complexity and I'd be reluctant to go that way. What we're trying to do is what you describe above -- based on signals sent by the probe we're trying to give useful clues to the hosts about what's going on. We can look at the current diagnostics and see if we already squeeze out as much diagnostics as possible. We also plan to include IPv6 PMTU problems, broken local resolvers and such in an upcoming iteration. Regards, Robert From carsten at schiefner.de Mon Dec 16 16:58:27 2013 From: carsten at schiefner.de (Carsten Schiefner) Date: Mon, 16 Dec 2013 16:58:27 +0100 Subject: [atlas] management access...? In-Reply-To: References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> Message-ID: <52AF2323.4030106@schiefner.de> C'mon, Nigel - such an event every now and then would just keep you and your esteemed board collegues alert and prevent you from feeling bored. ;-b On 16.12.2013 16:23, Nigel Titley wrote: > Speaking with my Board hat on at the moment, I do not want to wake up > one morning and read the headline "RIPE NCC deploys world's largest > botnet" From dario.ciccarone at gmail.com Mon Dec 16 16:52:59 2013 From: dario.ciccarone at gmail.com (Dario Ciccarone) Date: Mon, 16 Dec 2013 10:52:59 -0500 Subject: [atlas] management access...? In-Reply-To: References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> Message-ID: I think that's a bit of an exaggeration :) I agree with Gert that probes need better diagnostic capabilities - and tcpdump just doesn't cut it. And probe or not probe, small form factor or not - it's a Linux box. I would like to be able to troubleshoot it like any other *nix box. There IS a middle ground here, I think. The current firmware image could stay as it is - no SSH, no incoming connections. A "full" image could be provided, that would allow: A) starting the SSH daemon B) configuring key-based authentication for SSH, allow importing of public keys C) configuring IP-based restrictions (iptables, or AllowUsers) As none of those would be the default configuration, and would NOT be enable thru the web-based admin interface, they shouldn't have a security impact on anyone that does NOT choose to enable them - but would be available for "power users", so to speak. On 12/16/13 10:23 AM, "Nigel Titley" wrote: >Speaking with my Board hat on at the moment, I do not want to wake up one >morning and read the headline "RIPE NCC deploys world's largest botnet" > >Keep them simple, keep them safe > >Nigel >-----Original Message----- >From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] On >Behalf Of Robert Kisteleki >Sent: 16 December 2013 15:14 >To: Gert Doering >Cc: ripe-atlas at ripe.net >Subject: Re: [atlas] management access...? > >Hi Gert, > >> Better diagnostics at the atlas dashboard would have helped me, too, >> but for cases like "I think I have network by my DNS isn't working" or >> "I think I have network but can't connect to my controllers" errors, >> local data might still be beneficial. > >This is reasonable, but it leads to a place where probes *do* run >services that are open to "all". I guess it's possible to redefine "all" >to be "my local network" or "the same /24 or /64 as the probe" or such, >but that adds complexity and I'd be reluctant to go that way. > >What we're trying to do is what you describe above -- based on signals >sent by the probe we're trying to give useful clues to the hosts about >what's going on. We can look at the current diagnostics and see if we >already squeeze out as much diagnostics as possible. We also plan to >include IPv6 PMTU problems, broken local resolvers and such in an >upcoming iteration. > >Regards, >Robert > > > From nigel.titley at easynet.com Mon Dec 16 16:58:53 2013 From: nigel.titley at easynet.com (Nigel Titley) Date: Mon, 16 Dec 2013 15:58:53 +0000 Subject: [atlas] management access...? In-Reply-To: References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> Message-ID: Of course it was an exaggeration.... but think about it.... 5000 identical machines with the same software. An exploit would go through them like a curry and a couple of pints of lager. Your half way house might be acceptable though Nigel -----Original Message----- From: Dario Ciccarone [mailto:dario.ciccarone at gmail.com] Sent: 16 December 2013 15:53 To: Nigel Titley; Robert Kisteleki; Gert Doering Cc: ripe-atlas at ripe.net Subject: Re: [atlas] management access...? I think that's a bit of an exaggeration :) I agree with Gert that probes need better diagnostic capabilities - and tcpdump just doesn't cut it. And probe or not probe, small form factor or not - it's a Linux box. I would like to be able to troubleshoot it like any other *nix box. There IS a middle ground here, I think. The current firmware image could stay as it is - no SSH, no incoming connections. A "full" image could be provided, that would allow: A) starting the SSH daemon B) configuring key-based authentication for SSH, allow importing of public keys C) configuring IP-based restrictions (iptables, or AllowUsers) As none of those would be the default configuration, and would NOT be enable thru the web-based admin interface, they shouldn't have a security impact on anyone that does NOT choose to enable them - but would be available for "power users", so to speak. On 12/16/13 10:23 AM, "Nigel Titley" wrote: >Speaking with my Board hat on at the moment, I do not want to wake up >one morning and read the headline "RIPE NCC deploys world's largest botnet" > >Keep them simple, keep them safe > >Nigel >-----Original Message----- >From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] >On Behalf Of Robert Kisteleki >Sent: 16 December 2013 15:14 >To: Gert Doering >Cc: ripe-atlas at ripe.net >Subject: Re: [atlas] management access...? > >Hi Gert, > >> Better diagnostics at the atlas dashboard would have helped me, too, >> but for cases like "I think I have network by my DNS isn't working" >> or "I think I have network but can't connect to my controllers" >> errors, local data might still be beneficial. > >This is reasonable, but it leads to a place where probes *do* run >services that are open to "all". I guess it's possible to redefine "all" >to be "my local network" or "the same /24 or /64 as the probe" or such, >but that adds complexity and I'd be reluctant to go that way. > >What we're trying to do is what you describe above -- based on signals >sent by the probe we're trying to give useful clues to the hosts about >what's going on. We can look at the current diagnostics and see if we >already squeeze out as much diagnostics as possible. We also plan to >include IPv6 PMTU problems, broken local resolvers and such in an >upcoming iteration. > >Regards, >Robert > > > From nigel.titley at easynet.com Mon Dec 16 16:59:38 2013 From: nigel.titley at easynet.com (Nigel Titley) Date: Mon, 16 Dec 2013 15:59:38 +0000 Subject: [atlas] management access...? In-Reply-To: <52AF2323.4030106@schiefner.de> References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> <52AF2323.4030106@schiefner.de> Message-ID: Boredom is good..... we like boredom -----Original Message----- From: Carsten Schiefner [mailto:carsten at schiefner.de] Sent: 16 December 2013 15:58 To: Nigel Titley Cc: ripe-atlas at ripe.net Subject: Re: [atlas] management access...? C'mon, Nigel - such an event every now and then would just keep you and your esteemed board collegues alert and prevent you from feeling bored. ;-b On 16.12.2013 16:23, Nigel Titley wrote: > Speaking with my Board hat on at the moment, I do not want to wake up > one morning and read the headline "RIPE NCC deploys world's largest > botnet" From gert at space.net Mon Dec 16 17:10:07 2013 From: gert at space.net (Gert Doering) Date: Mon, 16 Dec 2013 17:10:07 +0100 Subject: [atlas] management access...? In-Reply-To: <52AF18A1.1010603@ripe.net> References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> Message-ID: <20131216161007.GD81676@Space.Net> Hi, On Mon, Dec 16, 2013 at 04:13:37PM +0100, Robert Kisteleki wrote: > What we're trying to do is what you describe above -- based on signals > sent by the probe we're trying to give useful clues to the hosts about > what's going on. We can look at the current diagnostics and see if we > already squeeze out as much diagnostics as possible. We also plan to > include IPv6 PMTU problems, broken local resolvers and such in an upcoming > iteration. Well, right now the probe in question is listed in the dashboard as "abandoned", while it does send a panic DNS query every few minutes... 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: 826 bytes Desc: not available URL: From gert at space.net Mon Dec 16 17:11:59 2013 From: gert at space.net (Gert Doering) Date: Mon, 16 Dec 2013 17:11:59 +0100 Subject: [atlas] management access...? In-Reply-To: <52AF18A1.1010603@ripe.net> References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> Message-ID: <20131216161159.GE81676@Space.Net> Hi, On Mon, Dec 16, 2013 at 04:13:37PM +0100, Robert Kisteleki wrote: > > Better diagnostics at the atlas dashboard would have helped me, too, > > but for cases like "I think I have network by my DNS isn't working" or > > "I think I have network but can't connect to my controllers" errors, > > local data might still be beneficial. > > This is reasonable, but it leads to a place where probes *do* run services > that are open to "all". I guess it's possible to redefine "all" to be "my > local network" or "the same /24 or /64 as the probe" or such, but that > adds complexity and I'd be reluctant to go that way. I can understand that, though. I wouldn't want an SSH access to it, more something what the old TTM boxes had - a port where you can telnet to, which would completely ignore whatever you send to it, but which would spit out some sort of one-line health status. Limited to "the local network" (which is not *that* hard to figure out). 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: 826 bytes Desc: not available URL: From nick at inex.ie Mon Dec 16 17:12:31 2013 From: nick at inex.ie (Nick Hilliard) Date: Mon, 16 Dec 2013 16:12:31 +0000 Subject: [atlas] management access...? In-Reply-To: References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> <52AF2323.4030106@schiefner.de> Message-ID: <52AF266F.5030202@inex.ie> On 16/12/2013 15:59, Nigel Titley wrote: > Boredom is good..... we like boredom "chairman of the bored". Nick From the.lists at mgm51.com Mon Dec 16 17:14:34 2013 From: the.lists at mgm51.com (Mike.) Date: Mon, 16 Dec 2013 11:14:34 -0500 Subject: [atlas] management access...? In-Reply-To: References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> <52AF2323.4030106@schiefner.de> Message-ID: <201312161114340939.0584027C@smtp.24cl.home> On 12/16/2013 at 3:59 PM Nigel Titley wrote: |Boredom is good..... we like boredom ============= Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --- Albert Einstein From dario.ciccarone at gmail.com Mon Dec 16 17:18:54 2013 From: dario.ciccarone at gmail.com (Dario Ciccarone) Date: Mon, 16 Dec 2013 11:18:54 -0500 Subject: [atlas] management access...? In-Reply-To: References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> Message-ID: I indeed agree that they would be a tempting target - IPv4 and IPv6 both. However, they're low powered devices - DDoS sources, maybe - amplification attacks. Don't see them doing any BitCoin mining any time soon :) But yes, depending on where on the host network they sit, they could be used as stepping stones . . . A good reason for people deploying a probe to understand the inherent risks of deploying it. And an opportunity for the Atlas community to share best practices/deployment scenarios. My probe sits on a DMZ, w/o access to the internal network. And I haven't implemented rate-limiting for it - but come to think of it, it may be a good idea to do so - limit the probe to 512Kbps or less. On 12/16/13 10:58 AM, "Nigel Titley" wrote: >Of course it was an exaggeration.... but think about it.... 5000 >identical machines with the same software. An exploit would go through >them like a curry and a couple of pints of lager. > >Your half way house might be acceptable though > >Nigel > >-----Original Message----- >From: Dario Ciccarone [mailto:dario.ciccarone at gmail.com] >Sent: 16 December 2013 15:53 >To: Nigel Titley; Robert Kisteleki; Gert Doering >Cc: ripe-atlas at ripe.net >Subject: Re: [atlas] management access...? > >I think that's a bit of an exaggeration :) > >I agree with Gert that probes need better diagnostic capabilities - and >tcpdump just doesn't cut it. And probe or not probe, small form factor or >not - it's a Linux box. I would like to be able to troubleshoot it like >any other *nix box. > >There IS a middle ground here, I think. The current firmware image could >stay as it is - no SSH, no incoming connections. A "full" image could be >provided, that would allow: > >A) starting the SSH daemon >B) configuring key-based authentication for SSH, allow importing of >public keys >C) configuring IP-based restrictions (iptables, or AllowUsers) > >As none of those would be the default configuration, and would NOT be >enable thru the web-based admin interface, they shouldn't have a security >impact on anyone that does NOT choose to enable them - but would be >available for "power users", so to speak. > > >On 12/16/13 10:23 AM, "Nigel Titley" wrote: > >>Speaking with my Board hat on at the moment, I do not want to wake up >>one morning and read the headline "RIPE NCC deploys world's largest >>botnet" >> >>Keep them simple, keep them safe >> >>Nigel >>-----Original Message----- >>From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] >>On Behalf Of Robert Kisteleki >>Sent: 16 December 2013 15:14 >>To: Gert Doering >>Cc: ripe-atlas at ripe.net >>Subject: Re: [atlas] management access...? >> >>Hi Gert, >> >>> Better diagnostics at the atlas dashboard would have helped me, too, >>> but for cases like "I think I have network by my DNS isn't working" >>> or "I think I have network but can't connect to my controllers" >>> errors, local data might still be beneficial. >> >>This is reasonable, but it leads to a place where probes *do* run >>services that are open to "all". I guess it's possible to redefine "all" >>to be "my local network" or "the same /24 or /64 as the probe" or such, >>but that adds complexity and I'd be reluctant to go that way. >> >>What we're trying to do is what you describe above -- based on signals >>sent by the probe we're trying to give useful clues to the hosts about >>what's going on. We can look at the current diagnostics and see if we >>already squeeze out as much diagnostics as possible. We also plan to >>include IPv6 PMTU problems, broken local resolvers and such in an >>upcoming iteration. >> >>Regards, >>Robert >> >> >> > > From carsten at schiefner.de Mon Dec 16 17:20:57 2013 From: carsten at schiefner.de (Carsten Schiefner) Date: Mon, 16 Dec 2013 17:20:57 +0100 Subject: [atlas] management access...? In-Reply-To: <52AF266F.5030202@inex.ie> References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> <52AF2323.4030106@schiefner.de> <52AF266F.5030202@inex.ie> Message-ID: <52AF2869.7000003@schiefner.de> Thanks, Nick - I intentionally left this one for somebody else to coin, :-D On 16.12.2013 17:12, Nick Hilliard wrote: > On 16/12/2013 15:59, Nigel Titley wrote: >> Boredom is good..... we like boredom > > "chairman of the bored". From cwerny at ernw.de Mon Dec 16 23:19:00 2013 From: cwerny at ernw.de (Christopher Werny) Date: Mon, 16 Dec 2013 22:19:00 +0000 Subject: [atlas] IPv6 Gateway Undetermined/Unknown Message-ID: Hi Everybody, we received our probe a couple of days ago and after successful "deployment" (with static configuration), I noticed that the Configuration pane states that the IPv6 gateway is in the state "Undetermined/Unknown". It is correctly configured and IPv6 measurements are working fine. I couldn't find anything related to my "observation", hence why I am asking here. I just want to make sure I did everything right and whether this might be a known bug or limitation? Thanks for your time. Cheers, Christopher From madis555 at hot.ee Tue Dec 17 00:20:27 2013 From: madis555 at hot.ee (Sulev-Madis Silber) Date: Tue, 17 Dec 2013 01:20:27 +0200 Subject: [atlas] management access...? In-Reply-To: <52AF2869.7000003@schiefner.de> References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> <52AF2323.4030106@schiefner.de> <52AF266F.5030202@inex.ie> <52AF2869.7000003@schiefner.de> Message-ID: <52AF8ABB.9020500@hot.ee> I wonder why no one else suggested this before. As v3 probes have physical switch, it could be used to turn on some debugging mode temporarily... or what? From robert at ripe.net Tue Dec 17 09:16:20 2013 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 17 Dec 2013 09:16:20 +0100 Subject: [atlas] IPv6 Gateway Undetermined/Unknown In-Reply-To: References: Message-ID: <52B00854.20606@ripe.net> On 2013.12.16. 23:19, Christopher Werny wrote: > Hi Everybody, > > we received our probe a couple of days ago and after successful "deployment" (with static configuration), I noticed that the Configuration pane states that the IPv6 gateway is in the state "Undetermined/Unknown". It is correctly configured and IPv6 measurements are working fine. I couldn't find anything related to my "observation", hence why I am asking here. I just want to make sure I did everything right and whether this might be a known bug or limitation? > > Thanks for your time. > > Cheers, > Christopher Hello, This is listed in the "known bugs" documentation section (https://atlas.ripe.net/docs/bugs/): "The user interface never shows any IPv6 gateway; the entry is always displayed as "Undetermined/Unknown."" We made some internal changes regarding this in the last couple of months, so it's possible that we'll fill this field out soon. (But it's not as easy as for IPv4.) Regards, Robert From philip.homburg at ripe.net Tue Dec 17 10:09:42 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 17 Dec 2013 10:09:42 +0100 Subject: [atlas] management access...? In-Reply-To: <52AF8ABB.9020500@hot.ee> References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> <52AF2323.4030106@schiefner.de> <52AF266F.5030202@inex.ie> <52AF2869.7000003@schiefner.de> <52AF8ABB.9020500@hot.ee> Message-ID: <52B014D6.6090009@ripe.net> On 2013/12/17 0:20 , Sulev-Madis Silber wrote: > I wonder why no one else suggested this before. As v3 probes have > physical switch, it could be used to turn on some debugging mode > temporarily... or what? Maybe it is good to take a step backward and focus on what should be reported instead of how it should be reported. On v3 probes, the LEDs blink in various patterns to indicate what is going on. As soon as probes have any kind of network connectivity they start reporting what they are doing. Now, it is quite possible that some of that only makes it to our logs and not to the user interface. But in that case it would probably more effective to update the user interface rather than to create alternative mechanisms of reporting status information. If anyone has stories on what the probe didn't report, then I'd like to hear them. Philip From BECHA at ripe.net Tue Dec 17 12:23:56 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 17 Dec 2013 12:23:56 +0100 Subject: [atlas] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: References: Message-ID: <52B0344C.5080109@ripe.net> Dear colleagues, Sharing information about Internet performance is at the heart of collaborative efforts such as RIPE Atlas. Most of the RIPE Atlas probes and RIPE Atlas measurements are already public, and we'd now like to suggest opening up the publication of RIPE Atlas data further. We also want to clarify exactly what is and isn't public in the current system. We describe this in more detail in this RIPE Labs article, where we also ask for community feedback about our suggested plan to move forward: https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public Our proposed plan is to make all *new* measurements and technical information about the *new* probes public from an agreed upon date in the future. We propose implementing this change in mid-April. All probes and measurements that were not marked "public" by April 2014 would remain non-"public". For a detailed description of what this means, please see the RIPE Labs article (above). Although we believe that having public measurement data contributes to the goal of RIPE Atlas, the RIPE NCC greatly values our users' privacy. We want to ensure you that we will continue to protect our probe hosts' personal information. We look forward to your feedback and comments on the MAT Working Group Mailing List. Regards, Vesna Manojlovic Senior Community Builder Measurements Community Building RIPE NCC From v.bajpai at jacobs-university.de Tue Dec 17 12:43:56 2013 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Tue, 17 Dec 2013 11:43:56 +0000 Subject: [atlas] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <52B0344C.5080109@ripe.net> References: <52B0344C.5080109@ripe.net> Message-ID: <7249E3EB-8EF8-4E87-B920-AB7AA9FCD693@jacobs-university.de> On 17 Dec 2013, at 12:23, Vesna Manojlovic wrote: > Dear colleagues, > > Sharing information about Internet performance is at the heart of collaborative efforts such as RIPE Atlas. > > Most of the RIPE Atlas probes and RIPE Atlas measurements are already public, and we'd now like to suggest > opening up the publication of RIPE Atlas data further. We also want to clarify exactly what is and isn?t > public in the current system. We describe this in more detail in this RIPE Labs article, where we also ask > for community feedback about our suggested plan to move forward: > https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public [...] > > We look forward to your feedback and comments on the MAT Working Group Mailing List. Hello, Thanks for the initiative. I support this. Additionally, would it be possible to open the built-in measurements of public probes? (via REST API) Suppose, I am interested in analysing the latency to k.root-servers.net from probes X (public) and Y (public) specifically. I have 3 options: a) Search a UDM that is running this measurement on probe X and Y, and download that JSON data. b) Run my own UDM using probe X and Y. c) Fetch the RIPE?s in-built ping4 and ping6 measurements to k.root-servers.net for X and Y. a) is tedious. b) is what I would do now, however it not only consumes my credit, but also puts measurement load on X and Y, even though X and Y are already running this through RIPE?s in-built measurement. In addition, the timeline of your in-built measurement will be much richer than what I can achieve through a UDM. It would be great if I could make a REST call to fetch the richer dataset in c) Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gert at space.net Tue Dec 17 12:54:15 2013 From: gert at space.net (Gert Doering) Date: Tue, 17 Dec 2013 12:54:15 +0100 Subject: [atlas] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <52B0344C.5080109@ripe.net> References: <52B0344C.5080109@ripe.net> Message-ID: <20131217115415.GQ81676@Space.Net> Hi, On Tue, Dec 17, 2013 at 12:23:56PM +0100, Vesna Manojlovic wrote: > Our proposed plan is to make all *new* measurements and technical > information about the *new* probes public from an agreed upon date > in the future. We propose implementing this change in mid-April. I'd support changing the default to "public", but I can't see a compelling reason why you would want to make *everything* public. What if I'm measuring something, where I know some bits of my network are broken but need to figure out the overall damage, that I don't want the competition and media to know (if they figure it out themselves, fine, but not handing it on a silver platter). 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: 826 bytes Desc: not available URL: From Ondrej.Caletka at cesnet.cz Tue Dec 17 13:05:36 2013 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?B?T25kxZllaiBDYWxldGth?=) Date: Tue, 17 Dec 2013 13:05:36 +0100 Subject: [atlas] management access...? In-Reply-To: <52B014D6.6090009@ripe.net> References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> <52AF2323.4030106@schiefner.de> <52AF266F.5030202@inex.ie> <52AF2869.7000003@schiefner.de> <52AF8ABB.9020500@hot.ee> <52B014D6.6090009@ripe.net> Message-ID: <52B03E10.7000805@cesnet.cz> Hi list, Dne 17.12.2013 10:09, Philip Homburg napsal(a): > If anyone has stories on what the probe didn't report, then I'd like to > hear them. My probe had perfect network connectivity, however it somehow turned its status into ?disconnected? and then ?abandoned?, although it still responded to ICMP(v6) ping. Visiting it personally, I found nothing wrong, except the LEDs was blinking in the pattern ?running from internal memory?. Long story short, after few round trips with Atlas support, I found out that the probe may be repaired by unplugging the USB flash drive, overwritting it with zeros and plugging it back in. It would be really nice if this state of probe was displayed somewhere, because the probe was certainly able to talk to the controller. Personally, I would prefer simple status webpage on the probe itself. Read-only access without authentication would suit this purpose perfectly without much extra complexity or security issues. Regards, 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 gilles.massen at restena.lu Tue Dec 17 13:28:21 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Tue, 17 Dec 2013 13:28:21 +0100 Subject: [atlas] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <20131217115415.GQ81676@Space.Net> References: <52B0344C.5080109@ripe.net> <20131217115415.GQ81676@Space.Net> Message-ID: <52B04365.9030801@restena.lu> Hi, > I'd support changing the default to "public", but I can't see a compelling > reason why you would want to make *everything* public. > > What if I'm measuring something, where I know some bits of my network are > broken but need to figure out the overall damage, that I don't want the > competition and media to know (if they figure it out themselves, fine, but > not handing it on a silver platter). I agree very much with this thinking. Personally I could live with non-public data becoming public a few days after the measurement, but if everything is public in realtime Atlas would lose a lot of its attractiveness as debugging tool. best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From philip.homburg at ripe.net Tue Dec 17 13:43:58 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 17 Dec 2013 13:43:58 +0100 Subject: [atlas] management access...? In-Reply-To: <52B03E10.7000805@cesnet.cz> References: <52AF0A19.7090904@ripe.net> <20131216143658.GC81676@Space.Net> <52AF18A1.1010603@ripe.net> <52AF2323.4030106@schiefner.de> <52AF266F.5030202@inex.ie> <52AF2869.7000003@schiefner.de> <52AF8ABB.9020500@hot.ee> <52B014D6.6090009@ripe.net> <52B03E10.7000805@cesnet.cz> Message-ID: <52B0470E.4070808@ripe.net> On 2013/12/17 13:05 , Ond?ej Caletka wrote: > My probe had perfect network connectivity, however it somehow turned its > status into ?disconnected? and then ?abandoned?, although it still > responded to ICMP(v6) ping. Visiting it personally, I found nothing > wrong, except the LEDs was blinking in the pattern ?running from > internal memory?. Long story short, after few round trips with Atlas > support, I found out that the probe may be repaired by unplugging the > USB flash drive, overwritting it with zeros and plugging it back in. > > It would be really nice if this state of probe was displayed somewhere, > because the probe was certainly able to talk to the controller. > Personally, I would prefer simple status webpage on the probe itself. > Read-only access without authentication would suit this purpose > perfectly without much extra complexity or security issues. In this case, you should have had a couple of emails from the Atlas system that your probe was not connected. I think the first one is sent when the probe is not connected for two weeks. This is a situation where the user interface has to be updated. The probe did report that it could not find its USB stick. But that information is not shown to the probe host. Unfortunately, in situations with marginal USB power supplies, probe behavior can become weird. Like overwriting the USB stick is not supposed to have any effect. But in this case it did. Philip From pk at DENIC.DE Tue Dec 17 13:52:54 2013 From: pk at DENIC.DE (Peter Koch) Date: Tue, 17 Dec 2013 13:52:54 +0100 Subject: [atlas] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <52B04365.9030801@restena.lu> References: <52B0344C.5080109@ripe.net> <20131217115415.GQ81676@Space.Net> <52B04365.9030801@restena.lu> Message-ID: <20131217125254.GW16803@x28.adm.denic.de> On Tue, Dec 17, 2013 at 01:28:21PM +0100, Gilles Massen wrote: > I agree very much with this thinking. Personally I could live with > non-public data becoming public a few days after the measurement, but if > everything is public in realtime Atlas would lose a lot of its > attractiveness as debugging tool. there are two aspects: 1) disclosure of the meaasurements and results I agree with Gilles and Gert that there is a difference between the results of measurements and the fact that something is measured right now and here. A publication delay seems the minimum to me, but for one off measurements in particular there might be reasons to not ever disclose them. 2) privacy of the probe host Maybe we need to work on "privacy considerations for probe hosts"; The ability to track the last 25 "connections" allows tracking the probe's IP address (maybe that's possible even easier?) and I'm not sure every host is aware of that. Opt-In is probably the very least we can do. -Peter From dario.ciccarone at gmail.com Tue Dec 17 15:38:38 2013 From: dario.ciccarone at gmail.com (Dario Ciccarone) Date: Tue, 17 Dec 2013 09:38:38 -0500 Subject: [atlas] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <20131217115415.GQ81676@Space.Net> References: <52B0344C.5080109@ripe.net> <20131217115415.GQ81676@Space.Net> Message-ID: +1 On 12/17/13 6:54 AM, "Gert Doering" wrote: >Hi, > >On Tue, Dec 17, 2013 at 12:23:56PM +0100, Vesna Manojlovic wrote: >> Our proposed plan is to make all *new* measurements and technical >> information about the *new* probes public from an agreed upon date >> in the future. We propose implementing this change in mid-April. > >I'd support changing the default to "public", but I can't see a compelling >reason why you would want to make *everything* public. > >What if I'm measuring something, where I know some bits of my network are >broken but need to figure out the overall damage, that I don't want the >competition and media to know (if they figure it out themselves, fine, but >not handing it on a silver platter). > >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 From mgalante at ripe.net Tue Dec 17 16:25:07 2013 From: mgalante at ripe.net (Michela Galante) Date: Tue, 17 Dec 2013 16:25:07 +0100 Subject: [atlas] ATE (FR) has joined RIPE Atlas anchors Message-ID: <8E1D593B-5712-42D0-9FEC-FAB60568744C@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 fr-zdb-as35625 and is hosted by ATE in Sainghin en M?lantois, France. 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: 2626 bytes Desc: not available URL: From s.eravuchira at jacobs-university.de Tue Dec 17 16:44:22 2013 From: s.eravuchira at jacobs-university.de (Eravuchira, Steffie Jacob) Date: Tue, 17 Dec 2013 15:44:22 +0000 Subject: [atlas] (no subject) Message-ID: <081E9415D79F9A469A4B6C79815FC0926E3158@SXCHMB01.jacobs.jacobs-university.de> Hi, There are three hardware versions of RIPE Atlas probes namely v1,v2 and v3. Each of the support different firmware versions. Can I get the latest firmware version supported by each the hardware versions? Thanks, Steffie From robert at ripe.net Tue Dec 17 20:05:38 2013 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 17 Dec 2013 20:05:38 +0100 Subject: [atlas] (no subject) In-Reply-To: <081E9415D79F9A469A4B6C79815FC0926E3158@SXCHMB01.jacobs.jacobs-university.de> References: <081E9415D79F9A469A4B6C79815FC0926E3158@SXCHMB01.jacobs.jacobs-university.de> Message-ID: <52B0A082.8040306@ripe.net> On 2013.12.17. 16:44, Eravuchira, Steffie Jacob wrote: > Hi, > > There are three hardware versions of RIPE Atlas probes namely v1,v2 and > v3. Each of the support different firmware versions. Can I get the latest > firmware version supported by each the hardware versions? > > Thanks, Steffie Hello, Usually the different hardware revisions run the same firmware version. Currently that's not the case (v3 is one version ahead at 4580, v1/2 are at 4570). The system automatically notifies probes about the latest firmware available for that hardware revision whenever the probe reconnects. The probe then upgrades right away, if the latest version is not yet installed. This requires no intervention from the probe host. If the probe is otherwise up and running happily, then it does not get the notification, therefore does not upgrade until the next reconnect. So in general we have a lazy upgrade approach. As of right now, all connected probes across all probe hardware revisions are running the latest firmware version available (with the exception of two misbehaving v2 probes). Hope this helps, Robert From liman at netnod.se Wed Dec 18 14:15:17 2013 From: liman at netnod.se (Lars-Johan Liman) Date: Wed, 18 Dec 2013 14:15:17 +0100 Subject: [atlas] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <52B04365.9030801@restena.lu> (Gilles Massen's message of "Tue, 17 Dec 2013 13:28:21 +0100") References: <52B0344C.5080109@ripe.net> <20131217115415.GQ81676@Space.Net> <52B04365.9030801@restena.lu> Message-ID: <22wqj22tcq.fsf@ziptop.autonomica.net> gilles.massen at restena.lu: > Hi, >> I'd support changing the default to "public", but I can't see a compelling >> reason why you would want to make *everything* public. >> >> What if I'm measuring something, where I know some bits of my network are >> broken but need to figure out the overall damage, that I don't want the >> competition and media to know (if they figure it out themselves, fine, but >> not handing it on a silver platter). > I agree very much with this thinking. Personally I could live with > non-public data becoming public a few days after the measurement, but if > everything is public in realtime Atlas would lose a lot of its > attractiveness as debugging tool. Agreed. ... and I would add that I don't want DDoS culprits to be able to use Atlas as a real-time assessment tool of the effectiveness of their attacks. (Maybe they can already, but let's not help them more.) Publishing delayed data is better. Cheers, /Liman #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman at netnod.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Netnod Internet Exchange, Stockholm ! http://www.netnod.se/ #---------------------------------------------------------------------- From mgalante at ripe.net Thu Dec 19 12:44:04 2013 From: mgalante at ripe.net (Michela Galante) Date: Thu, 19 Dec 2013 12:44:04 +0100 Subject: [atlas] DANTE (UK) has joined RIPE Atlas anchors Message-ID: <94990E46-D4C9-428D-897A-75E870577F9D@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 uk-lcy-as20965 and is hosted by DANTE in London, United Kingdom. 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: 2626 bytes Desc: not available URL: From BECHA at ripe.net Thu Dec 19 16:44:36 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 19 Dec 2013 16:44:36 +0100 Subject: [atlas] Updated RIPE Atlas roadmap Message-ID: <52B31464.8020504@ripe.net> Dear colleagues, we have considered the feedback we have received from you in the previous few months, on this list and MAT-wg mailing list, and last week we have made an updated version of the roadmap: http://roadmap.ripe.net/ripe-atlas/ We have added few new items under "requested features", and shifted some of the previously requested and planned towards "in progress". We are updating this document every two months, so you can expect newer requests to be added early next year. Regards, Vesna From gboonie at gmail.com Thu Dec 19 19:26:04 2013 From: gboonie at gmail.com (dave) Date: Thu, 19 Dec 2013 19:26:04 +0100 Subject: [atlas] Updated RIPE Atlas roadmap In-Reply-To: <52B31464.8020504@ripe.net> References: <52B31464.8020504@ripe.net> Message-ID: <72652D0C-9CE6-4398-AFD1-CCE3DD429AEC@gmail.com> Hi, Why is 'quick Look DNS' not available for all users? Also, I'd love to have constrains for probe selection. This would allow to ping from i.e. 3 probes in each AS. Please consider such a feature. Thanks, Dave. ----- Quick Look DNS Introduce easy to use 'Quick Look' DNS measurements with rapid results for RIPE NCC members > Op 19 dec. 2013 om 16:44 heeft Vesna Manojlovic het volgende geschreven: > > Dear colleagues, > > we have considered the feedback we have received from you in the previous few months, on this list and MAT-wg mailing list, and last week we have made an updated version of the roadmap: > > http://roadmap.ripe.net/ripe-atlas/ > > We have added few new items under "requested features", and shifted some of the previously requested and planned towards "in progress". > > We are updating this document every two months, so you can expect newer requests to be added early next year. > > Regards, > Vesna > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Thu Dec 19 19:34:47 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 19 Dec 2013 19:34:47 +0100 Subject: [atlas] Updated RIPE Atlas roadmap In-Reply-To: <72652D0C-9CE6-4398-AFD1-CCE3DD429AEC@gmail.com> References: <52B31464.8020504@ripe.net> <72652D0C-9CE6-4398-AFD1-CCE3DD429AEC@gmail.com> Message-ID: <52B33C47.8050001@ripe.net> On 2013/12/19 19:26 , dave wrote: > Also, I'd love to have constrains for probe selection. This would allow > to ping from i.e. 3 probes in each AS. Please consider such a feature. Just thinking out loud, is this something that should be part of the web UI? Before you know it, probe selection becomes some sort of complex filter language that can do anything, but nobody knows how to use it. Instead, it may be worth doing these kinds of things through the API: download the complete list of probes, apply your filter criteria and then create a measurement that involves the probes that match. Philip From gboonie at gmail.com Thu Dec 19 21:25:06 2013 From: gboonie at gmail.com (dave) Date: Thu, 19 Dec 2013 21:25:06 +0100 Subject: [atlas] Updated RIPE Atlas roadmap In-Reply-To: <52B33C47.8050001@ripe.net> References: <52B31464.8020504@ripe.net> <72652D0C-9CE6-4398-AFD1-CCE3DD429AEC@gmail.com> <52B33C47.8050001@ripe.net> Message-ID: <67CFC230-6E26-4DB2-9083-2C1D89F2283E@gmail.com> Hi Philip, Working via API is not something anyone can do. Also, it seem to me to be something for a measurement which was given quite some thought. The web UI allows novice users to do a quick test as a tool for faultfinding. No API knowledge needed. That is what I'm using Atlas for. Quick short tests from multiple points. Thanks for your response. > Op 19 dec. 2013 om 19:34 heeft Philip Homburg het volgende geschreven: > >> On 2013/12/19 19:26 , dave wrote: >> Also, I'd love to have constrains for probe selection. This would allow >> to ping from i.e. 3 probes in each AS. Please consider such a feature. > > Just thinking out loud, is this something that should be part of the web > UI? Before you know it, probe selection becomes some sort of complex > filter language that can do anything, but nobody knows how to use it. > > Instead, it may be worth doing these kinds of things through the API: > download the complete list of probes, apply your filter criteria and > then create a measurement that involves the probes that match. From mgalante at ripe.net Fri Dec 20 10:27:58 2013 From: mgalante at ripe.net (Michela Galante) Date: Fri, 20 Dec 2013 10:27:58 +0100 Subject: [atlas] SOX (RS) has joined RIPE Atlas anchors Message-ID: <1A277628-D3DC-45CF-8BB1-794F270DD51C@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 rs-beg-as13004 and is hosted by SOX (Serbian Open eXchange) in Belgrade, Serbia. 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: 2626 bytes Desc: not available URL: From lukasz at wsisiz.edu.pl Fri Dec 20 11:59:13 2013 From: lukasz at wsisiz.edu.pl (Lukasz Trabinski) Date: Fri, 20 Dec 2013 11:59:13 +0100 (CET) Subject: [atlas] BGP hijacking Message-ID: Hi I know that is not related with RIPE atlas, but maybe do know where to report in RIPE BGP hijacking topic? >From today BGP table: 46.0.0.0/8 xx 33 6939 5541 I 77.0.0.0/8 xxx 33 6939 5541 I 89.0.0.0/8 xxx 33 6939 5541 I 91.0.0.0/8 xxx 33 6939 5541 I 94.0.0.0/8 xxx 33 6939 5541 I 95.0.0.0/8 xxx 33 6939 5541 I From bortzmeyer at nic.fr Fri Dec 20 12:37:58 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 20 Dec 2013 12:37:58 +0100 Subject: [atlas] BGP hijacking In-Reply-To: References: Message-ID: <20131220113758.GA7263@nic.fr> On Fri, Dec 20, 2013 at 11:59:13AM +0100, Lukasz Trabinski wrote a message of 20 lines which said: > I know that is not related with RIPE atlas, but maybe do know where > to report in RIPE BGP hijacking topic? Apparently, they did not went too far? RIPE stat does not see them (yet?). Neither does the looking glass of the upstream From lukasz at trabinski.net Fri Dec 20 12:45:28 2013 From: lukasz at trabinski.net (=?UTF-8?B?xYF1a2FzeiBUcsSFYmnFhHNraQ==?=) Date: Fri, 20 Dec 2013 12:45:28 +0100 Subject: [atlas] BGP hijacking In-Reply-To: <20131220113758.GA7263@nic.fr> References: <20131220113758.GA7263@nic.fr> Message-ID: from lg.he.net: core1.fmt1.he.net> show ip bgp routes detail 46.0.0.0/8 Number of BGP Routes matching display condition : 1 S:SUPPRESSED F:FILTERED s:STALE 1 Prefix: 46.0.0.0/8, Status: BI, Age: 10h37m29s NEXT_HOP: 216.66.87.162, Metric: 1869, Learned from Peer: 216.218.252.169 (6939) LOCAL_PREF: 140, MED: 20, ORIGIN: igp, Weight: 0 AS_PATH: 5541 COMMUNITIES: 6939:1001 6939:1002 6939:1510 6939:1000 Last update to IP routing table: 10h37m29s, 1 path(s) installed: # Entry cached for another 60 seconds. 2013/12/20 Stephane Bortzmeyer > On Fri, Dec 20, 2013 at 11:59:13AM +0100, > Lukasz Trabinski wrote > a message of 20 lines which said: > > > I know that is not related with RIPE atlas, but maybe do know where > > to report in RIPE BGP hijacking topic? > > Apparently, they did not went too far? RIPE stat does not see them > (yet?). > > Neither does the looking glass of the upstream > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wilhelm at ripe.net Fri Dec 20 13:00:49 2013 From: wilhelm at ripe.net (Rene Wilhelm) Date: Fri, 20 Dec 2013 13:00:49 +0100 Subject: [atlas] BGP hijacking In-Reply-To: <20131220113758.GA7263@nic.fr> References: <20131220113758.GA7263@nic.fr> Message-ID: <52B43171.7020303@ripe.net> On 12/20/13 12:37 PM, Stephane Bortzmeyer wrote: > On Fri, Dec 20, 2013 at 11:59:13AM +0100, > Lukasz Trabinski wrote > a message of 20 lines which said: > >> I know that is not related with RIPE atlas, but maybe do know where >> to report in RIPE BGP hijacking topic? > Apparently, they did not went too far? RIPE stat does not see them > (yet?). They are visible in the BGPlay widget. For example https://stat.ripe.net/widget/bgplay#w.resource=46.0.0.0%2F8 First announced yesterday at 23:00 UTC. Seen by in total 120 peers on 13 RIS route collectors. The RIPEstat at-a-glance page, https://stat.ripe.net/46/8#tabId=at-a-glance , does not show them yet because the backend powering those widgets does not have the most recent data. As the warning in the prefix-overview and routing-status widgets says, the data there is at this moment 35 hours old. We are working on replacing that backend system by one which process the RIS data more timely. In near future the delays will be much shorter. -- Rene > Neither does the looking glass of the upstream > > > From philip.homburg at ripe.net Fri Dec 20 13:06:59 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 20 Dec 2013 13:06:59 +0100 Subject: [atlas] Updated RIPE Atlas roadmap In-Reply-To: <67CFC230-6E26-4DB2-9083-2C1D89F2283E@gmail.com> References: <52B31464.8020504@ripe.net> <72652D0C-9CE6-4398-AFD1-CCE3DD429AEC@gmail.com> <52B33C47.8050001@ripe.net> <67CFC230-6E26-4DB2-9083-2C1D89F2283E@gmail.com> Message-ID: <52B432E3.7070004@ripe.net> On 2013/12/19 21:25 , dave wrote: > Working via API is not something anyone can do. Also, it seem to me to be something for a measurement which was given quite some thought. > > The web UI allows novice users to do a quick test as a tool for faultfinding. No API knowledge needed. That is what I'm using Atlas for. Quick short tests from multiple points. Using the API does not imply that you have to write the script yourself. There have been quite a few requests for probe selection features. I sort of wonder if those can be implemented without leading to complexity that nobody can understand anymore. Philip From lukasz at trabinski.net Fri Dec 20 13:30:02 2013 From: lukasz at trabinski.net (=?UTF-8?B?xYF1a2FzeiBUcsSFYmnFhHNraQ==?=) Date: Fri, 20 Dec 2013 13:30:02 +0100 Subject: [atlas] BGP hijacking In-Reply-To: References: <20131220113758.GA7263@nic.fr> Message-ID: Hi again. Well. It seems to be fixed. 2013/12/20 ?ukasz Tr?bi?ski > from lg.he.net: > > core1.fmt1.he.net> show ip bgp routes detail 46.0.0.0/8 > Number of BGP Routes matching display condition : 1 > S:SUPPRESSED F:FILTERED s:STALE > 1 Prefix: 46.0.0.0/8, Status: BI, Age: 10h37m29s > NEXT_HOP: 216.66.87.162, Metric: 1869, Learned from Peer: 216.218.252.169 (6939) > LOCAL_PREF: 140, MED: 20, ORIGIN: igp, Weight: 0 > AS_PATH: 5541 > COMMUNITIES: 6939:1001 6939:1002 6939:1510 6939:1000 > Last update to IP routing table: 10h37m29s, 1 path(s) installed: > # Entry cached for another 60 seconds. > > > > > > 2013/12/20 Stephane Bortzmeyer > >> On Fri, Dec 20, 2013 at 11:59:13AM +0100, >> Lukasz Trabinski wrote >> a message of 20 lines which said: >> >> > I know that is not related with RIPE atlas, but maybe do know where >> > to report in RIPE BGP hijacking topic? >> >> Apparently, they did not went too far? RIPE stat does not see them >> (yet?). >> >> Neither does the looking glass of the upstream >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.arvunescu at adnet.ro Fri Dec 20 14:50:14 2013 From: bogdan.arvunescu at adnet.ro (Bogdan Arvunescu) Date: Fri, 20 Dec 2013 15:50:14 +0200 Subject: [atlas] BGP hijacking Message-ID: <52B44B16.3080503@adnet.ro> Hello Lukasz, thank you for reporting the problem with the six /8s originated by our AS. For future notice, please note that our company has a response time of 15 minutes to e-mails sent to noc at adnettelecom.ro aut-num: AS5541 [...] remarks: E-mail NOC: noc at adnettelecom.ro We have been notified by one of our customers that you have sent several e-mails to the ripe-atlas mailing list related to our company. We have investigated the problem reported and noticed that last night, while enabling our BGP session with AS6939 an error in the config caused the announcement of six /8s. The problem is now fixed and the colleague with the fat fingers will have to eat within the next hour 0.000001 Christmas candies for each IP in the rogue announcements. We wish you a Merry Christmas! and ask you to send us an e-mail to noc at adnettelecom.ro if you see any problem originated from our AS in the future. Best regards, Bogdan -- Best regards, Bogdan *Help us improve Technical Support , Service Delivery * -- *Bogdan Arvunescu* Senior Network Engineer phone: +40-21.527.37.37 mobile: +40-737.999.009 fax: +40-21.320.61.18 e-mail: bogdan.arvunescu at adnet.ro AdNet Telecom 96B Basarabia Blvd, District 2 022121, Bucharest, Romania www.adnettelecom.ro www.datacity.ro www.adnettv.ro -------------- next part -------------- An HTML attachment was scrubbed... URL: From gboonie at gmail.com Sat Dec 21 09:06:09 2013 From: gboonie at gmail.com (dave) Date: Sat, 21 Dec 2013 09:06:09 +0100 Subject: [atlas] Updated RIPE Atlas roadmap In-Reply-To: <52B432E3.7070004@ripe.net> References: <52B31464.8020504@ripe.net> <72652D0C-9CE6-4398-AFD1-CCE3DD429AEC@gmail.com> <52B33C47.8050001@ripe.net> <67CFC230-6E26-4DB2-9083-2C1D89F2283E@gmail.com> <52B432E3.7070004@ripe.net> Message-ID: Please tell me more. Is there a repository of scripts? I've looked, but not yet found such. If a script is available to configure pings from maximum 3 probes in each AS in a selectable country to a selectable target, I'm interested. Anyway, if such could be implemented in the web UI I'd prefer it. Thanks. > Op 20 dec. 2013 om 13:06 heeft Philip Homburg het volgende geschreven: > > Using the API does not imply that you have to write the script yourself. > > There have been quite a few requests for probe selection features. I > sort of wonder if those can be implemented without leading to complexity > that nobody can understand anymore. > > Philip > From inigo at infornografia.net Sat Dec 21 11:13:52 2013 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Sat, 21 Dec 2013 11:13:52 +0100 Subject: [atlas] Updated RIPE Atlas roadmap In-Reply-To: References: <52B31464.8020504@ripe.net> <72652D0C-9CE6-4398-AFD1-CCE3DD429AEC@gmail.com> <52B33C47.8050001@ripe.net> <67CFC230-6E26-4DB2-9083-2C1D89F2283E@gmail.com> <52B432E3.7070004@ripe.net> Message-ID: On Sat, Dec 21, 2013 at 9:06 AM, dave wrote: > Please tell me more. Is there a repository of scripts? I've looked, but not yet found such. Some code can be found at GitHub [1]. The repo hosts content contributed by members of the RIPE Atlas community. You can find code to create measurements from the CLI. I particularly recommend St?phane Bortzmeyer's Tutorial files. Regards, [1] https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib > If a script is available to configure pings from maximum 3 probes in each AS in a selectable country to a selectable target, I'm interested. > > Anyway, if such could be implemented in the web UI I'd prefer it. > > Thanks. > >> Op 20 dec. 2013 om 13:06 heeft Philip Homburg het volgende geschreven: >> >> Using the API does not imply that you have to write the script yourself. >> >> There have been quite a few requests for probe selection features. I >> sort of wonder if those can be implemented without leading to complexity >> that nobody can understand anymore. >> >> Philip >> > From bortzmeyer at nic.fr Mon Dec 23 10:05:41 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 23 Dec 2013 10:05:41 +0100 Subject: [atlas] Updated RIPE Atlas roadmap In-Reply-To: References: <52B31464.8020504@ripe.net> <72652D0C-9CE6-4398-AFD1-CCE3DD429AEC@gmail.com> <52B33C47.8050001@ripe.net> <67CFC230-6E26-4DB2-9083-2C1D89F2283E@gmail.com> <52B432E3.7070004@ripe.net> Message-ID: <20131223090541.GA21264@nic.fr> On Sat, Dec 21, 2013 at 09:06:09AM +0100, dave wrote a message of 21 lines which said: > Please tell me more. Is there a repository of scripts? I've looked, > but not yet found such. There is apparently possible improvments on the web site... I?igo Ortiz de Urbina gave you the URL but do note there is today no script to apply Philip Homburg's excellent idea (download the list of probes, then filter, then create the measurement). TODO :-) > If a script is available to configure pings from maximum 3 probes in > each AS in a selectable country to a selectable target, I'm > interested. Not yet. Anyone brave enough to do it and submit it to the Github repository? From bortzmeyer at nic.fr Mon Dec 23 10:07:37 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 23 Dec 2013 10:07:37 +0100 Subject: [atlas] Updated RIPE Atlas roadmap In-Reply-To: <52B432E3.7070004@ripe.net> References: <52B31464.8020504@ripe.net> <72652D0C-9CE6-4398-AFD1-CCE3DD429AEC@gmail.com> <52B33C47.8050001@ripe.net> <67CFC230-6E26-4DB2-9083-2C1D89F2283E@gmail.com> <52B432E3.7070004@ripe.net> Message-ID: <20131223090737.GB21264@nic.fr> On Fri, Dec 20, 2013 at 01:06:59PM +0100, Philip Homburg wrote a message of 12 lines which said: > There have been quite a few requests for probe selection features. I > sort of wonder if those can be implemented without leading to > complexity that nobody can understand anymore. Seems reasonable. But, in that case, I would request, in exchange, that the default selection is improved to be actually random: there are apparently huge biases in the selection, so drawing quantitative conclusions ("x % of Atlas probes can ping www.example.com with IPv4") from default selection is dangerous. From v.bajpai at jacobs-university.de Mon Dec 23 12:54:48 2013 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Mon, 23 Dec 2013 11:54:48 +0000 Subject: [atlas] (no subject) In-Reply-To: <52B0A082.8040306@ripe.net> References: <081E9415D79F9A469A4B6C79815FC0926E3158@SXCHMB01.jacobs.jacobs-university.de> <52B0A082.8040306@ripe.net> Message-ID: <2DD8FC12-9A6F-4311-96A2-D1B07990C65F@jacobs-university.de> On 17 Dec 2013, at 20:05, Robert Kisteleki wrote: > On 2013.12.17. 16:44, Eravuchira, Steffie Jacob wrote: > >> There are three hardware versions of RIPE Atlas probes namely v1,v2 and >> v3. Each of the support different firmware versions. Can I get the latest >> firmware version supported by each the hardware versions? >> >> Thanks, Steffie > > Hello, > > Usually the different hardware revisions run the same firmware version. > Currently that's not the case (v3 is one version ahead at 4580, v1/2 are at > 4570). > > The system automatically notifies probes about the latest firmware available > for that hardware revision whenever the probe reconnects. The probe then > upgrades right away, if the latest version is not yet installed. This > requires no intervention from the probe host. > > If the probe is otherwise up and running happily, then it does not get the > notification, therefore does not upgrade until the next reconnect. So in > general we have a lazy upgrade approach. > > As of right now, all connected probes across all probe hardware revisions > are running the latest firmware version available (with the exception of two > misbehaving v2 probes). Hello Robert, The question popped up at our end because we were looking at the plots of measurement results generated by different probes. We wanted to make sure these probes were comprised of the same hardware and that they run the same firmware version. It?s great that each UDM attaches the firmware version of the probe as a tag in its results. However: a) Although, the hardwares currently are capable of running the same firmware revision, but as you mentioned, at times they diverge away. b) Would different hardwares always support the latest firmware version? I ask because v3 is more capable than v1/v2, and I don?t know if you plan to diverge away the firmware at some point to provide more measurement capabilities for v3 probes. Due to a) and b) would it make sense to also attach the hardware version (v1, v2, v3) of the probe as a tag in each UDM result as well? We don?t know if different hardwares have effects on the measurement results. We can cross-confirm this if the UDMs attach a hardware version in addition to the firmware revision. Thanks! Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From mgalante at ripe.net Mon Dec 23 15:49:59 2013 From: mgalante at ripe.net (Michela Galante) Date: Mon, 23 Dec 2013 15:49:59 +0100 Subject: [atlas] SURFnet (NL) has joined RIPE Atlas anchors Message-ID: 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 nl-ams-as1101 and is hosted by SURFnet in Amsterdam, Netherlands. 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 ---------------------- The RIPE Atlas Team wishes you happy holidays and all the best for 2014! https://atlas.ripe.net/media/community/action/originals/RIPE-Atlas-Christmas-Probe-022.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From bortzmeyer at nic.fr Mon Dec 23 17:18:11 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 23 Dec 2013 17:18:11 +0100 Subject: [atlas] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <22wqj22tcq.fsf@ziptop.autonomica.net> References: <52B0344C.5080109@ripe.net> <20131217115415.GQ81676@Space.Net> <52B04365.9030801@restena.lu> <22wqj22tcq.fsf@ziptop.autonomica.net> Message-ID: <20131223161811.GA32675@nic.fr> On Wed, Dec 18, 2013 at 02:15:17PM +0100, Lars-Johan Liman wrote a message of 31 lines which said: > ... and I would add that I don't want DDoS culprits to be able to > use Atlas as a real-time assessment tool of the effectiveness of > their attacks. I do not see the relationship between this requirment and the discussion about the proposed new policy. If I run a dDoS, I can run the Atlas tests too (there is not process to filter out the bad guys...), I would not rely on other people's measurements. From bortzmeyer at nic.fr Mon Dec 23 17:19:14 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 23 Dec 2013 17:19:14 +0100 Subject: [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <52B04365.9030801@restena.lu> References: <52B0344C.5080109@ripe.net> <20131217115415.GQ81676@Space.Net> <52B04365.9030801@restena.lu> Message-ID: <20131223161914.GB32675@nic.fr> On Tue, Dec 17, 2013 at 01:28:21PM +0100, Gilles Massen wrote a message of 24 lines which said: > I could live with non-public data becoming public a few days after > the measurement, One of the goals of the new policy is to simplify the Atlas code and documentation. What you suggest would add new code and complexity. From gilles.massen at restena.lu Mon Dec 23 18:55:26 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Mon, 23 Dec 2013 18:55:26 +0100 Subject: [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <20131223161914.GB32675@nic.fr> References: <52B0344C.5080109@ripe.net> <20131217115415.GQ81676@Space.Net> <52B04365.9030801@restena.lu> <20131223161914.GB32675@nic.fr> Message-ID: <52B8790E.1040901@restena.lu> On 23/12/2013, 17:19 , Stephane Bortzmeyer wrote: >> I could live with non-public data becoming public a few days after >> the measurement, > > One of the goals of the new policy is to simplify the Atlas code and > documentation. What you suggest would add new code and complexity. Over making everything public, certainly. Compared to the current public/private distinction the additional complexity looks negligeable (naively I'd say replace the private flag with a timestamp that will expire - added complexity: one cron job, and a few queries to adapt). However it would meet the other goal: make all data public and thus avoid duplicate jobs. Anyway, making jobs private (forever or temporarily) means a lot to me, and so I would be willing to tolerate quite some complexity (I know that I'd hardly feel the cost personally...) Best, Gilles From ripe at chevelus.org Mon Dec 23 19:09:34 2013 From: ripe at chevelus.org (Pierre Blanchet) Date: Mon, 23 Dec 2013 19:09:34 +0100 Subject: [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: <52B8790E.1040901@restena.lu> References: <52B0344C.5080109@ripe.net> <20131217115415.GQ81676@Space.Net> <52B04365.9030801@restena.lu> <20131223161914.GB32675@nic.fr> <52B8790E.1040901@restena.lu> Message-ID: On Mon, Dec 23, 2013 at 6:55 PM, Gilles Massen wrote: > Anyway, making jobs private (forever or temporarily) means a lot to me, > and so I would be willing to tolerate quite some complexity (I know that > I'd hardly feel the cost personally...) > I host a probe because I believe Atlas is a valuable tool for the *community*. I do not host a probe to help you to debug your network and/or to keep the data for yourself. Keeping the results public will make sure Atlas does not become a cheap monitoring solution for enterprises only. Thanks, Pierre. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgalante at ripe.net Tue Dec 24 10:39:48 2013 From: mgalante at ripe.net (Michela Galante) Date: Tue, 24 Dec 2013 10:39:48 +0100 Subject: [atlas] ISNIC (IS) has joined RIPE Atlas anchors Message-ID: <463B815A-8AFD-4156-9A2D-D6C03747B72A@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 is-rey-as1850 and is hosted by ISNIC in Reykjavik, Iceland. 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 ---------------------- The RIPE Atlas Team wishes you happy holidays and all the best for 2014! https://atlas.ripe.net/media/community/action/originals/RIPE-Atlas-Christmas-Probe-022.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2626 bytes Desc: not available URL: From gilles.massen at restena.lu Tue Dec 24 12:06:06 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Tue, 24 Dec 2013 12:06:06 +0100 Subject: [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: References: <52B0344C.5080109@ripe.net> <20131217115415.GQ81676@Space.Net> <52B04365.9030801@restena.lu> <20131223161914.GB32675@nic.fr> <52B8790E.1040901@restena.lu> Message-ID: <52B96A9E.7070005@restena.lu> On 23/12/2013, 19:09 , Pierre Blanchet wrote: > I host a probe because I believe Atlas is a valuable tool for the > *community*. I do not host a probe to help you to debug your network > and/or to keep the data for yourself. We have been hosting a TTM Box for years and have now several probes and an anchor - because we believe in the tool, not in the return of investment. Atlas does have two sides though: it is the RIPE NCC membership and the sponsors that are footing the bill, but it will not work without the community at large helping to host probes. I see no reason for Atlas not to be able to accommodate those (overlapping) groups. > Keeping the results public will make sure Atlas does not become a cheap > monitoring solution for enterprises only. "temporarily" was the keyword. Besides, the credit system is well taking care of the 'cheap'. And as long as it's called the *Inter*net, I want it to be debugged and to work. Even the purely commercial parts. Best, Gilles From gilles.massen at restena.lu Tue Dec 24 12:15:52 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Tue, 24 Dec 2013 12:15:52 +0100 Subject: [atlas] probe information - useful feature? Message-ID: <52B96CE8.20003@restena.lu> Hi, With a few measurements I was stumbling about probes returning 'unexpected' results (e.g. having DNS responses rewritten). I was wondering if it made sense to provide a way to add information to probes that are somehow 'noteworthy'. Just adding free comments to probes could be enough. The reason is not to lose time each time someone stumbles over the results and has to investigate the specifics over and over again. The probe selection does not have to be affected - after all the weirdness is part of the internet. It shouldn't either result in some kind of blaming, only information sharing. Additionally a probe host could be notified if some text is added to his probe (he might not be aware after all). Thoughts? Best, Gilles From bortzmeyer at nic.fr Tue Dec 24 12:27:45 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 24 Dec 2013 12:27:45 +0100 Subject: [atlas] probe information - useful feature? In-Reply-To: <52B96CE8.20003@restena.lu> References: <52B96CE8.20003@restena.lu> Message-ID: <20131224112745.GA32130@nic.fr> On Tue, Dec 24, 2013 at 12:15:52PM +0100, Gilles Massen wrote a message of 22 lines which said: > probes returning 'unexpected' results (e.g. having DNS responses > rewritten). Probe #4778, for instance. > I was wondering if it made sense to provide a way to add information > to probes that are somehow 'noteworthy'. Just adding free comments > to probes could be enough. Let me add a request: that these comments be timestamped automatically. Things change and a probe may switch to another DNS resolver, with other properties. From gert at space.net Tue Dec 24 13:04:40 2013 From: gert at space.net (Gert Doering) Date: Tue, 24 Dec 2013 13:04:40 +0100 Subject: [atlas] [mat-wg] Proposing more public RIPE Atlas data and clarifying the current situation In-Reply-To: References: <52B0344C.5080109@ripe.net> <20131217115415.GQ81676@Space.Net> <52B04365.9030801@restena.lu> <20131223161914.GB32675@nic.fr> <52B8790E.1040901@restena.lu> Message-ID: <20131224120440.GU81676@Space.Net> Hi, On Mon, Dec 23, 2013 at 07:09:34PM +0100, Pierre Blanchet wrote: > On Mon, Dec 23, 2013 at 6:55 PM, Gilles Massen wrote: > > > Anyway, making jobs private (forever or temporarily) means a lot to me, > > and so I would be willing to tolerate quite some complexity (I know that > > I'd hardly feel the cost personally...) > > I host a probe because I believe Atlas is a valuable tool for the > *community*. I do not host a probe to help you to debug your network and/or > to keep the data for yourself. Well, we host an Atlas Anchor, which we paid for ourselves, so we can use this for diagnosing problems in our network - and which we are happy to see used by other folks to improve their networks. I don't particularily care for *your* probe, for which you didn't pay anything... > Keeping the results public will make sure Atlas does not become a cheap > monitoring solution for enterprises only. Forcing all results to be public will result in Atlas not being used for things people will not want to see public, and *that* is quite likely to result in people that are going to invest more into Atlas than "yeah, give me a probe for free!" to, well, *not* invest. 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 emile.aben at ripe.net Mon Dec 30 22:10:19 2013 From: emile.aben at ripe.net (Emile Aben) Date: Mon, 30 Dec 2013 22:10:19 +0100 Subject: [atlas] Updated RIPE Atlas roadmap In-Reply-To: <20131223090541.GA21264@nic.fr> References: <52B31464.8020504@ripe.net> <72652D0C-9CE6-4398-AFD1-CCE3DD429AEC@gmail.com> <52B33C47.8050001@ripe.net> <67CFC230-6E26-4DB2-9083-2C1D89F2283E@gmail.com> <52B432E3.7070004@ripe.net> <20131223090541.GA21264@nic.fr> Message-ID: <52C1E13B.7080804@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 23/12/2013 10:05, Stephane Bortzmeyer wrote: > On Sat, Dec 21, 2013 at 09:06:09AM +0100, dave > wrote a message of 21 lines which said: > >> Please tell me more. Is there a repository of scripts? I've >> looked, but not yet found such. > > There is apparently possible improvments on the web site... I?igo > Ortiz de Urbina gave you the URL but do note there is today no > script to apply Philip Homburg's excellent idea (download the list > of probes, then filter, then create the measurement). TODO :-) > >> If a script is available to configure pings from maximum 3 probes >> in each AS in a selectable country to a selectable target, I'm >> interested. > > Not yet. Anyone brave enough to do it and submit it to the Github > repository? Hi, I did have a similar itch-to-scratch, so I do have a hack laying around that almost does what you want, it's usage description: schootpunt$./select_probes.py -h usage: select_probes.py [-h] [-v] [-l LOCSTRING] [-p POINT] [-r RADIUS] [-c COUNT] [-f FIELDS] [-a MAXPERAS] [-d] optional arguments: -h, --help show this help message and exit -v, --verbosity -l LOCSTRING, --locstring LOCSTRING location string, ie 'Amsterdam,NL' -p POINT, --point POINT location as ,-string, ie '48.45,9.16' -r RADIUS, --radius RADIUS radius (km) within which to select probes -c COUNT, --count COUNT number of probes requested -f FIELDS, --fields FIELDS comma separated list of fields to return (output is tsv) -a MAXPERAS, --maxperas MAXPERAS maximum no. of probes per IPv4 source AS -d, --includedownprobes include probes that are down (default: don't include these) This doesn't select an individual country, but selects probes around a specific coordinate, so ./select_probes.py -l"Amsterdam,NL" -c 50 -a 3 -f id Would return the IDs of the 50 closest probes to Amsterdam city center (or whatever coordinate the google geocoding API gives for "Amsterdam,NL"), with a maximum of 3 probes per v4 AS. I can submit this to the Github, if it's close enough to what others would want. Emile -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLB4TsACgkQj05ACITZaqopWAD9Fa3ri/TP05qNDQ7agglxVqCE nldKJEPLQ0PmPhDtPQ0BAIdGX6XagIjeBokd5LNiogCpra6yOOKnrrfqKfq4B6Y7 =TCFU -----END PGP SIGNATURE-----