Sessions and the BGP state machine
BGP does not discover neighbours. Every peer is configured explicitly, and the two routers talk over a TCP connection to port 179. TCP gives BGP reliable, ordered delivery, so BGP itself never has to retransmit or acknowledge individual messages.
Because of this, the very first thing to check when a session is down is plain IP reachability between the two peer addresses, and whether anything is filtering TCP/179.
Each peer runs a finite state machine (FSM) defined in RFC 4271:
| State | Meaning |
|---|---|
| Idle | Not trying. Waiting for a start event (or penalised after an error). |
| Connect | Trying to complete a TCP connection to the peer. |
| Active | The TCP attempt failed; listening for the peer to connect and retrying when the ConnectRetry timer expires. |
| OpenSent | TCP is up and our OPEN has been sent; waiting for the peer's OPEN. |
| OpenConfirm | Peer's OPEN accepted; waiting for a KEEPALIVE. |
| Established | Up. UPDATE, KEEPALIVE and NOTIFICATION messages flow. |
Step through the diagram below, then drive the state machine yourself.
- Idle → Connect. An operator configures the neighbor (ManualStart). R1 allocates resources, starts the ConnectRetry timer and tries to open a TCP connection to R2.
- TCP SYN. BGP rides on TCP port 179. Whichever side connects first becomes the TCP client; if both connect at once, a collision-detection rule keeps the session from the router with the higher router ID.
- TCP SYN-ACK. R2 accepts the connection. If R2 has no neighbor statement for 192.0.2.1 it resets the connection instead — R1 would fall back to Active.
- TCP ACK → OpenSent. The three-way handshake completes. R1 moves to OpenSent and immediately sends its OPEN message.
- OPEN messages. Each side sends OPEN with its BGP version, ASN, hold time, router ID and capabilities (4-byte ASN, address families, route refresh…). Each checks the peer's ASN matches its remote-as configuration.
- KEEPALIVE → Established. A KEEPALIVE acknowledges the peer's OPEN. Hold time is negotiated to the lower of the two values. After sending and receiving KEEPALIVE, both peers are Established.
- UPDATE: exchange routes. Now the peers send UPDATE messages containing the routes their policy allows. Initially this is the full set; afterwards only changes are sent — BGP is incremental.
- Steady state. With nothing to say, peers send a KEEPALIVE every hold-time/3 (60s by default). Miss the hold time (180s) and the session is torn down and all its routes withdrawn.
Interactive: Drive the BGP finite state machine Fire events to move the peer between states. Try to reach Established, then break the session in different ways. (needs JavaScript)