Hello Group,
I was wondering if anyone could share their experience with any route optimization approaches, methodologies or platforms, either open source or commercial (Internap FCP), that can actively adjust BGP parameters based on latency and number of layer 3 hops to a network rather than AS hops. We have upstreams all over the country and we would like to automate optimization to take the best egress path.
Thank you for your feedback in advance.
Best Regards,
Babak
Hi.
We`ve started working on a similar product.
We are now running a closed beta with one US-based and another european hosting provider and expect to have a full-working prototype in about 3 months.
As per our research there aren`t many competitors in this market.
Actually Cisco has its //Optimized Edge Routing (OER) feature available in the IOS, Internap has FCP, Avaya has RouteScience which is now available only for their voip customers.
Several providers I`ve spoken with have developed something for internal use.
Back in the 2001-2002 there were much many products available.
Hello Group,
I was wondering if anyone could share their experience with any route optimization approaches, methodologies or platforms, either open source or commercial (Internap FCP), that can actively adjust BGP parameters based on latency and number of layer 3 hops to a network rather than AS hops. We have upstreams all over the country and we would like to automate optimization to take the best egress path.
We were using Internap, but ended up writing our own so that we could look at larger number of speakers. The technology is not that complicated, you basically take netflow data and send it to a host that has tunnels over each one of your BGP peers that you care about. It then uses a combination of traceroute and ping to collect its data that is then injected back to the router over BGP.
<>
Nathan Stratton CTO, BlinkMind, Inc.
nathan at robotics.net nathan at blinkmind.com
http://www.robotics.net http://www.blinkmind.com
It's also probably helpful to use SNMP to verify that the data you're getting from netflow is at least somewhat accurate and that the routing changes are actually effective in getting the desired results.
thanks,
-Drew
This is basically Arbinet's "Optimized" product; it uses actual measurements for loss, round trip time, and jitter to choose routes. Right now, it is just sold as a service, going through the providers they sell access to; I don't know if you could purchase/license the software for your own use.
-Dave
(Full disclosure: Arbinet is my current employer.)
Honestly someone should just convince Avaya to opensource and/or sell the Route Science product.
It's only real flaws (even today) are the performance of the hardware it was built on and the lack of IPv6 support.
Give it an x64 kernel that supports 32GB of RAM and you could probably still be using it today.
-Drew
I used the PathControl for years (~2003-2007) and it rocked. We used
it for both performance and cost, preferring cheaper links as long as
the performance was comparable. It was super stable, I think we had
one or two problems with it the entire time it was installed. The
only drawback was it was too good, we got lazy and just let it do
everything.
-Gregor
I used Pathcontrol with great success, moving bandwidth from one provider to another at a very granular level. It beat the Netflow/CAIDA tools manual approach hands down. I don't understand the performance issue, though, and this is not the first time performance has been raised as an issue. Some have seemed to think that the Pathcontrol existed inline in the data plane, so, it was maintained, Pathcontrol could not scale to 10 GiGE and higher ISP links. But Pathcontrol was defined as a route-reflector BGP client in the control plane, and functioned as a method of calculating the fastest path to destination BGP prefixes, and then advertising the best BGP route to IBGP route-reflector peers, which, in the absence of route table churn, did not require a super high-performing device.
Avaya should either bring the product back, or release the licensing for someone else to use.
The more flows you throw at it the more RAM/CPU it uses until eventually it can't handle anymore. You can keep raising your sampling rate if you want but at some point the CNA 336 is just too old/slow. As I said if the kernel supported more RAM it would still be a viable platform. I think Avaya just got tired of having to keep the 3 dudes they had on staff to support it.
thanks,
-Drew
Hi.
Just FYI, we have already launched a stable release.
Feel free to contact me off-list if interested.