From alexsaroyan at gmail.com Fri Nov 1 11:46:19 2013 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Fri, 01 Nov 2013 14:46:19 +0400 Subject: [atlas] Fwd: UDM/Credit troubles In-Reply-To: <527363E1.3050700@gmail.com> References: <527363E1.3050700@gmail.com> Message-ID: <5273867B.6060107@gmail.com> Hi, I faced some troubles today using Atlas. My running credit consumption was 0 because all UDMs were stopped already for few days(screenshot attached). I have defined 2 UDMs (16 Pings from 12 Probes - nothing special - nothing big - about 300 credits) - they failed to start with no reason (screenshot attached). When defining 3-rd similar UDM, I've got message saying my current consumption is 276800 and no credit available to start an 300 credit UDM.(screenshot attached) It seems to me that some UDM is stuck, it is stopped but Atlas credit system thinks that it is running. So I faced two troubles 1-st regarding mysterious failed UDM and 2-nd regarding credit consumption. -- Regards. /Alex Saroyan -------------- next part -------------- A non-text attachment was scrubbed... Name: Atlas_credit_status.png Type: image/png Size: 17753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Atlas_Insufficient_credit.png Type: image/png Size: 17718 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Atlas_2failed_UDMs.png Type: image/png Size: 16288 bytes Desc: not available URL: From alexsaroyan at gmail.com Fri Nov 1 12:27:19 2013 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Fri, 01 Nov 2013 15:27:19 +0400 Subject: [atlas] UDM/Credit troubles In-Reply-To: <5273867B.6060107@gmail.com> References: <527363E1.3050700@gmail.com> <5273867B.6060107@gmail.com> Message-ID: <52739017.9080907@gmail.com> Hi, Failures seems to be fixed now, but still wrong credit calculation is there. Regards. /Alex Saroyan On 11/01/2013 02:46 PM, Alex Saroyan wrote: > Hi, > > I faced some troubles today using Atlas. > > My running credit consumption was 0 because all UDMs were stopped > already for few days(screenshot attached). > I have defined 2 UDMs (16 Pings from 12 Probes - nothing special - > nothing big - about 300 credits) - they failed to start with no reason > (screenshot attached). > When defining 3-rd similar UDM, I've got message saying my current > consumption is 276800 and no credit available to start an 300 credit > UDM.(screenshot attached) > > It seems to me that some UDM is stuck, it is stopped but Atlas credit > system thinks that it is running. > > So I faced two troubles 1-st regarding mysterious failed UDM and 2-nd > regarding credit consumption. > From BECHA at ripe.net Wed Nov 6 09:32:16 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 06 Nov 2013 09:32:16 +0100 Subject: [atlas] Discussing IPv6 extension headers feature on mat-wg Message-ID: <5279FE90.2030205@ripe.net> Hi RIPE-Atlas-users, one of the features often requested to add to RIPE Atlas is "enable IPv6 extension headers". We would like to know the details of your needs, so please join the discussion on the MAT-WG that Jens started: https://www.ripe.net/ripe/mail/archives/mat-wg/2013-November/000364.html (I am deliberately not copying the text here, please keep the discussion on one list...) Thank you for your input! Vesna From gilles.massen at restena.lu Wed Nov 6 10:35:17 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Wed, 06 Nov 2013 10:35:17 +0100 Subject: [atlas] msm_name in DNS measurements? Message-ID: <527A0D55.2040207@restena.lu> Hello, I just stumbled over a field 'msm_name' in a DNS UDM - but it's apparently undocumented (at https://atlas.ripe.net/doc/data_struct#v4540_dns ). What could it contain (except 'Tdig')? (and would it be possible to add it to the documentation?) best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From vnaumov at ripe.net Wed Nov 6 11:53:57 2013 From: vnaumov at ripe.net (Viktor Naumov) Date: Wed, 06 Nov 2013 11:53:57 +0100 Subject: [atlas] msm_name in DNS measurements? In-Reply-To: <527A0D55.2040207@restena.lu> References: <527A0D55.2040207@restena.lu> Message-ID: <527A1FC5.4060009@ripe.net> Hi Gilles, You can ignore it. It is for the system purposes. WBR /vty On 11/6/13 10:35 AM, Gilles Massen wrote: > Hello, > > I just stumbled over a field 'msm_name' in a DNS UDM - but it's > apparently undocumented (at > https://atlas.ripe.net/doc/data_struct#v4540_dns ). > > What could it contain (except 'Tdig')? (and would it be possible to add > it to the documentation?) > > best, > Gilles > From vnaumov at ripe.net Wed Nov 6 21:39:51 2013 From: vnaumov at ripe.net (Viktor Naumov) Date: Wed, 06 Nov 2013 21:39:51 +0100 Subject: [atlas] msm_name in DNS measurements? In-Reply-To: <22mwlhcqkt.fsf@ziptop.autonomica.net> References: <527A0D55.2040207@restena.lu> <527A1FC5.4060009@ripe.net> <22mwlhcqkt.fsf@ziptop.autonomica.net> Message-ID: <527AA917.4060803@ripe.net> Well... It is a legacy field needed to speed up consumption of the measurement results by saving on database requests. Result consumption is a place where we put a lot of optimization efforts. Basically 'Tdig' is a class name. Since we are still in transition to the new measurement result storage we need to keep it. As soon as we stop depending on it it will be gone. The system is evolving and it may happen that you get it in the downloaded results because we are transparent and do little filtering on the results data. That is the reason you can ignore it and you shouldn't depend on it. WBR Viktor Naoumov On 11/6/13 7:50 PM, Lars-Johan Liman wrote: > vnaumov at ripe.net: >> You can ignore it. It is for the system purposes. > Umm. This is a very disappointing answer. The RIPE NCC always prides > itself in being transparent. The answer above is not a supporting > fact. > > It may well be that the field is for system purposes, but please do > describe those system purposes. We are engineers, not children. > > Best regards, > /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 daniel.karrenberg at ripe.net Thu Nov 7 08:53:48 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 7 Nov 2013 08:53:48 +0100 Subject: [atlas] msm_name in DNS measurements? In-Reply-To: <527AA917.4060803@ripe.net> References: <527A0D55.2040207@restena.lu> <527A1FC5.4060009@ripe.net> <22mwlhcqkt.fsf@ziptop.autonomica.net> <527AA917.4060803@ripe.net> Message-ID: Grown-ups and never depend on undocumented features/data ..... ;-) Sorry, could not resist ...... Daniel (who has been acting childishly from time to time) > On 11/6/13 7:50 PM, Lars-Johan Liman wrote: >> vnaumov at ripe.net: >>> You can ignore it. It is for the system purposes. >> Umm. This is a very disappointing answer. The RIPE NCC always prides >> itself in being transparent. The answer above is not a supporting >> fact. >> >> It may well be that the field is for system purposes, but please do >> describe those system purposes. We are engineers, not children. >> >> Best regards, >> /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/ >> #---------------------------------------------------------------------- > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From BECHA at ripe.net Thu Nov 7 15:41:26 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 07 Nov 2013 15:41:26 +0100 Subject: [atlas] News about RIPE Atlas anchoring measurements Message-ID: <527BA696.8050209@ripe.net> Dear colleagues, at the RIPE67 we announced that RIPE Atlas anchors are now ready for the next stage -- full production service. Since then, we already got 10 applications! Currently there are 15 anchors deployed, there is a full-mesh of measurements between the anchors, and we are scaling up the "anchoring" measurements from hundreds of probes towards each anchor, to provide the map of regional reachability. We are now looking for more interested hosts, in new locations. Please find out more details of the benefits of hosting an anchor, technical requirements and available features in RIPE Labs article: https://labs.ripe.net/Members/suzanne_taylor_muzzin/announcing-the-ripe-atlas-anchors-service Regards, Vesna From gilles.massen at restena.lu Fri Nov 8 15:46:48 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Fri, 08 Nov 2013 15:46:48 +0100 Subject: [atlas] probe allocations Message-ID: <527CF958.2070502@restena.lu> Hi, I was wondering how the number of allocated probes is determined for a given UDM. Specifically, I set up a recurring UDM with 50 world-wide probes (DNS), but 110 probes were allocated to the test. While I'm certainly flattered that RIPE Atlas deemed the measurement so worthwhile, the credit consumption was somewhat higher than expected... so what is the logic, and am I able to get (at most) what I requested? best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From astrikos at ripe.net Fri Nov 8 16:40:27 2013 From: astrikos at ripe.net (Andreas Strikos) Date: Fri, 08 Nov 2013 16:40:27 +0100 Subject: [atlas] probe allocations In-Reply-To: <527CF958.2070502@restena.lu> References: <527CF958.2070502@restena.lu> Message-ID: <527D05EB.2030704@ripe.net> Hi Gilles, normally every measurement is allocated equal or less (if we don't have enough) probes than the user has requested. In your case though, due a bug, your measurement got scheduled more than once, so you got more than you requested. If you are low on credits we could give you back the overcharge amount. Sorry for the inconvenience. Regards, Andreas On 11/8/13, 3:46 PM, Gilles Massen wrote: > Hi, > > I was wondering how the number of allocated probes is determined for a > given UDM. Specifically, I set up a recurring UDM with 50 world-wide > probes (DNS), but 110 probes were allocated to the test. While I'm > certainly flattered that RIPE Atlas deemed the measurement so > worthwhile, the credit consumption was somewhat higher than expected... > so what is the logic, and am I able to get (at most) what I requested? > > best, > Gilles > From gboonie at gmail.com Fri Nov 8 17:55:19 2013 From: gboonie at gmail.com (Dave .) Date: Fri, 8 Nov 2013 17:55:19 +0100 Subject: [atlas] need higher timeout value for ping Message-ID: Hi, I did send a mail to atlas at ripe.nl. I never received an answer although it's 19 days ago. Not sure if staff is reading here, but let's see. This graph shows pings to a mobile device. A device connected to a mobile network. As mobile networks need to do paging and need some time to re-establish the radio connection, more time is needed for the packets in the first 2 or 3 seconds to get through. My request is to consider making a configurable timeout value for pings? For mobile networks a typical RTT for a first packet would be some 3 seconds. There are however buffers in a typical mobile network which store packets up to 30 seconds in case multiple pagings would fail. I really would like to be able to have a timeout maximum of just over 30 seconds but I could understand if you would limit on 5 seconds. Below, I kept a continuous ping open parallel to the Atlas tests in the marked timeframe. Therefore no paging was needed as the radio channel was kept open all the time. It seems the current timeout is 2 or 3 seconds. Regards, Dave Boonstra. [image: Inline afbeelding 1] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 93055 bytes Desc: not available URL: From klaus.darilion at nic.at Fri Nov 8 18:03:58 2013 From: klaus.darilion at nic.at (Klaus Darilion) Date: Fri, 8 Nov 2013 18:03:58 +0100 Subject: [atlas] Categorize probes (feature request) Message-ID: <527D197E.7050900@nic.at> Hi! Depending on the measurement, sometimes I want a realistic "user's view" which means using probes in residential areas, and sometimes I want a "backbone" view, which mean using probes in the back-bone (good connected) e.g. to measure my access network or my servers without the delay introduced by the probes access network. Thus, it would be cool if the probe selection algorithm allows also to choose "residential" probes or "backbone" probes. Maybe this categorization can be done automatically, or probe owners can be asked to specify the probes connectivity manually. Thanks, Klaus From gilles.massen at restena.lu Fri Nov 8 18:54:41 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Fri, 08 Nov 2013 18:54:41 +0100 Subject: [atlas] probe allocations In-Reply-To: <527D05EB.2030704@ripe.net> References: <527CF958.2070502@restena.lu> <527D05EB.2030704@ripe.net> Message-ID: <527D2561.2020103@restena.lu> Hi Andreas, Thanks for clarifying. If its only a but (that gets fixed eventually) that's fine. And I'm not desperate about the credits yet ... Best, Gilles On 8/11/13, 16:40 , Andreas Strikos wrote: > Hi Gilles, > > normally every measurement is allocated equal or less (if we don't have > enough) probes than the user has requested. > In your case though, due a bug, your measurement got scheduled more than > once, so you got more than you requested. > If you are low on credits we could give you back the overcharge amount. > > Sorry for the inconvenience. > > Regards, > Andreas > > On 11/8/13, 3:46 PM, Gilles Massen wrote: >> Hi, >> >> I was wondering how the number of allocated probes is determined for a >> given UDM. Specifically, I set up a recurring UDM with 50 world-wide >> probes (DNS), but 110 probes were allocated to the test. While I'm >> certainly flattered that RIPE Atlas deemed the measurement so >> worthwhile, the credit consumption was somewhat higher than expected... >> so what is the logic, and am I able to get (at most) what I requested? >> >> best, >> Gilles >> From carsten at schiefner.de Fri Nov 8 18:58:57 2013 From: carsten at schiefner.de (Carsten Schiefner) Date: Fri, 08 Nov 2013 18:58:57 +0100 Subject: [atlas] need higher timeout value for ping In-Reply-To: References: Message-ID: <527D2661.7080700@schiefner.de> Hi Dave, On 08.11.2013 17:55, Dave . wrote: > I did send a mail to atlas at ripe.nl . I never > received an answer although it's 19 days ago. Not sure if staff is > reading here, but let's see. try - that should do. Best, Carsten From gboonie at gmail.com Fri Nov 8 19:44:41 2013 From: gboonie at gmail.com (Dave .) Date: Fri, 8 Nov 2013 19:44:41 +0100 Subject: [atlas] need higher timeout value for ping In-Reply-To: <527D2661.7080700@schiefner.de> References: <527D2661.7080700@schiefner.de> Message-ID: Hi Carsten, Good catch. That is what I did though. It was a typo in the message here. I did get a auto-reply but no actual response. Thanks, Dave 2013/11/8 Carsten Schiefner > Hi Dave, > > On 08.11.2013 17:55, Dave . wrote: > >> I did send a mail to atlas at ripe.nl . I never >> >> received an answer although it's 19 days ago. Not sure if staff is >> reading here, but let's see. >> > > try - that should do. > > Best, > > Carsten > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Fri Nov 8 19:58:52 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 08 Nov 2013 19:58:52 +0100 Subject: [atlas] need higher timeout value for ping In-Reply-To: References: <527D2661.7080700@schiefner.de> Message-ID: <527D346C.7020307@ripe.net> On 2013/11/08 19:44 , Dave . wrote: > Good catch. That is what I did though. It was a typo in the message > here. I did get a auto-reply but no actual response. It did arrive, but then unfortunately got dropped handing it over from one person to another. Philip From gilles.massen at restena.lu Fri Nov 8 20:26:30 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Fri, 08 Nov 2013 20:26:30 +0100 Subject: [atlas] Categorize probes (feature request) In-Reply-To: <527D197E.7050900@nic.at> References: <527D197E.7050900@nic.at> Message-ID: <527D3AE6.2070201@restena.lu> On 8/11/13, 18:03 , Klaus Darilion wrote: > Hi! > > Depending on the measurement, sometimes I want a realistic "user's view" > which means using probes in residential areas, and sometimes I want a > "backbone" view, which mean using probes in the back-bone (good > connected) e.g. to measure my access network or my servers without the > delay introduced by the probes access network. A kind of rough classification is asked when you register a probe, but apparently it cannot be changed later on, or used for filtering. It would be an interesting feature though. If it becomes an option, please allow multiple choices: currently the choices are exclusive. regards, Gilles From ivo.vdmaagdenberg at gmail.com Fri Nov 8 22:24:57 2013 From: ivo.vdmaagdenberg at gmail.com (ivo.vdmaagdenberg at gmail.com) Date: Fri, 8 Nov 2013 22:24:57 +0100 (CET) Subject: [atlas] Archiving user-defined measurements in Atlas Message-ID: Hi, Played a bit with measurements, now I want make some sensible ones and get rid of the rest. In the documentation "How do I stop a user-defined measurement?" there is mention of the 'Archive' option per measurement. I see that option but it is grayed out. The question is: What are the circumstance that grey the option? This holds for the "Forced to Stop", "Stopped" and "Ongoing" UDMs (maybe more...) Kind regards, Ivo From BECHA at ripe.net Mon Nov 11 11:49:57 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 11 Nov 2013 11:49:57 +0100 Subject: [atlas] Categorize probes (feature request) In-Reply-To: <527D3AE6.2070201@restena.lu> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> Message-ID: <5280B655.4000207@ripe.net> Hi Klaus, Gilles, thank you for describing the feature that you would like to see. We already have this on the roadmap, listed under "More control over probe selection - Enable choice of probes based on the type of connection": http://roadmap.ripe.net/ripe-atlas/ However, as you can see on the roadmap, we have many features that we are working on, and few more in the planning; also, during RIPE meeting we received few more that will make it to the "requested" column... Posting your wish on the mailing list will raise the priority of your requested feature, so, everyone, please keep on doing that! You can expect that we will get to work on this "soon", but I can't give you any time estimates yet on when will this be implemented. Kind regards, Vesna On 08-nov.-13 20:26, Gilles Massen wrote: > On 8/11/13, 18:03 , Klaus Darilion wrote: >> Hi! >> >> Depending on the measurement, sometimes I want a realistic "user's view" >> which means using probes in residential areas, and sometimes I want a >> "backbone" view, which mean using probes in the back-bone (good >> connected) e.g. to measure my access network or my servers without the >> delay introduced by the probes access network. > > A kind of rough classification is asked when you register a probe, but > apparently it cannot be changed later on, or used for filtering. It > would be an interesting feature though. > > If it becomes an option, please allow multiple choices: currently the > choices are exclusive. > > regards, > Gilles > > > From gert at space.net Mon Nov 11 12:12:17 2013 From: gert at space.net (Gert Doering) Date: Mon, 11 Nov 2013 12:12:17 +0100 Subject: [atlas] feature requests In-Reply-To: <5280B655.4000207@ripe.net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> Message-ID: <20131111111217.GT81676@Space.Net> Hi, On Mon, Nov 11, 2013 at 11:49:57AM +0100, Vesna Manojlovic wrote: > Posting your wish on the mailing list will raise the priority of your > requested feature, so, everyone, please keep on doing that! - restart an UDM after it has stopped - change parameters of an UDM and restart it, keeping the same ID (usage case: test run an UDM with just a few probes, develop the software to fetch and evaluate the json result data, then set the number of probes / number of packets / frequency / ... to what the final measurement should be, without having to change the ID in the grabbing software - especially if tweaking parameters for a couple of rounds this gets inconvenient) 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 klaus.darilion at nic.at Mon Nov 11 12:21:54 2013 From: klaus.darilion at nic.at (Klaus Darilion) Date: Mon, 11 Nov 2013 12:21:54 +0100 Subject: [atlas] feature requests In-Reply-To: <20131111111217.GT81676@Space.Net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> Message-ID: <5280BDD2.2060407@nic.at> On 11.11.2013 12:12, Gert Doering wrote: > Hi, > > On Mon, Nov 11, 2013 at 11:49:57AM +0100, Vesna Manojlovic wrote: >> Posting your wish on the mailing list will raise the priority of your >> requested feature, so, everyone, please keep on doing that! > - restart an UDM after it has stopped > > - change parameters of an UDM and restart it, keeping the same ID > > (usage case: test run an UDM with just a few probes, develop the > software to fetch and evaluate the json result data, then set > the number of probes / number of packets / frequency / ... to > what the final measurement should be, without having to change the > ID in the grabbing software - especially if tweaking parameters for > a couple of rounds this gets inconvenient) That's one reason why I switched to the REST API regards Klaus From klaus.darilion at nic.at Mon Nov 11 12:22:59 2013 From: klaus.darilion at nic.at (Klaus Darilion) Date: Mon, 11 Nov 2013 12:22:59 +0100 Subject: [atlas] feature requests In-Reply-To: <5280BDD2.2060407@nic.at> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <5280BDD2.2060407@nic.at> Message-ID: <5280BE13.6030103@nic.at> On 11.11.2013 12:21, Klaus Darilion wrote: > > On 11.11.2013 12:12, Gert Doering wrote: >> Hi, >> >> On Mon, Nov 11, 2013 at 11:49:57AM +0100, Vesna Manojlovic wrote: >>> Posting your wish on the mailing list will raise the priority of your >>> requested feature, so, everyone, please keep on doing that! >> - restart an UDM after it has stopped >> >> - change parameters of an UDM and restart it, keeping the same ID >> >> (usage case: test run an UDM with just a few probes, develop the >> software to fetch and evaluate the json result data, then set >> the number of probes / number of packets / frequency / ... to >> what the final measurement should be, without having to change the >> ID in the grabbing software - especially if tweaking parameters for >> a couple of rounds this gets inconvenient) > That's one reason why I switched to the REST API To be more verbose: My "add measurement" script writes the ID to a file, and my "analyze" script reads the ID from this file. regards Klaus From gert at space.net Mon Nov 11 13:02:14 2013 From: gert at space.net (Gert Doering) Date: Mon, 11 Nov 2013 13:02:14 +0100 Subject: [atlas] feature requests In-Reply-To: <5280BE13.6030103@nic.at> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <5280BDD2.2060407@nic.at> <5280BE13.6030103@nic.at> Message-ID: <20131111120214.GU81676@Space.Net> Hi, On Mon, Nov 11, 2013 at 12:22:59PM +0100, Klaus Darilion wrote: > To be more verbose: My "add measurement" script writes the ID to a file, > and my "analyze" script reads the ID from this file. I could do that, but I don't want that - I'm not adding new measurements often enough to make it worthwile to add a script for that (the web ui is nice enough). Almost all I need should be there today, it's just a matter of priorization - and as Vesna said "voice your wishes", here I am :-) 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 gboonie at gmail.com Mon Nov 11 19:24:09 2013 From: gboonie at gmail.com (dave) Date: Mon, 11 Nov 2013 19:24:09 +0100 Subject: [atlas] feature requests In-Reply-To: <20131111120214.GU81676@Space.Net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <5280BDD2.2060407@nic.at> <5280BE13.6030103@nic.at> <20131111120214.GU81676@Space.Net> Message-ID: <9B0645D3-811C-438C-B7F1-05D705DB7A54@gmail.com> Hi, I do have some wishes. - configurable ping timeout up to 30+ seconds. Or possibly 5 at least. - contrains for selecting probes so that one can configure pings from 2 probes on every AS. - tcp ping to check connectivity to places that do not accept pings - longer time-out for the atlas website. Is it 2 hours now? Could it be 12 please? - take firewalled probes out of the pool for new UDMs. I often get 2 probes out of 10 that can not reach anything. If probe can nog reach most root servers, it's pretty useless. - stop - modify - start. Of UDMs Thanks, Dave. From the.lists at mgm51.com Mon Nov 11 19:32:38 2013 From: the.lists at mgm51.com (Mike.) Date: Mon, 11 Nov 2013 13:32:38 -0500 Subject: [atlas] feature requests In-Reply-To: <9B0645D3-811C-438C-B7F1-05D705DB7A54@gmail.com> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <5280BDD2.2060407@nic.at> <5280BE13.6030103@nic.at> <20131111120214.GU81676@Space.Net> <9B0645D3-811C-438C-B7F1-05D705DB7A54@gmail.com> Message-ID: <201311111332380325.00AAD1E2@smtp.24cl.home> Hi, My one wish (for now :) )... Allow me to disable the processing of RA's on IPv6, so that I can configure IPv6 statically and not have it overwritten by an RA. Thanks, Mike. From rdekema at gmail.com Mon Nov 11 19:43:47 2013 From: rdekema at gmail.com (Rusty Dekema) Date: Mon, 11 Nov 2013 13:43:47 -0500 Subject: [atlas] feature requests In-Reply-To: <9B0645D3-811C-438C-B7F1-05D705DB7A54@gmail.com> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <5280BDD2.2060407@nic.at> <5280BE13.6030103@nic.at> <20131111120214.GU81676@Space.Net> <9B0645D3-811C-438C-B7F1-05D705DB7A54@gmail.com> Message-ID: I've said this before, although perhaps not in the right venue: I second (third, etc) the request for configurable (longer) ping timeouts. -Rusty On Mon, Nov 11, 2013 at 1:24 PM, dave wrote: > Hi, > > I do have some wishes. > - configurable ping timeout up to 30+ seconds. Or possibly 5 at least. > - contrains for selecting probes so that one can configure pings from 2 > probes on every AS. > - tcp ping to check connectivity to places that do not accept pings > - longer time-out for the atlas website. Is it 2 hours now? Could it be 12 > please? > - take firewalled probes out of the pool for new UDMs. I often get 2 > probes out of 10 that can not reach anything. If probe can nog reach most > root servers, it's pretty useless. > - stop - modify - start. Of UDMs > > > Thanks, > > Dave. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.karrenberg at ripe.net Tue Nov 12 08:35:44 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 12 Nov 2013 08:35:44 +0100 Subject: [atlas] Regularly Publish Metadata, Was: feature requests In-Reply-To: References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <5280BDD2.2060407@nic.at> <5280BE13.6030103@nic.at> <20131111120214.GU81676@Space.Net> <9B0645D3-811C-438C-B7F1-05D705DB7A54@gmail.com> Message-ID: <1A336A8C-B279-4967-9D90-E2AA01FA99BA@ripe.net> Hey, good to see the recent flurry of feature requests. I take it as an indication of active usage. Having become somewhat of a power user myself recently I have a request too. Let me suggest a little more structured way to make these requests. This would help everyone, including the developers, to understand them better. Also a snazzy title will make it easier to identify requests in the road map. Here is my first one: Title: Regularly Publish Metadata Description: Regularly publish a snapshot of all metadata, such as https://atlas.ripe.net/contrib/active_probes.json and https://atlas.ripe.net/atlas/publicprobesgrid.json?start=XX&limit=XX&sort=XX&dir=XX A period of once every 24 hours would be sufficient. Use: When analysing past measurements it is often required to refer to the state of RIPE Atlas at the time of the measurement. Referring to the current state will be less and less useful as the data analysed is more and more in the past. Changes in the meta data will make the results confusing at best and misleading at worst. Assumed complexity: Low, just dump it once a day and make it available in a structured way thru the API. Assumed cost: A little storage, not significant in the great scheme of things. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From daniel.karrenberg at ripe.net Tue Nov 12 08:43:56 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 12 Nov 2013 08:43:56 +0100 Subject: [atlas] Feature request: Regularly Publish Names Message-ID: <1F128ECE-3908-4630-8383-EC4B3B01FC1B@ripe.net> Title: Regularly Publish Names Description: Regularly collect all IP addresses referenced in measurement definitions and all results. Reverse resolve the addresses in the DNS. Collect netnames for the addresses from the RIR registration data. Possibly collect other data such as geo-location and ASes announcing. Publish this collected data both in bulk and thru the API indexed by IP. A frequency of once every 24 hours would be sufficient to stat with. Use: When analysing measurements from the past it is important to have meta information that was current at the time of the measurement. Having this data collected in advance often also allows for more efficient analysis and more responsive tools. Perceived complexity: Low. Use hadoop to collect the list of IPs. Then run a low priority job to collect the meta data. The job also has high potential for parallelism. Perceived cost: Low. Just some cycles and storage on the back end. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From daniel.karrenberg at ripe.net Tue Nov 12 10:26:43 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 12 Nov 2013 10:26:43 +0100 Subject: [atlas] Categorize probes (feature request) In-Reply-To: <527D197E.7050900@nic.at> References: <527D197E.7050900@nic.at> Message-ID: <86776046-F932-456D-8B86-C42F49E80D87@ripe.net> On 08.11.2013, at 18:03 , Klaus Darilion wrote: > Hi! > > Depending on the measurement, sometimes I want a realistic "user's view" which means using probes in residential areas, and sometimes I want a "backbone" view, which mean using probes in the back-bone (good connected) e.g. to measure my access network or my servers without the delay introduced by the probes access network. > > Thus, it would be cool if the probe selection algorithm allows also to choose "residential" probes or "backbone" probes. Maybe this categorization can be done automatically, or probe owners can be asked to specify the probes connectivity manually. > > Thanks, > Klaus I understand the question. I am not sure what the answer is, e.g. which categories we should use and how to do the categorisation. At the moment the Anchors provide backbone views. Most small probes are at the edge of the network. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From liman at netnod.se Wed Nov 6 19:50:26 2013 From: liman at netnod.se (Lars-Johan Liman) Date: Wed, 06 Nov 2013 10:50:26 -0800 Subject: [atlas] msm_name in DNS measurements? In-Reply-To: <527A1FC5.4060009@ripe.net> (Viktor Naumov's message of "Wed, 06 Nov 2013 11:53:57 +0100") References: <527A0D55.2040207@restena.lu> <527A1FC5.4060009@ripe.net> Message-ID: <22mwlhcqkt.fsf@ziptop.autonomica.net> vnaumov at ripe.net: > You can ignore it. It is for the system purposes. Umm. This is a very disappointing answer. The RIPE NCC always prides itself in being transparent. The answer above is not a supporting fact. It may well be that the field is for system purposes, but please do describe those system purposes. We are engineers, not children. Best regards, /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 liman at netnod.se Wed Nov 6 22:27:21 2013 From: liman at netnod.se (Lars-Johan Liman) Date: Wed, 06 Nov 2013 13:27:21 -0800 Subject: [atlas] msm_name in DNS measurements? In-Reply-To: <527AA917.4060803@ripe.net> (Viktor Naumov's message of "Wed, 06 Nov 2013 21:39:51 +0100") References: <527A0D55.2040207@restena.lu> <527A1FC5.4060009@ripe.net> <22mwlhcqkt.fsf@ziptop.autonomica.net> <527AA917.4060803@ripe.net> Message-ID: <22mwlh9q6e.fsf@ziptop.autonomica.net> vnaumov at ripe.net: > Well... It is a legacy field needed to speed up consumption of the > measurement results by saving on database requests. Result consumption > is a place where we put a lot of optimization efforts. Basically > Tdig' is a class name. > Since we are still in transition to the new measurement result storage > we need to keep it. As soon as we stop depending on it it will be > gone. > The system is evolving and it may happen that you get it in the > downloaded results because we are transparent and do little filtering > on the results data. > That is the reason you can ignore it and you shouldn't depend on it. Thanks! You've now stilled the curiosity of 200 engineers. :-) Cheers, /Liman From klaus.darilion at nic.at Tue Nov 12 12:00:08 2013 From: klaus.darilion at nic.at (Klaus Darilion) Date: Tue, 12 Nov 2013 12:00:08 +0100 Subject: [atlas] Categorize probes (feature request) In-Reply-To: <86776046-F932-456D-8B86-C42F49E80D87@ripe.net> References: <527D197E.7050900@nic.at> <86776046-F932-456D-8B86-C42F49E80D87@ripe.net> Message-ID: <52820A38.9080705@nic.at> Hi Daniel! On 12.11.2013 10:26, Daniel Karrenberg wrote: > On 08.11.2013, at 18:03 , Klaus Darilion wrote: > >> Hi! >> >> Depending on the measurement, sometimes I want a realistic "user's view" which means using probes in residential areas, and sometimes I want a "backbone" view, which mean using probes in the back-bone (good connected) e.g. to measure my access network or my servers without the delay introduced by the probes access network. >> >> Thus, it would be cool if the probe selection algorithm allows also to choose "residential" probes or "backbone" probes. Maybe this categorization can be done automatically, or probe owners can be asked to specify the probes connectivity manually. >> >> Thanks, >> Klaus > > I understand the question. I am not sure what the answer is, e.g. which categories we should use and how to do the categorisation. > At the moment the Anchors provide backbone views. Most small probes are at the edge of the network. I do want to measure the connectivity of the anchors node as this actually measures the connectivity of the probes when I assume that the anchor nodes are well connected. I want to test the connectivity from the Internet backbone to my servers (similar like the RIPE DNSMON). So for some UDM I want to use "backbone nodes" to see if there are problems with my servers, and for other UDMs I want to use "residental nodes" to see the end user view. regards Klaus From klaus.darilion at nic.at Tue Nov 12 12:09:06 2013 From: klaus.darilion at nic.at (Klaus Darilion) Date: Tue, 12 Nov 2013 12:09:06 +0100 Subject: [atlas] Categorize probes (feature request) In-Reply-To: <52820A38.9080705@nic.at> References: <527D197E.7050900@nic.at> <86776046-F932-456D-8B86-C42F49E80D87@ripe.net> <52820A38.9080705@nic.at> Message-ID: <52820C52.1090104@nic.at> On 12.11.2013 12:00, Klaus Darilion wrote: > Hi Daniel! > > On 12.11.2013 10:26, Daniel Karrenberg wrote: >> On 08.11.2013, at 18:03 , Klaus Darilion wrote: >> >>> Hi! >>> >>> Depending on the measurement, sometimes I want a realistic "user's >>> view" which means using probes in residential areas, and sometimes I >>> want a "backbone" view, which mean using probes in the back-bone >>> (good connected) e.g. to measure my access network or my servers >>> without the delay introduced by the probes access network. >>> >>> Thus, it would be cool if the probe selection algorithm allows also >>> to choose "residential" probes or "backbone" probes. Maybe this >>> categorization can be done automatically, or probe owners can be >>> asked to specify the probes connectivity manually. >>> >>> Thanks, >>> Klaus >> >> I understand the question. I am not sure what the answer is, e.g. >> which categories we should use and how to do the categorisation. >> At the moment the Anchors provide backbone views. Most small probes >> are at the edge of the network. > I do want to measure the connectivity of the anchors node as this > actually measures the connectivity of the probes when I assume that > the anchor nodes are well connected. ^^^^^^ Ups, typo. Should read: "I do NOT want" ... > > I want to test the connectivity from the Internet backbone to MY > servers (similar like the RIPE DNSMON). So for some UDM I want to use > "backbone nodes" to see if there are problems with my servers, and for > other UDMs I want to use "residental nodes" to see the end user view. > > regards > Klaus > From BECHA at ripe.net Tue Nov 12 13:23:06 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 12 Nov 2013 13:23:06 +0100 Subject: [atlas] Archiving user-defined measurements in Atlas In-Reply-To: References: Message-ID: <52821DAA.7020906@ripe.net> Dear Ivo, On 08-nov.-13 22:24, ivo.vdmaagdenberg at gmail.com wrote: > Hi, > > Played a bit with measurements, now I want make some sensible ones and > get rid of the rest. In the documentation "How do I stop a user-defined > measurement?" there is mention of the 'Archive' option per measurement. > > I see that option but it is grayed out. This was a bug - thanks for spotting it! Now that is fixed, and you should be able to "archive" stopped measurements. > The question is: What are the > circumstance that grey the option? This holds for the "Forced to Stop", > "Stopped" and "Ongoing" UDMs (maybe more...) You can not "archive" ongoing measurements, only "stopped". Archiving of the measurements with other statuses will be implemented later. Kind regards, Vesna From bortzmeyer at nic.fr Wed Nov 13 10:04:56 2013 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 13 Nov 2013 10:04:56 +0100 Subject: [atlas] Bulk access to the measurements? Message-ID: <20131113090456.GA13154@nic.fr> A colleague asks me if it is possible to have bulk access to public measurement data. (Properly: otherwise, he could dor a for loop over all measurement IDs but I suspect it is not nice.) I find nothing in the Atlas documentation. Is it because I do not search hard enough or because this possibility does not exist? #BigData From philip.homburg at ripe.net Wed Nov 13 11:16:12 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 13 Nov 2013 11:16:12 +0100 Subject: [atlas] Bulk access to the measurements? In-Reply-To: <20131113090456.GA13154@nic.fr> References: <20131113090456.GA13154@nic.fr> Message-ID: <5283516C.4020400@ripe.net> On 2013/11/13 10:04 , Stephane Bortzmeyer wrote: > A colleague asks me if it is possible to have bulk access to public > measurement data. (Properly: otherwise, he could dor a for loop over > all measurement IDs but I suspect it is not nice.) > > I find nothing in the Atlas documentation. Is it because I do not > search hard enough or because this possibility does not exist? No, there is no API for that. I wonder what it should look like. Assuming that one bulk data download gets 100 Mbps (just a guess, you don't want bulk data downloads to slow down the rest of the system) then downloading 1 Tbyte of data takes about a day. So for the entire Atlas data set that may easily be a week or more. Connections that last for more than a week are not nice, so I guess the client should maintain a cursor and issue multiple requests. (That is very close to just iterating over all measurements) One other issue is whether the data gets stored or not. If you are going to store data, then an API that can be used to update the stored data set make most sense. If you are not going to store the data, then running map/reduce on the server side make most sense, but I'm not sure if there exist proper sandbox environments to allow that to be done on the hadoop cluster directly. Philip From dquinn at ripe.net Wed Nov 13 11:20:20 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 13 Nov 2013 11:20:20 +0100 Subject: [atlas] Bulk access to the measurements? In-Reply-To: <20131113090456.GA13154@nic.fr> References: <20131113090456.GA13154@nic.fr> Message-ID: <52835264.9050005@ripe.net> On Wed 13 Nov 2013 10:04:56 CET, Stephane Bortzmeyer wrote: > A colleague asks me if it is possible to have bulk access to public > measurement data. (Properly: otherwise, he could dor a for loop over > all measurement IDs but I suspect it is not nice.) I think we'd need more information regarding what is meant by "bulk access". At present, all measurement *result* data is only available by way of explicit measurement id, but the *metadata* is available as a list: The results have to be fetched one measurement at a time: /api/v1/measurement/MSM_ID/result/ But you can get basic information about every measurement too: /api/v1/measurement/?is_public=1&limit=100 That call will give you a list of the first 100 of all public measurements and their metadata. You can tweak the limit (be kind) and/or loop over some limit/offset values to get them all. This won't give you all of the *result* data, but it may be what you're looking for. From daniel.karrenberg at ripe.net Wed Nov 13 11:31:30 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 13 Nov 2013 11:31:30 +0100 Subject: [atlas] Bulk access to the measurements? In-Reply-To: <5283516C.4020400@ripe.net> References: <20131113090456.GA13154@nic.fr> <5283516C.4020400@ripe.net> Message-ID: On 13.11.2013, at 11:16 , Philip Homburg wrote: > ... I wonder what it should look like. ... I would be happy to get all measurements for a 24-hour period at a time for measurements of the previously finished UTC day or earlier. This might be a good way to start and it would allow people to test their methods. We could add the most recent measurements later. In order to discourage frivolous downloads we could attach a price to it in credits. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gilles.massen at restena.lu Wed Nov 13 15:59:58 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Wed, 13 Nov 2013 15:59:58 +0100 Subject: [atlas] feature requests In-Reply-To: <20131111111217.GT81676@Space.Net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> Message-ID: <528393EE.4030604@restena.lu> Hi, On 11/11/2013 12:12 PM, Gert Doering wrote: > - restart an UDM after it has stopped > > - change parameters of an UDM and restart it, keeping the same ID I'd second those. For the second point: if keeping the same ID is not possible, allow to create a new measurement as an (editable) copy of a previous query (which would be a desirable feature on its own). Best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From gilles.massen at restena.lu Wed Nov 13 16:19:32 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Wed, 13 Nov 2013 16:19:32 +0100 Subject: [atlas] probe allocations In-Reply-To: <527D05EB.2030704@ripe.net> References: <527CF958.2070502@restena.lu> <527D05EB.2030704@ripe.net> Message-ID: <52839884.8090304@restena.lu> Andreas, On 11/08/2013 04:40 PM, Andreas Strikos wrote: > normally every measurement is allocated equal or less (if we don't have > enough) probes than the user has requested. > In your case though, due a bug, your measurement got scheduled more than > once, so you got more than you requested. As it happened again (this time >350 allocated probes instead of 53) I was wondering what triggers the bug? Is the scheduling of several measurement in one go the culprit? And is there a recommended workaround for the time being? Best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From daniel.karrenberg at ripe.net Wed Nov 13 18:01:54 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 13 Nov 2013 18:01:54 +0100 Subject: [atlas] feature requests In-Reply-To: <528393EE.4030604@restena.lu> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <528393EE.4030604@restena.lu> Message-ID: <01DE17FB-38E6-4961-8A22-B3CE06EEEDDA@ripe.net> On 13.11.2013, at 15:59 , Gilles Massen wrote: > For the second point: if keeping the same ID is not possible, allow to > create a new measurement as an (editable) copy of a previous query > (which would be a desirable feature on its own). I prefer creating a new editable measurement over changing an already defined measurement in any other aspect than ending time. Changing other parameters of a measurement will create confusion in diagnosing problems and will complicate any study of how Atlas is used. Changing the definition of something that is normally intended to be immutable looks like bad style/architecture to me in general. Measurement IDs are not scarce and I am sure Gert can write his scripts in a way that does not require him to keep track of IDs manually. ;-) Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From astrikos at ripe.net Wed Nov 13 19:26:22 2013 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 13 Nov 2013 10:26:22 -0800 Subject: [atlas] probe allocations In-Reply-To: <52839884.8090304@restena.lu> References: <527CF958.2070502@restena.lu> <527D05EB.2030704@ripe.net> <52839884.8090304@restena.lu> Message-ID: <5283C44E.1030406@ripe.net> Hi Gilles, after some more investigation I spotted another problem related to the the group measurements. I released a hot fix and this should be fixed now but the initial problem still remains. The frequency, though, of faulty scheduling will be reduced. The initial bug is triggered when we have a network timeout for one of our control messages. In that case another process kicks in and tries to schedule your measurement. Eventually, since we are handling the network timeouts for all of these control messages, the message is delivered and we schedule again your measurement. That situation was handled smoothly before a month, where we did a big change in the whole Atlas machinery in order to allow addition/removal of probes for all UDMs and unfortunately we broke this part. We know how to fix it but it might take a while (~ December). In the meantime if you or any other that is over-credited due to this bug please send us a mail and we can easily reimburse yours credits. I hope this answers your question :) Regards, Andreas On 11/13/13, 7:19 AM, Gilles Massen wrote: > Andreas, > > On 11/08/2013 04:40 PM, Andreas Strikos wrote: > >> normally every measurement is allocated equal or less (if we don't have >> enough) probes than the user has requested. >> In your case though, due a bug, your measurement got scheduled more than >> once, so you got more than you requested. > As it happened again (this time >350 allocated probes instead of 53) I > was wondering what triggers the bug? Is the scheduling of several > measurement in one go the culprit? And is there a recommended workaround > for the time being? > > Best, > Gilles > From gert at space.net Wed Nov 13 19:49:26 2013 From: gert at space.net (Gert Doering) Date: Wed, 13 Nov 2013 19:49:26 +0100 Subject: [atlas] feature requests In-Reply-To: <01DE17FB-38E6-4961-8A22-B3CE06EEEDDA@ripe.net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <528393EE.4030604@restena.lu> <01DE17FB-38E6-4961-8A22-B3CE06EEEDDA@ripe.net> Message-ID: <20131113184926.GZ81676@Space.Net> Hi, On Wed, Nov 13, 2013 at 06:01:54PM +0100, Daniel Karrenberg wrote: > Measurement IDs are not scarce and I am sure Gert can write his scripts in a way that does not require him to keep track of IDs manually. ;-) Sure I could. But I don't *want* that. Results are received by asking for an ID and a timeline. This is what I want to use, not "oh, jump through some 5 extra hoops to figure out what ID my measurement had at some point in the past". Doing this manually is tedious, doing this in a script is brittle. If your internal model doesn't allow this, add a "user-visible ID" that can be left unchanged but is sufficient to query the results. (And I don't want to set up a new UDM every time I want to test how a parameter change affects what I see. For me, this is *one* UDM that evolves over time) 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 gilles.massen at restena.lu Wed Nov 13 20:58:03 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Wed, 13 Nov 2013 20:58:03 +0100 Subject: [atlas] probe allocations In-Reply-To: <5283C44E.1030406@ripe.net> References: <527CF958.2070502@restena.lu> <527D05EB.2030704@ripe.net> <52839884.8090304@restena.lu> <5283C44E.1030406@ripe.net> Message-ID: <5283D9CB.3060408@restena.lu> Hi Andreas, On 13/11/13, 19:26 , Andreas Strikos wrote: > Hi Gilles, > > after some more investigation I spotted another problem related to the > the group measurements. I released a hot fix and this should be fixed > now but the initial problem still remains. The frequency, though, of > faulty scheduling will be reduced. Good, thanks for looking into it. > In the meantime if you or any other that is over-credited due to this > bug please send us a mail and we can easily reimburse yours credits. I will survive :) > I hope this answers your question :) Well, almost. I'm not entirely clear on how to setup my new measurement - considering that I'd want to have about 8 UDMs sharing the same set of probes (or a good approximation). Since you fixed it almost entirely, but not quite, should I retry the 'setup in one go' or rather do them individually and chose the probes from the first UDM? best, Gilles From astrikos at ripe.net Wed Nov 13 21:05:08 2013 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 13 Nov 2013 12:05:08 -0800 Subject: [atlas] probe allocations In-Reply-To: <5283D9CB.3060408@restena.lu> References: <527CF958.2070502@restena.lu> <527D05EB.2030704@ripe.net> <52839884.8090304@restena.lu> <5283C44E.1030406@ripe.net> <5283D9CB.3060408@restena.lu> Message-ID: <5283DB74.70303@ripe.net> On 11/13/13, 11:58 AM, Gilles Massen wrote: > Hi Andreas, > > On 13/11/13, 19:26 , Andreas Strikos wrote: >> Hi Gilles, >> >> after some more investigation I spotted another problem related to the >> the group measurements. I released a hot fix and this should be fixed >> now but the initial problem still remains. The frequency, though, of >> faulty scheduling will be reduced. > Good, thanks for looking into it. > >> In the meantime if you or any other that is over-credited due to this >> bug please send us a mail and we can easily reimburse yours credits. > I will survive :) > >> I hope this answers your question :) > Well, almost. I'm not entirely clear on how to setup my new measurement > - considering that I'd want to have about 8 UDMs sharing the same set of > probes (or a good approximation). Since you fixed it almost entirely, > but not quite, should I retry the 'setup in one go' or rather do them > individually and chose the probes from the first UDM? Try as you used to, with grouping (in one go as you said). As I said, the faulty scheduling frequency should be low now. > best, > Gilles > > Regards, Andreas From daniel.karrenberg at ripe.net Thu Nov 14 08:17:45 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 14 Nov 2013 08:17:45 +0100 Subject: [atlas] feature requests In-Reply-To: <20131113184926.GZ81676@Space.Net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <528393EE.4030604@restena.lu> <01DE17FB-38E6-4961-8A22-B3CE06EEEDDA@ripe.net> <20131113184926.GZ81676@Space.Net> Message-ID: <225FF3C4-1DD5-4B62-8941-6760CE18E9A4@ripe.net> On 13.11.2013, at 19:49 , Gert Doering wrote: > Hi, > > On Wed, Nov 13, 2013 at 06:01:54PM +0100, Daniel Karrenberg wrote: >> Measurement IDs are not scarce and I am sure Gert can write his scripts in a way that does not require him to keep track of IDs manually. ;-) > > Sure I could. But I don't *want* that.... We disagree. I am sure the Atlas developers can implement anything that can be done with an algorithm that runs on the platforms they have at their disposal. My point is specifically that not anything and everything should be done in any specific system. In the early Unix days we called this "creeping featurism". Good design and style avoids this. Someone else said it much better than I can possibly do: La perfection est enfin atteinte, non pas lorsqu'il n'y a plus rien ? ajouter, mais lorsqu'il n'y a plus rien ? enlever. Antoine de Saint Exup?ry My amateur translation: Perfection will finally be achieved, not when there is nothing left to add, but when there is nothing left to take away. So I still argue that what you want to do is best done in the form of a shell around multiple measurements. Of course if more people want such a shell, it should be put on the roadmap and supplied by the NCC. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From daniel.karrenberg at ripe.net Thu Nov 14 09:27:27 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 14 Nov 2013 09:27:27 +0100 Subject: [atlas] Categorize probes (feature request) In-Reply-To: <52820A38.9080705@nic.at> References: <527D197E.7050900@nic.at> <86776046-F932-456D-8B86-C42F49E80D87@ripe.net> <52820A38.9080705@nic.at> Message-ID: <30F3AE5B-1EE7-4F1F-8856-10604C476C61@ripe.net> On 12.11.2013, at 12:00 , Klaus Darilion wrote: > I want to test the connectivity from the Internet backbone to my servers (similar like the RIPE DNSMON). So for some UDM I want to use "backbone nodes" to see if there are problems with my servers, and for other UDMs I want to use "residental nodes" to see the end user view. Why not set up a UDM using only anchors for this, e.g from the anchors to your servers? Anchors have probe ids between 6000 and 7000. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From daniel.karrenberg at ripe.net Thu Nov 14 09:43:19 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 14 Nov 2013 09:43:19 +0100 Subject: [atlas] Categorize probes (feature request) In-Reply-To: <30F3AE5B-1EE7-4F1F-8856-10604C476C61@ripe.net> References: <527D197E.7050900@nic.at> <86776046-F932-456D-8B86-C42F49E80D87@ripe.net> <52820A38.9080705@nic.at> <30F3AE5B-1EE7-4F1F-8856-10604C476C61@ripe.net> Message-ID: On 14.11.2013, at 9:27 , Daniel Karrenberg wrote: > Why not set up a UDM using only anchors for this, e.g from the anchors to your servers? See measurement 1039778 for an example. It nicely explores the connectivity of a server: Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: labske-from-anchors.png Type: image/png Size: 37827 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From daniel.karrenberg at ripe.net Thu Nov 14 10:19:02 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 14 Nov 2013 10:19:02 +0100 Subject: [atlas] probe allocations In-Reply-To: <5283C44E.1030406@ripe.net> References: <527CF958.2070502@restena.lu> <527D05EB.2030704@ripe.net> <52839884.8090304@restena.lu> <5283C44E.1030406@ripe.net> Message-ID: <9B08FC15-EC08-4D75-8801-B3F2FD1FE0CC@ripe.net> On 13.11.2013, at 19:26 , Andreas Strikos wrote: > ... That situation was handled smoothly before a month, where we did a big change in the whole Atlas machinery in order to allow addition/removal of probes for all UDMs and unfortunately we broke this part. ... With hindsight(!) this shows that adding and removing probes in existing measurements was probably not such a good design choice, although I supported it in order to allow repleneshing the probe pool of long-running measurements. Maybe it would be better to revisit that design and go for creating new measurements based on existing ones. We could maintain the genesis history, e.g. which measurement was used as a basis for creating the new one. This would allow tracing back the chain. We could also note that a measurement was used as a template for new measurements which allows following the genesis chain forward. This would solve Gert's use case. It is never too late to review a design choice. It may be painful; but if it prevents future pain it may be the right thing to do. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gert at space.net Thu Nov 14 15:28:49 2013 From: gert at space.net (Gert Doering) Date: Thu, 14 Nov 2013 15:28:49 +0100 Subject: [atlas] feature requests In-Reply-To: <225FF3C4-1DD5-4B62-8941-6760CE18E9A4@ripe.net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <528393EE.4030604@restena.lu> <01DE17FB-38E6-4961-8A22-B3CE06EEEDDA@ripe.net> <20131113184926.GZ81676@Space.Net> <225FF3C4-1DD5-4B62-8941-6760CE18E9A4@ripe.net> Message-ID: <20131114142849.GJ81676@Space.Net> Hi, On Thu, Nov 14, 2013 at 08:17:45AM +0100, Daniel Karrenberg wrote: > On 13.11.2013, at 19:49 , Gert Doering wrote: > > > On Wed, Nov 13, 2013 at 06:01:54PM +0100, Daniel Karrenberg wrote: > >> Measurement IDs are not scarce and I am sure Gert can write his scripts in a way that does not require him to keep track of IDs manually. ;-) > > > > Sure I could. But I don't *want* that.... > > We disagree. I'm not sure we can disagree on what *I* *want*. :-) > I am sure the Atlas developers can implement anything that can > be done with an algorithm that runs on the platforms they have at > their disposal. My point is specifically that not anything and > everything should be done in any specific system. In the early Unix > days we called this "creeping featurism". Good design and style > avoids this. Someone else said it much better than I can possibly > do: Nice quote, and I agree with the underlying idea. OTOH, if you want to build a *successful* platform, it certainly helps to make it nice-to-use to those that are trying to *use* it. I can't find any intuitive reasons why I would find it useful to have to add new UDMs all the time when all I want is "restart a given UDM" or "add more probes to a given UDM, but keep the rest of the parameters the same", etc. But anyway. My wishes have been stated a few times now, do what you want with it. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From gilles.massen at restena.lu Thu Nov 14 16:51:58 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Thu, 14 Nov 2013 16:51:58 +0100 Subject: [atlas] probe allocations In-Reply-To: <5283DB74.70303@ripe.net> References: <527CF958.2070502@restena.lu> <527D05EB.2030704@ripe.net> <52839884.8090304@restena.lu> <5283C44E.1030406@ripe.net> <5283D9CB.3060408@restena.lu> <5283DB74.70303@ripe.net> Message-ID: <5284F19E.9020904@restena.lu> Hi Andreas, > Try as you used to, with grouping (in one go as you said). As I said, > the faulty scheduling frequency should be low now. It works fine now (at least this time :) ). Thanks! Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From job.snijders at hibernianetworks.com Thu Nov 14 17:06:35 2013 From: job.snijders at hibernianetworks.com (Job Snijders) Date: Thu, 14 Nov 2013 17:06:35 +0100 Subject: [atlas] Power plugs for the Anchor nodes Message-ID: <20131114160635.GM17022@Eleanor.local> Dear all, A moment of clarity occurred to me, just before I shipped out some anchor nodes: the power plugs on the back of box (C7 type) won't easily be connected in most datacenter deployments. I found these cute plugs [1], which can be ordered here [2]. Hope this helps others :-) How have others solved the issue? Any ideas on how to get these Anchors to run on 48V DC (for telco-style deployment)? Kind regards, Job [1] - http://www.kempelektroniks.nl/FilesContent/menu/menu000250/images_iecc7adapters400_copy1.png [2] - http://shop.kempelektroniks.nl/index.php/accessories/iec-adapters.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 873 bytes Desc: not available URL: From gilles.massen at restena.lu Thu Nov 14 17:37:04 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Thu, 14 Nov 2013 17:37:04 +0100 Subject: [atlas] UI displays of measurements Message-ID: <5284FC30.5010308@restena.lu> Hi, When you visualize a measurement in the GUI, what data is used for tabs like "Probes" or "Map"? Is that the latest available data from each participating probe, or something else? Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From gilles.massen at restena.lu Thu Nov 14 17:47:28 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Thu, 14 Nov 2013 17:47:28 +0100 Subject: [atlas] probe allocations In-Reply-To: <9B08FC15-EC08-4D75-8801-B3F2FD1FE0CC@ripe.net> References: <527CF958.2070502@restena.lu> <527D05EB.2030704@ripe.net> <52839884.8090304@restena.lu> <5283C44E.1030406@ripe.net> <9B08FC15-EC08-4D75-8801-B3F2FD1FE0CC@ripe.net> Message-ID: <5284FEA0.9070304@restena.lu> On 11/14/2013 10:19 AM, Daniel Karrenberg wrote: > With hindsight(!) this shows that adding and removing probes in > existing measurements was probably not such a good design choice, > although I supported it in order to allow repleneshing the probe pool > of long-running measurements. >From a simple user point of view I have mixed feelings toward that feature: on one hand it would prevent long running measurements from decaying, on the other hand if you run (multiple) measurements on a specific set of probes you might not want them to drift apart. Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From nick at inex.ie Thu Nov 14 17:35:40 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 14 Nov 2013 16:35:40 +0000 Subject: [atlas] Power plugs for the Anchor nodes In-Reply-To: <20131114160635.GM17022@Eleanor.local> References: <20131114160635.GM17022@Eleanor.local> Message-ID: <5284FBDC.302@inex.ie> On 14/11/2013 16:06, Job Snijders wrote: > How have others solved the issue? Any ideas on how to get these Anchors > to run on 48V DC (for telco-style deployment)? https://www.soekris.com/manuals/net6501_manual.pdf > 4.1 J7, DC Input Jack > The 2.1mm DC Power Jack should be used for connecting a small wall mount > unregulated power adapter, supplying 6V - 28V DC at minimum 15 VA, > preferable more depending on expansion added, with a 5.5mm outside, > 2.1mm inside female power plug with plus at center pin. It is protected > against reverse polarity. > Please note that standard unregulated power transformers can supply much > higher voltage that the specified nominal voltage, so when using such a > type it's recommended to use one that is specified for 16V DC or less. So all you need to do is transform from -48VDC to say +16V/1A and feed that to a 2.1mm connector. Nick From dquinn at ripe.net Thu Nov 14 18:04:38 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Thu, 14 Nov 2013 18:04:38 +0100 Subject: [atlas] UI displays of measurements In-Reply-To: <5284FC30.5010308@restena.lu> References: <5284FC30.5010308@restena.lu> Message-ID: <528502A6.8070109@ripe.net> The data shown on these tabs is direct from our datastore and should be the latest values available at page load time. From daniel.karrenberg at ripe.net Thu Nov 14 19:40:06 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 14 Nov 2013 19:40:06 +0100 Subject: [atlas] probe allocations In-Reply-To: <5284FEA0.9070304@restena.lu> References: <527CF958.2070502@restena.lu> <527D05EB.2030704@ripe.net> <52839884.8090304@restena.lu> <5283C44E.1030406@ripe.net> <9B08FC15-EC08-4D75-8801-B3F2FD1FE0CC@ripe.net> <5284FEA0.9070304@restena.lu> Message-ID: <5C16003A-750D-48D9-B3E0-00F5A969D13B@ripe.net> On 14.11.2013, at 17:47 , Gilles Massen wrote: > > On 11/14/2013 10:19 AM, Daniel Karrenberg wrote: > >> With hindsight(!) this shows that adding and removing probes in >> existing measurements was probably not such a good design choice, >> although I supported it in order to allow repleneshing the probe pool >> of long-running measurements. > >> From a simple user point of view I have mixed feelings toward that > feature: on one hand it would prevent long running measurements from > decaying, on the other hand if you run (multiple) measurements on a > specific set of probes you might not want them to drift apart. Don't worry. No matter how we implement it, it will be configurable. e.g.: if the number of probes drops below a configurable threshold one will have the option to stop the measurement or replenish. Or one can do nothing until there is no probe left. > > Gilles > > -- > Fondation RESTENA - DNS-LU > 6, rue Coudenhove-Kalergi > L-1359 Luxembourg > tel: (+352) 424409 > fax: (+352) 422473 > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gilles.massen at restena.lu Fri Nov 15 07:47:29 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Fri, 15 Nov 2013 07:47:29 +0100 Subject: [atlas] UI displays of measurements In-Reply-To: <528502A6.8070109@ripe.net> References: <5284FC30.5010308@restena.lu> <528502A6.8070109@ripe.net> Message-ID: <5285C381.1050903@restena.lu> On 11/14/2013 06:04 PM, Daniel Quinn wrote: > The data shown on these tabs is direct from our datastore and should be > the latest values available at page load time. Thanks, that's as expected. Then I have the obvious addition to the feature request list: please make it possible to pick the time for the data to be mapped. And as a suggestion, to go along with it: add a 'download the shown data set' button. Both elements would make it easier to navigate measurements visually (rather then drill through the raw data) but still go through the details whenever the colors look 'unusual'. Both features are probably most useful to lazy users :) Best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From BECHA at ripe.net Fri Nov 15 11:46:09 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 15 Nov 2013 11:46:09 +0100 Subject: [atlas] Power plugs for the Anchor nodes In-Reply-To: <20131114160635.GM17022@Eleanor.local> References: <20131114160635.GM17022@Eleanor.local> Message-ID: <5285FB71.60107@ripe.net> Hi Job, all, On 14-nov.-13 17:06, Job Snijders wrote: > Dear all, > > A moment of clarity occurred to me, just before I shipped out some anchor > nodes: the power plugs on the back of box (C7 type) won't easily be > connected in most datacenter deployments. > > I found these cute plugs [1], which can be ordered here [2]. Hope this > helps others :-) We have suggested to all anchor hosts who are ordering from the supplier we are working with to also order the converter cable, should they need it, at no extra cost: https://encrypted.kd85.com/ripe-atlas-anchor.html "C14 Power cable, for use in racks, back of UPS, ..." I asked Wim to clarify the page even more, just in case it is not clear to more people then just Job. Thanks for flagging this! Vesna From colin at spakka.net Fri Nov 15 11:51:33 2013 From: colin at spakka.net (Colin Petrie) Date: Fri, 15 Nov 2013 11:51:33 +0100 Subject: [atlas] Power plugs for the Anchor nodes In-Reply-To: <5284FBDC.302@inex.ie> References: <20131114160635.GM17022@Eleanor.local> <5284FBDC.302@inex.ie> Message-ID: <5285FCB5.3020801@spakka.net> On 11/14/13 5:35 PM, Nick Hilliard wrote: > So all you need to do is transform from -48VDC to say +16V/1A and feed that > to a 2.1mm connector. FYI, there's also a power supply header on the board (instead of using the 2.1mm jack): 4.15 JP15, DC Power 4 pins AMP MTA100 header, for connecting of an internal power supply of 5V to 28V DC., Pin 1 is the top pin, closest to JP 16. Please note that JP15 is NOT protected against reverse voltage. Regards, Colin From tarko at lanparty.ee Wed Nov 20 12:48:02 2013 From: tarko at lanparty.ee (Tarko Tikan) Date: Wed, 20 Nov 2013 13:48:02 +0200 Subject: [atlas] Sudden raise in UDM credit consumption Message-ID: <528CA172.2050200@lanparty.ee> hey, Has there been a change how UDM probe prices are calculated? I stopped old UDM (1004320) that had following parameters: - v4 ping - 10 probes - 240 seconds, 3 packets, size 500 - 3.0 credits per result, 10800 credits per day When I created identical UDM (1040516) (UDM parameters should really be changeable to there should be possiblity to clone UDM and then modify all parameters) with double amount of probes (20) and same parameters, I'm now suddenly charged 31.25 credits per result. This does not follow the linear logic as only parameter that changed is number of probes. -- tarko From dquinn at ripe.net Wed Nov 20 14:06:56 2013 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 20 Nov 2013 14:06:56 +0100 Subject: [atlas] Sudden raise in UDM credit consumption In-Reply-To: <528CA172.2050200@lanparty.ee> References: <528CA172.2050200@lanparty.ee> Message-ID: <528CB3F0.3050309@ripe.net> On Wed 20 Nov 2013 12:48:02 CET, Tarko Tikan wrote: > Has there been a change how UDM probe prices are calculated? Yes and no. Yes, there was a change, but it happened some time ago. January of this year in fact. It used to be that we didn't charge for packet size, but back in January, we opted to start charging for packet size as well as an increase in packet size would reflect an increase in traffic. We didn't want to punish users who were already running measurements though, so we grandfathered these in, which is why your old measurement cost you only 3cr per result, but your new one costs 31.25cr per result. The details of the pricing scheme can be found on the credits documentation page: https://atlas.ripe.net/docs/credits/ I hope that helps explain things :-) From tarko at lanparty.ee Wed Nov 20 15:50:29 2013 From: tarko at lanparty.ee (Tarko Tikan) Date: Wed, 20 Nov 2013 16:50:29 +0200 Subject: [atlas] Sudden raise in UDM credit consumption In-Reply-To: <528CB3F0.3050309@ripe.net> References: <528CA172.2050200@lanparty.ee> <528CB3F0.3050309@ripe.net> Message-ID: <528CCC35.9080903@lanparty.ee> hey, > Yes, there was a change, but it happened some time ago. January of > this year in fact. It used to be that we didn't charge for packet > size, but back in January, we opted to start charging for packet size > as well as an increase in packet size would reflect an increase in > traffic. Thanks, this totally explains it. -- tarko From f4w at echo.emu.st Wed Nov 20 16:32:36 2013 From: f4w at echo.emu.st (Mark Delany) Date: 20 Nov 2013 15:32:36 +0000 Subject: [atlas] Very short uptime for some probes Message-ID: <20131120153236.56186.qmail@f5-external.bushwire.net> Hi all. I've only been on this list for a relatively short while so this is most likely in an FAQ I should be digging thru... I've noticed that the uptime for some of the physical probes we've installed are very short. According to the control panel, one in particular has connect times of around 2-3 minutes and disconnect times of 4-6 minutes. This cycle is repeated every 10 minutes or so. All day, every day. Superficially that sort of pattern suggests some sort of continuous reboot loop. However, if I ping the probe remotely, I get just an occasional packet loss. Certainly no long gaps that you'd expect from a continuous reboot. That I can ping it remotely also suggests that external connectivity isn't the problem. Besides the periodicity is just too regular and frequent for a routing loss or similar. (In any event, if the network it's on is losing connectivity every 5 minutes I would have plenty of other symptoms.) The problem probe is also reported as getting UDMs assigned and running them so I'm not quite sure how it manages to squeeze those tests in if that connectivity status report is accurate. So my main question is, should I be concerned about the control panel connectivity reports? And if I should be, is there much I can do beyond ensuring the device has good connectivity? Mark. From philip.homburg at ripe.net Wed Nov 20 17:00:41 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 20 Nov 2013 17:00:41 +0100 Subject: [atlas] Very short uptime for some probes In-Reply-To: <20131120153236.56186.qmail@f5-external.bushwire.net> References: <20131120153236.56186.qmail@f5-external.bushwire.net> Message-ID: <528CDCA9.2020904@ripe.net> Hi, On 2013/11/20 16:32 , Mark Delany wrote: > I've noticed that the uptime for some of the physical probes we've > installed are very short. According to the control panel, one in > particular has connect times of around 2-3 minutes and disconnect > times of 4-6 minutes. This cycle is repeated every 10 minutes or > so. All day, every day. > > Superficially that sort of pattern suggests some sort of continuous > reboot loop. This is not normal. The probe is not rebooting, but it is constantly losing its connection to the controller. And it doesn't seem to report any results. I'll send it to a different controller to see if it makes a difference. Philip From f4w at echo.emu.st Wed Nov 20 20:50:14 2013 From: f4w at echo.emu.st (Mark Delany) Date: 20 Nov 2013 19:50:14 +0000 Subject: [atlas] Very short uptime for some probes In-Reply-To: <528CDCA9.2020904@ripe.net> References: <20131120153236.56186.qmail@f5-external.bushwire.net> <528CDCA9.2020904@ripe.net> Message-ID: <20131120195014.57439.qmail@f5-external.bushwire.net> On 20Nov13, Philip Homburg allegedly wrote: > Hi, > > On 2013/11/20 16:32 , Mark Delany wrote: > > I've noticed that the uptime for some of the physical probes we've > > installed are very short. > This is not normal. The probe is not rebooting, but it is constantly > losing its connection to the controller. And it doesn't seem to report > any results. > > I'll send it to a different controller to see if it makes a difference. You probably know this Philip, but that made an instant difference. That probe is now reporting being up 100% since the switch. Just out of curiousity, do you have a theory on why switching controllers makes a difference? If it's a bit of a mystery at the controller end, is there anything we can do to help diagnose the problem at the probe end? As you can see I have a nicely reproducable situation if it's of use. Mark. From philip.homburg at ripe.net Thu Nov 21 11:05:15 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 21 Nov 2013 11:05:15 +0100 Subject: [atlas] Very short uptime for some probes In-Reply-To: <20131120195014.57439.qmail@f5-external.bushwire.net> References: <20131120153236.56186.qmail@f5-external.bushwire.net> <528CDCA9.2020904@ripe.net> <20131120195014.57439.qmail@f5-external.bushwire.net> Message-ID: <528DDADB.6050002@ripe.net> Hi Mark, On 2013/11/20 20:50 , Mark Delany wrote: > You probably know this Philip, but that made an instant > difference. That probe is now reporting being up 100% since the > switch. > > Just out of curiousity, do you have a theory on why switching > controllers makes a difference? We have some ideas of what it might be. I'll look if I can find out what is going on from our end. Philip From davidp at preshweb.co.uk Thu Nov 21 11:52:49 2013 From: davidp at preshweb.co.uk (David Precious) Date: Thu, 21 Nov 2013 10:52:49 +0000 Subject: [atlas] HTTP/HTTPS probe In-Reply-To: References: <524AE49C.4080005@netassist.ua> <524B0DF8.4000409@ripe.net> <20131002081343.GA31298@nic.fr> <524BDC8E.8080907@ripe.net> <20131002092137.Horde.vjUFJNi2YDSy8Gl2w01atw2@mail.kix.es> Message-ID: <20131121105249.448614a6@columbia> On Wed, 2 Oct 2013 14:13:11 -0400 Richard Barnes wrote: > (3) is a huge security risk, because of the wide variety of things > that are done with HTTP requests. For simplicity, let's assume the > probe would send a GET request, and not anything more sophisticated > (POST, PUT, DELETE, etc.). You could use a GET request to download a > file, but you can also a GET request to do things to supply responses > to HTTP forms. Want to make sure your favorite band wins the > EuroVision Song Contest? Just task the Atlas network have 1000 > probes vote for them every 5 minutes. GET requests should not alter state; if they do, arguably the problem there lies with the design of the faulty website. From rlb at ipv.sx Thu Nov 21 15:18:22 2013 From: rlb at ipv.sx (Richard Barnes) Date: Thu, 21 Nov 2013 09:18:22 -0500 Subject: [atlas] HTTP/HTTPS probe In-Reply-To: <20131121105249.448614a6@columbia> References: <524AE49C.4080005@netassist.ua> <524B0DF8.4000409@ripe.net> <20131002081343.GA31298@nic.fr> <524BDC8E.8080907@ripe.net> <20131002092137.Horde.vjUFJNi2YDSy8Gl2w01atw2@mail.kix.es> <20131121105249.448614a6@columbia> Message-ID: On Thursday, November 21, 2013, David Precious wrote: > On Wed, 2 Oct 2013 14:13:11 -0400 > Richard Barnes wrote: > > > (3) is a huge security risk, because of the wide variety of things > > that are done with HTTP requests. For simplicity, let's assume the > > probe would send a GET request, and not anything more sophisticated > > (POST, PUT, DELETE, etc.). You could use a GET request to download a > > file, but you can also a GET request to do things to supply responses > > to HTTP forms. Want to make sure your favorite band wins the > > EuroVision Song Contest? Just task the Atlas network have 1000 > > probes vote for them every 5 minutes. > > GET requests should not alter state; if they do, arguably the problem > there lies with the design of the faulty website. > > Indeed, that is what the HTTP spec says. But there are a good number of fault websites out there, and it seems bad to have Atlas be a tool to exploit them. In theory, there's no difference between theory and practice, but in practice there is :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From the.lists at mgm51.com Thu Nov 21 19:12:20 2013 From: the.lists at mgm51.com (Mike.) Date: Thu, 21 Nov 2013 13:12:20 -0500 Subject: [atlas] Change account email address Message-ID: <201311211312200444.0105AC2B@smtp.24cl.home> Hi, Is there a way to change the email address that is used to log in to the RIPE Atlas site? I am talking about the email address that is the answer to the prompt: Sign in using your RIPE NCC Access account and not the alert email address used when the probe goes offline for a period of time. Thanks, Mike. From f4w at echo.emu.st Thu Nov 21 19:23:05 2013 From: f4w at echo.emu.st (Mark Delany) Date: 21 Nov 2013 18:23:05 +0000 Subject: [atlas] HTTP/HTTPS probe In-Reply-To: References: <524AE49C.4080005@netassist.ua> <524B0DF8.4000409@ripe.net> <20131002081343.GA31298@nic.fr> <524BDC8E.8080907@ripe.net> <20131002092137.Horde.vjUFJNi2YDSy8Gl2w01atw2@mail.kix.es> <20131121105249.448614a6@columbia> Message-ID: <20131121182305.62060.qmail@f5-external.bushwire.net> On 21Nov13, Richard Barnes allegedly wrote: > > GET requests should not alter state; if they do, arguably the problem > > there lies with the design of the faulty website. > > > > > Indeed, that is what the HTTP spec says. But there are a good number of > fault websites out there, and it seems bad to have Atlas be a tool to > exploit them. Agreed. Given the infinite monkeys that have written piblic facing web services, there is bound to be web sites that use HTTP verbs in weird and wonderful ways. But what about using HEAD? That would serve a lot of monitoring purposes as it can give you connect time and time to first byte, it doesn't return any content so the problem of fetching dodgy content is mitigated and the size of the payload is much more constrained. Another alternative is to only allow something like the "OPTION" or "TRACE" verbs. For those probing their own systems they could implement these VERBs but even if those VERBS aren't implemented you still get time to first byte as a consequence of the error returned. Mark. From ax at initrd.net Thu Nov 21 19:30:10 2013 From: ax at initrd.net (Imre Szvorenyi) Date: Thu, 21 Nov 2013 19:30:10 +0100 Subject: [atlas] HTTP/HTTPS probe In-Reply-To: <20131121182305.62060.qmail@f5-external.bushwire.net> References: <524AE49C.4080005@netassist.ua> <524B0DF8.4000409@ripe.net> <20131002081343.GA31298@nic.fr> <524BDC8E.8080907@ripe.net> <20131002092137.Horde.vjUFJNi2YDSy8Gl2w01atw2@mail.kix.es> <20131121105249.448614a6@columbia> <20131121182305.62060.qmail@f5-external.bushwire.net> Message-ID: Hi, HEAD would be better imho because TRACE mode is usually disabled. (vulnerability scanners tend to complain about it so it will be disabled most of the time...) ax On Thu, Nov 21, 2013 at 7:23 PM, Mark Delany wrote: > On 21Nov13, Richard Barnes allegedly wrote: > > > GET requests should not alter state; if they do, arguably the problem > > > there lies with the design of the faulty website. > > > > > > > > Indeed, that is what the HTTP spec says. But there are a good number of > > fault websites out there, and it seems bad to have Atlas be a tool to > > exploit them. > > Agreed. Given the infinite monkeys that have written piblic facing web > services, there is bound to be web sites that use HTTP verbs in weird > and wonderful ways. > > But what about using HEAD? > > That would serve a lot of monitoring purposes as it can give you > connect time and time to first byte, it doesn't return any content so > the problem of fetching dodgy content is mitigated and the size of the > payload is much more constrained. > > Another alternative is to only allow something like the "OPTION" or > "TRACE" verbs. > > For those probing their own systems they could implement these VERBs > but even if those VERBS aren't implemented you still get time to first > byte as a consequence of the error returned. > > > Mark. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnaumov at ripe.net Thu Nov 21 20:05:10 2013 From: vnaumov at ripe.net (Viktor Naumov) Date: Thu, 21 Nov 2013 20:05:10 +0100 Subject: [atlas] Change account email address In-Reply-To: <201311211312200444.0105AC2B@smtp.24cl.home> References: <201311211312200444.0105AC2B@smtp.24cl.home> Message-ID: <528E5966.7000808@ripe.net> Hi Mike, You can create a new account and transfer your probe and credits to it. WBR /vty On 11/21/13 7:12 PM, Mike. wrote: > Hi, > > Is there a way to change the email address that is used to log > in to the RIPE Atlas site? > > I am talking about the email address that is the answer to the > prompt: > > Sign in using your RIPE NCC Access account > > and not the alert email address used when the probe goes offline > for a period of time. > > Thanks, > Mike. > > > > From the.lists at mgm51.com Thu Nov 21 20:24:59 2013 From: the.lists at mgm51.com (Mike.) Date: Thu, 21 Nov 2013 14:24:59 -0500 Subject: [atlas] Change account email address In-Reply-To: <528E5966.7000808@ripe.net> References: <201311211312200444.0105AC2B@smtp.24cl.home> <528E5966.7000808@ripe.net> Message-ID: <201311211424590276.01482ED3@smtp.24cl.home> On 11/21/2013 at 8:05 PM Viktor Naumov wrote: |Hi Mike, | |You can create a new account and transfer your probe and credits to it. | ============= Hi Viktor, I was hoping not to have to do that. Someone pointed out this webpage to me in a private email: https://access.ripe.net/profile That allows email and password changes to be made. Perhaps it should be called out on the Atlas page somewhere, imo. Thanks, Mike. From rlb at ipv.sx Thu Nov 21 20:41:43 2013 From: rlb at ipv.sx (Richard Barnes) Date: Thu, 21 Nov 2013 14:41:43 -0500 Subject: [atlas] HTTP/HTTPS probe In-Reply-To: References: <524AE49C.4080005@netassist.ua> <524B0DF8.4000409@ripe.net> <20131002081343.GA31298@nic.fr> <524BDC8E.8080907@ripe.net> <20131002092137.Horde.vjUFJNi2YDSy8Gl2w01atw2@mail.kix.es> <20131121105249.448614a6@columbia> <20131121182305.62060.qmail@f5-external.bushwire.net> Message-ID: I think HEAD would probably be OK. At least, I'm not aware of any exploits that would enable. --Richard On Thu, Nov 21, 2013 at 1:30 PM, Imre Szvorenyi wrote: > Hi, > > > HEAD would be better imho because TRACE mode is usually disabled. > (vulnerability scanners tend to complain about it so it will be disabled > most of the time...) > > ax > > > > > > > On Thu, Nov 21, 2013 at 7:23 PM, Mark Delany wrote: > >> On 21Nov13, Richard Barnes allegedly wrote: >> > > GET requests should not alter state; if they do, arguably the problem >> > > there lies with the design of the faulty website. >> > > >> > > >> > Indeed, that is what the HTTP spec says. But there are a good number of >> > fault websites out there, and it seems bad to have Atlas be a tool to >> > exploit them. >> >> Agreed. Given the infinite monkeys that have written piblic facing web >> services, there is bound to be web sites that use HTTP verbs in weird >> and wonderful ways. >> >> But what about using HEAD? >> >> That would serve a lot of monitoring purposes as it can give you >> connect time and time to first byte, it doesn't return any content so >> the problem of fetching dodgy content is mitigated and the size of the >> payload is much more constrained. >> >> Another alternative is to only allow something like the "OPTION" or >> "TRACE" verbs. >> >> For those probing their own systems they could implement these VERBs >> but even if those VERBS aren't implemented you still get time to first >> byte as a consequence of the error returned. >> >> >> Mark. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Fri Nov 22 09:21:49 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 22 Nov 2013 09:21:49 +0100 Subject: [atlas] Change account email address In-Reply-To: <201311211424590276.01482ED3@smtp.24cl.home> References: <201311211312200444.0105AC2B@smtp.24cl.home> <528E5966.7000808@ripe.net> <201311211424590276.01482ED3@smtp.24cl.home> Message-ID: <528F141D.3040400@ripe.net> Hi Mike, On 21-nov.-13 20:24, Mike. wrote: > > Someone pointed out this webpage to me in a private email: > > https://access.ripe.net/profile > > That allows email and password changes to be made. Perhaps it > should be called out on the Atlas page somewhere, imo. We will add this to the FAQ. Kind regards, Vesna From robert at ripe.net Fri Nov 22 09:27:12 2013 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 22 Nov 2013 09:27:12 +0100 Subject: [atlas] Change account email address In-Reply-To: <201311211312200444.0105AC2B@smtp.24cl.home> References: <201311211312200444.0105AC2B@smtp.24cl.home> Message-ID: <528F1560.8080000@ripe.net> On 2013.11.21. 19:12, Mike. wrote: > Hi, > > Is there a way to change the email address that is used to log > in to the RIPE Atlas site? > > I am talking about the email address that is the answer to the > prompt: > > Sign in using your RIPE NCC Access account > > and not the alert email address used when the probe goes offline > for a period of time. > > Thanks, > Mike. You can also change your email address globally at https://access.ripe.net/, which will be picked up by RIPE Atlas as well as other NCC services that rely on the single sing on feature -- but keep in mind that later you will not be able to change it back to what it used to be. Regards, Robert From robert at ripe.net Fri Nov 22 09:32:56 2013 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 22 Nov 2013 09:32:56 +0100 Subject: [atlas] Change account email address In-Reply-To: <528F1560.8080000@ripe.net> References: <201311211312200444.0105AC2B@smtp.24cl.home> <528F1560.8080000@ripe.net> Message-ID: <528F16B8.2000507@ripe.net> > You can also change your email address globally at https://access.ripe.net/, > which will be picked up by RIPE Atlas as well as other NCC services that > rely on the single sing on feature -- but keep in mind that later you will > not be able to change it back to what it used to be. > > Regards, > Robert Apologies for the noise, I did not see that this was already covered. Robert From robert at ripe.net Fri Nov 22 10:19:20 2013 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 22 Nov 2013 10:19:20 +0100 Subject: [atlas] UI displays of measurements In-Reply-To: <5285C381.1050903@restena.lu> References: <5284FC30.5010308@restena.lu> <528502A6.8070109@ripe.net> <5285C381.1050903@restena.lu> Message-ID: <528F2198.7050405@ripe.net> On 2013.11.15. 7:47, Gilles Massen wrote: > > On 11/14/2013 06:04 PM, Daniel Quinn wrote: >> The data shown on these tabs is direct from our datastore and should be >> the latest values available at page load time. > > Thanks, that's as expected. > > Then I have the obvious addition to the feature request list: please > make it possible to pick the time for the data to be mapped. And as a > suggestion, to go along with it: add a 'download the shown data set' > button. Both elements would make it easier to navigate measurements > visually (rather then drill through the raw data) but still go through > the details whenever the colors look 'unusual'. Both features are > probably most useful to lazy users :) This would be the "time travel" feature -- as in "show me the map as it looked at X". Good idea, and it seems not too difficult; we'll put it on the agenda. Regards, Robert From robert at ripe.net Fri Nov 22 10:27:36 2013 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 22 Nov 2013 10:27:36 +0100 Subject: [atlas] Categorize probes (feature request) In-Reply-To: <5280B655.4000207@ripe.net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> Message-ID: <528F2388.3010500@ripe.net> On 2013.11.11. 11:49, Vesna Manojlovic wrote: > You can expect that we will get to work on this "soon", but I can't give you > any time estimates yet on when will this be implemented. Update: this request is closely related to a set of changes we're already working on, related to the layout of the probe list and probe status pages. So I can confirm that this is no longer "requested" but "in progress". Regards, Robert From philip.homburg at ripe.net Fri Nov 22 11:08:39 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 22 Nov 2013 11:08:39 +0100 Subject: [atlas] feature requests In-Reply-To: <201311111332380325.00AAD1E2@smtp.24cl.home> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <5280BDD2.2060407@nic.at> <5280BE13.6030103@nic.at> <20131111120214.GU81676@Space.Net> <9B0645D3-811C-438C-B7F1-05D705DB7A54@gmail.com> <201311111332380325.00AAD1E2@smtp.24cl.home> Message-ID: <528F2D27.2040003@ripe.net> Hi, On 2013/11/11 19:32 , Mike. wrote: > Allow me to disable the processing of RA's on IPv6, so that I > can configure IPv6 statically and not have it overwritten by an > RA. This feature has been requested by a handful of people. However, this introduces more complexity in the already way too complex network configuration of the probes. So we like to avoid implementing this feature. Of course if there is wide spread demand for it, then we will look into it. I should try it sometime, but in theory one way to give the static address priority is to set all prefixes in the RA to deprecated. On a 'normal' network where you one prefix, it should not make a difference for any of the other hosts. Philip From rm at romanrm.net Fri Nov 22 11:17:55 2013 From: rm at romanrm.net (Roman Mamedov) Date: Fri, 22 Nov 2013 16:17:55 +0600 Subject: [atlas] feature requests In-Reply-To: <528F2D27.2040003@ripe.net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <5280BDD2.2060407@nic.at> <5280BE13.6030103@nic.at> <20131111120214.GU81676@Space.Net> <9B0645D3-811C-438C-B7F1-05D705DB7A54@gmail.com> <201311111332380325.00AAD1E2@smtp.24cl.home> <528F2D27.2040003@ripe.net> Message-ID: <20131122161755.4ba7af44@natsu> On Fri, 22 Nov 2013 11:08:39 +0100 Philip Homburg wrote: > I should try it sometime, but in theory one way to give the static > address priority is to set all prefixes in the RA to deprecated. On a > 'normal' network where you one prefix, it should not make a difference > for any of the other hosts. It will make them prefer IPv4 over IPv6 for dual-stack destinations. # curl -vI google.com * About to connect() to google.com port 80 (#0) * Trying 2a00:1450:4001:808::1004... ... # ip addr change 2001:470:xxxxxxxx preferred_lft 0 dev wlan0 # curl -vI google.com * About to connect() to google.com port 80 (#0) * Trying 173.194.112.131.. ... -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From robert at ripe.net Fri Nov 22 11:30:04 2013 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 22 Nov 2013 11:30:04 +0100 Subject: [atlas] feature requests In-Reply-To: <20131114142849.GJ81676@Space.Net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <528393EE.4030604@restena.lu> <01DE17FB-38E6-4961-8A22-B3CE06EEEDDA@ripe.net> <20131113184926.GZ81676@Space.Net> <225FF3C4-1DD5-4B62-8941-6760CE18E9A4@ripe.net> <20131114142849.GJ81676@Space.Net> Message-ID: <528F322C.20303@ripe.net> Hello, > But anyway. My wishes have been stated a few times now, do what you > want with it. Since this thread is also about quotes: "There's no problem in Computer Science that can't be solved by adding another level of indirection to it" I propose a middle ground here (between "UDMs are immutable" and "I need a stable ID anyway") -- labels. The user specifying a UDM would be able to attach one (ore more?) labels to it, like "Ping to Gert's network". Then this label can be used in access functions, like data downloads, where instead of an ID, you ask for the label; the result is a union of all the measurements with that label. In other words, a label is a kind of ID that stays the same across multiple measurements. Would this work for you? Regards, Robert From daniel.karrenberg at ripe.net Fri Nov 22 12:10:25 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 22 Nov 2013 12:10:25 +0100 Subject: [atlas] feature requests In-Reply-To: <528F322C.20303@ripe.net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <528393EE.4030604@restena.lu> <01DE17FB-38E6-4961-8A22-B3CE06EEEDDA@ripe.net> <20131113184926.GZ81676@Space.Net> <225FF3C4-1DD5-4B62-8941-6760CE18E9A4@ripe.net> <20131114142849.GJ81676@Space.Net> <528F322C.20303@ripe.net> Message-ID: On 22.11.2013, at 11:30 , Robert Kisteleki wrote: > Hello, > >> But anyway. My wishes have been stated a few times now, do what you >> want with it. > > Since this thread is also about quotes: "There's no problem in Computer > Science that can't be solved by adding another level of indirection to it" > > I propose a middle ground here (between "UDMs are immutable" and "I need a > stable ID anyway") -- labels. > > The user specifying a UDM would be able to attach one (ore more?) labels > to it, like "Ping to Gert's network". Then this label can be used in > access functions, like data downloads, where instead of an ID, you ask for > the label; the result is a union of all the measurements with that label. > In other words, a label is a kind of ID that stays the same across > multiple measurements. > > Would this work for you? > > Regards, > Robert What is needed from my point of view: - make it possible to define a new measurement copying any parameter that makes remote sense from an existing measurement - int API and GUI, API more important - allow filtering in the API based on 'owner' and 'description' This way one can create a series of related measurements and find them back by a common description tag. No new field is needed. Just make existing ones searchable in the API as they are in the GUI. What would be nice to have is a forward/backward link chain of these measurements, e.g. enumerate measurements based on this msmid enumerate measurements this msmid is based on. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gert at space.net Fri Nov 22 12:28:27 2013 From: gert at space.net (Gert Doering) Date: Fri, 22 Nov 2013 12:28:27 +0100 Subject: [atlas] feature requests In-Reply-To: <528F322C.20303@ripe.net> References: <527D197E.7050900@nic.at> <527D3AE6.2070201@restena.lu> <5280B655.4000207@ripe.net> <20131111111217.GT81676@Space.Net> <528393EE.4030604@restena.lu> <01DE17FB-38E6-4961-8A22-B3CE06EEEDDA@ripe.net> <20131113184926.GZ81676@Space.Net> <225FF3C4-1DD5-4B62-8941-6760CE18E9A4@ripe.net> <20131114142849.GJ81676@Space.Net> <528F322C.20303@ripe.net> Message-ID: <20131122112827.GQ81676@Space.Net> Hi, On Fri, Nov 22, 2013 at 11:30:04AM +0100, Robert Kisteleki wrote: > The user specifying a UDM would be able to attach one (ore more?) labels > to it, like "Ping to Gert's network". Then this label can be used in > access functions, like data downloads, where instead of an ID, you ask for > the label; the result is a union of all the measurements with that label. > In other words, a label is a kind of ID that stays the same across > multiple measurements. That would work for me, yes (I think it was mentioned in the thread already). To make it fully useful, it would need to go hand in hand with "take this UDM, clone it, change a few parameters, and keep the rest" to make modifying just single parameters easier than "remember everything and type it all in again" :-) 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 Fri Nov 22 12:32:05 2013 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 22 Nov 2013 12:32:05 +0100 Subject: [atlas] HTTP/HTTPS probe In-Reply-To: References: <524AE49C.4080005@netassist.ua> <524B0DF8.4000409@ripe.net> <20131002081343.GA31298@nic.fr> <524BDC8E.8080907@ripe.net> <20131002092137.Horde.vjUFJNi2YDSy8Gl2w01atw2@mail.kix.es> <20131121105249.448614a6@columbia> <20131121182305.62060.qmail@f5-external.bushwire.net> Message-ID: <528F40B5.1080707@ripe.net> On 2013.11.21. 20:41, Richard Barnes wrote: > I think HEAD would probably be OK. At least, I'm not aware of any exploits > that would enable. > > --Richard A completely different dimension of this is something that's (almost) unique to Atlas: you can use vantage points that are in others' networks or homes. Seemingly the request (whether it's GET or HEAD) will come from there. If one uses this to access illegal content (for whatever definition of illegal), then the host will be in trouble, and I don't think explanations about "it was not me, it was someone else" or "it was just a HEAD request, I didn't really see that picture" will make a difference in all cases. (We will likely be able to trace back the actual request to someone, but it may not help the host in question.) Maybe I'm a pessimist here, but if I'm not, then it means we can only use some kind of opt-in method, and even that does not solve the root problem. The alternative is to limit the potential destinations system-wide, which severely limits the usefulness of such measurements (or it boosts the Atlas Anchor deployment rate ;-) Robert From daniel.karrenberg at ripe.net Fri Nov 22 12:53:01 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 22 Nov 2013 12:53:01 +0100 Subject: [atlas] HTTP/HTTPS probe In-Reply-To: <528F40B5.1080707@ripe.net> References: <524AE49C.4080005@netassist.ua> <524B0DF8.4000409@ripe.net> <20131002081343.GA31298@nic.fr> <524BDC8E.8080907@ripe.net> <20131002092137.Horde.vjUFJNi2YDSy8Gl2w01atw2@mail.kix.es> <20131121105249.448614a6@columbia> <20131121182305.62060.qmail@f5-external.bushwire.net> <528F40B5.1080707@ripe.net> Message-ID: <545C7655-898A-4845-ADDC-68E23730381D@ripe.net> I suggest to start making HEAD requests to a limited set of destinations available to all users. Initially limit the list destinations under control of RIPE NCC, including anchors. I feel that this would not require an opt-in question to probe hosts, just information. As a next step we could then define a process for adding other destinations. This would prevent Atlas from becoming a general purpose tool for HTTP performance measurement and abuse. How's that to start with? Daniel On 22.11.2013, at 12:32 , Robert Kisteleki wrote: > On 2013.11.21. 20:41, Richard Barnes wrote: >> I think HEAD would probably be OK. At least, I'm not aware of any exploits >> that would enable. >> >> --Richard > > A completely different dimension of this is something that's (almost) unique > to Atlas: you can use vantage points that are in others' networks or homes. > Seemingly the request (whether it's GET or HEAD) will come from there. > > If one uses this to access illegal content (for whatever definition of > illegal), then the host will be in trouble, and I don't think explanations > about "it was not me, it was someone else" or "it was just a HEAD request, I > didn't really see that picture" will make a difference in all cases. (We > will likely be able to trace back the actual request to someone, but it may > not help the host in question.) > > Maybe I'm a pessimist here, but if I'm not, then it means we can only use > some kind of opt-in method, and even that does not solve the root problem. > > The alternative is to limit the potential destinations system-wide, which > severely limits the usefulness of such measurements (or it boosts the Atlas > Anchor deployment rate ;-) > > Robert > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From philip.homburg at ripe.net Fri Nov 22 16:11:34 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 22 Nov 2013 16:11:34 +0100 Subject: [atlas] Very short uptime for some probes In-Reply-To: <528DDADB.6050002@ripe.net> References: <20131120153236.56186.qmail@f5-external.bushwire.net> <528CDCA9.2020904@ripe.net> <20131120195014.57439.qmail@f5-external.bushwire.net> <528DDADB.6050002@ripe.net> Message-ID: <528F7426.7070006@ripe.net> On 2013/11/21 11:05 , Philip Homburg wrote: > Hi Mark, > > On 2013/11/20 20:50 , Mark Delany wrote: >> You probably know this Philip, but that made an instant >> difference. That probe is now reporting being up 100% since the >> switch. >> >> Just out of curiousity, do you have a theory on why switching >> controllers makes a difference? > > We have some ideas of what it might be. I'll look if I can find out what > is going on from our end. The cause was... incorrect MSS clamping (together with broken Linux Ethernet drivers). First a bit of background information. In a small fraction of the Internet, path MTU discovery does not work. Unfortunately, Linux does not have PMTU blackhole detection enabled by default. This causes some number of probes to fail, mostly probes that connect over IPv6. The failure mode is that the probes connect fine, but when they want to report results the probe hits the PMTU blackhole. The connection times out, the probe connects again and the same thing happens. Over and over again. One way out of this is to tell the probe host to fix the PMTU problem. But we cannot be sure that it PMTU and the probe host may not be able to fix the problem. An easy way around this problem is reducing the MSS: if the controller sends a smaller MSS to the probe then the PMTU blackhole can be avoided. A quick and dirty way to cause this lower MSS to be sent is to lower the MTU on the controller's interface. So after verifying that it works, we starting running the controllers with MTU 1400. Problem solved. Well, not quite. What 'mtu 1400' really does seems to depend on the Ethernet driver. In some cases the controller continues to receive packets up to the normal Ethernet MTU of 1500, it just does not send anything bigger than 1400. In this case, the trick works great. In other cases, and that includes the 'ctr-ams04' controller, the Ethernet driver considers everything above 1400 as a framing error and discards it. Normally, this does not cause any problems. Controllers almost exclusively use TCP connections and for TCP we have the MSS option to keep the packets smaller than the lowered MTU. Enter middleboxes. Middleboxes, like home routers have been doing MSS clamping for years. This way most users never notice PMTU problems. However in this case, MSS clamping causes the whole thing to fail. I got permission from Mark to run tcpdump on his probe, so I can show the packets sent by the controller and how they are received by his probe. This is what we see on the controller: 14:01:59.723671 IP probeXXXXXX.53447 > ctr-ams04.atlas.ripe.net.https: Flags [S], seq 1044848773, win 14600, options [mss 1452,sackOK,TS val 622493 ecr 0,nop,wscale 2], length 0 14:01:59.723696 IP ctr-ams04.atlas.ripe.net.https > probeXXXXX.53447: Flags [S.], seq 4267097689, ack 1044848774, win 13480, options [mss 1360,sackOK,TS val 1898121349 ecr 622493,nop,wscale 7], length 0 The controller receives an MSS of 1452 from the probe, which is a weird number because the probe is connected to Ethernet. So this suggests that MSS clamping is going on and that the probe is connecting over PPPoE. Then the controller responds with an MSS of 1360, which is the MTU of 1400 minus the IPv4 and TCP headers. At the probe however, it looks quite differently: 14:01:57.758623 IP probeXXXXX.53447 > ctr-ams04.atlas.ripe.net.https: Flags [S], seq 1044848773, win 14600, options [mss 1460,sackOK,TS val 622493 ecr 0,nop,wscale 2], length 0 14:01:58.129470 IP ctr-ams04.atlas.ripe.net.https > probeXXXXX.53447: Flags [S.], seq 4267097689, ack 1044848774, win 13480, options [mss 1452,sackOK,TS val 1898121349 ecr 622493,nop,wscale 7], length 0 So the probe actually sent 1460 as expected, but now the MSS of ctr-ams04 is suddenly raised to 1452! The net result is that the probe starts sending packets bigger than 1400, which gets dropped by the Ethernet driver on ctr-ams04 and we effectively have a PMTU blackhole. To make sure I assign blame to the right party (after all, the NCC also has firewalls, etc) I also captured the same exchange for a probe at my home: First on ctr-ams04: 15:08:10.852178 IP probeYYYYY.52323 > ctr-ams04.atlas.ripe.net.https: Flags [S], seq 2626247187, win 14600, options [mss 1460,sackOK,TS val 61346 ecr 0,nop,wscale 2], length 0 15:08:10.852203 IP ctr-ams04.atlas.ripe.net.https > probeYYYYY.52323: Flags [S.], seq 1208489868, ack 2626247188, win 13480, options [mss 1360,sackOK,TS val 1902092478 ecr 61346,nop,wscale 7], length 0 And then on the probe: 15:08:09.021948 IP probeYYYYY.52323 > ctr-ams04.atlas.ripe.net.https: Flags [S], seq 2626247187, win 14600, options [mss 1460,sackOK,TS val 61346 ecr 0,nop,wscale 2], length 0 15:08:09.039768 IP ctr-ams04.atlas.ripe.net.https > probeYYYYY.52323: Flags [S.], seq 1208489868, ack 2626247188, win 13480, options [mss 1360,sackOK,TS val 1902092478 ecr 61346,nop,wscale 7], length 0 Finally, it came as a surprise to me that the probe connected just fine when I sent it to our test controller, which is ctr-ams01. Ctr-ams01 is in the same network as ctr-ams04 so I was quite surprised that it made a difference. It turns out that ctr-ams01 is a virtual machine and the driver for VMware does not have a problem with packet bigger than 1400. Philip From daniel.karrenberg at ripe.net Fri Nov 22 17:31:02 2013 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 22 Nov 2013 17:31:02 +0100 Subject: [atlas] Very short uptime for some probes In-Reply-To: <528F7426.7070006@ripe.net> References: <20131120153236.56186.qmail@f5-external.bushwire.net> <528CDCA9.2020904@ripe.net> <20131120195014.57439.qmail@f5-external.bushwire.net> <528DDADB.6050002@ripe.net> <528F7426.7070006@ripe.net> Message-ID: <051D1369-4709-4503-8D36-37FE10E8913F@ripe.net> Never a boring moment in network computing :-( Kudos for figuring it out. Daniel On 22.11.2013, at 16:11 , Philip Homburg wrote: > > The cause was... incorrect MSS clamping (together with broken Linux > Ethernet drivers). ... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: Message signed with OpenPGP using GPGMail URL: From philip.homburg at ripe.net Fri Nov 22 17:39:56 2013 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 22 Nov 2013 17:39:56 +0100 Subject: [atlas] Very short uptime for some probes In-Reply-To: <051D1369-4709-4503-8D36-37FE10E8913F@ripe.net> References: <20131120153236.56186.qmail@f5-external.bushwire.net> <528CDCA9.2020904@ripe.net> <20131120195014.57439.qmail@f5-external.bushwire.net> <528DDADB.6050002@ripe.net> <528F7426.7070006@ripe.net> <051D1369-4709-4503-8D36-37FE10E8913F@ripe.net> Message-ID: <528F88DC.5000607@ripe.net> On 2013/11/22 17:31 , Daniel Karrenberg wrote: > Never a boring moment in network computing :-( > > Kudos for figuring it out. I had help from Robert, Colin, and our whiteboard. That triggers the question of whether we should add detection mechanisms for (broken) middleboxes to Atlas... Philip From f4w at echo.emu.st Fri Nov 22 18:15:34 2013 From: f4w at echo.emu.st (Mark Delany) Date: 22 Nov 2013 17:15:34 +0000 Subject: [atlas] HTTP/HTTPS probe In-Reply-To: <528F40B5.1080707@ripe.net> References: <20131002081343.GA31298@nic.fr> <524BDC8E.8080907@ripe.net> <20131002092137.Horde.vjUFJNi2YDSy8Gl2w01atw2@mail.kix.es> <20131121105249.448614a6@columbia> <20131121182305.62060.qmail@f5-external.bushwire.net> <528F40B5.1080707@ripe.net> Message-ID: <20131122171534.66140.qmail@f5-external.bushwire.net> > about "it was not me, it was someone else" or "it was just a HEAD request, I > didn't really see that picture" will make a difference in all cases. (We > will likely be able to trace back the actual request to someone, but it may > not help the host in question.) That's why I suggested "OPTIONS" or "TRACE". There is no real content exchanged in either of those two verbs. Well, I guess a truly subverted HTTP server could send content with any verb, but equally you can run a content server over DNS if you try hard enough... I don't think it matters that many web servers don't implement those VERBs as the exchange from a TCP perspective is identical to a GET or HEAD in either case. The only difference is that the content may be an options list or a 400 response. Not something a TCP stack cares about. That is not to ignore the concern you raised. I agree that it's very real. But it's a question of degree as the risk already exists. If someone was trawling thru my ISPs dnscache logs and saw queries to unsavoury host names referred to by UDMs, that could similarly be embarrassing. Or worse, raise an alert with the local authorities if the host names in question contains words on a government proscribed list - as exist in some countries already. So if TCP measurements were to be allowed - then HTTP OPTIONS in cleartext is almost as innocuous as a DNS query over TCP which is almost as innocuous as a DNS query over UDP. It's also pretty innocuous from the receivers perspective too. Seeing an occasional OPTIONS request in an HTTP log is pretty mild compared to all the other cruft sent by spiders and bots. On my personal web server I see about 1 real request for every 30-40 spider/bot requests. The anomaly for me is a real person looking at my site :-) Mark. From alexsaroyan at gmail.com Mon Nov 25 15:51:21 2013 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Mon, 25 Nov 2013 18:51:21 +0400 Subject: [atlas] RTT Graphs for UDMs Message-ID: <529363E9.3070603@gmail.com> Hi, As far as I understand there is no RTT history/graph for UDMs. I think it could be very usefull to have a graph storing maybe 1-6 month history of RTT for UDMs. I would really appreciate to have such a history of certain RTT values and the look for correlation with operational changes. -- Regards. /Alex Saroyan From the.lists at mgm51.com Mon Nov 25 16:43:19 2013 From: the.lists at mgm51.com (Mike.) Date: Mon, 25 Nov 2013 10:43:19 -0500 Subject: [atlas] feature requests Message-ID: <201311251043190986.004A2A5B@smtp.24cl.home> Philip Homburg Fri Nov 22 11:08:39 CET 2013 > >Hi, > >>On 2013/11/11 19:32 , Mike. wrote: >> Allow me to disable the processing of RA's on IPv6, so that I >> can configure IPv6 statically and not have it overwritten by an >> RA. > >This feature has been requested by a handful of people. However, this >introduces more complexity in the already way too complex network >configuration of the probes. So we like to avoid implementing this >feature. Of course if there is wide spread demand for it, then we will >look into it. > >I should try it sometime, but in theory one way to give the static >address priority is to set all prefixes in the RA to deprecated. On a >'normal' network where you one prefix, it should not make a difference >for any of the other hosts. > >Philip Hi Philip, In the context of ~~I don't know what is going on inside the Atlas probe, so I'll presume an easy solution~~ ... WOuldn't a solution be to just disable the rtsol daemon when static IPv6 addresses are configured? If the probe does not issue a router solicitation request, then it won't receive RA's. Seems to me that somewhere there is a rtsol=enable that could be changed to rtsol-disable and that would resolve the issue. Configuration would still need to be done via IPv4 using DHCP in this instance. But that process is already well documented. As always, thanks for listening. Mike. From BECHA at ripe.net Wed Nov 27 17:35:24 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 27 Nov 2013 17:35:24 +0100 Subject: [atlas] New on RIPE Labs: Map a RIPE Atlas Anchor In-Reply-To: <5295E939.7010804@ripe.net> References: <5295E939.7010804@ripe.net> Message-ID: <52961F4C.5050907@ripe.net> Dear colleagues, Please find a new article, contributed by Daniel Karrenberg, on RIPE Labs: RIPE Atlas Fun - Map a RIPE Atlas Anchor. https://labs.ripe.net/Members/dfk/map-a-ripe-atlas-anchor It shows some interesting graphs based on RIPE Atlas traceroute measurements. Kind regards, Mirjam Kuehne RIPE NCC From BECHA at ripe.net Thu Nov 28 15:06:16 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 28 Nov 2013 15:06:16 +0100 Subject: [atlas] First RIPE Atlas anchor since production service now active Message-ID: <52974DD8.4010308@ripe.net> Dear RIPE Atlas users, We are proud to announce that the first RIPE Atlas anchor since this new service went into full production came online yesterday! It is situated in Munich, Germany, and is operated by Space.net. Congratulations on being the first one! Our thanks go to Gert Doering, who put in a lot of effort working alongside the RIPE NCC team through the new procedure, as well as to five other new hosts whose anchors will be activated tomorrow. From now on, we will announce each new anchor as it is activated, together with the anchoring measurements towards them. All RIPE Atlas anchors can be seen on this list and map: https://atlas.ripe.net/anchors/list/ https://atlas.ripe.net/anchors/map/ Kind regards, Vesna Manojlovic Measurements Community Building RIPE NCC From BECHA at ripe.net Thu Nov 28 17:41:07 2013 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 28 Nov 2013 17:41:07 +0100 Subject: [atlas] Space.net (DE) has joined RIPE Atlas anchors Message-ID: <52977223.4040403@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network. The new anchor is called de-muc-as5539 and is operated by Space.net in Munchen, Germany. 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 From mgalante at ripe.net Fri Nov 29 17:51:08 2013 From: mgalante at ripe.net (Michela Galante) Date: Fri, 29 Nov 2013 17:51:08 +0100 Subject: [atlas] Six new RIPE Atlas anchors are now active Message-ID: Dear RIPE Atlas users, We're happy to announce that six more RIPE Atlas anchors have joined the network: us-pao-as5580 is operated by Atrato Networks in Palo Alto, United States us-ewr-as5580 is operated by Atrato Networks in New York, United States de-fra-as5580 is operated by Atrato Networks in Frankfurt, Germany nl-dft-as31019 is operated by Meanie in Delft, Netherlands fr-sxb-as8839 is operated by SdV Plurimedia in Strasbourg, France nl-ams-as3333-2 is operated by RIPE NCC in Amsterdam, Netherlands Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards these anchors from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ We would like to thank Job, Paul and Salim who put in a lot of effort to become the first anchor hosts! 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 gert at space.net Fri Nov 29 18:09:44 2013 From: gert at space.net (Gert Doering) Date: Fri, 29 Nov 2013 18:09:44 +0100 Subject: [atlas] Six new RIPE Atlas anchors are now active In-Reply-To: References: Message-ID: <20131129170944.GX81676@Space.Net> Hi, 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*!!! Gert, running fast and hiding for the weekend -- 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: smime.p7s Type: application/x-pkcs7-signature Size: 5023 bytes Desc: not available URL: From job.snijders at hibernianetworks.com Fri Nov 29 18:58:32 2013 From: job.snijders at hibernianetworks.com (Job Snijders) Date: Fri, 29 Nov 2013 18:58:32 +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: <20131129175832.GF479@Eleanor.local> On Fri, Nov 29, 2013 at 06:09:44PM +0100, Gert Doering wrote: > Hi, > > 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*!!! > > Gert, I might be second, but at least I got more :P Kind regards, Job -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 873 bytes Desc: not available URL: From gert at space.net Fri Nov 29 19:11:27 2013 From: gert at space.net (Gert Doering) Date: Fri, 29 Nov 2013 19:11:27 +0100 Subject: [atlas] Six new RIPE Atlas anchors are now active In-Reply-To: <20131129175832.GF479@Eleanor.local> References: <20131129170944.GX81676@Space.Net> <20131129175832.GF479@Eleanor.local> Message-ID: <20131129181127.GA81676@Space.Net> Hi, On Fri, Nov 29, 2013 at 06:58:32PM +0100, Job Snijders wrote: > On Fri, Nov 29, 2013 at 06:09:44PM +0100, Gert Doering wrote: > > Hi, > > > > 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*!!! > > I might be second, but at least I got more :P Indeed. And on more continents as well :-( *pout* 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: