BGP Message Types & FSM

In this tutorial we will discuss about different message types of BGP, BGP Peer Connection, BGP Finite State Machine. Before establishing BGP Peer Connection, two neighbor must perform TCP Three-Way-Handshake and open a connection to Port number 179. BGP is a Transport Layer Protocol, hence TCP provides fragmentation, acknowledgement, sequencing functions necessary for reliable connection. BGP Peer must be statically configured and a route must present in the routing table. All the BGP Messages are unicast over TCP Connection. BGP Uses five basic message.

BGP Messages

  • Open
  • Keepalive
  • Update
  • Notification
  • Route Refresh

All BGP Messages have a common header and encapsulated into a TCP Fragment. Header consists of Marker, Length and Type of the BGP Messages. A Keepalive message is nothing but a BGP Header. Open Message consists of version number of bgp, autonomous system number of the originating router, hold time, bgp identifier and optional parameters for capabilities negotiation. A Update Message consists of withdrawn routes, path attributes and NLRI. Notification message consists of error code and subcodes. The parameters inside a BGP Message are represented in a TLV format. TLV is a triplet of Type, Length and Value.

Encapsulation of BGP Messages

All BGP Messages are encapsulated in TCP using Port Number 179. BGP TCP Client uses a registered higher range port( 1024 to 49151 ) as Source Port and Port number 179 as destination port. BGP TCP Server use the port in the reverse way. IP Layer further encapsulate the TCP message using source IP as defined by update-source in the BGP configuration or the IP of the exit interface of the route pointing toward peer IP. It uses the peer IP configured as destination ip of the IP Packet. Refer the below diagram for further details.

BGP Neighborship and validation of Parameters

For very basic understanding we will discuss neighborship between two routers R1 and R2 residing in AS 1 & 2 accordingly. Before any BGP message would be sent, a TCP connection must open between R1 & R2. Once TCP connection is established, any of the routers can send the BGP open message to other neighbor.

In the above example, R1 sends a OPEN message to R2 once the TCP session is established. R2 then verify the parameters like AS numbers, RID, source IP ect comparing with the values configured in it. If it found the OPEN is valid, then it send a reply OPEN message to R1. R1 will also check the parameters. Once validation completed, R1 will reply with a KEEPALIVE. R1 now consider it in neighborship established with R2. Once R2 will receive the KEEPALIVE, it will change it state to established.
Some parameters must be checked to validate the TCP and BGP messages. These are D-IP, S-IP, TCP Ports, REMOTE AS, MY AS, RID.
The Destination IP(D-IP) would be the IP configured as a neighbor and it must match the source IP(update-source) of the peer router. The Source IP(S-IP) would be either the interface IP configured as an update source or the IP of the exit interface pointing toward the route of the neighbor and it must match with the IP configured as neighbor in the peer router. The Source & Destination Port must open for successful TCP connection. Remote AS must match with the AS number of the peer that is the BGP instance number configured in the peer router. My AS(than is configured as BGP instance number) must match with the AS number configured as remote-as of the peer router. BGP Router ID(RID) must be a unique value.

BGP Finite State Machine

All the above signalling and states are controlled by BGP Finite State Machine(FSM). In BGP FSM, some Input Events(IE) and valid states are defined. The transition between finite states are governed by input events. There are 13 input events and 5 finite states are defined in bgp. In the following section, we will discuss that. The input events are locally triggered and it is based upon many inputs like manual configuration change, command input, arrival of different bgp messages, etc.

Input Events(IE)Description
1BGP Start
2BGP Stop
3BGP Transport connection open
4BGP Transport connection closed
5BGP Transport connection open failed
6BGP Transport fatal error
7ConnectRetry timer expired
8Hold timer expired
9Keepalive timer expired
10Receive Open message
11Receive Keepalive message
12Receive Update message
13Receive Notification message

BGP forms a TCP session with neighbor routers called peers. BGP uses the Finite State Machine (FSM) to maintain a table of all BGP peers and their operational status. The BGP session may report in the following states:

  • Idle
  • Connect
  • Active
  • OpenSent
  • OpenConfirm
  • Established

From the OSI Model’s perspective, BGP is simply a networking application running on top of the the Session layer and everything below it. Thus, an ESTABLISHED BGP SESSION is required for BGP to begin exchanging routes.

FSM Transition between States


BGP always begins with an IDLE state. In IDLE state it refuses all incoming connections. Once a BGP START event occurs in IDLE state, BGP tries to initialize all BGP resources, initialize a TCP connection to Peer using Port 179, listen on port number 179 and starts a CONNECT_RETRY timer. After initiating all the mentioned process BGP changes it’s state to CONNECT. The BGP START event usually takes place while a new BGP configuration is done or BGP RESET is triggered.
An error causes the BGP Process to transition back to IDLE state, while in IDLE state it tries to initiate the TCP initialization process once again. But BGP does it in a throttled rate. After first failed attempt, BGP assign a CONNECT_RETRY timer(by default 120 sec.). BGP starts the initialization only after the connect retry timer expires. For any consecutive failed attempts, the value of the CONNECT_RETRY timer doubled, means its twice the value of the previous CONNECT_RETRY.


In connect BGP waits for the TCP Connection to be completed. If TCP connection is successful, it send a OPEN_SENT to it’s neighbor and goes to the OPEN_SENT state. If TCP Connection is unsuccessful(IE 5 – BGP Transport Connection Open Failed) then it reset the CONNECT_RETRY and goes to ACTIVE. If the CONNECT_RETRY expires while in CONNECT state, BGP remains in CONNECT state and another attempt is made to initiate TCP Connection. Any other input events(IE*) causes the BGP to go back to the IDLE state.
IE* – The events are BGP STOP(2), TCP Transport Connection CLosed(4), BGP Transport Fatal Error(6), Hold Time Expired(8), KEEPALIVE Expired(9)


In ACTIVE state, BGP Process tries to initiate a TCP Connection with the neighbor. If TCP Connection is successful, BGP sends a OPEN Message to neighbor and goes to OPEN_SENT. Else if Transport Connection Open Failed(IE5) occur or Neighbor try to initiate a TCP connection using an invalid IP then the BGP stays in ACTIVE state. Else if the CONNECT_RETRY time expires while in ACTIVE sate, the BGP process goes back to CONNECT state. Any other input error events(IE*) causes the BGP to goes back to IDLE state.
IE* – BGP STOP(2), BGP Transport Connection Closed(4), BGP Transport Fatal Error(6), Hold Timer Expired(8), NOTIFICATION Received(13)


In OPEN_SENT, a OPEN Message has been sent already and BGP is waiting for a valid OPEN Message from it’s neighbor. If a OPEN Message is received and the parameters validation are successful then it send a KEEPALIVE to it’s neighbor, reset the KEEPALIVE timer, negotiate the HOLD DOWN timer, set a HOLD DOWN timer and go to OPEN Confirm state. Else if a invalid OPEN Message reved, BGP sends a NOTIFICATION to the neighbor and go back to the IDLE state. Else if a TCP Connection Close(IE4) occur or TCP Disconnect Request Received or local process stop TCP connection, BGP resets the CONNECT_RETRY timer and go the the ACTIVE state. Else if any other input events(IE*) then BGP goes back to IDLE.
IE* – BGP Stop(2), BGP Transport Connection Open(3), BGP Transport Connection Open Failed(5), Notification Received(13)


In OPEN CONFIRM state, BGP waits for a Keepalive or Notification message. If a KEEPALIVE is received, BGP goes to ESTABLISHED state. Else if a NOTIFICATION received or TCP Disconnection received, BGP goes back to IDLE. Else if HOLD Timer expired or BGP STOP(IE2) event occurs or error detected then BGP sends a NOTIFICATION, close the TCP Connection and goes back to IDLE state.


In this state, BGP Peer connection is fully established and peers can exchange BGP updates now. if a NOTIFICATION received then BGP goes back to IDLE state. Else if TCP Disconnection received or HOLD/KEEPALIVE time expired or any other input error events, BGP sneds a NOTIFICATION and goes back to IDLE state.

  Previous Next  

Leave a Reply