When show ip ospf neighbor shows nothing
An empty neighbour table means the router is not receiving Hellos from any OSPF neighbour. A partial table — where the expected neighbour is missing or stuck in a non-Full state — means Hellos are reaching the router but the adjacency is not forming or is not completing.
Both are different problems. Treat them differently.
Six causes the exam tests
1. Mismatched Hello and Dead timers
OSPF routers must agree on Hello interval and Dead interval to form an adjacency. The default Hello interval is 10 seconds on broadcast and point-to-point links, 30 seconds on NBMA. Dead interval defaults to four times the Hello interval.
If you change the Hello interval on one router and not the other, they will never reach Full state. The output of show ip ospf interface will show different timer values on the two routers. This is the most common Hello-related trap on the CCNA exam.
The fix: set matching timers on both interfaces using ip ospf hello-interval and ip ospf dead-interval.
2. Mismatched area IDs
Both routers must have the same area configured for the network on the connecting interface. If Router A has network 10.1.1.0 0.0.0.3 area 0 and Router B has network 10.1.1.0 0.0.0.3 area 1, they will see each other's Hellos but will not form an adjacency.
The show ip ospf neighbor output will show the neighbour in Init or 2-Way state, never reaching Full.
3. Mismatched authentication
If one router has OSPF MD5 authentication configured and the other does not — or both have authentication but with different keys — the Hellos will be rejected. The neighbour will not appear in the table at all, or will appear briefly and then drop.
4. MTU mismatch
OSPF uses the MTU value of the interface when exchanging Database Description (DBD) packets during the ExStart phase. If the two interfaces have different MTU values, the adjacency will get stuck in ExStart or Exchange and never reach Full.
This is a common production issue and also a CCNA exam favourite. You will see the neighbour in the output but stuck in a non-Full state. The fix is to match the MTU on both interfaces or use ip ospf mtu-ignore to bypass the check (acceptable in lab environments, not recommended in production).
5. Network type mismatch
OSPF has different network types for different interface types: broadcast (Ethernet), point-to-point (serial), and NBMA (Frame Relay). The network type controls whether a DR/BDR election happens and how Hellos are sent.
If one end of a link is configured as point-to-point and the other is configured as broadcast, the Hello intervals default to different values (10 vs 10, but the DR election behaviour differs), and the adjacency may not form correctly.
6. Passive interface
If an interface is configured with passive-interface under the OSPF process, it will not send or receive OSPF Hellos. Any neighbour on that segment will never form an adjacency.
This is easy to miss because passive-interface is commonly used deliberately on interfaces facing end hosts — but if it is applied to an interface that should be peering with another router, the neighbour will simply not appear.
Reading the show ip ospf neighbor output
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.1.2.1 1 FULL/DR 00:00:35 10.1.1.2 GigabitEthernet0/0
10.1.3.1 1 EXSTART/- 00:00:38 10.1.1.3 GigabitEthernet0/0
The State column tells you where the adjacency is stuck:
- FULL: Fully adjacent. Routes are being exchanged. Normal.
- 2-WAY: Both routers see each other. Normal for DROTHER-to-DROTHER relationships on broadcast networks. Abnormal for point-to-point links.
- EXSTART or EXCHANGE: The adjacency is negotiating the DBD exchange. Stuck here usually means MTU mismatch.
- LOADING: LSA requests are pending. Rarely seen in practice; usually resolves quickly.
- INIT: Only one router is receiving Hellos. Usually means a one-way packet flow — check ACLs or interface issues blocking return traffic.
- ATTEMPT: Only seen on NBMA networks. The router is trying to contact a neighbour it knows the address of but has not yet received a Hello from.
The exam scenario
A question shows show ip ospf neighbor with a neighbour stuck in EXSTART. The answers will include: MTU mismatch, mismatched area IDs, mismatched Hello timers, and passive interface. The correct answer is MTU mismatch because EXSTART is specifically the DBD exchange phase where MTU is checked.
Do not memorise just the answer — memorise which state maps to which cause. That is what the exam is actually testing.
Practice OSPF questions
Courseiva's CCNA practice questions include OSPF neighbour troubleshooting scenarios. The OSPF routing protocol topic guide covers the full neighbour state machine and what each state means. For certification context, see the CCNA 200-301 practice test page.
Frequently asked questions
Why would a neighbour appear in 2-Way but not Full on a point-to-point link? On point-to-point links, both routers should always reach Full. If they are stuck in 2-Way on a serial or point-to-point Ethernet link, suspect network type mismatch — one side thinks it is on a broadcast network and is waiting for a DR election that will never happen.
Can I fix timer mismatches from one side only? Yes. Set the timers on one router to match the other. The timers must be identical on both ends — it does not matter which router you change, as long as both end up the same.
What is the difference between Init and ATTEMPT? Init: a Hello was received but the receiving router's own RID was not in the Hello packet. ATTEMPT: the router is sending Hellos to a manually configured neighbour address but has not received a reply. ATTEMPT only appears on NBMA interfaces.
The Exact show Commands — Run Them in This Order
Do not guess at OSPF problems. There is a systematic command sequence that locates the fault every time.
Step 1 — Confirm the neighbour is missing:
R1# show ip ospf neighbor
If nothing appears, hellos are not being exchanged at all. If a router appears but is stuck in INIT, EXSTART, or EXCHANGE, hellos are getting through but the relationship cannot advance past that point.
Step 2 — Verify OSPF parameters on the interface:
R1# show ip ospf interface GigabitEthernet0/0
Look for: area number, hello interval (default 10s on broadcast), dead interval (default 40s), network type (BROADCAST, POINT_TO_POINT, NBMA), and whether authentication is configured.
Step 3 — Verify which networks OSPF is routing for:
R1# show ip protocols
Under "Routing for Networks:" you see which network statements matched which interfaces. If the interface IP is not covered by any network statement, OSPF is silent on that interface — no hellos sent, no routes learned.
Step 4 — Check for ACLs blocking OSPF multicast:
R1# show ip access-lists
OSPF hellos travel to multicast 224.0.0.5 (all OSPF routers) and 224.0.0.6 (DR/BDR only) using IP protocol 89. An ACL that denies multicast or blocks protocol 89 will silently prevent OSPF from functioning with no obvious error message.
Diagnosing Specific Stuck States
INIT state — Your router receives their hello but your router ID does not appear in it. Hellos are one-directional. Possible causes: passive-interface is configured on the remote interface, or the local interface is set passive and is not sending hellos at all.
EXSTART state — The master/slave election for DBD exchange is deadlocked. Almost always an MTU mismatch. If R1 has ip mtu 1500 and R2 has ip mtu 1400 (because of a GRE tunnel reducing the effective MTU), DBD packets are fragmented or dropped.
Two fixes: match the MTU on both sides, or add ip ospf mtu-ignore on both interfaces to tell OSPF to skip the MTU field check in DBD packets.
EXCHANGE state — DBD exchange completed but LSR/LSU packets are not finishing. Rare. Usually indicates asymmetric MTU or high packet loss. Try clear ip ospf process on both routers.
LOADING state — The router sent LSRs (requests for specific LSAs) but is waiting for the LSUs. Usually transient. If stuck for more than a minute, check for MTU edge cases or corrupted database entries.
The Network Type Mismatch — Catching It in show ip ospf interface
If R1 is configured with network point-to-point and R2 defaults to network broadcast on the same Ethernet segment:
- R2 expects a DR/BDR election before forming Full adjacency
- R1 skips DR election entirely and expects to go directly to Full
- They exchange hellos (reach INIT/2-Way) but disagree on how to proceed
R1# show ip ospf interface GigabitEthernet0/0
Network Type POINT_TO_POINT, Cost: 1
R2# show ip ospf interface GigabitEthernet0/0
Network Type BROADCAST, Cost: 1
Designated Router (ID) 2.2.2.2
Network type mismatch confirmed. Fix by configuring both to the same type.
Authentication Mismatch — Finding It Without the Key
You do not need to know the authentication key to spot a mismatch. Show ip ospf interface reveals whether authentication is enabled and what type:
R1: Message digest authentication enabled
Key id used is 1
R2: Simple password authentication enabled
One uses MD5, the other uses simple text — they will not form an adjacency even if the actual key string matches. Running debug ip ospf adj on the router that is not forming shows "Invalid authentication type" messages in real time.
When the Neighbour Was There Before and Disappeared
If OSPF was working and a neighbour dropped unexpectedly, ask what changed. The most common culprits in exam scenarios:
- A passive-interface command was added (silences hellos on that interface)
- A network statement was removed or the wildcard was changed
- An ACL was applied to the interface or in global config
- An ip mtu value was changed on the interface
- The interface flapped and came back with different OSPF parameters due to default-information originate changes upstream
Practice Question Sets
The only way to build genuine speed on CCNA questions is reps under realistic conditions. Pick a session size that fits your schedule: