An adjacency becoming Full validates database synchronization with that neighbor; it does not prove an application path.

Quick reference

State / item	Meaning	First check
Down / Init	No usable bidirectional hello exchange	Link, area, timers, filtering
2-Way	Bidirectional hellos	Can be normal between DROTHERs
ExStart / Exchange	Database negotiation / exchange	MTU, IDs, packet loss
Loading	Missing LSAs being requested	Loss and retransmission evidence
Full	Database synchronization complete	Then inspect prefix and next hop
IP protocol 89	OSPF transport	Not TCP/UDP port 89
224.0.0.5 / .6	AllSPFRouters / AllDRouters	Link-local multicast roles

What to understand first

Area, authentication, compatible hello/dead timers and link/network-type assumptions must agree where required. On ordinary broadcast links, DR/BDR behavior determines which pairs become fully adjacent.

A persistent 2-Way state is not automatically a fault. Two DROTHER routers on a broadcast network normally do not form Full adjacency with each other.

Persistent ExStart/Exchange can indicate an MTU mismatch or exchange problem. Compare interface MTU and database-description evidence instead of bypassing MTU checks immediately.

OSPF cost influences path selection. An LSA in the database, an OSPF-selected route, an installed RIB entry and a resolved forwarding next hop are distinct evidence.

Commands and interpretation

Inspection commands are read-only unless explicitly labeled otherwise. Capture commands start collection; configuration-mode commits change device state.

Cisco IOS XE

Read-only EXEC

show ip ospf neighbor
show ip ospf interface
show ip ospf database
show ip route 192.0.2.10

Inspect: Match neighbor state to link type, then check the destination route and outgoing path.

Junos

Read-only operational

show ospf neighbor
show ospf interface detail
show ospf database
show route 192.0.2.0/24 detail

Inspect: Use the correct routing instance and inspect protocol preference and resolved next hop.

Worked example · Illustrative, not a device capture

Illustrative adjacency failure

Peer state: ExStart for several minutes
Local interface MTU: 1500
Peer interface MTU:  9000
Affected link: routed Ethernet

The mismatch is a strong lead, not the only possible cause. Confirm exchange evidence and the intended MTU end to end.

An approved correction should align the design; do not blindly enable an MTU-ignore workaround.

Troubleshooting sequence

Verify interface state, local/peer addresses and OSPF-enabled link context.
Compare area, authentication, timers, router IDs and network type.
Use the state table to inspect hello versus database exchange evidence.
For a missing prefix, follow database -> protocol route -> installed route -> forwarding entry.
Test the affected application and reverse path after convergence.

Common mistakes

Treating every 2-Way neighbor as broken.
Changing router IDs or restarting the process before collecting evidence.
Using Full adjacency as the sole deployment acceptance test.

Acceptance checks

Expected adjacencies match link type and remain stable.
Required prefixes and next hops are installed in the correct table.
Forward, reverse and planned failover application tests pass.

Primary references

Vendor documentation and protocol specifications support this guide. The diagrams, scenarios and troubleshooting sequences are Wolex-authored.

OSPF neighbors, routes & failure states