Neighbours and adjacencies
OSPF runs directly over IP as protocol 89 — no TCP, no UDP. It handles reliability itself with acknowledgements and retransmissions. Neighbours are discovered automatically by sending Hello packets to the multicast address 224.0.0.5 on every OSPF-enabled interface.
What must match
A Hello is silently discarded unless these fields agree between the two routers:
| Field | Default | Notes |
|---|---|---|
| Area ID | — | Both interfaces must be in the same area |
| Hello / Dead interval | 10s / 40s | Broadcast & point-to-point defaults (30s/120s on NBMA) |
| Subnet and mask | — | Not checked on point-to-point links |
| Stub area flag | — | Both must agree whether the area is a stub |
| Authentication | none | Type and key must match |
| Router ID | — | Must be different — duplicates are ignored |
MTU is not in the Hello. It is checked later, during the database exchange, which is why an MTU mismatch produces the classic "stuck in ExStart/Exchange" symptom.
Neighbour states
| State | Meaning |
|---|---|
| Down | No Hellos heard from this neighbour recently |
| Init | Heard their Hello, but they haven't listed our router ID yet (one-way) |
| 2-Way | Both see each other. On a LAN, non-DR routers stop here — by design |
| ExStart | Negotiating master/slave for the database exchange |
| Exchange | Swapping database summaries (DBD packets) |
| Loading | Requesting the LSAs we're missing |
| Full | Databases are synchronised — this is the goal |
- Down → Init. R1 sends a Hello to 224.0.0.5 (AllSPFRouters) every 10 seconds. It lists the neighbours R1 has heard from — none yet. When R2 receives it, R2 moves R1 to Init.
- Init → 2-Way. R2's Hello lists R1's router ID. R1 sees itself in the list: communication works both ways, so R1 moves R2 to 2-Way.
- 2-Way on both sides. R1's next Hello lists R2, and R2 reaches 2-Way too. On a point-to-point link the routers always continue to a full adjacency. (On a LAN, two non-DR routers stop here — that's normal.)
- ExStart: who leads?. Both send an empty Database Description (DBD) packet claiming to be master. The higher router ID (R2) wins and controls the sequence numbers. MTU is checked here — a mismatch leaves neighbours stuck in ExStart.
- Exchange: compare catalogues. The routers send DBDs listing the headers of every LSA they hold — a table of contents, not the LSAs themselves.
- Loading: fetch what's missing. R1 sends a Link State Request for LSAs it lacks or has older copies of. R2 answers with a Link State Update containing the full LSAs.
- Full. R1 acknowledges the LSAs. Both databases are now identical: the adjacency is Full and both routers re-run SPF.
- Steady state. Hellos continue every 10s. Miss them for the dead interval (40s) and the neighbour is torn down. LSAs are refreshed every 30 minutes even if nothing changes.
Interactive: Adjacency lab Two routers on one link. Change any setting and see how far the adjacency gets. Try: area 1 on R2, MTU 9000 on R1, a stub area on one side, an auth key on one side, or block inbound OSPF on R2. (needs JavaScript)
Check your understanding
R1 has listed R2 in ExStart for ten minutes. Hellos are flowing fine in both directions. What's the most likely cause?
- Area ID mismatch
- MTU mismatch
- Hello timer mismatch
- Duplicate router ID