netcerts.

net
Routing & Switching

Contact

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 frees 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

LOOP DETECTION (AS_PATH ATTRIBUTE ON EACH ROUTE)

AS 100 is originating the network prefix 1.1.1.0/24 and will advertise the prefix to its unique
unicast BGP neighbors as (Network Prefix : ORIGIN-CODE : AS-Path) 1.1.1.0/24: 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 1.1.1.0/24 only to AS- 300 as ( 1.1.1.0/24 : 100) then AS-300 advertises the
route-prefix to AS-200 as ( 1.1.1.0/24 : 300,100) and the packet traverses to AS-200 at this point
AS-200 advertises the path to AS-100 as ( 1.1.1.0/24 : 200,300,100). Here AS-100 will see its
own AS in the AS Path listed and will drop the packet.
SHORTEST PATH SELECTION (AS_PATH ATTRIBUTE ON EACH ROUTE)
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
1.1.1.0/24 from both AS 300 and AS 600. The route receiving from AS 300 will look like
[ 1.1.1.0/24 : 300,100] and the same route receiving from AS 600 will look like [ 1.1.1.0/24 :
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.
LOAD BALANCING Overview in BGP

If there is more than one equal-cost path to a particular destination then Ciscos 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.

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 peers 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, 5632064511 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 neighbors BGP Session to close. Below are the ErrorCodes and their corresponding Sub-codes which can help determine what type of event triggered
the BGP to close the session.

Error Code
1 Message Header
Error

Error Subcode
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 neighbors 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:

bgp backward transition (103)

bgpBackwardTransition (50)

bgp fsm (37)

BGP states (31)

bgp protocol (20)

bgp finite state machine (18)

bgp process (2)

bgp parameters that need to match (1)

bgp duplicate AS in path (1)

bgp backwards FSM transition (1)

what are routing protocols netcert (1)

May 14, 2010 Amit Rai BGP No Comment BGP, Routing Protocols
BGP Path Attributes

Leave a Reply
You must be logged in to post a comment.
Categories

[]BGP (5)
o BGP Decision Process
o BGP Path Attributes
o BGP Protocol Overview
o IBGP Basics
o Route Reflectors and Confederations

[+]IP Multicast (1)

[+]IPv6 (2)

[+]Layer-2 Switching (5)

[+]Layer-7 Applications (1)

[+]MPLS (4)

[+]Network Services (2)

[+]QoS (9)

Archives
Recent Posts

Exploring HTTP and PKI

Configuring Cisco router as a DHCP client

QoS Congestion Avoidance

CBWFQ and LLQ

Custom Queuing and Priority Queuing

Queuing and WFQ

IP SLA

Q-in-Q Tunneling

Private VLANs

MSTP (802.1S)

Site Info

Contact

netcerts.net Copyright 2014 | Theme: Magazine Style Powered by WordPress