OSPF isn’t a particularly difficult routing protocol to implement, as long as you understand how it works and what it takes to configure. However, there are several common problems and config errors that you may come up against - here we describe some of the most usual problems and how to check that your network is working as it should.
OSPF routers that are directly connected should exchange Hellos and form neighbour relationships. On a point to point link, every neighbour relationship should also result in an adjacency being formed, but that’s not necessarily true where say several routers are connected to the same LAN segment—in this case they will only form an adjacency with the Designated Router (and BDR).
When an OSPF adjacency is formed between neighbours, a router goes through several state changes before it becomes fully adjacent with its neighbour. Until all required adjacencies have been formed, your network will not operate correctly. What you want to see is a steady-state something like this (extract from a Cisco router):
Router#show ip ospf neighbor
|Neighbor ID||State||Dead Time||Address||Interface|
This router has formed a full adjacency with the DR and BDR on this segment. It has one other neighbour that it knows about: it won’t form an adjacency with this one, but the 2WAY state means that there is bi-directional communication between them, which is normal on a broadcast medium. If this was a point to point link, it would indicate a problem, since 2WAY should change to FULL.
Anything else, including the following states is a cause for concern and needs to be rectified:
No entry of an expected neighbour ID: The router’s not aware that it’s supposed to be part of OSPF process on the interface to that expected neighbour. This means that generally it’s not receiving hellos.
Is the link up? If you can’t ping the other end of the link (which is directly connected and therefore doesn’t need a routing protocol to be reachable), you can’t expect OSPF to be running. Fix that problem first.
Make sure that the interfaces at both ends are configured to support OSPF and that if one end thinks it’s a point-to-point link, rather than a broadcast one, the other does too. Neighbouring interfaces must be in same area and area type (eg stub area). If a router is in more than one area, then it should have at least one interface in Area 0 (try if at all possible not to have to use virtual links). Dead and hello timers need to be the same at both ends. Without these correct, you won’t get neighbours formed, which means no adjacencies are possible.
INIT state: The router is seeing Hellos from that neighbour, but there’s still no two-way communication. It’s probable that your router is receiving Hellos, but the one at the other end isn’t seeing yours. Checks are as for the case above.
EXSTART/EXCHANGE: Things have started out okay but although there’s a relationship formed, the two routers have a problem. Often caused by vendor interoperability issues, typically MTU mismatches or something related to large packet sizes.
LOADING: If you see this, unfortunately you may have LSA corruption someplace. You may have to start taking pieces out of the network to fix this one.
Okay, it looks like your neighbours are set up, and you’re seeing the OSPF database getting populated from the LSAs, but routes are not appearing in the routing table. This is usually a config error, due to a topology mismatch somewhere.
First you need to identify if the problem is with all types of routes, or if it’s specific to summary routes or external routes. Summary route problems are often related to non-contiguous Area 0 issues. If it’s just external routes, and you find that there is an entry in the LSA database, but not in the routing table, it may be that the forwarding address associated with that route isn’t known as an internal route, in which case it won’t get included. Otherwise you’ll need to go to the originating router and check that the entry is there and that the router is set up correctly for redistribution.
Another surprisingly common problem results where you have two parallel links between a pair of routers, and you’ve got the interfaces crossed at one end so that the IP addresses don’t match at either end. They’ll quite happily form neighbour relationships and adjacencies (since OSPF doesn’t care about subnets at this stage) but the discrepancy will stop the routes from being advertised.
If things aren’t taking the path you expect, have a look at how the metrics are being calculated. Remember that the default path cost is 10 8 divided by the bandwidth. This gives both Fast Ethernet and Gigabit the same cost. You may need to scale up your cost settings to get differentiated route calculations, but be careful how you do this and make sure you fully understand how this may change your topology.
If you’re not seeing information shared amongst routers, check to see what access lists you have configured. If you have any problems, remove those access lists before you go any further - you can out them back later. Many people convince themselves it’s not an access list issue and waste far too much time looking for other problems that don’t exist.
Yes, it’s always recommended that you use authentication to make sure that you are only getting valid LSAs from authorised routers, but if you’re not receiving LSAs, particularly if this is a new deployment (it’s unlikely that authentication will suddenly stop working), turn it off and get the link working first.
If you’re adding a router, remember that you must use the same authentication type within the whole area - any area border routers will need authentication configured for each. It’s always possible that you could have mistyped an authentication key, but debugging the OSPF process should tell you that authentication is failing if this is the case.