Lab ts-ipc-01 - Troubleshooting OSPF Tickets

OSPF is where CCNA troubleshooting gets interesting, because OSPF can fail in two completely different ways that produce the same user symptom. Either the adjacency never forms, or the adjacency is perfectly healthy but a prefix still does not appear in the routing table. Tell those two apart quickly and you have most of OSPF troubleshooting solved. This lab gives you three tickets that drill exactly that distinction. It is part of the PingLabz CCNA Troubleshooting Labs and runs on the five-node base topology, so it fits Cisco Modeling Labs Free. Every output below was captured on Cisco IOS XE.

The topology and healthy state

R1, R2, and R3 run OSPF process 1, area 0, with their transit links and loopbacks advertised. Router IDs are 0.0.0.1, 0.0.0.2, and 0.0.0.3. In the healthy state, R2 sits in the middle with a full adjacency to each neighbor and learns both far-end loopbacks:

R2# show ip ospf neighbor
Neighbor ID   Pri   State      Dead Time   Address      Interface
0.0.0.3        1   FULL/DR     00:00:39    10.30.30.2   Ethernet0/1
0.0.0.1        1   FULL/BDR    00:00:36    10.20.0.1    Ethernet0/0

R2# show ip route ospf | include 10.255.0
O   10.255.0.1/32 [110/11] via 10.20.0.1, Ethernet0/0
O   10.255.0.3/32 [110/11] via 10.30.30.2, Ethernet0/1

Lab setup: this topology boots with all three faults already in place. Two of them sit on the same R2-to-R3 link and stack on top of each other, so clearing the first one does not bring the neighbor up by itself: it exposes the second. That is realistic, and it is the whole point of working a problem in order. Fix what you can see, re-test, and let each fix reveal the next layer.

What you will learn

• The first fork in every OSPF problem: is the adjacency down, or up-but-not-advertising?
• The handful of values that must match for two routers to become neighbors: area, subnet, timers, and authentication.
• Why a passive interface hides every other adjacency fault behind it, and how to spot it in one command.
• Why a FULL neighbor with a missing route is a network-statement problem, not an adjacency problem.

Ticket 1: "R3 fell out of OSPF"

Reported symptom: "R2 lost its OSPF neighbor to R3 and every route behind it. The link is up."
Success criterion: R2 is sending hellos toward R3 again (the interface is no longer passive).

Confirm the neighbor is gone, then go to the interface that should be forming it. The neighbor table shows only R1:

R2# show ip ospf neighbor
Neighbor ID   Pri   State      Dead Time   Address      Interface
0.0.0.1        1   FULL/BDR    00:00:38    10.20.0.1    Ethernet0/0

R3 is missing. The link to R3 is Ethernet0/1, and the layers below OSPF are fine (the interface is up and addressed), so read OSPF's own view of that interface:

R2# show ip ospf interface Ethernet0/1
Ethernet0/1 is up, line protocol is up
  Internet Address 10.30.30.1/30, Area 0
  Process ID 1, Router ID 0.0.0.2, Network Type BROADCAST, Cost: 10
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    No Hellos (Passive interface)
  Neighbor Count is 0, Adjacent neighbor count is 0

There it is: No Hellos (Passive interface). Someone made the interface passive. A passive interface still advertises its subnet but stops sending hellos, so it can never form an adjacency over that link. It also goes silent, which means it hides any other fault on the same link: with no hellos leaving R2, the far end has nothing to complain about, so this is the only fault you can see right now.