Manral,

On Mon, 11 Mar 2002 23:53:59 -0500, Manral, Vishwas <VishwasMNETPLANE.COM>
wrote:

>Innokenty,
>
>I am not sure what you mean by
>
>> Whether the filtering policy conveyed
>> in the LSA applies or not will depend on whether a particular route (from
>> the perspective of the calculating router) goes through the corresponding
>> interface of the router on which the policy is applied.
>
>Are you talking about the path to destination D going thru the calculating
>router interface or just the nexthop? Please describe the exact policy you
>intend to make and the exact info you want to send?

10.1.1.0/24 10.1.2.0/24
 +---+---+ +---+---+
      \ /
       \ /
        \ /
         \ /
        +-+-+-+
        | R1 |
        +--+--+
           |
           |
        +--+--+
        | R2 |
        +--+--+
          /i2
         / <-- deny 10.1.1.0/24
        / permit any
       /
   +--+--+
   | R3 |
   +--+--+
       \
        \
         \
       +--+--+
       | R4 |
       +--+--+
         /
        .
       .

Router R1 is attached to two stub segments whose network prefixes are
10.1.1.0/24 and 10.1.2.0/24. Router R2 has a filtering policy assigned on
interface i2; from the diagram the policy denies the first network prefix
and permits the second one. Routers R3 and R4 will calculate the routes for
both network prefixes. However, when deciding whether to install the routes
they will check the policy and having done that they will install only the
route for the second network prefix (the permitted route). Router R2
however will install both routes as from its perspective none of the
routers goes through any interface with the route policy.

How to achieve this effect is a separate question. One way I imagine would
be to check the policy during Dijkstra calculation. If on some iteration a
route passes a link with a policy and the policy denies the network prefix,
the Dijkstra could label the route as denied. The label may be removed if
Dikjstra discovers a shorter path that does not cross a link with a deny
policy. If by the end of Dijkstra calculation the route is labeled as
denied, the route is not installed in the routing table.

>
>Let me make some things clear to you again. If you are applying a
particular
>policy to some routers and not to others, it could lead to routing
>loops/blackholes. If you use the second best route(which could result if
the
>best path traverses thru the filtering interface) on some routers it too
>will lead to routing loops.

That depends. If the policy denies the shortest route but does not prevent
the longer route for the same destination from being installed in the
routing table, then obviously routing loops can emerge. That's exactly the
case with dv protocols. If however the policy denies the shortest route and
the routing table update process does not try to install the longer one,
then no routing loops should occur.

In either case, routing information filtering is a manual interference with
normal routing protocol calculation procedure and as such may lead to
unforeseen consequences. Yet people do route filtering all the time. I
guess whoever resorts to route filtering should simply realize that they do
it at their own risk.

Innokenty.

>
>Thanks,
>Vishwas
>
>
>-----Original Message-----
>From: Innokenty Rudenko [mailto:irudenkoHOTMAIL.COM]
>Sent: Tuesday, March 12, 2002 3:05 AM
>To: OSPFDISCUSS.MICROSOFT.COM
>Subject: Re: route filtering
>
>
>Manral,
>
>>
>>1. Dijakstra should have the same topology at all nodes to make a loopfree
>>and blackhole free paths to destination.
>
>The topology should be the same as all the LSAs are flooded without any
>changes. In addition though, a new "filtering" LSA also needs to be
>flooded. The only purpose of this new LSA is to propagate the filtering
>policy.
>
>Regarding Dijkstra. I'm not sure at all if the filtering should take place
>during the Dijkstra calculation. What should happen however is that if a
>route that Dijkstra calculates as the shortest does go through a router,
>which is configured with the filtering policy that "denies" the route's
>network prefix, then the route must not be installed in the router's
>routing table. This is very similar to a route filtering in distance-vector
>protocols.
>
>>2. Because flooding is so done that all the routers in an area have the
>same
>>topology, so all routers behind R1/R2 in the samae area too would get that
>>"filtering" LSA.
>
>Yep. And that's what I think should happen.
>
>>3. If you are doing filtering(aggregation) it is best to do it at the ABR,
>>as you cannot have half the area have one set of LSA's and the other
>another
>>set. So any filtering anywhere would result in the same filtering in the
>>whole area.
>
>I'm not proposing to filter LSAs. What I'm proposing is to filter routes as
>they are installed in the routing table. For example Cisco allows
>configuring an OSPF "inbound distribute-list" for an interface, which works
>as follows: if OSPF is to install a route for a certain network prefix
>pointing to the interface on which the distribute list assigned, the router
>should then check if the distribute-list (ACL) "permits" the route. If it
>does, OSPF will install the route. Notice, Dijkstra should've already taken
>place; also, this process does not affect the integrity of the link state
>database. A similar effect is achieved if a routing protocol with the admin
>distance lower than that of OSPF installs a route for the same network
>prefix, then OSPF won't install its own route.
>
>>1. Do you mean we ask people to not add a particular route in their
>>database(filter LSA/routes)?
>
>The only change to the link state database that I'm proposing is this
>additional "filtering" LSA.
>
>>2. What is the exact advantage from filtering you gain in any router
within
>>in ur case(now that the flooding scope is the entire area)?
>
>The effect of the proposed filtering is similar to the "distance-vector"
>filtering. The advantage is that it significantly lowers the administrative
>burden of configuring "local" filtering on every router as OSPF will
>propagate the filtering policy and it will provide means to adequately
>apply the policy.
>
>The question is if there is a demand for this feature or not. I think there
>is and that's why I'm proposing it. If someone uses a routing protocol
>other than OSPF (RIP, E/IGRP, etc.) but considers migrating to OSPF, it's
>typical (at least in my experience) to hear something like "well, but how
>do I go about filtering? I definitely need to filter this route and that
>route, and though I do understand that I can use inbound distribute lists
>(if the routers are Cisco), it puts a lot of admin burden as I have to make
>sure that all the routers are configured with the same ACLs in the first
>place and also whenever I make a change to the filtering policy".
>
>>3. When you talk about filtering done as part of Dijakstra, do you mean
>>result of dijakstra/SPF tree?
>
>Not the tree, but the decision of whether or not to install the calculated
>shortest route into the routing table. Whether it is done during the
>Dijkstra calculation or not, I'm not sure. That's a detail that needs to be
>worked out.
>
>>4. Do you intend to use some special flooding mechanism to limit the
>>flooding of the LSA even within an area?
>
>Nope, just the standard flooding. In fact, I would want every router in the
>area to have the same filtering LSA. Whether the filtering policy conveyed
>in the LSA applies or not will depend on whether a particular route (from
>the perspective of the calculating router) goes through the corresponding
>interface of the router on which the policy is applied.
>
>Innokenty.
>
>>
>>Thanks,
>>Vishwas
>>
>>
>>-----Original Message-----
>>From: Innokenty Rudenko [mailto:irudenkoHOTMAIL.COM]
>>Sent: Monday, March 11, 2002 7:46 PM
>>To: OSPFDISCUSS.MICROSOFT.COM
>>Subject: route filtering
>>
>>
>>I'm not sure if it was brought up before. Anyway:
>>
>>One of the complains I've heard about OSPF is that one cannot filter
routes
>>the same way as he can do in the distance-vector routing protocols.
>>Obviously route filtering is available on ABRs; plus implementations often
>>allow for local route filtering whereby an OSPF route won't be installed
in
>>the routing table if it isn't "permitted" by an ACL. The latter however
>>won't have any effect on the other OSPF routers, which will install the
>>route unless they are also configured to filter it out. (In DV protocols
>>such a route won't be propagated to the other routers, hence won't be
>>installed unless an alternative path is available.)
>>
>>To address the issue, why not create a separate LSA type to propagate a
>>filtering policy. E.g.:
>>
>>
>> / /
>> / /
>> +--+-+ +--+-+
>> | R1 | | R2 |
>> +-+--+ +--+-+
>>Rt.Flt. / \ Rt.Flt.
>>-------> / \ <--------
>> / \
>> .......................
>> . .
>> . OSPF Routers .
>> . in the same area .
>> . .....................
>>
>>In the picture above the route filter is applied on routers' R1 and R2
>>interfaces leading to a group of networks in the same area shown as a
cloud
>>with a dotted border. R1 and R2 should then create a filtering LSA and
>>flood it to the other routers in the area. The OSPF routers in the area
>>when calculating their routing tables would check if a filter applies and
>>if so would not install the "denied" OSPF routes into the routing table.
>>
>>By "filter applies" I mean if the shortest path for a network prefix
>>actually goes through the router interface on which the filter is applied.
>>If the filter "permits" the network prefix, the route is installed,
>>otherwise it isn't.
>>
>>For example, if the filter "denies" some network prefix "above" routers R1
>>and R2, the routers "below" in the dotted area won't install routes for
it.
>>
>>This should ensure a "distance-vector protocol" like behavior of route
>>filtering in OSPF.
>>
>>Any thoughts on that?
>>
>>Some open questions would be:
>>1. Should filtering be done as a part of Dijkstra?
>>2. If a route is filtered, should alternative routes be considered for
>>installation in the routing table? Those routes will be longer and
>>therefore may potentially create a routing loop.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]