RE: [nsp] BGP Confederation question

From: tcobb@staff.circle.net
Date: Mon Oct 25 1999 - 01:17:28 EDT


The IGP is IBGP. The problem I'm having is not related to
internal routing inside each sub-AS confederation. OSPF
gains me nothing in the situation I presented.

-Troy Cobb
 Circle Net, Inc.
 http://www.circle.net

> -----Original Message-----
> From: Scott Lampert [mailto:scott@altair.heavymetal.org]
> Sent: Sunday, October 24, 1999 9:34 PM
> To: tcobb@staff.circle.net
> Subject: Re: [nsp] BGP Confederation question
>
>
> OSPF would handle this rather transparently assuming
> you're not already
> running that. You should be able to announce dynamic
> defaults to the BGP
> routers and traffic will follow the least cost path to
> destinations within your
> AS without having to touch anything.
> -Scott
>
> --
> +-----------------------+--------------------------------+
> | Scott Lampert | Systems Administrator |
> | scott@ioa.com | Internet of Asheville |
> |(828) 687-8848 Ext 310 | http://www.ioa.com |
> +-----------------------+--------------------------------+
>
> On Sun, Oct 24, 1999 at 07:07:47AM -0400,
> tcobb@staff.circle.net wrote:
> > 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