OSPF Troubleshooting - Networking Essentials

Troubleshooting at a Glance

Start with the lowest failed layer. A route cannot appear until the interface works, OSPF runs on it, neighbors exchange LSAs, and the router accepts the best path.

Layer 1Interface and IP

Layer 2OSPF neighbor

Layer 3LSDB evidence

Layer 4Route and traffic

Golden rule: Do not change configuration until you can state the symptom, expected result, and failed layer. Capture evidence first; fix one cause at a time.

In This Lesson

Build a known-good baseline
Follow the five-layer workflow
Check interfaces and OSPF activation
Use the neighbor state as a clue
Compare both ends of the link
Trace the expected LSA
Solve Full-neighbor but missing-route cases
Prove the forwarding and return paths
Use debugging safely
Use the incident runbook
Complete guided fault labs
Review the frequently asked questions

1. Build a Known-Good Baseline

Use three routers in Area 0. R1 owns 10.1.1.0/24, R3 owns 10.3.3.0/24, and R2 provides the transit path. Confirm this simple network works before creating any fault.

R1RID 1.1.1.110.1.1.0/24

10.0.12.0/30FULLArea 0

R2RID 2.2.2.2Transit router

10.0.23.0/30FULLArea 0

R3RID 3.3.3.310.3.3.0/24

Healthy baseline: both adjacencies are Full, every router has the expected LSAs, and R1 can reach R3's loopback in both directions.

Save neighbor evidence

R2# show ip ospf neighbor

Neighbor ID  State    Interface
1.1.1.1      FULL/-   GigabitEthernet0/0
3.3.3.3      FULL/-   GigabitEthernet0/1

Save route evidence

R1# show ip route ospf
O 10.3.3.0/24 [110/3] via 10.0.12.2

R1# ping 10.3.3.3 source 10.1.1.1
Success rate is 100 percent

Why a baseline matters: After introducing one fault, the changed output tells you what the fault actually affected. Without a baseline, normal OSPF behavior can look like a problem.

2. Follow the Five-Layer Workflow

Move from left to right. Stop at the first failed check and repair that layer before investigating the next one.

1

Interface

Is the link up/up with correct addresses and MTU?

2

OSPF enabled

Is the interface active in the correct process and area?

3

Neighbor

Do parameters match, and is the expected state reached?

4

LSDB

Did the correct LSA reach this router?

5

Route and traffic

Was the route installed, and can packets return?

Layer	Fast command	Healthy evidence
Interface	`show ip interface brief`	Status and protocol are up
OSPF activation	`show ip ospf interface brief`	Correct process, area, cost, and state
Neighbor	`show ip ospf neighbor`	Expected peer and stable state
Database	`show ip ospf database`	Expected LSA and advertising router
Route	`show ip route ospf`	Expected prefix, metric, and next hop

3. Check Interfaces and OSPF Activation

If no neighbor appears, begin here. OSPF cannot exchange Hellos over a failed, incorrectly addressed, passive, or unselected interface.

Physical and IP checks

show ip interface brief
show interfaces GigabitEthernet0/0
show ip interface GigabitEthernet0/0
show arp

OSPF activation checks

show ip ospf interface brief
show ip ospf interface GigabitEthernet0/0
show ip protocols
show running-config | section router ospf

Interface state: Both status values should normally be up/up.
Addressing: Both ends of a direct link must use compatible addresses and masks.
Area: The two connected interfaces must use the same OSPF area.
Passive interface: A passive interface advertises its network but does not send Hellos or form neighbors.
Network statement: Confirm the wildcard mask actually selects the intended interface.

4. Use the Neighbor State as a Clue

The state is not just a status label. It tells you how far the adjacency progressed and which part of the exchange failed.

Observed state	What it means	Check first
No neighbor or DOWN	No valid Hello received	Interface, subnet, OSPF activation, passive state, ACL, multicast
INIT	Hello received, but the local router is not listed in it	One-way link, return traffic, ACL, switch path
2-WAY	Two-way Hello exchange completed	Normal between DROTHER routers on broadcast LANs; otherwise check network type and election
EXSTART or EXCHANGE	Database description exchange cannot complete	MTU mismatch, duplicate router ID, unstable link
LOADING	Router is requesting missing LSAs	Packet loss, retransmissions, CPU, or a damaged LSA exchange
FULL	Required databases are synchronized	If a route is missing, move to LSDB and route installation

Important exception: Two DROTHER routers on the same broadcast Ethernet segment normally remain 2-Way with each other. They form Full adjacencies with the DR and BDR. Do not repair normal behavior.

5. Compare Both Ends of the Link

Never inspect only one router. Place the two interface outputs side by side and compare the values that must agree.

R1 interface evidence

R1# show ip ospf interface GigabitEthernet0/0
  Internet Address 10.0.12.1/30, Area 0
  Network Type POINT_TO_POINT, Cost 1
  Timer intervals: Hello 10, Dead 40
  Message digest authentication enabled

R2 interface evidence

R2# show ip ospf interface GigabitEthernet0/0
  Internet Address 10.0.12.2/30, Area 1
  Network Type POINT_TO_POINT, Cost 1
  Timer intervals: Hello 10, Dead 40
  Message digest authentication enabled

Parameter	Must agree?	Typical failure
Area ID and area type	Yes	No adjacency
Hello and dead timers	Yes	No adjacency or repeated resets
Authentication method and secret	Yes	Packets rejected
Network type	Operationally compatible	Stuck state, election, or timer problems
MTU	Should match	EXSTART/EXCHANGE
Router ID	Must be unique	Adjacency or LSDB instability
OSPF process ID	No	Locally significant only

Fault in this example: R1 uses Area 0 while R2 uses Area 1. Correct the wrong area assignment; do not change timers, authentication, or unrelated routing policy.

6. Trace the Expected LSA

If the neighbors are healthy, ask whether the route's LSA reached the router. Search for the prefix and identify the advertising router and LSA type.

Search the database

show ip ospf database router 3.3.3.3
show ip ospf database summary 10.3.3.0
show ip ospf database external 172.16.50.0
show ip ospf database nssa-external

Connect LSA type to location

Type 1  Router topology inside one area
Type 2  Broadcast network from the DR
Type 3  Inter-area prefix from an ABR
Type 5  External prefix from an ASBR
Type 7  External prefix inside an NSSA

Confirm the source router advertises the connected or redistributed prefix.
Confirm the expected LSA exists in the source area.
Follow it across the ABR or ASBR boundary.
Find the first router where the LSA disappears; inspect policy at that boundary.

7. Solve “Neighbor Full but Route Missing”

A Full neighbor proves database synchronization with that peer. It does not prove that every prefix was originated, allowed across an area boundary, or selected for the routing table.

Evidence	Likely cause	Next action
Prefix absent from source LSDB	Interface not advertised or redistribution policy denies it	Check source OSPF activation and route map
LSA stops at an ABR	Area filter, summarization, or stub-area rule	Inspect ABR policy and area type
LSA present, OSPF route absent	Distribute list, unreachable forwarding address, or better route	Check local policy and all route sources
Summary present, component absent	Intentional summarization	Verify the summary and component reachability
External LSA present, no route	Forwarding address or ASBR path is unreachable	Check reachability to the forwarding address and ASBR

Inspect one prefix

show ip route 10.3.3.0
show ip route ospf
show ip ospf database | include 10.3.3.0
show ip prefix-list
show route-map

Look for a competing route

R1# show ip route 10.3.3.0
Routing entry for 10.3.3.0/24
  Known via "static", distance 1

The static route wins over OSPF AD 110.

8. Prove the Forwarding and Return Paths

A route in the table is not the end of troubleshooting. Test the correct destination from a useful source address, then confirm that the destination knows how to reply.

Test the forward path

R1# ping 10.3.3.3 source 10.1.1.1
R1# traceroute 10.3.3.3 source 10.1.1.1
R1# show ip cef 10.3.3.3 detail

Prove the return path

R3# show ip route 10.1.1.0
R3# ping 10.1.1.1 source 10.3.3.3
R3# traceroute 10.1.1.1 source 10.3.3.3

Wrong next hop: Inspect path selection, cost, and competing route sources.
Route exists but traffic fails: Check ACLs, firewall policy, CEF, and the return route.
Asymmetric path: It can be valid, but stateful devices may require both directions to follow an allowed path.

9. Use Debugging Safely

Use show commands first. Debug only the narrow behavior you need, watch it for a short time, and disable it immediately after collecting evidence.

Focused debug commands

debug ip ospf adj
debug ip ospf hello
debug ip ospf packet

undebug all

Safer passive evidence

show logging | include OSPF
show processes cpu sorted
show interfaces counters errors
show ip ospf statistics
show ip ospf retransmission-list

Production safety: Packet debugging can generate heavy output and consume CPU. Use an approved maintenance process, send output to a controlled destination, and always know how you will stop the debug.

10. Use This Incident Runbook

This short sequence keeps troubleshooting focused during an outage.

Phase 1: Define and Protect

State the affected prefixes, routers, and start time.
Confirm whether the problem affects one path, one area, or the whole domain.
Record recent changes and protect current evidence.
Avoid clearing OSPF or reloading a router before diagnosis.

Output: A precise symptom and a safe investigation scope.

Phase 2: Find the First Failed Layer

Check interfaces and addressing.
Check OSPF activation and areas.
Check neighbor state on both ends.
Trace the LSA, route, next hop, and return path.

Output: Evidence that points to one layer and one likely cause.

Phase 3: Repair and Prove

Change only the confirmed faulty setting.
Confirm neighbors and LSDBs stabilize.
Test affected and unaffected prefixes.
Save after-state output and document prevention.

Output: Restored service with proof, rollback awareness, and a useful incident record.

11. Guided Fault Labs

Begin with the healthy three-router baseline. Introduce only one fault per task and restore it before moving to the next task.

Task 1: Repair an Area Mismatch

Change R2's interface toward R1 from Area 0 to Area 1.
Confirm the physical interface remains up/up.
Compare show ip ospf interface on R1 and R2.
Restore Area 0 on R2.
Prove the neighbor returns to Full and routes recover.

Expected result: You identify the area mismatch without changing timers, authentication, or the OSPF process ID.

Task 2: Diagnose EXSTART

In an isolated lab, create an MTU mismatch on the R2–R3 link.
Watch the neighbor state without immediately debugging.
Compare interface MTU values on both routers.
Correct the underlying MTU mismatch.
Confirm database exchange completes and the state reaches Full.

Expected result: You connect EXSTART/EXCHANGE to the database-description and MTU checks.

Task 3: Solve Full but Missing Route

Keep all adjacencies Full.
Apply a local inbound OSPF distribute list on R1 for 10.3.3.0/24.
Confirm the LSA remains in R1's LSDB.
Confirm the route is absent from R1's routing table.
Remove the policy and prove route and traffic recovery.

Expected result: You explain the difference between LSDB flooding and local route installation.

Task 4: Find a Return-Path Failure

Confirm R1 has a route toward R3's loopback.
Remove or filter R3's route back to R1's loopback in the lab.
Test with explicit source addresses.
Trace both traffic directions.
Restore the return route and verify success.

Expected result: You prove that a correct forward route alone does not guarantee successful communication.

12. Frequently Asked Questions

What should I check first when an OSPF neighbor disappears?

Check interface state, IP addressing, subnet masks, and whether OSPF is active on the interface. Then compare area, timers, authentication, network type, and MTU on both ends.

Is every 2-Way neighbor state a failure?

No. Two DROTHER routers on a broadcast network normally remain 2-Way with each other. They form Full adjacencies with the DR and BDR.

Why is my neighbor stuck in EXSTART or EXCHANGE?

An MTU mismatch is a common cause because database description packets cannot be agreed upon. Also check duplicate router IDs, packet loss, and link stability.

Why is the neighbor Full but the OSPF route is missing?

The route may not have been originated, its LSA may be filtered at a boundary, a local distribute list may block installation, the forwarding address may be unreachable, or a better route source may already own the prefix.

Do OSPF process IDs need to match between neighbors?

No. The process ID is locally significant. The connected interfaces must agree on neighbor-forming parameters such as area, timers, authentication, and compatible network behavior.

Should I use ip ospf mtu-ignore to fix an MTU mismatch?

Prefer correcting the real interface or path MTU so control-plane and data-plane behavior agree. MTU ignore can hide the adjacency symptom while leaving packet-forwarding problems.

When should I clear the OSPF process?

Only when the confirmed change requires it and the operational impact is understood. Clearing the process drops adjacencies and triggers route recalculation, so it is not a first troubleshooting step.

OSPF Troubleshooting: Find the Fault Layer by Layer