[147554] in North American Network Operators' Group
RE: Multiple ISP Load Balancing
daemon@ATHENA.MIT.EDU (Rampley Jr, Jim F)
Wed Dec 14 15:43:24 2011
From: "Rampley Jr, Jim F" <jim.rampley@chartercom.com>
To: "Justin M. Streiner" <streiner@cluebyfour.org>, "nanog@nanog.org"
<nanog@nanog.org>
Date: Wed, 14 Dec 2011 14:42:21 -0600
In-Reply-To: <Pine.LNX.4.64.1112141451030.30735@whammy.cluebyfour.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
We have specific situations where we have successfully used the Avaya CNA t=
ool (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 d=
one on our internal network where we have MPLS VPN's sometimes over multipl=
e 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 t=
est a path and move traffic at the first hint of trouble. =20
Jim=20
-----Original Message-----
From: Justin M. Streiner [mailto:streiner@cluebyfour.org]=20
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=20
> balancers such as the old Routescience Pathcontrol device are still=20
> around, and if not what have others found to replace that function. I=20
> have used the Routescience device with much success 10 years ago when it=20
> first came on the market, but since then a full BGP feed has become much=20
> larger, Routescience has been bought by Avaya, then discontinued, and=20
> other competitors such as Sockeye, Netvmg have been acquired by other=20
> companies.
It's important to keep in mind what load-balancing is and isn't in this=20
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=20
data center. Some people can (and sometimes do) confuse the two, which=20
can cause unrealistic expectations to be set :)
Achieving a perfect split of network traffic across two or more upstream=20
links rarely happens in the real world. General good practice is to put=20
bandwidth where the network traffic wants to go, but that can be a moving=20
target, and executives and accountants don't like those :) Traffic=20
engineering still has a place on many networks, for a veriety of reasons=20
(technical, financial, political, some combination of these), but as=20
other posters have mentioned, it's often done manually, i.e. looking at=20
Netflow reports, seeing where your traffic is going/coming from, adjusting=20
BGP policies accordingly. Repeat as needed. Since traffic profiles can=20
change over time, any policy tweaks that are put in place need to be=20
reviewed periodically.
Depending on how much prep work and planning you're willing to do, you can=20
put a fairly rich set of internal BGP communities in place to control=20
things like localpref, MEDs, selective prepends, and tagging outbound=20
advertisements with provider-specific communities. With that kind of=20
structure, you could control many aspects of your traffic engineering from=20
a route server, rather than having to tinker with route policies on each=20
outside-facing router.
One caveat: If your route server crashes or has to be taken down for=20
maintenance, the traffic patterns that were being tweaked by your policy=20
framework could start to revert to the way the traffic would flow in its=20
un-altered state, which could cause you some unintended headaches.
jms
E-MAIL CONFIDENTIALITY NOTICE:=20
=20
=20
=20
The contents of this e-mail message and=20
any attachments are intended solely for the=20
addressee(s) and may contain confidential=20
and/or legally privileged information. If you=20
are not the intended recipient of this message=20
or if this message has been addressed to you=20
in error, please immediately alert the sender
by reply e-mail and then delete this message=20
and any attachments. If you are not the=20
intended recipient, you are notified that=20
any use, dissemination, distribution, copying,=20
or storage of this message or any attachment=20
is strictly prohibited.
