PracticeLabs
Week 5Lesson 3Required44 min estimated0% progress

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

Link-stateLSALSDBSPF (Dijkstra)Router IDProcess IDHello / dead intervalAdjacencyDROTHER

Time breakdown

  • Read the notes22 min
  • Routing Table Trainer12 min
  • Neighbour diagnosis practice10 min

Assigned video

Opens on YouTube
Optional 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.

Hello does the negotiating

What must match for an adjacency to form
Must matchWhy
Hello and dead intervalsCarried in every Hello; a mismatch is rejected outright
Area IDBoth interfaces must be in the same OSPF area
Subnet and maskThe two interfaces must be on the same IP subnet
Stub area flagBoth sides must agree on stub versus normal
AuthenticationType 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.

The state machine, Down to Full
StateWhat is happening
DownNo Hello heard yet
InitA Hello arrived, but this router's RID is not yet listed in it — one-way so far
2-WayEach router sees its own RID in the other's Hello; DR/BDR election happens here on multi-access links
ExStartMaster and slave roles negotiated to control the database exchange
ExchangeDatabase-description packets summarise each LSDB
LoadingRequests and updates fill in any missing LSAs
FullDatabases synchronised — the adjacency is complete
Full is the goal, but not with everyone
On point-to-point links both routers should reach FULL. On a broadcast Ethernet segment, ordinary routers — DROTHERs — go FULL only with the DR and the BDR, and two DROTHERs deliberately settle at 2-WAY with each other. So 2-WAY is a fault only where you expected FULL, such as between a router and the DR. DR election is Lesson 5's subject; here you only need to recognise that 2-WAY between DROTHERs is normal.

Reading show ip ospf neighbor

Three neighbours, two of them Full
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

Neighbor 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.

Troubleshooting — a neighbour stuck at INIT
Symptom: R1 and R2 share an Ethernet link, both run OSPF in area 0, but the neighbour 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 its RID back. Fix: match the hello and dead intervals on both interfaces. The neighbour then climbs Init to 2-Way and on to Full, and the routes populate.

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.
Pause and predictNot scored — nothing is recorded

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?

Interactive tool
Required~12 min

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