Guides
What an “Open-Only” BGP Capture Really Means
You capture a BGP session and see the OPEN — then nothing. Is the peer down, or did you just miss the rest? Here's how to read it without jumping to conclusions.
Read article All articles
Packet analysisJuly 16, 20269 min read
How to Diagnose an OSPF Adjacency From a Packet Capture
An OSPF neighbor that won't reach Full is usually one of a few problems — and the capture shows which. Here's how to read the adjacency straight from the packets.
Key takeaways
- An OSPF adjacency has a visible lifecycle in the capture — Hello, then DBD, then LSR/LSU/LSAck. Where it stops tells you what's wrong.
- Most stuck adjacencies come down to a short list: one-way Hellos, mismatched timers, subnet/MTU disagreement, or an authentication mismatch — all visible in the packets.
- Read the capture as evidence, not verdict: it shows what was observed, with a confidence level. Missing packets are a capture limitation, not proof a device is misconfigured.
An adjacency is a sequence you can watch
Two OSPF routers don't become neighbors in one step. They move through a sequence, and every stage leaves packets behind: periodic Hellos to find each other and agree on parameters, then a Database Description (DBD) exchange to compare link-state databases, then Link State Request, Update and Acknowledgment packets to sync the missing pieces.
That's the key insight for troubleshooting from a capture: you don't have to guess the neighbor state — you can watch where the sequence stops. An adjacency stuck before DBD is a different problem from one that exchanges DBDs but never finishes, and the packets tell you which.
Start with the Hello — is it two-way?
The single most common OSPF problem is a one-way Hello. Router A lists Router B in its Hello's neighbor field, but B never lists A back (or you only ever see Hellos from one side). Until each router sees its own ID in the other's Hello, the adjacency can't progress past the two-way check.
So the first question is simply: do you see Hellos from both routers, and does each one name the other? If not, you have a one-way visibility problem — a filtered direction, a unidirectional link, or a capture taken at a point that only sees one side.
- Hellos from only one router: a capture placement or link-direction issue, or the other side isn't sending.
- Hellos both ways but neighbor lists empty or non-reciprocal: each side isn't hearing the other — investigate the return path.
- Hellos both ways and reciprocal: the two-way check passes; move on to parameters and DBD.
Hellos agree to exist — do they agree on terms?
Even with two-way Hellos, an adjacency won't form if the routers disagree on the parameters carried in those Hellos. These mismatches are all right there in the packet:
- Hello and dead interval: both values are in the Hello. If they differ between the two routers, the adjacency won't hold — one side times the other out.
- Area ID and network mask: a subnet-mask disagreement (or unexpected multi-area participation) shows up as routers that Hello but never settle.
- Authentication: if one side sends authenticated Hellos and the other doesn't, or the types differ, the exchange stalls. The auth fields are visible even when you can't read the secret.
- Duplicate router IDs: two routers advertising the same ID produce confusing, unstable neighbor behavior that's obvious once you line the IDs up.
When DBDs start but never finish, look at MTU
If Hellos are healthy but the adjacency loops in the DBD exchange — DBDs going back and forth without ever moving on to full sync — the classic culprit is an MTU mismatch. Each DBD carries the interface MTU, and if the two routers disagree, one keeps rejecting the other's database description.
This is a great example of reading state from evidence: you don't need device access to suspect it. You can see the DBDs, see the MTU values they carry, and see that the exchange never progresses — enough to point the on-site engineer straight at the interface MTU.
Report the observation, with a confidence level
The discipline that makes packet-based OSPF diagnosis trustworthy is honesty about what the capture proves. A capture shows observed behavior — the Hellos, DBDs and LSAs that were on the wire at that point, at that time. It does not show the device's running configuration, and a missing packet is a limit of the capture, not evidence that something didn't happen.
So the useful output isn't "router X is misconfigured" — it's "the capture shows a one-way Hello from X to Y with no reciprocal neighbor, medium confidence; check Y's interface and auth against X, frames 1042–1190." That's a finding an engineer can act on and defend.
Frequently asked questions
Why is my OSPF neighbor stuck and what does the capture show?
OSPF neighbors usually stick for a few reasons that are all visible in a capture: one-way Hellos (the two-way check never passes), mismatched Hello/dead timers, subnet-mask or MTU disagreement seen during the DBD exchange, or an authentication mismatch. Which stage the packet sequence stops at tells you which problem you're looking at.
What does a one-way OSPF Hello mean?
It means one router's Hello names the other as a neighbor but not vice versa (or you only see Hellos from one side). The adjacency can't progress past the two-way state. In a capture it's a strong lead — but it can also just mean the capture only saw one direction of traffic, so confirm on the device.
Can you tell OSPF authentication or MTU mismatch from a PCAP?
Yes. Authentication type and presence are visible in the Hello even when the secret isn't readable, so a one-sided or mismatched auth setup is observable. An MTU mismatch shows up as a DBD exchange that loops without completing, because each DBD carries the interface MTU the routers disagree on.