From: Mingzhou Nie (mnie@xxxxxxxxx)
Date: Mon May 27 2002 - 12:54:48 GMT-3
How about community "no-advertise"
--- Nigel Taylor <nigel_taylor@hotmail.com> wrote:
> Paul,
>
> There are so many options here it's not funny, of which "table-map"
> isn't
> one of them. The
> question here is as Howard would state it..
>
> "What's the problem you're trying to solve?"
>
> If this is a lab specific requirement then all that's need is to
> apply a
> distribute-list on
> the "neighbor x.x.x.x " of the BGP peer from the other AS inbound.
> Then
> create an ACL
> with on statement to "permit" the aggregate route(let's say
> 140.10.0.0).
> This would address
> the issue. in order to aggregate the route you could then create
> either a
> loopback interface
> and then use the aggregate-address summary-only" bgp command. There
> are
> inherent flaws
> with this configuration.(see A)
>
> Another option here would be to use either the distribute-list bgp
> command
> to only allow
> the aggregate route out to IBGP peers.
>
> The emphasis on not having the routes present in r1's RIB is somewhat
> confusing me. Mainly
> because since all these routes were learned through EBGP, they will
> be in
> the r1 RIB
> as BGP routes(AD 20). In any event the distribute-list would meet the
> requirement, which is
> dependant on the aggregate route being received from the other AS.
>
> (A) In a real world scenario since you would be providing
> aggregation, then
> realistic routing policies
> would suggest the user is using part of the Provider space in which
> case you
> would want the
> more specific routes a part of the r1 RIB. Without this information
> packets
> will be blackholed since
> you would be originating the aggregate route which is derived from a
> loopback interface or null0 route.
>
> basically, the important note here is.. the routing policy in use and
> address space
> in use by the external bgp customer/system.
>
> Nigel
>
>
>
>
>
> ----- Original Message -----
> From: "David Ham" <ccieau@hotmail.com>
> To: <p_chopin@yahoo.com>
> Cc: <ccielab@groupstudy.com>
> Sent: Monday, May 27, 2002 7:23 AM
> Subject: Re: BGP aggregation
>
>
> > paul,
> >
> > Yes, you must create a loopback as well as network statement to
> allow the
> > aggregate address to be put in the routing table.
> >
> > David Ham
> >
> >
> >
> > >From: Paul <p_chopin@yahoo.com>
> > >Reply-To: Paul <p_chopin@yahoo.com>
> > >To: David Ham <ccieau@hotmail.com>
> > >CC: ccielab@groupstudy.com
> > >Subject: Re: BGP aggregation
> > >Date: Sun, 26 May 2002 23:39:09 -0700 (PDT)
> > >
> > >If you filter all incoming routes , how are you going
> > >to create aggreate? You must then use network
> > >statement
> > >I guess
> > >Paul
> > >--- David Ham <ccieau@hotmail.com> wrote:
> > > > I don't think Table-map do the trick.
> > > > You might have to filter the all the incoming routes
> > > > before getting into R1
> > > > and put the aggregate statement at R1. Only problem
> > > > is other routers would
> > > > think the aggregate route is from R1 as the origin
> > > > of aggregate route will
> > > > bg IGP.
> > > >
> > > > Regards,
> > > >
> > > > David Ham
> > > > OPTUS
> > > >
> > > >
> > > > >From: Carlos G Mendioroz <tron@huapi.ba.ar>
> > > > >Reply-To: Carlos G Mendioroz <tron@huapi.ba.ar>
> > > > >To: Paul <p_chopin@yahoo.com>
> > > > >CC: Groupstudy ccielab list
> > > > <ccielab@groupstudy.com>
> > > > >Subject: Re: BGP aggregation
> > > > >Date: Sun, 26 May 2002 11:03:03 -0300
> > > > >
> > > > >How about using table-map to filter the specifics ?
> > > > >
> > > > >Paul wrote:
> > > > > >
> > > > > > Hi guy,
> > > > > > Here it is scenario. R1 is getting external
> > > > routes
> > > > > > from other AS. R1 is doing aggregation and
> > > > sending
> > > > > > only aggregate towards internal peers. Question
> > > > is how
> > > > > > to prevent R1 from installing specific routes
> > > > into its
> > > > > > own routing table.It should have only aggregate.
> > > > > > Paul
> > > > > >
> > > > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:59:10 GMT-3