Ed Morin <edm@halcyon.com> writes
* We peer, using BGP, with several "backbone" provider networks for transit
* purposes. Some of these links are "faster" than others (e.g. T-3 vs.
* multiple T-1 and single T-1) for various reasons. If our router sees
* a route to a particular destination via a "high-speed" link and a "low-
* speed" link that has the _same_ number of AS "hops", it picks the link
* with the "lowest" IP address! (At least that's what I'm told and what
* I observe...)
Yup, this is the ultimate tie breaker if there are two routes that are
otherwise identical.
* Why doesn't BGP pick the link with the highest bandwidth, or, better
* yet, pick the link with the highest bandwidth AND least congestion to
* label as the "best" available route? The needed information is avail-
The first one is easy, in fact you can do that yourself by fiddling
with metrics or such on the different BGP sessions. The second one
would have dramatic consequences in terms of route instability. You
pick one route now because of load on the link, the load changes and
you pick the other, now BGP will have to change the announcement of
this network to other peers. So, now we not only have flaps because of
links/routers going up and down, we also have flap because of load
changes on the network. The result: you are dampened out forever, or
the network falls over.
-Marten
Is this really true? All I'm asking for is that the route a router
considers to be "best" be picked by something a little more rational
than the ordinate order of its IP address relative to another link.
I don't see a flap situation at all here -- only that a decision to
route a packet may change more frequently based on load.
Ed Morin
Northwest Nexus Inc. (206) 455-3505 (voice)
Professional Internet Services
edm@nwnexus.WA.COM
I know this is not the cisco list, but I'm sounding a warning.
We had a bad, bad, BAD experience with BGP peer groups
recently, which cisco are coming in to discuss. Symptoms
are your outgoing AS filter lists will not work with *some*
peers! This can look really confusing if, like us,
you rely on a local peer-session to do sanity
checking of your filter-lists and it shows everything
is OK.
Version is:
Cisco Internetwork Operating System Software
IOS (tm) GS Software (RSP-JV-M), Version 11.1(6), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-1996 by cisco Systems, Inc.
cisco RSP2 (R4600) processor with 131072K bytes of memory.
R4700 processor, Implementation 33, Revision 1.0
I've talked to at least one other provider who has experienced
similar problems. I've yet to see a bug report from cisco on
this, but would appreciate any comments from other folks
who see similar behaviour (directly to me, I'll summarize).
Oh, and this problem can take several days to manifest
itself, and it seems to have impeccable timing 
Mark
Is this really true? All I'm asking for is that the route a router
considers to be "best" be picked by something a little more rational
than the ordinate order of its IP address relative to another link.
I don't see a flap situation at all here -- only that a decision to
route a packet may change more frequently based on load.
A decision to route a packet may change more frequently based on load.
And those decisions are propogated and acted upon by other routers. And
they send traffic down those links. And the load on those links changes.
And you make a new decision to route a packet based on the new load.