From: Paul (p_chopin@xxxxxxxxx)
Date: Mon May 27 2002 - 16:11:36 GMT-3
Nigel,
You right but remember we dealing with lab. Everything
is allowed and a bit convoluted. I guess the idea of
question was how to prevent R1 from installing
specific routes in its routing table when is doing
summarization.
Thanks.
--- 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