Lesson 2 of 5

Troubleshooting: Neighbors Not Forming

Lab Objectives

  • Understand and fix common causes of OSPF neighbors stuck in Down or Init states.
  • Perform Layer 1, Layer 2 and Layer 3 checks to locate the root cause of adjacency problems.
  • Verify OSPF neighbor formation using show commands and interpret the OSPF protocol behavior.

Base lab topology (exact IPs on every interface)

                [Internet]
               203.0.113.1
                    |
               R1 (Gateway)
              Gi0/0: 10.10.10.1
              Gi0/1: 10.10.20.1
              Gi0/2: 10.10.30.1
              /     |     \
           R2      R3      R4

Gi0/0: 10.10.10.2 | Gi0/0: 10.10.30.2 Gi0/1: 10.10.40.1 | / \ | S1 S2 S3 / \ | /
PC1 PC2 PC3 PC4 PC5

Tip: OSPF adjacency relies on simple building blocks — the physical link must work, IP addressing must be correct, and OSPF settings (area, timers, network type) must match. Think of OSPF neighbor formation like two people trying to shake hands: if either hand is missing, gloved differently, or they speak different languages (timers/area), the handshake fails.

Lab Tasks (Try It Yourself First!)

Complete these tasks WITHOUT looking at the solution below. Use ? and show commands to figure it out.

Task 1: Configure OSPF on R1 and R2 (Area 0)

Configure OSPF process 1 on R1 and R2 so the 10.10.10.0/24 link becomes OSPF neighbors in area 0. Use the interfaces from the topology.

Task 2: Verify and Fix a Neighbor Stuck in INIT

Check OSPF neighbor state on R1. If the neighbor toward R2 is stuck in INIT, investigate Layer 1/2/3 and OSPF settings (interfaces, IPs, network statements, passive-interface). Fix the cause so the neighbor reaches FULL.

Task 3: Verify Hello/Dead Timers and Network Type

On the R1–R2 link verify OSPF Hello and Dead intervals and the OSPF network type. Adjust timers on one side only if they are mismatched, so the adjacency forms reliably.

Think About It: Why does OSPF require both routers to advertise the same area and compatible timer settings before forming a FULL adjacency? How would you explain this requirement to someone new to routing?


Lab Solution

Task 1 Solution: Configure OSPF on R1 and R2 (Area 0)

What we are doing: We enable OSPF process 1 and tell each router which directly-connected networks should participate in OSPF and in which area. This allows routers to send OSPF Hello packets on the interface and discover neighbors.

R1# configure terminal
R1(config)# router ospf 1
R1(config-router)# network 10.10.10.0 0.0.0.255 area 0
R1(config-router)# network 10.10.20.0 0.0.0.255 area 0
R1(config-router)# network 10.10.30.0 0.0.0.255 area 0
R1(config-router)# end

R2# configure terminal
R2(config)# router ospf 1
R2(config-router)# network 10.10.10.0 0.0.0.255 area 0
R2(config-router)# network 10.10.40.0 0.0.0.255 area 0
R2(config-router)# end

What each command does and why it matters:

  • router ospf 1 — starts OSPF process 1 on the router. Without an OSPF process, the router will not send Hello packets.
  • network X Y area 0 — tells OSPF which directly-connected interfaces to include in the OSPF process and places them into area 0. This controls where Hellos are sent and which interfaces accept OSPF neighbors.

Verify:

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.2       1    FULL/DR         00:00:33    10.10.10.2      GigabitEthernet0/0

Explanation of expected output:

  • If the neighbor shows FULL on R1, adjacency formed correctly. State shows the OSPF neighbor state (e.g., DOWN, INIT, 2WAY, EXSTART, EXCHANGE, LOADING, FULL). Address is the neighbor's IP on the link. Interface is the local interface used.

Task 2 Solution: Verify and Fix a Neighbor Stuck in INIT

What we are doing: When a neighbor is stuck in INIT the local router sees Hellos from the neighbor but the neighbor has not seen the local router's Router ID in its Hello — typically caused by IP addressing mistakes, passive-interface, area mismatch, or ACL/filter blocking OSPF. We'll step through checks from Layer 1 to OSPF.

Step-by-step checks and fixes:

  1. Layer 1 / Layer 2 check — ensure interface is up/up and no shutdown:
R1# show ip interface brief
Interface                      IP-Address      OK? Method Status                Protocol
GigabitEthernet0/0             10.10.10.1      YES manual up                    up
GigabitEthernet0/1             10.10.20.1      YES manual up                    up
GigabitEthernet0/2             10.10.30.1      YES manual up                    up
  • What this does: lists interfaces and whether they are administratively up and line protocol state.
  • Why it matters: If the interface or protocol is down, OSPF will not send Hellos.
  1. Verify OSPF sees Hellos and neighbor state:
R1# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.10.10.1/24, Area 0
  Process ID 1, Router ID 10.10.10.1, Network Type BROADCAST, Cost: 1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  Hello due in 00:00:08
  Supports only single TOS(TOS0) routes
  A network adjacency is not required
  • What this does: shows OSPF per-interface parameters including Hello/Dead timers and network type.
  • Why it matters: If Hello/Dead timers mismatch between neighbors, one side will see Hello but not accept adjacency; network types (BROADCAST vs POINT-TO-POINT) also affect DR/BDR election and adjacency behavior.
  1. If show ip ospf neighbor shows INIT on R1:
R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.2       1    INIT            00:00:34    10.10.10.2      GigabitEthernet0/0
  • Interpretation: R1 received a Hello from 10.10.10.2 but R2 did not include R1 in its Hello as seen by R1 — typical causes: passive-interface on R2, R2 not running OSPF on that interface, or area mismatch.
  1. Check R2 configuration for passive-interface or network statements:
R2# show running-config | section router ospf
router ospf 1
 network 10.10.10.0 0.0.0.255 area 1
 network 10.10.40.0 0.0.0.255 area 0
!
  • What this does: shows OSPF configuration lines.
  • Why it matters: In this example the 10.10.10.0 network was incorrectly placed in area 1 on R2 — area mismatch prevents adjacency formation.

Fix: Put 10.10.10.0 on R2 into area 0 to match R1:

R2# configure terminal
R2(config)# router ospf 1
R2(config-router)# no network 10.10.10.0 0.0.0.255 area 1
R2(config-router)# network 10.10.10.0 0.0.0.255 area 0
R2(config-router)# end
  • What this does: removes incorrect area assignment and configures the network in area 0.
  • Why it matters: OSPF neighbors must be in the same area on the shared link to form an adjacency.

Verify after fix:

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.2       1    FULL/ -         00:00:32    10.10.10.2      GigabitEthernet0/0
  • Expected outcome: State is FULL indicating adjacency established.

Task 3 Solution: Verify Hello/Dead Timers and Network Type

What we are doing: OSPF Hello interval defaults (on many platforms) are 10 seconds on broadcast networks and Dead is 4x Hello. If one router has modified Hello timers, the other side will not form adjacency until timers match. We'll check and align timers if necessary.

Check current timers on both sides:

R1# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.10.10.1/24, Area 0
  Process ID 1, Router ID 10.10.10.1, Network Type BROADCAST
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

R2# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.10.10.2/24, Area 0
  Process ID 1, Router ID 10.10.10.2, Network Type BROADCAST
  Timer intervals configured, Hello 15, Dead 60, Wait 60, Retransmit 5
  • What this shows: R1 uses Hello 10s, R2 uses Hello 15s — mismatch will prevent adjacency beyond 2-way/Init depending on timing.

Fix: Configure R2 to match R1 (set Hello 10 / Dead 40) on the interface:

R2# configure terminal
R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip ospf hello-interval 10
R2(config-if)# ip ospf dead-interval 40
R2(config-if)# end
  • What these commands do: ip ospf hello-interval and ip ospf dead-interval set per-interface timers. Matching these ensures both routers recognize each other's Hellos within the expected timeframes.

Verify:

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.10.10.2       1    FULL/ -         00:00:34    10.10.10.2      GigabitEthernet0/0

R2# show ip ospf interface GigabitEthernet0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet Address 10.10.10.2/24, Area 0
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

Troubleshooting Scenario

Scenario: R1 sees R2 in INIT state — adjacency not forming

Symptom: On R1 show ip ospf neighbor displays R2 in INIT, pings between R1 and R2 succeed, but OSPF remains stuck.

Your task: Find and fix the problem.

Hint: Layer 3 reachability exists; check OSPF configuration lines and area assignments.

Solution:

  • Cause: R2 had the network 10.10.10.0 statement under area 1 instead of area 0. OSPF Hellos were being sent but the area mismatch prevented mutual recognition.
  • Fix: Change R2's OSPF network statement to area 0 (commands shown in Task 2 Solution). After correcting the area, the neighbor moves to FULL.

Why this works: OSPF expects both routers on the same shared network to belong to the same area. If the local router's Hello packets advertise an area that the neighbor doesn't accept for that interface, the neighbor will not include the local router in its neighbor list — the handshake cannot complete.

Verification Checklist

  • Interface between R1 and R2 is administratively up and line protocol is up.
  • OSPF process is enabled and the correct networks are in area 0 on both R1 and R2.
  • OSPF show ip ospf neighbor shows the neighbor in FULL state.
  • Hello and Dead timers match on the shared interface.

Common Mistakes

SymptomCauseFix
Neighbor stuck in INITArea mismatch (one router configured the shared network in a different OSPF area)Move the network statement into the correct area on the misconfigured router.
Neighbor not seen at all (DOWN)Interface down or no ip address or shutdownshow ip interface briefinterface ...no shutdown and configure correct IP.
Adjacency intermittentMismatched Hello/Dead timersSet ip ospf hello-interval and ip ospf dead-interval to the same values on both routers for that interface.
No adjacency on multi-access networkPassive-interface enabled on one sideRemove passive-interface for the relevant interface under OSPF on the router where it is set.

Challenge Task

Recreate a situation where R1 and R3 are on the 10.10.20.0/24 link and R3 has been made passive for OSPF on Gi0/1. Your goal: without changing the physical topology, enable R3 to actively form OSPF neighbor relationships with R1 while keeping OSPF passive on another interface of R3 (e.g., Gi0/??). Do this without step-by-step guidance — identify the affected interfaces and modify only what is necessary.

Important real-world note: In production networks, carefully consider where you use passive-interface. It's useful for preventing unwanted adjacency formation on access links (e.g., to hosts), but if you accidentally set it on a router-to-router link you'll silently break routing adjacencies. Analogously, it's like locking the door to a room where you actually need to invite guests in.

Key takeaways:

  • OSPF neighbor formation is deterministic: physical/link viability + correct IP addressing + matching OSPF parameters (area, timers, network type).
  • Start troubleshooting bottom-up: check Layer 1/2, then Layer 3 addressing, then OSPF process and per-interface OSPF settings.