Fwd: Re[4]: [nsp] eBGP routes not balancing

[Jeff Chan]

With his permission, here's a forwarded suggestion from Aaron
to use localprefs to manually route larger networks, thereby
balancing the traffic between upstreams.  It's a reasonable if
somewhat labor intensive solution.

Someone else on the list suggested to ask the upstreams to send
communities indicating their source of routes as customer,
originated by the upstream, or non-originated, then using route
maps to set localprefs based on that.  This is what I'm setting
up now. 

That way traffic to networks known to be at or customers of a
particular peer are routed to that peer.  It's a wise and
intended use of communities.  I knew about it, but forgot.  :(

The networks that are not originated at or customers of
the upstreams (i.e. the rest of the Internet) we'll probably
split up by network numbers or route manually per Aaron's
suggestion below.

Thanks to all who helped!

Jeff C.
__

This is a forwarded message
From: Jeff Chan <cisco-nsp at jeffchan.com-nospam>
To: Aaron Weintraub <aaronw at distracted.org-nospam>
Date: Monday, November 17, 2003, 3:50:25 PM
Subject: [nsp] eBGP routes not balancing

===8<==============Original message text===============
On Monday, November 17, 2003, 3:17:12 PM, Aaron Weintraub wrote:
> On Mon, Nov 17, 2003 at 02:09:11PM -0800, Jeff Chan wrote:
>> After enabling "bgp bestpath compare-routerid" and resetting the
>> sessions, most of the traffic went to the peer with the lower
>> numerical address (ID), which again is unbalanced.  So I've
>> disabled compare-routerid and will probably reset all the
>> sessions late at night with "clear ip bgp all" in the hopes
>> that the ages of the routes will then be close enough, since
>> they're all cleared and re-learned at the same time, to
>> result in traffic that is closer to balanced.

> This is entirely incorrect.  You can't get them both relearned at the same exact
> time, and that's a really sloppy way to balance traffic, because what if the line
> resets?

> Regardless, I completely agree that compare router-id SHOULD be installed because
> then no matter how many times all the lines reset, the traffic will be the same,
> i.e., state won't enter into the path selection at all.

Thanks Aaron, I agree.  I'm not comfortable with the route
selection being dependent on age either.

> Instead, what you should do, is, for example, set a lpref of 110 on _3356_ routes
> from your provider that has lower traffic in steady state.  Observe how much
> traffic moves.  If that moved too much, try something like _209_.  Then try
> something like _3549_.  Keep on trying moving large chunks of the route table
> around and see what 'buckets' work best for you.  This works better if you have
> netflow because then you know what size the buckets are, but it works fine without
> it, you just have to see what happens.  What kind of userbase do you have? If you
> have mostly content, try moving around viewers - SBC, Cox, Adelphia, etc.  If you
> have mostly viewers, move around content - CNN/TW, Abovenet, CW/Exodus, etc.

> This is by far the cleanest way to do it.  Of course, you can also decide to move
> specific other ASNs that you perceive as having good or bad connectivity to the
> other upstream.  Like, if you see that the path to Qwest is much better through
> Sprint than CW, well, then, put Qwest permanently on Sprint!

Sounds reasonable if requiring some tweaking.  Good for us
control freaks.  :)

Jeff C.
===8<===========End of original message text===========

-- 
Jeff Chan
mailto:jeffc at supranet.net
http://www.jeffchan.com/