To troubleshoot an OSPF neighbor, start with its current state: each state identifies how far the routers have progressed through Hello communication and database synchronization. A persistent ExStart or Exchange state merits investigation; Two-Way can be normal on a broadcast network when the routers are not expected to form a full adjacency.
This guide covers OSPFv2 as specified in RFC 2328. Command examples and platform-specific troubleshooting notes are Cisco guidance; check syntax and behavior for your own vendor and software version.
What each OSPF neighbor state tells you
RFC 2328 §10.1 describes OSPFv2 neighbor states as stages of increasing functionality. Read the state as evidence of protocol progress, not as a fault verdict by itself.
| State | What it means | What to check next |
|---|---|---|
| Down | No recent information has been received from the neighbor. | Check interface and link health, then whether Hello packets can travel in both directions. |
| Init | A Hello arrived, but it did not list this router’s Router ID. Bidirectional communication has not been established. | Check whether the peer receives and includes this router in its Hello; inspect OSPF interface settings and packet delivery. |
| Two-Way | Each router has confirmed the other in its Hello. | Determine the network type and DR/BDR roles before deciding whether a full adjacency is expected. |
| ExStart | The routers begin adjacency setup, including negotiating the master/slave relationship and initial Database Description sequence number. | If the state persists, compare MTUs and investigate Database Description packet delivery and exchange errors. |
| Exchange | The routers exchange Database Description packets summarizing their link-state databases. RFC 2328 §10.1 says, “In this state the router is describing its entire link state database by sending Database Description packets to the neighbor.” | If progress stalls or resets, check MTU, packet passage, Router ID uniqueness, and protocol error evidence. |
| Loading | A router requests newer or missing Link State Advertisements (LSAs). | Look for missing or invalid requested LSA evidence if the neighbor does not progress. |
| Full | The adjacency has completed link-state database synchronization. | Confirm the expected adjacency is Full and that the link-state database has converged. |
These definitions are specified in RFC 2328 §§10.1–10.3.
#1 Best Overall
Record the neighbor and its transition before changing anything
Use the neighbor display available on the deployed platform to capture the peer, local interface, state, timers, and any transition or reason fields. Cisco documents show ip ospf neighbor for this check in its OSPF neighbor troubleshooting guidance. Confirm the equivalent command and output fields for other vendors.
If possible, compare the same details at both ends and note whether the neighbor is absent, persistently in one state, or repeatedly returning to an earlier state. The distinction helps separate a Hello-delivery problem from a synchronization problem.
Rank #2
If the neighbor is absent, Down, or Init
Start with the interface and link, then verify that Hello packets are delivered in both directions. In Init, one router has heard a Hello but has not seen its own Router ID listed in the peer’s Hello; the relationship is not yet bidirectional.
- Check interface/link status and the OSPF interface configuration at both ends.
- Inspect whether filtering or other packet-delivery issues are preventing Hellos from reaching the peer.
- For Init specifically, determine why the peer’s Hello does not confirm this router’s Router ID.
Do not begin with database-exchange troubleshooting while the routers have not established two-way Hello communication. The state definitions and Hello behavior are covered in RFC 2328 §10.1.
Rank #3
If the neighbor stays Two-Way
Two-Way confirms bidirectional Hello communication, but it does not always mean the routers should become fully adjacent. On a broadcast network, routers that are neither the Designated Router (DR) nor Backup Designated Router (BDR) may remain Two-Way with each other. Check the network type and DR/BDR roles before treating this state as a fault. Cisco discusses this behavior in its neighbor troubleshooting guidance and Nexus OSPF adjacency guidance.
If the neighbor is stuck in ExStart or Exchange
ExStart and Exchange are normal stages of adjacency formation. A neighbor persistently stuck in either state warrants investigation; the state alone does not identify the cause.
1. Compare interface MTUs and test packet-size reachability
Check the configured MTU at both ends and whether the path can carry packets at that size. Cisco’s documented ExStart/Exchange case describes a larger Database Description packet being ignored by a neighbor that cannot receive it, and recommends matching interface MTUs when that is the cause. Cisco calls MTU mismatch the most common cause in that case but gives no percentage; it is a diagnostic lead, not a guaranteed explanation. See its ExStart/Exchange troubleshooting guidance, updated October 3, 2024.
2. Verify Database Description packets traverse the path
If MTU is not the cause, establish whether Database Description packets are delivered in both directions. Cisco’s cited guidance lists broken unicast delivery, ACL filtering, NAT translation, incorrect Frame Relay or ATM virtual-circuit mapping, and dialer/PRI/BRI combinations among possible causes. Which delivery checks apply depends on the link type.
Best Value
3. Check Router ID uniqueness
Verify that the routers do not have duplicate Router IDs. Cisco includes duplicate Router IDs among possible causes of an ExStart/Exchange problem in its troubleshooting guidance.
4. Look for exchange and LSA-request errors
If the state resets during Exchange, inspect available logs and packet evidence for Database Description sequence-number mismatch, unexpected initialize-bit behavior, differing options, or a BadLSReq condition involving a missing requested LSA. RFC 2328 specifies that SeqNumberMismatch and BadLSReq can return an adjacency to ExStart; Cisco’s ExStart/Exchange guide also describes exchange-error troubleshooting.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Verify recovery safely
After correcting a diagnosed cause, observe whether the neighbor advances through synchronization to Full and whether the link-state database converges. Avoid treating a reset or debug command as a first diagnostic step: commands and live-network actions can have operational impact. Cisco cautions users to take care with debugging and troubleshooting actions in its neighbor troubleshooting guidance. Confirm the command’s effect and procedure against the deployed platform before using it.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
