[147546] in North American Network Operators' Group
Re: Multiple ISP Load Balancing
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Wed Dec 14 14:35:40 2011
In-Reply-To: <F3318834F1F89D46857972DD4B411D700527428411@exchange>
Date: Wed, 14 Dec 2011 14:34:46 -0500
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Drew Weaver <drew.weaver@thenap.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Wed, Dec 14, 2011 at 2:28 PM, Drew Weaver <drew.weaver@thenap.com> wrote=
:
> I've asked several times about this in the past; although I learned quick=
ly to stop asking.
>
> It seems that the consensus has generally been that the best way to handl=
e traffic engineering in networks where you have multiple full-feed up-stre=
ams is to do it manually (i.e. set preference for your top N AS/prefix dest=
inations) or don't do it at all (let BGP figure it out..?).
>
seems the feeling is that if you have multiple full feeds and need to
loadshare, you really don't want (in most cases) ispa=3D500mbps +
ispb=3D500mbps.
you really want destinationA to be reached across the 'best path'
(best ... in some form, distance? packetdrop%? jitter? cost?) you'll
most likely have to tweak things in order to achieve what you want
since only distance is really used in the stock bgp calculation
(distance by as-hops, presuming you don't listen to closely to med
from your providers)
> Suggesting that a "route optimization system" has any value generally mak=
es people cranky.
>
ha! :)
-chris
> Thanks,
> -Drew
>
> -----Original Message-----
> From: Holmes,David A [mailto:dholmes@mwdh2o.com]
> Sent: Wednesday, December 14, 2011 2:07 PM
> To: nanog@nanog.org
> Subject: Multiple ISP Load Balancing
>
> 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 n=
ot what have others found to replace that function. I have used the Routesc=
ience device with much success 10 years ago when it first came on the marke=
t, but since then a full BGP feed has become much larger, Routescience has =
been bought by Avaya, then discontinued, and other competitors such as Sock=
eye, Netvmg have been acquired by other companies.
>
> Doing some research on how load balancing can be accomplished in 2011, I =
have come across Cisco's performance routing feature, and features from loa=
d balancing companies such as F5's Link Controller. I have always found BGP=
to be easy to work with, and an elegant, simple solution to load balancing=
using a route-reflector configuration in which one BGP client (Routescienc=
e Pathcontrol in my background) learns the best route to destination networ=
ks, and then announces that best route to BGP border routers using common a=
nd widely understood BGP concepts such as communities and local pref, and f=
ound this to lead to a deterministic Internet routing architecture. This re=
quired a knowledge only of IETF standards (common BGP concepts and configur=
ations), required no specialized scripting, or any other knowledge lying ou=
tside IETF boundaries, and it seemed reasonable to expect that network engi=
neers should eagerly and enthusiastically want to master this technology, j=
ust as any other technology must be mastered to run high availability netwo=
rks.
>
> So I am wondering if anyone has experience with implementing load balanci=
ng across multiple ISP links in 2011, and if there have been any comparison=
s between IETF standards-based methods using BGP, and other proprietary met=
hods which may use a particular vendor's approach to solving the same probl=
em, but involves some complexity with more variables to be plugged in to th=
e architecture.
>
> David
>
>
>
> =A0________________________________
> This communication, together with any attachments or embedded links, is f=
or the sole use of the intended recipient(s) and may contain information th=
at is confidential or legally protected. If you are not the intended recipi=
ent, you are hereby notified that any review, disclosure, copying, dissemin=
ation, distribution or use of this communication is strictly prohibited. If=
you have received this communication in error, please notify the sender im=
mediately by return e-mail message and delete the original and all copies o=
f the communication, along with any attachments or embedded links, from you=
r system.
>
