From: Mannan Venkatesan (mv_lab@xxxxxxxxxxx)
Date: Mon Mar 11 2002 - 22:55:43 GMT-3
Hi Chang,
I thought so and it worked the same for me when I had tried this before. But
I just wanted to confirm.
Thanks,
Mannan
----- Original Message -----
From: "ying chang" <ying_c@hotmail.com>
To: <mv70@lucent.com>; <hcb@gettcomm.com>; <ccielab@groupstudy.com>
Sent: Monday, March 11, 2002 6:19 PM
Subject: Re: distribute-list
> Hi Mannan,
>
> The way I understand it, "distribute-list in" is used by the router to
> decide whether the route should be added to its routing table bsed on the
> access-list. It doesn't make a whole lot of sense when you put the
> "distribute-list in" under the eigrp process trying to filter a route
coming
> from ospf process. There's no way you can remove it, as ospf process will
> put it in the routing table regardless what you do in the eigrp process.
> Same thing apply to the r1 side, if you add 8.0.0.0 at r1, the
> distribute-list will work under eigrp process, but it will not work under
> ospf process.
>
> Chang
>
>
> >From: Mannan Venkatesan <mv70@lucent.com>
> >Reply-To: Mannan Venkatesan <mv70@lucent.com>
> >To: "Howard C. Berkowitz" <hcb@gettcomm.com>, ccielab@groupstudy.com
> >Subject: Re: distribute-list
> >Date: Mon, 11 Mar 2002 15:49:25 -0500
> >
> >Thanks for the info, Howard. But I was curious about what you said on
> >"distribution x in". I got on to my lab, tested the following scenario,
> >
> >Used net 10.0.0.0/24,
> >
> > r1------------------r2------------------r3---
> >1.1 eig .2 2.1 osp .2
> >
> >I was doing redistribution on r2 from ospf to eigp. R2 is learning
9.0.0.0
> >network from r3 through ospf. I had acl to deny 9.0.0.0.
> >
> >When I put "distribute-li 1 in' under ospf process, it removes 9.0.0.0
> >network from RIB and from eigrp process too. When I configured the same
> >command under eigrp process, it does nothing. R2 had 9.0.0.0 learned
> >through
> >ospf and r1 had it through eigrp as an external route. I had to use
> >dist-list out command under eigrp to filter the route.
> >
> >So, what I am getting to is 'dist-in' doesn't filter the routes being
> >redistributed, atleast on a cisco box.
> >
> >Mannan
> >
> >----- Original Message -----
> >From: "Howard C. Berkowitz" <hcb@gettcomm.com>
> >To: <ccielab@groupstudy.com>
> >Sent: Monday, March 11, 2002 2:45 PM
> >Subject: Re: distribute-list
> >
> >
> > > At 1:54 PM -0500 3/11/02, Mannan Venkatesan wrote:
> > > >Ok, I have a question here. You said "redistribute bar information,
> >with
> > > >filters y and foo metric x, into foo". 'Distribute-list y in' command
> >only
> > > >control what is going to go to your local router's routing table.
> > >
> > > Actually, it doesn't even do that. It filters what goes into the
> > > specific routing process' tables. The output of that routing table
> > > with other sources of routing information for installation in the
> > > main RIB.
> > >
> > > >It doesn't
> > > >filter what is going to go other routers.
> > > >
> > > >router eig 1
> > > >red osp 1 def x
> > > >distribute-list 1 in
> > > >
> > > >This will filter routes getting into local router's routing table
based
> >on
> > > >acl 1. But it will not filter what is being sent to other eig
neighbors
> > > >So, is "distribute-list in" import???
> > >
> > > Yes, with respect to the local router
> > >
> > > >
> > > >And again, distribute-list 1 out osp 1 will control the routes being
> > > >imported from ospf to eigrp. So, is distribute-list out "import"
here?
> > > >Confused,enough???
> > >
> > > It's export with respect to ospf, but import with respect to eigrp.
> > > The redistribute command just doesn't have the fine granularity to
> > > make it unambiguous.
> > >
> > > Here's some material from the draft of my upcoming Wiley book,
> > > _Building Service Provider Networks_ (sorry, it's much more readable
> > > with formatting)
> > >
> > > Policy Notation with RPSL
> > > -------------------------
> > >
> > > RPSL is the only standards-based routing policy notation. Tools have
> > > been written to generate specific router configuration statements
> > > from it.
> > > This discussion of notation is not intended as a complete tutorial on
> > > the languages involved. Rather, it is intended to give a sense of
> > > their capabilities.
> > >
> > > Information flow in RPSL is defined with respect to peering
> > > specifications. Most often, peering specifications are of the
> > > granularity of AS to AS. They can, however, be refined to
> > > information flow at specific router interfaces, or broadened to
> > > define policy to multiple AS. The most general form of the peering
> > > specification allows the possibility of exchanging information
> > > between routing protocols, although BGP is the default.
> > >
> > > The full power of import and export expressions involves the
> > > capability of interacting among different routing protocols, not just
> > > BGP.
> > >
> > > Table 1: Import Peering Expression (from the RPSL specification)
> > >
> > > import: [protocol <protocol-1>] [into <protocol-2>]
> > > from <peering-1>
> > >
> > > AS-SETs are not the only kind of set you can define, and you can use
> > > recursion for each type.
> > >
> > > Route-sets include multiple prefixes:
> > >
> > > A fairly complex example is the peering-set:
> > > peering-set: prng-bar
> > > peering: AS1 at 9.9.9.1
> > > peering-set: prng-foo
> > > peering: prng-bar
> > > peering: AS2 at 9.9.9.1
> > > aut-num: AS1
> > > import: from prng-foo accept { 128.9.0.0/16 }
> > >
> > > --------
> > > Contrast Cisco, RPSL, and Juniper:
> > > --------
> > >
> > > JunOS has a specific policy construct that differs from RPSL, but has
> > > some of the same structured characteristics. Its syntax is
> > > consistent with the general JunOS style, which draws from FreeBSD
> > > UNIX configuration language.
> > > There are two primary ways to use policy with JunOS. Our principal
> > > focus here is on BGP acceptance and advertising policies. JunOS
> > > policy expressions, however, also can be used to control the
> > > exporting of routes out of the main RIB, into, for example, OSPF and
> > > ISIS.
> > > You write policies per routing protocol, using the policy-option
> > > construct. Most of the detailed policy matching and action
> > > conditions are in the policy-statement policy-name inside the
> > > policy-option structure, but are preceded by information about
> > > as-path, community, and damping.
> > > policy-options {
> > > as-path name regular-expression;
> > > community name members [community-ids];
> > > damping name {
> > > half-life minutes;
> > > max-suppress minutes;
> > > reuse number;
> > > suppress number;
> > > }
> > > policy-statement policy-name {
> > > term term-name {
> > > from {
> > > match-conditions;
> > > route-filter destination-prefix match-type <actions>;
> > > prefix-list name;
> > > }
> > > to {
> > > match-conditions;
> > > }
> > > then actions;
> > > }
> > > }
> > > prefix-list name {
> > > ip-addresses;
> > > }
> > >
> > >
> > > For individual policy expressions, you can combine unitary and set AS
> > > information with the Boolean operators AND, OR, and EXCEPT.
> > >
> > > The EXCEPT operator
> > >
> > > EXCEPT is the operator for set subtraction, and is equivalent to AND
> > > NOT. ((AS1 OR AS2) EXCEPT AS2), for example, equals AS1.
> > >
> > >
> > >
> > > >
> > > >Mannan
> > > >
> > > >
> > > >----- Original Message -----
> > > >From: "Howard C. Berkowitz" <hcb@gettcomm.com>
> > > >To: <ccielab@groupstudy.com>
> > > >Sent: Monday, March 11, 2002 11:27 AM
> > > >Subject: Re: distribute-list
> > > >
> > > >
> > > >> A general comment here that might help in understanding.
> > > >>
> > > >> "Redistribution" is a Cisco term that is rather awkward, but has
> >been
> > > >> adopted by the industry. There are less ambiguous terms I'll
> >mention
> > > >> in a minute.
> > > >>
> > > >> But I like to explain what "redistribute" means by expanding the
> >grammar:
> > > >>
> > > >> router foo
> > > >> redistribute bar default-metric x
> > > >> distribute-list y in
> > > >>
> > > >> means
> > > >>
> > > >> redistribute bar information, with filters y and foo metric
x,
> >into
> > > >foo.
> > > >>
> > > >> The more general terms are import and export. Redistribution is
> > > >importing:
> > > >>
> > > >> import bar into foo [optional filters and actions]
> > > >>
> > > >> Export is like a distribute-list out.
> > > >>
> > > >>
> > > >>
> > > >> At 7:09 AM -0800 3/11/02, Bhisham Bajaj wrote:
> > > >> >mannan
> > > >> >
> > > >> >thank u
> > > >> >
> > > >> >i got the point and by now know how wrong i was in
> > > >> >understanding redistribution
> > > >> >
> > > >> >thank u
> > > >> >Reg
> > > >> >bajaj
> > > >> >
> > > >> >--- Mannan Venkatesan <mv70@lucent.com> wrote:
> > > >> >> Bajaj,
> > > >> >> Yigit is correct. "out" option works differently
> > > >> >> when you use it with a RP.
> > > >> >> If you use it with interface, it will filter the
> > > >> >> routes sending out of that
> > > >> >> interface.
> > > >> >>
> > > >> >> It you use it with RP, it will filter the routes
> > > >> >> from the RP being
> > > >> >> redistributed.
> > > >> >>
> > > >> >> HTHs,
> > > >> >> Mannan
> > > >> >>
> > > >> >>
> > > >> >> ----- Original Message -----
> > > >> >> From: "A Yigit Zorlu" <alec_cisco@yahoo.com>
> > > >> >> To: "'Bhisham Bajaj'" <bhishambajaj@yahoo.com>;
> > > >> >> "'Mannan Venkatesan'"
> > > >> >> <mv_lab@hotmail.com>; "'lab'"
> > > >> >> <ccielab@groupstudy.com>
> > > >> >> Sent: Monday, March 11, 2002 1:48 AM
> > > >> >> Subject: RE: distribute-list
> > > >> >>
> > > >> >>
> > > >> >> > Hi,
> > > >> >> >
> > > >> >> > If you would using distribute-list 1 out serial 0
> > > >> >> you were correct. But in
> > > >> >> > this case it filters routes coming out of EIGRP
> > > >> >> into OSPF. Same for
> > > >> >> > connected. Same for IPX as well
> > > >> >> >
> > > >> >> > ipx nlsp
> > > >> >> > redistribute eigrp 1
> > > >> >> > distribute-list 7 out eigrp 1
> > > >> >> > from EIGRP into NLSP.
> > > >> >> >
> > > >> >> > Thanks,
> > > >> >> >
> > > > > >> > Yigit
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:01 GMT-3