OSPF route advertise ment issue.

[Darren Frowen]

Hi,

I am having problems with a route not being learned by a neighbour device. I have three layer3 switches each connected and peering with each other using ospf over a VRF. Each device is connected via SVI’s point to point links. So I have three devices connected in a triangle as seen below;

                                             R1

                              R2                         R3--à 172.24.36.32/27 SVI

R3 has a local SVI 172.24.36.32/27, I have blocked this route being received by R1 using the distance 255 and acl on R1 under ospf process. R2 can see the route from R3 but R1 does not see the diverse path, via R2, I cannot figure out why this is the case. Would you be able to assist in fault finding the issue please?

Regards

Darren

[Peter Paluch · Accepted solution]

Darren,

You are approaching this issue from a "distance-vector" point of view. You believe that because you have prevented one of the paths to be used on R1, it will choose another available path.

This is not how link-state protocols like OSPF work. What you have done is only prevent OSPF from installing the route to 172.24.36.32/27 into the routing table. However, in its internal databases, OSPF still considers the direct connection from R1 to R3 to be the best path toward that network, and it has no reason to think otherwise unless the link truly goes down or becomes too costly. It does not really know that you have filtered out that particular route, and it does not care about other potentially worse paths. If you prevent R1 to install the best path to that network into its routing table then you basically filter out the only route OSPF is considering to be usable at the moment, and so you'll end up with having no route to the 172.24.36.32/27 whatsoever.

In OSPF, there is no way of selectively increasing the cost of chosen networks on a neighbor-to-neighbor basis. On all OSPF routers in a single area, the link-state database representing the entire area is identical, and so what one router knows and can see, all routers know and can see, and they compute their best paths based on this shared, common, identical knowledge of the network in an area. It is its underlying principle; it cannot be changed.

Best regards,
Peter

[Darren Frowen]

Peter Hi,

Thanks for the explanation very much appreciated. Is there a way to see the alternative path from R1's point of view for the destination 172.24.36.32/27. I am thinking about the EIGRP command "show ip eigrp topology" command where you can see the alternate paths, I have tried to see with the database command but only see the single path. How are you able to confirm from a router that it does actually have an alternative path without actually failing an interface to test it?

Regards

Darren

[Peter Paluch · Accepted solution]

Hi Darren,

In OSPF, there is no way to see a potential backup path from R1 to a destination network. Even in EIGRP, the feasible successors and resulting backup paths are in fact only a byproduct of how the loop prevention in EIGRP works. There are situations even in EIGRP where a router does not recognize a path as being loop-free - this is because the Feasible Condition is a sufficient, not a necessary condition, which means that each path satisfying the Feasible Condition is loop-free, however, not every loop-free path satisfies the Feasibility Condition.

In general, routing protocols are designed as reactive mechanisms - they deal with an event only after it takes place. What you are asking for is a proactive approach in which the routing protocol thinks ahead and calculates alternative paths for a set of possible events before they even happen. This is actually a realm of what we call Fast ReRoute (FRR) - having a router precompute backup paths and have them ready in case something happens on the current best path. The area of FRR mechanisms is quite large and complex because one of requirements on FRR is that ideally, no prior coordination, or only a very little coordination with neighboring routers should be required during backup path precomputation and switchover. If extensive coordination was required, an FRR would not be much better than the routing protocol itself. This means that, similarly to EIGRP, FRR mechanisms have different repair coverage and depending on how they internally work, they may fail to identify a possible backup path.

FRR support is not widespread in Cisco IOSes. From what I know, Cisco IOSes may support so-called LFA (Loop-Free Alternate) and rLFA (Remote Loop-Free Alternate) mechanisms even though there is perhaps a dozen of these mechanisms available. You may try to look up these mechanisms for your devices and IOSes but as far as I know, these are mostly supported only on service provider grade routers.

Best regards,
Peter

[Darren Frowen]

Hi Peter,

Thanks again for coming back to me. Yes had come to the conclusion of the back up path within OSPF I was just to used to seeing EIGRP topology and BGP outputs over the years and expecting to see the same with OSPF. Yes I had read the FRR but unfortunately it is not supported on the old 3750's we are using for this function. Thanks again for all your help on this matter is has been very much appreciated.

Regards

Darren