04 BGP Neighbor States (FSM)
Before two BGP routers can exchange routes, their session passes through a Finite State Machine (FSM) of six states. Understanding this sequence is essential for troubleshooting: the state a session is stuck in tells you where the problem lies.
The six states, in order
Idle
The starting state. On the Start event, BGP initializes its resources, starts the ConnectRetry timer, initiates the TCP connection to the peer, and listens for incoming TCP connections from the peer. A session sitting in Idle usually means BGP cannot even begin (for example, no route to the neighbor, or the neighbor is administratively down).
Connect
BGP waits for the TCP three-way handshake to complete. If TCP succeeds, it sends the Open message and moves on. If the ConnectRetry timer expires before TCP completes, it moves to Active.
Active
BGP is actively trying to complete the TCP connection (it retries after the ConnectRetry timer expired in Connect). If TCP now succeeds, it sends its Open message.
Connect/Active flapping is a TCP problem
A session oscillating between Connect and Active is a classic symptom of a TCP connectivity issue: port 179 blocked, a missing route to the neighbor, or a one-way reachability problem. The name “Active” is misleading — it does not mean the session is healthy; it means the router is still trying to bring up TCP.
OpenSent
The Open message has been sent, and BGP is waiting for the peer’s Open message. When it arrives, the parameters are checked. If they are incompatible (wrong version, unexpected AS, bad authentication, etc.), a Notification is sent and the session drops back to Idle.
OpenConfirm
The peer’s Open has been accepted. BGP now waits for a Keepalive (which confirms the session and moves it to Established) or a Notification (which indicates an error and drops the session back to Idle).
Established
The session is fully up. Update messages can now be exchanged and routes learned. This is the only state in which routing information flows.
Summary of transitions
| State | Waiting for | Success leads to | Failure leads to |
|---|---|---|---|
| Idle | Start event | Connect | stays / retries |
| Connect | TCP handshake | OpenSent (sends Open) | Active |
| Active | TCP handshake | OpenSent (sends Open) | Idle / retry |
| OpenSent | Peer’s Open | OpenConfirm | Idle (Notification) |
| OpenConfirm | Keepalive | Established | Idle (Notification) |
| Established | — | routes exchanged | Idle (on error) |
Troubleshooting value
- Stuck in Idle → BGP cannot start: no route to peer, neighbor not configured, or administratively shut.
- Flapping Connect/Active → TCP layer problem: port 179 filtered, missing/asymmetric route.
- Stuck in OpenSent/OpenConfirm → parameter mismatch: version, AS number, authentication, or hold-time incompatibility.
- Established → healthy; the session is up and routes flow.
Self-check
Q1 — In which state does BGP wait for the TCP three-way handshake to complete after initiating it?
A) Idle
B) Connect
C) OpenSent
D) Established
Respuesta
B is correct. In Connect, BGP waits for TCP to complete; on success it sends the Open, on ConnectRetry expiry it moves to Active.
- A) False — Idle is the starting state, before TCP is under way.
- C) False — OpenSent is after the Open was already sent.
- D) False — Established is the final, fully-up state.
Q2 — A session oscillating between Connect and Active most likely indicates:
A) A healthy, active session exchanging routes
B) A TCP connectivity problem (port 179 blocked or missing route)
C) An AS-PATH loop
D) A best-path tie
Respuesta
B is correct. Connect/Active flapping points to a TCP-layer issue: port 179 filtered, a missing route, or one-way reachability. “Active” means still trying to bring up TCP, not healthy.
- A) False — no routes are exchanged until Established; Active is not healthy.
- C) False — loop prevention is unrelated to TCP session setup.
- D) False — best-path selection happens after the session is up.
Q3 — What does a router wait for in OpenConfirm?
A) The TCP handshake
B) The peer’s Open message
C) A Keepalive (or a Notification)
D) The first Update
Respuesta
C is correct. In OpenConfirm the router waits for a Keepalive to move to Established, or a Notification which drops it back to Idle.
- A) False — TCP is already done by this stage.
- B) False — the peer’s Open was already received and accepted (that was OpenSent).
- D) False — Updates flow only after Established.
Q4 — In which state is routing information actually exchanged?
A) OpenSent
B) OpenConfirm
C) Active
D) Established
Respuesta
D is correct. Established is the only state in which Update messages are exchanged and routes are learned.
- A) False — OpenSent is still negotiating parameters.
- B) False — OpenConfirm is awaiting the confirming Keepalive.
- C) False — Active is still trying to bring up TCP.
Q5 — A session stuck in OpenSent most likely means:
A) No route to the neighbor
B) A parameter mismatch such as version, AS number, or authentication
C) The neighbor is administratively shut
D) The best-path algorithm failed
Respuesta
B is correct. OpenSent waits for and checks the peer’s Open; getting stuck there points to incompatible parameters (version, AS, authentication, hold-time).
- A) False — no route would keep it in Idle or flapping Connect/Active.
- C) False — an admin shut keeps the session in Idle.
- D) False — best-path runs only after the session is Established.