3 OSPF Neighbors and Adjacencies
Learn how OSPF routers discover neighbors, form adjacencies, progress through neighbor states, and troubleshoot common connection problems.
Neighbors and adjacencies
OSPF routers use to discover one another and maintain neighbor relationships. Being neighbors does not necessarily mean that two routers have formed an : an is the relationship used to synchronize link-state databases (LSDBs).
On a point-to-point network, the two routers normally become adjacent. On a broadcast network, routers form full adjacencies with the and Backup Designated Router (BDR), while other router pairs can remain to limit unnecessary database exchanges.
Requirements for neighbor formation
Before troubleshooting, verify that the interface is operational and OSPF is enabled on it. In the usual OSPFv2 setup, neighboring routers must agree on the Hello and Dead intervals, area, and authentication settings. On broadcast and NBMA networks, their subnet masks must agree as well.
Area options must be compatible, router IDs must be unique, and the network type and interface configuration must support communication between the routers. A mismatch can prevent from being accepted or stop formation.
Hello and Dead intervals are configured per interface. The determines how long a router waits without hearing a Hello before declaring the neighbor down. Check the actual values at both ends of the link rather than assuming that defaults are in use.
OSPF neighbor states
OSPF neighbors progress through states as they discover one another and synchronize their LSDBs:
Down: No recent valid Hello has been received. This is the starting state and can also mean that the expired.
Attempt: On an NBMA network, the router is actively trying to contact a configured neighbor.
Init: A Hello was received, but it does not list this router’s ID; two-way communication has not yet been confirmed.
: Each router sees its own ID in the other router’s Hello. On broadcast networks, two DROthers commonly remain with one another.
ExStart: Routers negotiate which one starts the database-description exchange and establish sequence numbers.
Exchange: Routers exchange Database Description (DBD) packets that summarize their LSDBs.
Loading: Routers request and receive needed or newer LSAs.
Full: The is formed and the exchange is complete.
ExStart, Exchange, and Loading are normal transitional states. They are cause for investigation when a neighbor remains in one of them instead of progressing.
Check interfaces and neighbors
Compare the local and remote interface settings rather than relying on the output from only one router. These are Cisco IOS-style examples; command syntax and available details vary by platform.
Check that the interface and line protocol are up, the correct IP address and mask are configured, and OSPF is active on the interface. Confirm that the area, timers, network type, authentication, and MTU are as intended.
show ip ospf neighbor reports the neighbor state, router ID, address, and local interface. On Cisco IOS, show ip ospf interface is especially useful for checking OSPF-specific interface settings.
Troubleshoot by neighbor state
Use the observed state to narrow down where to investigate:
No neighbor entry: The router has not received a valid Hello from that neighbor. Check link status, OSPF enablement, addressing, area, Hello and Dead intervals, authentication, and whether packets can pass across the link.
Init: Hellos arrive, but the neighbor’s Hello does not list this router. Check the return path and whether the peer is receiving and processing this router’s Hellos. Also verify area, timers, and authentication.
: First check the network type and DR/BDR roles. On a broadcast network, DROther routers commonly remain with one another; this alone is not a fault. If an is expected, verify the DR/BDR election and interface priorities.
ExStart or Exchange: Check for an first, then examine DBD exchange, router ID uniqueness, and packet delivery. A mismatch can prevent DBD packets from being accepted and stall formation.
Loading: The routers are requesting LSAs but have not finished synchronization. Investigate missing, outdated, or corrupted LSA exchanges and link reliability.
Full, then Down: Check for intermittent link problems, missed Hellos, congestion or resource pressure, and timer configuration.
Common causes also include mismatched timers, network type, MTU, or area type; duplicate router IDs; and Hellos that are blocked or not processed. Correct the underlying mismatch. Where supported, an MTU-ignore option should be reserved for cases where the MTU difference is understood and intentional.
Interpret common troubleshooting cases
A neighbor that stays in Init indicates that Hellos reach the local router, but bidirectional discovery is not confirmed. Check whether the neighbor receives this router’s Hellos and whether the return path and compatibility settings are correct.
If two routers on Ethernet remain , check whether both are DROthers. If they are, this is expected: each should form a full with the DR and BDR. If one router should be adjacent but is not, verify its DR/BDR role and priority.
A neighbor staying in ExStart warrants checking interface MTUs at both ends, then the DBD exchange and router IDs. Do not treat a transient ExStart state as a failure; determine whether it is stuck there.
A Full neighbor state means the and synchronization completed, but it does not by itself guarantee that a particular route is being advertised, accepted, or installed. If routes are missing, check the and routing table next.