What an “Open-Only” BGP Capture Really Means

The BGP session lifecycle, in packets

A healthy BGP session has a recognisable shape on the wire. Two speakers exchange OPEN messages to agree on versions, AS numbers, hold timers and capabilities. They confirm with KEEPALIVEs, then exchange UPDATEs carrying prefixes, paths and attributes. KEEPALIVEs continue at the negotiated interval to hold the session up. A NOTIFICATION means one side is tearing the session down, and it carries a reason.

Because that sequence is so predictable, the interesting question in most BGP captures is simply: how far did it get? An OPEN followed by KEEPALIVEs and UPDATEs is an established, productive session. An OPEN followed by a NOTIFICATION is a session that reset — and the NOTIFICATION tells you why. And an OPEN followed by nothing is the case that trips people up.

“Open-only” is a capture result, not a diagnosis

An open-only result means exactly one thing: the capture contains OPEN evidence but no later session activity for that peer. It is tempting to read that as “the session never came up” — but the capture can be open-only for two very different reasons, and they lead to opposite conclusions.

• The session genuinely didn't establish: the OPEN was sent, the peer never completed the handshake, and there is nothing more to see because nothing more happened.
• The capture simply missed it: the session was already up (or came up outside the capture window), or the capture was taken at a point that only saw the OPEN and not the ongoing KEEPALIVEs and UPDATEs.

How to tell which one you've got

A few checks quickly separate a real failure from a capture artefact:

• Look at the capture window: does it span long enough to have seen at least one KEEPALIVE interval? A 5-second capture of a session with a 60-second keepalive will look open-only even when the session is perfectly healthy.
• Check capture placement: were you positioned to see both directions and the ongoing traffic, or only the initial exchange?
• Look for a NOTIFICATION: if the session actually failed to establish or was reset, there's often a NOTIFICATION with a structured reason (hold timer expired, bad parameters, administrative reset). Its presence turns “open-only” into a concrete cause.
• Correlate with the data plane: if traffic was flowing to prefixes that peer would have announced, the session was almost certainly up and the capture just missed it.

Why the distinction matters

Calling an open-only capture a “peer failure” when the session was actually healthy sends an investigation in the wrong direction and can escalate an incident that isn't real. Calling a real failure a “capture artefact” does the opposite. The whole point of reading BGP from evidence is to keep those two apart and attach a confidence level to whichever you conclude.

So the good habit is to state what the packets show, note that it's open-only, and record the reason you believe it's a real failure or a capture limitation — with the frames that support it. That's a finding the next engineer can trust.