From maildanrl at googlemail.com Fri May 4 17:39:51 2012 From: maildanrl at googlemail.com (Dan Luedtke) Date: Fri, 4 May 2012 17:39:51 +0200 Subject: [atlas] Sharing Stats? Message-ID: Hello everyone, what are your opinions on sharing stats from a probe to the public? My idea: I have a public probe and public UDMs running, and I would like to embed the "last 8 hours" graphs into a website where people can see it, even those that do not have access to RIPE Atlas. Do you think it is a good idea to ask for a feature that splits the "Public" checkbox into two ones saying "Public (ATLAS Community)" and "Public (Internet)"? best regards, Dan -- Dan Luedtke http://www.danrl.de From rbarnes at bbn.com Fri May 4 20:15:28 2012 From: rbarnes at bbn.com (Richard L. Barnes) Date: Fri, 4 May 2012 14:15:28 -0400 Subject: [atlas] Sharing Stats? In-Reply-To: References: Message-ID: <1EBD9F60-EA8F-4C2A-8126-E255B5F9AD81@bbn.com> Seems like a good idea to me! On May 4, 2012, at 11:39 AM, Dan Luedtke wrote: > Hello everyone, > > what are your opinions on sharing stats from a probe to the public? > > My idea: I have a public probe and public UDMs running, and I would > like to embed the "last 8 hours" graphs into a website where people > can see it, even those that do not have access to RIPE Atlas. Do you > think it is a good idea to ask for a feature that splits the "Public" > checkbox into two ones saying "Public (ATLAS Community)" and "Public > (Internet)"? > > best regards, > Dan > > -- > Dan Luedtke > http://www.danrl.de > From inigo at infornografia.net Fri May 4 21:20:22 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Fri, 4 May 2012 21:20:22 +0200 Subject: [atlas] Sharing Stats? In-Reply-To: <1EBD9F60-EA8F-4C2A-8126-E255B5F9AD81@bbn.com> References: <1EBD9F60-EA8F-4C2A-8126-E255B5F9AD81@bbn.com> Message-ID: On Fri, May 4, 2012 at 8:15 PM, Richard L. Barnes wrote: > Seems like a good idea to me! > > > +1 Besides, it is along the lines of the idea behind the RIPEStat widgets > On May 4, 2012, at 11:39 AM, Dan Luedtke wrote: > > > Hello everyone, > > > > what are your opinions on sharing stats from a probe to the public? > > > > My idea: I have a public probe and public UDMs running, and I would > > like to embed the "last 8 hours" graphs into a website where people > > can see it, even those that do not have access to RIPE Atlas. Do you > > think it is a good idea to ask for a feature that splits the "Public" > > checkbox into two ones saying "Public (ATLAS Community)" and "Public > > (Internet)"? > > > > best regards, > > Dan > > > > -- > > Dan Luedtke > > http://www.danrl.de > > > > > -- - As? que este es el futuro del hombre: calentarse a los rayos del sol, ba?arse en las claras corrientes de agua, y comer los frutos de la tierra olvidando todo trabajo y fatiga. - Bueno, y por qu? no? "El tiempo en sus manos" -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerome.benoit at grenouille.com Fri May 4 23:17:32 2012 From: jerome.benoit at grenouille.com (=?ISO-8859-1?B?Suly9G1l?= Benoit) Date: Fri, 4 May 2012 23:17:32 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <4F9A7E73.2040604@sidn.nl> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> <4F9A7E73.2040604@sidn.nl> Message-ID: <20120504231732.007ad2cd@nemesis.grenouille.com> On Fri, 27 Apr 2012 13:09:39 +0200 "Marco Davids (SIDN)" wrote: > As SamKnows been mentioned here? There's quite some resemblance > between SamKnows and Atlas, and changes for synergy as well. Yes, there are both a closed-source with a secret roadmap project for no good reasons that force similar project that prefer FOSS licences and development model to re-implement software that perform active and passive measurement primitive in the FOSS fashion and hopefully with a better thought architecture to cope with a wide range of needs and large scale campaign coordination runt on end-users "computers" :) Cheers. -- J?r?me Benoit aka fraggle La M?t?o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From fred at cisco.com Sat May 5 01:47:28 2012 From: fred at cisco.com (Fred Baker) Date: Fri, 4 May 2012 16:47:28 -0700 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> Message-ID: Well, a suggestion. Suppose that every time a probe does its test, it also reads from RIPE that tells it the address of the target to probe next. This would allow RIPE (passing along your instructions, or executing its own) that could implement any of a variety of scenarios, and change them from time to time. On Apr 27, 2012, at 3:20 AM, Alexander Mayrhofer wrote: > Hello, > > i'm figuring how RIPE atlas could be most useful for assisting in monitoring our Ancast Network, and came up with the following idea: > > The Atlas network has a big advantage over other monitoring /measurement networks, which is obviously its sheer size (and topological diversity). Rather than using the Atlas network for pure performance measurements, i would love to be able to use Atlas for reachability measurements (and understand which Anycast location attracts traffic from which region, and how this changes over time). These reachability / topology discovery measurements do not need to be nearly as frequent as the performance measurements, but should utilize all available probes. > > So, instead of being able to use 10 probes to run a continous performance test (say, DNS query every 300 seconds), i would rather like to be able to use a very high number of probes (best case: "all"), but have each of the probe eg. perform just one traceroute per day (or, even once per week would be enough). This would give me an excellent overview about the topology, but is not possible using the current limits of the UDMs. > > However, instead of allowing users to allocate measurements to a much higher number of probes, this functionality would also be possible be adding some "probe round-robin" feature to the control infrastructure, for example "randomly allocate a new set of probes every xx seconds". > > If that feature would exist, i could implement the above reachability test with the following parameters: > > Test: traceroute > Number of probes: 10 > Measurement interval: 3600 > Swap probe-set interval: 10800 (NEW feature) > > (which would re-allocate new probes every 3 hours, theoretically working through all 1500 probes about every month?). An obvious alternative would be functionality where i could "queue" "single-shot" measurements for the whole network (since chances are low i would get every probe if they are randomly assigned). > > comments? Suggestions? Alternatives? > > Alex Mayrhofer > Head of R&D nic.at > From me at anuragbhatia.com Sat May 5 05:48:10 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sat, 5 May 2012 09:18:10 +0530 Subject: [atlas] Sharing Stats? In-Reply-To: References: Message-ID: +1 Nice idea Dan. I too agree. Public profile on probeID.Atlas.ripe.net will be something very cool and will enable us to pass link in emails as reference. Last time I had to pass info about F root sever data, I hid to literally save graph as image externally and then attach with mail. There can be lot better solution for Public probes. (Sent from my mobile device) Anurag Bhatia http://anuragbhatia.com On May 4, 2012 9:18 PM, "Dan Luedtke" wrote: > Hello everyone, > > what are your opinions on sharing stats from a probe to the public? > > My idea: I have a public probe and public UDMs running, and I would > like to embed the "last 8 hours" graphs into a website where people > can see it, even those that do not have access to RIPE Atlas. Do you > think it is a good idea to ask for a feature that splits the "Public" > checkbox into two ones saying "Public (ATLAS Community)" and "Public > (Internet)"? > > best regards, > Dan > > -- > Dan Luedtke > http://www.danrl.de > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maildanrl at googlemail.com Sat May 5 09:20:34 2012 From: maildanrl at googlemail.com (Dan Luedtke) Date: Sat, 5 May 2012 09:20:34 +0200 Subject: [atlas] Sharing Stats? In-Reply-To: References: Message-ID: On Sat, May 5, 2012 at 5:48 AM, Anurag Bhatia wrote: > Public profile on probeID.Atlas.ripe.net will be something very cool and > will enable us to pass link in emails as reference I would like to suggest -stats.atlas.ripe.net and -stats.atlas.ripe.net, UDMs are a real extra value and their stats are at least as interesting as the probe's stats. I totally agree on the "passing links in mails" stuff, that really is a problem at the moment. Nevertheless, the project hast achieved a lot, thanks for that btw! regards, Dan -- Dan Luedtke http://www.danrl.de From philip.homburg at ripe.net Sat May 5 11:58:11 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Sat, 05 May 2012 11:58:11 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> Message-ID: <4FA4F9B3.7030607@ripe.net> On 5/5/12 1:47 , Fred Baker wrote: > Well, a suggestion. > > Suppose that every time a probe does its test, it also reads from RIPE that tells it the address of the target to probe next. This would allow RIPE (passing along your instructions, or executing its own) that could implement any of a variety of scenarios, and change them from time to time. > > That is already there. Probes are under full control of the Atlas infrastructure. The problem is more that the Atlas backend is very complex distributed system. So it takes time before the necessary datastructures and database tables are in place to really express the concept of looping over all probe. From philip.homburg at ripe.net Sat May 5 12:22:15 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Sat, 05 May 2012 12:22:15 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <20120504231732.007ad2cd@nemesis.grenouille.com> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> <4F9A7E73.2040604@sidn.nl> <20120504231732.007ad2cd@nemesis.grenouille.com> Message-ID: <4FA4FF57.7050104@ripe.net> On 5/4/12 23:17 , J?r?me Benoit wrote: > On Fri, 27 Apr 2012 13:09:39 +0200 > "Marco Davids (SIDN)" wrote: > >> As SamKnows been mentioned here? There's quite some resemblance >> between SamKnows and Atlas, and changes for synergy as well. > Yes, there are both a closed-source with a secret roadmap project for > no good reasons that force similar project that prefer FOSS licences > and development model to re-implement software that perform active and > passive measurement primitive in the FOSS fashion and hopefully > with a better thought architecture to cope with a wide range of needs > and large scale campaign coordination runt on end-users "computers" :) > > I don't know about SamKnows, but for RIPE Atlas, talks contain a lot of details about how the system works. To the extent that there is a well defined road map, we talk about it. As much as I like open source projects, I really don't see it working for the current Atlas system. Probe are just too fragile, the whole system is too complex. Does releasing the Atlas source benefit the RIPE community? I don't know. Fortunately, that is not my decision to make. There is not a lot of magic in Atlas. It is mostly just hard work to get all the details right. If you have a dedicated team in an open source project, then you should be able to duplicate our work. You can always for feedback on any design, or ask how we do things. One word of warning though: try avoid the second system effect. If your system is going to do everything it may never get there. From davidp at preshweb.co.uk Sat May 5 14:23:58 2012 From: davidp at preshweb.co.uk (David Precious) Date: Sat, 5 May 2012 13:23:58 +0100 Subject: [atlas] Sharing Stats? In-Reply-To: References: Message-ID: <20120505132358.35d8fa31@columbia> On Fri, 4 May 2012 17:39:51 +0200 Dan Luedtke wrote: > Hello everyone, > > what are your opinions on sharing stats from a probe to the public? > > My idea: I have a public probe and public UDMs running, and I would > like to embed the "last 8 hours" graphs into a website where people > can see it, even those that do not have access to RIPE Atlas. Do you > think it is a good idea to ask for a feature that splits the "Public" > checkbox into two ones saying "Public (ATLAS Community)" and "Public > (Internet)"? The only potential problem I see is if people embed those graph images on popular websites, the Atlas project will need to serve a lot of requests from the public - probably not a big issue, but would need to be considered. In the meantime, I imagine you could whip up a script to periodically screen-scrape the Atlas interface to grab a copy of the graph you want to share with the world and cache it on your server; whether that would be considered OK by RIPE, I don't know, but I see no real reason it shouldn't. -- David Precious ("bigpresh") http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github From jerome.benoit at grenouille.com Sat May 5 16:43:43 2012 From: jerome.benoit at grenouille.com (=?ISO-8859-1?B?Suly9G1l?= Benoit) Date: Sat, 5 May 2012 16:43:43 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <4FA4FF57.7050104@ripe.net> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> <4F9A7E73.2040604@sidn.nl> <20120504231732.007ad2cd@nemesis.grenouille.com> <4FA4FF57.7050104@ripe.net> Message-ID: <20120505164343.3b3e2fc4@nemesis.grenouille.com> On Sat, 05 May 2012 12:22:15 +0200 Philip Homburg wrote: > On 5/4/12 23:17 , J?r?me Benoit wrote: > > On Fri, 27 Apr 2012 13:09:39 +0200 > > "Marco Davids (SIDN)" wrote: > > > >> As SamKnows been mentioned here? There's quite some resemblance > >> between SamKnows and Atlas, and changes for synergy as well. > > Yes, there are both a closed-source with a secret roadmap project > > for no good reasons that force similar project that prefer FOSS > > licences and development model to re-implement software that > > perform active and passive measurement primitive in the FOSS > > fashion and hopefully with a better thought architecture to cope > > with a wide range of needs and large scale campaign coordination > > runt on end-users "computers" :) > > > > > I don't know about SamKnows, but for RIPE Atlas, talks contain a lot > of details about how the system works. To the extent that there is a > well defined road map, we talk about it. I'm having hard time to find the roadmap and the talks on the RIPE Atlas web site as a public user with no account. But I might have not searched enough. Where are they ? > As much as I like open source projects, I really don't see it working > for the current Atlas system. It work very well, we do it since age but we took a very different approach : The measurement agent is designed as a standalone component with that requirement : * Must be portable, that mean all measurements must be implemented natively. * Datagram-based measurement are divided in four components - packets forge - packets injection - packets capture - packets filter Each component work is mapped to a dedicated thread (an Lwt job more precisely, which bring in a very nice way to manipulate packets in a asynchronous fashion). * Other measurement can be mapped with a plugin dynamically loaded (the API is not stable yet) * A syntax (that is not yet finished) permit to express what a measurement will do. The syntax is thought as a way to express what the software functionalities are and how each component interact with each other. I give a working example just to show the idea : {"probe": // the probe module that will be dynamically loaded {"name":["delay","round_trip","icmp","bin"] // send and receive sample definition, the time // sequence that the measurement will follow while running ,"send": {"seq": // repeat 3 times each 30 min, other keyword are // gamma, uniform, poisson, seq can recurse // under conditions {"repeat": {"count":3 ,"seq":{"periodic":{"period":1800.0}} } } } ,"recv": {"seq": {"repeat": // repeat 2 times each 3 seconds the // the sample measurement {"count":2 ,"seq":{"periodic":{"period":3.0}} } } } ,"parallel": [ // measurement module specific configuration, // here destination and ICMP type 8 packet size {"mark":null ,"data": {"host":"free.fr" ,"size":16 } } ,{"mark":null ,"data": {"host":"google.fr" ,"size":16 } } ] } // where to send the sample result (file, stdout, URI REStful API) ,"sample": {"file":"-" } } I do not have enough time to describe the whole design in one mail but the goal is to permit measurement end to end from the network edge with user participation on end user "computers" or dedicated hardware, coordinate them and compute analysis on measurement results. > Probe are just too fragile, the whole > system is too complex. ? I fail to understand this argument. Every single piece of software is a complex system, that has never ever be an argument to not opensource it. And for the fragility, probably a design issue of the probe (but I can't known for sure, no source code to review). > Does releasing the Atlas source benefit the > RIPE community? I don't know. Fortunately, that is not my decision to > make. RIPE call. I think RIPE have made a mistake by not going opensource since the beginning. > There is not a lot of magic in Atlas. It is mostly just hard work to > get all the details right. We're working hard and we have the details very right, one piece after an other, the measurement agent first :) For example, the difference between wire time timestamp vs the system time timestamp and timestamping error calibration on the datagram based measurement. > If you have a dedicated team in an open > source project, then you should be able to duplicate our work. You > can always for feedback on any design, or ask how we do things. I do not know the list of active measurements an Atlas probe cover. > > One word of warning though: try avoid the second system effect. If > your system is going to do everything it may never get there. > It's a revamp of an old system that will not be disconnect from your first user base until your user base will have not understood what you're trying to achieve and the migration plan is complete. The release cycle will be thought to cope with scalability issue (we have a huge user base). Don't worry, we know what we are doing, we're not a young project, just like your current running system we're redoing :) -- J?r?me Benoit aka fraggle La M?t?o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From maildanrl at googlemail.com Mon May 7 12:47:09 2012 From: maildanrl at googlemail.com (Dan Luedtke) Date: Mon, 7 May 2012 12:47:09 +0200 Subject: [atlas] Sharing Stats? In-Reply-To: <20120505132358.35d8fa31@columbia> References: <20120505132358.35d8fa31@columbia> Message-ID: What do the RIPE people think? Do we have a chance to get that idea on the roadmap? -- Dan Luedtke http://www.danrl.de From BECHA at ripe.net Mon May 7 14:05:10 2012 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 07 May 2012 14:05:10 +0200 Subject: [atlas] Sharing Stats? In-Reply-To: References: <20120505132358.35d8fa31@columbia> Message-ID: <4FA7BA76.6030908@ripe.net> Dear Dan, all, On 5/7/12 12:47 PM, Dan Luedtke wrote: > What do the RIPE people think? Thank you for your interest & your suggestion - good idea! Also thanks to all the rest of you, who supported Dan's suggestion & clariefied how would you wanted it implemented... > Do we have a chance to get that idea on the roadmap? Yes, we've heard you, and added it to the list of wanted features. However, it will have to wait till after 6th June (World IPv6 Launch Day), since until then we are busy implementing specific measurements and features that are IPv6-related. Regards, Vesna From philip.homburg at ripe.net Mon May 7 14:15:26 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 07 May 2012 14:15:26 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <20120505164343.3b3e2fc4@nemesis.grenouille.com> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> <4F9A7E73.2040604@sidn.nl> <20120504231732.007ad2cd@nemesis.grenouille.com> <4FA4FF57.7050104@ripe.net> <20120505164343.3b3e2fc4@nemesis.grenouille.com> Message-ID: <4FA7BCDE.1060905@ripe.net> On 5/5/12 16:43 , J?r?me Benoit wrote: > On Sat, 05 May 2012 12:22:15 +0200 > Philip Homburg wrote: > >> I don't know about SamKnows, but for RIPE Atlas, talks contain a lot >> of details about how the system works. To the extent that there is a >> well defined road map, we talk about it. > I'm having hard time to find the roadmap and the talks on the RIPE Atlas > web site as a public user with no account. But I might have not > searched enough. Where are they ? > There is not a single comprehensive road map. What is there, is just bits and pieces. Most of it was discussed during the most recent RIPE meeting. The talks by Robert and Daniel should be online. To list some things that have been mentioned: * TTM shutdown, Atlas is expected to provide functionality similar (but not identical) to what TTM provides * DNSMON gets moved to Atlas * Roll out of Atlas Anchor boxes (regular PCs at well connected locations that can serve as the target of measurements and as a more powerful Atlas probe) * Measurements for IPv6 launch * Better UDM interface * UDM for all RIPE members (instead of just probe hosts and sponsors) >> As much as I like open source projects, I really don't see it working >> for the current Atlas system. > It work very well, we do it since age but we took a very different > approach : > > The measurement agent is designed as a standalone component with that > requirement : > > * Must be portable, that mean all measurements must be implemented > natively. > * Datagram-based measurement are divided in four components > - packets forge > - packets injection > - packets capture > - packets filter > Each component work is mapped to a dedicated thread (an Lwt job more > precisely, which bring in a very nice way to manipulate packets in a > asynchronous fashion). Note that for Atlas, it has to work on an underpowered CPU without MMU and with 8 MB of memory. > * Other measurement can be mapped with a plugin dynamically loaded (the > API is not stable yet) > * A syntax (that is not yet finished) permit to express what a > measurement will do. The syntax is thought as a way to express > what the software functionalities are and how each component > interact with each other. I give a working example just to show > the idea : However, I think this would be a great area the community can work on. Plenty of people has expressed interest in something more general than what is currently implemented in Atlas. So if people can come up with a design that is both secure and can work on 8 MB probes, then maybe that can be used to create a common interface to the different measurement platforms. >> Probe are just too fragile, the whole >> system is too complex. > ? > > I fail to understand this argument. > Every single piece of software is a complex system, that has never ever > be an argument to not opensource it. > And for the fragility, probably a design issue of the probe (but I > can't known for sure, no source code to review). Running an open source project is not a goal of the RIPE NCC. If that's supposed to be a goal then the members will have to ask for it through the appropriate channels. >> Does releasing the Atlas source benefit the >> RIPE community? I don't know. Fortunately, that is not my decision to >> make. > RIPE call. I think RIPE have made a mistake by not going opensource > since the beginning. I guess opinions differ there. > >> If you have a dedicated team in an open >> source project, then you should be able to duplicate our work. You >> can always for feedback on any design, or ask how we do things. > I do not know the list of active measurements an Atlas probe cover. > At the moment, ping, traceroute, tdig (dns), httpget, sslgetcert. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maildanrl at googlemail.com Mon May 7 19:10:50 2012 From: maildanrl at googlemail.com (Dan Luedtke) Date: Mon, 7 May 2012 19:10:50 +0200 Subject: [atlas] Sharing Stats? In-Reply-To: <4FA7BA76.6030908@ripe.net> References: <20120505132358.35d8fa31@columbia> <4FA7BA76.6030908@ripe.net> Message-ID: Hello, On Mon, May 7, 2012 at 2:05 PM, Vesna Manojlovic wrote: > Yes, we've heard you, and added it to the list of wanted features. Thanks a lot! Drop me a mail if I can be of any help, e.g. beta-testing. regards, Dan -- Dan Luedtke http://www.danrl.de From jerome.benoit at grenouille.com Mon May 7 21:44:23 2012 From: jerome.benoit at grenouille.com (=?ISO-8859-1?B?Suly9G1l?= Benoit) Date: Mon, 7 May 2012 21:44:23 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <4FA7BCDE.1060905@ripe.net> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> <4F9A7E73.2040604@sidn.nl> <20120504231732.007ad2cd@nemesis.grenouille.com> <4FA4FF57.7050104@ripe.net> <20120505164343.3b3e2fc4@nemesis.grenouille.com> <4FA7BCDE.1060905@ripe.net> Message-ID: <20120507214423.5b08f0f3@nemesis.grenouille.com> On Mon, 07 May 2012 14:15:26 +0200 Philip Homburg wrote: > > I'm having hard time to find the roadmap and the talks on the RIPE > > Atlas web site as a public user with no account. But I might have > > not searched enough. Where are they ? > > > There is not a single comprehensive road map. What is there, is just > bits and pieces. Most of it was discussed during the most recent RIPE > meeting. The talks by Robert and Daniel should be online. > > To list some things that have been mentioned: > > * TTM shutdown, Atlas is expected to provide functionality similar > (but not identical) to what TTM provides You plan to change the measurement control protocol used in TTM ? I do not know which protocol TTM is using but if it's OWAMP ou TWAMP, that will not fit the needs for large scale measurement campaign runt from network edge. > * DNSMON gets moved to Atlas In what Atlas call a "probe" (and what I call the measurement agent) ? > * Roll out of Atlas Anchor boxes (regular PCs at well connected > locations that can serve as the target of measurements and as a > more powerful Atlas probe) Sound like a good idea :) You then should add a tag to the measurement result that will permit to distinguish the type of box running the measurement agent, like "generated": atlas-probe "generated": atlas-box for example. > * Better UDM interface > * UDM for all RIPE members (instead of just probe hosts and > sponsors) Eye candies. > > * A syntax (that is not yet finished) permit to express what a > > measurement will do. The syntax is thought as a way to express > > what the software functionalities are and how each component > > interact with each other. I give a working example just to show > > the idea : > > However, I think this would be a great area the community can work > on. Plenty of people has expressed interest in something more general > than what is currently implemented in Atlas. > > So if people can come up with a design that is both secure and can > work on 8 MB probes, then maybe that can be used to create a common > interface to the different measurement platforms. If you have any document describing the JSON syntax used in Atlas, I can write the code for your measurement agent that will de-/serialize the probe definition to begin with. If you have the same for the REST API, the implentation be done also. grenouille_config (the component that permit to read the probe definition) is modular and pluggable; just like grenouille_sample (the component that send the result). The 8MB limit will be the hard part, since your agent is written is OCaml, it will mainly ? matter of tuning the GC and profiling the data structure defined to avoid large allocation of chunk. We do not have securities problem because of OCaml choice on the implementation side. Securities mechanism will probably be the same as of the one you can find on most "web services" (shared secret salted and hashed) to ensure that a REST transaction is legit. I have to think about it some more ... For API and JSON syntax standardisation, the first step is to write the specifications we(grenouille.com) plan to use and Atlas use and plan to use, then discuss and factor out the best of each. We have some writings but most of them are in French :) > > I do not know the list of active measurements an Atlas probe cover. > > > At the moment, ping, traceroute, tdig (dns), httpget, sslgetcert. > > Natively implemented or run via a external binary and CLI options ? Regards, -- J?r?me Benoit aka fraggle La M?t?o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From philip.homburg at ripe.net Wed May 9 11:20:38 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 09 May 2012 11:20:38 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <20120507214423.5b08f0f3@nemesis.grenouille.com> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> <4F9A7E73.2040604@sidn.nl> <20120504231732.007ad2cd@nemesis.grenouille.com> <4FA4FF57.7050104@ripe.net> <20120505164343.3b3e2fc4@nemesis.grenouille.com> <4FA7BCDE.1060905@ripe.net> <20120507214423.5b08f0f3@nemesis.grenouille.com> Message-ID: <4FAA36E6.6060101@ripe.net> On 5/7/12 21:44 , J?r?me Benoit wrote: > On Mon, 07 May 2012 14:15:26 +0200 > Philip Homburg wrote: > >> >> To list some things that have been mentioned: >> >> * TTM shutdown, Atlas is expected to provide functionality similar >> (but not identical) to what TTM provides > You plan to change the measurement control protocol used in TTM ? > I do not know which protocol TTM is using but if it's OWAMP ou TWAMP, > that will not fit the needs for large scale measurement campaign runt > from network edge. TTM boxes have GPS devices for time synchronization. That allows them to perform accurate one-way measurements. This capability will be lost. The TTM network is relatively small and static. Atlas can easily handle that, except you will be limited to two-way measurements. > In what Atlas call a "probe" (and what I call the measurement agent) ? > Yes. Except that an Atlas probe tends to be a physical device as well. >> * Roll out of Atlas Anchor boxes (regular PCs at well connected >> locations that can serve as the target of measurements and as a >> more powerful Atlas probe) > Sound like a good idea :) > > You then should add a tag to the measurement result that will permit > to distinguish the type of box running the measurement agent, like > > "generated": atlas-probe > "generated": atlas-box > > for example. We still have to figure out where we want to document meta-data. It doesn't make much sense to put all data about a probe in each and every measurement result. >> * Better UDM interface >> * UDM for all RIPE members (instead of just probe hosts and >> sponsors) > Eye candies. No, it is not eye candy. UDM allows users of the Atlas system to measure their own targets using remote probes. > If you have any document describing the JSON syntax used in Atlas, I > can write the code for your measurement agent that will > de-/serialize the probe definition to begin with. Commands for the probes are not in JSON. For output we are still transitioning to JSON. Currently the output is a mix of JSON meta data and free form ASCII output. In the next firmware upgrade that should become just JSON. For example for ping: |{| |||"id"||:||"1001"||,| |||"fw"||:||4414||,| |||"time"||:||1331729380||,| |||"name"||:||"193.0.14.129"||,| |||"addr"||:||"193.0.14.129"||,| |||"srcaddr"||:||"193.0.10.135"||,| |||"mode"||:||"ICMP4"||,| |||"ttl"||:||62||,| |||"size"||:||20||,| |||"result"||: [| ||| { ||"rtt"||:||49.101000| |},| ||| { ||"rtt"||:||6.899000| |},| ||| { ||"rtt"||:||4.139000| |} | |||] | |} We have this as internal documentation, but it should be published some time. | > > > We do not have securities problem because of OCaml choice > on the implementation side. Securities mechanism will probably be > the same as of the one you can find on most "web services" (shared > secret salted and hashed) to ensure that a REST transaction is > legit. I have to think about it some more ... Our security policy goes further than just protecting the probe. We also try to avoid getting the probe hosts in trouble. For example, having a probe visit certain web sites may be a bad idea. > > > For API and JSON syntax standardisation, the first step is to write the > specifications we(grenouille.com) plan to use and Atlas use and plan to > use, then discuss and factor out the best of each. We have some > writings but most of them are in French :) Yes. >>> I do not know the list of active measurements an Atlas probe cover. >>> >> At the moment, ping, traceroute, tdig (dns), httpget, sslgetcert. >> >> > Natively implemented or run via a external binary and CLI options ? Natively implemented. Creating lots of new processes turned out to be a bad idea on a system without an MMU. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abarcomb at ripe.net Wed May 9 14:24:33 2012 From: abarcomb at ripe.net (Ann Barcomb) Date: Wed, 09 May 2012 14:24:33 +0200 Subject: [atlas] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas In-Reply-To: <4FAA5E67.9090401@ripe.net> References: <4FAA5E67.9090401@ripe.net> Message-ID: <4FAA6201.1020404@ripe.net> [apologies for duplicate mails] Dear colleagues, RIPE Atlas can now be used to test your IPv6 reachability, even if you do not host a RIPE Atlas probe - provided you are a RIPE NCC member. More details can be found on RIPE Labs: https://labs.ripe.net/Members/becha/test-your-ipv6-reachability-using-ripe-atlas If you have any comments or questions, please let us know. Kind Regards, Ann Barcomb From jens.weibler at h-da.de Wed May 9 14:41:47 2012 From: jens.weibler at h-da.de (Jens Weibler) Date: Wed, 09 May 2012 14:41:47 +0200 Subject: [atlas] Credit Consumption Message-ID: <4FAA660B.7050005@h-da.de> Hi, I just noticed that I can't create new measurements anymore: "Your current daily credit consumption (62496) is higher than you allowed (15000)." But I've got enough credits on my balance and I don't want to stop my measurements. Why can't I just change the probe count or the measurement interval? ;) -- Jens Weibler IT-Services Hochschule Darmstadt www.h-da.de University of Applied Sciences Fachbereich Informatik www.fbi.h-da.de Sch?fferstr. 8b D-64295 Darmstadt Tel +49 6151 16-8425 Fax +49 6151 16-8935 jens.weibler at h-da.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4690 bytes Desc: S/MIME Cryptographic Signature URL: From astrikos at ripe.net Wed May 9 15:29:33 2012 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 09 May 2012 15:29:33 +0200 Subject: [atlas] Credit Consumption In-Reply-To: <4FAA660B.7050005@h-da.de> References: <4FAA660B.7050005@h-da.de> Message-ID: <4FAA713D.7060008@ripe.net> Hi, On 5/9/12 2:41 PM, Jens Weibler wrote: > Hi, > > I just noticed that I can't create new measurements anymore: > "Your current daily credit consumption (62496) is higher than you > allowed (15000)." > You are doing already more than what we allow to all users ;) You shouldn't complain :):) > But I've got enough credits on my balance and I don't want to stop my > measurements. > Why can't I just change the probe count or the measurement interval? ;) > We could implement it, but does it give an additional value except than dealing with the daily credit consumption limit[*]? Why stopping one of your UMDs is not enough[**]? The only reason that I see is to have continuous graphs... Anyhow, if people think is useful we could add it to our implementation list... Regards, Andreas * We would be happy to increase your limits if you have a nice usecase. Just tell us... ** For your case though, since you are a beta-tester and had more running UDMs before we apply the limits, if you stop one of your UMDs you will not be able to start another one From jerome.benoit at grenouille.com Wed May 9 23:32:25 2012 From: jerome.benoit at grenouille.com (=?ISO-8859-1?B?Suly9G1l?= Benoit) Date: Wed, 9 May 2012 23:32:25 +0200 Subject: [atlas] Feature-suggestion: "round-robin" probes In-Reply-To: <4FAA36E6.6060101@ripe.net> References: <19F54F2956911544A32543B8A9BDE07505A6A9@NICS-EXCH.sbg.nic.at> <4F9A7E73.2040604@sidn.nl> <20120504231732.007ad2cd@nemesis.grenouille.com> <4FA4FF57.7050104@ripe.net> <20120505164343.3b3e2fc4@nemesis.grenouille.com> <4FA7BCDE.1060905@ripe.net> <20120507214423.5b08f0f3@nemesis.grenouille.com> <4FAA36E6.6060101@ripe.net> Message-ID: <20120509233225.35568b93@nemesis.grenouille.com> On Wed, 09 May 2012 11:20:38 +0200 Philip Homburg wrote: > >> * TTM shutdown, Atlas is expected to provide functionality > >> similar (but not identical) to what TTM provides > > You plan to change the measurement control protocol used in TTM ? > > I do not know which protocol TTM is using but if it's OWAMP ou > > TWAMP, that will not fit the needs for large scale measurement > > campaign runt from network edge. > TTM boxes have GPS devices for time synchronization. That allows them > to perform accurate one-way measurements. This capability will be > lost. Maybe not. There's two way to cope with the lost of GPS device : * The smart one : If you use a Linux or FreeBSD kernel, you can use : http://www.cubinlab.ee.unimelb.edu.au/radclock/ which is very accurate (less than a micro-second) and cheap. * The dumb one : The time keeping feature is done by the control-configuration server, which mean that no time-stamp will be sent to "probe", only the the time difference between the current time and the measurement time-stamp calculated on the server. It's not very accurate but it permit to do measurement without the need to have the "probe" synchronized. The main problem here is that the protocol is so dumb that the time elapsed by packet travel is never counted anywhere. If seconds accuracy is enough, that the simplest solution. > > The TTM network is relatively small and static. Atlas can easily > handle that, except you will be limited to two-way measurements. > > In what Atlas call a "probe" (and what I call the measurement > > agent) ? > > > Yes. Except that an Atlas probe tends to be a physical device as well. I hope the host functionalities and the measurement functionalities have been thought with some kind of separation :p > > >> * Roll out of Atlas Anchor boxes (regular PCs at well connected > >> locations that can serve as the target of measurements and as > >> a more powerful Atlas probe) > > Sound like a good idea :) > > > > You then should add a tag to the measurement result that will permit > > to distinguish the type of box running the measurement agent, like > > > > "generated": atlas-probe > > "generated": atlas-box > > > > for example. > We still have to figure out where we want to document meta-data. It > doesn't make much sense to put all data about a probe in each and > every measurement result. In the some kind of "hello" command that describe the probe by itself only. In your system, the measurement agent will probably expose two orthogonal API : * One to write a measurement; * One to gather information on the measurement host (OS type, packets in flight, and so on). I say probably because we also have discussed a pipelined architecture of measurements that will not make this kind of difference : measurement 1 -OK-> measurement 2 -OK-> measurement 3 | KO -> stop measurement which permit to mimic a decision tree with not must complexity added : measurement 2 wait for a result that might be conditional to be runt. The latter is probably the better. > >> * Better UDM interface > >> * UDM for all RIPE members (instead of just probe hosts and > >> sponsors) > > Eye candies. > > No, it is not eye candy. UDM allows users of the Atlas system to > measure their own targets using remote probes. I see. Interface is then the protocol used by users to define their own measurement. The work flow should define is some way a "central authority" that will permit the measurement to be runt. As far as I see it, UDM is a moderated measurement campaign generator that can be hosted anywhere as long as the configuration approved go to the configuration server and are distributed to "probe". > > We have this as internal documentation, but it should be published > some time. > Let me known when the dust has settled and RIPE publish them. > > > > > > > We do not have securities problem because of OCaml choice > > on the implementation side. Securities mechanism will probably be > > the same as of the one you can find on most "web services" (shared > > secret salted and hashed) to ensure that a REST transaction is > > legit. I have to think about it some more ... > Our security policy goes further than just protecting the probe. We > also try to avoid getting the probe hosts in trouble. For example, > having a probe visit certain web sites may be a bad idea. The policy is enforced on the configuration server ? (that what we intend to implement via some kind of automation when possible) I should write down the big picture after some talks by the end of may. > > > > > > For API and JSON syntax standardisation, the first step is to write > > the specifications we(grenouille.com) plan to use and Atlas use and > > plan to use, then discuss and factor out the best of each. We have > > some writings but most of them are in French :) > Yes. Great. We're going to translate some already written and document the whole architecture in details. Cheers. -- J?r?me Benoit aka fraggle La M?t?o du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jens.weibler at h-da.de Wed May 9 23:57:36 2012 From: jens.weibler at h-da.de (Jens Weibler) Date: Wed, 09 May 2012 23:57:36 +0200 Subject: [atlas] Credit Consumption In-Reply-To: <4FAA713D.7060008@ripe.net> References: <4FAA660B.7050005@h-da.de> <4FAA713D.7060008@ripe.net> Message-ID: <4FAAE850.1040306@h-da.de> Hi, On 09.05.2012 15:29, Andreas Strikos wrote: > > On 5/9/12 2:41 PM, Jens Weibler wrote: >> I just noticed that I can't create new measurements anymore: >> "Your current daily credit consumption (62496) is higher than you >> allowed (15000)." >> > You are doing already more than what we allow to all users ;) You > shouldn't complain :):) :) But I am only doing a couple of checks.. I get 21.598 Credits per day for "Probe Uptime" but can only spend 15.000 credits/day? ;) yet 62k credits is way to high for 15k credits.. I only do: 1 ping from 10 probes (300s) 1 traceroute from 10 probes (900s) 1 traceroute6 from 10 probes (900s) 1 traceroute from 1 probe (900s) 1 traceroute6 from 1 probe (900s) What would be better values? What kind of measurements do the other users do? >> But I've got enough credits on my balance and I don't want to stop my >> measurements. >> Why can't I just change the probe count or the measurement interval? ;) >> > > We could implement it, but does it give an additional value except > than dealing with the daily credit consumption limit[*]? > Why stopping one of your UMDs is not enough[**]? The only reason that > I see is to have continuous graphs... > the graphs are one reason yes - but if I want to decrease the probe count/measurement interval I would have to enter all input again.. > Anyhow, if people think is useful we could add it to our > implementation list... let's see what other mailing list members say.. -- Jens Weibler IT-Services Hochschule Darmstadt www.h-da.de University of Applied Sciences Fachbereich Informatik www.fbi.h-da.de Sch?fferstr. 8b D-64295 Darmstadt Tel +49 6151 16-8425 Fax +49 6151 16-8935 jens.weibler at h-da.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4690 bytes Desc: S/MIME Cryptographic Signature URL: From noreply+4vc7a9 at twoomail.com Thu May 10 18:02:38 2012 From: noreply+4vc7a9 at twoomail.com (=?UTF-8?B?VGhvbWFzIHZpYSBUd29v?=) Date: Thu, 10 May 2012 16:02:38 +0000 Subject: [atlas] =?utf-8?q?baccouche2=40yahoo=2Ecom_t=27invite_=C3=A0_rejo?= =?utf-8?q?indre_Twoo?= Message-ID: <6B.64.09652.996EBAF4@mail03> Je viens de d?couvrir un nouvel outil pour rencontrer du monde en ligne : Twoo.com. ---------------------------------------------------------------- Hi, ripe-atlas Thomas vient de trouver un nouvel outil pour rencontrer du monde en ligne et aimerait que tu te joignes ? la f?te : Twoo.com Copie/colle le lien ci-dessous dans ton navigateur : http://twoo.com/m/39jVbXL_ Tu ne veux plus recevoir ces mails? Clique sur ce lien: /unsubscribe/?email=ripe-atlas%40ripe.net&code=37d33a52e2b420b3962ae52bae8ce1cb&typeid=2---------------------------------------------------------------- TWOO NV/SA, UBIDOCA Center 3145, 105 Route Pommiers, F-74370 Bellevue, France info-fr at twoo.com BE0834322338. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maildanrl at googlemail.com Fri May 11 16:34:02 2012 From: maildanrl at googlemail.com (Dan Luedtke) Date: Fri, 11 May 2012 16:34:02 +0200 Subject: [atlas] Ping to labs.ripe.net Message-ID: Hi probe-admins, I see this on all my probes, do you have the same problem? Ping (IPv4) labs.ripe.net 193.0.6.153 100% packet loss regards Dan -- Dan Luedtke http://www.danrl.de From inigo at infornografia.net Fri May 11 17:14:47 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Fri, 11 May 2012 17:14:47 +0200 Subject: [atlas] Ping to labs.ripe.net In-Reply-To: References: Message-ID: On Fri, May 11, 2012 at 4:34 PM, Dan Luedtke wrote: > Hi probe-admins, > > I see this on all my probes, do you have the same problem? > > Ping (IPv4) ? ? ?labs.ripe.net > 193.0.6.153 ? ? 100% packet loss > Yes, since mid March, from all my three probes. It was mentioned on the list that ICMP rate limiting was being enforced somewhere near labs, IIRC. Best, > regards > Dan > -- > Dan Luedtke > http://www.danrl.de > -- - As? que este es el futuro del hombre: calentarse a los rayos del sol, ba?arse en las claras corrientes de agua, y comer los frutos de la tierra olvidando todo trabajo y fatiga. - Bueno, y por qu? no? "El tiempo en sus manos" From ckeck at texoma.net Sat May 12 18:34:54 2012 From: ckeck at texoma.net (ckeck at texoma.net) Date: Sat, 12 May 2012 11:34:54 -0500 (CDT) Subject: [atlas] Cannot ping 128.0.0.1, 128.0.24.1 Message-ID: Cheers! Looked at my stats, and it looks as if not only my probe can't ping 128.0.0.1 and 128.0.24.1. The probe is hooked up to a router on a Verizon FIOS (fiberoptic) line. To see if that's a systemic issue, I pinged the same addresses from systems at work, as well as TMobile's (U.S.) wireless broadband, and they respond just fine. Question now is, where is the problem at? THX! -Cornelius -- Cornelius Keck -----------------------------------------> ckeck at texoma.net Beware, so long as you live, of judging men by their outward appearance. Jean de La Fontaine From ckeck at texoma.net Sat May 12 18:48:40 2012 From: ckeck at texoma.net (ckeck at texoma.net) Date: Sat, 12 May 2012 11:48:40 -0500 (CDT) Subject: [atlas] Cannot ping 128.0.0.1, 128.0.24.1 In-Reply-To: References: Message-ID: BTW, "not only my probe" means that I can't ping those two addresses from any system on the same network as the probe. -Cornelius On Sat, 12 May 2012 ckeck at texoma.net wrote: > Date: Sat, 12 May 2012 11:34:54 -0500 (CDT) > From: ckeck at texoma.net > To: ripe-atlas at ripe.net > Subject: [atlas] Cannot ping 128.0.0.1, 128.0.24.1 > > > Cheers! > > Looked at my stats, and it looks as if not only my probe can't ping > 128.0.0.1 and 128.0.24.1. The probe is hooked up to a router on a > Verizon FIOS (fiberoptic) line. To see if that's a systemic issue, > I pinged the same addresses from systems at work, as well as TMobile's > (U.S.) wireless broadband, and they respond just fine. Question now > is, where is the problem at? > > THX! > > -Cornelius > > -- Cornelius Keck -----------------------------------------> ckeck at texoma.net Beware, so long as you live, of judging men by their outward appearance. Jean de La Fontaine From lukasz at wsisiz.edu.pl Sat May 12 19:43:31 2012 From: lukasz at wsisiz.edu.pl (Lukasz Trabinski) Date: Sat, 12 May 2012 19:43:31 +0200 (CEST) Subject: [atlas] Cannot ping 128.0.0.1, 128.0.24.1 In-Reply-To: References: Message-ID: Hi Probably problem is related with: https://labs.ripe.net/Members/emileaben/the-curious-case-of-128.0-16 On Sat, 12 May 2012, ckeck at texoma.net wrote: > > Cheers! > > Looked at my stats, and it looks as if not only my probe can't ping > 128.0.0.1 and 128.0.24.1. The probe is hooked up to a router on a > Verizon FIOS (fiberoptic) line. To see if that's a systemic issue, > I pinged the same addresses from systems at work, as well as TMobile's > (U.S.) wireless broadband, and they respond just fine. Question now > is, where is the problem at? > > THX! > > -Cornelius > > From inigo at infornografia.net Sat May 12 19:55:50 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Sat, 12 May 2012 19:55:50 +0200 Subject: [atlas] Cannot ping 128.0.0.1, 128.0.24.1 In-Reply-To: References: Message-ID: On Sat, May 12, 2012 at 7:43 PM, Lukasz Trabinski wrote: > Hi > > Probably problem is related with: > https://labs.ripe.net/Members/emileaben/the-curious-case-of-128.0-16 > > http://www.ris.ripe.net/debogon/2012/05/20120511.shtml provides a list of filtering ASNs too. > > > On Sat, 12 May 2012, ckeck at texoma.net wrote: > >> >> Cheers! >> >> Looked at my stats, and it looks as if not only my probe can't ping >> 128.0.0.1 and 128.0.24.1. The probe is hooked up to a router on a >> Verizon FIOS (fiberoptic) line. To see if that's a systemic issue, >> I pinged the same addresses from systems at work, as well as TMobile's >> (U.S.) wireless broadband, and they respond just fine. Question now >> is, where is the problem at? >> >> THX! >> >> -Cornelius >> >> > -- - As? que este es el futuro del hombre: calentarse a los rayos del sol, ba?arse en las claras corrientes de agua, y comer los frutos de la tierra olvidando todo trabajo y fatiga. - Bueno, y por qu? no? "El tiempo en sus manos" From abarcomb at ripe.net Wed May 16 11:00:02 2012 From: abarcomb at ripe.net (Ann Barcomb) Date: Wed, 16 May 2012 11:00:02 +0200 Subject: [atlas] Ping to labs.ripe.net In-Reply-To: References: Message-ID: <4FB36C92.8080900@ripe.net> Hi Dan, Thank you for reminding us of this (and I?igo, thank you for answering). I have added an entry to the FAQ to explain this, and we will be removing labs.ripe.net from the default measurements. Kind Regards, Ann -- Ann Barcomb RIPE NCC Community Builder http://www.ripe.net Measurements Community Building +31 20 535 4444 On /11/52012 16:34 , Dan Luedtke wrote: > Hi probe-admins, > > I see this on all my probes, do you have the same problem? > > Ping (IPv4) labs.ripe.net > 193.0.6.153 100% packet loss > > regards > Dan From randy at psg.com Mon May 28 08:06:48 2012 From: randy at psg.com (Randy Bush) Date: Mon, 28 May 2012 15:06:48 +0900 Subject: [atlas] v6 support In-Reply-To: References: Message-ID: i am not understanding why probe 2285 does not seem to even get an ipv6 address on the in-rack lan, while a whole lot of other devices do. and 2283 managed to get a v6 address but no gateway, and of course no v6dns. what do the little puppies want, nd ra ??? randy From randy at psg.com Mon May 28 08:26:08 2012 From: randy at psg.com (Randy Bush) Date: Mon, 28 May 2012 15:26:08 +0900 Subject: [atlas] v6 support In-Reply-To: References: Message-ID: > i am not understanding why probe 2285 does not seem to even get an ipv6 > address on the in-rack lan, while a whole lot of other devices do. this mailing list *really* works! a few minutes after posting the above, the problem went away, the device got a global ipv6 addy after a couple of weeks without. > and 2283 managed to get a v6 address but no gateway, and of course no > v6dns. now both are the same, ip addy but claim to have no gateway. otoh, they seem to be globally ping6able. wth? IPv4 IPv6 Internet Address: 147.28.0.132 2001:418:1:0:220:4aff:fee0:246d Local Address: 147.28.0.132 2001:df9::220:4aff:fee0:246d/64 Gateway: 147.28.0.1 Undetermined/Unknown DNS Resolver: 147.28.0.35 Undetermined/Unknown AS Number: AS3130 AS3130 IPv4 IPv6 Internet Address: 210.138.216.50 2001:240:6a8:0:220:4aff:fee0:227c Local Address: 192.168.0.27 2001:240:6a8:0:220:4aff:fee0:227c/64 Gateway: 192.168.0.1 Undetermined/Unknown DNS Resolver: 192.168.0.1 Undetermined/Unknown AS Number: AS2497 AS2497 randy From maildanrl at googlemail.com Mon May 28 09:28:44 2012 From: maildanrl at googlemail.com (Dan Luedtke) Date: Mon, 28 May 2012 09:28:44 +0200 Subject: [atlas] v6 support In-Reply-To: References: Message-ID: On Mon, May 28, 2012 at 8:26 AM, Randy Bush wrote: > now both are the same, ip addy but claim to have no gateway. ?otoh, they > seem to be globally ping6able. ?wth? Same problem here. I switched to static configuration, but that doesn't help. IPv4 IPv6 Internet Address: 193.160.39.7 Undetermined/Unknown Local Address: 193.160.39.7 2001:67c:26f4::7/64 Gateway: 193.160.39.1 Undetermined/Unknown DNS Resolver: 2001:67c:26f4:100::20, 193.160.39.20 Undetermined/Unknown AS Number: AS57821 Undetermined/Unknown The probe just ignores whatever I put in there for static IPv6, except the address. It isn't ping6-able even with a static address (of course, since it has no gateway to route the responds to). -- Dan Luedtke http://www.danrl.de From daniel.karrenberg at ripe.net Mon May 28 10:54:43 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 28 May 2012 10:54:43 +0200 Subject: [atlas] v6 support In-Reply-To: References: Message-ID: Sorry, engineers are off today. It's a public holiday over here. I am sure they will be back to you tomorrow at the latest. On 28.05.2012, at 09:28, Dan Luedtke wrote: Daniel > On Mon, May 28, 2012 at 8:26 AM, Randy Bush wrote: >> now both are the same, ip addy but claim to have no gateway. otoh, they >> seem to be globally ping6able. wth? > Same problem here. I switched to static configuration, but that doesn't help. > > IPv4 IPv6 > Internet Address: 193.160.39.7 Undetermined/Unknown > Local Address: 193.160.39.7 2001:67c:26f4::7/64 > Gateway: 193.160.39.1 Undetermined/Unknown > DNS Resolver: 2001:67c:26f4:100::20, 193.160.39.20 Undetermined/Unknown > AS Number: AS57821 Undetermined/Unknown > > The probe just ignores whatever I put in there for static IPv6, except > the address. It isn't ping6-able even with a static address (of > course, since it has no gateway to route the responds to). > > > -- > Dan Luedtke > http://www.danrl.de > > From antony at ripe.net Mon May 28 22:15:19 2012 From: antony at ripe.net (Antony Antony) Date: Mon, 28 May 2012 22:15:19 +0200 Subject: [atlas] v6 support In-Reply-To: References: Message-ID: <20120528201519.GA24906@dog.ripe.net> On Mon, May 28, 2012 at 03:26:08PM +0900, Randy Bush wrote: > > i am not understanding why probe 2285 does not seem to even get an ipv6 > > address on the in-rack lan, while a whole lot of other devices do. > > this mailing list *really* works! a few minutes after posting the > above, the problem went away, the device got a global ipv6 addy after a > couple of weeks without. > > > and 2283 managed to get a v6 address but no gateway, and of course no > > v6dns. > > now both are the same, ip addy but claim to have no gateway. otoh, they > seem to be globally ping6able. wth? > > IPv4 IPv6 > Internet Address: 147.28.0.132 2001:418:1:0:220:4aff:fee0:246d > Local Address: 147.28.0.132 2001:df9::220:4aff:fee0:246d/64 > Gateway: 147.28.0.1 Undetermined/Unknown V6 Gateway is not reported in the UI. However, in this case, the probe has it and reports it. Probe 2285, the gw start with fe80 and ends wiht 341c. At the moment the only way to add V6 resolver is add it statically; you can add just resolvers(add both v4 adn v6). Probe Settings Change Probe's Network Configuration. Change DNS servers. > DNS Resolver: 147.28.0.35 Undetermined/Unknown > AS Number: AS3130 AS3130 > > IPv4 IPv6 > Internet Address: 210.138.216.50 2001:240:6a8:0:220:4aff:fee0:227c > Local Address: 192.168.0.27 2001:240:6a8:0:220:4aff:fee0:227c/64 > Gateway: 192.168.0.1 Undetermined/Unknown v6 gateway ends with b500. > DNS Resolver: 192.168.0.1 Undetermined/Unknown > AS Number: AS2497 AS2497 > regards, -antony From randy at psg.com Mon May 28 22:59:54 2012 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2012 05:59:54 +0900 Subject: [atlas] v6 support In-Reply-To: <20120528201519.GA24906@dog.ripe.net> References: <20120528201519.GA24906@dog.ripe.net> Message-ID: mornin' antony, >> this mailing list *really* works! a few minutes after posting the >> above, the problem went away, the device got a global ipv6 addy after a >> couple of weeks without. any idea about this magic? >>> and 2283 managed to get a v6 address but no gateway, and of course no >>> v6dns. >> IPv4 IPv6 >> Internet Address: 147.28.0.132 2001:418:1:0:220:4aff:fee0:246d >> Local Address: 147.28.0.132 2001:df9::220:4aff:fee0:246d/64 >> Gateway: 147.28.0.1 Undetermined/Unknown > > V6 Gateway is not reported in the UI. any chance for a low priority cosmetic fix for this? > However, in this case, the probe has it and reports it. Probe 2285, > the gw start with fe80 and ends with 341c. i will avoid heresies about RA and link local :) > At the moment the only way to add V6 resolver is add it statically; > you can add just resolvers(add both v4 adn v6). > Probe Settings > Change Probe's Network Configuration. thanks! randy From randy at psg.com Mon May 28 23:23:07 2012 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2012 06:23:07 +0900 Subject: [atlas] v6 support In-Reply-To: References: <20120528201519.GA24906@dog.ripe.net> Message-ID: >> At the moment the only way to add V6 resolver is add it statically; >> you can add just resolvers(add both v4 adn v6). >> Probe Settings >> Change Probe's Network Configuration. > thanks! a good recipe for down-time randy From antony at ripe.net Mon May 28 23:56:00 2012 From: antony at ripe.net (Antony Antony) Date: Mon, 28 May 2012 23:56:00 +0200 Subject: [atlas] v6 support In-Reply-To: References: <20120528201519.GA24906@dog.ripe.net> Message-ID: <20120528215559.GA25257@dog.ripe.net> Hi Randy, On Tue, May 29, 2012 at 05:59:54AM +0900, Randy Bush wrote: > >> this mailing list *really* works! a few minutes after posting the > >> above, the problem went away, the device got a global ipv6 addy after a > >> couple of weeks without. > > any idea about this magic? from what i gather the probe got first RA around epoch 1337782688, and reported around 2012-05-23 14:20:09 UTC. When the UI got updated, that is close to magic:) I can't explain!! However, if you look at "Show last 25 connections" you see an entry for 2012-05-27 16:38:58 UTC from a v6 address. that means, in the worst case, UI could have picked up V6 address change around that time. Also, after this reconnection it sent/received v6 measurements. > >>> and 2283 managed to get a v6 address but no gateway, and of course no > >>> v6dns. > >> IPv4 IPv6 > >> Internet Address: 147.28.0.132 2001:418:1:0:220:4aff:fee0:246d > >> Local Address: 147.28.0.132 2001:df9::220:4aff:fee0:246d/64 > >> Gateway: 147.28.0.1 Undetermined/Unknown > > > > V6 Gateway is not reported in the UI. > > any chance for a low priority cosmetic fix for this? One day we shoule improve the UI; no idea when. To do it right we have to show multiple addresses and gateways. The probe can have multiple V6 addresses. When it receives multiple RA(different prefixes) and static IPv6 address it ends up with multiple V6 gateways too. Then it is a bit messy to show. Just now you switched to static V6. Yes,there was some down time, but it is back now:) Now the fun begins, because the probe has two v6 address and two gateways, ::1 and the one it got via RA! regards, -antony From randy at psg.com Tue May 29 01:29:08 2012 From: randy at psg.com (Randy Bush) Date: Tue, 29 May 2012 08:29:08 +0900 Subject: [atlas] v6 support In-Reply-To: <20120528215559.GA25257@dog.ripe.net> References: <20120528201519.GA24906@dog.ripe.net> <20120528215559.GA25257@dog.ripe.net> Message-ID: mornin'antony, > When the UI got updated, that is close to magic:) I can't explain!! i demand a full refund! > One day we shoule improve the UI; no idea when. To do it right we have > to show multiple addresses and gateways. The probe can have multiple > V6 addresses. When it receives multiple RA(different prefixes) and > static IPv6 address it ends up with multiple V6 gateways too. Then it > is a bit messy to show. i will refrain from heresies about RA and link local > Just now you switched to static V6. Yes,there was some down time, but > it is back now:) i was a bit amazed at the length of down time > Now the fun begins, because the probe has two v6 address and two > gateways, ::1 and the one it got via RA! maybe, when it is statically configured it should drop what it learned via RA? hard call, as RA is a poor geek's vrrp6. sigh. randy From robert at ripe.net Thu May 31 10:08:02 2012 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 31 May 2012 10:08:02 +0200 Subject: [atlas] Cannot ping 128.0.0.1, 128.0.24.1 In-Reply-To: References: Message-ID: <4FC726E2.3050901@ripe.net> See also: http://albatross.ripe.net/128-probe-measurements/ Robert On 2012.05.12. 19:43, Lukasz Trabinski wrote: > Hi > > Probably problem is related with: > https://labs.ripe.net/Members/emileaben/the-curious-case-of-128.0-16 > > > > On Sat, 12 May 2012, ckeck at texoma.net wrote: > >> >> Cheers! >> >> Looked at my stats, and it looks as if not only my probe can't ping >> 128.0.0.1 and 128.0.24.1. The probe is hooked up to a router on a >> Verizon FIOS (fiberoptic) line. To see if that's a systemic issue, >> I pinged the same addresses from systems at work, as well as TMobile's >> (U.S.) wireless broadband, and they respond just fine. Question now >> is, where is the problem at? >> >> THX! >> >> -Cornelius >> >> > >