OSPF troubleshooting: five checks before the rabbit hole
Start with reachability, interface settings and neighbor state before blaming the entire protocol.
1. Establish the symptom
Is a neighbor missing, stuck in a state, or Full while a route is missing? Those are different investigations. Record what you expected, what you saw and when it changed.
2. Check the link and participation
Confirm interfaces are up and have the expected addressing. Verify OSPF is enabled on the intended interface and that passive-interface settings are intentional. Check that filters permit OSPF IP protocol 89; it does not use a TCP or UDP port.
3. Compare both ends
Check area ID, Hello and Dead intervals, authentication and area options. Check subnet masks where the network type requires them. Network-type differences can create misleading states even when Hellos are received.
4. Let the state narrow the search
No neighbor: follow Hellos. Init: investigate one-way communication. ExStart/Exchange: compare MTU and inspect database-description exchange. Loading: investigate missing LSAs. Full: move on to LSDB and routing policy rather than endlessly resetting the adjacency.
5. Follow a missing prefix
Does the expected LSA exist? Is the route intra-area, inter-area or external? Can the next hop or forwarding address be resolved? Is another route source preferred? Remember that a Full adjacency does not guarantee every expected route is installed.
Make the fix small
Save observations before changing anything. Change one evidenced cause, verify recovery, and remove temporary diagnostics. A process reset is disruptive and can hide the original failure.
Print the troubleshooting flowchart.
Protocol reference: RFC 2328 (OSPFv2). NSSA reference: RFC 3101.