Explain how OSPF builds a shared link-state database and walk two routers from Down to Full — naming what each Hello parameter must match and reading the neighbor state that proves the adjacency formed.
Week 5 · Lesson 3 · Active ~44 min · Video ~8 min (optional) · Lab ~12 min · Domain: IP Connectivity
You should be able to read an O route line and its [110/cost] field. This lesson explains how those O routes get there — starting with how two routers agree to talk.
Prerequisites: reading-show-ip-route
Paths: Start lesson · Test out (jump to the quick check) · Review sheet
Baseline check
Two routers are cabled together and both are running OSPF, but no OSPF routes appear on either one. show ip ospf neighbor shows the peer stuck at INIT. Before continuing, commit to a guess: is the problem more likely a wrong metric, or something in the Hello packet?
The answer — a Hello parameter, never a metric — is the core idea of neighbor formation. OSPF routers must agree before they exchange anything, and that agreement lives entirely in the Hello.
OSPF shares a map, not a rumor. Distance-vector protocols tell neighbors "here are the networks I can reach and how far." OSPF does something different: each router describes its own links in a link-state advertisement (LSA), floods those LSAs to every router in the area, and every router assembles the identical link-state database (LSDB) — a full map of the area. Each router then runs the SPF (Dijkstra) algorithm on that map by itself to compute the shortest path to every destination. Because everyone shares the same map and computes independently, OSPF converges fast and avoids the loops distance-vector protocols risk during changes.
The sequence, once neighbors are up. After two routers become adjacent, they exchange database-description (DBD) packets to compare LSDBs, request the LSAs they are missing (LSR), receive them (LSU), and acknowledge (LSAck). After that initial sync, updates are event-driven — a link change floods a new LSA — not periodic full-table dumps. OSPF rides directly on IP protocol 89 (not TCP or UDP) and sends Hellos to the multicast address 224.0.0.5.
Router ID: the router's name in OSPF. Every OSPF router needs a unique 32-bit Router ID (RID) in dotted-decimal form. IOS selects it, in order: a manually configured router-id; else the highest loopback IP; else the highest active physical IP. Best practice is to set it explicitly (or with a loopback) so that an interface flap cannot silently change the router's OSPF identity. Changing the RID after the process is running requires clear ip ospf process to take effect.
If OSPF process IDs differ on two routers, will they still form a neighbor?
Yes. The OSPF process ID (router ospf 1) is locally significant only — it never has to match the neighbor. It exists so one router could run more than one OSPF process. What must match are the Hello-carried parameters: hello/dead timers, area ID, the subnet/mask on the link, the stub flag, and authentication. Confusing process ID with those matching parameters is a classic exam trap — R1 with router ospf 1 and R2 with router ospf 99 form an adjacency perfectly well if their Hellos agree.
Link-state mechanics, packet types, and RID selection (topic guide)
Hello does the negotiating. OSPF discovers and maintains neighbors with Hello packets, sent every hello interval (10 s on broadcast/point-to-point by default). If no Hello is heard within the dead interval (40 s, four times the hello by default), the neighbor is declared down. For an adjacency to progress, both ends must agree on:
| Must match | Why it matters |
|---|---|
| Hello and dead intervals | Carried in every Hello; a mismatch is rejected outright |
| Area ID | Both interfaces must be in the same OSPF area |
| Subnet and mask | The two interfaces must be on the same IP subnet |
| Stub area flag | Both sides must agree on stub/normal |
| Authentication | Type and key must match if configured |
Notice what is not on the list: process ID, Router ID value (must be unique, not matching), interface cost, and bandwidth. Those never block adjacency.
The state machine — Down to Full. Watching show ip ospf neighbor during startup, a healthy pair climbs through these states:
| State | What is happening |
|---|---|
| Down | No Hello heard yet |
| Init | A Hello arrived, but this router's RID is not yet listed in it (one-way so far) |
| 2-Way | Each router sees its own RID in the other's Hello — bidirectional; DR/BDR election happens here on multi-access links |
| ExStart | Master/slave roles negotiated to control the DBD exchange |
| Exchange | DBD packets summarize each LSDB |
| Loading | LSR/LSU fills in any missing LSAs |
| Full | LSDBs synchronized — adjacency complete |
FULL is the goal — but not always with everyone. On point-to-point links both routers should reach FULL. On broadcast (Ethernet) segments, ordinary routers (DROTHERs) go FULL only with the DR and BDR; two DROTHERs deliberately settle at 2-WAY with each other. So "2-WAY" is a fault only when you expected FULL — between a router and the DR, for example. (DR/BDR election is the focus of a later lesson; here you only need to recognize that 2-WAY between DROTHERs is normal.)
Full state machine and stuck-state troubleshooting table (topic guide)
Free CCNA | OSPF Part 1 | Day 26 | CCNA 200-301 Complete Course
~8 min
Optional visual pass: watch Hello discovery and LSDB synchronization. The written lesson and lab checkpoint already cover what the gate tests.
Skip if the adjacency requirements and state machine above are clear.
Watch on YouTubeEnrichment only — the required work is bringing two routers to FULL in the lab checkpoint and reading the neighbor table.
Read show ip ospf neighbor
R1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
2.2.2.2 1 FULL/BDR 00:00:37 10.1.12.2 GigabitEthernet0/1
3.3.3.3 1 FULL/DR 00:00:34 10.1.23.3 GigabitEthernet0/2
4.4.4.4 0 2WAY/DROTHER 00:00:35 10.1.23.4 GigabitEthernet0/2
Reading each column: Neighbor ID is the peer's Router ID (not its interface IP). Pri is the interface OSPF priority used in DR/BDR election. State has two parts — the adjacency state (FULL or 2WAY) and the neighbor's role on that segment (DR/BDR/DROTHER). Dead Time counts down and resets on every Hello — if it hits zero the neighbor drops. Address is the peer's interface IP (the next-hop for its routes). Interface is the local interface facing that peer.
Line by line: R1 is FULL with 2.2.2.2 and 3.3.3.3 — those LSDBs are synchronized and their routes are trusted. The third neighbor, 4.4.4.4, is at 2WAY/DROTHER with priority 0. That is not a fault: both R1 and 4.4.4.4 are DROTHERs on the 10.1.23.0 segment (4.4.4.4's priority 0 even makes it ineligible for DR), so they intentionally stop at 2-WAY and rely on the DR to relay LSAs.
Pause and predict
On a point-to-point link, show ip ospf neighbor shows the peer stuck at EXSTART, flapping to EXCHANGE and back, never reaching FULL. Pings across the link succeed and the timers match. What single link property is the prime suspect, and how do you confirm it?
Reveal answer
The signature of a neighbor stuck in ExStart/Exchange is an MTU mismatch on the link. During the DBD exchange the routers compare interface MTU; if one side is 1500 and the other 1400, they cannot agree and never progress to Loading/Full. Pings still work because small ICMP packets fit either MTU — which is why "the link is up and pings fine" does not rule this out. Confirm with show ip ospf interface (it lists the MTU) or show interface, then match the MTU on both ends (or, as a lab shortcut, ip ospf mtu-ignore on the interface). Contrast with a stuck INIT, which means one-way Hellos — the neighbor is not yet seeing this router's RID, usually a multicast/ACL problem or a timer mismatch upstream.
After the adjacency reaches FULL in the lab, use the trainer to confirm you can read the resulting O routes and their [110/cost] values.
Open routing-tableThis is the neighbor-formation stage of the shared lab-week5-ospf-single-area lab (a skeleton you extend across the OSPF lessons). Here you only need two routers to reach FULL — configuration depth comes in the next lesson.
Lab checkpoint · lab-week5-ospf-single-area · ~12 min · packet_tracer
Skill: Bring two directly connected routers to a FULL OSPF adjacency in area 0
Starting: R1 and R2 are cabled on a common /30 with correct IPs; neither runs OSPF yet.
Action: Enable OSPF on the shared link on both routers in area 0 and confirm the adjacency forms.
Verify: show ip ospf neighbor lists the peer in state FULL with a valid neighbor Router ID and the peer's interface as the next-hop.
Variant: Set ip ospf hello-interval 5 on one side only and watch the neighbor never reach FULL because the timers no longer match; restore it to confirm the fix.
Quick check (3 items) · test
Answer from memory:
- Name three Hello parameters that must match for an adjacency, and one field that must be unique (not matching).
- What does state FULL prove, and why is 2-WAY between two DROTHERs not a problem?
- A neighbor is stuck flapping between ExStart and Exchange. What is the most likely cause?
Review sheet
- Link-state: LSAs → LSDB → SPF, per router; event-driven updates, protocol 89, Hellos to 224.0.0.5.
- Must match: hello/dead timers, area ID, subnet/mask, stub flag, auth. Process ID need not match.
- States: Down → Init → 2-Way → ExStart → Exchange → Loading → Full.
- FULL = synchronized LSDB; 2-WAY between DROTHERs is normal.
- Stuck ExStart/Exchange = MTU mismatch; stuck INIT = one-way Hellos.
Troubleshooting scenario
Symptom. R1 and R2 share an Ethernet link, both run OSPF in area 0, but the neighbor never leaves INIT and no O routes appear.
Diagnosis. INIT means R1 hears R2's Hello but R2 does not yet list R1's Router ID — the Hellos are one-way. show ip ospf interface reveals R1's hello-interval is 10 while R2's is 5, so R2 rejects R1's Hellos and never echoes R1's RID back.
Fix. Match the hello (and dead) intervals on both interfaces — restore R2 to ip ospf hello-interval 10 (or set both explicitly). The neighbor climbs Init -> 2-Way -> ... -> Full and the O routes populate.
You can recognize a healthy adjacency; next you configure OSPF cleanly — process, network statements or interface config, router-id, and passive interfaces.
Next: Single-Area OSPFv2 Configuration