Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
Sent from my iPad
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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?
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] 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 > >
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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 > >
Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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
[atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
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
