[147594] in North American Network Operators' Group
RE: Multiple ISP Load Balancing
daemon@ATHENA.MIT.EDU (Drew Weaver)
Thu Dec 15 08:05:30 2011
From: Drew Weaver <drew.weaver@thenap.com>
To: "'Rampley Jr, Jim F'" <jim.rampley@chartercom.com>, "Justin M. Streiner"
<streiner@cluebyfour.org>, "nanog@nanog.org" <nanog@nanog.org>
Date: Thu, 15 Dec 2011 08:04:17 -0500
In-Reply-To: <5D717D6976F4D8498089CBEE22C2EBCD12D78DA6@KSTLMEXCP03MBX.CORP.CHARTERCOM.COM>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
This is why I wish they would release it as open source or sell it to someo=
ne else, the product really did work well, the kernel in the underlying Lin=
ux is the biggest hurdle.
Thanks,
-Drew
-----Original Message-----
From: Rampley Jr, Jim F [mailto:jim.rampley@chartercom.com]=20
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 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]
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=20
> it first came on the market, but since then a full BGP feed has become=20
> much larger, Routescience has been bought by Avaya, then discontinued,=20
> and other competitors such as Sockeye, Netvmg have been acquired by=20
> other companies.
It's important to keep in mind what load-balancing is and isn't in this cas=
e. The terminology gap can be important because load-balancing (more accur=
ately, 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 li=
nks rarely happens in the real world. General good practice is to put band=
width where the network traffic wants to go, but that can be a moving targe=
t, and executives and accountants don't like those :) Traffic engineering =
still has a place on many networks, for a veriety of reasons (technical, fi=
nancial, political, some combination of these), but as other posters have m=
entioned, it's often done manually, i.e. looking at Netflow reports, seeing=
where your traffic is going/coming from, adjusting BGP policies accordingl=
y. Repeat as needed. Since traffic profiles can change over time, any pol=
icy 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 thing=
s like localpref, MEDs, selective prepends, and tagging outbound advertisem=
ents 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 ro=
uter.
One caveat: If your route server crashes or has to be taken down for mainte=
nance, the traffic patterns that were being tweaked by your policy framewor=
k 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:=20
=20
=20
=20
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 informa=
tion. If you are not the intended recipient of this message or if this mess=
age 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, disseminatio=
n, distribution, copying, or storage of this message or any attachment is s=
trictly prohibited.
