From v.bajpai at jacobs-university.de Tue Nov 3 11:55:26 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Tue, 3 Nov 2015 10:55:26 +0000 Subject: [atlas] ntp built-in measurements? In-Reply-To: <56324413.8000107@ripe.net> References: <2E2315C0-0376-4CC0-9D8C-47FBA5D4F2E6@jacobs-university.de> <56324413.8000107@ripe.net> Message-ID: Hello, > On 29 Oct 2015, at 17:06, Philip Homburg wrote: > >> On 2015/10/29 16:12 , Bajpai, Vaibhav wrote: >> Do the probes not run (new) NTP measurements as built-in >> measurements? ? I was glancing over the measurement data pushed by >> my probe, but I do not see any NTP measurement data. Although, when >> I try to provision a UDM, I do get an option to schedule an NTP >> measurement. > > I'm running a few NTP measurements on all probes (frequency 900). So > it would be weird if you probe doesn't have them. > > What target where you trying? I do see your NTP measurements, but I suppose these are UDMs provisioned by your user account, no? ? I somehow had the impression that the NTP measurements would also be running on my probe as built-in measurements by the RIPE Atlas system (similar to ping/ping6 to first/second hop). Perhaps I am wrong. > Philip PS: I am not trying to provision a UDM, I was just out of curiosity looking at the data collected by my probe via the built-in measurements. Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From philip.homburg at ripe.net Tue Nov 3 12:08:50 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 3 Nov 2015 12:08:50 +0100 Subject: [atlas] ntp built-in measurements? In-Reply-To: References: <2E2315C0-0376-4CC0-9D8C-47FBA5D4F2E6@jacobs-university.de> <56324413.8000107@ripe.net> Message-ID: <563895C2.2060402@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015/11/03 11:55 , Bajpai, Vaibhav wrote: > I do see your NTP measurements, but I suppose these are UDMs > provisioned by your user account, no? ? I somehow had the > impression that the NTP measurements would also be running on my > probe as built-in measurements by the RIPE Atlas system (similar to > ping/ping6 to first/second hop). Perhaps I am wrong. Hi, It was mostly of a matter of that there was no obvious NTP measurement for a built-in and nobody expressed a strong desire to have one. If anyone has a good idea, let us know. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWOJXCAAoJEPr6076EDopyBIAP/37WN7qFD8xBnNzN4omGOHSc EZsZOi13izlLhF4jBgzFaUvcihKTYmU5chbnsmPfVOhdb+exht7nHV+/+X0GumzH mJqMJ4JUWwK2OOJ2/o1XTb9CGu8uEUdP7al1XiNdp/Lyzs+ErBvTMYPZnJqS0bHn GvLO5eB4i4oskW4Aawp43eYPEEASSGbEzesmo3KW1uK3Icr7MmWi7TRxDoqL42XY 97P5T3JDuojtcO6j35ku4yRRbZanfNjB0w5FB9t6/R7fjN2YyY39bUPQBEwakozz 37JA9K1JD4aLxS+rijL5SawL7z+rDD5gc38/Sad1eTXNYB7gH/YRy2fAfHeZP71C bfzcw6FLkaT6OHd43Qdsun7d61x9FvDnWkLjxxQ4DvvH1nEXxtSzLh4WiWM42D+w pymfSDyMtERdeqo5ZbwUeYsHHSPmj8gAMq91uDZG42fPZpfEVFIJnsAYRdmFLrjM W6cTw6wbg0r/n+mEEPNa8wNXuosUQAIyHr5TvSkbD+CeVWFADZrJAmIoRtj/vkET VudLoaKgdXAz8zm+7rRAoPJ/YNvagvgZpP5sj3kfSSRg78/BzQ5ZhcoMRhE7cvd1 PtlLu4gORHRstC0F7vIBbiz9MIBBzVqukg5CuWnhZJvDsDhDy1gOLD15sRQMwg5r tZCtbTaUOUnqIJg3Ew/b =8nTg -----END PGP SIGNATURE----- From randy at psg.com Wed Nov 4 06:51:43 2015 From: randy at psg.com (Randy Bush) Date: Wed, 04 Nov 2015 14:51:43 +0900 Subject: [atlas] ntp built-in measurements? In-Reply-To: <563895C2.2060402@ripe.net> References: <2E2315C0-0376-4CC0-9D8C-47FBA5D4F2E6@jacobs-university.de> <56324413.8000107@ripe.net> <563895C2.2060402@ripe.net> Message-ID: > It was mostly of a matter of that there was no obvious NTP measurement > for a built-in and nobody expressed a strong desire to have one. no one expected ntp to become popular no one expected the spanish inquisition :) randy From BECHA at ripe.net Thu Nov 5 10:36:11 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 5 Nov 2015 10:36:11 +0100 Subject: [atlas] Read on RIPE Labs about the newest features & the community efforts In-Reply-To: <563B2227.60608@ripe.net> References: <563B2227.60608@ripe.net> Message-ID: <563B230B.8040408@ripe.net> Dear colleagues, There are a number of interesting new features and enhancements for RIPE Atlas users. Learn how you can put them to use: https://labs.ripe.net/Members/kistel/ripe-atlas-update-http-measurements-cli-tools-domainmon-and-more Regards, Vesna From bortzmeyer at nic.fr Thu Nov 5 15:14:24 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 5 Nov 2015 23:14:24 +0900 Subject: [atlas] Read on RIPE Labs about the newest features & the community efforts In-Reply-To: <563B230B.8040408@ripe.net> References: <563B2227.60608@ripe.net> <563B230B.8040408@ripe.net> Message-ID: <20151105141424.GA16361@laperouse.bortzmeyer.org> On Thu, Nov 05, 2015 at 10:36:11AM +0100, Vesna Manojlovic wrote a message of 9 lines which said: > https://labs.ripe.net/Members/kistel/ripe-atlas-update-http-measurements-cli-tools-domainmon-and-more Apparently, there is no link to the documentation of the API v2. Where is it? I need it to modify my programs (one more thing to do :-( From mcandela at ripe.net Thu Nov 5 15:53:42 2015 From: mcandela at ripe.net (Massimo Candela) Date: Thu, 5 Nov 2015 15:53:42 +0100 Subject: [atlas] Read on RIPE Labs about the newest features & the community efforts In-Reply-To: <20151105141424.GA16361@laperouse.bortzmeyer.org> References: <563B2227.60608@ripe.net> <563B230B.8040408@ripe.net> <20151105141424.GA16361@laperouse.bortzmeyer.org> Message-ID: <467138A6-DA9B-4CDF-A5F2-CE5C8798E19A@ripe.net> On 05 Nov 2015, at 15:14, Stephane Bortzmeyer wrote: > On Thu, Nov 05, 2015 at 10:36:11AM +0100, > Vesna Manojlovic wrote > a message of 9 lines which said: > >> https://labs.ripe.net/Members/kistel/ripe-atlas-update-http-measurements-cli-tools-domainmon-and-more > > Apparently, there is no link to the documentation of the API v2. Where > is it? I need it to modify my programs (one more thing to do :-( > > Hi Stephane, Don?t worry! The api is not going to change soon, and the V1 will be supported for a long time in parallel with the V2. It was just a heads-up about the planned changes. As soon as we have a documentation we will announce it. Ciao, Massimo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From pavel.odintsov at gmail.com Mon Nov 9 10:04:12 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 9 Nov 2015 12:04:12 +0300 Subject: [atlas] Feature request for IP record route feature in RIPE Atlas Message-ID: Hello, dear Atlas Team! As host of RIPE Anchor #6111 I have some feedback about your awesome service! Thanks for your Great Job in measuring Internet! I would like to ask very important feature for measuring reverse trace route. I'm speaking about IP record route option which could track up to 9 hops of reverse path. I want to know path to my hosts from networks who haven't RIPE Atlas. Actually I could not implement this feature due to 9 hop restriction in IP header. But RIPE Atlas offer really huge coverage over the World and we could reach really any host with <7 hops. But we haven't this feature in RIPE Atlas. Finally with this feature we could build full adjacently map over all the World. I have checked implementation details here https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code Looks like we need to build separate libevent based toolkit for this task or add this feature to ping tool. But unfortunately I could not find any docs about deploy of RIPE source code for development. Could you share some information? -- Sincerely yours, Pavel Odintsov From colinj at mx5.org.uk Mon Nov 9 11:16:56 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Mon, 9 Nov 2015 10:16:56 +0000 Subject: [atlas] Feature request for IP record route feature in RIPE Atlas In-Reply-To: References: Message-ID: virtual vm probe would be great as well :) ask for this before Colin > On 9 Nov 2015, at 09:04, Pavel Odintsov wrote: > > Hello, dear Atlas Team! > > As host of RIPE Anchor #6111 I have some feedback about your awesome service! > > Thanks for your Great Job in measuring Internet! > > I would like to ask very important feature for measuring reverse trace > route. I'm speaking about IP record route option which could track up > to 9 hops of reverse path. > > I want to know path to my hosts from networks who haven't RIPE Atlas. > Actually I could not implement this feature due to 9 hop restriction > in IP header. > > But RIPE Atlas offer really huge coverage over the World and we could > reach really any host with <7 hops. But we haven't this feature in > RIPE Atlas. > > Finally with this feature we could build full adjacently map over all the World. > > I have checked implementation details here > https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code > > Looks like we need to build separate libevent based toolkit for this > task or add this feature to ping tool. But unfortunately I could not > find any docs about deploy of RIPE source code for development. Could > you share some information? > > -- > Sincerely yours, Pavel Odintsov > From pavel.odintsov at gmail.com Mon Nov 9 11:30:22 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 9 Nov 2015 13:30:22 +0300 Subject: [atlas] Feature request for IP record route feature in RIPE Atlas In-Reply-To: References: Message-ID: +1 for VM probe :) On Mon, Nov 9, 2015 at 1:16 PM, Colin Johnston wrote: > virtual vm probe would be great as well :) ask for this before > > Colin > >> On 9 Nov 2015, at 09:04, Pavel Odintsov wrote: >> >> Hello, dear Atlas Team! >> >> As host of RIPE Anchor #6111 I have some feedback about your awesome service! >> >> Thanks for your Great Job in measuring Internet! >> >> I would like to ask very important feature for measuring reverse trace >> route. I'm speaking about IP record route option which could track up >> to 9 hops of reverse path. >> >> I want to know path to my hosts from networks who haven't RIPE Atlas. >> Actually I could not implement this feature due to 9 hop restriction >> in IP header. >> >> But RIPE Atlas offer really huge coverage over the World and we could >> reach really any host with <7 hops. But we haven't this feature in >> RIPE Atlas. >> >> Finally with this feature we could build full adjacently map over all the World. >> >> I have checked implementation details here >> https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code >> >> Looks like we need to build separate libevent based toolkit for this >> task or add this feature to ping tool. But unfortunately I could not >> find any docs about deploy of RIPE source code for development. Could >> you share some information? >> >> -- >> Sincerely yours, Pavel Odintsov >> > -- Sincerely yours, Pavel Odintsov From robert at ripe.net Mon Nov 9 13:27:45 2015 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 09 Nov 2015 13:27:45 +0100 Subject: [atlas] Sharing credits with colleagues In-Reply-To: <563241A3.3080202@eunetworks.com> References: <563241A3.3080202@eunetworks.com> Message-ID: <56409141.1070501@ripe.net> On 2015-10-29 16:56, Oliver Haake wrote: > Hey there, > > I'm very curious if you guys have an ETA for the "Sharing credits with > colleagues" feature. > > Any ideas? > > > > Cheers, > Oliver Hello, This task is coming up shortly, so I expect that we can deliver it soon. At the moment we think it'll result in two functions: 1. Make "standing orders": automatically spread the excess amount of credits to other accounts if I have more than X, AND/OR 2. Let me make a measurement that will be billed to someone else, who authorised me before to do this These two will fit a lot of use cases with (we believe) a low amount of complexity. Cheers, Robert From s.wolf at wolfsec.ch Mon Nov 9 13:34:41 2015 From: s.wolf at wolfsec.ch (Stephan Wolf) Date: Mon, 9 Nov 2015 13:34:41 +0100 Subject: [atlas] Feature request for IP record route feature in RIPE Atlas In-Reply-To: References: Message-ID: +2 for VM probe Am 09.11.2015 11:30 schrieb "Pavel Odintsov" : > +1 for VM probe :) > > On Mon, Nov 9, 2015 at 1:16 PM, Colin Johnston wrote: > > virtual vm probe would be great as well :) ask for this before > > > > Colin > > > >> On 9 Nov 2015, at 09:04, Pavel Odintsov > wrote: > >> > >> Hello, dear Atlas Team! > >> > >> As host of RIPE Anchor #6111 I have some feedback about your awesome > service! > >> > >> Thanks for your Great Job in measuring Internet! > >> > >> I would like to ask very important feature for measuring reverse trace > >> route. I'm speaking about IP record route option which could track up > >> to 9 hops of reverse path. > >> > >> I want to know path to my hosts from networks who haven't RIPE Atlas. > >> Actually I could not implement this feature due to 9 hop restriction > >> in IP header. > >> > >> But RIPE Atlas offer really huge coverage over the World and we could > >> reach really any host with <7 hops. But we haven't this feature in > >> RIPE Atlas. > >> > >> Finally with this feature we could build full adjacently map over all > the World. > >> > >> I have checked implementation details here > >> > https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code > >> > >> Looks like we need to build separate libevent based toolkit for this > >> task or add this feature to ping tool. But unfortunately I could not > >> find any docs about deploy of RIPE source code for development. Could > >> you share some information? > >> > >> -- > >> Sincerely yours, Pavel Odintsov > >> > > > > > > -- > Sincerely yours, Pavel Odintsov > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Mon Nov 9 13:43:44 2015 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 09 Nov 2015 13:43:44 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: References: Message-ID: <56409500.4050104@ripe.net> Dear All, At the risk of assigning more work to myself than I anticipate: there's an action item on me to come up with some thoughts and questions to the community about the VM probes. For example: what virtualisation technology would people prefer (as we cannot support all of them)? How would we manage these (think of field-upgrades) and how to administer them (at the moment it's easy, since we supply the whole device with keys and firmware). Regards, Robert On 2015-11-09 13:34, Stephan Wolf wrote: > +2 for VM probe From colinj at mx5.org.uk Mon Nov 9 13:49:19 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Mon, 9 Nov 2015 12:49:19 +0000 Subject: [atlas] VM probes In-Reply-To: <56409500.4050104@ripe.net> References: <56409500.4050104@ripe.net> Message-ID: <860CB300-1143-474A-BF1A-08EEE9BFA4B1@mx5.org.uk> one vote for vmware virtualisation should be able to do upgrade of vm in place, like Sophus do with their UTM device admin via download and assign probe on first time vm startup with script. Colin > On 9 Nov 2015, at 12:43, Robert Kisteleki wrote: > > Dear All, > > At the risk of assigning more work to myself than I anticipate: there's an > action item on me to come up with some thoughts and questions to the > community about the VM probes. For example: what virtualisation technology > would people prefer (as we cannot support all of them)? How would we manage > these (think of field-upgrades) and how to administer them (at the moment > it's easy, since we supply the whole device with keys and firmware). > > Regards, > Robert > > > On 2015-11-09 13:34, Stephan Wolf wrote: >> +2 for VM probe > From pavel.odintsov at gmail.com Mon Nov 9 13:54:15 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Mon, 9 Nov 2015 15:54:15 +0300 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <56409500.4050104@ripe.net> References: <56409500.4050104@ripe.net> Message-ID: Hello, Robert! I completely agree with you. I'm thinking from developer point of view. I want to hack evtraceroute/evping. But I could not compile they on my Linux box. So I'm looking for some way to build / check RIPE Atlas environment on my machine. So I definitely could install it manually into VirtualBox appliance. On Mon, Nov 9, 2015 at 3:43 PM, Robert Kisteleki wrote: > Dear All, > > At the risk of assigning more work to myself than I anticipate: there's an > action item on me to come up with some thoughts and questions to the > community about the VM probes. For example: what virtualisation technology > would people prefer (as we cannot support all of them)? How would we manage > these (think of field-upgrades) and how to administer them (at the moment > it's easy, since we supply the whole device with keys and firmware). > > Regards, > Robert > > > On 2015-11-09 13:34, Stephan Wolf wrote: >> +2 for VM probe > -- Sincerely yours, Pavel Odintsov From oliver.haake at eunetworks.com Mon Nov 9 14:02:31 2015 From: oliver.haake at eunetworks.com (Oliver Haake) Date: Mon, 9 Nov 2015 14:02:31 +0100 Subject: [atlas] Sharing credits with colleagues In-Reply-To: <56409141.1070501@ripe.net> References: <563241A3.3080202@eunetworks.com> <56409141.1070501@ripe.net> Message-ID: <56409967.7000901@eunetworks.com> Thank you Robert, that sounds awesome. Keep up the good work. Cheers, Oliver On 09.11.2015 13:27, Robert Kisteleki wrote: > On 2015-10-29 16:56, Oliver Haake wrote: >> Hey there, >> >> I'm very curious if you guys have an ETA for the "Sharing credits with >> colleagues" feature. >> >> Any ideas? >> >> >> >> Cheers, >> Oliver > > Hello, > > This task is coming up shortly, so I expect that we can deliver it soon. At > the moment we think it'll result in two functions: > > 1. Make "standing orders": automatically spread the excess amount of credits > to other accounts if I have more than X, AND/OR > 2. Let me make a measurement that will be billed to someone else, who > authorised me before to do this > > These two will fit a lot of use cases with (we believe) a low amount of > complexity. > > Cheers, > Robert > -- Oliver Haake | Tier3 Network Engineer | euNetworks Theodor-Heuss-Allee 112 | 60486 Frankfurt/Main +49 69 905 542 49 office F?r weitere Informationen ?ber euNetworks oder f?r Informationen ?ber unsere Unternehmen, darunter euNetworks GmbH, besuchen Sie bitte unsere Webseite www.eunetworks.de. Diese E-Mail und oder Anh?nge k?nnen vertrauliche und/oder gesetzlich privilegierte Information enthalten. Wenn Sie nicht der beabsichtigte Empf?nger sind, l?schen Sie bitte die E-Mail, ohne sie zu lesen, und benachrichtigen Sie den Absender. euNetworks GmbH Gesch?ftsf?hrer: Joachim Piroth Sueleyman Karaman Myriam Buchheister Amtsgericht Frankfurt am Main HRB 88224 Steuernummer 04523251638 Umsatzsteuer ID: DE 201 739 716 From philip.homburg at ripe.net Mon Nov 9 14:10:51 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 9 Nov 2015 14:10:51 +0100 Subject: [atlas] Feature request for IP record route feature in RIPE Atlas In-Reply-To: References: Message-ID: <56409B5B.3000907@ripe.net> On 2015/11/09 10:04 , Pavel Odintsov wrote: > But RIPE Atlas offer really huge coverage over the World and we could > reach really any host with <7 hops. But we haven't this feature in > RIPE Atlas. > > Finally with this feature we could build full adjacently map over all the World. > > I have checked implementation details here > https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code > > Looks like we need to build separate libevent based toolkit for this > task or add this feature to ping tool. But unfortunately I could not > find any docs about deploy of RIPE source code for development. Could > you share some information? Hi, I use a vm running debian wheezy for development. The anchors run CentOS 6. So the code should run there. If it doesn't run on other Linux versions then please let me know and I'll see what I can do. The INSTALL file in the source code has specific instructions on how to build. I would advice against just writing some code and asking it to be merged. Instead coordinate with me what you want to change. Philip From s.wolf at wolfsec.ch Mon Nov 9 14:13:17 2015 From: s.wolf at wolfsec.ch (Stephan Wolf) Date: Mon, 9 Nov 2015 14:13:17 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <56409500.4050104@ripe.net> References: <56409500.4050104@ripe.net> Message-ID: Hello, here I would generate a OVM: https://en.wikipedia.org/wiki/Open_Virtualization_Format so it is in first stage hypervizor independent. however for sure, the NIC needs to be supported who is emulated. E.g. E1000 under VMware is ok, and not their proprietary VMXnet. So I would simply support the commonly used - in most cases the E1000 from Intel. if someone uses an "special" hypervizor, which is not supporting to emulate an E1000, well... unsupported Just my 2 cents, Cheers Stephan 2015-11-09 13:43 GMT+01:00 Robert Kisteleki : > Dear All, > > At the risk of assigning more work to myself than I anticipate: there's an > action item on me to come up with some thoughts and questions to the > community about the VM probes. For example: what virtualisation technology > would people prefer (as we cannot support all of them)? How would we manage > these (think of field-upgrades) and how to administer them (at the moment > it's easy, since we supply the whole device with keys and firmware). > > Regards, > Robert > > > On 2015-11-09 13:34, Stephan Wolf wrote: > > +2 for VM probe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.karrenberg at ripe.net Tue Nov 10 09:33:01 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 10 Nov 2015 09:33:01 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <56409500.4050104@ripe.net> References: <56409500.4050104@ripe.net> Message-ID: <5641ABBD.1050504@ripe.net> I understand the temptation of "easy deployment". The con-s also have been outlined ad nauseam. So let me repeat this only once: We should all assess this thoroughly before diving into it. What quality of data we expect from VMs? What is the real cost of *supporting* VMs? The main costs are not in the hardware or in deployment. They are in running the back-end and support. So far RIPE Atlas produces quite repeatable and comparable results even if stressed well beyond the design limits. This is a unique feature of RIPE Atlas. Is the per definition non-repeatable and comparable data from VMs worth the effort of support and back-end resources? My suspicion is that when we look beyond the "+1s" in favor of easy, almost cost-less, deployment we will find that it is not worth it. Also there will be much less incentive to deploy first rate anchors and probes when the second rate VMs are available? Why earn credits by making the effort to install real probes when credits can be earned in a much easier way? >From my personal, informal assessment I advise against supporting VMs. I recommend a thorough assessment of the data quality, the costs and the effects on RIPE Atlas as a whole before diving into soloutioneering. Daniel On 9.11.15 13:43 , Robert Kisteleki wrote: > Dear All, > > At the risk of assigning more work to myself than I anticipate: there's an > action item on me to come up with some thoughts and questions to the > community about the VM probes. For example: what virtualisation technology > would people prefer (as we cannot support all of them)? How would we manage > these (think of field-upgrades) and how to administer them (at the moment > it's easy, since we supply the whole device with keys and firmware). > > Regards, > Robert > > > On 2015-11-09 13:34, Stephan Wolf wrote: >> +2 for VM probe > > From gert at space.net Tue Nov 10 09:56:40 2015 From: gert at space.net (Gert Doering) Date: Tue, 10 Nov 2015 09:56:40 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <5641ABBD.1050504@ripe.net> References: <56409500.4050104@ripe.net> <5641ABBD.1050504@ripe.net> Message-ID: <20151110085640.GN89490@Space.Net> Hi, On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote: > >From my personal, informal assessment I advise against supporting VMs. I > recommend a thorough assessment of the data quality, the costs and the > effects on RIPE Atlas as a whole before diving into soloutioneering. From experience running a recursive DNS on a VM platform, I'd also speak against supporting VMs. Unpredictable load elsewhere on the same host can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't be able to differenciate from "something on the path is broken/lossy". Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From pavel.odintsov at gmail.com Tue Nov 10 10:07:21 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 10 Nov 2015 12:07:21 +0300 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <20151110085640.GN89490@Space.Net> References: <56409500.4050104@ripe.net> <5641ABBD.1050504@ripe.net> <20151110085640.GN89490@Space.Net> Message-ID: Hello, Community! I like idea about VM based Anchor's. For example in Russia we have so much companies who really want to host RIPE Anchor hosting but it's really hard due to so much bureaucracy for computer hardware import. It's really sophisticated and long task. VM based Anchors could help in this case. But they should be designated as "second-rate monitoring". So somebody who interested in monitoring over non-so-reliable-vm's could use they. Actually, this VM's should "mine" less points than full-size-Anchor. We could select some unified way to run VM's. I prefer VmWare because it's: 1) Free 2) Simple to deploy 3) Mature 4) Very simple VM deploy Xen, KVM are pretty too but they are based on non standard linux distributions and it could be a configuration issue. OpenVZ/Docker and LXC should be avoided because (actually I have so much experience with they and I'm not a technology hater) they are not offer dedicated service and not isolated perfectly from each other processes. On Tue, Nov 10, 2015 at 11:56 AM, Gert Doering wrote: > Hi, > > On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote: >> >From my personal, informal assessment I advise against supporting VMs. I >> recommend a thorough assessment of the data quality, the costs and the >> effects on RIPE Atlas as a whole before diving into soloutioneering. > > From experience running a recursive DNS on a VM platform, I'd also speak > against supporting VMs. Unpredictable load elsewhere on the same host > can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't > be able to differenciate from "something on the path is broken/lossy". > > 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 -- Sincerely yours, Pavel Odintsov From daniel.karrenberg at ripe.net Tue Nov 10 10:36:48 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 10 Nov 2015 10:36:48 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: References: <56409500.4050104@ripe.net> <5641ABBD.1050504@ripe.net> <20151110085640.GN89490@Space.Net> Message-ID: <5641BAB0.8000104@ripe.net> At this time are 485 connected probes and two connected anchors in Russia. As far as I know Soekris boxes can be bought in Russia. Daniel On 10.11.15 10:07 , Pavel Odintsov wrote: > Hello, Community! > > I like idea about VM based Anchor's. > > For example in Russia we have so much companies who really want to > host RIPE Anchor hosting but it's really hard due to so much > bureaucracy for computer hardware import. It's really sophisticated > and long task. > > VM based Anchors could help in this case. But they should be > designated as "second-rate monitoring". So somebody who interested in > monitoring over non-so-reliable-vm's could use they. Actually, this > VM's should "mine" less points than full-size-Anchor. > > We could select some unified way to run VM's. I prefer VmWare because it's: > 1) Free > 2) Simple to deploy > 3) Mature > 4) Very simple VM deploy > > Xen, KVM are pretty too but they are based on non standard linux > distributions and it could be a configuration issue. OpenVZ/Docker and > LXC should be avoided because (actually I have so much experience with > they and I'm not a technology hater) they are not offer dedicated > service and not isolated perfectly from each other processes. > > > > On Tue, Nov 10, 2015 at 11:56 AM, Gert Doering wrote: >> Hi, >> >> On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote: >>> >From my personal, informal assessment I advise against supporting VMs. I >>> recommend a thorough assessment of the data quality, the costs and the >>> effects on RIPE Atlas as a whole before diving into soloutioneering. >> >> From experience running a recursive DNS on a VM platform, I'd also speak >> against supporting VMs. Unpredictable load elsewhere on the same host >> can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't >> be able to differenciate from "something on the path is broken/lossy". >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 > > > From pavel.odintsov at gmail.com Tue Nov 10 10:49:01 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 10 Nov 2015 12:49:01 +0300 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <5641BAB0.8000104@ripe.net> References: <56409500.4050104@ripe.net> <5641ABBD.1050504@ripe.net> <20151110085640.GN89490@Space.Net> <5641BAB0.8000104@ripe.net> Message-ID: Hello! Awesome! Could you share where we could bought it? I will share this information with local community. On Tue, Nov 10, 2015 at 12:36 PM, Daniel Karrenberg wrote: > At this time are 485 connected probes and two connected anchors in > Russia. As far as I know Soekris boxes can be bought in Russia. > > Daniel > > On 10.11.15 10:07 , Pavel Odintsov wrote: >> Hello, Community! >> >> I like idea about VM based Anchor's. >> >> For example in Russia we have so much companies who really want to >> host RIPE Anchor hosting but it's really hard due to so much >> bureaucracy for computer hardware import. It's really sophisticated >> and long task. >> >> VM based Anchors could help in this case. But they should be >> designated as "second-rate monitoring". So somebody who interested in >> monitoring over non-so-reliable-vm's could use they. Actually, this >> VM's should "mine" less points than full-size-Anchor. >> >> We could select some unified way to run VM's. I prefer VmWare because it's: >> 1) Free >> 2) Simple to deploy >> 3) Mature >> 4) Very simple VM deploy >> >> Xen, KVM are pretty too but they are based on non standard linux >> distributions and it could be a configuration issue. OpenVZ/Docker and >> LXC should be avoided because (actually I have so much experience with >> they and I'm not a technology hater) they are not offer dedicated >> service and not isolated perfectly from each other processes. >> >> >> >> On Tue, Nov 10, 2015 at 11:56 AM, Gert Doering wrote: >>> Hi, >>> >>> On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote: >>>> >From my personal, informal assessment I advise against supporting VMs. I >>>> recommend a thorough assessment of the data quality, the costs and the >>>> effects on RIPE Atlas as a whole before diving into soloutioneering. >>> >>> From experience running a recursive DNS on a VM platform, I'd also speak >>> against supporting VMs. Unpredictable load elsewhere on the same host >>> can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't >>> be able to differenciate from "something on the path is broken/lossy". >>> >>> 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 >> >> >> -- Sincerely yours, Pavel Odintsov From jaap at NLnetLabs.nl Tue Nov 10 10:52:38 2015 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Tue, 10 Nov 2015 10:52:38 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <5641BAB0.8000104@ripe.net> References: <56409500.4050104@ripe.net> <5641ABBD.1050504@ripe.net> <20151110085640.GN89490@Space.Net> <5641BAB0.8000104@ripe.net> Message-ID: <201511100952.tAA9qcaK097397@bela.nlnetlabs.nl> Daniel Karrenberg writes: > At this time are 485 connected probes and two connected anchors in > Russia. As far as I know Soekris boxes can be bought in Russia. And there are regularly atlas ambassadors in Russia. I returned with 3 probes from ENOG-10 because I couldn't get rid of them. jaap From sebastian at sneuner.org Tue Nov 10 10:57:36 2015 From: sebastian at sneuner.org (Sebastian Neuner) Date: Tue, 10 Nov 2015 10:57:36 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <56409500.4050104@ripe.net> References: <56409500.4050104@ripe.net> Message-ID: <5641BF90.8000903@sneuner.org> Hi all, first of all, I see a few problems with VM probes. It's important for the Atlas measurements to be comparable, which can be a problem if you just run a virtual probe on someones hardware in a datacenter somewhere. Or to put it simple: we want to measure networks, not virtualization hardware. Another problem might be, that a hosting company might not be okay with information like traceroutes being publicly available. That might be an issue for the customer, but also for RIPE, who is hosting the data, and some thought should be put into this. Also, since people are using the results for scientific purposes, it should at least be possible to differentiate between results of hardware and software probes. > what virtualisation technology > would people prefer (as we cannot support all of them)? Just a random thought: Why run a complete VM for that? Why not just a binary? > How would we manage > these (think of field-upgrades) and how to administer them (at the moment > it's easy, since we supply the whole device with keys and firmware). If it's a binary, you could ship it via package managers, i.e. debian/ubuntu/centos packages. Regards, Sebastian On 09.11.2015 13:43, Robert Kisteleki wrote: > Dear All, > > At the risk of assigning more work to myself than I anticipate: there's an > action item on me to come up with some thoughts and questions to the > community about the VM probes. For example: what virtualisation technology > would people prefer (as we cannot support all of them)? How would we manage > these (think of field-upgrades) and how to administer them (at the moment > it's easy, since we supply the whole device with keys and firmware). > > Regards, > Robert > > > On 2015-11-09 13:34, Stephan Wolf wrote: >> +2 for VM probe > From v.bajpai at jacobs-university.de Tue Nov 10 11:10:35 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Tue, 10 Nov 2015 10:10:35 +0000 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <5641BF90.8000903@sneuner.org> References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> Message-ID: <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> Hello, As a researcher, I will have to filter out these VM probes unless there is considerable evidence that VM probes are able to produce results comparable to hardware probes. Note, calibrating probes is really hard and it takes time and effort [1, 2]. The idea of using these VM probes for "second-rate monitoring? is also less useful because it leads to fragmentation of RIPE Atlas vantage points. I am completely in line with Daniel?s view ? the novelty of RIPE Atlas is being able to produce repeatable / comparable results. We should not compromise this unique standpoint. [1] http://dx.doi.org/10.1145/2805789.2805796 [2] http://dx.doi.org/10.1145/2815675.2815710 Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From s.wolf at wolfsec.ch Tue Nov 10 11:18:37 2015 From: s.wolf at wolfsec.ch (Stephan Wolf) Date: Tue, 10 Nov 2015 11:18:37 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> Message-ID: Sure, PROBES as an VM in e.g. overloaded environments are a problem. So Probes on a VM = can result in some troubles in the existing Atlas model. To make a "second class" probes I agree that this takes too much efforts. ANCHOR as an VM would really make sense. What do you think about this ? PACKAGES for an OS I see too much dependencies / problems incoming. So a VM with an isolated OS for this usage makes sense. Just my 2 cents .-) Cheers, Stephan 2015-11-10 11:10 GMT+01:00 Bajpai, Vaibhav : > Hello, > > As a researcher, I will have to filter out these VM probes unless there > is considerable evidence that VM probes are able to produce results > comparable to hardware probes. Note, calibrating probes is really > hard and it takes time and effort [1, 2]. > > The idea of using these VM probes for "second-rate monitoring? is also > less useful because it leads to fragmentation of RIPE Atlas vantage points. > > I am completely in line with Daniel?s view ? the novelty of RIPE Atlas > is being able to produce repeatable / comparable results. We should > not compromise this unique standpoint. > > [1] http://dx.doi.org/10.1145/2805789.2805796 > [2] http://dx.doi.org/10.1145/2815675.2815710 > > Best, Vaibhav > > ===================================================== > Vaibhav Bajpai > > Room 91, Research I > School of Engineering and Sciences > Jacobs University Bremen, Germany > > www.vaibhavbajpai.com > ===================================================== > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Tue Nov 10 11:27:17 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 10 Nov 2015 10:27:17 +0000 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> Message-ID: <5641C685.5090009@inex.ie> On 10/11/2015 10:18, Stephan Wolf wrote: > ANCHOR as an VM would really make sense. > What do you think about this ? it depends how the hypervisor is managed. I've seen some completely overloaded hypervisors where the VM performance is terrible. At least with the hardware probe, the RIPE NCC controls everything down to the hardware, which makes it more predictable to manage, which means better results. Nick From daniel.karrenberg at ripe.net Tue Nov 10 11:30:48 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 10 Nov 2015 11:30:48 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: References: <56409500.4050104@ripe.net> <5641ABBD.1050504@ripe.net> <20151110085640.GN89490@Space.Net> <5641BAB0.8000104@ripe.net> Message-ID: <5641C758.1020405@ripe.net> Pavel, it appears that my information is out-dated. You are right one needs to import them these days. I realise that this is awkward and expensive, but it appears to be possible. Maybe rather than wasting time on VMs we should consider a new type of anchor which is more readily available everywhere than the Soekris. Personally I would go in the direction of Ubiquity Edge Routers or Mikrotik routers which I know for sure are available in Russia and also widely available around the world. Do you have suggestions? Daniel On 10.11.15 10:49 , Pavel Odintsov wrote: > Hello! > > Awesome! Could you share where we could bought it? I will share this > information with local community. > > On Tue, Nov 10, 2015 at 12:36 PM, Daniel Karrenberg > wrote: >> At this time are 485 connected probes and two connected anchors in >> Russia. As far as I know Soekris boxes can be bought in Russia. >> >> Daniel >> >> On 10.11.15 10:07 , Pavel Odintsov wrote: >>> Hello, Community! >>> >>> I like idea about VM based Anchor's. >>> >>> For example in Russia we have so much companies who really want to >>> host RIPE Anchor hosting but it's really hard due to so much >>> bureaucracy for computer hardware import. It's really sophisticated >>> and long task. >>> >>> VM based Anchors could help in this case. But they should be >>> designated as "second-rate monitoring". So somebody who interested in >>> monitoring over non-so-reliable-vm's could use they. Actually, this >>> VM's should "mine" less points than full-size-Anchor. >>> >>> We could select some unified way to run VM's. I prefer VmWare because it's: >>> 1) Free >>> 2) Simple to deploy >>> 3) Mature >>> 4) Very simple VM deploy >>> >>> Xen, KVM are pretty too but they are based on non standard linux >>> distributions and it could be a configuration issue. OpenVZ/Docker and >>> LXC should be avoided because (actually I have so much experience with >>> they and I'm not a technology hater) they are not offer dedicated >>> service and not isolated perfectly from each other processes. >>> >>> >>> >>> On Tue, Nov 10, 2015 at 11:56 AM, Gert Doering wrote: >>>> Hi, >>>> >>>> On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote: >>>>> >From my personal, informal assessment I advise against supporting VMs. I >>>>> recommend a thorough assessment of the data quality, the costs and the >>>>> effects on RIPE Atlas as a whole before diving into soloutioneering. >>>> >>>> From experience running a recursive DNS on a VM platform, I'd also speak >>>> against supporting VMs. Unpredictable load elsewhere on the same host >>>> can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't >>>> be able to differenciate from "something on the path is broken/lossy". >>>> >>>> Gert Doering >>>> -- NetMaster >>>> -- >>>> have you enabled IPv6 on something today...? >>>> >>>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >>>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>>> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >>> >>> >>> > > > From pavel.odintsov at gmail.com Tue Nov 10 11:39:26 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 10 Nov 2015 13:39:26 +0300 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <5641C758.1020405@ripe.net> References: <56409500.4050104@ripe.net> <5641ABBD.1050504@ripe.net> <20151110085640.GN89490@Space.Net> <5641BAB0.8000104@ripe.net> <5641C758.1020405@ripe.net> Message-ID: Hello! Maybe we could fix import issues with some vendor? We have really huge and good shop of network hardware here: http://shop.nag.ru If they could offer Soekris platform could be fine. On Tue, Nov 10, 2015 at 1:30 PM, Daniel Karrenberg wrote: > Pavel, > > it appears that my information is out-dated. You are right one needs to > import them these days. I realise that this is awkward and expensive, > but it appears to be possible. > > Maybe rather than wasting time on VMs we should consider a new type of > anchor which is more readily available everywhere than the Soekris. > Personally I would go in the direction of Ubiquity Edge Routers or > Mikrotik routers which I know for sure are available in Russia and also > widely available around the world. Do you have suggestions? > > Daniel > > On 10.11.15 10:49 , Pavel Odintsov wrote: >> Hello! >> >> Awesome! Could you share where we could bought it? I will share this >> information with local community. >> >> On Tue, Nov 10, 2015 at 12:36 PM, Daniel Karrenberg >> wrote: >>> At this time are 485 connected probes and two connected anchors in >>> Russia. As far as I know Soekris boxes can be bought in Russia. >>> >>> Daniel >>> >>> On 10.11.15 10:07 , Pavel Odintsov wrote: >>>> Hello, Community! >>>> >>>> I like idea about VM based Anchor's. >>>> >>>> For example in Russia we have so much companies who really want to >>>> host RIPE Anchor hosting but it's really hard due to so much >>>> bureaucracy for computer hardware import. It's really sophisticated >>>> and long task. >>>> >>>> VM based Anchors could help in this case. But they should be >>>> designated as "second-rate monitoring". So somebody who interested in >>>> monitoring over non-so-reliable-vm's could use they. Actually, this >>>> VM's should "mine" less points than full-size-Anchor. >>>> >>>> We could select some unified way to run VM's. I prefer VmWare because it's: >>>> 1) Free >>>> 2) Simple to deploy >>>> 3) Mature >>>> 4) Very simple VM deploy >>>> >>>> Xen, KVM are pretty too but they are based on non standard linux >>>> distributions and it could be a configuration issue. OpenVZ/Docker and >>>> LXC should be avoided because (actually I have so much experience with >>>> they and I'm not a technology hater) they are not offer dedicated >>>> service and not isolated perfectly from each other processes. >>>> >>>> >>>> >>>> On Tue, Nov 10, 2015 at 11:56 AM, Gert Doering wrote: >>>>> Hi, >>>>> >>>>> On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote: >>>>>> >From my personal, informal assessment I advise against supporting VMs. I >>>>>> recommend a thorough assessment of the data quality, the costs and the >>>>>> effects on RIPE Atlas as a whole before diving into soloutioneering. >>>>> >>>>> From experience running a recursive DNS on a VM platform, I'd also speak >>>>> against supporting VMs. Unpredictable load elsewhere on the same host >>>>> can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't >>>>> be able to differenciate from "something on the path is broken/lossy". >>>>> >>>>> 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 >>>> >>>> >>>> >> >> >> -- Sincerely yours, Pavel Odintsov From v.bajpai at jacobs-university.de Tue Nov 10 11:45:40 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Tue, 10 Nov 2015 10:45:40 +0000 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> Message-ID: <3EC156C3-5CD6-406B-ABB9-C72AB71E54CC@jacobs-university.de> > On 10 Nov 2015, at 11:18, Stephan Wolf wrote: > > Sure, PROBES as an VM in e.g. overloaded environments are a problem. So > Probes on a VM = can result in some troubles in the existing Atlas model. To > make a "second class" probes I agree that this takes too much efforts. > > ANCHOR as an VM would really make sense. What do you think about this ? I think it simply shifts the problem from source to destination. The destination must also not be overloaded when responding to packets. Someone provisioning a UDM, may have no clue how overloaded the underlying hardware supporting the anchor VM was at the time of the measurement. In a recent IEPG presentation [1], Emile showed us how latencies over IPv4 and IPv6 compare using anchoring measurements. In the methodology, it was clearly stated how the measurements were performed using the 'same' source hardware (probes) and 'same' destination hardware (anchors). This adds confidence to the accuracy of the results. I suspect perhaps we risk losing these RIPE Atlas benefits with the VM approach. PS: Anchors can also be used as probes. [1] http://www.iepg.org/2015-11-01-ietf94/2015-10.iepg-v4v6.emileaben.pdf Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From gert at space.net Tue Nov 10 11:55:14 2015 From: gert at space.net (Gert Doering) Date: Tue, 10 Nov 2015 11:55:14 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> Message-ID: <20151110105514.GO89490@Space.Net> Hi, On Tue, Nov 10, 2015 at 11:18:37AM +0100, Stephan Wolf wrote: > ANCHOR as an VM would really make sense. > What do you think about this ? Even less so than a probe - as the anchor needs to provide reliable and robust measurements *and* responses to probes. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From woeber at cc.univie.ac.at Tue Nov 10 13:20:39 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Tue, 10 Nov 2015 13:20:39 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> Message-ID: <5641E117.8020402@cc.univie.ac.at> On 2015-11-10 11:18, Stephan Wolf wrote: > ANCHOR as an VM would really make sense. > What do you think about this ? I think this would really be a BAD idea! The anchors are meant to be more capable and more stable than the candy probes. Messing around with that concept should not be done, imho. > Just my 2 cents .-) ...same here :-) Wilfried PS: I myself do see the beauty of the idea to virtualize the (candy-)probes, but I have - already a while ago - been convinced that the data generated by them should *not* be mixed in with the data from those under full NCC control. And whether those VM probes should even be catalogued by the NCC is another open question. > Cheers, > Stephan From colinj at mx5.org.uk Tue Nov 10 13:36:41 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 10 Nov 2015 12:36:41 +0000 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <5641E117.8020402@cc.univie.ac.at> References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> <5641E117.8020402@cc.univie.ac.at> Message-ID: <1BA82457-C93A-4D4F-83E4-569B69AA7CA1@mx5.org.uk> > On 10 Nov 2015, at 12:20, Wilfried Woeber wrote: > > > On 2015-11-10 11:18, Stephan Wolf wrote: > >> ANCHOR as an VM would really make sense. >> What do you think about this ? > > I think this would really be a BAD idea! The anchors are meant to be more > capable and more stable than the candy probes. Messing around with that > concept should not be done, imho. > >> Just my 2 cents .-) > > ...same here :-) > > Wilfried > > PS: I myself do see the beauty of the idea to virtualize the (candy-)probes, > but I have - already a while ago - been convinced that the data generated > by them should *not* be mixed in with the data from those under full NCC > control. And whether those VM probes should even be catalogued by the NCC > is another open question. After having lived and still work in a Solaris physical metal land, I took onboard the virtual machine world for a webservice/emailservice. The virtual world is cheaper in long run. However does require a vm/ov image. I think it is important cloud as such as machines are monitored and I thought vm probe would for great for that Colin From jared at puck.nether.net Tue Nov 10 13:42:07 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 10 Nov 2015 07:42:07 -0500 Subject: [atlas] Sharing credits with colleagues In-Reply-To: <56409967.7000901@eunetworks.com> References: <563241A3.3080202@eunetworks.com> <56409141.1070501@ripe.net> <56409967.7000901@eunetworks.com> Message-ID: Or you can ask me for credits. I transfer credits to people who ask. My credit cup runneth over. - Jared > On Nov 9, 2015, at 8:02 AM, Oliver Haake wrote: > > Thank you Robert, that sounds awesome. > Keep up the good work. > > > Cheers, > Oliver > > > > > > On 09.11.2015 13:27, Robert Kisteleki wrote: >> On 2015-10-29 16:56, Oliver Haake wrote: >>> Hey there, >>> >>> I'm very curious if you guys have an ETA for the "Sharing credits with >>> colleagues" feature. >>> >>> Any ideas? >>> >>> >>> >>> Cheers, >>> Oliver >> >> Hello, >> >> This task is coming up shortly, so I expect that we can deliver it soon. At >> the moment we think it'll result in two functions: >> >> 1. Make "standing orders": automatically spread the excess amount of credits >> to other accounts if I have more than X, AND/OR >> 2. Let me make a measurement that will be billed to someone else, who >> authorised me before to do this >> >> These two will fit a lot of use cases with (we believe) a low amount of >> complexity. >> >> Cheers, >> Robert >> > > > -- > Oliver Haake | Tier3 Network Engineer | euNetworks > Theodor-Heuss-Allee 112 | 60486 Frankfurt/Main > +49 69 905 542 49 office > > F?r weitere Informationen ?ber euNetworks oder f?r Informationen ?ber > unsere Unternehmen, darunter euNetworks GmbH, besuchen Sie bitte unsere > Webseite www.eunetworks.de. > > Diese E-Mail und oder Anh?nge k?nnen vertrauliche und/oder gesetzlich > privilegierte Information enthalten. Wenn Sie nicht der beabsichtigte > Empf?nger sind, l?schen Sie bitte die E-Mail, ohne sie zu lesen, und > benachrichtigen Sie den Absender. > euNetworks GmbH Gesch?ftsf?hrer: Joachim Piroth Sueleyman Karaman Myriam > Buchheister Amtsgericht Frankfurt am Main HRB 88224 Steuernummer > 04523251638 Umsatzsteuer ID: DE 201 739 716 From pavel.odintsov at gmail.com Tue Nov 10 13:45:02 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 10 Nov 2015 15:45:02 +0300 Subject: [atlas] Feature request for IP record route feature in RIPE Atlas In-Reply-To: <56409B5B.3000907@ripe.net> References: <56409B5B.3000907@ripe.net> Message-ID: Thanks! I will try to run it on CentOS VirtualBox vm. On Mon, Nov 9, 2015 at 4:10 PM, Philip Homburg wrote: > On 2015/11/09 10:04 , Pavel Odintsov wrote: >> But RIPE Atlas offer really huge coverage over the World and we could >> reach really any host with <7 hops. But we haven't this feature in >> RIPE Atlas. >> >> Finally with this feature we could build full adjacently map over all the World. >> >> I have checked implementation details here >> https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-code >> >> Looks like we need to build separate libevent based toolkit for this >> task or add this feature to ping tool. But unfortunately I could not >> find any docs about deploy of RIPE source code for development. Could >> you share some information? > > Hi, > > I use a vm running debian wheezy for development. The anchors run CentOS > 6. So the code should run there. If it doesn't run on other Linux > versions then please let me know and I'll see what I can do. > > The INSTALL file in the source code has specific instructions on how to > build. > > I would advice against just writing some code and asking it to be > merged. Instead coordinate with me what you want to change. > > Philip > -- Sincerely yours, Pavel Odintsov From oliver.haake at eunetworks.com Tue Nov 10 13:46:20 2015 From: oliver.haake at eunetworks.com (Oliver Haake) Date: Tue, 10 Nov 2015 13:46:20 +0100 Subject: [atlas] Sharing credits with colleagues In-Reply-To: References: <563241A3.3080202@eunetworks.com> <56409141.1070501@ripe.net> <56409967.7000901@eunetworks.com> Message-ID: <5641E71C.90109@eunetworks.com> My colleagues can also ask me for credits, but the point is, that I don't want to do this manually. So the idea that Robert presented in his reply sounds quite good. On 10.11.2015 13:42, Jared Mauch wrote: > Or you can ask me for credits. I transfer credits to people who ask. My credit cup runneth over. > > - Jared > >> On Nov 9, 2015, at 8:02 AM, Oliver Haake wrote: >> >> Thank you Robert, that sounds awesome. >> Keep up the good work. >> >> >> Cheers, >> Oliver >> >> >> >> >> >> On 09.11.2015 13:27, Robert Kisteleki wrote: >>> On 2015-10-29 16:56, Oliver Haake wrote: >>>> Hey there, >>>> >>>> I'm very curious if you guys have an ETA for the "Sharing credits with >>>> colleagues" feature. >>>> >>>> Any ideas? >>>> >>>> >>>> >>>> Cheers, >>>> Oliver >>> >>> Hello, >>> >>> This task is coming up shortly, so I expect that we can deliver it soon. At >>> the moment we think it'll result in two functions: >>> >>> 1. Make "standing orders": automatically spread the excess amount of credits >>> to other accounts if I have more than X, AND/OR >>> 2. Let me make a measurement that will be billed to someone else, who >>> authorised me before to do this >>> >>> These two will fit a lot of use cases with (we believe) a low amount of >>> complexity. >>> >>> Cheers, >>> Robert >>> >> >> >> -- >> Oliver Haake | Tier3 Network Engineer | euNetworks >> Theodor-Heuss-Allee 112 | 60486 Frankfurt/Main >> +49 69 905 542 49 office >> >> F?r weitere Informationen ?ber euNetworks oder f?r Informationen ?ber >> unsere Unternehmen, darunter euNetworks GmbH, besuchen Sie bitte unsere >> Webseite www.eunetworks.de. >> >> Diese E-Mail und oder Anh?nge k?nnen vertrauliche und/oder gesetzlich >> privilegierte Information enthalten. Wenn Sie nicht der beabsichtigte >> Empf?nger sind, l?schen Sie bitte die E-Mail, ohne sie zu lesen, und >> benachrichtigen Sie den Absender. >> euNetworks GmbH Gesch?ftsf?hrer: Joachim Piroth Sueleyman Karaman Myriam >> Buchheister Amtsgericht Frankfurt am Main HRB 88224 Steuernummer >> 04523251638 Umsatzsteuer ID: DE 201 739 716 > -- Oliver Haake | Tier3 Network Engineer | euNetworks Theodor-Heuss-Allee 112 | 60486 Frankfurt/Main +49 69 905 542 49 office F?r weitere Informationen ?ber euNetworks oder f?r Informationen ?ber unsere Unternehmen, darunter euNetworks GmbH, besuchen Sie bitte unsere Webseite www.eunetworks.de. Diese E-Mail und oder Anh?nge k?nnen vertrauliche und/oder gesetzlich privilegierte Information enthalten. Wenn Sie nicht der beabsichtigte Empf?nger sind, l?schen Sie bitte die E-Mail, ohne sie zu lesen, und benachrichtigen Sie den Absender. euNetworks GmbH Gesch?ftsf?hrer: Joachim Piroth Sueleyman Karaman Myriam Buchheister Amtsgericht Frankfurt am Main HRB 88224 Steuernummer 04523251638 Umsatzsteuer ID: DE 201 739 716 From philip.homburg at ripe.net Tue Nov 10 13:50:41 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 10 Nov 2015 13:50:41 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <1BA82457-C93A-4D4F-83E4-569B69AA7CA1@mx5.org.uk> References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> <5641E117.8020402@cc.univie.ac.at> <1BA82457-C93A-4D4F-83E4-569B69AA7CA1@mx5.org.uk> Message-ID: <5641E821.9090408@ripe.net> On 2015/11/10 13:36 , Colin Johnston wrote: > After having lived and still work in a Solaris physical metal land, I took onboard the virtual machine world for a webservice/emailservice. > The virtual world is cheaper in long run. > However does require a vm/ov image. > > I think it is important cloud as such as machines are monitored and I thought vm probe would for great for that One way of looking at it, are the people who want a VM willing to guarantee that the VM performs better than the current Soekris boxes we use for anchors? And is there is way of monitoring that they live up to their promises. Somehow shipping hardware around the world sounds rather old fashioned. But sometimes old fashioned methods works best. For ordinary probes, we have absolutely no control over the network. Probe hosts don't have to guarantee anything. So I wonder if blackbox testing would even allow distinguishing between an overloaded VM and a probe on a very bad consumer line. Philip From colinj at mx5.org.uk Tue Nov 10 14:01:25 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 10 Nov 2015 13:01:25 +0000 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <5641E821.9090408@ripe.net> References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> <5641E117.8020402@cc.univie.ac.at> <1BA82457-C93A-4D4F-83E4-569B69AA7CA1@mx5.org.uk> <5641E821.9090408@ripe.net> Message-ID: reply inline > On 10 Nov 2015, at 12:50, Philip Homburg wrote: > > On 2015/11/10 13:36 , Colin Johnston wrote: >> After having lived and still work in a Solaris physical metal land, I took onboard the virtual machine world for a webservice/emailservice. >> The virtual world is cheaper in long run. >> However does require a vm/ov image. >> >> I think it is important cloud as such as machines are monitored and I thought vm probe would for great for that > > One way of looking at it, are the people who want a VM willing to > guarantee that the VM performs better than the current Soekris boxes we > use for anchors? And is there is way of monitoring that they live up to > their promises. > A well managed vm is monitored/firewalled for traffic and process load monitored to work within predefined boundaries and alerting in place if issues which I thought Ripe Atlas would be good monitoring addition to. > Somehow shipping hardware around the world sounds rather old fashioned. > But sometimes old fashioned methods works best. > > For ordinary probes, we have absolutely no control over the network. > Probe hosts don't have to guarantee anything. So I wonder if blackbox > testing would even allow distinguishing between an overloaded VM and a > probe on a very bad consumer line. > > Philip > > > Colin From nick at inex.ie Tue Nov 10 14:05:16 2015 From: nick at inex.ie (Nick Hilliard) Date: Tue, 10 Nov 2015 13:05:16 +0000 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> <5641E117.8020402@cc.univie.ac.at> <1BA82457-C93A-4D4F-83E4-569B69AA7CA1@mx5.org.uk> <5641E821.9090408@ripe.net> Message-ID: <5641EB8C.9060806@inex.ie> On 10/11/2015 13:01, Colin Johnston wrote: > A well managed vm this is the key point. the ripe atlas people have no control over the hypervisor management, which is important from a measurement point of view. Nick From gert at space.net Tue Nov 10 14:05:44 2015 From: gert at space.net (Gert Doering) Date: Tue, 10 Nov 2015 14:05:44 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <5641E821.9090408@ripe.net> References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> <5641E117.8020402@cc.univie.ac.at> <1BA82457-C93A-4D4F-83E4-569B69AA7CA1@mx5.org.uk> <5641E821.9090408@ripe.net> Message-ID: <20151110130544.GR89490@Space.Net> Hi, On Tue, Nov 10, 2015 at 01:50:41PM +0100, Philip Homburg wrote: > For ordinary probes, we have absolutely no control over the network. > Probe hosts don't have to guarantee anything. So I wonder if blackbox > testing would even allow distinguishing between an overloaded VM and a > probe on a very bad consumer line. But isn't this a significantly different statement? "Here's a bad line" is something you can only assess if you know that your probe is sane. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From philip.homburg at ripe.net Tue Nov 10 14:05:52 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 10 Nov 2015 14:05:52 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> <5641E117.8020402@cc.univie.ac.at> <1BA82457-C93A-4D4F-83E4-569B69AA7CA1@mx5.org.uk> <5641E821.9090408@ripe.net> Message-ID: <5641EBB0.9090209@ripe.net> On 2015/11/10 14:01 , Colin Johnston wrote: >> One way of looking at it, are the people who want a VM willing to >> guarantee that the VM performs better than the current Soekris boxes we >> use for anchors? And is there is way of monitoring that they live up to >> their promises. >> > A well managed vm is monitored/firewalled for traffic and process load monitored to work within predefined boundaries and alerting in place if issues which I thought Ripe Atlas would be good monitoring addition to. I was thinking of monitoring within Atlas. I.e. if the Atlas system can say, this VM is operating within specs, you can trust the results. From philip.homburg at ripe.net Tue Nov 10 14:11:24 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 10 Nov 2015 14:11:24 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <20151110130544.GR89490@Space.Net> References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> <7B44FAEF-CBFE-4354-BA03-E10376E052AE@jacobs-university.de> <5641E117.8020402@cc.univie.ac.at> <1BA82457-C93A-4D4F-83E4-569B69AA7CA1@mx5.org.uk> <5641E821.9090408@ripe.net> <20151110130544.GR89490@Space.Net> Message-ID: <5641ECFC.3070902@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015/11/10 14:05 , Gert Doering wrote: > Hi, > > On Tue, Nov 10, 2015 at 01:50:41PM +0100, Philip Homburg wrote: >> For ordinary probes, we have absolutely no control over the >> network. Probe hosts don't have to guarantee anything. So I >> wonder if blackbox testing would even allow distinguishing >> between an overloaded VM and a probe on a very bad consumer >> line. > > But isn't this a significantly different statement? "Here's a bad > line" is something you can only assess if you know that your probe > is sane. True. I assumed measuring a remote target. If you want to say something about the probe's access network then of course that doesn't work. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWQez8AAoJEPr6076EDopyRikP/2Kkqk/9OCwR8EnavCuuHr/Z LaNqNnRdASG8QkId5fA5kkTjWYmf76HTL5gxogutzgSBGlvnbKMB5Jy2z52JE5Gq F4qyzgHv1vYO/NX1NGf5k3YKIzDoaxXn5MoYrtq3priYhuZOXgC5SAIrqvupM2TA QNuORSeP7BtwcdWYv+DMBVWm0uG8Ugirf/vFItLvjKoKELtYnpHx3QSqWrc0PFWi 9WF0tfeTWncRV/J5yx7+0iPAT17SxxcIcQRtZ4Xe3M58ZE8o6CxHl7aWLMWOLpEK FpCZcaD8JhTK8fW3ve0u10f4qD2K4n8N2AMNTPFD0UWAkR9b5bhzm8p2MciwG74+ BIMGVtXBXYke256Ut4Bs1AE6FraZvsyoAlOjDJ11i2jpXLxCe06I6YocbxIwCpAo NbCsj5qMDRarElCrOy6PkIdXttPK9yhMSdca22Zxy7M7iXkGNDJqx4SjGTwJ4+OU j1lVdcnr12BM1KgJfwEuYkaevfCpMpxHxHHQhr6O+r1aewYAoNk4KXOr8n1h8BFf 5wgwY97K+xnNzJYkCb+Gaqr271RqB4SzOCKdJPaNUnh6dtb5OIiVlTkEI1Ra1ZH+ zzoOAAsllML90UkEjAogjtwva5niJ8WgMniVeMgfNM5yf0/mX0rv9qyXeckAKLzp D0F+ICXXluKFQSY/U2U6 =LPos -----END PGP SIGNATURE----- From budiwijaya at ipv6.or.id Tue Nov 10 15:01:48 2015 From: budiwijaya at ipv6.or.id (Budiwijaya) Date: Tue, 10 Nov 2015 21:01:48 +0700 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: References: <56409500.4050104@ripe.net> <5641ABBD.1050504@ripe.net> <20151110085640.GN89490@Space.Net> <5641BAB0.8000104@ripe.net> <5641C758.1020405@ripe.net> Message-ID: So, is this mean that we can build our soekris hardware by our self? (we don't have to import any soekris from outside). If this true, then it will be an opportunity for any network that want to host an anchor but limited by import issues. On Tue, Nov 10, 2015 at 5:39 PM, Pavel Odintsov wrote: > Hello! > > Maybe we could fix import issues with some vendor? > > We have really huge and good shop of network hardware here: > http://shop.nag.ru If they could offer Soekris platform could be fine. > > On Tue, Nov 10, 2015 at 1:30 PM, Daniel Karrenberg > wrote: >> Pavel, >> >> it appears that my information is out-dated. You are right one needs to >> import them these days. I realise that this is awkward and expensive, >> but it appears to be possible. >> >> Maybe rather than wasting time on VMs we should consider a new type of >> anchor which is more readily available everywhere than the Soekris. >> Personally I would go in the direction of Ubiquity Edge Routers or >> Mikrotik routers which I know for sure are available in Russia and also >> widely available around the world. Do you have suggestions? >> >> Daniel >> >> On 10.11.15 10:49 , Pavel Odintsov wrote: >>> Hello! >>> >>> Awesome! Could you share where we could bought it? I will share this >>> information with local community. >>> >>> On Tue, Nov 10, 2015 at 12:36 PM, Daniel Karrenberg >>> wrote: >>>> At this time are 485 connected probes and two connected anchors in >>>> Russia. As far as I know Soekris boxes can be bought in Russia. >>>> >>>> Daniel >>>> >>>> On 10.11.15 10:07 , Pavel Odintsov wrote: >>>>> Hello, Community! >>>>> >>>>> I like idea about VM based Anchor's. >>>>> >>>>> For example in Russia we have so much companies who really want to >>>>> host RIPE Anchor hosting but it's really hard due to so much >>>>> bureaucracy for computer hardware import. It's really sophisticated >>>>> and long task. >>>>> >>>>> VM based Anchors could help in this case. But they should be >>>>> designated as "second-rate monitoring". So somebody who interested in >>>>> monitoring over non-so-reliable-vm's could use they. Actually, this >>>>> VM's should "mine" less points than full-size-Anchor. >>>>> >>>>> We could select some unified way to run VM's. I prefer VmWare because it's: >>>>> 1) Free >>>>> 2) Simple to deploy >>>>> 3) Mature >>>>> 4) Very simple VM deploy >>>>> >>>>> Xen, KVM are pretty too but they are based on non standard linux >>>>> distributions and it could be a configuration issue. OpenVZ/Docker and >>>>> LXC should be avoided because (actually I have so much experience with >>>>> they and I'm not a technology hater) they are not offer dedicated >>>>> service and not isolated perfectly from each other processes. >>>>> >>>>> >>>>> >>>>> On Tue, Nov 10, 2015 at 11:56 AM, Gert Doering wrote: >>>>>> Hi, >>>>>> >>>>>> On Tue, Nov 10, 2015 at 09:33:01AM +0100, Daniel Karrenberg wrote: >>>>>>> >From my personal, informal assessment I advise against supporting VMs. I >>>>>>> recommend a thorough assessment of the data quality, the costs and the >>>>>>> effects on RIPE Atlas as a whole before diving into soloutioneering. >>>>>> >>>>>> From experience running a recursive DNS on a VM platform, I'd also speak >>>>>> against supporting VMs. Unpredictable load elsewhere on the same host >>>>>> can (and does) lead to UDP/ICMP packet loss, which the "Atlas VM" won't >>>>>> be able to differenciate from "something on the path is broken/lossy". >>>>>> >>>>>> 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 >>>>> >>>>> >>>>> >>> >>> >>> > > > > -- > Sincerely yours, Pavel Odintsov > From mgalante at ripe.net Tue Nov 10 16:40:01 2015 From: mgalante at ripe.net (Michela Galante) Date: Tue, 10 Nov 2015 16:40:01 +0100 Subject: [atlas] RIPE Atlas anchor self assembly Message-ID: <4B54D1C0-FE14-4808-B9D4-91C1BC07A348@ripe.net> Hi everyone, Some people on this list have been asking about the possibility of purchasing hardware for a RIPE Atlas anchor by themselves and assembling it. This is indeed possible. However we do not recommend it because if the assembled hardware is not exactly to our specifications, we will not be able to use it as an anchor. If you still wish to assemble an anchor by yourself, you can find step by step instructions here: https://atlas.ripe.net/docs/anchor-installation/ Please, note that you do need more than the Soekris box. The anchor consists of: ? Soekris Net6501-70 board ? 1U 19-inch rack-mounted case ? Intel SSD 525 or 530 series 240GB mSATA SSD More requirements are listed here: https://atlas.ripe.net/get-involved/become-an-anchor-host/ If you have more questions about anchors, please email to atlas at ripe.net and we will be very happy to help you. Best regards, Michela Galante Measurements Community Building RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From colinj at mx5.org.uk Tue Nov 10 16:56:36 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 10 Nov 2015 15:56:36 +0000 Subject: [atlas] RIPE Atlas anchor self assembly In-Reply-To: <4B54D1C0-FE14-4808-B9D4-91C1BC07A348@ripe.net> References: <4B54D1C0-FE14-4808-B9D4-91C1BC07A348@ripe.net> Message-ID: <86F244FF-6BB3-41A0-81D5-31E6093C3B17@mx5.org.uk> Can we have link to image so we can can convert to a VM image for hosting via virtual instead :) maybe useful cost saving :) Colin > On 10 Nov 2015, at 15:40, Michela Galante wrote: > > Hi everyone, > > Some people on this list have been asking about the possibility of purchasing hardware for a RIPE Atlas anchor by themselves and assembling it. > > This is indeed possible. However we do not recommend it because if the assembled hardware is not exactly to our specifications, we will not be able to use it as an anchor. > > If you still wish to assemble an anchor by yourself, you can find step by step instructions here: > https://atlas.ripe.net/docs/anchor-installation/ > > Please, note that you do need more than the Soekris box. > The anchor consists of: > > ? Soekris Net6501-70 board > ? 1U 19-inch rack-mounted case > ? Intel SSD 525 or 530 series 240GB mSATA SSD > > More requirements are listed here: https://atlas.ripe.net/get-involved/become-an-anchor-host/ > > If you have more questions about anchors, please email to atlas at ripe.net and we will be very happy to help you. > > Best regards, > Michela Galante > Measurements Community Building > RIPE NCC From philip.homburg at ripe.net Tue Nov 10 17:01:23 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 10 Nov 2015 17:01:23 +0100 Subject: [atlas] RIPE Atlas anchor self assembly In-Reply-To: <86F244FF-6BB3-41A0-81D5-31E6093C3B17@mx5.org.uk> References: <4B54D1C0-FE14-4808-B9D4-91C1BC07A348@ripe.net> <86F244FF-6BB3-41A0-81D5-31E6093C3B17@mx5.org.uk> Message-ID: <564214D3.9020301@ripe.net> On 2015/11/10 16:56 , Colin Johnston wrote: > Can we have link to image so we can can convert to a VM image for hosting via virtual instead :) > > maybe useful cost saving :) The image contains not much more than CentOS, a compiled version of the Atlas source code (which is published) and a bunch of not to complex shell scripts (which so far we don't publish) However, the magic dust to make it an anchor is not in the image :-) Philip From d.baeza at tvt-datos.es Tue Nov 10 17:31:19 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Tue, 10 Nov 2015 17:31:19 +0100 Subject: [atlas] RIPE Atlas anchor self assembly In-Reply-To: <564214D3.9020301@ripe.net> References: <4B54D1C0-FE14-4808-B9D4-91C1BC07A348@ripe.net> <86F244FF-6BB3-41A0-81D5-31E6093C3B17@mx5.org.uk> <564214D3.9020301@ripe.net> Message-ID: <56421BD7.4090302@tvt-datos.es> So... if we give you access to a CentOS VM, you can make it Anchor? :) El 10/11/2015 a las 17:01, Philip Homburg escribi?: > On 2015/11/10 16:56 , Colin Johnston wrote: >> Can we have link to image so we can can convert to a VM image for hosting via virtual instead :) >> >> maybe useful cost saving :) > > The image contains not much more than CentOS, a compiled version of the > Atlas source code (which is published) and a bunch of not to complex > shell scripts (which so far we don't publish) > > However, the magic dust to make it an anchor is not in the image :-) > > Philip > > From daniel.karrenberg at ripe.net Tue Nov 10 17:40:24 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Tue, 10 Nov 2015 17:40:24 +0100 Subject: [atlas] RIPE Atlas anchor self assembly In-Reply-To: <56421BD7.4090302@tvt-datos.es> References: <4B54D1C0-FE14-4808-B9D4-91C1BC07A348@ripe.net> <86F244FF-6BB3-41A0-81D5-31E6093C3B17@mx5.org.uk> <564214D3.9020301@ripe.net> <56421BD7.4090302@tvt-datos.es> Message-ID: <56421DF8.4040406@ripe.net> No, see the other discussion. On 10.11.15 17:31 , Daniel Baeza (Red y Sistemas TVT) wrote: > So... if we give you access to a CentOS VM, you can make it Anchor? :) > > El 10/11/2015 a las 17:01, Philip Homburg escribi?: >> On 2015/11/10 16:56 , Colin Johnston wrote: >>> Can we have link to image so we can can convert to a VM image for >>> hosting via virtual instead :) >>> >>> maybe useful cost saving :) >> >> The image contains not much more than CentOS, a compiled version of the >> Atlas source code (which is published) and a bunch of not to complex >> shell scripts (which so far we don't publish) >> >> However, the magic dust to make it an anchor is not in the image :-) >> >> Philip >> >> > > From bortzmeyer at nic.fr Wed Nov 11 16:32:55 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 11 Nov 2015 16:32:55 +0100 Subject: [atlas] Any way to select the probes from upstream AS (not origin AS)? Message-ID: <20151111153254.GA2080@sources.org> Is there an easy way to select probes, not on the origin AS, but on an AS upstream? Example: probe 23865, IP prefix announced by AS 56339 which currently has only one provider, AS 16080. Currently, Atlas tells me there are no probes in AS 16080... From robert at ripe.net Wed Nov 11 16:43:49 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 11 Nov 2015 16:43:49 +0100 Subject: [atlas] Any way to select the probes from upstream AS (not origin AS)? In-Reply-To: <20151111153254.GA2080@sources.org> References: <20151111153254.GA2080@sources.org> Message-ID: <56436235.5080101@ripe.net> On 2015-11-11 16:32, Stephane Bortzmeyer wrote: > Is there an easy way to select probes, not on the origin AS, but on an > AS upstream? Example: probe 23865, IP prefix announced by AS 56339 > which currently has only one provider, AS 16080. Currently, Atlas > tells me there are no probes in AS 16080... Hi, No, we don't have direct support for this. I guess one could download latest traceroute results for a (random) built-in measurement, map IPs to ASNs and use that -- but I have to admit it's not easy. Regards, Robert From bortzmeyer at nic.fr Wed Nov 11 16:45:49 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 11 Nov 2015 16:45:49 +0100 Subject: [atlas] VM probes In-Reply-To: <860CB300-1143-474A-BF1A-08EEE9BFA4B1@mx5.org.uk> References: <56409500.4050104@ripe.net> <860CB300-1143-474A-BF1A-08EEE9BFA4B1@mx5.org.uk> Message-ID: <20151111154549.GB4193@sources.org> On Mon, Nov 09, 2015 at 12:49:19PM +0000, Colin Johnston wrote a message of 30 lines which said: > one vote for vmware virtualisation Strong -1 against any proprietary technology. Free software or nothing. (But, like most people here, I'm not interested in VM probes and even less in VM anchors.) From bortzmeyer at nic.fr Wed Nov 11 16:47:02 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 11 Nov 2015 16:47:02 +0100 Subject: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas) In-Reply-To: <5641BF90.8000903@sneuner.org> References: <56409500.4050104@ripe.net> <5641BF90.8000903@sneuner.org> Message-ID: <20151111154702.GC4193@sources.org> On Tue, Nov 10, 2015 at 10:57:36AM +0100, Sebastian Neuner wrote a message of 55 lines which said: > It's important for the Atlas measurements to be comparable, which > can be a problem if you just run a virtual probe on someones > hardware in a datacenter somewhere. Or to put it simple: we want to > measure networks, not virtualization hardware. [Full agreement here] > Also, since people are using the results for scientific purposes, it > should at least be possible to differentiate between results of > hardware and software probes. I assume that, should it be done, we would have system tags to differentiate them? From bortzmeyer at nic.fr Wed Nov 11 17:03:15 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 11 Nov 2015 17:03:15 +0100 Subject: [atlas] Any way to select the probes from upstream AS (not origin AS)? In-Reply-To: <56436235.5080101@ripe.net> References: <20151111153254.GA2080@sources.org> <56436235.5080101@ripe.net> Message-ID: <20151111160315.GA6897@sources.org> On Wed, Nov 11, 2015 at 04:43:49PM +0100, Robert Kisteleki wrote a message of 14 lines which said: > No, we don't have direct support for this. I guess one could > download latest traceroute results for a (random) built-in > measurement, map IPs to ASNs and use that -- but I have to admit > it's not easy. I understand. Also, a probe has one origin AS but may have several upstream AS and you don't know which one will be used when the probe fires a packet to the target. From bortzmeyer at nic.fr Wed Nov 11 17:36:28 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 11 Nov 2015 17:36:28 +0100 Subject: [atlas] [Request] System tags for DNS resolution Message-ID: <20151111163628.GA5532@sources.org> [Is there a better way to record enhancement requests for Atlas? Atlas has no public issue tracker, if I'm correct?] It would be cool to have system (automatic) tags for DNS resolution because some probes are using broken DNS resolvers. For instance, system-dns-works (modeled on IPv6's system tag) would be fine. Or may be system-dns-resolver-works (longer but more accurate). For instance, probes 16659, 17072, 17620, 17854 use a resolver which yields a REFUSED for any request and probe 19948, 20065 one with systematic SERVFAIL. [Is the maintainer of the probe automatically notified when there is such an issue?] From v.bajpai at jacobs-university.de Thu Nov 12 10:30:58 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Thu, 12 Nov 2015 09:30:58 +0000 Subject: [atlas] [Request] System tags for DNS resolution In-Reply-To: <20151111163628.GA5532@sources.org> References: <20151111163628.GA5532@sources.org> Message-ID: > On 11 Nov 2015, at 17:36, Stephane Bortzmeyer wrote: > > [Is there a better way to record enhancement requests for Atlas? Atlas > has no public issue tracker, if I'm correct?] > > It would be cool to have system (automatic) tags for DNS resolution > because some probes are using broken DNS resolvers. For instance, > > system-dns-works (modeled on IPv6's system tag) would be fine. Or may > be system-dns-resolver-works (longer but more accurate). > > For instance, probes 16659, 17072, 17620, 17854 use a resolver which > yields a REFUSED for any request and probe 19948, 20065 one with > systematic SERVFAIL. I would like to support this request. I will use it. Additionally would also be nice if we can identify whether the used resolver is a local / open resolver. Latency measurements that rely on DNS resolution may get affected depending on what is used. Perhaps, easiest would be to just report what resolver is used and let the identification be left for the data analysis phase. > [Is the maintainer of the probe automatically notified when there is > such an issue?] Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From camin at ripe.net Thu Nov 12 10:41:03 2015 From: camin at ripe.net (Chris Amin) Date: Thu, 12 Nov 2015 10:41:03 +0100 Subject: [atlas] [Request] System tags for DNS resolution In-Reply-To: <20151111163628.GA5532@sources.org> References: <20151111163628.GA5532@sources.org> Message-ID: <56445EAF.5020408@ripe.net> Hi Stephane, On 11/11/2015 17:36, Stephane Bortzmeyer wrote: > [Is there a better way to record enhancement requests for Atlas? Atlas > has no public issue tracker, if I'm correct?] You can also send requests to atlas at ripe.net, where they will be automatically added to our issue queue. There's nothing intrinsically wrong with sending things to the list though, especially because it allows other users to chime in and say that they've noticed similar things before/they have an explanation/a workaround/etc. > It would be cool to have system (automatic) tags for DNS resolution > because some probes are using broken DNS resolvers. For instance, > > system-dns-works (modeled on IPv6's system tag) would be fine. Or may > be system-dns-resolver-works (longer but more accurate). > > For instance, probes 16659, 17072, 17620, 17854 use a resolver which > yields a REFUSED for any request and probe 19948, 20065 one with > systematic SERVFAIL. You may have noticed that we apply "system-resolves-a[aaa]-correctly" to probes. This happens when we find that at least one of their DNS resolvers correctly resolves one of a few specific records at least partially over a 4 hour period. We decided to be specific and shy away from claims like "DNS works" because that could be considered a rather strong claim. The above probes are mostly tagged as "resolves-a[aaa]-correctly" because they managed to resolve certain A records (e.g. MSM ID 1698856). Can you provide the measurement ID(s) where you see the REFUSED and SERVFAIL responses? > [Is the maintainer of the probe automatically notified when there is > such an issue?] If there is a tagging change, then we send an in-site RIPE Atlas message to the user. We don't currently provide the option of emailing users on such changes, but it's something that we would consider if there is support for such an idea. Regards, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From BECHA at ripe.net Thu Nov 12 11:58:08 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 12 Nov 2015 11:58:08 +0100 Subject: [atlas] [Request] System tags for DNS resolution In-Reply-To: <20151111163628.GA5532@sources.org> References: <20151111163628.GA5532@sources.org> Message-ID: <564470C0.4050701@ripe.net> Hi Stephane, all, On 11-nov.-15 17:36, Stephane Bortzmeyer wrote: > [Is there a better way to record enhancement requests for Atlas? Atlas > has no public issue tracker, if I'm correct?] You are correct, to some extent -- there is a manual processing involved in the middle ;-) It's good that you ask for features on the list, where people can comment on your feature request & add their own use cases (just like Vaibhav just did); then I collect them, we discuss them internally & prioritize them, and they end up on the roadmap: https://atlas.ripe.net/docs/roadmap/ (notice the new URL & new formatting - we are in the process of migrating the roadmap from the old URL to the new one...) > [Is the maintainer of the probe automatically notified when there is > such an issue?] There is something similar already on the roadmap: "Provide additional information to the probe owner about the probe: After analysis of measurements, results will be added to a comments page for the specified probe. This helps the hosts to identify issues and fix them." I will add your additional request to this one. Keep them coming :) Regards, Vesna and thanks for tagging it with [Request] -- good practice :) From bortzmeyer at nic.fr Thu Nov 12 21:45:11 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 12 Nov 2015 21:45:11 +0100 Subject: [atlas] [Request] System tags for DNS resolution In-Reply-To: <56445EAF.5020408@ripe.net> References: <20151111163628.GA5532@sources.org> <56445EAF.5020408@ripe.net> Message-ID: <20151112204511.GA27036@sources.org> On Thu, Nov 12, 2015 at 10:41:03AM +0100, Chris Amin wrote a message of 75 lines which said: > > For instance, probes 16659, 17072, 17620, 17854 use a resolver > > which yields a REFUSED for any request and probe 19948, 20065 one > > with systematic SERVFAIL. ... > The above probes are mostly tagged as "resolves-a[aaa]-correctly" > because they managed to resolve certain A records (e.g. MSM ID > 1698856). Can you provide the measurement ID(s) where you see the > REFUSED and SERVFAIL responses? Probes 19948, 20065 now seems OK. But 16659, 17072, 17620, 17854 still return REFUSED: measurements #2928193 and #2928199. From yang.yu.list at gmail.com Fri Nov 13 07:01:38 2015 From: yang.yu.list at gmail.com (Yang Yu) Date: Fri, 13 Nov 2015 00:01:38 -0600 Subject: [atlas] edst 193.0.0.228 in traceroute results Message-ID: Hello, In https://atlas.ripe.net/measurements/2928258, I did a UDP traceroute. "edst":"193.0.0.228" from first hop and second hop somehow showed up in the results after the last hop that responded to traceroute, which should have been a reply to buil-in measurement to tt01.ripe.net. And under maps tab the result is presented with the first 2 hops showing up after several non-responding hops. Is this a bug? I actually see it happening quite often in atlas traceroute results with firmware > 4680. Another example is https://atlas.ripe.net/measurements/2928262 >>> https://atlas.ripe.net/docs/bugs/ 2015-03-04 Before firmware 4680, traceroute could experience interference from other measurements. In general, periodic traceroutes did not interfere with other periodic traceroutes, but could experience interference from one-off traceroutes. Typically, this interference will show up in the 'edst' field. This problem was fixed in 4680. Thanks. Yang From yang.yu.list at gmail.com Fri Nov 13 07:10:31 2015 From: yang.yu.list at gmail.com (Yang Yu) Date: Fri, 13 Nov 2015 00:10:31 -0600 Subject: [atlas] Architecture and firmware version filter in probe selection Message-ID: It would be nice to be able to set architecture and firmware version criteria when selecting probes, making the results more consistent and avoid unnecessary measurements in certain cases. Yang From robert at ripe.net Fri Nov 13 10:34:23 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 13 Nov 2015 10:34:23 +0100 Subject: [atlas] New on RIPE Labs: RIPE Atlas WiFi Measurements In-Reply-To: <5645ADDE.2010504@ripe.net> References: <5645ADDE.2010504@ripe.net> Message-ID: <5645AE9F.8010908@ripe.net> Dear colleagues, We're thinking about implementing WiFi measurements in RIPE Atlas, and we want to know what you think. There are several different ways we could do this - find out more on RIPE Labs and then take our poll to make your voice heard! https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-wifi-measurements Kind regards, Mirjam Kuehne & Robert Kisteleki RIPE NCC From colinj at mx5.org.uk Fri Nov 13 10:50:25 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Fri, 13 Nov 2015 09:50:25 +0000 Subject: [atlas] New on RIPE Labs: RIPE Atlas WiFi Measurements In-Reply-To: <5645AE9F.8010908@ripe.net> References: <5645ADDE.2010504@ripe.net> <5645AE9F.8010908@ripe.net> Message-ID: done survey If a (vm image solution was chosen as well as hardware) then different types of network support could be offered depending on the physical hardware of the virtual host Colin > On 13 Nov 2015, at 09:34, Robert Kisteleki wrote: > > > Dear colleagues, > > We're thinking about implementing WiFi measurements in RIPE Atlas, and we > want to know what you think. There are several different ways we could do > this - find out more on RIPE Labs and then take our poll to make your voice > heard! > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-wifi-measurements > > Kind regards, > Mirjam Kuehne & Robert Kisteleki > RIPE NCC > > From yueli.cnfr at gmail.com Fri Nov 13 15:52:43 2015 From: yueli.cnfr at gmail.com (Yue LI) Date: Fri, 13 Nov 2015 15:52:43 +0100 Subject: [atlas] Feature request for Traceroute in RIPE Atlas Message-ID: Dear all, So far, the Atlas traceroute is such that if there are 5 consecutive hops with only timeouts (denoted by a star "*"), traceroute will directly try hop 255 and then stop the measurement, which means that the number of total hops can not be obtained. An example can be found: https://atlas.ripe.net/measurements/2841001/#!probes (the probe #22341) Unfortunately, the number of hops is so important to be used as a metric to evaluate the performance of a new protocol. Thus, I propose to add a configuration option for the number of hops after which traceroute decides to call it quits. I wonder whether there are somebody else are also interested in this new feature please? Best regards, Yue -- Yue LI PhD student, Telecom ParisTech Tel: +33 (0)661091840 E-mail: yueli.cnfr at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Fri Nov 13 19:02:48 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 13 Nov 2015 20:02:48 +0200 Subject: [atlas] Architecture and firmware version filter in probe selection In-Reply-To: References: Message-ID: <564625C8.8060602@ripe.net> On 2015-11-13 8:10, Yang Yu wrote: > It would be nice to be able to set architecture and firmware version > criteria when selecting probes, making the results more consistent and > avoid unnecessary measurements in certain cases. > > Yang Hello, The architecture is already available as a tag that you can use (system-v[123] and system-anchor). The firmware version is usually the latest except for the duration when we're in the process of deploying a new version, so tagging probes with this would only have limited benefits. Regards, Robert From camin at ripe.net Sun Nov 15 08:32:09 2015 From: camin at ripe.net (Chris Amin) Date: Sun, 15 Nov 2015 09:32:09 +0200 Subject: [atlas] [Request] System tags for DNS resolution In-Reply-To: <20151112204511.GA27036@sources.org> References: <20151111163628.GA5532@sources.org> <56445EAF.5020408@ripe.net> <20151112204511.GA27036@sources.org> Message-ID: <564834F9.4040307@ripe.net> On 12/11/2015 22:45, Stephane Bortzmeyer wrote: >>> For instance, probes 16659, 17072, 17620, 17854 use a resolver >>> which yields a REFUSED for any request and probe 19948, 20065 one >>> with systematic SERVFAIL. > ... >> The above probes are mostly tagged as "resolves-a[aaa]-correctly" >> because they managed to resolve certain A records (e.g. MSM ID >> 1698856). Can you provide the measurement ID(s) where you see the >> REFUSED and SERVFAIL responses? > > Probes 19948, 20065 now seems OK. But 16659, 17072, 17620, 17854 still > return REFUSED: measurements #2928193 and #2928199. I think what is happening here is that all of those probes except for 17854 have at least *one* resolver which does respond to queries. 17854 seems to have no resolvers responding successfully, which is why it has the tag "Doesn't Resolve A". This is because the "Resolves A Correctly" tag is really "Resolves A Correctly (for at least one resolver) (for at least one pre-designated stable target)". We have discussed internally creating another set of tags which say something about the reliability and stability of DNS resolution, rather than our current liberal tags which basically claim something like "you will probably get *some* usable results from this probe". I would be interested to hear your (or anybody else's) thoughts on whether you would use such a reliable/stable DNS resolution tag, and what kind of criteria you would expect for it to be applied. Cheers, Chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From gil at magisto.com Mon Nov 16 09:35:44 2015 From: gil at magisto.com (Gil Bahat) Date: Mon, 16 Nov 2015 10:35:44 +0200 Subject: [atlas] HTTP measurements at willing targets / protocol suggestion Message-ID: Hi, We are interested (like many others, I guess) in the ability to perform HTTP measurements at our own non-anchored network. Understanding the potential for abuse, I would like to suggest the following authentication protocol, which is based on best practices exhibited by other services with such potential (abuse or privacy implications). 1. Confirm control of the domain registration: * This is usually done by mailing the technical contact for the relevant WHOIS entry with a confirmation email containing a unique hash, thus validating ownership. 2. Confirm control of the DNS servers: * This is usually done by editing the root TXT record with a unique hash or publishing a CNAME with unique hash. 3. Confirm control of the Web servers: * This is usually done by placing a uniquely-hashed file in the webserver root directory, a unique hash in the meta-tags for the index html file or a unique value in a file such as robots.txt. I believe this protocol is sufficient to ensure that a web site owner agrees to the implications of allowing free HTTP measurements against their servers and that no unwilling server will ever be probed. At most during the protocol, the only resource that can be hit is a static file or robots.txt specifically, which has very little capability to overwhelm a web server, especially if negative responses are cached for a considerable amount of time / validation is done via a few nodes and propagated across the network. thoughts/ideas welcome. Regards, Gil Bahat, DevOps Engineer, Magisto Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emil at emilstahl.dk Mon Nov 16 12:00:05 2015 From: emil at emilstahl.dk (Emil Stahl Pedersen) Date: Mon, 16 Nov 2015 12:00:05 +0100 Subject: [atlas] HTTP measurements at willing targets / protocol suggestion In-Reply-To: References: Message-ID: ?+1 ? Sounds like a perfect solution ? ?? Med venlig hilsen / Best regards Emil Stahl On Mon, Nov 16, 2015 at 9:35 AM, Gil Bahat wrote: > Hi, > > We are interested (like many others, I guess) in the ability to perform > HTTP measurements at our own non-anchored network. Understanding the > potential for abuse, I would like to suggest the following authentication > protocol, which is based on best practices exhibited by other services with > such potential (abuse or privacy implications). > > 1. Confirm control of the domain registration: > * This is usually done by mailing the technical contact for the relevant > WHOIS entry with a confirmation email containing a unique hash, thus > validating ownership. > > 2. Confirm control of the DNS servers: > * This is usually done by editing the root TXT record with a unique hash > or publishing a CNAME with unique hash. > > 3. Confirm control of the Web servers: > * This is usually done by placing a uniquely-hashed file in the webserver > root directory, a unique hash in the meta-tags for the index html file or a > unique value in a file such as robots.txt. > > I believe this protocol is sufficient to ensure that a web site owner > agrees to the implications of allowing free HTTP measurements against their > servers and that no unwilling server will ever be probed. At most during > the protocol, the only resource that can be hit is a static file or > robots.txt specifically, which has very little capability to overwhelm a > web server, especially if negative responses are cached for a considerable > amount of time / validation is done via a few nodes and propagated across > the network. > > thoughts/ideas welcome. > > Regards, > > Gil Bahat, > DevOps Engineer, > Magisto Ltd. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Mon Nov 16 12:08:15 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 16 Nov 2015 12:08:15 +0100 Subject: [atlas] HTTP measurements at willing targets / protocol suggestion In-Reply-To: References: Message-ID: <5649B91F.2060408@ripe.net> On 2015/11/16 12:00 , Emil Stahl Pedersen wrote: > ?+1 ? > Sounds like a perfect solution > ? ?? Sounds like it is open for abuse. Someone registers evil.whatever, passes all validation checks and can then serve any content he likes. No way to find out who set it up. From klaus.mailinglists at pernau.at Mon Nov 16 15:15:53 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Mon, 16 Nov 2015 15:15:53 +0100 Subject: [atlas] Any way to select the probes from upstream AS (not origin AS)? In-Reply-To: <20151111153254.GA2080@sources.org> References: <20151111153254.GA2080@sources.org> Message-ID: <5649E519.7020403@pernau.at> On 11.11.2015 16:32, Stephane Bortzmeyer wrote: > Is there an easy way to select probes, not on the origin AS, but on an > AS upstream? Example: probe 23865, IP prefix announced by AS 56339 > which currently has only one provider, AS 16080. Currently, Atlas > tells me there are no probes in AS 16080... I have the same problem quite often. For several important Backbone providers there aren't any probes. But there would be a lot of probes which are "behind" these ASes. Choosing this probes is of course not a guarantee that the targeted transit ISP is really used for routing (multihoming, peering) but I think in many cases this would work. You RIPE guys build so cool systems, I think it would be easy for you to integrate RIS data into Atlas. So, if somebody searches for probes in an AS, you could also suggest probes from neighboring ASes (especially the ones which have only one neighbor AS). So for above case: https://stat.ripe.net/data/asn-neighbours/data.json?resource=56339 If you do this lookup once a day and add the info to the probe information (maybe only using "left" neighbors), it could be used for probe selection. regards Klaus From gil at magisto.com Mon Nov 16 15:30:42 2015 From: gil at magisto.com (Gil Bahat) Date: Mon, 16 Nov 2015 16:30:42 +0200 Subject: [atlas] Any way to select the probes from upstream AS (not origin AS)? In-Reply-To: <5649E519.7020403@pernau.at> References: <20151111153254.GA2080@sources.org> <5649E519.7020403@pernau.at> Message-ID: Wouldn't it be easier to simply convince said transit ASes to host a probe? for most part, you'd now be dealing with networking professionals rather than end-users, so they have an incentive to host a probe (for their own routing needs) and technical capacity to do so, whereas for non-transit ASes you are sometimes dependant on a user being a good samaritan or otherwise having a need to access measurements. Regards, Gil Bahat, DevOps Engineer, Magisto Ltd. On Mon, Nov 16, 2015 at 4:15 PM, Klaus Darilion < klaus.mailinglists at pernau.at> wrote: > On 11.11.2015 16:32, Stephane Bortzmeyer wrote: > > Is there an easy way to select probes, not on the origin AS, but on an > > AS upstream? Example: probe 23865, IP prefix announced by AS 56339 > > which currently has only one provider, AS 16080. Currently, Atlas > > tells me there are no probes in AS 16080... > > I have the same problem quite often. For several important Backbone > providers there aren't any probes. But there would be a lot of probes > which are "behind" these ASes. Choosing this probes is of course not a > guarantee that the targeted transit ISP is really used for routing > (multihoming, peering) but I think in many cases this would work. > > You RIPE guys build so cool systems, I think it would be easy for you to > integrate RIS data into Atlas. So, if somebody searches for probes in an > AS, you could also suggest probes from neighboring ASes (especially the > ones which have only one neighbor AS). So for above case: > > https://stat.ripe.net/data/asn-neighbours/data.json?resource=56339 > > If you do this lookup once a day and add the info to the probe > information (maybe only using "left" neighbors), it could be used for > probe selection. > > regards > Klaus > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pavel.odintsov at gmail.com Tue Nov 17 17:50:16 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 17 Nov 2015 19:50:16 +0300 Subject: [atlas] Spoofing measurenments Message-ID: Hello, Community! I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some difficult ethical question. Could we detect probe hosts who do not deploy outgoing filtering and accept spoofed traffic? We need to know amount of they. It's really important for solving spoofing issue in Internet scale. -- Sincerely yours, Pavel Odintsov From furry13 at gmail.com Tue Nov 17 18:00:08 2015 From: furry13 at gmail.com (Jen Linkova) Date: Tue, 17 Nov 2015 18:00:08 +0100 Subject: [atlas] Spoofing measurenments In-Reply-To: References: Message-ID: On Tue, Nov 17, 2015 at 5:50 PM, Pavel Odintsov wrote: > I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some > difficult ethical question. > > Could we detect probe hosts who do not deploy outgoing filtering and > accept spoofed traffic? > > We need to know amount of they. It's really important for solving > spoofing issue in Internet scale. It's been discussed before and some ethical concerns have been raised by RIPE NCC. >From pure technical point of view I think it might be possible some data for Ipv6 (with some false negatives): - a probe could generate ULA prefix for itself and send traffic from that ULA source to, let's say, some anchors (or some other pre-defined target which is known for allowing packets from ULA sources). Receiving such packet from a probe would prove tat there is no BCP38 filtering on the path (however blocking packets proves only the fact that ULAs are being blocked, not real spoofed packets). Or maybe a probe might get a GUA IP address from RIPE prefix and use it as a source.. As bi-directional communication is not necessary, any source address would work. > > -- > Sincerely yours, Pavel Odintsov > -- SY, Jen Linkova aka Furry From pavel.odintsov at gmail.com Tue Nov 17 18:03:13 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Tue, 17 Nov 2015 20:03:13 +0300 Subject: [atlas] Spoofing measurenments In-Reply-To: References: Message-ID: Hello! Thanks for answer! But actually we have huge issues with IPv4. Could we collect this stats with full anonymous approach for bitting ethical problem here? So we definitely need number of networks who ignore this rules. On Tue, Nov 17, 2015 at 8:00 PM, Jen Linkova wrote: > On Tue, Nov 17, 2015 at 5:50 PM, Pavel Odintsov > wrote: >> I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some >> difficult ethical question. >> >> Could we detect probe hosts who do not deploy outgoing filtering and >> accept spoofed traffic? >> >> We need to know amount of they. It's really important for solving >> spoofing issue in Internet scale. > > It's been discussed before and some ethical concerns have been raised > by RIPE NCC. > > From pure technical point of view I think it might be possible some > data for Ipv6 (with some false negatives): > > - a probe could generate ULA prefix for itself and send traffic from > that ULA source to, let's say, some anchors (or some other pre-defined > target which is known for allowing packets from ULA sources). > Receiving such packet from a probe would prove tat there is no BCP38 > filtering on the path (however blocking packets proves only the fact > that ULAs are being blocked, not real spoofed packets). Or maybe a > probe might get a GUA IP address from RIPE prefix and use it as a > source.. > As bi-directional communication is not necessary, any source address would work. > >> >> -- >> Sincerely yours, Pavel Odintsov >> > > > > -- > SY, Jen Linkova aka Furry -- Sincerely yours, Pavel Odintsov From jared at puck.nether.net Tue Nov 17 18:29:11 2015 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 17 Nov 2015 12:29:11 -0500 Subject: [atlas] Spoofing measurenments In-Reply-To: References: Message-ID: Wish i were there.. There?s some cool ways to detect this externally that I know some researchers are working on documenting. I think their results will be at NDSS or PAM (i forget which). - Jared > On Nov 17, 2015, at 12:03 PM, Pavel Odintsov wrote: > > Hello! > > Thanks for answer! > > But actually we have huge issues with IPv4. Could we collect this > stats with full anonymous approach for bitting ethical problem here? > > So we definitely need number of networks who ignore this rules. > > On Tue, Nov 17, 2015 at 8:00 PM, Jen Linkova wrote: >> On Tue, Nov 17, 2015 at 5:50 PM, Pavel Odintsov >> wrote: >>> I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some >>> difficult ethical question. >>> >>> Could we detect probe hosts who do not deploy outgoing filtering and >>> accept spoofed traffic? >>> >>> We need to know amount of they. It's really important for solving >>> spoofing issue in Internet scale. >> >> It's been discussed before and some ethical concerns have been raised >> by RIPE NCC. >> >> From pure technical point of view I think it might be possible some >> data for Ipv6 (with some false negatives): >> >> - a probe could generate ULA prefix for itself and send traffic from >> that ULA source to, let's say, some anchors (or some other pre-defined >> target which is known for allowing packets from ULA sources). >> Receiving such packet from a probe would prove tat there is no BCP38 >> filtering on the path (however blocking packets proves only the fact >> that ULAs are being blocked, not real spoofed packets). Or maybe a >> probe might get a GUA IP address from RIPE prefix and use it as a >> source.. >> As bi-directional communication is not necessary, any source address would work. >> >>> >>> -- >>> Sincerely yours, Pavel Odintsov >>> >> >> >> >> -- >> SY, Jen Linkova aka Furry > > > > -- > Sincerely yours, Pavel Odintsov From pk at DENIC.DE Tue Nov 17 19:01:24 2015 From: pk at DENIC.DE (Peter Koch) Date: Tue, 17 Nov 2015 19:01:24 +0100 Subject: [atlas] Spoofing measurenments In-Reply-To: References: Message-ID: <20151117180124.GX10407@x28.adm.denic.de> On Tue, Nov 17, 2015 at 07:50:16PM +0300, Pavel Odintsov wrote: > Could we detect probe hosts who do not deploy outgoing filtering and > accept spoofed traffic? while this may sound tempting, I think it would be more helpful in the long run to maintain atlas probes as a tool to map the Internet rather than as "spy in the house". -Peter From karsten_thomann at linfre.de Tue Nov 17 19:12:47 2015 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Tue, 17 Nov 2015 19:12:47 +0100 Subject: [atlas] Spoofing measurenments In-Reply-To: <20151117180124.GX10407@x28.adm.denic.de> References: <20151117180124.GX10407@x28.adm.denic.de> Message-ID: <20151117181247.7090257.33529.40885@linfre.de> ?I don't think the measurement would show usable results, as you don't know if the cpe at the probe would block unknown sources or the provider. For example at my home the v4 connection uses the provider owned cpe nat and v6 would go through my firewall as the sixxs tunnel terminate on it. How would you know where the anti spoofing is implemented? Gesendet?von?meinem?BlackBerry ? Originalnachricht ? Von: Peter Koch Gesendet: Dienstag, 17. November 2015 19:02 An: ripe-atlas at ripe.net Betreff: Re: [atlas] Spoofing measurenments On Tue, Nov 17, 2015 at 07:50:16PM +0300, Pavel Odintsov wrote: > Could we detect probe hosts who do not deploy outgoing filtering and > accept spoofed traffic? while this may sound tempting, I think it would be more helpful in the long run to maintain atlas probes as a tool to map the Internet rather than as "spy in the house". -Peter From ainapat at kenet.or.ke Wed Nov 18 09:36:02 2015 From: ainapat at kenet.or.ke (Anne Inapat) Date: Wed, 18 Nov 2015 11:36:02 +0300 (EAT) Subject: [atlas] Probe with no firmware Message-ID: <2086727889.895772.1447835762405.JavaMail.zimbra@kenet.or.ke> I registered my probe almost 2 days ago. when I check on the probe on your site, it is indicated no firmware. I am also unable to get an IP through DHCP. Kindly help. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgalante at ripe.net Wed Nov 18 10:31:56 2015 From: mgalante at ripe.net (Michela Galante) Date: Wed, 18 Nov 2015 11:31:56 +0200 Subject: [atlas] Seven new RIPE Atlas anchors have joined the community Message-ID: <6988BAAC-D77B-4211-A315-2841FE5CBCF3@ripe.net> Dear RIPE Atlas users, Seven new RIPE Atlas anchors have been activated bringing the total number to 157. - Three anchors hosted by Leaseweb Network: us-mnz-as30633 in Manassas, Virginia, us-sfo-as7203 in San Francisco, California, and sg-sin-as59253 in Singapore. - jp-tyo-as13901, hosted by Afilias in Tokyo, Japan. - de-gaa-as56357, hosted by Technische Universit?t M?nchen in Garching, Germany. - cl-scl-as27678, hosted by NIC Chile in Santiago, Chile and sponsored by LACNIC. - pe-lim-as27843, hosted by Optical Technologies in Lima, Peru. The map of all anchor locations is available at: https://atlas.ripe.net/anchors/map/ You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ And here are the logos and links to hosting companies: https://atlas.ripe.net/get-involved/community/#!tab-anchor-sponsors We are still accepting new applications from organisations interested in hosting a RIPE Atlas anchor. We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa, in order to add more geographical diversity to the measurement data. There are more organisations that want to host a RIPE Atlas anchor but don?t have the necessary funding. To learn more about sponsoring an anchor, please contact us at mcb at ripe.net To apply for your own RIPE Atlas anchor: https://atlas.ripe.net/get-involved/become-an-anchor-host/ For any other questions, please contact us at atlas at ripe.net Regards, Michela Galante Measurements Community Building RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bortzmeyer at nic.fr Wed Nov 18 12:32:59 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 18 Nov 2015 12:32:59 +0100 Subject: [atlas] [Request] System tags for DNS resolution In-Reply-To: <564834F9.4040307@ripe.net> References: <20151111163628.GA5532@sources.org> <56445EAF.5020408@ripe.net> <20151112204511.GA27036@sources.org> <564834F9.4040307@ripe.net> Message-ID: <20151118113259.GA25240@sources.org> On Sun, Nov 15, 2015 at 09:32:09AM +0200, Chris Amin wrote a message of 64 lines which said: > I think what is happening here is that all of those probes except > for 17854 have at least *one* resolver which does respond to > queries. OK, I get it. I modified resolve-name to continue if the fist resolver returns REFUSED or SERVFAIL Thanks for the explanations. > why it has the tag "Doesn't Resolve A". Do note that many tags documented in do not work (reported as [ripe.net #1195138]). > I would be interested to hear your (or anybody else's) thoughts on > whether you would use such a reliable/stable DNS resolution tag, and > what kind of criteria you would expect for it to be applied. The current system is not bad, once it is explained and the above bug fixed. From bortzmeyer at nic.fr Wed Nov 18 13:17:05 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 18 Nov 2015 13:17:05 +0100 Subject: [atlas] Spoofing measurenment In-Reply-To: <20151117180124.GX10407@x28.adm.denic.de> References: <20151117180124.GX10407@x28.adm.denic.de> Message-ID: <20151118121705.GA12902@sources.org> On Tue, Nov 17, 2015 at 07:01:24PM +0100, Peter Koch wrote a message of 10 lines which said: > while this may sound tempting, I think it would be more helpful in > the long run to maintain atlas probes as a tool to map the Internet > rather than as "spy in the house". Hmmm, the Atlas probe already learns a lot about the house and publishes it: * "this house uses Google Public DNS" * "this house uses a validating DNS resolver" * "this house uses IPv6 ULA" From furry13 at gmail.com Wed Nov 18 13:18:07 2015 From: furry13 at gmail.com (Jen Linkova) Date: Wed, 18 Nov 2015 13:18:07 +0100 Subject: [atlas] Spoofing measurenments In-Reply-To: References: Message-ID: On Wed, Nov 18, 2015 at 12:57 PM, Alexander Lyamin wrote: > Do we have a statistics on what percentage of probes operate behind NAT? There is a tag "IPv4 RFC1918" so you can select all probes with that tag to get that number. > On Tue, Nov 17, 2015 at 7:03 PM, Pavel Odintsov > wrote: >> >> Hello! >> >> Thanks for answer! >> >> But actually we have huge issues with IPv4. Could we collect this >> stats with full anonymous approach for bitting ethical problem here? >> >> So we definitely need number of networks who ignore this rules. >> >> On Tue, Nov 17, 2015 at 8:00 PM, Jen Linkova wrote: >> > On Tue, Nov 17, 2015 at 5:50 PM, Pavel Odintsov >> > wrote: >> >> I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some >> >> difficult ethical question. >> >> >> >> Could we detect probe hosts who do not deploy outgoing filtering and >> >> accept spoofed traffic? >> >> >> >> We need to know amount of they. It's really important for solving >> >> spoofing issue in Internet scale. >> > >> > It's been discussed before and some ethical concerns have been raised >> > by RIPE NCC. >> > >> > From pure technical point of view I think it might be possible some >> > data for Ipv6 (with some false negatives): >> > >> > - a probe could generate ULA prefix for itself and send traffic from >> > that ULA source to, let's say, some anchors (or some other pre-defined >> > target which is known for allowing packets from ULA sources). >> > Receiving such packet from a probe would prove tat there is no BCP38 >> > filtering on the path (however blocking packets proves only the fact >> > that ULAs are being blocked, not real spoofed packets). Or maybe a >> > probe might get a GUA IP address from RIPE prefix and use it as a >> > source.. >> > As bi-directional communication is not necessary, any source address >> > would work. >> > >> >> >> >> -- >> >> Sincerely yours, Pavel Odintsov >> >> >> > >> > >> > >> > -- >> > SY, Jen Linkova aka Furry >> >> >> >> -- >> Sincerely yours, Pavel Odintsov > > > > > -- > connecting the dots -- SY, Jen Linkova aka Furry From pavel.odintsov at gmail.com Wed Nov 18 13:23:33 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 18 Nov 2015 15:23:33 +0300 Subject: [atlas] Spoofing measurenments In-Reply-To: References: Message-ID: Hello! Could somebody share link to archives with previous discussion of this ethical question? On Wed, Nov 18, 2015 at 3:18 PM, Jen Linkova wrote: > On Wed, Nov 18, 2015 at 12:57 PM, Alexander Lyamin wrote: >> Do we have a statistics on what percentage of probes operate behind NAT? > > There is a tag "IPv4 RFC1918" so you can select all probes with that > tag to get that number. > >> On Tue, Nov 17, 2015 at 7:03 PM, Pavel Odintsov >> wrote: >>> >>> Hello! >>> >>> Thanks for answer! >>> >>> But actually we have huge issues with IPv4. Could we collect this >>> stats with full anonymous approach for bitting ethical problem here? >>> >>> So we definitely need number of networks who ignore this rules. >>> >>> On Tue, Nov 17, 2015 at 8:00 PM, Jen Linkova wrote: >>> > On Tue, Nov 17, 2015 at 5:50 PM, Pavel Odintsov >>> > wrote: >>> >> I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some >>> >> difficult ethical question. >>> >> >>> >> Could we detect probe hosts who do not deploy outgoing filtering and >>> >> accept spoofed traffic? >>> >> >>> >> We need to know amount of they. It's really important for solving >>> >> spoofing issue in Internet scale. >>> > >>> > It's been discussed before and some ethical concerns have been raised >>> > by RIPE NCC. >>> > >>> > From pure technical point of view I think it might be possible some >>> > data for Ipv6 (with some false negatives): >>> > >>> > - a probe could generate ULA prefix for itself and send traffic from >>> > that ULA source to, let's say, some anchors (or some other pre-defined >>> > target which is known for allowing packets from ULA sources). >>> > Receiving such packet from a probe would prove tat there is no BCP38 >>> > filtering on the path (however blocking packets proves only the fact >>> > that ULAs are being blocked, not real spoofed packets). Or maybe a >>> > probe might get a GUA IP address from RIPE prefix and use it as a >>> > source.. >>> > As bi-directional communication is not necessary, any source address >>> > would work. >>> > >>> >> >>> >> -- >>> >> Sincerely yours, Pavel Odintsov >>> >> >>> > >>> > >>> > >>> > -- >>> > SY, Jen Linkova aka Furry >>> >>> >>> >>> -- >>> Sincerely yours, Pavel Odintsov >> >> >> >> >> -- >> connecting the dots > > > > -- > SY, Jen Linkova aka Furry -- Sincerely yours, Pavel Odintsov From swmike at swm.pp.se Wed Nov 18 13:27:25 2015 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 18 Nov 2015 13:27:25 +0100 (CET) Subject: [atlas] Spoofing measurenments In-Reply-To: References: Message-ID: On Wed, 18 Nov 2015, Pavel Odintsov wrote: > Hello! > > Could somebody share link to archives with previous discussion of this > ethical question? https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-September/001005.html http://www.gossamer-threads.com/lists/nanog/users/174708 ... for instance. -- Mikael Abrahamsson email: swmike at swm.pp.se From bortzmeyer at nic.fr Wed Nov 18 13:36:12 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 18 Nov 2015 13:36:12 +0100 Subject: [atlas] Spoofing measurenments In-Reply-To: References: Message-ID: <20151118123612.GA15309@sources.org> On Wed, Nov 18, 2015 at 03:23:33PM +0300, Pavel Odintsov wrote a message of 83 lines which said: > Could somebody share link to archives with previous discussion of this > ethical question? https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-September/001005.html https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-June/000838.html See also the roadmap , section "Measurements to detect BCP38 compliance" From pavel.odintsov at gmail.com Wed Nov 18 15:25:21 2015 From: pavel.odintsov at gmail.com (Pavel Odintsov) Date: Wed, 18 Nov 2015 17:25:21 +0300 Subject: [atlas] Spoofing measurenments In-Reply-To: <20151118123612.GA15309@sources.org> References: <20151118123612.GA15309@sources.org> Message-ID: Thanks! Will read it deeply. On Wed, Nov 18, 2015 at 3:36 PM, Stephane Bortzmeyer wrote: > On Wed, Nov 18, 2015 at 03:23:33PM +0300, > Pavel Odintsov wrote > a message of 83 lines which said: > >> Could somebody share link to archives with previous discussion of this >> ethical question? > > https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-September/001005.html > https://www.ripe.net/ripe/mail/archives/ripe-atlas/2013-June/000838.html > > See also the roadmap , section > "Measurements to detect BCP38 compliance" > -- Sincerely yours, Pavel Odintsov From melanor9 at gmail.com Wed Nov 18 12:57:00 2015 From: melanor9 at gmail.com (Alexander Lyamin) Date: Wed, 18 Nov 2015 13:57:00 +0200 Subject: [atlas] Spoofing measurenments In-Reply-To: References: Message-ID: Do we have a statistics on what percentage of probes operate behind NAT? On Tue, Nov 17, 2015 at 7:03 PM, Pavel Odintsov wrote: > Hello! > > Thanks for answer! > > But actually we have huge issues with IPv4. Could we collect this > stats with full anonymous approach for bitting ethical problem here? > > So we definitely need number of networks who ignore this rules. > > On Tue, Nov 17, 2015 at 8:00 PM, Jen Linkova wrote: > > On Tue, Nov 17, 2015 at 5:50 PM, Pavel Odintsov > > wrote: > >> I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some > >> difficult ethical question. > >> > >> Could we detect probe hosts who do not deploy outgoing filtering and > >> accept spoofed traffic? > >> > >> We need to know amount of they. It's really important for solving > >> spoofing issue in Internet scale. > > > > It's been discussed before and some ethical concerns have been raised > > by RIPE NCC. > > > > From pure technical point of view I think it might be possible some > > data for Ipv6 (with some false negatives): > > > > - a probe could generate ULA prefix for itself and send traffic from > > that ULA source to, let's say, some anchors (or some other pre-defined > > target which is known for allowing packets from ULA sources). > > Receiving such packet from a probe would prove tat there is no BCP38 > > filtering on the path (however blocking packets proves only the fact > > that ULAs are being blocked, not real spoofed packets). Or maybe a > > probe might get a GUA IP address from RIPE prefix and use it as a > > source.. > > As bi-directional communication is not necessary, any source address > would work. > > > >> > >> -- > >> Sincerely yours, Pavel Odintsov > >> > > > > > > > > -- > > SY, Jen Linkova aka Furry > > > > -- > Sincerely yours, Pavel Odintsov > -- connecting the dots -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Thu Nov 19 10:52:06 2015 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 19 Nov 2015 11:52:06 +0200 Subject: [atlas] Spoofing measurenments In-Reply-To: References: Message-ID: <564D9BC6.90501@ripe.net> Hi, Perhaps some people who are interested in topic are not aware: CAIDA runs a "spoofer project" with precisely this goal. You can find more info and statistics here: http://spoofer.caida.org/summary.php Regards, Robert From la at qrator.net Thu Nov 19 17:30:08 2015 From: la at qrator.net (Alexander Lyamin) Date: Thu, 19 Nov 2015 18:30:08 +0200 Subject: [atlas] Spoofing measurenments In-Reply-To: <564D9BC6.90501@ripe.net> References: <564D9BC6.90501@ripe.net> Message-ID: Its well known. Nice attempt, but its ridden with "survivors bias". On Thu, Nov 19, 2015 at 11:52 AM, Robert Kisteleki wrote: > > Hi, > > Perhaps some people who are interested in topic are not aware: CAIDA runs a > "spoofer project" with precisely this goal. > > You can find more info and statistics here: > http://spoofer.caida.org/summary.php > > Regards, > Robert > > -- Alexander Lyamin CEO | Qrator * Labs* office: 8-800-3333-LAB (522) mob: +7-916-9086122 skype: melanor9 mailto: la at qrator.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.karrenberg at ripe.net Mon Nov 23 13:03:53 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 23 Nov 2015 13:03:53 +0100 Subject: [atlas] Spoofing measurenments In-Reply-To: References: Message-ID: <565300A9.4000406@ripe.net> On 17.11.15 17:50 , Pavel Odintsov wrote: > Hello, Community! > > I'm writing from RIPE71 / Anti spoofing BoF. So I want to ask for some > difficult ethical question. > > Could we detect probe hosts who do not deploy outgoing filtering and > accept spoofed traffic? > > We need to know amount of they. It's really important for solving > spoofing issue in Internet scale. > Why exactly do we need to know the exact amount of this problem? We surely know it exists and that it is widespread enough to allow serious reflection attacks. We will know that we are solving the problem when these attacks are getting less. Why not measure that? Would it not be much better to get all ISPs to do something about it? If we are interested in the amount of BCP-38 compliant address space we could just ask. Those that implement it or are in the process of doing so will gladly tell us since that shows them as good citizens. How about getting address space users to publish the BCP-38 status of their address space holdings like this? BCP-38 fully implemented BCP-38 100% implemented by BCP-38 considering Maybe add an attribute to the inetnum:s in the database? Run a campaign to encourage porganisations to publish BCP-38 status and shame those that do not. That would provide a useful measure and also raise awareness! In the case of ISPs it would be open to verification by customers. Daniel From nick at inex.ie Mon Nov 23 13:11:23 2015 From: nick at inex.ie (Nick Hilliard) Date: Mon, 23 Nov 2015 12:11:23 +0000 Subject: [atlas] Spoofing measurenments In-Reply-To: <565300A9.4000406@ripe.net> References: <565300A9.4000406@ripe.net> Message-ID: <5653026B.6050000@inex.ie> On 23/11/2015 12:03, Daniel Karrenberg wrote: > Why exactly do we need to know the exact amount of this problem? it would be useful to know the sources of the problem. Nick From daniel.karrenberg at ripe.net Mon Nov 23 14:01:08 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 23 Nov 2015 14:01:08 +0100 Subject: [atlas] Spoofing measurenments In-Reply-To: <5653026B.6050000@inex.ie> References: <565300A9.4000406@ripe.net> <5653026B.6050000@inex.ie> Message-ID: <56530E14.7040407@ripe.net> On 23.11.15 13:11 , Nick Hilliard wrote: > On 23/11/2015 12:03, Daniel Karrenberg wrote: >> Why exactly do we need to know the exact amount of this problem? > > it would be useful to know the sources of the problem. > > Nick > Those would be the ones not reporting to implement BCP-38. Daniel From Piotr.Strzyzewski at polsl.pl Mon Nov 23 14:12:13 2015 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Mon, 23 Nov 2015 14:12:13 +0100 Subject: [atlas] Spoofing measurenments In-Reply-To: <56530E14.7040407@ripe.net> References: <565300A9.4000406@ripe.net> <5653026B.6050000@inex.ie> <56530E14.7040407@ripe.net> Message-ID: <20151123131213.GM19578@hydra.ck.polsl.pl> On Mon, Nov 23, 2015 at 02:01:08PM +0100, Daniel Karrenberg wrote: > > > On 23.11.15 13:11 , Nick Hilliard wrote: > > On 23/11/2015 12:03, Daniel Karrenberg wrote: > >> Why exactly do we need to know the exact amount of this problem? > > > > it would be useful to know the sources of the problem. > > > > Those would be the ones not reporting to implement BCP-38. You are over-optimistic. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From nick at inex.ie Mon Nov 23 17:02:06 2015 From: nick at inex.ie (Nick Hilliard) Date: Mon, 23 Nov 2015 16:02:06 +0000 Subject: [atlas] Spoofing measurenments In-Reply-To: <56530E14.7040407@ripe.net> References: <565300A9.4000406@ripe.net> <5653026B.6050000@inex.ie> <56530E14.7040407@ripe.net> Message-ID: <5653387E.1070209@inex.ie> On 23/11/2015 13:01, Daniel Karrenberg wrote: > On 23.11.15 13:11 , Nick Hilliard wrote: >> On 23/11/2015 12:03, Daniel Karrenberg wrote: >>> Why exactly do we need to know the exact amount of this problem? >> >> it would be useful to know the sources of the problem. >> > > Those would be the ones not reporting to implement BCP-38. I know of a bunch of organisations that quietly implement bcp38 but don't talk about it. Also, add to the problem that just because a provider supports bcp38, that doesn't mean they support bcp38 everywhere on their network. Like any fence, you can end up with holes appearing due to poor installation or lack of maintenance. Overall it's a problem which would benefit from good quality characterisation. This isn't a request for Atlas to be the mechanism to do this, btw, but there would be value in having an opt-in mechanism with informed consent. This should be sufficient to deal with ethical issues associated with spoof testing. Nick From BECHA at ripe.net Thu Nov 26 12:35:58 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 26 Nov 2015 12:35:58 +0100 Subject: [atlas] Invitation: RIPE NCC Member Lunches in London & Manchester, mid-December 2015 In-Reply-To: <56531665.6090109@ripe.net> References: <56531665.6090109@ripe.net> Message-ID: <5656EE9E.3040004@ripe.net> Dear colleagues, We warmly invite you to join us for a RIPE NCC Member Lunches: - in London on Wednesday, 9 December. - in Manchester on Thursday, 10 December The lunch gives members an open-discussion format to exchange ideas and information among each other as well as with RIPE NCC staff. The goal of these lunches is to offer you an opportunity to meet up with our staff and discuss how we can better engage with the local technical community. Members may also use this opportunity to voice concerns as well as resolve any issues with resource requests or open tickets. I will be there to talk about RIPE Atlas and other measurements & statistics related topics; my colleagues will be there to answer any other questions. This is a free event, with capacity for around 30 people, so we would appreciate an indication of whether you or any of your colleagues wish to attend (up to two attendees from a single LIR). Please confirm your attendance by filling out the registration form below. All who register will be sent a further information sheet prior to the meeting. You can learn more about the services RIPE NCC provides for our members and the RIPE community at: http://www.ripe.net/lir-services/ncc/list-of-ripe-ncc-services We look forward to meeting you in December! Kind regards, Vesna Manojlovic Community Builder & Fergal Cunningham Membership Communications Officer RIPE NCC Details & registration: ======================= London ====== The lunch will be held on Wednesday, 9 December from 13:00-15:00 (arrival from 12:30) at: De Hems Dutch Cafe Bar Dutch-themed, traditional 19th-century pub serving Dutch and Belgian beers, British menu and snacks. Address: 11 Macclesfield St, London W1D 5BW Register: https://portal.ripe.net/meeting-pub/registration?meetingId=b1400c45-7b87-4920-bb9a-523495b7db81 Manchester ========== The lunch will be held on Thursday, 10 December from 13:00-15:00 (arrival from 12:30) at: Address: The Lowry Hotel 50 Dearmans Pl, Chapel Wharf, Manchester M3 5LH, United Kingdom https://www.thelowryhotel.com/restaurants-and-bars/river-bar-and-grill Register: https://portal.ripe.net/meeting-pub/registration?meetingId=2d9ce8d0-46e7-43bb-bd51-3de0ef215149 From BECHA at ripe.net Fri Nov 27 11:24:03 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 27 Nov 2015 11:24:03 +0100 Subject: [atlas] Leftover budget? Consider a RIPE Atlas anchor In-Reply-To: References: Message-ID: <56582F43.7020703@ripe.net> Dear all, The end of the year is coming closer, and you might be wondering, ?What is the best way to spend some of the money still left in my budget, while at the same time contributing to the good of the Internet?? Why not consider hosting a RIPE Atlas anchor?! Investing in an anchor means you will: - Gain access to a wealth of measurement data (IPv4/IPv6 pings, trace routes) targeting your anchor from all the other anchors and hundreds of probes throughout the RIPE Atlas network, without spending credits - Earn 10 times more credits compared to hosing a regular probe that you can spend on your own customised measurements - HTTP measurements towards your anchor [1] - Have your logo included on the RIPE Atlas website [2] - Join a growing community that is providing great benefit to the Internet: there are currently 159 RIPE Atlas anchors around the world You can learn more about hosting an anchor here: https://atlas.ripe.net/get-involved/become-an-anchor-host/ Thanks, and happy holiday season! Vesna [1] https://labs.ripe.net/Members/kistel/ripe-atlas-update-http-measurements-cli-tools-domainmon-and-more#http-measurements-towards-anchors [2] https://atlas.ripe.net/get-involved/community/#!anchor-sponsors From v.bajpai at jacobs-university.de Fri Nov 27 15:02:45 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Fri, 27 Nov 2015 14:02:45 +0000 Subject: [atlas] spread control (thank you) In-Reply-To: <563B2227.60608@ripe.net> References: <563B2227.60608@ripe.net> Message-ID: Hello, > The new spread control, available via the API and the web interface, now > allows users to tailor this to their specific needs. In addition to specifying > the measurement frequency, users can also specify the duration of a time > interval within which the probes will be linearly distributed. This week got hit by the need to have ^ feature. Just wanted to say thank you to the RIPE team for implementing this! Best, Vaibhav > On 05 Nov 2015, at 10:32, Mirjam Kuehne wrote: > > Dear colleagues, > > There are a number of interesting new features and enhancements for RIPE > Atlas users. Learn how you can put them to use: > > https://labs.ripe.net/Members/kistel/ripe-atlas-update-http-measurements-cli-tools-domainmon-and-more > > Kind regards, > Mirjam Kuehne > RIPE NCC ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From v.bajpai at jacobs-university.de Fri Nov 27 15:12:35 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Fri, 27 Nov 2015 14:12:35 +0000 Subject: [atlas] [request]: probe timezone offsets Message-ID: Hello, It would be nice to report a timezone offset for each probe via the probe API. Since measurements are reported in UTC, it's currently difficult to visualise a timeseries result in the local time of the probe. In order to do this, one has to turn the geolocations (currently reported in the probe API) of the probe to the corresponding timezone offset (which takes time) and then adjust the measurement timestamps by the timezone offset. It would be great if the timezone offsets of the probe are available via API. Thanks! PS: This is very low priority request. Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From bortzmeyer at nic.fr Fri Nov 27 15:29:28 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 27 Nov 2015 15:29:28 +0100 Subject: [atlas] [request]: probe timezone offsets In-Reply-To: References: Message-ID: <20151127142928.GA11044@sources.org> On Fri, Nov 27, 2015 at 02:12:35PM +0000, Bajpai, Vaibhav wrote a message of 65 lines which said: > It would be great if the timezone offsets of the probe are available > via API. But how would the probe learn it? It is not sent in the DHCP answer. From v.bajpai at jacobs-university.de Fri Nov 27 16:02:07 2015 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Fri, 27 Nov 2015 15:02:07 +0000 Subject: [atlas] [request]: probe timezone offsets In-Reply-To: <20151127142928.GA11044@sources.org> References: <20151127142928.GA11044@sources.org> Message-ID: <205A9F76-E723-435C-BDDD-F60C520E0141@jacobs-university.de> > On 27 Nov 2015, at 15:29, Stephane Bortzmeyer wrote: > >> It would be great if the timezone offsets of the probe are available via API. > > But how would the probe learn it? It is not sent in the DHCP answer. No no, the probe does not need to learn it. The timezone offset can be derived from the latitude / longitude (provided by the probe owner during registration; currently available via probe API). As long as the geolocation does not change, so does the timezone offset. It's possible to do this in the analysis phase as well, but it takes time to calculate these offsets for ~9K probes. Therefore, was thinking, perhaps a field in the probe API would save time. Best, Vaibhav ===================================================== Vaibhav Bajpai Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com ===================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From robachevsky at isoc.org Fri Nov 27 17:40:08 2015 From: robachevsky at isoc.org (Andrei Robachevsky) Date: Fri, 27 Nov 2015 17:40:08 +0100 Subject: [atlas] Spoofing measurenments In-Reply-To: <5653026B.6050000@inex.ie> References: <565300A9.4000406@ripe.net> <5653026B.6050000@inex.ie> Message-ID: <56588768.9090500@isoc.org> Nick Hilliard wrote on 23/11/15 13:11: > On 23/11/2015 12:03, Daniel Karrenberg wrote: >> Why exactly do we need to know the exact amount of this problem? > > it would be useful to know the sources of the problem. > Agree. It is also important to be able to track the overall trend. Stats on volumetric DDoS attacks are not a good indicator, since they depend on other factors like number and amplification capabilities of reflectors and botnet parameters. I doubt that without good measurements and traceability we can effectively address this problem. Having said that I do not think Atlas can really help. Atlas can only offer a fraction of devices that can effectively spoof (although I heard that not every NAT device prevents spoofing for any IP range). And its deployment is not uniform, so the results won't be more statistically representative than those from Spoofer (http://spoofer.caida.org/). Sigh... Andrei From klaus.mailinglists at pernau.at Mon Nov 30 13:30:39 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Mon, 30 Nov 2015 13:30:39 +0100 Subject: [atlas] Feature Request Web Interface Message-ID: <565C416F.6070701@pernau.at> When viewing the "Map" results of a DNS measurement some details will be shown in a pop-up when clicking on the respective probe. It would be great if the NSID (if available) would be shown too (not only Response Time and Serial) thanks Klaus From klaus.mailinglists at pernau.at Mon Nov 30 13:48:33 2015 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Mon, 30 Nov 2015 13:48:33 +0100 Subject: [atlas] Problem with Map Tab of DNS Measurement Message-ID: <565C45A1.4020200@pernau.at> Hi! I did a one-off DNS measurement: https://atlas.ripe.net/measurements/3050168/ As long as the measurement was running, I could click on the map tab. But now as the measurement is finished, the "map" tab is gone. While loading the site I see for a short time the tabs General information, Probes, Map and Results. But as soon as the site is loaded completely the Map and Probes tab are gone. Calling the map explicitely using https://atlas.ripe.net/measurements/3050168/#!map does also not work. Is this a feature or a bug? Thanks Klaus From BECHA at ripe.net Mon Nov 30 13:59:14 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 30 Nov 2015 13:59:14 +0100 Subject: [atlas] New on RIPE Labs: RIPE Atlas Tools Hackathon Results Message-ID: <565C4822.5060905@ripe.net> Dear colleagues, The second RIPE Atlas hackathon took place 13-14 November 2015 in conjunction with the RIPE 71 meeting. Impressive results were hacked together by programmers and operators during an intensive weekend of work and fun in Bucharest. In this article we celebrate the hackathon achievements and report about the benefits for the community in detail: https://labs.ripe.net/Members/becha/ripe-atlas-tools-hackathon-results Regards, Vesna ps to bring you some spirit of the event... http://www.memes.com/meme/784389 -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-11-30 at 13.53.25.png Type: image/png Size: 217059 bytes Desc: not available URL: From robert at ripe.net Mon Nov 30 14:05:59 2015 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 30 Nov 2015 14:05:59 +0100 Subject: [atlas] Problem with Map Tab of DNS Measurement In-Reply-To: <565C45A1.4020200@pernau.at> References: <565C45A1.4020200@pernau.at> Message-ID: <565C49B7.7000503@ripe.net> Hi, Thank you for reporting -- this is indeed a bug, introduced today. We're working on a fix. Regards, Robert On 2015-11-30 13:48, Klaus Darilion wrote: > Hi! > > I did a one-off DNS measurement: > https://atlas.ripe.net/measurements/3050168/ > > As long as the measurement was running, I could click on the map tab. > But now as the measurement is finished, the "map" tab is gone. While > loading the site I see for a short time the tabs General information, > Probes, Map and Results. But as soon as the site is loaded completely > the Map and Probes tab are gone. > > Calling the map explicitely using > https://atlas.ripe.net/measurements/3050168/#!map > does also not work. > > Is this a feature or a bug? > > Thanks > Klaus > > From andrea.consadori at hotmail.it Mon Nov 30 15:42:55 2015 From: andrea.consadori at hotmail.it (Andrea Consadori) Date: Mon, 30 Nov 2015 15:42:55 +0100 Subject: [atlas] Measurements delete and ping issue Message-ID: Hi all, i just start using proble atlas and i found is not possible to delete Stopped measurements from web, it's normal? i try to search on old mailing list messages and seems to be and old issue but i still cannot delete stopped masurements (for example ids: 3050379, 3034900) Another issue i see, if i create a ping measurement (id 3034899) under probes i see RTT column unreachable for every raw... but the public ip is pingable form everywhere.. maybe there's simple solutions i cannot found, if so can someone show me a good link where to found how to fix this two issues? Regards Andrea Consadori -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Mon Nov 30 16:54:20 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 30 Nov 2015 16:54:20 +0100 Subject: [atlas] Measurements delete and ping issue In-Reply-To: References: Message-ID: <565C712C.7070906@ripe.net> On 2015/11/30 15:42 , Andrea Consadori wrote: > Another issue i see, if i create a ping measurement (id 3034899 > ) under probes i see RTT > column unreachable for every raw... but the public ip is pingable form > everywhere.. Hi Andrea, Just commenting on this part. There a surprisingly simple explanation. You set the packet interval to 2 ms (there is a mis-feature on the website in that the unit is not displayed next to the value). Because the measurement code doesn't have a separate overall timeout, this reduces the total time that the probes listen for any replies to 6 ms. Philip From daniel.karrenberg at ripe.net Mon Nov 30 19:44:53 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 30 Nov 2015 19:44:53 +0100 Subject: [atlas] Fwd: Re: Measurements delete and ping issue In-Reply-To: <565C9760.2050704@ripe.net> References: <565C9760.2050704@ripe.net> Message-ID: <565C9925.8070500@ripe.net> I did not copy the list on this message and then realised that it is a generic answer that deserves to be seen and archived here. Daniel -------- Forwarded Message -------- Subject: Re: [atlas] Measurements delete and ping issue To: Andrea Consadori References: From: Daniel Karrenberg Message-ID: <565C9760.2050704 at ripe.net> Date: Mon, 30 Nov 2015 19:37:20 +0100 On 30.11.15 15:42 , Andrea Consadori wrote: > > > Hi all, > i just start using proble atlas and i found is not possible to delete > Stopped measurements from web, it's normal? > i try to search on old mailing list messages and seems to be and old > issue but i still cannot delete stopped masurements > (for example ids: 3050379 > , 3034900 > ) > ... Andrea, An important idea behind RIPE Atlas is that all results are re-useable. Therefore we store the results of *all* measurements as long as we possibly can because those results can be useful for other researchers even if they did not run the measurements themselves. Each result says something about the packet flow in the Internet at the particular time it was obtained. There is no way we can foresee how these results can help to answer interesting research questions and help us to understand the Internet packet layer better than we do now. For a recent example of this, please see https://labs.ripe.net/Members/becha/ripe-atlas-tools-hackathon-results "ASN Tryst". Therefore we do not provide the functionality of deleting measurements. The only way we foresee that results can be deleted is if we run out of storage space. Of course that one has to be careful to select the measurements one wants to re-use according to the question one wants to answer. Your measurement shows this very well. I do not recommend using your results unless the question is about reachability with RTTs under 6ms. I hope this answers your question Daniel (co-inventor of RIPE Atlas)