From: Nick Shah (nshah@xxxxxxxxxxxxxx)
Date: Tue Jul 09 2002 - 06:12:24 GMT-3
Yes, that will work.
Since the prefix itself is not being sent to RtrC, the question of RtrC not
honoring community wont arise.
rgds
Nick
----- Original Message -----
From: Donny MATEO <donny.mateo@sg.ca-indosuez.com>
To: Nick Shah <nshah@connect.com.au>
Cc: <ccielab@groupstudy.com>; Hansang Bae <hbae@nyc.rr.com>;
<nobody@groupstudy.com>
Sent: Tuesday, July 09, 2002 6:50 PM
Subject: Re: As Transit
>
> 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.mateo@sg.ca-indosuez.com>, "Hansang Bae"
> m.au> <hbae@nyc.rr.com>
> cc:
<ccielab@groupstudy.com>, <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