Skip to content
Back to Learning
CCNA · 200-301Intermediate

OSPF: An Empty Neighbor Table and a Link That Pings Fine

A healthy link, matching areas, and an empty neighbor table with nothing in the log to explain it. Find the parameter that does not match, live, right below.

Interactive simRoutingOSPFTroubleshooting

Symptom

Both routers can ping across the link, yet neither has an OSPF neighbor. The Hellos arrive with different timer values, so OSPF discards them before an adjacency can form.

Your mission

Inspect, recover, then verify

Format

Cisco IOS CLI

OSPF: Hello and Dead Timer Mismatch

Investigate before you configure.

Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.

Observe the symptom and link state.

Diagnose by comparing the protocol evidence.

Verify the expected device state and confirm the original symptom is resolved.

Console access: R1 · R2

This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.

Need a hint?

Reveal the root cause when you're ready.

Try the investigation first, then use this as your escape hatch, not a dead end.

Locked

Create a free account to open OSPF: An Empty Neighbor Table and a Link That Pings Fine. You get the root cause and the full step-by-step fix.

Already have an account? Sign in

No spam. The fix lands in your inbox too. Your account includes 5 guided labs free. After that, the Learning Pass unlocks every remaining lab.

Lab debrief

Turn the session into a repeatable troubleshooting pattern.

Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.

The problem

R1 and R2 are directly connected on GigabitEthernet0/0 in the 10.0.0.0/30 network. Both use OSPF process 1 in area 0, and both links are up. R1 uses Hello 10 and Dead 40. R2 uses Hello 5 and Dead 20. The neighbor table is empty on both routers even though ping 10.0.0.2 succeeds.

What you'll practice

  • Separate Layer 3 reachability from OSPF adjacency formation
  • Read the hello and dead intervals from show ip ospf interface GigabitEthernet0/0
  • Recognise why an empty neighbor table points to an early OSPF mismatch
  • Match the timers and verify the neighbor reaches FULL

1. An empty table is a useful clue

When show ip ospf neighbor has only its header, the routers have not formed an OSPF neighbor. That is earlier than the EXSTART state seen in an MTU mismatch, so the investigation belongs in the Hello parameters first.

2. Ping proves a different layer

The adapter returns !!!!! for ping 10.0.0.2. That proves the directly connected IP path is reachable, but it does not make OSPF accept a Hello with incompatible timer values.

3. Both timer values must match

R1 uses Hello 10 and Dead 40 while R2 uses Hello 5 and Dead 20. Matching only one value still leaves the pair incompatible. Restoring R2's hello interval to 10 lets its automatically derived dead interval become 40.

The topology

R1 GigabitEthernet0/0 at 10.0.0.1/30 connects directly to R2 GigabitEthernet0/0 at 10.0.0.2/30. Both routers run OSPF process 1 in area 0. R1 has Router ID 1.1.1.1 and R2 has Router ID 2.2.2.2.

Commands to run yourself

The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.

Check the empty neighbor table
show ip ospf neighbor
Compare the OSPF timers
show ip ospf interface GigabitEthernet0/0
Prove the link is reachable
ping 10.0.0.2

Topology diagram

Fact-checked references

The commands and behaviour in this lab were checked against these primary references.

Frequently asked

Why is the neighbor table empty when ping succeeds?

Ping tests Layer 3 reachability between 10.0.0.1 and 10.0.0.2. OSPF still discards the Hellos because R1 uses Hello 10 and Dead 40 while R2 uses Hello 5 and Dead 20.

Why does setting only Dead 40 on R2 not fix the adjacency?

The hello intervals would still be 10 on R1 and 5 on R2. OSPF requires both hello and dead intervals to match exactly, so changing only ip ospf dead-interval 40 leaves the fault in place.

Why does R2's dead interval become 40 when its hello interval becomes 10?

R2 has no explicit dead interval in its interface running configuration. The adapter models IOS's automatic four times relationship, so changing ip ospf hello-interval 10 changes Dead from 20 to 40.

Ready to run this lab yourself?

No setup, no image sourcing. Book a session or ask for a live demo.