Load balance over multiple bgp feeds

Fri Apr 22 00:06:27 UTC 2005

On Thu, Apr 21, 2005 at 06:47:36PM -0500, Mike Hyde wrote:

> I was wondering what everyone does to load balance over multiple bgp
> feeds. We currently have 5 bgp feeds with 2 providers. Do you just
> randomly pick networks, or use something like netflow to try and
> pick the best path.

A lot of it depends on what you're trying to balance for (cost?
performance?), the size of each link, the type of traffic you're
dealing with, and other factors. My main experience has been at a
couple of stub networks, and I don't claim to be an expert on this.
YMMV.

I've generally been able to get surprisingly accurate results in terms
of how much traffic to send out one link or another just by using
route-maps and some simple netflow analysis, plus traceroute / ping.
I don't know if Netflow will give you much information in terms of
the best path, but it can give you an idea of how much traffic you're
sending / receiving to various ASes. I've found ehnt[1] pretty helpful
for this. Even a few simple rules (all traffic to AOL goes through
X, all traffic passing through 701 goes through Y) can often get you
pretty close to where you want to be.

This is a sledgehammer / shotgun type tool... but it has worked well for
me. Of course you need to take into consideration the size of your pipes
and how the loss of connectivity to one provider may affect your rules.

And of course there are tools which claim to do this for you (for a
"small" price), Route Science, Internap's appliance (whatever it's
called), etc. I've not had any personal experience with these devices;
check the NANOG archives for plenty of opinions.

I'm not sure if there are any open source tools that do a good job of
this, but you might see the NANOG thread with the subject "Open Source
BGP Route Optimization?"[2] from May 2004 - came up from a quick google
search I did.

For content type stuff, I haven't found performance to be a huge deal
most of the time... I imagine with VOIP and other applications, it
might be more of a concern, though.

/w

[1] http://ehnt.sourceforge.net/
[2] Looks like this is the first item in the thread:
http://www.cctec.com/maillists/nanog/current/msg00719.html