Every OSPF neighbor relationship passes through eight named states on its way from "we just saw each other" to "we agree on the topology." When OSPF works, the states scroll past in seconds and nobody looks at them again. When OSPF breaks, the state the neighbor is stuck in tells you exactly where in the conversation it failed. This post walks through all eight states, what triggers a transition, and what to check when a neighbor refuses to move past a specific one.
For the cluster overview, see the OSPF complete guide. For the analogous state machine on the other major routing protocol, see the BGP pillar.
The 8-state FSM at a glance
| # | State | What it means | What you check if stuck here |
|---|---|---|---|
| 1 | Down | No Hellos received from this neighbor. The default initial state. | L1/L2 connectivity, OSPF enabled on interface, correct area |
| 2 | Attempt | NBMA only. The router is unicasting Hellos hoping for a reply. | neighbor statements under router ospf, NBMA reachability |
| 3 | Init | We saw a Hello from this neighbor but our own Router ID is not in their neighbor list yet. | One-way Hellos. Auth mismatch. ACL blocking return traffic. |
| 4 | 2-Way | Bidirectional Hello exchange confirmed. On broadcast networks, non-DR/BDR pairs stop here. | If two DROTHERs sit at 2-Way that is normal. If two routers that should peer fully sit here, check priorities. |
| 5 | ExStart | Master/slave election for the upcoming database exchange. | MTU mismatch. Auth mismatch. Both sides claim master forever. |
| 6 | Exchange | DBD packets sent describing each side's LSA headers. | MTU again (most common cause of stuck-in-Exchange). DBD packet drops. |
| 7 | Loading | One side has requested LSAs it does not have yet via LSR; the other is sending them via LSU. | Database corruption is rare. Usually transient. |
| 8 | Full | The two routers have synchronized link-state databases. This is the working steady state. | Nothing. This is the goal. |
State 1 - Down
The starting state. Either OSPF just came up on the interface or the dead-interval expired on a previously-known neighbor. Stays here until a Hello packet arrives from any source on the segment.
Routers that should be neighbors but stay Down indefinitely usually have a Layer 1 or 2 issue (cable, switch port assignment, no carrier) or OSPF is not actually enabled on the interface. Confirm with show ip ospf interface brief. If your expected interface is not listed, the network statement under router ospf does not cover it, or the interface-level ip ospf 1 area X command is missing.
State 2 - Attempt (NBMA only)
Only seen on non-broadcast multi-access networks (Frame Relay, ATM) where multicast is not available and the router must unicast Hellos based on configured neighbor statements. If the neighbor never responds, the state stays in Attempt until you intervene.
In a modern Cisco IOS XE network you will almost never see this state. It survives in OSPF for historical reasons but most current designs use point-to-multipoint or point-to-point network types instead, which skip Attempt entirely.
State 3 - Init
A Hello arrived from the neighbor, but the Hello did not list our own Router ID in its neighbor section. This means we are seeing them, but they are not seeing us back. One-way communication.
The classic causes:
- OSPF authentication mismatch. One side sends authenticated Hellos; the other side either does not authenticate or uses a different key. The authenticated side drops the unauthenticated Hellos silently.
- An inbound ACL on the neighbor's interface dropping OSPF (protocol 89). Hellos out work; Hellos in get filtered.
- Hello / dead-interval mismatch. The Hello arrives but is discarded as malformed for that interface.
- Network-type mismatch. One side configured as point-to-point, the other as broadcast. Hellos look different.
Stuck-in-Init is almost always one of these four. Run show ip ospf interface <X> on both sides and diff the output line by line.
State 4 - 2-Way
Bidirectional Hellos confirmed. The routers know they see each other. On broadcast and NBMA networks, the next thing OSPF does is run the DR/BDR election. Routers that lose the election (DROTHERs) do not progress past 2-Way with each other. They only go past 2-Way with the DR and BDR.
Two DROTHERs sitting at 2-Way forever is correct behavior and not a problem. Two routers that should fully peer but sit at 2-Way usually have a priority misconfiguration. Confirm with show ip ospf neighbor and look at the State column. The DR will show as FULL/DR, the BDR as FULL/BDR, and other neighbors as 2-WAY/DROTHER (which is fine).
State 5 - ExStart
The routers are about to exchange databases. First they have to elect a master and a slave to control the DBD sequence numbering. The router with the higher Router ID wins.
The most famous cause of "stuck in ExStart/Exchange" is MTU mismatch. OSPF includes the interface MTU in the DBD packet. If the receiver's interface MTU is smaller than what is in the DBD, the receiver drops the DBD and the conversation stalls. Both routers retransmit, neither makes progress.
The fix is one of:
- Make both interface MTUs match (usual answer)
- Use
ip ospf mtu-ignoreon the interface to skip the MTU check (workaround; consider whether the MTU mismatch will cause other problems)
State 6 - Exchange
DBD packets flow describing each side's LSA headers. Each router builds a list of LSAs the other side has that it does not. Stuck-in-Exchange is almost always the same MTU problem as stuck-in-ExStart, just discovered slightly later when a DBD packet happens to be larger than the receiver's MTU.
Less commonly, stuck-in-Exchange can be caused by an extreme amount of packet loss on the segment, which prevents the DBD chain from completing before retransmission timers expire indefinitely.
State 7 - Loading
Each side has identified which LSAs it needs from the other. It sends Link State Requests (LSRs). The other side replies with Link State Updates (LSUs) containing the requested LSAs. When the request list is empty on both sides, the conversation advances to Full.
Stuck-in-Loading is uncommon. When it happens, the typical cause is database corruption on one side or packet drops of LSU packets specifically (less common than DBD drops, but possible if there is an ACL or QoS classifier mishandling protocol 89).
State 8 - Full
The two routers have synchronized link-state databases. They will continue to exchange routine Hellos at the configured Hello interval, and will exchange LSAs as topology changes occur, but the relationship itself is steady state. Time spent in Full is unbounded; an adjacency can stay Full for years.
Reading show ip ospf neighbor
The one command you will use 80% of the time:
R2# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
1.1.1.1 1 FULL/DR 00:00:32 10.20.0.1 Ethernet0/0
3.3.3.3 1 FULL/BDR 00:00:34 10.20.0.3 Ethernet0/0
4.4.4.4 0 FULL/ - 00:00:38 10.30.30.4 Ethernet0/1Three things to read off this output:
- State column. FULL is the goal. Anything else needs investigation.
- The slash suffix. /DR, /BDR, /DROTHER tell you the DR election outcome on the segment. The dash for 4.4.4.4 means a P2P link (no DR election).
- Dead Time. Counting down. If it hits zero, the adjacency drops. A dead time that climbs back up means a Hello arrived.
The debug command, used with caution
For diagnosing stuck states, the most useful debug is:
R2# debug ip ospf adjThis prints every adjacency state transition. Run it on the side that is failing, watch for the transition that does not happen, and the line above tells you why. Turn it off immediately when you have the answer; on a busy router it produces enough log volume to flood the console.
Key takeaways
The OSPF neighbor FSM has eight states. Down means no contact. Init means one-way. 2-Way means bidirectional but no database sync yet. ExStart through Loading are the database synchronization phases. Full is the goal. The state a stuck neighbor is in tells you which phase of the conversation failed, and there is a small finite list of causes for each state. Memorize the table at the top of this post and the troubleshooting time on any OSPF adjacency problem drops by a factor of three.
For broader OSPF coverage, see the OSPF pillar.
