Professional Documents
Culture Documents
External BGP
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.
Router C Router D
(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
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)
MikeC# MikeD#
MikeC# MikeD#
MikeC#show run MikeD#show run
Building configuration... Building configuration...
MikeC#
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:
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...
~ ~ ~ (<-- output omitted)
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
no auto-summary
!
~ ~ ~ (<-- output omitted)
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:
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
Enter configuration commands, one per line. End with CNTL/Z.
MikeD(config)#router bgp 65002
MikeD(config-router)#nei 192.168.1.1 remote-as 65001
MikeD(config-router)#^Z
MikeD#
On Router C:
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:
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:
The BGP state is given as Established. The omitted output is counters that become significant after BGP
has begun to advertise.
You can see that the State/PfxRcd field says Active instead of showing a digit.
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#
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.
MikeC#
No output at all—fairly ambiguous. What does the show ip bgp neighbors command have to say?
MikeC#
MikeC#s run
~ ~ ~ (<-- output omitted)
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
no auto-summary
!
~ ~ ~ (<-- output omitted)
The BGP process has been configured, but no neighbor has been specified.
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:
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
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.
How about this output from the show ip bgp summary and show ip bgp neighbors commands:
Outbound Inbound
Local Policy Denied Prefixes: -------- -------
Total: 0 0
Number of NLRIs in the update sent: max 0, min 0
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.
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.
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
Enter configuration commands, one per line. End with CNTL/Z.
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)
Router D
MikeD#conf t
Enter configuration commands, one per line. End with CNTL/Z.
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
Enter configuration commands, one per line. End with CNTL/Z.
MikeC(config)#ip route 172.16.255.2 255.255.255.255 192.168.1.2
MikeC(config)#^z
MikeC(config)#
MikeD#conf t
Enter configuration commands, one per line. End with CNTL/Z.
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.
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.
Idle state:
Connect state:
Active state:
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.
Established state:
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
Connect(2)
1 none none 2
3 Complete initialization OPEN 4
Clear ConnectRetry timer
5 Restart ConnectRetry timer none 3
7 Restart ConnectRetry timer none 2
Initiate a transport connection
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
7 Restart ConnectRetry timer none 2
Initiate a transport connection
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
4 Release resources none 1
6 Release resources none 1
9 Restart KeepAlive timer KEEPALIVE 5
11 Complete initialization none 6
Restart Hold Timer
13 Close transport connection 1
Release resources
others Close transport connection NOTIFICATION 1
Release resources