skip to content

Peering Session States

3 roadmaps6 questions

A BGP session walks Idle, Connect, Active, OpenSent and OpenConfirm to Established over TCP 179, kept up by KEEPALIVEs and a hold timer. Stuck in Active is the classic troubleshooting question.

on this pageshow

explore

questions

6

Why does BGP run its sessions over TCP port 179, and what are the four message types a BGP-4 session exchanges?

level: juniorimportance: must knowfreq 46%

answer

  1. reliability borrowed, not rebuilt
  2. one TCP connection per peering
  3. open, advertise, complain, stay alive
  4. type codes 1 to 4, header 19 octets

basics

~20 s

BGP runs over TCP port 179 so TCP supplies retransmission, ordering and sequencing for it. A BGP-4 session uses four messages: OPEN starts it, UPDATE advertises and withdraws routes, NOTIFICATION reports an error and closes it, KEEPALIVE shows the peer is alive.

solid answer

~50 s

RFC 4271 puts BGP on TCP so that BGP needs no fragmentation, retransmission, acknowledgement or sequencing of its own. A speaker listens on TCP port 179 and also connects out to its configured peers. Because delivery is reliable, BGP sends the routes its export policy allows once, then only incremental changes, with no periodic refresh. The four message types are `OPEN` (type 1: version 4, the sender's AS, a proposed hold time, the BGP Identifier and optional parameters such as capabilities), `UPDATE` (type 2: withdrawn prefixes, path attributes and the prefixes they describe), `NOTIFICATION` (type 3: an error code and subcode, after which the connection is closed) and `KEEPALIVE` (type 4: a bare 19-octet header that keeps the peer's hold timer from expiring). RFC 2918 later added `ROUTE-REFRESH` as type 5, usable only when both peers advertise that capability.

go deeper

for a junior

Recall TCP port 179 and the four message names with what each does. Saying that withdrawals ride inside UPDATE, not in a message of their own, already sets you apart.

for a middle

Explain why TCP lets BGP send incremental updates with no periodic refresh, and why BGP still needs KEEPALIVE when TCP is reliable. Mention that a NOTIFICATION always closes the connection.

for a senior

Connect the transport to operations: both speakers dial each other, the collision rule keeps the higher Identifier's connection, and route refresh lets you re-apply inbound policy without a reset.

for a principal

Frame the trade: leaning on TCP made BGP simple and incremental, but it also made error handling all-or-nothing per session, which RFC 7606 later softened for most UPDATE errors.

## Why BGP sits on TCP **BGP-4**, specified in **RFC 4271**, is the routing protocol that autonomous systems use to tell each other which IP prefixes they can reach. Unlike most interior routing protocols, it does not build its own reliable transport. It runs over **TCP**, and RFC 4271 gives the reason directly: using TCP removes the need for BGP to implement fragmentation, retransmission, acknowledgement and sequencing of its updates. That one design choice shapes the rest of the protocol: - **Incremental updates.** Because TCP delivers every byte in order or fails the connection, a speaker sends the routes its export policy allows once, when the session comes up, and afterwards only what changes. BGP has no periodic refresh, unlike RIP, which re-advertises its table every 30 seconds. - **Errors ride the graceful close.** BGP's error mechanism assumes TCP delivers outstanding data before the connection closes, so a NOTIFICATION written just before the close still reaches the peer. - **One connection per peering.** RFC 4271 keeps one state machine per configured peer, and each state machine corresponds to exactly one TCP connection. ## Port 179 and who connects A BGP implementation **must listen on TCP port 179** and, unless it is configured to stay passive, also tries to connect to each configured peer. So by default both speakers dial each other. Once a connection completes, it does not matter who initiated it; RFC 4271 notes that the only difference is which end has port 179. The listening end uses 179 as its local port, while the connecting end uses an ephemeral source port and sends to destination port 179. When both speakers connect at the same moment, two TCP connections exist for one peering. RFC 4271 calls this a **connection collision** and resolves it after the OPEN messages arrive: the speakers compare **BGP Identifiers** as unsigned 32-bit integers and keep only the connection initiated by the speaker with the higher one. The losing connection is closed with a NOTIFICATION carrying the Cease error code. How TCP itself opens the connection is the TCP handshake's subject, not BGP's. ## The common message header Every BGP message starts with the same **19-octet header**: 1. **Marker**, 16 octets, set to all ones and kept for compatibility. 2. **Length**, 2 octets, the whole message including the header, at least 19 and at most 4096. 3. **Type**, 1 octet, the message type code. The Length field is what lets a receiver find the start of the next message inside the TCP byte stream. ## The four message types | Type code | Message | When it is sent | What it carries | |---|---|---|---| | 1 | `OPEN` | first message each side sends after TCP connects | version 4, My Autonomous System, Hold Time, BGP Identifier, optional parameters | | 2 | `UPDATE` | only once the session is Established | withdrawn routes, path attributes, and the prefixes (NLRI) those attributes describe | | 3 | `NOTIFICATION` | when an error is detected, or a speaker chooses to close the session | error code, error subcode, diagnostic data | | 4 | `KEEPALIVE` | to confirm a received OPEN, then periodically | nothing beyond the 19-octet header | A few details that interviewers probe: - **There is no separate withdraw message.** An UPDATE can withdraw prefixes, advertise prefixes, or do both at once. - **NOTIFICATION is terminal.** RFC 4271 says the BGP connection is closed immediately after it is sent. Its error codes are Message Header Error (1), OPEN Message Error (2), UPDATE Message Error (3), Hold Timer Expired (4), Finite State Machine Error (5) and Cease (6). Cease is the code for a deliberate close with no fatal error, for example closing a session because the peer sent more prefixes than a configured limit. - **KEEPALIVE is BGP's own liveness check.** RFC 4271 states that BGP does not use a TCP keep-alive mechanism to decide whether a peer is reachable. KEEPALIVEs are sent often enough that the peer's hold timer does not expire; about a third of the hold time is the RFC's suggestion, and never more than one per second. ## What came later Two extensions sit on top of these four messages: - **Capabilities** (RFC 5492) travel inside the OPEN message as an optional parameter. A speaker lists what it supports, and a capability is used only when both peers advertise it. - **ROUTE-REFRESH** (RFC 2918) is a fifth message type, code 5. It asks a peer to resend its routes so that a changed inbound policy can be applied without tearing the session down. A speaker may send it only to a peer that advertised the route-refresh capability. ## Common mistakes - Saying BGP uses UDP and retransmits lost updates itself: it relies entirely on TCP. - Saying BGP floods its whole table periodically: that is RIP's behaviour, not BGP's. - Inventing a WITHDRAW message: withdrawals travel in UPDATE. - Treating NOTIFICATION as a warning: the session ends when it is sent.

  • Since BGP already runs over TCP, why does it need its own KEEPALIVE message?
    RFC 4271 says BGP does not use TCP keep-alive to decide whether a peer is reachable. A quiet TCP connection with nothing in flight can take a long time to notice a dead peer, and TCP cannot tell whether the BGP process on the far end is still working. KEEPALIVE and UPDATE messages restart the peer's hold timer; if neither arrives within the negotiated hold time, the speaker sends a Hold Timer Expired NOTIFICATION and closes the session.
  • If two BGP speakers connect to each other's port 179 at the same moment, which connection survives?
    That is a connection collision. When an OPEN arrives, the speaker checks its connections in OpenConfirm (and optionally OpenSent) for one to the same BGP Identifier. It compares the two BGP Identifiers as unsigned 32-bit integers and keeps only the connection initiated by the speaker with the higher Identifier, closing the other with a Cease NOTIFICATION.

saying these in an interview costs you the question

  • BGP runs over UDP and retransmits lost updates by itself.
  • BGP re-sends its whole routing table to every peer every 30 seconds.
  • Withdrawn prefixes travel in a separate WITHDRAW message type.
  • A NOTIFICATION is just a warning; the session stays up after it.
  • Both ends of a BGP session use port 179 as source and destination port.
open as a page

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%

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.

open as a page

Why does a new BGP session sit in the Active state and never reach Established, and what does Active actually mean?

level: middleimportance: must knowfreq 38%

basics

~20 s

In BGP, Active means the speaker has no TCP connection to its peer yet: it listens, and redials when ConnectRetryTimer expires. Stuck there means TCP never completes: no route, wrong peer or source address, port 179 filtered, or mismatched authentication.

open as a page

How do two BGP peers settle on a hold time, how often should KEEPALIVEs flow, and what happens when the hold timer expires?

level: middleimportance: should knowfreq 30%

basics

~20 s

Each BGP peer proposes a hold time in its OPEN and both use the smaller, which must be zero or at least 3 seconds. KEEPALIVEs flow about every third of it; if nothing arrives in time, the session closes with Hold Timer Expired.

open as a page

A BGP session reaches OpenSent, then drops to Idle with a NOTIFICATION on every retry; what in the OPEN exchange, including capability negotiation, causes that?

level: seniorimportance: should knowfreq 20%

basics

~20 s

The peer's OPEN failed a check: wrong AS, an unacceptable hold time, a bad BGP Identifier, an unsupported version or optional parameter, or a required capability missing. The receiver sends an OPEN Message Error NOTIFICATION whose subcode names the problem, then returns to Idle.

open as a page

Why did RFC 7606 replace the BGP session reset for many malformed UPDATE messages with treat-as-withdraw, and what does that trade away?

level: seniorimportance: nice to knowfreq 12%

basics

~20 s

Under RFC 4271, any malformed BGP UPDATE reset the whole session, dropping every route on it, often far from the router at fault. For most attribute errors RFC 7606 withdraws only that UPDATE's routes, risking unreachability and inconsistent routing inside an AS.

open as a page