Home » BGP » BGP Protocol Overview

BGP Protocol Overview

BGP is as a Path Vector protocol and it forms unique unicast connections with each of its BGP speaking peers. BGP uses TCP Port 179, this free’s BGP from the overhead of lost packets retransmission, processing acknowledgements and sequencing, as all this is taken care by the transport layer protocol (TCP).

Distance Vector Protocols use the router hop count to determine the shortest path, and in a similar way but instead of router hop count BGP uses the AS-Number hop count to determine the shortest path. BGP uses a list of AS Numbers from which a packet must traverse to reach its destination. All the AS Numbers are recorded in the packets path in an attribute known as Path_Attribute, hence BGP is also called as Path Vector protocol.

The AS-Path attribute lets BGP know the shortest path. Best path is  the path with least number of AS traversed to reach a destination . This feature also lets BGP know if there is a routing loop, if BGP receives a route which has its own AS number listed in its AS-Path then it knows that this is a duplicate packet and drops the packet to avoid any routing loop.

If the neighbor with which the BGP speaker peers with is in a different AS then its called as external BGP or EBGP, and if the neighbor is the same AS then its called as internal BGP or IBGP. There are a set of different rules for how EBGP and IBGP should work. EBGP does not show the topologies within each AS as EBGP only sees a tree view of all autonomous systems for each route prefix. This can be seen with executing the command “sh ip bgp” on a BGP speaking router.

The Admin Distance for both EGBP and IGBP are different as EBGP is considered to be more reliable than IBGP.

Administrative Distance For EGBP and IBGP (Cisco Implementation)

  • EBGP :  20
  • IBGP   :  200

* Admin Distance is the first criteria a router uses to determine which routing protocol to use where two or more routing protocols are providing the route information for same destination. Admin Distance is locally significant and not advertised in the routing updates and routing protocols with smaller admin distance are always preferred. “smaller admin distance = more reliable routing protocol”.

In the diagram below as an example

AS 100 is originating the network prefix and will advertise the prefix to its unique unicast BGP neighbors as (Network Prefix : ORIGIN-CODE : AS-Path) i,100. Lets assume here AS-100 is advertising this prefix only to AS-300 and not to AS-200. The field “i” in the AS Path indicates that the network prefix was originated in an internal AS. AS -100 advertises network only to AS- 300 as ( : 100) then AS-300 advertises the route-prefix to AS-200 as ( : 300,100) and the packet traverses to AS-200 at this point AS-200 advertises the path to AS-100 as ( : 200,300,100). Here AS-100 will see its own AS in the AS Path listed and will drop the packet.


Using the AS_PATH attribute BGP is also able to make the decision on the shortest route. The Shortest route is the one for each route which has the lowest number of AS Numbers listed in the AS_Path. For example in the above example diagram assume that AS 400 receives the route from both AS 300 and AS 600. The route receiving from AS 300 will look like [ : 300,100] and the same route receiving from AS 600 will look like [ : 600,300,100]. As the route entry receiving from AS 300 is shorter, it will be selected by the BGP speaker in AS 400 by default.


If there is more than one equal-cost path to a particular destination then Cisco’s implementation of EBGP defaults to select only one path. This can however be changed by the maximum-path command and can be in the range of 1-6. The load Balancing will only work with EBGP and IBGP can use only one link.

Python Tutorial: Python Network Programming – Build 7 Apps

Establishing connection to Peers.

When a BGP Speaker establishes connection with any BGP speaking router, both the routers exchange their full BGP routing tables. Only incremental updates are done after full routing table exchange has completed. Incremental updates happen only  when some information has changed and only the changed information is exchanged.

BGP does not use periodic updates as other routing protocols do, therefore the mechanism to  maintain and detect a connection to BGP peer  is done through the exchange of keepalive messages.

BGP  Message Types:

BGP uses 4 message types for communication.

  1. Open
  2. Keepalive
  3. Update
  4. Notification

Open Message:

Each BGP Speaker uses open message to identify itself to its peer and to also specify its BGP Operational parameters. The BGP operational parameters must match between both the BGP speakers and both of them have to agree on them in order to make successful peering. BGP open message is sent after a TCP session is established between the BGP speakers who are trying to establish the peering.

The open message contains the following information

1. BGP version number

2. AS Number

3. Hold Time

4. BGP Identifier

BGP version number must match between both the BGP speakers, the version number can be 2,3 or 4. By default it will be BGP-4 unless the BGP speaker is set to run an earlier version. If the BGP version number does not match then the connection is closed and a new connection is attempted upon the lower BGP version number. The router running the higher BGP version number attempts to establish a connection by lowering it BGP version number to its peer’s BGP version number. This negotiation continues until both BGP speakers agree on the same value (lower value if any one speaker is not running version 4)

AS number determines if the BGP session will be IBGP or if it will be an EBGP session. Each router announces its own AS number in the open message.

Autonomous System Definition: Within the Internet, an autonomous system (AS) is a collection of connected IP routing prefixes under the control of one or more network operators that presents a common, clearly defined routing policy to the Internet

The range for AS Numbers is 0 – 65535, where 0, 56320–64511 and 65535 are reserved by IANA and cannot be used in any routing environment.  ASN 0 may be used to label non-routed networks. AS Numbers can be public or private. Public AS numbers are assigned by IANA, Private AS Numbers can range between 64512 through 65534.

Hold Time is the maximum number of seconds that can elapse before receiving a keepalive  or an update message. Hold time values must match between both the BGP speakers, if the hold time values differ then the lower value is selected as hold time for the connection. If the hold time is set to  Zero then no keepalives are sent.  If keeplaives are needed then the lowest hold time value which can be set is 3 seconds for Cisco implementation of BGP.

BGP identifier is the IP address that identifies a BGP speaker. If BGP Identifier is not manually set then Cisco defaults to use the BGP identifier as numerically highest loopback address and if no loopback address is configured on the router then numerically highest IP address on a physical interface is used.

Open message also carries some optional parameters like multiprotocol support, authentication, etc.

Keepalive Message:

If the parameters in the open message are accepted then the router responds with a keepalive message.

Keepalive messages ensure that the connections to BGP peers are alive. Cisco default keepalive interval is 60 seconds and the hold time interval is 180 seconds (3 x keepalive). Keepalives are sent every 60 seconds and after not receiving any keepalive message from BGP peer for 180 seconds, the connection to that peer is declared as dead and the bgp neighbor is reported as down.

Update Message:

Update Messages are used to update the BGP neighbor about the network layer reachability information (NLRI) and the path attributes associated with that NLRI.
NLRI is simply the combination of IP address Prefix and length (subnet mask) in the format x.x.x.x /mask for IPv4 addresses. Path Attributes are used in the selection of shortest path or to detect any routing loops. Update messages advertise both feasible routes and also the withdrawn routes. Withdrawn routes let the BGP neighbor know of any destinations which have become unreachable.

Notification Message:

Notification messages are sent whenever an error is detected and will always cause the BGP connection to close.

Notification Message has 3 Fields

1 – Error Code (1-byte)
2 – Error Subcode (1-byte)
3 – Data (Variable)

Upon looking at the notification message you can find out what is the probable cause of the notification message which caused the neighbor’s BGP Session to close. Below are the Error-Codes and their corresponding Sub-codes which can help determine what type of event triggered the BGP to close the session.

Error Code Error Subcode
1 – Message Header Error 1 – Connection Not Synchronized
2 – Bad Message Length
3 – Bad Message Type
2 – OPEN Message Error 1 – Unsupported Version Number
2 – Bad Peer AS
3 – Bad BGP Identifier
4 – Unsupported Optional Parameters
5 – Authentication Failure
6 – Unacceptable Hold Timer
7 – Unsupported Capability
3 – UPDATE Message Error 1 – Malformed Attribute List
2 – Unrecognized Well Know Attribute
3 – Missing Well-known Attribute
4 – Attribute Flags Error
5 – Attribute Length Error
6 – Invalid Origin Attribute
7 – AS Routing Loop
8 – Invalid NEXT_HOP Attribute
9 – Optional Attribute Error
10 – Invalid Network Field
11 Malformed AS_PATH
4 – Hold Timer Expired
5 – Finite State machine Error
6 – Cease (fatal error)

BGP Finite State Machine: (BGP States and Timers)

You can find a BGP session to a neighbor in any one of the following six states.
1. Idle State
2. Connect State
3. Active State
4. OpenSent State
5. OpenConfirm State
6. Established State

Finally to summarize the Six BGP States, check the diagram below.














Active State:

This state indicates BGP is trying to initiate a TCP connection with the BGP neighbor. There can be three states of transition from Active state.

If the TCP connection to neighbor is successful then Open message is sent to BGP neighbor and the state is transitioned to OpenSent also the ConnectRetry timer is cleared. The hold time is set to 4 minutes in this case.

If the ConnectRetry timer expires while waiting in this state the process transitions back to Connect State and resets the ConnectRetry timer. Initiates a TCP connection to the neighbor and waits for the neighbor’s connection. If the neighbor attempts to establish a tcp session with unexpected IP address, then the connectRetry timer is reset, connection is refused and the BGP process stays in the Active State.

Any other input event except a BGP Start event while waiting for the neighbors TCP connection transitions BGP back to Idle state. Note that a BGP Start event is ignored in the Active State.

OpenSent State:

Indicates an Open message has been sent to the BGP neighbor and BGP is waiting to hear an Open Message from that neighbor.  There are three possibilities from this state, BGP can either progress to OpenConfirm State or to Active State or back to Idle state.

It progresses to OpenConfirm State if the open message is received from the neighbor and the open message has no errors. Also a the hold time is negotiated and the keepalive timers are set. A keepalive message is also sent once it transitions to OpenConfirm state.

It transitions back to Idle state if the open message received has errors, a notification message is sent indicating error and BGP transitions back to Idle State.

It transitions to Active state if a TCP disconnect is received before the open message, upon receiving the TCP disconnect, the BGP connection is closed and the ConnectRetry timer is reset.

Idle State:
Idle state occurs  in one of the two scenarios
1. when the BGP first starts or
2. when an error has caused BGP to transition to this state from any other state.

BGP always starts in Idle state and a BGP Start event triggers the BGP process to initialize.  The BGP Start event occurs when an operator configures a new BGP process or an existing BGP is reset by the router or by an operator. After the start event BGP process initializes all BGP resources, starts a ConnectRetry timer and initializes a TCP connection to the neighbor, then changes its state from Idle to Connect and waits in Connect state listening for the TCP connection from neighbor.

If an error caused the BGP process to transition to Idle state, then the router automatically tries to issue another start event but to avoid constant flapping by trying to restart the BGP process constantly in error conditions, some limitations are imposed using the ConnectRetry timer. The router sets the ConnectRetry timer and will not attempt to restart BGP until this timer expires. This takes care of a router constantly trying to initialize BGP when there are persistent error conditions and forces the router to wait until the timer expires. On Cisco the initial ConnectRetry timer is 60 seconds and for each subsequent attempt it becomes twice of the previous ConnectRetry time, exponentially increasing the consecutive wait times.

Connect State:

This is the state where the BGP process is waiting for the completion of the TCP connection with the neighbor. There are three possible outcomes from this state.
1. progress to OpenSent state if all is well
2. progress to Active State indicating a problem
3. transition to Idle state again

On successful TCP connection, BGP process clears the ConnectRetry timer and sends an Open message to the BGP neighbor. The state is progressed to OpenSent.

On an unsuccessful TCP connection, the BGP process resets the ConnectRetry timer and transitions to Active State.

If the ConnectRetry expires in Connect State while still waiting for any TCP connection outcome, then the ConnectRetry timer is reset and another attempt is made to establish the TCP connection with the neighbor, and the process stays in Connect State until the timer expires. Any other event in this state causes the transition back to Idle State.

OpenConfirm State:

In this state the BGP process is just waiting for a Keepalive or a Notification message. There are two possible transitions from this state.

If a Keepalive message is received then BGP state transitions to Established state.
If a Notification message is received then BGP state transitions to Idle state.
Also if the hold timer expires or a stop event occurs then BGP transitions to Idle state and a notification message is sent to the neighbor

Established State:

This state indicates that the BGP Session to the Peer is fully established and both the BGP peers can exchange Keepalives, Update and Notification messages.
The hold timer is restarted every time when a Keepalive or an Update message is received.
If a Notification message is received then the state transitions to Idle and any other event except the BGP start event, which is ignored causes BGP to send a Notification to neighbor and transition to Idle state. Note that a BGP Start event is also ignored in the Established State.


Incoming search terms for the article:

Leave a Reply