When an Adjacency Will Not Form

Stuck at ExStart, and the checklist that will not find it

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Read a neighbour state as a diagnosis rather than a status
▸Explain why an MTU mismatch stalls at ExStart specifically
▸Name the three parameters that must match before an adjacency can form

Before this lesson — it builds directly on:

OSPF adjacencies do not simply work or fail. They stop, and where they stop tells you what has already succeeded and what has not. That makes the neighbour state the single most useful diagnostic OSPF gives you — more useful than any log line, because a stalled adjacency usually produces no log at all. Learning what each state means turns "it is not working" into "the hellos are getting through and the database exchange is not", which is a completely different investigation.

Watch these fields in the lab: ospf.type

1Down — nothing has been heard from this neighbour at all.
2Init — their hello arrived here. The link works in that direction.
32-Way — their hello listed our router id, so they can hear us too. Both directions proven.
4ExStart — both sides agreed to synchronise databases and are negotiating who leads.
5Exchange — Database Descriptions are being sent and accepted.
6Loading — the missing LSAs have been requested and are arriving.
7Full — the databases match. Only now does this adjacency contribute to anybody's SPF.

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

An adjacency is stuck at 2-Way between two routers on a point-to-point link. Is that normal?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.