[OSPF distribute-list query] Why should a route **NOT** be denied from the OSPF database?

[ananda123]

Hello Routing/Route-Filtering Experts,

I have a query reg. OSPF Route Filtering via "distribute-list" using acl.

The documentation available in internet says, a route is denied only from the IP Routing Table and **NOT** from the OSPF Database. WHY ???

What happens if the Route is denied from the OSPF database as well ?? If there multiple issues with that, please list all the possible cases.

Regards,

Anand

[Peter Paluch]

Hi Anand,

The documentation available in internet says, a route is denied only from the IP Routing Table and **NOT** from the OSPF Database. WHY ???

Because in link-state routing protocols, all routing information is contained in LSAs, and a particular LSA may be modified only by its originating router. Another router cannot "erase" a network address entry from an LSA that was originated by another router. Doing so would result in different routers woring with different link-state databases which is illegal.

The same goes for summarization in link-state protocols. A summarization would also constitute modifying the topological and routing information originated by other routers. Therefore, it cannot be performed inside an area - only at area borders where the routing information is reoriginated by area border routers and injected into other areas.

Best regards,

Peter

[ananda123]

Hi Peter,

Thanks for the quick reply. Apprciate your precise answer.

But I still have few doubts (Apologies for too many queries in a single post ):

Considering a topolgy like this:

[Router_A] eth1--------eth1 [Router_B] eth2------------eth2[Router_C]                       // OSPF is enabled on all the devices

1) Do you mean to say an LSA received by Router_B (from Router_A) is directly forwarded to Router_C without any modifcation?

2) Doesn't Router_B store the information from the LSA (received from Router_A) into its OSPF database and then originate a NEW LSA for Router_C ?

3) When you say denying the route froms the OSPF database i illegal, are there any supporting documents or links that mention the same?

4) Also from command output perspective, If a route is denied by distribute-list:

• show ip route      // The denied route should not be visible here - Right ?
• show ip ospf route  // Should it be denied here also?
• show ip ospf database  // As per your reply, it should NOT be denied here - Right?

5) What is the difference between the "show ip ospf route" and "show ip ospf database"? Does "show ip ospf route" also display the routes from the OSPF database only (or) Is a seperate OSPF Routing Table is maintained?

6) If it is a seperate OSPF routing table, when is this table useful/referred ? What is the use of this?

Lastly, Denying a route from the IP Routing Table, but not from the OSPF Database might help in maintaing the same link-state database by all the OSPF Routers, BUT Doesn't it create black holes?

For Example,

Considering the same topolgy (as mentioned above):

[Router_A] eth1--------eth1 [Router_B] eth2------------eth2[Router_C]                       // OSPF is enabled on all the devices

If I add a static route (1.1.1.1/32) in Router_A and redistribute it via OSPF, and say if we deny that route via adistribute-list in Router_B (from getting installed in the IP Routing table, but still present in OSPF database) ,

Then, since the route is still present in the OSPF database, the route will be advertised to Router_C and Router_C will install this route in its IP Routing table (Note: distribute-list is configured only in Router_B and is not configured in Router_C).

Now, since Router_C has the route (1.1.1.1/32) in its IP Routing table with next hop as Router_B, a user might think that he can reach that route. BUT actually he can’t (ping from Router_C to 1.1.1.1 fails) as Router_B cannot forward it further since it does not have route to 1.1.1.1/32 in its IP Routing table (as it is denied by distribute-list).

So, seems like there is no use (rather it is misleading, consumes some extra resources of entries in the database and also SPF calculation, LSA construction and advertising overhead) to hold and advertise a route which is denied from the IP table.

Does it still make sense to keep a route (denied from the IP Routing Table) in the OSPF database and advertise it even though one can not reach it?

Regards,

Anand

[Peter Paluch]

Hi Anand,

1) Do you mean to say an LSA received by Router_B (from Router_A) is directly forwarded to Router_C without any modifcation?

Exactly. Only the LS Age is incremented by one on subsequent router but the LSA contents themselves are not modified in any way.

2) Doesn't Router_B store the 
information from the LSA (received from Router_A) into its OSPF database
 and then originate a NEW LSA for Router_C ?

No. The Router_B receives the LSA from Router_A, stores it in its database and floods it without modification through all remaining interfaces, thus towards to Router_C. Only the LS Age is incremented which is a non-issue for our discussion here.

3) When you say denying the route froms the OSPF database i illegal, are
 there any supporting documents or links that mention the same?

I did not say exactly that. I have said that it is illegal for different OSPF routers in the same area to have different link-state database contents. The reason is clear and it follows from the very algorithm that the OSPF uses to compute shortest paths: each router must see the network in the same way, otherwise two routers could arrive at conflicting shortest path routes during calculation - in the worst case, they could form a routing loop. Also, the RFC 2328 about OSPF stresses multiple times that routers in a single area "maintain an identical database describing the topology". Try to look for the word "identical" in the RFC 2328.

4) Also from command output perspective, If a route is denied by distribute-list:
show ip route      // The denied route should not be visible here - Right ?
show ip ospf route  // Should it be denied here also?
show ip ospf database  // As per your reply, it should NOT be denied here - Right?

I do not know the "show ip ospf route" command. Perhaps it is a new command in 12.4T - I will have a look later. The route that is filtered out by a distribute-list should not be visible in the "show ip route" but it should be visible in the "show ip ospf database".

5) What is the difference between the "show ip ospf route" and "show ip 
ospf database"? Does "show ip ospf route" also display the routes from 
the OSPF database only (or) Is a seperate OSPF Routing Table is maintained?

I have to familiarize myself with the "show ip ospf route" command - I cannot answer this question momentarily. In any case, the RFC 2328 itself calls for a separate routing table maintained by the OSPF. That routing table is only a conceptual component, it does not have to be implemented as a routing table, merely only as a data structure holding the shortest paths computed by the SPF algorithm. It is possible that the IOS in recent versions allows you to display the contents of this routing table. In such case, yes, it would be a separate table that should actually not be called a true routing table because it is not used to route packets, only merely to hold the shortest paths found by the SPF algorithm in OSPF.

I will answer the rest of your post later.

Best regards,

Peter

[ananda123]

Thanks a lot Peter for your detailed reply.

I am awaiting for your comments on this:

Denying a route from the IP Routing Table, but not from the OSPF Database might help in maintaing the same link-state database by all the OSPF Routers, BUT Doesn't it create black holes?

For Example,

Considering the same topolgy (as mentioned above):

[Router_A] eth1--------eth1 [Router_B] eth2------------eth2[Router_C]                       // OSPF is enabled on all the devices

If I add a static route (1.1.1.1/32) in Router_A and redistribute it via OSPF, and say if we deny that route via adistribute-list in Router_B (from getting installed in the IP Routing table, but still present in OSPF database) ,

Then, since the route is still present in the OSPF database, the route will be advertised to Router_C and Router_C will install this route in its IP Routing table (Note: distribute-list is configured only in Router_B and is not configured in Router_C).

Now, since Router_C has the route (1.1.1.1/32) in its IP Routing table with next hop as Router_B, a user might think that he can reach that route. BUT actually he can’t (ping from Router_C to 1.1.1.1 fails) as Router_B cannot forward it further since it does not have route to 1.1.1.1/32 in its IP Routing table (as it is denied by distribute-list).

So, seems like there is no use (rather it is misleading, consumes some extra resources of entries in the database and also SPF calculation, LSA construction and advertising overhead) to hold and advertise a route which is denied from the IP table.

Does it still make sense to keep a route (denied from the IP Routing Table) in the OSPF database and advertise it even though one can not reach it?

Regards,

Anand

[Peter Paluch]

Anand,

Okay, let's try to answer some more of your questions.

First of all, did you mean the command show ip ospf rib? That command indeed displays the local routing table computed by the OSPF process. Contents of this table are then attempted to be installed into the actual routing table of the router.

I have verified that if a distribute-list is used, the denied route will be removed only from the routing table. It will not be removed from the topology database (show ip ospf database) neither from the OSPF RIB (show ip ospf rib).

Denying a route from the IP Routing Table, but not from the OSPF 
Database might help in maintaing the same link-state database by all the
 OSPF Routers, BUT Doesn't it create black holes?

Of course it does! Look... the distribute lists are not an OSPF component, nor are they mandated by its specification. Distribute lists are IOS tools. They are often used in distance vector protocols and so customers undoubtedly called for a similar functionality in the OSPF as well. However, that is easier said than done - in link state protocols, you can't simply filter out networks in the link state database to your liking because it would mean modifying someone else's LSAs which is prohibited. So if a customer insists on having the distribute list functionality in the OSPF, it can be done only by not installing the resulting routes into the routing table. But the LSAs may not be modified.

Using distribute lists in OSPF means that a black hole, suboptimal routing or a routing loop can occur very easily. So if you intend to use distribute lists in OSPF, you must manually apply them on all routers in an area and keep them synchronized manually. This is a structural disadvantage of link state protocols given by their fundamental principles.

Your scenario about the network 1.1.1.1/32 being present on Router_A, redistributed into OSPF, filtered out on Router_B and present again in Router_C is absolutely correct. This is a wonderful and obvious example of a black hole. I stress again that the distribute-lists are not by any means a part or a component of the OSPF protocol. They are unnatural to link state technology. Therefore, forcing them upon OSPF produces quite bizzare results that you see for yourself.

Does it still make sense to keep a route (denied from the IP Routing Table) in the OSPF database and advertise it even though one can not reach it?

You have absolutely no other option. As I stated multiple times, a router is absolutely prohibited from modifying foreign LSAs. So if you cannot modify foreign LSAs, you cannot filter out foreign networks. It's as simple as that. Customers wanted distribute lists even for OSPF - fine, they got it, but because distribute lists are artifical to OSPF, their entire usage is artificial as a result.

Best regards,

Peter