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, one per ticket. Faults can mask each other, so work bottom-up and re-test after each fix. The downloadable topology and the full ticket walkthroughs are part of PingLabz Pro.

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.
• How show ip ospf interface exposes a passive interface, a wrong area, and mismatched timers at a glance.
• Why a FULL neighbor with a missing route is a network-statement problem, not an adjacency problem.

Ticket 1: "All the R3 routes vanished"

Reported symptom: "R1 and R2 lost every route to the R3 loopback. The link is up."
Success criterion: 10.255.0.3 is back in R2's table via OSPF.

The route is gone and so, you will find, is the neighbor. But before you assume a dead link, compare the two ends of the R2 to R3 segment. Look at each router's view of its own interface:

R3# show ip ospf interface brief
Interface  PID  Area   IP Address/Mask   Cost  State Nbrs F/C
Lo0        1    0      10.255.0.3/32     1     LOOP  0/0
Et0/0      1    1      10.30.30.2/30     10    WAIT  0/0     <-- Area 1

R2# show ip ospf interface brief
Et0/1      1    0      10.30.30.1/30     10    BDR   1/1     <-- Area 0