Dear RIPE Atlas team I want to ask why don't you make software probes? RIPE NCC have to spend a lot of money on RIPE Atlas. They can easily make RIPE Atlas VMWare image or an RPM,deb package and even windows service. So people can install them on their servers. The other way to save probes is making probes multi-home. For example I have 4 probes in one place to monitor 4 different IP prefixes and paths. I know because of the hardware limits we can't use sub-interfaces but we can set 4 IP addresses manually and add 4 any route by the source, then we can save 3 other probes. -- Shahin Gharghi
valid point On 26/11/2014 16:56, Shahin Gharghi wrote:
Dear RIPE Atlas team
I want to ask why don't you make software probes? RIPE NCC have to spend a lot of money on RIPE Atlas. They can easily make RIPE Atlas VMWare image or an RPM,deb package and even windows service. So people can install them on their servers.
The other way to save probes is making probes multi-home. For example I have 4 probes in one place to monitor 4 different IP prefixes and paths. I know because of the hardware limits we can't use sub-interfaces but we can set 4 IP addresses manually and add 4 any route by the source, then we can save 3 other probes.
-- Shahin Gharghi
On Wed Nov 26 15:56:01 2014 GMT+0100, Shahin Gharghi wrote:
Dear RIPE Atlas team
I want to ask why don't you make software probes? RIPE NCC have to spend a lot of money on RIPE Atlas. They can easily make RIPE Atlas VMWare image or an RPM,deb package and even windows service. So people can install them on their servers.
I guess a "plug and play" approach. Also if RIPE NCC does VMware images, why not KVM or Hyper-V? Tough to keep up... -- Sent from my Jolla
Dear Shahin, On 26-nov.-14 15:56, Shahin Gharghi wrote:
Dear RIPE Atlas team
I want to ask why don't you make software probes?
we regularly get these questions, and we have documented the reply here: https://atlas.ripe.net/about/faq/#why-did-you-choose-a-hardware-solution-ins... There are other projects that do measurements using virtual machines or SW applications, that might be more suitable for your needs, for example NLNOG RING: https://ring.nlnog.net/ We cooperate with them on several levels, but out goals are slightly different. For example, using RIPE Atlas you can target RING nodes: https://atlas.ripe.net/targets/ringnodes/map/
RIPE NCC have to spend a lot of money on RIPE Atlas. They can easily make RIPE Atlas VMWare image or an RPM,deb package and even windows service. So people can install them on their servers.
The other way to save probes is making probes multi-home.
For example I have 4 probes in one place to monitor 4 different IP prefixes and paths. I know because of the hardware limits we can't use sub-interfaces but we can set 4 IP addresses manually and add 4 any route by the source, then we can save 3 other probes.
Now that's an interesting idea, and I can say that we'll take it into consideration -- but you have already mentioned HW limits yourself. Please take a look at our roadmap, where we document major feature requests. SW probe is also there, as "requested", along with the link to the explanation why we are not going to go for that solution now: http://roadmap.ripe.net/ripe-atlas/ Regards, Vesna Manojlovic Community Builder for Measurements Tools
Hi Shahin, On 2014/11/26 15:56 , Shahin Gharghi wrote:
The other way to save probes is making probes multi-home. For example I have 4 probes in one place to monitor 4 different IP prefixes and paths. I know because of the hardware limits we can't use sub-interfaces but we can set 4 IP addresses manually and add 4 any route by the source, then we can save 3 other probes.
One thing to keep in mind is that there are very good reasons to try to keep probes as simple as possible. Even if that means installing 4 probes in one location. Extra complexity translates into extra testing effort and more bugs. What is gained by using the hardware more efficiently can be lost easily in more engineering effort. At this moment, making a probe multi-homed would be a significant engineering effort because just about all code implicitly assumes that every probe has exactly one interface. (I assume that from a hardware point of view, VLAN tagging would allow a probe to be connect to different ethernets) Philip
Dear Vesna Thank you for your explanation and Thank others for their reply. I think only this reason prevents you to make a software probe : - It is easier to tamper with the results. This is also why we chose not to release a software version in tandem with the hardware solution . And I think the hardware problem could be solved by changing the LAN chipset ( Maybe TPLink do this for you). On Fri, Nov 28, 2014 at 9:22 PM, Philip Homburg <philip.homburg@ripe.net> wrote:
Hi Shahin,
On 2014/11/26 15:56 , Shahin Gharghi wrote:
The other way to save probes is making probes multi-home. For example I have 4 probes in one place to monitor 4 different IP prefixes and paths. I know because of the hardware limits we can't use sub-interfaces but we can set 4 IP addresses manually and add 4 any route by the source, then we can save 3 other probes.
One thing to keep in mind is that there are very good reasons to try to keep probes as simple as possible. Even if that means installing 4 probes in one location.
Extra complexity translates into extra testing effort and more bugs. What is gained by using the hardware more efficiently can be lost easily in more engineering effort.
At this moment, making a probe multi-homed would be a significant engineering effort because just about all code implicitly assumes that every probe has exactly one interface.
(I assume that from a hardware point of view, VLAN tagging would allow a probe to be connect to different ethernets)
Philip
-- Shahin Gharghi
participants (5)
-
nicolas＠ncartron.org -
Philip Homburg -
Promise Kumalo -
Shahin Gharghi -
Vesna Manojlovic