On Wed, 14 Dec 2011, Holmes,David A wrote:
From time to time some have posted questions asking if BGP load
balancers such as the old Routescience Pathcontrol device are still
around, and if not what have others found to replace that function. I
have used the Routescience device with much success 10 years ago when it
first came on the market, but since then a full BGP feed has become much
larger, Routescience has been bought by Avaya, then discontinued, and
other competitors such as Sockeye, Netvmg have been acquired by other
companies.
It's important to keep in mind what load-balancing is and isn't in this
case. The terminology gap can be important because load-balancing (more
accurately, load-sharing) in the context of internetwork traffic
engineering is very different from load-balancing pools of servers in a
data center. Some people can (and sometimes do) confuse the two, which
can cause unrealistic expectations to be set :)
Achieving a perfect split of network traffic across two or more upstream
links rarely happens in the real world. General good practice is to put
bandwidth where the network traffic wants to go, but that can be a moving
target, and executives and accountants don't like those :) Traffic
engineering still has a place on many networks, for a veriety of reasons
(technical, financial, political, some combination of these), but as
other posters have mentioned, it's often done manually, i.e. looking at
Netflow reports, seeing where your traffic is going/coming from, adjusting
BGP policies accordingly. Repeat as needed. Since traffic profiles can
change over time, any policy tweaks that are put in place need to be
reviewed periodically.
Depending on how much prep work and planning you're willing to do, you can
put a fairly rich set of internal BGP communities in place to control
things like localpref, MEDs, selective prepends, and tagging outbound
advertisements with provider-specific communities. With that kind of
structure, you could control many aspects of your traffic engineering from
a route server, rather than having to tinker with route policies on each
outside-facing router.
One caveat: If your route server crashes or has to be taken down for
maintenance, the traffic patterns that were being tweaked by your policy
framework could start to revert to the way the traffic would flow in its
un-altered state, which could cause you some unintended headaches.
jms