Multiple ISP Load Balancing

Wed Dec 14 20:42:21 UTC 2011

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.  

Jim 

-----Original Message-----
From: Justin M. Streiner [mailto:streiner at cluebyfour.org] 
Sent: Wednesday, December 14, 2011 2:10 PM
To: nanog at 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 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

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.