OSPF adjacencies move through multiple intermediate states, giving them more places to stall than protocols with a binary up/down model. A BGP session usually presents a simple change: established, then absent. OSPF neighbors may advance, retreat, partially recover, and fail again without triggering monitoring that only watches link-down events.
Knowing the OSPF neighbor state machine well enough to identify early failure signals is a practical skill for anyone operating a production routing domain.
Reading the OSPF Neighbor States
OSPF forms adjacencies through a defined sequence: Down, Attempt, Init, 2-Way, ExStart, Exchange, Loading, Full. A new neighbor normally passes through these states once and remains at Full. In production, focus on states that show the adjacency cannot remain established.
2-Way is expected between non-DR and non-BDR routers on a multi-access segment. Two DROTHER routers remain at 2-Way with one another, creating a neighbor relationship without a full adjacency. That is correct. The fault is a router that should reach Full with its DR or BDR but remains at 2-Way.
ExStart and Exchange are temporary database synchronization states. A neighbor stuck in ExStart commonly points to an MTU mismatch. Both interfaces must accept the same maximum OSPF packet size. If one permits packets larger than the peer accepts, database exchange stalls. Jumbo frames on only some segments make this especially common.
Loading means database exchange is complete, but one router still requests link-state advertisements. Remaining in Loading beyond a few seconds usually indicates packet loss or retransmission trouble during synchronization.
Matching Hello and Dead Intervals
Hello or dead interval mismatches are a frequent source of OSPF instability across vendors. Both ends must use the same values. Cisco IOS and IOS-XR apply a strict check, so the adjacency will not form when they differ. Behavior varies with some Juniper configurations and Arista EOS versions, creating a trap where one side appears to form the adjacency while the other does not.
For an intermittent adjacency, compare hello and dead intervals at both ends first. Cisco exposes them with show ip ospf interface <interface>, Juniper with show ospf interface <interface>, and Arista with show ip ospf interface <interface>. These commands also show time since the last neighbor hello. Missing hellos through the dead interval cause the local router to declare the neighbor down.
Point-to-point links commonly default to 10 seconds for hellos and a 40-second dead interval. Broadcast Ethernet defaults vary by vendor. Risk rises on multi-vendor interconnects, where differing defaults can break an adjacency after it initially forms.
Area and Authentication Checks
An area type mismatch can prevent adjacency formation without an obvious alarm. One router may treat an area as regular while the other sees it as stub or not-so-stubby. They exchange hellos, but the area information causes each hello to be rejected. Monitoring may show ignored hellos, while the OSPF process is receiving and discarding them for the mismatch.
Vendor-specific debug commands usually enable OSPF hello or packet debugging. Look for messages such as "mismatched options" or "area type mismatch." Use this during a controlled maintenance window, since verbose output can raise router CPU usage when many adjacencies exist.
Authentication mismatches create the same silent rejection pattern. If one side uses MD5 and the other does not, hellos from the unauthenticated side are rejected without a normal monitoring error. The adjacency never forms, and the local router may show the peer as undefined or dead.
When Database Synchronization Breaks
A subtler pattern appears when an adjacency reaches Full and then drops during database synchronization. It often points to link-level reliability problems, with OSPF LSA retransmissions unanswered within the retransmission timer window.
OSPF provides reliability for LSA flooding by requiring an explicit acknowledgment for each LSA sent to a neighbor. Without one before the retransmit interval expires, the LSA is sent again. Continued unacknowledged retransmissions eventually time out and drop the adjacency.
Physical degradation can create this cycle even with mild intermittent loss. A link showing 0.5% packet loss may trigger retransmissions, and sustained loss can exhaust the retransmission timer before the dead timer expires. The adjacency drops, returns, and drops again, resembling a hello issue with a different cause.
Check the OSPF retransmit queue during a flap to separate this from a hello timer issue. A growing queue suggests lost acknowledgments. A zero or steady queue alongside dead timer expiry suggests the neighbor is not sending hellos.
Spotting Unstable Neighbors Early
Most monitoring tools alert only when an adjacency reaches Down. By then, route loss may already be underway, making the alert reactive rather than preventive.
Neighbor state logs provide earlier evidence. A router cycling through Init, 2-Way, and ExStart several times an hour shows a pre-failure pattern, even if it never reaches Down during the observation window. Collect state changes from syslog and compare them with dead-timer cycles to expose failures sooner.
In the PhysicalLayer agent, we track OSPF neighbor transitions from syslog and flag interfaces whose rate exceeds the near-zero pattern expected on stable adjacencies. The warning arrives before the drop, leaving time for investigation during business hours instead of during route loss.
The playbook is simple: compare hello and dead intervals, verify area type and authentication, check MTU at both ends, and inspect link errors for physical degradation. This covers established adjacencies that become unstable; commissioning failures that never reach Full follow a separate diagnostic path.