The following is a list of problems most commonly seen when forming BGP
neighbor relationships:
- Directly connected external BGP neighbors not initializing
- Non-directly connected external BGP neighbors not initializing
- Internal BGP neighbors not initializing
- BGP neighbors (external and internal) not initializing
Directly Connected External BGP Neighbors Not
Initializing
The autonomous system (AS) will not send or receive any IP
prefix updates to or from a neighboring AS unless the neighbor relationship
reaches the Established state, which is the final stage of BGP neighbor
establishment. When an AS has a single EBGP connection, no IP connectivity can
occur until BGP finalizes its operation of sending and receiving IP prefixes.
Figure
shows a network
in which an external BGP neighbor relationship is configured between AS 109 and
AS 110. The most common possible causes of directly connected external BGP
neighbors not initializing are:
- Layer 2 is down, preventing communication with directly connected EBGP
neighbor.
- An incorrect neighbor IP address is in the BGP configuration.
The BGP neighbor relationship can be verified by using the
show ip bpg summary and show ip bgp
neighbors commands.
This
command shows that the BGP neighbor is in Active state. This state indicates
that no successful communication between the neighbors has taken place and the
BGP has failed to form a neighbor relationship. The ping
command can be used to verify the connectivity problem, and the output should
show the ping failures. The solution to this problem would be the correction of
the Layer 1/2 problem.
Misconfiguration of the neighbor IP address is a
fairly common mistake, and it can be caught with a visual inspection of the
configuration. However, in a large IP network, this might not be a trivial
task. The debug ip bgp command, as demonstrated in Figure
can help
diagnose this problem. Observe that router R2 is having difficulty
communicating with host 131.108.1.11, which has a misconfigured neighbor
address on R2, as shown in Figure
. The solution
here would be to correct the neighbor address in the configuration of router
R2.

Nondirectly Connected External BGP Neighbors Not Initializing
In
some cases, EBGP neighbors are not directly connected. BGP neighbor
relationships can be established between routers trying to make an EBGP
neighbor relationship that are separated by one or more routers. Such a
neighbor relationship is termed EBGP multihop in Cisco IOS Software.
Peering between loopbacks between EBGP typically is done when multiple
interfaces exist between the routers, and IP traffic needs to be load-shared
among those interfaces. Such a connection is considered nondirectly connected.
Figure
shows an example
of a nondirectly connected EBGP session between two loopback interfaces.
The most common possible causes for nondirectly connected external BGP
neighbors not initializing are:
- The route to the nondirectly connected peer address is missing from the
routing table.
- The ebgp-multihop command is missing in BGP
configuration.
- The update-source interface command is missing.
The show ip bpg summary and show ip bgp
neighbors commands can be used to show that the neighbor
relationship is in Active state.
In the case of
ebgp-multihop command missing in the BGP configuration,
these commands will show that the BGP neighbor is in Idle state, because no
resources are allocated to the BGP neighbor. This might be because the other
side has not received any BGP negotiation.
The solutions to these
possible causes vary and depend upon the exact situation. Using the scenario in
Figure
, the following
are some possible solutions.
The solutions for the route to the
nondirectly connected peer address is missing from the routing table is to
either use a static route (common practice) to the connected peer address or a
use an IGP dynamic routing protocol such as OSPF. This is usually an issue when
peering is done between peers using loopback addresses.
A possible
solution to the ebgp-multihop command missing in the BGP
configuration is to properly configure this command. Figure
shows an example
of configuring this command on router R1.
In the case of the
update-source interface command missing, using the example
in Figure
, R1 and R2
should be configured with the update-source command. The
update-source command ensures that the source address is
that of Loopback 0.

Internal BGP Neighbors Not Initializing
IBGP can
experience similar issues to EBGP in neighbor relationship. IBGP is an
important piece of BGP-running networks. The causes of IBGP neighbor
relationship issues are identical to those of EBGP:
- The route to the nondirectly connected IBGP neighbor is missing.
- The update-source interface command is missing in BGP configuration.
The same troubleshooting and configuration techniques can be used for
IBGP neighbor issues that are used for EBGP neighbor issues.
BGP
Neighbors (external and internal) Not Initializing
Interface access
list/filters are another common cause of BGP neighbor activation problems. If
an interface access list unintentionally blocks TCP packets that carry BGP
protocol packets, the BGP neighbor will not come up.
Figure
shows a sample
access list 101 that explicitly blocks TCP. Access list 102 has an implicit
deny of BGP because of the implicit deny at the end of each access list. Figure
shows the
revised access configuration that permits the BGP port (TCP port 179). All BGP
packets will be permitted because of the second line in access list 101.