PracticeLabs
Week 50%

Lesson 6 — OSPF Verification and Troubleshooting

Week 5Lesson 6Required42 min estimated0% progress

OSPF Verification and Troubleshooting

Verify a single-area OSPF domain with the core show commands, and map each stuck adjacency state and each missing-route symptom to the exact mismatch that caused it.

Lesson orientation

What you'll learn (5 objectives)~42 min: video → lesson → check → apply → lab prep

Learning objectives

  • Verify OSPF in order: neighbor, interface, protocols, then routes
  • Interpret the neighbour state and DR/BDR role to decide whether an adjacency is healthy
  • Map a stuck INIT, 2-Way, or ExStart/Exchange state to its root cause and correct it
  • Diagnose a missing OSPF route caused by an area, mask, passive-interface, or network-statement error
  • Use a mismatched-parameter checklist to localise an adjacency failure

Terms you will see

Verification orderAdjacency-blocking mismatchRoute-blocking local errorMTU mismatchArea mismatch

Time breakdown

  • Read the notes20 min
  • Routing Table Trainer14 min
  • Fault diagnosis practice8 min

Assigned video

Opens on YouTube
Optional video

Free CCNA | Configuring OSPF (3) | Day 28 Lab | CCNA 200-301 Complete Course

By Jeremy's IT Lab · Opens externally on YouTube

Assigned watch
~6 min
Watch on YouTube(opens in a new tab)

The link opens in a new browser tab. Return here when you finish watching.

Watch for these concepts

  • The verification show commands demonstrated on a live OSPF topology

Go beyond the video

The assigned video introduces the idea. CCNA Practice Labs completes the learning path: clarify core concepts, explore how each device behaves, visualize the communication path, check your understanding, and prepare for hands-on lab work.

Watch the concept → understand it → visualize it → practice it → apply it.

Verify from adjacency outward to routes

OSPF builds routes in stages — neighbours form, databases sync, SPF runs, routes install. Verify in that same order so a failure surfaces at the earliest stage rather than being chased at the wrong end.

  1. show ip ospf neighbor — the single most important command. Confirm each expected peer is FULL with a valid Router ID and next hop. If a neighbour is missing or stuck, stop here; nothing downstream will be right.
  2. show ip ospf interface brief — confirm every interface you intended to run OSPF is listed, in the right area, with a sensible cost and neighbour count. A missing interface means your network statement did not match it.
  3. show ip protocols — confirm the Router ID, the network statements and passive interfaces, and the neighbours being learned.
  4. show ip route ospf — confirm the actual O routes. Only meaningful once the first three are clean.
Why the neighbour table comes before the routing table
A missing route has two very different causes, and the neighbour table separates them instantly. If the neighbour is not FULL, the problem is adjacency formation — timers, area, subnet, MTU, or a down interface — and no amount of route troubleshooting helps until it comes up. If the neighbour is FULL but a route is still missing, the adjacency is fine and the fault is local. One glance tells you which half of the problem space to search, which is most of the diagnosis.

Every fault has a fingerprint

Symptom to cause to confirming command
SymptomMost likely causeConfirm with
No neighbour at allArea-ID mismatch, subnet/mask mismatch, interface down, ACL blocking protocol 89, or OSPF not enabled on the interfaceshow ip ospf interface, show ip interface brief
Stuck INITOne-way Hellos — the neighbour does not see this router's RID, usually a timer mismatch or blocked multicastshow ip ospf neighbor, compare timers
Stuck 2-WAY where FULL expectedThe expected DR/BDR relationship is not forming; normal only between DROTHERscheck priorities and DR/BDR roles
Stuck ExStart or ExchangeMTU mismatch on the linkshow ip ospf interface, show interface
Neighbour FULL but route missingMissing network statement, or the interface never enabled for OSPFshow ip protocols, show ip ospf interface brief
Sub-optimal path chosenReference-bandwidth or manual-cost inconsistencyshow ip ospf interface (cost)
The two mismatch families
Faults split cleanly. Adjacency-blocking mismatches — hello and dead timers, area ID, subnet and mask, stub flag, authentication — stop the neighbour forming, so you see no neighbour or a stuck state. Route-blocking local errors — a missing or wrong network statement, an interface never enabled — leave the neighbour perfectly healthy but keep a route out of the table. Knowing which family you are in, from one command, is the bulk of the work.

A healthy baseline to compare against

What working looks like
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 neighbours are FULL on point-to-point links — the dash in the role field means no DR or BDR, which is correct for point-to-point — and the two remote LANs are present as O routes. Keep this as your reference for what a clean domain looks like, because most diagnosis is spotting how a broken table differs from this one.

Troubleshooting — no neighbour at all on a working link
Symptom: R1 and R2 share an Ethernet link, pings succeed, both run OSPF, but show ip ospf neighbor lists no neighbour whatsoever and neither learns the other's routes. Diagnosis: no neighbour — as opposed to a stuck state — points to an adjacency-blocking mismatch that prevents Hellos being accepted at all. 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 neighbour entry is ever created. Fix: place both interfaces in the same area. Contrast: had this been an MTU mismatch, a neighbour would exist but sit stuck in ExStart or Exchange.

What you should retain

  • Verify in order: show ip ospf neighbor, then interface brief, then protocols, then route ospf.
  • An adjacency-blocking mismatch gives no neighbour or a stuck state.
  • A route-blocking local error gives a FULL neighbour with a route still missing.
  • Stuck INIT means one-way Hellos; stuck ExStart or Exchange means an MTU mismatch; an area mismatch means no neighbour at all.
  • 2-WAY between DROTHERs is normal, and only a problem where FULL was expected.
  • passive-interface never explains a missing route — it still advertises the connected subnet.
Pause and predictNot scored — nothing is recorded

Before you read on

Two separate faults. Fault A: R1 shows R2 flapping between EXSTART and EXCHANGE, never FULL, while the link is up and pings succeed. Fault B: R1 and R2 are FULL, but R2's LAN 10.1.20.0/24 is missing from R1's table. For each, name the most likely cause and the command that confirms it.

Interactive tool

See it happen

Required~14 min

Routing Table Trainer

After a simulated fix, confirm exactly which O routes and metrics should now be present, so you can tell a full recovery from a partial one. Declaring victory too early is the most common troubleshooting error after fixing the wrong device.

Open the tool
Section quiz

Check this section before moving on

Required8 questions~10 min

OSPF Tuning & Verification

The quiz opens on its own page so you can focus on it. It is a Week 1 milestone, tracked separately from this lesson's own completion.

Topics covered

  • • Cost, reference bandwidth, and the cost-1 tie
  • • DR/BDR election, priority, and non-preemption
  • • Injecting a default route into OSPF
  • • The verification order and each fault fingerprint
Start the quiz

Study deeper

Topic guides extend this lesson — they do not replace the first-party walkthrough above.

OSPF

For the complete OSPF verification command reference

Open guide