Re: [atlas] RIPE Atlas anchor self assembly
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 >> >> > >
Re: [atlas] RIPE Atlas anchor self assembly
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
Re: [atlas] RIPE Atlas anchor self assembly
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
Re: [atlas] RIPE Atlas anchor self assembly
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 at...@ripe.net and > we will be very happy to help you. > > Best regards, > Michela Galante > Measurements Community Building > RIPE NCC
[atlas] RIPE Atlas anchor self assembly
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 at...@ripe.net and we will be very happy to help you. Best regards, Michela Galante Measurements Community Building RIPE NCC signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 AGVorstand: 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 >
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
-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-
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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.
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 AGVorstand: 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 pgpEVCM6eygMF.pgp Description: PGP signature
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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
Re: [atlas] Sharing credits with colleagues
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
Re: [atlas] Feature request for IP record route feature in RIPE Atlas
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
Re: [atlas] Sharing credits with colleagues
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
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
> 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
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 AGVorstand: 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 pgpqZJQu9fL0k.pgp Description: PGP signature
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
> 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 = signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 AGVorstand: 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
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 AGVorstand: 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 >>> >>> >>> > > >
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 > = >
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 = signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 >
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 AGVorstand: 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
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 AGVorstand: 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 > > >
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 AGVorstand: 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
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 AGVorstand: 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 pgpjPq0TYEUQD.pgp Description: PGP signature
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 > >
