Sunday, March 10, 2013

Troubleshooting OSPF - Why routes are not in the routing table?

I was checking something out today in one of our core routers and came up on an issue that got me going around in circles for a while. So I decided it would be useful to post about it. I have studied the CCNP material and I can assure you that this is NOT covered in the CCNP material. However, if you are going for your CCIE then you should know this. 

Basic setup of the routers is as follows. 
Now the issue was R2 wouldn't learn the route from R1 as I would have expected. Why?? Well it took me a while and I started to tear apart the OSPF database, cost, filtering, etc but nothing seemed out of the ordinary. So let's walk through the troubleshooting process and see how I got my answer.
Why am i not learning the from R1 on R2??
Notice that on R2 is learned via R3 ( Why??
Checksum looks fine on 
The external route (O E2) is in the database from R1 and looks fine the cost looks ok. 
Well here it is ... the answer to my question "why isn't the route from OSPF making it into the routing table?" ... OSPF network type mismatch stopped the route from being inserted into the routing table. R1 was set to point-to-point and R2 was set to broadcast (by default). Just a refresher -- OSPF interface could be set to multiple network types.
  • Broadcast
  • Point-to-Point
  • NBMA
  • Point-to-Multipoint
  • Point-to-Multipoing NonBroadcast
  • Loopback

Since the hello/dead/ and all other timers matched between R1 and R2 the OSPF neighborship came up but OSPF will not insert routes from the neighbor if there is a network type mismatch.

Another way to spot this. 

Notice one states transit network and the other point-to-point. 
Once I changed the R1 to broadcast everything was good to go. As you can see R2 is now learning the route from R1.

Have you run into this..?

Many more articles to come so stay tuned.

Please reshare/subscribe/comment/+1 if you like my posts as it keeps me motivated to write more and spread the knowledge.