Packet analysis
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.
Read article All articles
Packet analysisJuly 11, 20267 min read
Connecting a Routing Event to Application Impact
A prefix was withdrawn — so what broke? Getting from a control-plane event to real application impact is where investigations stall. Here's how the evidence connects them.
Key takeaways
- A control-plane event on its own — a withdrawn prefix, a flapping session — is a signal, not an impact assessment.
- The impact question is answered by correlating the routing change with the data-plane flows that used the affected prefix, in the same capture.
- An empty impact result means no matching data-plane evidence was found in the capture — it does not prove there was no dependency.
“A route changed” is where most write-ups stop
Plenty of routing investigations end at the control plane: a prefix was withdrawn, a BGP session reset, an OSPF adjacency dropped. That's a real finding — but it's not the question the business is asking. The business wants to know what broke, for whom, and for how long.
The gap between “a route changed” and “here's the impact” is where investigations stall, because it requires connecting two different planes: the control-plane event, and the data-plane traffic that depended on it.
The impact lives in the same capture
If a capture contains both the routing event and the data-plane traffic around it, the correlation is available directly. The affected prefix is the join key: find the flows whose addresses fall within the prefix that was announced or withdrawn, and you've found the traffic that depended on that route.
From there you can describe real impact instead of a hypothetical: which applications or protocols were using the prefix, which endpoints were involved, how many packets, and — crucially — the exact frames that support the assessment. That turns a control-plane note into an impact statement someone can act on.
- Identify the affected prefix from the routing event (the announced or withdrawn NLRI, or the OSPF route).
- Find data-plane flows whose source or destination falls within that prefix.
- Summarise the applications, endpoints and packet counts involved.
- Keep the link back to the packets so the impact claim is traceable, not asserted.
From a signal to a defensible statement
The difference this makes is the difference between two sentences in an incident report. “A route to 203.0.113.0/24 was withdrawn” is a signal. “The route to 203.0.113.0/24 was withdrawn at 14:02; these observed flows from three internal hosts were using the prefix, and here are the packets showing the traffic stop” is an impact assessment — one that survives scrutiny because every part of it points at evidence.
When there's no matching traffic
Sometimes the correlation comes back empty: the capture has the routing event but no data-plane traffic for the affected prefix. It's important to read that correctly. An empty impact result means no matching data-plane evidence was found in this capture — it does not prove there was no real dependency. The traffic may have been elsewhere, at another time, or simply not captured.
So the honest output distinguishes “no impact observed in this evidence” from “no impact”. The first is a fact about the capture; the second is a claim about the network you usually can't make from one PCAP.
Frequently asked questions
How do you connect a BGP or OSPF routing change to application impact?
Use the affected prefix as the join key. Take the announced or withdrawn prefix from the routing event and find the data-plane flows in the same capture whose addresses fall within it. Those flows — their applications, endpoints and packet counts — are the traffic that depended on the route, and they let you describe real impact backed by specific packets.
Does an empty impact result mean the routing change caused no problems?
No. An empty result means no matching data-plane traffic for the affected prefix was found in that capture. The dependent traffic may have occurred elsewhere, at a different time, or simply wasn't captured. It's a statement about the evidence, not proof that nothing was affected.
Why isn't “a route changed” enough for an incident report?
Because it's a signal, not an impact assessment. Stakeholders need to know what broke, for whom, and for how long. Correlating the routing event with the flows that used the affected prefix — and keeping the link to the supporting packets — turns a control-plane observation into a defensible impact statement.