Lesson 3 — OSPF Concepts and Neighbor Formation
Week 5 outline
- Week 5 overview
- Lesson 1Reading show ip route
- Lesson 2Routing Failure Isolation
- QuizReading & Troubleshooting Routes
- Lesson 3OSPF Concepts and Neighbor Formation (current step)
- Lesson 4Single-Area OSPFv2 Configuration
- QuizOSPF Neighbours & Configuration
- Lesson 5OSPF Cost, DR/BDR, and Default Routes
- Lesson 6OSPF Verification and Troubleshooting
- QuizOSPF Tuning & Verification
- Lesson 7First-Hop Redundancy (HSRP)
- CheckpointWeek 5 Checkpoint
OSPF Concepts and Neighbor Formation
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 neighbour state that proves the adjacency formed.
Lesson orientation
What you'll learn (5 objectives)~44 min: video → lesson → check → apply → lab prep
Learning objectives
- Explain OSPF as link-state — LSAs into an LSDB, then SPF — versus distance-vector rumour
- List the Hello parameters that must match for an adjacency to form
- Walk the neighbour state machine from Down through to Full
- Read show ip ospf neighbor and interpret State together with the DR/BDR role
- Diagnose a stuck neighbour to the specific mismatch that caused it
Terms you will see
Time breakdown
- Read the notes22 min
- Routing Table Trainer12 min
- Neighbour diagnosis practice10 min
Assigned video

OSPF Part 1 (Day 26)
By Jeremy's IT Lab · Opens externally on YouTube
- Assigned watch
- ~8 min
The link opens in a new browser tab. Return here when you finish watching.
Watch for these concepts
- Hello discovery and LSDB synchronisation on live routers
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.
OSPF shares a map, not a rumour
Distance-vector protocols tell neighbours which networks they can reach and how far away those are. OSPF does something different: each router describes its own links in a link-state advertisement, floods those LSAs to every router in the area, and every router assembles an identical link-state database — 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 quickly and avoids the loops distance-vector protocols risk during a change. Once neighbours are up they exchange database-description packets to compare databases, request the LSAs they are missing, receive them, and acknowledge. After that initial sync, updates are event-driven — a link change floods a new LSA — rather than periodic full-table dumps.
| Item | Value |
|---|---|
| Transport | Directly on IP protocol 89 — not TCP, not UDP |
| Hello destination | Multicast 224.0.0.5 |
| Hello / dead interval | 10 s / 40 s by default on broadcast and point-to-point |
| Router ID selection | Manual router-id, else highest loopback IP, else highest active physical IP |
| Administrative distance | 110 |
Hello does the negotiating
| Must match | Why |
|---|---|
| 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 versus normal |
| Authentication | Type and key must match if configured |
Notice what is not on that list: process ID, the Router ID value — which must be unique rather than matching — interface cost, and bandwidth. None of those ever blocks an adjacency, which is why a neighbour problem is never a metric problem.
| 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; DR/BDR election happens here on multi-access links |
| ExStart | Master and slave roles negotiated to control the database exchange |
| Exchange | Database-description packets summarise each LSDB |
| Loading | Requests and updates fill in any missing LSAs |
| Full | Databases synchronised — the adjacency is complete |
Reading 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/2Neighbor ID is the peer's Router ID, not its interface address. Pri is the interface OSPF priority used in DR election. State has two parts — the adjacency state and the neighbour's role on that segment. Dead Time counts down and resets on every Hello; if it reaches zero the neighbour drops. Address is the peer's interface IP, which becomes the next hop for its routes, and Interface is the local port facing it.
Line by line: R1 is FULL with 2.2.2.2 and 3.3.3.3, so those databases are synchronised and their routes are trustworthy. The third neighbour sits 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, and a priority of 0 even makes 4.4.4.4 ineligible for DR, so they intentionally stop at 2-WAY and rely on the DR to relay LSAs.
What you should retain
- Link-state: LSAs build an LSDB, then each router runs SPF on it independently.
- OSPF rides on IP protocol 89 and sends Hellos to 224.0.0.5; its AD is 110.
- Must match: hello and dead timers, area ID, subnet and mask, stub flag, authentication. Process ID need not.
- States run Down, Init, 2-Way, ExStart, Exchange, Loading, Full.
- FULL means synchronised databases; 2-WAY between two DROTHERs is normal.
- Stuck ExStart or Exchange means an MTU mismatch; stuck INIT means one-way Hellos.
Before you read on
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?
See it happen
Routing Table Trainer
Once an adjacency is Full, confirm you can read the resulting O routes and their [110/cost] values. Recognising OSPF routes by their AD in a mixed table is the practical payoff of this lesson.
Study deeper
Topic guides extend this lesson — they do not replace the first-party walkthrough above.
OSPF
For link-state mechanics, the full OSPF packet types, and Router ID selection in more depth
OSPF Neighbours & Design
For the complete state machine and a fuller stuck-state troubleshooting table
