Verify a single-area OSPF domain with the core show commands and map each stuck adjacency state — INIT, 2-Way, ExStart/Exchange — and each missing-route symptom to the exact mismatch that caused it, then fix it.
Week 5 · Lesson 6 · Active ~42 min · Video ~6 min (optional) · Lab ~12 min · Domain: IP Connectivity
You should be able to configure OSPF and know what a FULL adjacency and a DR election look like. This lesson turns that into a verification routine and a fault-isolation method.
Prerequisites: ospf-single-area-configuration, ospf-cost-dr-bdr-and-default-route
Paths: Start lesson · Test out (jump to the quick check) · Review sheet
Baseline check
OSPF is configured on three routers but one remote LAN is missing from R1's routing table. Before continuing, write the very first command you would run — and what a healthy result of that command would look like.
The disciplined first command is almost always show ip ospf neighbor. No FULL adjacency, no synchronized database — and no routes. Verification has an order, and starting at the neighbor table saves time.
Verify from adjacency outward to routes. OSPF builds routes in stages — neighbors form, databases sync, SPF runs, routes install. Verify in that same order so a failure surfaces at the earliest stage:
show ip ospf neighbor— the single most important command. Confirm each expected peer is FULL (on transit/point-to-point) with a valid Router ID and next-hop. If a neighbor is missing or stuck, stop here; nothing downstream will be right.show ip ospf interface brief— confirm every interface you intended to run OSPF is listed, in the right area, with a sensible cost and neighbor count. A missing interface means your network statement orip ospfcommand did not match it.show ip protocols— confirm the Router ID, the network statements/passive interfaces, and the neighbors being learned. This catches a LAN that is passive when it should not be, or a network statement that is absent.show ip route ospf— confirm the actual O routes. Only meaningful after the first three are clean.
show ip ospf database is available for inspecting the LSDB, but at CCNA you rarely need it — the neighbor and interface commands localize almost every fault.
Why check the neighbor table before the routing table?
Because a missing route has two very different causes, and the neighbor table separates them instantly. If the neighbor is not FULL, the problem is adjacency formation — timers, area, subnet, MTU, or a down interface — and no amount of route troubleshooting helps until the neighbor comes up. If the neighbor is FULL but a route is still missing, the adjacency is fine and the fault is local — a passive-interface, a missing network statement, or the interface simply not enabled for OSPF. One glance at show ip ospf neighbor tells you which half of the problem space to search.
Every fault has a fingerprint. Match the symptom to the cause instead of guessing:
| Symptom | Most likely cause | Confirm with |
|---|---|---|
| No neighbor at all | Area-ID mismatch, subnet/mask mismatch, interface down, ACL blocking proto 89, or OSPF not enabled on the interface | show ip ospf interface, show ip interface brief |
| Stuck INIT | One-way Hellos — neighbor does not see this router's RID (timer mismatch, multicast/ACL) | show ip ospf neighbor, compare timers in show ip ospf interface |
| Stuck 2-WAY (where FULL expected) | On broadcast, expected DR/BDR relationship not forming; normal only between DROTHERs | check priorities and DR/BDR in show ip ospf interface |
| Stuck ExStart / Exchange | MTU mismatch on the link | show ip ospf interface (MTU), show interface |
| Neighbor FULL but route missing | Passive-interface on the wrong port, missing network statement, or interface not enabled | show ip protocols, show ip ospf interface brief |
| Suboptimal path | Reference-bandwidth or manual-cost inconsistency | show ip ospf interface (cost) |
The two mismatch families. Faults split cleanly. Adjacency-blocking mismatches — hello/dead timers, area ID, subnet/mask, stub flag, authentication — stop the neighbor from forming; you see no neighbor or a stuck state. Route-blocking local errors — passive-interface, missing/wrong network statement, wrong wildcard — leave the neighbor perfectly healthy but keep a route out of the table. Knowing which family you are in (from the neighbor table) is 80% of the diagnosis.
Stuck-state and missing-route troubleshooting table (topic guide)
Free CCNA | Configuring OSPF (3) | Day 28 Lab | CCNA 200-301 Complete Course
~6 min
Optional demonstration of the verification show commands on a live OSPF topology. The written lesson and lab checkpoints cover what the gate tests.
Skip if you can run the verification sequence and read its output.
Watch on YouTubeA healthy baseline to compare against
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 0 FULL/ - 00:00:36 10.1.12.2 GigabitEthernet0/1
3.3.3.3 0 FULL/ - 00:00:33 10.1.13.3 GigabitEthernet0/2
R1# show ip route ospf
10.0.0.0/8 is variably subnetted
O 10.1.20.0/24 [110/2] via 10.1.12.2, 00:07:41, GigabitEthernet0/1
O 10.1.30.0/24 [110/2] via 10.1.13.3, 00:07:41, GigabitEthernet0/2
Both neighbors are FULL on point-to-point links (the / - role field means no DR/BDR, correct for point-to-point), and the two remote LANs are present as O routes. This is what "working" looks like — keep it as your reference.
Pause and predict
Two separate faults, each on a different topology:
Fault A: show ip ospf neighbor on R1 shows R2 flapping between EXSTART and EXCHANGE, never FULL. The link is up and pings across it succeed.
Fault B: R1 and R2 are FULL, but R2's LAN 10.1.20.0/24 is missing from R1's routing table.
For each, name the most likely cause and the command that confirms it.
Reveal answer
Fault A is an MTU mismatch. Stuck ExStart/Exchange is its signature: during the DBD exchange the two routers compare interface MTU and refuse to proceed if they differ. Pings still succeed because small packets fit both MTUs — which is exactly why "the link is up and pings fine" does not clear it. Confirm with show ip ospf interface GigabitEthernet0/1 (it prints the MTU) on both ends, then match the MTU (or apply ip ospf mtu-ignore as a lab shortcut).
Fault B is a local route-blocking error, because the neighbor is already FULL — so the LSDB is syncing and adjacency is fine. The likely cause is that R2's LAN was never enabled for OSPF at all — no network statement or ip ospf command covers it — so R2 never advertises 10.1.20.0/24. (Note that a passive-interface on that LAN would not explain a missing route: a passive interface still advertises its connected subnet, it only stops Hellos.) Confirm with show ip protocols and show ip ospf interface brief on R2 — the LAN interface will be absent from the OSPF interface list. Add the network statement (or ip ospf 1 area 0 on the LAN) and the O route appears on R1.
After a simulated fix, use the trainer to confirm exactly which O routes and metrics should now be present so you can tell a full recovery from a partial one.
Open routing-tableThis is the verification and fault-isolation stage of the shared lab-week5-ospf-single-area lab. First confirm a healthy domain, then repair a deliberately broken adjacency.
Lab checkpoint · lab-week5-ospf-single-area · ~6 min · packet_tracer
Skill: Confirm a healthy single-area OSPF domain with the core show commands
Starting: OSPF is configured on R1, R2, R3 in area 0 with expected LANs and links.
Action: Run show ip ospf neighbor, show ip ospf interface brief, show ip protocols, and show ip route ospf and confirm every expected adjacency and route.
Verify: All transit neighbors are FULL, each intended interface is listed, and every remote LAN appears as an O route.
Variant: Compare the neighbor list against the topology to spot a link where the adjacency is missing entirely.
Lab checkpoint · lab-week5-ospf-single-area · ~6 min · troubleshooting
Skill: Diagnose and fix an adjacency that will not form due to a parameter mismatch
Starting: One transit link is configured with a mismatched area (or timers/MTU) so the neighbor never reaches FULL.
Action: Use show ip ospf interface and show ip ospf neighbor to identify the mismatched parameter, then correct it on the offending router.
Verify: The adjacency climbs to FULL and the previously missing O routes populate the table.
Variant: Distinguish an area mismatch (no neighbor forms at all) from an MTU mismatch (stuck ExStart/Exchange).
Quick check (3 items) · test
Answer from memory:
- What is the first OSPF verification command, and what does a healthy result look like on a point-to-point link?
- A neighbor is stuck in ExStart/Exchange while pings across the link succeed. What is the cause?
- Two routers are FULL but one remote LAN is missing on the other. Which family of fault is this, and where do you look?
Review sheet
- Verify in order:
show ip ospf neighbor→show ip ospf interface brief→show ip protocols→show ip route ospf. - Adjacency-blocking mismatch (timers/area/subnet/MTU/auth) = no neighbor or a stuck state.
- Route-blocking local error (passive/missing network statement) = neighbor FULL but route missing.
- Stuck INIT = one-way Hellos; stuck ExStart/Exchange = MTU mismatch; area mismatch = no neighbor at all.
- 2-WAY between DROTHERs is normal — only a problem where FULL is expected.
Troubleshooting scenario
Symptom. R1 and R2 share a working Ethernet link (pings succeed) and both run OSPF, but show ip ospf neighbor lists no neighbor at all and neither learns the other's routes.
Diagnosis. No neighbor -- not a stuck state -- points to an adjacency-blocking mismatch that prevents Hellos from being accepted. show ip ospf interface on each side reveals R1's interface is in area 0 while R2's is in area 1. An area-ID mismatch means the Hellos are discarded and no neighbor entry is ever created.
Fix. Place both interfaces in the same area (correct R2 to area 0, or R1 to area 1 to match the design). The neighbor forms and climbs to FULL, and the O routes populate. Contrast: had this been an MTU mismatch, a neighbor would exist but sit stuck in ExStart/Exchange.
OSPF gives routers redundant paths; HSRP gives end hosts a redundant default gateway — the last piece of Week 5.
Next: First-Hop Redundancy (HSRP)