skip to content

Which states does the BGP finite state machine pass through from Idle to Established, and what moves a session from each to the next?

level: middleimportance: must knowfreq 40%

answer

  1. one state machine per configured peer
  2. TCP first, then OPEN
  3. OPEN answered by KEEPALIVE
  4. errors fall back to Idle

basics

~20 s

A BGP session goes Idle, Connect (TCP attempt), OpenSent (TCP up, OPEN sent), OpenConfirm (peer's OPEN accepted, KEEPALIVE sent) and Established (peer's KEEPALIVE received). Active means it is waiting for a TCP connection; most errors return it to Idle.

solid answer

~40 s

RFC 4271 keeps one finite state machine per configured peer. In `Idle` the speaker refuses connections; a start event makes it open a TCP connection to port 179, start the `ConnectRetryTimer` and move to `Connect`. In `Active` it listens for and accepts a TCP connection, and when `ConnectRetryTimer` expires it goes back to `Connect` to dial again. As soon as TCP completes, it sends `OPEN`, sets its hold timer to a large value and enters `OpenSent`. A valid `OPEN` from the peer is answered with `KEEPALIVE`, the negotiated hold time is set, and the state becomes `OpenConfirm`. The peer's `KEEPALIVE` moves it to `Established`, the only state where `UPDATE`s flow. An error (a bad OPEN, an expired hold timer, a NOTIFICATION from the peer) sends it back to `Idle`.

go deeper

for a junior

Recall the six state names in order and that Established is the only state where routes flow. Knowing that a NOTIFICATION sends the session back to Idle is a strong start.

for a middle

Explain the trigger for each transition: TCP completing, OPEN sent, a valid OPEN answered with KEEPALIVE, the peer's KEEPALIVE received. Say why OpenSent uses a large hold timer.

for a senior

Read a session's state as a diagnosis: Connect or Active means TCP never completed, cycling through OpenSent to Idle means the OPEN is being rejected, and drops from Established point at hold timers or UPDATE errors.

for a principal

Discuss how strict all-or-nothing error handling in the FSM trades stability for simplicity, and why damping peer oscillation is left to implementations rather than specified.

## One state machine per peer **RFC 4271** describes a BGP session as a **finite state machine (FSM)**. A speaker keeps a separate FSM for every configured peer, plus a temporary one for each incoming TCP connection whose peer it has not yet identified. The FSM has six states: **Idle, Connect, Active, OpenSent, OpenConfirm and Established**. Two timers drive it during setup: the **ConnectRetryTimer**, which paces new TCP attempts (RFC 4271 suggests 120 seconds), and the **HoldTimer**, which limits how long the speaker waits for the peer's next message. ## The walk to Established | State | What the speaker is doing | What moves it forward | |---|---|---| | `Idle` | refuses all incoming connections for this peer; nothing is allocated | a start event: it opens TCP to port 179, listens, starts ConnectRetryTimer, goes to `Connect` (a passive start goes to `Active` instead) | | `Connect` | waiting for its outbound TCP connection to complete | TCP completes: it sends OPEN, sets the HoldTimer to a large value and goes to `OpenSent` | | `Active` | listening for, and accepting, a TCP connection from the peer | TCP completes: OPEN and `OpenSent` as above; ConnectRetryTimer expires: it dials again and goes to `Connect` | | `OpenSent` | has sent its OPEN, waiting for the peer's | a valid OPEN arrives: it sends KEEPALIVE, sets the negotiated hold time, goes to `OpenConfirm` | | `OpenConfirm` | waiting for the KEEPALIVE that confirms its own OPEN | KEEPALIVE arrives: it restarts the HoldTimer and goes to `Established` | | `Established` | exchanging UPDATE, KEEPALIVE and NOTIFICATION messages | stays here; each KEEPALIVE or UPDATE restarts the HoldTimer | Read as a sequence, a clean session start looks like this: 1. Both speakers start in Idle; an operator or automatic start event begins the session. 2. TCP to port 179 completes, from whichever side connected first. 3. Each side sends OPEN and sits in OpenSent. 4. Each side checks the other's OPEN, replies with KEEPALIVE and sits in OpenConfirm. 5. Each side receives the other's KEEPALIVE and reaches Established; the initial UPDATEs follow. The **large hold timer value** in OpenSent exists because the real hold time cannot be known until the peer's OPEN arrives; RFC 4271 suggests 4 minutes. Once the OPEN is accepted, the speaker uses the smaller of its own and the peer's proposed hold time. ## Where failures go The FSM is strict about errors, and almost every one of them ends in **Idle**: - **A bad OPEN** (wrong version, an unacceptable AS number, an unacceptable hold time, a malformed BGP Identifier) makes the receiver send a NOTIFICATION with the OPEN Message Error code and drop to Idle. - **The HoldTimer expiring** in OpenSent, OpenConfirm or Established makes the speaker send a Hold Timer Expired NOTIFICATION and drop to Idle. - **A NOTIFICATION received** in OpenConfirm or Established, or the TCP connection failing there, sends the FSM to Idle; in Established the routes learned from that peer are deleted. - **An unexpected message**, such as an UPDATE arriving in OpenConfirm, is a Finite State Machine Error: NOTIFICATION, then Idle. - **The TCP connection failing in OpenSent** is the one setup failure that goes to Active rather than Idle: the speaker keeps listening and restarts ConnectRetryTimer. Each fall to Idle increments the **ConnectRetryCounter**. RFC 4271 also defines optional **peer oscillation damping** (the DampPeerOscillations attribute with an IdleHoldTimer) so that a session that keeps failing is restarted more slowly; the method itself is left to implementations. ## The Connect and Active pair Connect and Active are the two "no session yet" states, and they are where a session that never comes up spends its time. Connect means an outbound attempt is in flight; Active means the speaker is listening and waiting. In RFC 1771, the older specification, a failed outbound attempt moved Connect to Active. RFC 4271 sends a failed attempt to Idle unless its optional DelayOpen timer is running, so the exact path differs between implementations. The meaning does not: a session shown in Connect or Active has no working TCP connection to its peer yet. ## Names that collide Three protocols in this family use the word "active" for different things. The BGP **Active** state means a speaker has no TCP connection and is waiting for one. An EIGRP route in the active state is one whose router is querying neighbours for a new path. A VRRP router in the Active state (RFC 9568's name for what RFC 5798 called Master) is the one forwarding for a virtual address. Name the protocol before using the word.

  • Why does a BGP speaker in OpenSent set its hold timer to a large value instead of the configured hold time?
    The session's hold time is the smaller of both sides' proposals, and the speaker does not know the peer's proposal until the peer's OPEN arrives. Until then it waits with a large value, which RFC 4271 suggests should be 4 minutes. When the OPEN is accepted, it switches to the negotiated value and starts sending KEEPALIVEs.
  • Where does a BGP session go after an error, and why can a persistent error make it flap?
    Almost every error sends a NOTIFICATION and returns the FSM to Idle, incrementing the ConnectRetryCounter. From Idle a start event begins the walk again, so a fault that recurs on every attempt makes the session cycle up and down. RFC 4271 offers optional peer oscillation damping, an IdleHoldTimer that delays the restart, but leaves the method to implementations.

saying these in an interview costs you the question

  • A BGP session reaches Established as soon as the TCP handshake completes.
  • A BGP session in Active is up and actively exchanging routes.
  • OpenConfirm is the state in which the speaker waits for the peer's OPEN.
  • A speaker may send UPDATE messages while it is still in OpenConfirm.
  • After an error, BGP drops back to Connect and retries immediately.