BGP session lifecycle

BGP is a TCP-based session, but TCP establishment is only the first gate. After the three-way handshake, the routers exchange OPEN messages, negotiate capabilities, confirm the hold-time contract, and only then enter Established. A session that is “up at Layer 4” can still be stuck in Active, rejected in OpenSent, or held in OpenConfirm.

The six-state lifecycle gives the operator a diagnostic map. Instead of saying “BGP is down,” the engineer can say “the session reached Active but did not complete TCP, so I am looking for a source route, return ACL, authentication, or wrong peer address.”

stateDiagram-v2
  [*] --> Idle
  Idle --> Connect: start or reset
  Connect --> Active: TCP connection attempt
  Connect --> Idle: connect failure
  Active --> OpenSent: TCP established and OPEN sent
  Active --> Idle: retry timer or failure
  OpenSent --> OpenConfirm: valid OPEN received
  OpenSent --> Idle: NOTIFICATION or hold failure
  OpenConfirm --> Established: KEEPALIVE accepted
  OpenConfirm --> Idle: fatal error
  Established --> Idle: hold expiry, reset, or shutdown
  Established --> Established: UPDATE, KEEPALIVE, and refresh

Idle: a decision to wait

Idle is the starting and administrative-rest state. The router is not actively attempting the TCP connection. Configuration changes, administrative shutdowns, fatal protocol errors, and some automatic resets return the peer to Idle before a later retry.

A router can be administratively configured and still show Idle when the neighbor is shut down, the BGP process is unavailable, or the candidate configuration has not been committed. Check the active configuration before interpreting Idle as a network failure.

The retry transition out of Idle is controlled by ConnectRetry. A short retry interval helps recovery but can create repeated log noise when the remote path is permanently misconfigured.

Connect: opening TCP port 179

Connect means the local speaker is attempting the TCP three-way handshake. The destination port is normally TCP 179. The source can be an interface address, a loopback selected with update-source, or another explicitly configured source.

The handshake is not proof that the remote router accepts the BGP session. A firewall can allow the SYN and SYN-ACK while dropping subsequent packets, or an authentication option can be required on every segment. Use both state output and a packet capture at this state.

Active: TCP is not enough

Active is the classic “connection attempt did not settle” state. It usually indicates that the TCP connection has not completed reliably, or that the local process is retrying after a failed attempt. The most common causes are:

• the neighbor address is not the address the remote router uses;
• an ACL, firewall, or zone policy blocks the return path;
• the source address is not routable or is not stable;
• TCP MD5 or another transport authentication mismatch causes resets;
• an eBGP peer is multiple hops away without the intended TTL or source configuration;
• the remote device is listening on a nonstandard port.

sequenceDiagram
  participant L as Local bgpd
  participant N as Network path
  participant R as Remote bgpd
  L->>N: SYN to peer port 179
  N-->>L: SYN-ACK or timeout
  L->>R: OPEN only after TCP completes
  R-->>L: OPEN or NOTIFICATION
  L->>R: KEEPALIVE
  R->>L: KEEPALIVE
  L->>R: UPDATE

OpenSent: OPEN is in flight

OpenSent means the local router sent its BGP OPEN and is waiting for the remote OPEN. The TCP connection is therefore present, but protocol negotiation has not completed. The remote router may have rejected the local AS, local router ID, capability set, or address family.

The most useful evidence is the detailed neighbor output and a packet capture. Search for NOTIFICATION messages and compare the offered and received fields. An AS mismatch is often visible in the neighbor summary and in the OPEN message; an address-family capability issue may require a specific family activation or a capability flag.

OpenConfirm: the contract is nearly complete

OpenConfirm means the local router received the remote OPEN and is waiting for the first KEEPALIVE, or for a NOTIFICATION. Hold time, keepalive, and capability negotiation have mostly happened.

A session in OpenConfirm often points to hold-time negotiation, transport authentication, or a reset after the OPEN. Verify that both ends propose compatible settings and that the peer accepts the configured source. Do not shorten timers as the first response; a fatal protocol event is already telling you that the contract was not acceptable.

Established: routes may flow

Established means the session has completed OPEN exchange and at least one KEEPALIVE. UPDATE messages can now flow, and the peer can appear in the BGP summary as a source of prefixes. Established is the first state in which route validation should begin; it is not the end of validation.

The session remains Established only while KEEPALIVE or UPDATE traffic satisfies the negotiated hold-time contract. The hold timer is reset by a valid KEEPALIVE or UPDATE, not by an operator looking at a dashboard.

A state-to-evidence table

VyOS validation sequence

A repeatable first pass is:

show bgp summary
show bgp neighbor 192.0.2.2
show log protocol bgp
show interfaces

Then inspect transport:

ss -tnp | grep ':179'
tcpdump -ni any host 192.0.2.2 and tcp port 179

A capture that shows SYN without SYN-ACK points to the network path. A complete handshake followed by RST points to a policy, authentication, or source issue. An OPEN followed by a NOTIFICATION points to BGP parameters. A stable TCP and OPEN flow with no final KEEPALIVE points to the hold-time contract or a local process issue.

How it fails

• A session repeatedly returns from Established to Idle after the hold time because the return path drops KEEPALIVE packets.
• An operator configures remote-as with the local value and waits for OpenConfirm, while the peer correctly rejects the relationship.
• A route is present in the summary but no prefix count is received; the session is up, but the address family is not active.
• A source loopback is configured, but the peer still uses the physical interface source and applies the wrong next-hop policy.
• A TCP MD5 mismatch looks like a TCP problem in a capture even though the underlying design decision is a secret mismatch.
• A multihop eBGP session remains in Active because the TTL or connected-route check was not changed deliberately.

Rollback

For a bad neighbor, remove the peer only after preserving the old configuration and the failure evidence:

configure
delete protocols bgp neighbor 192.0.2.2
commit
save

For a timer or source change, restore the previous values rather than flapping the peer with repeated edits. If the session is used for remote administration, use commit-confirm and retain an out-of-band console path.

Cross-course references

XVII-VyOS-RoutingFund introduces adjacency concepts and the distinction between control and data plane. XXIV-VyOS-BGPSession covers configuration, neighbors, timers, authentication, multihop, and session troubleshooting in detail. XXXI-VyOS-BGPTroubleshoot extends this state machine into a full incident workflow, while XXXII-VyOS-BFD explains a faster failure detector that complements BGP timers. The OPNsense and Linux courses provide useful comparisons for the same FRR event model.

Quiz