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 4.4.4.4/32 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 4.4.4.4/32 from R1 on R2?? |
 |
| Notice that on R2 4.4.4.4/32 is learned via R3 (3.3.3.3). Why?? |
 |
| Checksum looks fine on 4.4.4.4/32. |
 |
| 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 4.4.4.4/32 from R1.
Have you run into this..?
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.
CCNA course :
ReplyDeleteTwo routers may not form an OSPF adjacency if:
- The subnet masks do not match, causing the routers to be on separate networks.
- OSPF Hello or Dead Timers do not match.
- OSPF Network Types do not match.
- There is a missing or incorrect OSPF network command.
In addition, MTU mismatch on the outgoing interface of the Hello packets will cause the router to get stuck in EXSTART phase. Mismatch authentication will also cause the routers to not form adjacency.
Delete**OSPF Network Types do not match - That is not true. There is no RFC which states that the Network Type has to match, however different network types may have different hello/dead timers which will cause the adjacency not to form. As you can see from above the adjacency between two routers was successful even though there was a network type mismatch (but the timers matched) -- one was set to point to point and the other to broadcast.
R1 & R2 will become neighbors because of their area id is same & valid next hop address but won't form adjacency so there is no exchange of link state database
ReplyDeleteI disagree, slightly. As you can see from the example the adjacency does form and the LSDB is in fact exchanged. That is what makes this issue sort of nasty - everything "looks" normal.
DeleteThe problem is that when the SPF calculations are run the LSDB has an inconsistency with the Router LSAs (type 1) between the networks R1 thinks it is attached to and the networks R2 thinks it is attached to. Therefore the SPF calculations fail and the routes are not inserted into the RIB.
Yes I have seen a similar problem in a TS example. In your case timers matched so the adjacency formed! However p2p and broadcast types are compatible and will cause exactly the problem you describe.
ReplyDeleteIn the OSPF one side of the link between R2 and R1 is described with Network link and router records. However this is not the same for R1's view of the network.
If both R1 and R2 view of the network don't match then OSPF will not allow the routes to use this this path. There is good coverage of this in Moy and also in the RFC.
Nice tutorial.
ReplyDelete