BGP Routing Protocol Overview
BGP Routing Protocol Overview
Hi ! Today i will discuss about BGP Routing Protocol Overview. BGP is an Border gateway protocol, BGP mainly use for connect between different networks. It is the protocol used between Internet service providers (ISPs) and also can be used between an Enterprise and an ISP. BGP was built for reliability, scalability, and control.
- BGP stands for Border Gateway Protocol. Routers running BGP are termed BGP speakers.
- BGP uses the concept of autonomous systems (AS). An autonomous system is a group of networks under a common administration. The Internet Assigned Numbers Authority (IANA) assigns AS numbers: 1 to 64511 are public AS numbers and 64512 to 65535 are private AS numbers.
- Autonomous systems run Interior Gateway Protocols (IGP) within the system. They run an Exterior Gateway Protocol (EGP) between them. BGP version 4 is the only EGP currently in use.
- Routing between autonomous systems is called interdomain routing.
- The administrative distance for EBGP routes is 20. The administrative distance for IBGP routes is 200.
- BGP neighbors are called peers and must be statically configured.
- BGP uses TCP port 179. BGP peers exchange incremental, triggered route updates and periodic keepalives.
- Routers can run only one instance of BGP at a time.
- BGP is a path-vector protocol. Its route to a network consists of a list of autonomous systems on the path to that network.
- BGP’s loop prevention mechanism is an autonomous system number. When an update about a network leaves an autonomous system, that autonomous system’s number is prepended to the list of autonomous systems that have handled that update. When an autonomous system receives an update, it examines the autonomous system list. If it finds its own autonomous system number in that list, the update is discarded.
BGP uses three databases. The first two listed are BGP-specific; the third is shared by all routing processes on the router:
- Neighbor database: A list of all configured BGP neighbors. To view it, use the show ip bgp summary command.
- BGP database, or RIB (Routing Information Base): A list of networks known by BGP, along with their paths and attributes. To view it, use the show ip bgp command.
- Routing table: A list of the paths to each network used by the router, and the next hop for each network. To view it, use the show ip route command.
BGP Message Types
BGP has four types of messages:
- 1) Open: After a neighbor is configured, BGP sends an open message to try to establish peering with that neighbor. Includes information such as autonomous system number, router ID, and hold time.
- 2) Update: Message used to transfer routing information between peers. Includes new routes, withdrawn routes, and path attributes.
- 3) Notification: When a problem occurs that causes a router to end the BGP peering session, a notification message is sent to the BGP neighbor and the connection is closed.
- 4) Keepalive: BGP peers exchange keepalive messages every 60 seconds by default. These keep the peering session active.
- ROUTE-REFRESH: An optional message (negotiated during capability advertisement) that is sent to request dynamic BGP route updates from the Adj-RIB-Out table of a remote BGP speaker
BGP 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)
* BGP 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 multi protocol support, authentication, etc.
BGP 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.
A BGP Update message is able to advertise a single feasible route, or withdrawn multiple unfeasible routes, or both. An Update message contains information about a single path only; multiple paths require multiple Update messages. All the path attributes in the Update message refer to a particular path, and the prefixes that can be reached through the specified path – update packing.
The BGP Update message contains the following fields and information:
# Unfeasible Routes Length. A 2-byte field that indicates the total length of the following Withdrawn Routes field, in octets. A value of zero indicates that no routes are being withdrawn and there is no Withdrawn Routes field is included in the Update message.
# Withdrawn Routes. A variable-length field that contains a list of unreachable routes that are to be withdrawn from service, if any. Each route in the list is described with a (Length – Prefix) tuple. If the Length part of the tuple is 0, the Prefix matches all routes.
# Total Path Attribute Length. A 2-byte field that indicates the total length of the following Path Attributes field, in octets. A value of zero indicates that no path attributes and NLRI are included in the Update message.
# Path Attributes. A variable-length field that lists the attributes associated with the NLRI in the following field. Each path attribute is a variable-length triplet of (Attribute Type, Attribute Length, Attribute Value). The 2-byte Attribute Type field of the triplet consists of the 4 Attribute Flag bits, 4 unused bits, and a 1-byte Attribute Type Code field.
# Network Layer Reachability Information (NLRI). A variable-length field that contains a list of IP prefixes that can be reached via this path using the (Length – Prefix) tuples. A Length value of 0 indicates a prefix that matches all IP prefixes.
BGP 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||0|
|5 – Finite State machine Error||0|
|6 – Cease (fatal error)||0|
BGP 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.
The Route-refresh message notifies the route refreshment capability.If all routers of BGP are enabled with route-refresh capability, local BGP router sends route-refresh information to peers when the routing policy of BGP changes. The peers receiving the information resends routing information to the local BGP router. Thus, the routing table of BGP can be dynamically refreshed and the new routing policy can be used without interrupting BGP connections.
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.
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.
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 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.
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.
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
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.