From: Nigel Taylor (nigel_taylor@xxxxxxxxxxx)
Date: Mon May 27 2002 - 09:44:36 GMT-3
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:09 GMT-3