From: ying chang (ying_c@xxxxxxxxxxx)
Date: Mon Mar 11 2002 - 20:19:44 GMT-3
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:00 GMT-3