Esc
Type to search posts, tags, and more...
Skip to content

BGP finite state machine

The six-state FSM that governs BGP session lifecycle — from Idle through Established, with events and transitions.

Contents

States

Each configured peer has an independent FSM instance. The six states:

StateDescription
IdleNo resources allocated. Refuses all incoming connections. Waits for ManualStart or AutomaticStart.
ConnectTCP connection attempt in progress. ConnectRetryTimer running.
ActiveListening for incoming TCP connection (passive mode). ConnectRetryTimer running.
OpenSentTCP connected. OPEN message sent. Waiting for peer’s OPEN.
OpenConfirmOPEN received and validated. KEEPALIVE sent. Waiting for peer’s KEEPALIVE.
EstablishedSession fully operational. UPDATE and KEEPALIVE messages exchanged.

Session attributes

Mandatory

Every FSM instance maintains:

AttributePurpose
StateCurrent FSM state
ConnectRetryCounterNumber of connection attempts
ConnectRetryTimerTime before retrying TCP connection
HoldTimerDeadman timer — peer must send KEEPALIVE/UPDATE before expiry
HoldTimeNegotiated hold interval (initial value from configuration)
KeepaliveTimerInterval for sending KEEPALIVE messages
KeepaliveTimeInitial value (typically HoldTime/3)

Optional

AttributePurpose
DampPeerOscillationsBack off when peer flaps repeatedly
IdleHoldTime / IdleHoldTimerHold in Idle state after flap (exponential backoff)
DelayOpen / DelayOpenTimerDelay sending OPEN to allow peer to go first
PassiveTcpEstablishmentListen only, do not initiate TCP
SendNOTIFICATIONwithoutOPENAllow NOTIFICATION before OPEN exchange
CollisionDetectEstablishedStateProcess collisions in Established state

Events

Events drive state transitions. They fall into five categories.

Administrative events (1-8)

EventNameStatus
1ManualStartMandatory
2ManualStopMandatory
3AutomaticStartOptional
4ManualStart with PassiveTcpEstablishmentOptional
5AutomaticStart with PassiveTcpEstablishmentOptional
6AutomaticStart with DampPeerOscillationsOptional
7AutomaticStart with DampPeerOscillations and PassiveTcpOptional
8AutomaticStopOptional

Timer events (9-13)

EventNameStatus
9ConnectRetryTimer_ExpiresMandatory
10HoldTimer_ExpiresMandatory
11KeepaliveTimer_ExpiresMandatory
12DelayOpenTimer_ExpiresOptional
13IdleHoldTimer_ExpiresOptional

TCP events (14-18)

EventNameStatus
14TcpConnection_ValidOptional
15Tcp_CR_InvalidOptional
16Tcp_CR_AckedMandatory
17TcpConnectionConfirmedMandatory
18TcpConnectionFailsMandatory

BGP message events (19-28)

EventNameStatus
19BGPOpenMandatory
20BGPOpen with DelayOpenTimer runningOptional
21BGPHeaderErrMandatory
22BGPOpenMsgErrMandatory
23OpenCollisionDumpOptional
24NotifMsgVerErrMandatory
25NotifMsgMandatory
26KeepAliveMsgMandatory
27UpdateMsgMandatory
28UpdateMsgErrMandatory

State transitions in detail

Idle state

Connect state

TCP initiation is in progress. Three outcomes:

  1. TCP succeeds (Event 16/17) — clear ConnectRetryTimer, send OPEN, start HoldTimer → OpenSent
  2. TCP fails (Event 18) — restart ConnectRetryTimer, continue listening → Active
  3. ConnectRetryTimer expires (Event 9) — drop TCP, restart timer, initiate new TCP → Connect

Any error or ManualStop → close connection, release resources → Idle

Active state

Passively waiting for inbound TCP. Key transitions:

  1. TCP succeeds (Event 16/17) — clear ConnectRetryTimer, send OPEN → OpenSent
  2. ConnectRetryTimer expires (Event 9) — attempt active TCP connection → Connect
  3. TCP fails (Event 18) — restart timer, increment counter → Idle

OpenSent state

OPEN sent, waiting for peer’s OPEN. The large initial HoldTimer (4 minutes) runs.

  1. Valid OPEN received (Event 19) — negotiate Hold Time, set HoldTimer, send KEEPALIVE → OpenConfirm
  2. Error in OPEN (Event 22) — send NOTIFICATION → Idle
  3. TCP fails (Event 18) — close, restart ConnectRetryTimer → Active
  4. Connection collision (Event 23) — resolve per BGP Identifier comparison

OpenConfirm state

Both OPENs exchanged. Waiting for the confirming KEEPALIVE.

  1. KEEPALIVE received (Event 26) — start negotiated HoldTimer → Established
  2. NOTIFICATION received (Event 24/25) → Idle
  3. HoldTimer expires (Event 10) — send NOTIFICATION (Hold Timer Expired) → Idle

Established state

Session operational. Normal processing:

  • UpdateMsg (Event 27) — process UPDATE, restart HoldTimer
  • KeepaliveTimer expires (Event 11) — send KEEPALIVE
  • KeepAliveMsg (Event 26) — restart HoldTimer
  • HoldTimer expires (Event 10) — send NOTIFICATION → Idle
  • UpdateMsgErr (Event 28) — send NOTIFICATION → Idle
  • ManualStop (Event 2) — send Cease NOTIFICATION → Idle

Connection collision detection

When both peers initiate TCP simultaneously, two connections form. Resolution:

Collision detection happens upon receiving an OPEN when another connection to the same peer is in OpenConfirm state. The loser gets a Cease NOTIFICATION.

Peer oscillation damping

Implementations track the ConnectRetryCounter. After repeated flaps, the IdleHoldTime increases (commonly doubling up to a cap like 120 seconds). This prevents tight reconnection loops from consuming resources across the network.

Sources

Last synthesized: 2026-05-07

AI-assisted synthesis from the RFCs and sources linked above.