Innokenty,

I'm replying to this list post since it includes your picture. This
is certainly a valid topology. However, a better solution exists
today. You simply configure two instances of OSPF and selectively
redistribute between them. IMHO, it is preferably to treat the
two sets of prefixes as separate routing domains than to the
advertise the prefixes and filters preventing their use.

Thanks,
Acee

Innokenty Rudenko wrote:
> Alex,
>
> I think you have a very valid point on whether the proposed route filtering
> technology is worthwhile. Here're my thoughs on that:
>
> I see three possible uses of route filtering.
>
> 1. To reduce route calculation by decreasing the number of network prefixes
> for which the calculation is needed.
> 2. To divert the traffic at a router closest to the source if the traffic
> is "denied" a certain destination. For example:
> | |
> | <-- route filter --> |
> i1| i2|
> +--+--+ +--+--+
> | R1 | | R2 |
> +++++++ +++++++
> / \ \ / / \
> / -\--\--------------/ / \
> / / \ \ / \
> / / \ --------------/----- \
> / / \ / \ \
> / / \ / \ \
> +-+---+-+ +-+----------+-+ +-+---+-+
> NP1 NP2 NPn
>
> Routers R1 and R2 interconnect a set of networks NP1 through NPn. They
> route among these networks, however they should not advertise them through
> uplink interfaces i1 and i2. With a DV routing protocol you would implement
> route filter on i1 and i2, which denies NP1 through NPn.
>
> (One practical application of this: NP1 through NPn are used to host a
> bunch of servers. These servers to the rest of the world are represented by
> one or more virtual IP addresses advertised by R1 and R2. R1 and R2 would
> do server load balancing to actually forward the traffic to the servers.)
>
> 3. To deny knowledge of certain network prefixes to the destinations
> towards which the filtering is performed.
>
> As you Alex pointed out it's unlikely that the first goal is achievable. As
> Dijkstra starts with the router itself being the root of SPT it won't even
> have any destinations to which to apply the filtering policy.
>
> While the filtering policies do not help the performance of Dijkstra, I do
> not think that they adversely affect it either. You can handle filtering
> policies almost the same way you do next-hops. You simply propagate them
> down SPT from the links on which they first appear. So, certain vertices
> will have one or more filtering policies which will be applied to the
> routes for the network prefixes derived from the vertices.
>
> There will be additional processing associated with actually applying the
> filtering policies, hence one might want to optimize them (binary decision
> diagrams come to mind).
>
> The second goal is perfectly achievable with the proposed implementation of
> route filtering.
>
> The third goal is not achievable for an obvious reason -- all the routers
> still have the same topological picture of the network.
>
> So the question is is the proposed mechanism worth while given it can only
> help achieve one out of thee purposes of route filtering? I think it may be
> worth the while because:
>
> 1. It does not introduce any dramatic changes to the current OSPF
> specification.
> 2. In does not inflict significant additional processing on the routers.
> 3. The routers with the proposed route filtering capability may coexist
> with the routers that do not have it. Obviously the usage of the proposed
> route filtering policing would (most likely) require all of the routers to
> be capable of it.
>
> Finally, the second purpose of route filtering is really specific to the
> enterprise users of OSPF. Typically the enterprise users could care less
> about the reducing the impact of route calculations, yet they do care a lot
> about limiting where the traffic can go to (use #2). (For one, it helps
> deny the use of the network as the transport for malicious attempts to
> compromise the security of certain destinations.)
>
> Innokenty.
>
>
> On Tue, 12 Mar 2002 15:01:57 -0800, Alex Zinin <azininNEXSI.COM> wrote:
>
>
>>Innokenty,
>>
>>I'd like to hear whether other people believe that
>>such a mechanism would be interesting and why, but here's
>>my first thoughts on what's been discussed:
>>
>> 1. Architectural concern: one of the reasons why people
>> use route filtering is to decrease the amount of
>> state maintained by routers and the CPU load on them.
>>
>> A mechanism discussed here would not decrease state
>> (all LSAs are still flooded and maintained), but in
>> fact would even increase it (we have new LSAs ensuring
>> consistent decisions). The same can be said about
>> the CPU load (see below).
>>
>> 2. Technical concern: During calculation of SPT over
>> the topology graph, Dijkstra has no idea of prefixes,
>> i.e., it produces the SPT from a given node to all
>> other nodes. Note that the SPT is shared among all
>> prefixes. Regardless of which method is used to address
>> this, we'll finaly end up spending more CPU and memory,
>> which goes back to the architectural question.
>>
>>Perhaps we should first answer the question "what is the real
>>problem we're trying to solve here?" :)
>>
>>Regards.
>>--
>>Alex Zinin
>>
>
>

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