mailing list archives
RE: Multiple ISP Load Balancing
From: Drew Weaver <drew.weaver () thenap com>
Date: Thu, 15 Dec 2011 08:04:17 -0500
This is why I wish they would release it as open source or sell it to someone else, the product really did work well,
the kernel in the underlying Linux is the biggest hurdle.
From: Rampley Jr, Jim F [mailto:jim.rampley () chartercom com]
Sent: Wednesday, December 14, 2011 3:42 PM
To: Justin M. Streiner; nanog () nanog org
Subject: RE: Multiple ISP Load Balancing
We have specific situations where we have successfully used the Avaya CNA tool (old Route Science Patch Control). Not
for load balancing, but for sub second failover from primary to a backup paths over MPLS VPN's. This is done on our
internal network where we have MPLS VPN's sometimes over multiple carriers where normal convergence times are 30
seconds to 1 minute across an external provider. It's not easy to setup initially, but once you get it setup and the
kinks worked out I've been impressed with its ability to test a path and move traffic at the first hint of trouble.
From: Justin M. Streiner [mailto:streiner () cluebyfour org]
Sent: Wednesday, December 14, 2011 2:10 PM
To: nanog () nanog org
Subject: Re: Multiple ISP Load Balancing
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
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.
E-MAIL CONFIDENTIALITY NOTICE:
The contents of this e-mail message and any attachments are intended solely for the
addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient
of this message or if this message has been addressed to you in error, please immediately alert the sender by reply
e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that
any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.