BGP Connection Basics

BGP Connection Basics
External BGP
Created by Mike Bevan
Unlike most other routing protocols, Border Gateway Protocol (BGP) does not automatically discover
neighbors and then send updates. It must be manually configured with information regarding what devices
to peer with and what information to advertise to those peers. Security is the main driver behind this
method.
So when configuring a Cisco router to advertise using BGP, the first step is to establish peering between the
BGP devices and verify that the BGP devices have peered. It is important to stop and verify connectivity.
Nothing will work if the underlying connection is not made, so you should verify connectivity while things are
simple.
This document is about establishing this basic connectivity, and covers external BGP peering. Internal BGP
is covered in a later document.
Generally, but not always, External BGP (EBGP) peers are directly connected. This document covers basic
connectivity step by step, using the following scenario:
AS 65001 AS 65002
Lo0 Lo0
172.16.255.1/32 172.16.255.2/32
Router C Router D
S0/0/1 S0/0/1
192.168.1.1/24 192.168.1.2/24
As shown in the example, the BGP devices are directly connected using ports S0/0/1, and IP addresses
192.168.1.1 & 192.168.1.2.
1 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

Here is the version information, along with initial configurations:
Router C Router D
Version information: Version information:
MikeC#s ver MikeD#s ver

Cisco IOS Software, 2800 Software Cisco IOS Software, 2800 Software
(C2800NM-ADVIPSERVICESK9-M), Version (C2800NM-ADVIPSERVICESK9-M), Version
12.4(12), RELEASE SOFTWARE 12.4(12), RELEASE SOFTWARE
(fc1) (fc1)
Technical Support: Technical Support:
http://www.cisco.com/techsupport http://www.cisco.com/techsupport
Copyright (c) 1986-2006 by Cisco Systems, Copyright (c) 1986-2006 by Cisco Systems,
Inc. Inc.
Compiled Fri 17-Nov-06 12:02 by Compiled Fri 17-Nov-06 12:02 by
prod_rel_team prod_rel_team
ROM: System Bootstrap, Version 12.4(1r) ROM: System Bootstrap, Version

[hqluong 1r], RELEASE SOFTWARE (fc1) 12.4(13r)T, RELEASE SOFTWARE (fc1)
~ ~ ~ (<-- output omitted) ~ ~ ~ (<-- output omitted)
System image file is "flash:c2800nm- System image file is "flash:c2800nm-

advipservicesk9-mz.124-12.bin" advipservicesk9-mz.124-12.bin"
Cisco 2811 (revision 53.51) with Cisco 2811 (revision 53.51) with
249856K/12288K bytes of memory. 249856K/12288K bytes of memory.
Processor board ID FTX1013A1DJ Processor board ID FTX1107A6A1
2 FastEthernet interfaces 2 FastEthernet interfaces
2 Serial(sync/async) interfaces 2 Serial(sync/async) interfaces
1 Virtual Private Network (VPN) Module 1 Virtual Private Network (VPN) Module
DRAM configuration is 64 bits wide with DRAM configuration is 64 bits wide with
parity enabled. parity enabled.
239K bytes of non-volatile configuration 239K bytes of non-volatile configuration
memory. memory.
62720K bytes of ATA CompactFlash 62720K bytes of ATA CompactFlash
(Read/Write) (Read/Write)
Configuration register is 0x2101 Configuration register is 0x2102
MikeC# MikeD#
Starting Configuration Starting Configuration
MikeC# MikeD#
MikeC#show run MikeD#show run
Building configuration... Building configuration...
Current configuration : 882 bytes Current configuration : 1319 bytes

! !
version 12.4 version 12.4

! !
interface Loopback0 interface Loopback0
ip address 172.16.255.1 255.255.255.255 ip address 172.16.255.2 255.255.255.255
! !
interface FastEthernet0/0 interface FastEthernet0/0
no ip address no ip address
shutdown shutdown
duplex auto duplex auto
speed auto speed auto
! !
interface FastEthernet0/1 interface FastEthernet0/1
shutdown shutdown
duplex auto duplex auto
speed auto speed auto
! !
interface Serial0/0/0 interface Serial0/0/0
shutdown shutdown
! !
interface Serial0/0/1 interface Serial0/0/1
ip address 192.168.1.1 255.255.255.0 ip address 192.168.1.2 255.255.255.0
clock rate 2000000 !
! !
! ip http server
ip http server no ip http secure-server
no ip http secure-server !
!
~ ~ ~ (<-- output omitted)
MikeD#
MikeC#
At this point, BGP is not active, as shown by the following:
MikeC#s ip bgp summary

% BGP not active
MikeC#

Basic BGP Connectivity
Now you will configure basic BGP connectivity:
MikeC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
MikeC(config)#router bgp 65001
MikeC(config-router)#nei 192.168.1.2 remote-as 65002
MikeC(config-router)#^Z
MikeC#
Now take a look at both configuration statements so that you can see what is happening:
(1) MikeC(config)#router bgp 65001

Start the BGP process, and allocate resources.
Side note: If you exit configuration mode at this point and do a show running-config, you will see the
following in this IOS version:
MikeC#s run
Building configuration...
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
no auto-summary
!
(2) MikeC(config-router)#nei 192.168.1.2 remote-as 65002

Manually specify the BGP neighbor to peer with. This command gives the ip address of the device,
and the autonomous system number that it belongs to.
At this point, the router tries to establish a TCP connection with the neighboring device. Router D has not
been configured yet, so you get the following output:
*Oct 1 19:27:21.014: BGP: 192.168.1.2 went from Idle to Active

*Oct 1 19:27:21.014: BGP: 192.168.1.2 open active delayed 34461ms (35000ms max, 28%
jitter)
*Oct 1 19:27:55.478: BGP: 192.168.1.2 open active, local address 192.168.1.1
*Oct 1 19:27:55.478: BGP: 192.168.1.2 open failed: Connection refused by remote
Notice that the BGP state went from Idle to Active. Active is not an operational state, which will be
discussed in more detail later.
Now it is time to enable BGP on Router D, which is the same as on Router C except for the neighbor’s IP
address and AS number:
MikeD#conf t
MikeD(config)#router bgp 65002
MikeD(config-router)#nei 192.168.1.1 remote-as 65001
MikeD(config-router)#^Z
MikeD#

Now that the neighbors have been configured to peer with each other, that is what they do. (Please note
before you study the output in detail that only the last line is important; the rest shows just the progression in
getting there).
On Router C:
*Oct 1 19:33:31.914: BGP: 192.168.1.2 open active, local address 192.168.1.1

*Oct 1 19:33:31.914: BGP: 192.168.1.2 went from Active to OpenSent
*Oct 1 19:33:31.914: BGP: 192.168.1.2 sending OPEN, version 4, my as: 65001,
holdtime 180 seconds
*Oct 1 19:33:31.918: BGP: 192.168.1.2 send message type 1, length (incl. header) 45
*Oct 1 19:33:31.922: BGP: 192.168.1.2 rcv message type 1, length (excl. header) 26
*Oct 1 19:33:31.922: BGP: 192.168.1.2 rcv OPEN, version 4, holdtime 180 seconds
*Oct 1 19:33:31.922: BGP: 192.168.1.2 rcv OPEN w/ OPTION parameter len: 16
*Oct 1 19:33:31.926: BGP: 192.168.1.2 rcvd OPEN w/ optional parameter type 2
(Capability) len 6
*Oct 1 19:33:31.926: BGP: 192.168.1.2 OPEN has CAPABILITY code: 1, length 4
*Oct 1 19:33:31.926: BGP: 192.168.1.2 OPEN has MP_EXT CAP for afi/safi: 1/1
(Capability) len 2
*Oct 1 19:33:31.926: BGP: 192.168.1.2 OPEN has ROUTE-REFRESH capability(old) for
all address-families
(Capability) len 2
*Oct 1 19:33:31.926: BGP: 192.168.1.2 OPEN has ROUTE-REFRESH capability(new) for
all address-families
BGP: 192.168.1.2 rcvd OPEN w/ remote AS 65002
*Oct 1 19:33:31.926: BGP: 192.168.1.2 went from OpenSent to OpenConfirm
*Oct 1 19:33:31.926: BGP: 192.168.1.2 went from OpenConfirm to Established
*Oct 1 19:33:31.926: %BGP-5-ADJCHANGE: neighbor 192.168.1.2 Up
The same on Router D:
Oct 1 11:39:42.811: BGP: 192.168.1.1 went from Idle to Active

Oct 1 11:39:42.811: BGP: 192.168.1.1 open active delayed 30636ms (35000ms max, 28%
jitter)
Oct 1 11:39:51.955: BGP: 192.168.1.1 passive open to 192.168.1.2
Oct 1 11:39:51.955: BGP: 192.168.1.1 went from Active to Idle
Oct 1 11:39:51.955: BGP: 192.168.1.1 went from Idle to Connect
Oct 1 11:39:51.955: BGP: 192.168.1.1 rcv message type 1, length (excl. header) 26
Oct 1 11:39:51.955: BGP: 192.168.1.1 rcv OPEN, version 4, holdtime 180 seconds
Oct 1 11:39:51.955: BGP: 192.168.1.1 went from Connect to OpenSent
Oct 1 11:39:51.955: BGP: 192.168.1.1 sending OPEN, version 4, my as: 65002,
holdtime 180 seconds
Oct 1 11:39:51.955: BGP: 192.168.1.1 rcv OPEN w/ OPTION parameter len: 16
Oct 1 11:39:51.955: BGP: 192.168.1.1 rcvd OPEN w/ optional parameter type 2
(Capability) len 6
Oct 1 11:39:51.955: BGP: 192.168.1.1 OPEN has CAPABILITY code: 1, length 4
Oct 1 11:39:51.955: BGP: 192.168.1.1 OPEN has MP_EXT CAP for afi/safi: 1/1
(Capability) len 2
Oct 1 11:39:51.959: BGP: 192.168.1.1 OPEN has ROUTE-REFRESH capability(old) for all
address-families
(Capability) len 2

Oct 1 11:39:51.959: BGP: 192.168.1.1 OPEN has ROUTE-REFRESH capability(new) for all
address-families
BGP: 192.168.1.1 rcvd OPEN w/ remote AS 65001
Oct 1 11:39:51.959: BGP: 192.168.1.1 went from OpenSent to OpenConfirm
Oct 1 11:39:51.959: BGP: 192.168.1.1 send message type 1, length (incl. header) 45
Oct 1 11:39:51.963: BGP: 192.168.1.1 went from OpenConfirm to Established
Oct 1 11:39:51.963: %BGP-5-ADJCHANGE: neighbor 192.168.1.1 Up
The preceding output shows that BGP connectivity between the peers is up and operational. The last line
says that the state went from OpenConfirm to Established. Once the state is Established, the BGP devices
have peered and can now pass network information—except that in the example here, the devices have not
been configured to do so yet. (Remember that for security purposes, you have to manually tell BGP to
advertise prefixes, and you have not told BGP to do that yet).
If you want to really get into the preceding details, there is more information on the BGP states later in this
document.
If you missed the preceding output or are checking on BGP at a later time, you can use the following show
commands to determine the state of the BGP peers:
MikeC#s ip bgp sum

BGP router identifier 172.16.255.1, local AS number 65001
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

192.168.1.2 4 65002 6 6 1 0 0 00:02:52 0
Note that when using the show ip bgp summary command, the State/PfxRcd field is reporting 0, not
established. This situation is acceptable, since you have not yet configured the ability to advertise; a digit
greater than 0 means that the state is established, and in this case, no prefixes have been received. If you
really need to see that the state is Established, use the show ip bgp neighbors command:
MikeC#s ip bgp nei

BGP neighbor is 192.168.1.2, remote AS 65002, external link
BGP version 4, remote router ID 172.16.255.2
BGP state = Established, up for 00:03:12
Last read 00:00:12, last write 00:00:12, hold time is 180, keepalive interval is
60 seconds
Neighbor capabilities:
Route refresh: advertised and received(old & new)
Address family IPv4 Unicast: advertised and received
The BGP state is given as Established. The omitted output is counters that become significant after BGP
has begun to advertise.

If the state is not Established, what will be the output of the show ip bgp summary command? The
following output came from Router C when it was configured for BGP but Router D was not:
MikeC#s ip bgp sum


192.168.1.2 4 65002 0 0 0 0 0 never Active
MikeC#
You can see that the State/PfxRcd field says Active instead of showing a digit.
What Can Go Wrong?
In its simplicity, what can go wrong? More than you might think, and it is usually a configuration problem.
Please note that many times you have access to only one of the BGP peers; the other peer may belong to
another autonomous system that you cannot access. If you are sure that your configuration is correct, and
you still cannot get to the Established state, you will have to contact the administrator of the other
autonomous system and have them verify their configuration. But make sure that you have thoroughly
checked your end first.
1) You execute the show ip bgp summary command and receive the following:
MikeC#s ip bgp sum

% BGP not active
MikeC#
As shown here, this means that, for whatever reason, BGP has not been configured on this device. Your
colleague insists that BGP is configured on the router, or you may have done it yourself, but for whatever
reason BGP is not there. The show running-config command can verify this situation. If you see BGP
configured and you are getting this output, you have a more serious problem and it is not a BGP problem.
2) The show ip bgp summary command gives the following output:
MikeC#s ip bgp sum
MikeC#
No output at all—fairly ambiguous. What does the show ip bgp neighbors command have to say?
MikeC#s ip bgp nei
MikeC#

It is equally silent on the subject. A quick look at show running-config tells you what you need to know:
MikeC#s run
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
no auto-summary
!
The BGP process has been configured, but no neighbor has been specified.
3) The configuration is there, but it is just not working.
There are several things that can cause this issue.
Since you are building a TCP connection, there must be connectivity between the devices. Can
you ping the neighbor’s IP address? If not, you must first troubleshoot the connectivity problem. Is
something stopping traffic to or from TCP port 179 (BGP uses TCP port 179)? That is also a
possibility.
Is the neighbor directly connected? This means that the neighbor address that you are using
needs to be the IP address of the neighboring device’s directly connected interface. If it is not, you
can still peer with a nondirectly connected interface, but it is a little more involved. A more detailed
explanation will follow. However, before peering with an interface that is not directly connected,
you should ensure that you have a good reason for doing so.
Check out the following output from the show ip bgp summary and show ip bgp neighbors
commands:
MikeC#s ip bgp sum


192.168.2.2 4 65002 0 0 0 0 0 never Idle
MikeC#s ip bgp nei

BGP state = Idle
Last read 00:00:00, last write 00:00:00, hold time is 180, keepalive interval
is 60 seconds
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 0 0
Notifications: 0 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 0 0
Default minimum time between advertisement runs is 30 seconds

For address family: IPv4 Unicast
BGP table version 1, neighbor version 0/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Connections established 0; dropped 0

Last reset never
External BGP neighbor not directly connected.
No active TCP connection
MikeC#
Note that the show ip bgp summary command shows the state as Idle and that the show ip bgp
neighbors command also shows the state as Idle and specifies at the end that there is no active
TCP connection. Can you find a reason for this?
Look more carefully at the neighbor that is specified. It is easy to miss the fact that it is not the IP
address of the neighbor—close, but not close enough. The neighbor is 192.168.1.2, not
192.168.2.2.
MikeC#s ip bgp nei

How about this output from the show ip bgp summary and show ip bgp neighbors commands:
MikeC#s ip bgp sum


192.168.1.2 4 65022 2 2 0 0 0 never Active
MikeC#s ip bgp nei

BGP state = Active
Last read 00:00:11, last write 00:00:11, hold time is 180, keepalive interval
is 60 seconds
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 2 2

Notifications: 2 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 2 2
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast

BGP table version 1, neighbor version 0/0
Output queue size : 0
Index 1, Offset 0, Mask 0x2
1 update-group member
Sent Rcvd
Prefix activity: ---- ----
Prefixes Current: 0 0
Prefixes Total: 0 0
Implicit Withdraw: 0 0
Explicit Withdraw: 0 0
Used as bestpath: n/a 0
Used as multipath: n/a 0
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
Connections established 0; dropped 0

Last reset never
No active TCP connection
MikeC#
Review the neighbor’s autonomous system (AS) number. It may be a typo, or it may be that the
number you were given is incorrect. The wrong AS number will give the preceding output; note that
in the example, you are peering with AS 65002, and AS 65022 was input.
MikeC#s ip bgp nei

Peering with Nondirectly Connected Interfaces
While in most instances you will be peering with directly connected BGP devices, that is not always the
case. Cisco routers have the ability to EBGP peer with devices that are not directly connected. The
following example, shows peering between the loopback interfaces instead of between the directly
connected interfaces.

To repeat, if you are going to do this, make sure that you have a good reason. The example here shows a
connection using the loopback 0 interfaces, but that is usually not necessary. Generally, there is only one
path, and if the link goes down, the router does not find its peer by way of another path. However, peering
using loopback interfaces is a valid way to connect and loadshare when there are multiple links between the
two peering routers.
AS 65001 AS 65002
Lo0 Lo0
172.16.255.1/32 172.16.255.2/32
Router C Router D
S0/0/1 S0/0/1
192.168.1.1/24 192.168.1.2/24
By default, Cisco routers use the IP address of the outgoing interface to peer with its BGP neighbor. In the
previous example, where the devices peered with the directly connected interfaces, Router C was told to
peer with Router D IP address 192.168.1.2; Router D was told to peer with Router C IP address
192.168.1.1. The peering was built between the directly connected interfaces. Router C was not told to build
the peering using the IP address of the serial interface; it did it by default. The same is true for Router D.
To peer with an interface that is not directly connected, you must add the neighbor <ip address> ebgp-
multihop {ttl} command. This command tells the router that the BGP peer is not directly connected but is
multiple hops away. The Time to Live (TTL) field allows you to specify the number of hops (security again),
or you can let it default to 255.
If you want your router to peer using the IP address of an interface that is not the one directly connected to
its BGP neighbor (such as a loopback interface address), then you use the neighbor <ip address>
update-source <interface> command. You must also ensure that the peer uses that IP address in its
neighbor statements.
The example shows peering using loopback interfaces. Here is the configuration:
Router C
MikeC#conf t
MikeC(config)#router bgp 65001
MikeC(config-router)#nei 172.16.255.2 remote-as 65002
MikeC(config-router)#nei 172.16.255.2 update-source loopback 0
MikeC(config-router)#nei 172.16.255.2 ebgp-multihop
MikeC#
*Oct 2 00:02:52.117: BGP: 172.16.255.2 went from Idle to Active
*Oct 2 00:02:52.117: BGP: 172.16.255.2 open active delayed 30673ms (35000ms max,
28% jitter)
*Oct 2 00:03:22.793: BGP: 172.16.255.2 active open failed - no route to peer, open
active delayed 33707ms (35000ms max, 28% jitter)

The update-source loopback 0 command states that you will be peering using the loopback 0
interface.
The ebgp-multihop command lets the router know that the TTL field must be set higher than 1 to
allow the neighbor to be multiple hops away. In this case, though, a hop count has not been
specified, and therefore the neighbor could be up to 255 hops away.
Router D
MikeD#conf t
MikeD(config)#router bgp 65002
MikeD(config-router)#nei 172.16.255.1 remote-as 65001
MikeD(config-router)#nei 172.16.255.1 update-source loopback 0
MikeC(config-router)#nei 172.16.255.1 ebgp-multihop
MikeD#
Oct 1 16:11:09.193: BGP: 172.16.255.1 went from Idle to Active
Oct 1 16:11:09.193: BGP: 172.16.255.1 open active delayed 34535ms (35000ms max, 28%
jitter)
Oct 1 16:11:43.729: BGP: 172.16.255.1 active open failed - no route to peer, open
active delayed 26811ms (35000ms max, 28% jitter)
Looking at the show ip bgp summary and show ip bgp neighbors commands, you see that the BGP
state is Active and that no TCP session has been established. The terminal output when we configured
BGP tells you that there is no route to the peer.
This is a very common mistake when configuring non–directly connected BGP connectivity. Think about it.
You have specified the neighbor IP address, but the router does not know how to get there. The address is
not in your autonomous system and is therefore not in your routing table. You are not sharing internal
network information with your neighboring autonomous system, and it is certainly not sharing its information
with you.
You need a way to route to the peering IP address. How about a static route?
MikeC#conf t
MikeC(config)#ip route 172.16.255.2 255.255.255.255 192.168.1.2
MikeC(config)#^z
MikeC(config)#
MikeD#conf t
MikeD(config)#ip route 172.16.255.1 255.2
MikeD(config)#^z
MikeD(config)#
Watch the output after you have configured your router. If the router at the other end is configured correctly,
your state will go to Enabled.
Along with the problems mentioned in the “What Can Go Wrong?” section, a lot of troubleshooting time is
spent tracking down connectivity problems that turn out to be simply that the ebgp-multihop or the update-
source commands have not been configured, or both. IBGP does not need a multihop command to peer
with non–directly connected peers, so many people forget that it is needed for EBGP. You will save yourself
time if you remember this important point.

BGP States
Here is a quick summary of the BGP states:
1) Idle: The BGP peers are not connected, and the router is not even thinking about trying to do so.
2) Connect: The router has decided to connect to its peer. It does not stay in this state long; it goes to
Active, or back to Idle, or to OpenSent if the TCP connection is made. You will rarely see this using
a show command.
3) Active: If your BGP neighbor is in this state it means that there is a problem (see information
above).
4) OpenSent: The TCP session is active, BGP is performing its handshaking.
5) OpenConfirm: BGP is still performing its handshaking.
6) Established: BGP has connected with its neighbor.
If you would like to know exactly what each BGP state is and does, the following information is copied from
RFC 1771, titled “A Border Gateway Protocol 4 (BGP-4),” from March 1995. Section 8, which defines the
states and actions, and Appendix 1, with transitions and actions, are given here.
Network Working Group Y. Rekhter

Request for Comments: 1771 T.J. Watson Research Center, IBM Corp.
Obsoletes: 1654 T. Li
Category: Standards Track cisco Systems
Editors
March 1995
A Border Gateway Protocol 4 (BGP-4)
~~~ (<-- output omitted)
8. BGP Finite State machine.
This section specifies BGP operation in terms of a Finite State

Machine (FSM). Following is a brief summary and overview of BGP
operations by state as determined by this FSM. A condensed version
of the BGP FSM is found in Appendix 1.
Initially BGP is in the Idle state.
Idle state:
In this state BGP refuses all incoming BGP connections. No

resources are allocated to the peer. In response to the Start
event (initiated by either system or operator) the local system
initializes all BGP resources, starts the ConnectRetry timer,
initiates a transport connection to other BGP peer, while
listening for connection that may be initiated by the remote
BGP peer, and changes its state to Connect. The exact value of
the ConnectRetry timer is a local matter, but should be
sufficiently large to allow TCP initialization.

If a BGP speaker detects an error, it shuts down the connection
and changes its state to Idle. Getting out of the Idle state
requires generation of the Start event. If such an event is
generated automatically, then persistent BGP errors may result
in persistent flapping of the speaker. To avoid such a
condition it is recommended that Start events should not be
generated immediately for a peer that was previously
transitioned to Idle due to an error. For a peer that was
previously transitioned to Idle due to an error, the time
between consecutive generation of Start events, if such events
are generated automatically, shall exponentially increase. The
value of the initial timer shall be 60 seconds. The time shall
be doubled for each consecutive retry.
Any other event received in the Idle state is ignored.
Connect state:
In this state BGP is waiting for the transport protocol

connection to be completed.
If the transport protocol connection succeeds, the local system

clears the ConnectRetry timer, completes initialization, sends
an OPEN message to its peer, and changes its state to OpenSent.
If the transport protocol connect fails (e.g., retransmission

timeout), the local system restarts the ConnectRetry timer,
continues to listen for a connection that may be initiated by
the remote BGP peer, and changes its state to Active state.
In response to the ConnectRetry timer expired event, the local

system restarts the ConnectRetry timer, initiates a transport
connection to other BGP peer, continues to listen for a
connection that may be initiated by the remote BGP peer, and
stays in the Connect state.
Start event is ignored in the Active state.
In response to any other event (initiated by either system or

operator), the local system releases all BGP resources
associated with this connection and changes its state to Idle.
Active state:
In this state BGP is trying to acquire a peer by initiating a

transport protocol connection.
If the transport protocol connection succeeds, the local system

clears the ConnectRetry timer, completes initialization, sends
an OPEN message to its peer, sets its Hold Timer to a large
value, and changes its state to OpenSent. A Hold Timer value
of 4 minutes is suggested.
In response to the ConnectRetry timer expired event, the local

system restarts the ConnectRetry timer, initiates a transport
connection to other BGP peer, continues to listen for a
changes its state to Connect.

If the local system detects that a remote peer is trying to
establish BGP connection to it, and the IP address of the
remote peer is not an expected one, the local system restarts
the ConnectRetry timer, rejects the attempted connection,
continues to listen for a connection that may be initiated by
the remote BGP peer, and stays in the Active state.
Start event is ignored in the Active state.
In response to any other event (initiated by either system or

operator), the local system releases all BGP resources
associated with this connection and changes its state to Idle.
OpenSent state:
In this state BGP waits for an OPEN message from its peer.
When an OPEN message is received, all fields are checked for
correctness. If the BGP message header checking or OPEN
message checking detects an error (see Section 6.2), or a
connection collision (see Section 6.8) the local system sends a
NOTIFICATION message and changes its state to Idle.
If there are no errors in the OPEN message, BGP sends a

KEEPALIVE message and sets a KeepAlive timer. The Hold Timer,
which was originally set to a large value (see above), is
replaced with the negotiated Hold Time value (see section 4.2).
If the negotiated Hold Time value is zero, then the Hold Time
timer and KeepAlive timers are not started. If the value of
the Autonomous System field is the same as the local Autonomous
System number, then the connection is an "internal" connection;
otherwise, it is "external". (This will effect UPDATE
processing as described below.) Finally, the state is changed
to OpenConfirm.
If a disconnect notification is received from the underlying

transport protocol, the local system closes the BGP connection,
restarts the ConnectRetry timer, while continue listening for
goes into the Active state.
If the Hold Timer expires, the local system sends NOTIFICATION

message with error code Hold Timer Expired and changes its
state to Idle.
In response to the Stop event (initiated by either system or

operator) the local system sends NOTIFICATION message with
Error Code Cease and changes its state to Idle.
Start event is ignored in the OpenSent state.
In response to any other event the local system sends

NOTIFICATION message with Error Code Finite State Machine Error
and changes its state to Idle.
Whenever BGP changes its state from OpenSent to Idle, it closes

the BGP (and transport-level) connection and releases all
resources associated with that connection.

OpenConfirm state:
In this state BGP waits for a KEEPALIVE or NOTIFICATION

message.
If the local system receives a KEEPALIVE message, it changes

its state to Established.
If the Hold Timer expires before a KEEPALIVE message is

received, the local system sends NOTIFICATION message with
error code Hold Timer Expired and changes its state to Idle.
If the local system receives a NOTIFICATION message, it changes

its state to Idle.
If the KeepAlive timer expires, the local system sends a

KEEPALIVE message and restarts its KeepAlive timer.

transport protocol, the local system changes its state to Idle.

operator) the local system sends NOTIFICATION message with
Start event is ignored in the OpenConfirm state.
In response to any other event the local system sends

Whenever BGP changes its state from OpenConfirm to Idle, it

closes the BGP (and transport-level) connection and releases
all resources associated with that connection.
Established state:
In the Established state BGP can exchange UPDATE, NOTIFICATION,

and KEEPALIVE messages with its peer.
If the local system receives an UPDATE or KEEPALIVE message, it

restarts its Hold Timer, if the negotiated Hold Time value is
non-zero.
If the local system receives a NOTIFICATION message, it changes

its state to Idle.
If the local system receives an UPDATE message and the UPDATE

message error handling procedure (see Section 6.3) detects an
error, the local system sends a NOTIFICATION message and
changes its state to Idle.

transport protocol, the local system changes its state to Idle.
If the Hold Timer expires, the local system sends a

NOTIFICATION message with Error Code Hold Timer Expired and
changes its state to Idle.

If the KeepAlive timer expires, the local system sends a
KEEPALIVE message and restarts its KeepAlive timer.
Each time the local system sends a KEEPALIVE or UPDATE message,

it restarts its KeepAlive timer, unless the negotiated Hold
Time value is zero.

operator), the local system sends a NOTIFICATION message with
Start event is ignored in the Established state.
In response to any other event, the local system sends

Whenever BGP changes its state from Established to Idle, it

closes the BGP (and transport-level) connection, releases all
resources associated with that connection, and deletes all
routes derived from that connection.
~~~ (<-- output omitted)
Rekhter & Li [Page 47]
RFC 1771 BGP-4 March 1995
Appendix 1. BGP FSM State Transitions and Actions.
This Appendix discusses the transitions between states in the BGP FSM
in response to BGP events. The following is the list of these states
and events when the negotiated Hold Time value is non-zero.
BGP States:
1 - Idle
2 - Connect
3 - Active
4 - OpenSent
5 - OpenConfirm
6 - Established
BGP Events:
1 - BGP Start
2 - BGP Stop
3 - BGP Transport connection open
4 - BGP Transport connection closed
5 - BGP Transport connection open failed
6 - BGP Transport fatal error
7 - ConnectRetry timer expired
8 - Hold Timer expired
9 - KeepAlive timer expired
10 - Receive OPEN message
11 - Receive KEEPALIVE message
12 - Receive UPDATE messages
13 - Receive NOTIFICATION message

The following table describes the state transitions of the BGP FSM
and the actions triggered by these transitions.
Event Actions Message Sent Next State

--------------------------------------------------------------------
Idle (1)
1 Initialize resources none 2
Start ConnectRetry timer
Initiate a transport connection
others none none 1
Connect(2)
1 none none 2
3 Complete initialization OPEN 4
Clear ConnectRetry timer
5 Restart ConnectRetry timer none 3
others Release resources none 1
Active (3)
1 none none 3
3 Complete initialization OPEN 4
Clear ConnectRetry timer
5 Close connection 3
Restart ConnectRetry timer
others Release resources none 1
OpenSent(4)
1 none none 4
4 Close transport connection none 3
Restart ConnectRetry timer
6 Release resources none 1
10 Process OPEN is OK KEEPALIVE 5
Process OPEN failed NOTIFICATION 1
others Close transport connection NOTIFICATION 1
Release resources
OpenConfirm (5)
1 none none 5
9 Restart KeepAlive timer KEEPALIVE 5
11 Complete initialization none 6
Restart Hold Timer
13 Close transport connection 1
Release resources
Release resources

Established (6)
1 none none 6
9 Restart KeepAlive timer KEEPALIVE 6
11 Restart Hold Timer KEEPALIVE 6
12 Process UPDATE is OK UPDATE 6
Process UPDATE failed NOTIFICATION 1
13 Close transport connection 1
Release resources
Release resources
---------------------------------------------------------------------
The following is a condensed version of the above state transition

table.
Events| Idle | Connect | Active | OpenSent | OpenConfirm | Estab

| (1) | (2) | (3) | (4) | (5) | (6)
|--------------------------------------------------------------
1 | 2 | 2 | 3 | 4 | 5 | 6
| | | | | |
2 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
3 | 1 | 4 | 4 | 1 | 1 | 1
| | | | | |
4 | 1 | 1 | 1 | 3 | 1 | 1
| | | | | |
5 | 1 | 3 | 3 | 1 | 1 | 1
| | | | | |
6 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
7 | 1 | 2 | 2 | 1 | 1 | 1
| | | | | |
8 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
9 | 1 | 1 | 1 | 1 | 5 | 6
| | | | | |
10 | 1 | 1 | 1 | 1 or 5 | 1 | 1
| | | | | |
11 | 1 | 1 | 1 | 1 | 6 | 6
| | | | | |
12 | 1 | 1 | 1 | 1 | 1 | 1 or 6
| | | | | |
13 | 1 | 1 | 1 | 1 | 1 | 1
| | | | | |
---------------------------------------------------------------

BGP Connection Basics

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

BGP Connection Basics

Caricato da

Copyright:

Formati disponibili

BGP Connection Basics

1 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

Version information: Version information:

MikeC#s ver MikeD#s ver

ROM: System Bootstrap, Version 12.4(1r) ROM: System Bootstrap, Version

~ ~ ~ (<-- output omitted) ~ ~ ~ (<-- output omitted)

System image file is "flash:c2800nm- System image file is "flash:c2800nm-

~ ~ ~ (<-- output omitted) ~ ~ ~ (<-- output omitted)

Configuration register is 0x2101 Configuration register is 0x2102

Starting Configuration Starting Configuration

Current configuration : 882 bytes Current configuration : 1319 bytes

~ ~ ~ (<-- output omitted) ~ ~ ~ (<-- output omitted)

2 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

At this point, BGP is not active, as shown by the following:

MikeC#s ip bgp summary

3 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

Now you will configure basic BGP connectivity:

(1) MikeC(config)#router bgp 65001

(2) MikeC(config-router)#nei 192.168.1.2 remote-as 65002

*Oct 1 19:27:21.014: BGP: 192.168.1.2 went from Idle to Active

4 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

*Oct 1 19:33:31.914: BGP: 192.168.1.2 open active, local address 192.168.1.1

The same on Router D:

Oct 1 11:39:42.811: BGP: 192.168.1.1 went from Idle to Active

5 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

MikeC#s ip bgp sum

BGP table version is 1, main routing table version 1

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

MikeC#s ip bgp nei

6 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

MikeC#s ip bgp sum

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

What Can Go Wrong?

MikeC#s ip bgp sum

2) The show ip bgp summary command gives the following output:

MikeC#s ip bgp sum

MikeC#s ip bgp nei

7 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

3) The configuration is there, but it is just not working.

There are several things that can cause this issue.

MikeC#s ip bgp sum

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

MikeC#s ip bgp nei

8 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

Connections established 0; dropped 0

MikeC#s ip bgp nei

MikeC#s ip bgp sum

Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

MikeC#s ip bgp nei

9 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

For address family: IPv4 Unicast

Connections established 0; dropped 0

MikeC#s ip bgp nei

Peering with Nondirectly Connected Interfaces

10 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

11 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

12 BGP Connection Basics: External BGP © 2009 Cisco Systems, Inc.

Here is a quick summary of the BGP states:

Network Working Group Y. Rekhter

A Border Gateway Protocol 4 (BGP-4)

~~~ (<-- output omitted)

8. BGP Finite State machine.

This section specifies BGP operation in terms of a Finite State