I think you will agree with me that BGP is one of the least understood routing protocols. Many network engineers see it as one big clumsy technology that should not be muddled with. The muddling part is true to some extent because, unless you are in a service provider environment or a large network that peers with its ISP via BGP, then you will probably not configure BGP. In any case, this series aims to explain the concepts relating to BGP. I hope you enjoy and learn.

Overview of BGP

BGP was designed as a routing protocol between autonomous systems (AS) rather than within an AS, although BGP can also be used within an AS. It uses TCP as its transport protocol and operates over TCP port 179. There are basically two forms of BGP: internal BGP and external BGP. Internal BGP (IBGP) is a BGP connection between BGP speakers in the same AS while external BGP (EBGP) is a BGP connection between BGP speakers in different AS’s.

CCNA Training – Resources (Intense)

BGP speakers exchange routes between themselves in the form of IP prefixes (network layer reachability information – NLRI) plus the path attributes associated with that prefix (e.g., the list of AS numbers which the IP prefix has traversed to reach the BGP speaker). By supporting CIDR (classless interdomain routing), BGP is not restricted by the classful network routing.

Hint: In CIDR, an IP network is represented in the form of IP prefix/prefix length e.g.

BGP Message Types

BGP makes use of four different message types to perform its function namely: OPEN, UPDATE, KEEPALIVE, and NOTIFICATION. Before we consider these message types, we must look at the BGP message header that is present before all these message types and that indicates the type of message contained in the BGP packet.

Note: A 5th message type was defined called ROUTE-REFRESH to support the route refresh capability. You can read more about this message type in RFC 2918.

The BGP message header contains three fields as shown below, taken from RFC 4271:

The Marker field is used for synchronization and authentication purposes. It is usually set to all 1s; the Length field specifies the total length of the BGP message (including the BGP message header); and the Type field indicates the BGP message type.

OPEN message

After the TCP session is formed between BGP speakers, the OPEN message is sent to establish the BGP session. The OPEN message contains information such as the AS of the BGP speaker, the version of BGP it is using and other optional parameters that it supports. The format of this message is as shown below:

The current BGP version is version 4. By comparing the AS number in OPEN messages, BGP speakers can determine if they should form IBGP or EBGP sessions. The hold time specifies how long the BGP speaker proposes to wait before it considers its neighbor down. A BGP neighbor will be considered down if an UPDATE or KEEPALIVE message is not received from that neighbor before the hold time expires. The lower hold time value is used between BGP neighbors if the values are not the same. The BGP identifier is the IP address of the BGP speaker and it is the same on all interfaces of that BGP speaker and for all BGP peers. The BGP speaker may support optional parameters such as route refresh and this is contained in the Optional Parameters field.

Let’s use a simple topology to see packet captures of the BGP messages.

The configuration on the routers is as follows:

hostname R1
interface Loopback0
 ip address
interface FastEthernet0/0
 ip address
router bgp 1
 network mask
 neighbor remote-as 1
hostname R2
interface FastEthernet0/0
 ip address
router bgp 1
 neighbor remote-as 1

As you can see, the basic configuration to enable BGP on a Cisco router is as easy as defining the BGP process ID (which is the AS number) and also configuring the BGP neighbors along with their remote AS numbers.

Take a look at the packet capture between these two BGP speakers when they were trying to establish a BGP session.

The first three packets indicate that the routers first performed a three-way TCP handshake, after which they exchanged OPEN messages. Let’s view the content of one of the OPEN messages.

The part highlighted in green is the BGP message header, while the section highlighted in red contains the information in the OPEN message. Notice that the OPEN message has a Type code of 1 in the BGP message header. We also see that this BGP speaker (R2) is using BGP-4, has an AS of 1, proposes a hold time of 180 seconds, has a BGP identifier of, and supports three different optional parameters.

UPDATE message

The UPDATE message is sent after the BGP session has been established and it is used to exchange routing information between BGP neighbors. UPDATE messages can carry three types of information: feasible routes (in the NLRI field), path attributes and unfeasible routes. The general format of this message types is as shown below:

An UPDATE message may not contain any withdrawn routes, in which case the Withdrawn Routes Length field will be 0. Also, it is possible that the UPDATE message is used only to withdraw routes, in which case it will not contain the Path Attributes and NLRI fields.

From our scenario, R1 is the only one configured to advertise networks (via the network statement); therefore, we will see only an UPDATE message from R1 to R2.

First, we see that UPDATE messages have a type code of 2 in the BGP message header. We also notice that there are no withdrawn routes in this UPDATE message. There is one NLRI, which specifies the prefix. Also, we have a couple of path attributes for that NLRI. We will discuss path attributes in another article.

Just so we see the withdrawn routes, I will remove the network statement under the BGP configuration of R1. In that case, R1 will send an UPDATE message specifying that has become unfeasible. This UPDATE message will not contain any NLRI or path attributes.

BGP does not send UPDATE messages frequently like RIP does; UPDATE messages are sent after the BGP session has been established and when there is a change in the network. Rather than send frequent UPDATE messages, KEEPALIVE messages are sent.


These messages are sent periodically to ensure that a BGP neighbor is still up. It seems they are also sent immediately after the OPEN messages during BGP session establishment, before the UPDATE messages are sent. When a BGP peer receives a KEEPALIVE message (or UPDATE message) from its neighbor, it resets the hold timer. The RFC recommends that KEEPALIVE messages should be sent every one-third of the hold time interval. For example, if the negotiated hold time is 180 seconds, then KEEPALIVE messages should be sent every 60 seconds.

The KEEPALIVE message consists only of the BGP message header with no header and has a type value of 4.


These messages are sent when something goes wrong. The NOTIFICATION message contains a generic error code (e.g., OPEN message error), a more specific error subcode (e.g., Bad Peer AS), and a data field to give the reason for the error. You can view the different error codes and error subcodes here. The general format is as shown below:

To simulate a NOTIFICATION message, I would configure R2 with wrong neighbor information for R1 as follows:

router bgp 1
 no neighbor remote 1
 neighbor remote 2

When R2 receives the OPEN message sent by R1, it discovers that R1 specified an AS of 1. However, on R2, R1 is configured with an AS of 2, so R2 will send a NOTIFICATION message to R1 with an OPEN message error and Bad Peer AS error subcode. NOTIFICATION messages have a type code of 3 in the BGP message header.


In this article, we have considered four of the BGP message types including the OPEN message, which is used to establish the BGP session; the UPDATE message for exchanging routing information; the KEEPALIVE message to confirm that a neighbor is alive; and the NOTIFICATION message sent in response to an error.

I hope you have found this article insightful and I look forward to writing the next article in the series.

References and Further Reading

  1. RFC 4271: A Border Gateway Protocol 4 (BGP-4): http://tools.ietf.org/html/rfc4271
  2. Internet Routing Architectures 2nd Edition by Sam Halabi and Danny McPheron.