From: Donny MATEO (donny.mateo@xxxxxxxxxxxxxxxxxx)
Date: Tue Jul 09 2002 - 05:50:54 GMT-3
Hi Nick,
thanks for the explanation, i'm clear now on that part.
Now for the same scenario and I don't have controll on rtrA (let's assumed
it's the backbone).
What I can do in router B is to use filter-list / distribute-list to filter
routing update sent to RtrC.
What if, instead of this, I decided to give all routing update coming from
RtrA a community no-export (Input-policy-Engine on RtrB). So inside RtrB
(or it's AS) the route coming from RtrA will be tag with the community
no-export. And thus, any route learned from rtrA, won't be propagated by
RtrB to RtrC. As all route with communities would not be sent to RtrC,
RtrC does not have to honor the community. Will this work as well as the
first solution ?
Thanks
Donny
"Nick Shah"
<nshah@connect.co To: "Donny MATEO" <donny.m
ateo@sg.ca-indosuez.com>, "Hansang Bae"
m.au> <hbae@nyc.rr.com>
cc: <ccielab@groupstudy.co
m>, <nobody@groupstudy.com>
09-07-2002 16:30 Subject: Re: As Transit
Donny
What Hansang means is that "in some production environments" we override
communities, or ignore communities from certain customers (less popular
in
ISP/NSP environment).
So its not a sure shot way to ascertain that the community attribute would
be honored. Because you cannot guarantee that ur upstream will not over
ride
community or not accept community (not honor actually).
However in a lab/controlled environment as this, where there are 3 (or
more)
routers involved (RtrA --- RtrB ---- RtrC) we can either put a prefix
filter/distribute list on B (outbound towards RtrC) or set community
no-export on RtrA. This will depend mostly on which options are allowed and
which options are not. It will also depend upon which Router you are
allowed
to make changes on. Say RtrA is a backbone router over which you have no
control, your options are pretty much prefix filter or distribute list on
RtrB, basically not allowing the route to leak to RtrC. However if you are
having control on RtrA, then you could use community, which in my opinion
is
*slightly cleaner*
rgds
Nick
----- Original Message -----
From: Donny MATEO <donny.mateo@sg.ca-indosuez.com>
To: Hansang Bae <hbae@nyc.rr.com>
Cc: <ccielab@groupstudy.com>; <nobody@groupstudy.com>
Sent: Tuesday, July 09, 2002 4:26 PM
Subject: Re: As Transit
> Could you please elaborate more on "the other side does not *have* to
honor
> it" ?
> As far as I know ( do correct me if I'm wrong) all IBGP peer would have
the
> same comunities attribute set and as far as the effect is that the routes
> won't be propagated to external peers (EBGP), and that should (again
> correct me if I'm wrong) achieve the objective of not advertising route
> learned from external peer to other external peer(s).
>
> Thanks.
> Donny
>
>
>
> Hansang Bae
> <hbae@nyc.rr.com> To:
ccielab@groupstudy.com
> Sent by: cc:
> nobody@groupstudy Subject: Re: As Transit
> .com
>
>
> 09-07-2002 13:50
> Please respond to
> Hansang Bae
>
>
>
>
>
>
> At 12:52 PM 7/9/2002 +0800, Donny MATEO wrote:
> >How about community no-export when you receive the route
> >Something like
> >router bgp x
> > neighb x.x.x.x route-map SETCOM in
> >end
> >route-map SETCOM permit 10
> > set community no-export
> >end
>
>
> The problem with communities is that the other side does not *have* to
> honor it.
>
> I'd go with what others suggested.
>
>
> hsb
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:23 GMT-3