IBGP is the IGP. Each confederation is made up of
fully-meshed IBGP speakers in a peer-group. Intra-sub-as
routing is not a problem, it is routing between confederations
that is posing the trickiness.
-Troy Cobb
Circle Net, Inc.
http://www.circle.net
> -----Original Message-----
> From: Danny McPherson [mailto:danny@qwest.net]
> Sent: Sunday, October 24, 1999 8:16 PM
> To: tcobb@staff.circle.net
> Cc: cisco-nsp@puck.nether.net
> Subject: Re: [nsp] BGP Confederation question
>
>
>
> 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