Are you running a common IGP between the sub ASs? If so, your IGP metrics
should assist in deriving the optimal path to a destination.
-danny
> We have recently implemented BGP confederations as we
> expand the number of routing facilities/routers we depend on.
> However, I'm running into an annoying problem related
> to the fact that confederation (sub-AS) length are not
> counted when best-path is computed. Here's a quick
> and simplified example of meshed confederation BGP
> peer-group speakers between facilities:
>
> CONFEDB
> / |
> CONFEDA |
> \ |
> CONFEDC
>
> Assume for the moment that
> CONFEDA is locally connected to 10.0.0.0/24
> And CONFEDB is locally connected to 10.1.0.0/24
> And CONFEDC is locally connected to 10.2.0.0/24
> ("locally connected" is just being used as a placeholder
> for the fact that the routes originate on my AS at these
> locations)
>
> Now, assuming no other preference modifications, CONFEDA
> will see potential routes to 10.2.0.0/24 coming from CONFEDB
> and CONFEDC. However, due to the fact that internal sub-AS
> numbers are not computed as part of an AS path length selection, the
> routes appear to be equally weighted between the two hop
> route from CONFEDA->B->C and the one hop route of CONFEDA->C.
> Actually, in the above case, the best path computation goes all
> the way down to arbitrarily choosing the A->B->C as best route.
>
> What I'd like to do is find a way to continue meshing the confederations
> and dynamically assign best path based on the closeness to the point of
> route origination. With external AS, this happens fairly automatically,
> but with internal sub-AS, it does not appear to. I don't want to have
> to hard-code route preferences at any location. One way that I came up
> with was to send a community to internal peers whenever a route was
> originated
> on the router in question. However, this falls apart when we get past
> the simplest case, and also requires removing the community before routes
> are propagated further within my AS (communities persist).
>
> A MED also seemed reasonable, but suffers from similar problems.
>
> What I'd really like to do is either
> a) force Cisco BGP to consider sub-AS path lengths
> OR
> b) us a MED that increases additively based on the distance away from
> route origination
>
> The preferred best solution would avoid hard coding netblocks into
> route-map statements and would scale past the simplest case, above.
> Oh, if it matters, all of the BGP speakers are 7206 or larger Ciscos.
>
>
> Any ideas? Or did I simply miss some CLI option? ;)
>
>
> -Troy Cobb
> Circle Net, Inc.
> http://www.circle.net
>
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:12:06 EDT