OSPF Neighbor States: Down to Full Adjacency Explained

Q: Is OSPF 2-Way always a problem?

No. On a broadcast network, two DROTHER routers normally remain in 2-Way with each other. They form Full adjacencies with the DR and BDR.

Q: Why is an OSPF neighbor stuck in Init?

Init means the router receives Hello packets but does not see its own router ID in the neighbor's Hello. Check return-path multicast delivery, ACLs, interface problems and one-way connectivity.

Q: Why is an OSPF neighbor stuck in ExStart or Exchange?

A common cause is an interface MTU mismatch. Duplicate router IDs, packet loss and network-type problems can also interrupt database description exchange.

Q: What proves that an OSPF adjacency is healthy?

The expected neighbor reaches Full, the dead timer refreshes, the LSDB is synchronized and the expected OSPF routes are installed. On broadcast networks, an expected 2-Way DROTHER relationship is also healthy.

Q: Should I clear the OSPF process first when a neighbor is stuck?

No. Capture neighbor, interface, log and counter evidence first. A reset disrupts routing and may temporarily hide the original cause.

Neighbor States at a Glance

An OSPF neighbor is another router discovered with Hello packets. An adjacency is a deeper relationship in which two neighbors synchronize their link-state databases.

Discovery packetHello

Two-way communication2-Way

Database synchronizedFull

Best first commandshow ip ospf neighbor

Important: Full is not required between every pair of routers. On broadcast Ethernet, two DROTHER routers normally remain in 2-Way with each other.

1. Build the Baseline Lab

Start with a simple point-to-point link. Both interfaces are in Area 0, use matching timers, and have OSPF enabled. This gives you a healthy baseline before you introduce a fault.

R1RID 1.1.1.110.12.0.1/30

Hello →Area 0 · Point-to-Point← Hello

R2RID 2.2.2.210.12.0.2/30

Target result: both routers see the other neighbor in FULL state and learn routes from a synchronized LSDB.

R1 baseline

router ospf 1
 router-id 1.1.1.1
!
interface GigabitEthernet0/0
 ip address 10.12.0.1 255.255.255.252
 ip ospf 1 area 0
 ip ospf network point-to-point
 no shutdown

R2 baseline

router ospf 1
 router-id 2.2.2.2
!
interface GigabitEthernet0/0
 ip address 10.12.0.2 255.255.255.252
 ip ospf 1 area 0
 ip ospf network point-to-point
 no shutdown

2. Follow the State Journey

Think of the states as a conversation. Each state answers one question before the routers move to the next step.

01DownHave I heard a Hello?

02InitDoes the neighbor see me?

032-WayIs communication bidirectional?

04ExStartWho controls DBD sequencing?

05ExchangeWhat LSAs does each router know?

06LoadingWhich complete LSAs are missing?

07FullAre both LSDBs synchronized?

State	What is happening	What makes it move forward
Down	No valid Hello has been received.	A Hello arrives on an OSPF-enabled interface.
Init	A Hello arrived, but it does not list the local router ID.	Each router sees its own ID in the other's Hello.
2-Way	Two-way Hello communication is confirmed.	The network type and router roles require a Full adjacency.
ExStart	Routers choose master/slave behavior and a DBD sequence number.	Both routers agree on the database exchange session.
Exchange	Database Description packets summarize each LSDB.	Each router identifies the LSAs it needs.
Loading	Routers request and receive complete missing LSAs.	All Link-State Requests are satisfied.
Full	The neighbor databases are synchronized.	The adjacency stays healthy while Hellos continue.

Special NBMA state: Attempt appears with manually configured neighbors when the router is actively sending Hellos but has not received a reply.

3. Match Packets to Each Stage

OSPF uses five packet types. Knowing their job tells you which exchange is failing.

1

Hello

Discovers neighbors, checks key parameters, and maintains the relationship.

2

DBD

Provides a compact summary of the LSAs already in the database.

3

LSR

Requests the full copy of a specific missing or newer LSA.

4

LSU

Carries one or more complete LSAs to the requesting router.

5

LSAck

Confirms reliable receipt of an LSA.

Hello packets are central to Down, Init, and 2-Way. DBD packets drive ExStart and Exchange. LSR, LSU, and LSAck packets finish Loading and keep the LSDB reliable after Full.

4. Know When 2-Way Is Healthy

Always interpret the state together with the OSPF network type and DR/BDR role.

Network and relationship	Expected stable state	Reason
Point-to-point neighbors	FULL	The two routers synchronize directly.
Broadcast DR ↔ BDR	FULL	The BDR must be ready to replace the DR.
Broadcast DR/BDR ↔ DROTHER	FULL	DROTHER routers synchronize through both central routers.
Broadcast DROTHER ↔ DROTHER	2-WAY	A Full adjacency between them would add unnecessary database exchange.

Practical rule: FULL is the goal only when the topology requires an adjacency. A stable 2-WAY/DROTHER entry can prove that OSPF is working correctly.

5. Read the Verification Output

Begin with the short neighbor table. Then inspect the interface and detailed neighbor record only where the evidence points.

Confirm the state

R1# show ip ospf neighbor

Neighbor ID  Pri  State    Dead Time  Address
2.2.2.2        0  FULL/-   00:00:36   10.12.0.2

Inspect the neighbor

R1# show ip ospf neighbor 2.2.2.2 detail
 Neighbor 2.2.2.2, interface address 10.12.0.2
 In the area 0 via interface GigabitEthernet0/0
 Neighbor priority is 0, State is FULL
 Dead timer due in 00:00:36

Compare the interface

R1# show ip ospf interface g0/0
 Internet Address 10.12.0.1/30, Area 0
 Process ID 1, Router ID 1.1.1.1
 Network Type POINT_TO_POINT
 Timer intervals: Hello 10, Dead 40
 Neighbor Count is 1, Adjacent neighbor count is 1

State: Read both parts, such as FULL/DR, FULL/BDR, or 2WAY/DROTHER.
Dead timer: It should count down and refresh when Hellos arrive.
Neighbor ID: This is the neighbor's OSPF router ID, not necessarily its interface address.
After Full: Check show ip ospf database and show ip route ospf if routes are still missing.

6. Turn a Stuck State into a Clue

The state narrows the search, but it does not prove one exact cause. Confirm the clue on both routers.

Observed state	What it suggests	Check first
Down	No valid incoming Hellos	Interface/VLAN, subnet, passive interface, ACL, multicast and OSPF enablement
Init	One-way Hello communication	Return path, ACLs, multicast delivery and interface errors
2-Way	Discovery works; adjacency may not be required	Network type and DR/BDR/DROTHER roles
ExStart / Exchange	Database negotiation is restarting or failing	MTU mismatch, duplicate router ID, network type and packet loss
Loading	One or more requested LSAs are not completing	Retransmissions, packet loss, logs, CPU and control-plane filtering
Full but no route	Adjacency is healthy; route processing is the next layer	LSDB, area type, filtering, metric and route-table selection

Parameter mismatch note: Area ID, Hello/dead timers, authentication, area options, and compatible network behavior must agree. Some mismatches prevent a neighbor entry from forming at all.

7. Use a Safe Troubleshooting Workflow

Capture the symptom. Save neighbor state, dead timer, interface, logs, and the time of failure.
Check Layer 1 and Layer 2. Confirm both interfaces are up/up, in the correct VLAN, and free of serious errors.
Compare both OSPF interfaces. Check area, network type, Hello/dead timers, MTU, authentication, and passive status.
Verify unique router IDs. Duplicate IDs can repeatedly break database exchange.
Change one item. Make a controlled correction and watch the complete state transition.
Prove recovery. Confirm the expected state, synchronized LSDB, learned routes, and stable timers.

Avoid reset-first troubleshooting: Clearing the OSPF process disrupts routes and may erase useful evidence. Capture and compare before resetting anything.

8. Create Controlled Failures

Begin from a verified Full adjacency. Introduce only one fault at a time so the observed state has a clear meaning.

Safe lab change	Likely observation	Learning goal
Make R2 passive on the link	Neighbor disappears after the dead timer	See the effect of missing Hellos
Change the Hello interval on R2 only	Adjacency fails because timers do not match	Read interface parameters before guessing
Create an MTU mismatch	Neighbor may cycle in ExStart/Exchange	Connect DBD exchange to the interface MTU
Use priority 0 on broadcast Ethernet	Router stays eligible for adjacency but not DR/BDR	Separate election eligibility from adjacency

Restore the exact baseline after every experiment. Do not carry one fault into the next test.

9. Guided Practice Lab

Task 1: Observe a Healthy Journey

Build the two-router topology.
Start a terminal log before enabling OSPF.
Enable OSPF on the second router.
Watch the neighbor reach Full.
Record neighbor, interface, database, and route output.

Expected result: You can explain what each state accomplished before Full.

Task 2: Diagnose a Timer Mismatch

Change R2's Hello interval only.
Capture the state and logs without resetting OSPF.
Compare both interface outputs.
Restore the matching value.
Prove the adjacency and routes recover.

Expected result: You find the mismatch from evidence instead of trial and error.

Task 3: Explain 2-Way Correctly

Move to a broadcast LAN with four routers.
Identify the DR, BDR, and DROTHERs.
Find the DROTHER-to-DROTHER entry.
Confirm both DROTHERs are Full with DR and BDR.
Explain why 2-Way is healthy here.

Expected result: You judge a state using topology and role, not the state name alone.

10. Frequently Asked Questions

Is OSPF 2-Way always a problem?

No. Two DROTHER routers on a broadcast network normally remain in 2-Way with each other. They should be Full with the DR and BDR.

Why is an OSPF neighbor stuck in Init?

Init means your router receives a Hello but does not see its own router ID listed inside that Hello. Check one-way connectivity, ACLs, multicast delivery, and interface errors.

Why is an OSPF neighbor stuck in ExStart or Exchange?

An MTU mismatch is a common cause. Also check for duplicate router IDs, packet loss, and incompatible network-type behavior.

What proves that an OSPF adjacency is healthy?

The expected neighbor reaches Full, its dead timer keeps refreshing, the LSDB is synchronized, and expected OSPF routes appear. On broadcast networks, an expected 2-Way/DROTHER relationship is also healthy.

Should I clear the OSPF process first when a neighbor is stuck?

No. Capture neighbor, interface, logs, and counters first. A reset disrupts routing and can temporarily hide the original problem.