Feature request for IP record route feature in RIPE Atlas
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-... 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
virtual vm probe would be great as well :) ask for this before Colin
On 9 Nov 2015, at 09:04, Pavel Odintsov <pavel.odintsov@gmail.com> 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-...
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
+1 for VM probe :) On Mon, Nov 9, 2015 at 1:16 PM, Colin Johnston <colinj@mx5.org.uk> wrote:
virtual vm probe would be great as well :) ask for this before
Colin
On 9 Nov 2015, at 09:04, Pavel Odintsov <pavel.odintsov@gmail.com> 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-...
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
+2 for VM probe Am 09.11.2015 11:30 schrieb "Pavel Odintsov" <pavel.odintsov@gmail.com>:
+1 for VM probe :)
virtual vm probe would be great as well :) ask for this before
Colin
On 9 Nov 2015, at 09:04, Pavel Odintsov <pavel.odintsov@gmail.com> 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
On Mon, Nov 9, 2015 at 1:16 PM, Colin Johnston <colinj@mx5.org.uk> wrote: the World.
I have checked implementation details here
https://labs.ripe.net/Members/philip_homburg/ripe-atlas-measurements-source-...
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
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
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 <robert@ripe.net> 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
On Mon, Nov 09, 2015 at 12:49:19PM +0000, Colin Johnston <colinj@mx5.org.uk> 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.)
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 <robert@ripe.net> 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
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 <robert@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
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
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
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 <gert@space.net> 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
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 <gert@space.net> 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
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 <daniel.karrenberg@ripe.net> 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 <gert@space.net> 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
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 <daniel.karrenberg@ripe.net> 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 <gert@space.net> 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
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 <daniel.karrenberg@ripe.net> 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 <daniel.karrenberg@ripe.net> 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 <gert@space.net> 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
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 <pavel.odintsov@gmail.com> 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 <daniel.karrenberg@ripe.net> 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 <daniel.karrenberg@ripe.net> 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 <gert@space.net> 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
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
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
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 =====================================================
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 <v.bajpai@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 =====================================================
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
On 10 Nov 2015, at 11:18, Stephan Wolf <s.wolf@wolfsec.ch> 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 =====================================================
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
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
On 10 Nov 2015, at 12:20, Wilfried Woeber <woeber@cc.univie.ac.at> 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
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
reply inline
On 10 Nov 2015, at 12:50, Philip Homburg <philip.homburg@ripe.net> 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
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
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.
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
-----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-----
On Tue, Nov 10, 2015 at 10:57:36AM +0100, Sebastian Neuner <sebastian@sneuner.org> 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?
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-...
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
Thanks! I will try to run it on CentOS VirtualBox vm. On Mon, Nov 9, 2015 at 4:10 PM, Philip Homburg <philip.homburg@ripe.net> 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-...
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
participants (14)
-
Bajpai, Vaibhav -
Budiwijaya -
Colin Johnston -
Daniel Karrenberg -
Gert Doering -
Jaap Akkerhuis -
Nick Hilliard -
Pavel Odintsov -
Philip Homburg -
Robert Kisteleki -
Sebastian Neuner -
Stephan Wolf -
Stephane Bortzmeyer -
Wilfried Woeber