Internal BGP Neighbors
A BGP router considers each neighbor to be either an internal BGP (iBGP) peer or an external
BGP (eBGP) peer. Each BGP router resides in a single AS, so neighbor relationships are either
with other routers in the same AS (iBGP neighbors) or with routers in other autonomous systems
(eBGP neighbors). The two types of neighbors differ only slightly in regard to forming neighbor
relationships, with more significant differences in how the type of neighbor (iBGP or eBGP)
impacts the BGP update process and the addition of routes to the routing tables.
iBGP peers often use loopback interface IP addresses for BGP peering to achieve higher
availability. Inside a single AS, the physical topology often has at least two routes between each
pair of routers. If BGP peers use an interface IP address for their TCP connections, and that
interface fails, there still might be a route between the two routers, but the underlying BGP TCP
connection will fail. Any time two BGP peers have more than one route through which they can
reach the other router, peering using loopbacks makes the most sense.
Several examples that follow demonstrate BGP neighbor configuration and protocols, beginning
with Example 11-1. The example shows some basic BGP configuration for iBGP peers R1, R2,
and R3 in AS 123, with the following features, based on Figure 11-2.
BGP Neighbor Summary Table
BGP Feature Description and Values
How is the source IP address used to reach a
neighbor determined?
Defined with the neighbor update-source
command; or, by default, uses the outgoing interface
IP address for the route used to reach the neighbor
How is the destination IP address used to reach
a neighbor determined?
Explicitly defined on the neighbor command
Auto-summary* Off by default, enabled with auto-summary router
subcommand
Neighbor authentication MD5 only, using the neighbor password command
* Cisco changed the IOS default for BGP auto-summary to be disabled as of Cisco IOS Software Release 12.3.
Building BGP Neighbor Relationships 347
Figure 11-2 Sample Network for BGP Neighbor Configuration
■ The three routers in ASN 123 will form iBGP neighbor relationships with each other
(full mesh).
■ R1 will use the bgp router-id command to configure its RID, rather than use a loopback.
■ R3 uses a peer-group configuration for neighbors R1 and R2. This allows fewer configuration
commands, and improves processing efficiency by having to prepare only one set of outbound
Update packets for the peer group. (Identical Updates are sent to all peers in the peer group.)
■ The R1-R3 relationship uses BGP MD5 authentication, which is the only type of BGP
authentication supported in Cisco IOS.
IBGP
IBGP
IBGP
EBGP
EBGP
Network 21.0.0.0/8
Subnet 22.1.1.0/24
R5
10.1.34.4
10.1.134.4 IBGP
10.1.34.3
10.1.134.3
172.16.16.6
172.16.16.1
ASN 678
ASN 123 ASN 45
R7
RID
111.111.111.111
R9
R4
R6 R8
EBGP IBGP
IGP
Network 31.0.0.0/8
Subnet 32.1.1.0/24
RID
3.3.3.3
RID
8.8.8.8
RID
9.9.9.9
RID
7.7.7.7
RID
6.6.6.6
RID
2.2.2.2
RID
5.5.5.5
RID
4.4.4.4
R3
R2
R1
348 Chapter 11: BGP
Example 11-1 Basic iBGP Configuration of Neighbors
! R1 Config—R1 correctly sets its update-source to 1.1.1.1 for both R2 and R3,
! in order to match the R2 and R3 neighbor commands. The first three highlighted
! commands below were not typed, but added automatically as defaults by IOS 12.3
!—in fact, IOS 12.3 docs imply that the defaults of sync and auto-summary at
! IOS 12.2 has changed to no sync and no auto-summary as of IOS 12.3. Also, R1
! knows that neighbors 2.2.2.2 and 3.3.3.3 are iBGP because their remote-as values
! match R1’s router BGP command.
interface Loopback1
ip address 1.1.1.1 255.255.255.255
!
router bgp 123
no synchronization
bgp router-id 111.111.111.111
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 123
neighbor 2.2.2.2 update-source Loopback1
neighbor 3.3.3.3 remote-as 123
neighbor 3.3.3.3 password secret-pw
neighbor 3.3.3.3 update-source Loopback1
no auto-summary
! R3 Config—R3 uses a peer group called “my-as” for combining commands related
! to R1 and R2. Note that not all parameters must be in the peer group: R3-R2 does
! not use authentication, but R3-R1 does, so the neighbor password command was
! not placed inside the peer group, but instead on a neighbor 1.1.1.1 command.
interface Loopback1
ip address 3.3.3.3 255.255.255.255
!
router bgp 123
no synchronization
bgp log-neighbor-changes
neighbor my-as peer-group
neighbor my-as remote-as 123
neighbor my-as update-source Loopback1
neighbor 1.1.1.1 peer-group my-as
neighbor 1.1.1.1 password secret-pw
neighbor 2.2.2.2 peer-group my-as
no auto-summary
! Next, R1 has two established peers, but the fact that the status is “established”
! is implied by not having the state listed on the right side of the output, under
! the heading State/PfxRcd. Once established, that column lists the number of
! prefixes learned via BGP Updates received from each peer. Note also R1’s
! configured RID, and the fact that it is not used as the update source.
R1# show ip bgp summary
BGP router identifier 111.111.111.111, local AS number 123
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 123 59 59 0 0 0 00:56:52 0
3.3.3.3 4 123 64 64 0 0 0 00:11:14 0
A few features in Example 11-1 are particularly important. First, note that the configuration does
not overtly define peers as iBGP or eBGP. Instead, each router examines its own ASN as defined
on the router bgp command, and compares that value to the neighbor’s ASN listed in the
neighbor remote-as command. If they match, the peer is iBGP; if not, the peer is eBGP.
R3 in Example 11-1 shows how to use the peer-group construct to reduce the number of configuration
commands. BGP peer groups do not allow any new BGP configuration settings; they
simply allow you to group BGP neighbor configuration settings into a group, and then apply that
set of settings to a neighbor using the neighbor peer-group command. Additionally, BGP builds
one set of Update messages for the peer group, applying routing policies for the entire group—rather
than one router at a time—thereby reducing some BGP processing and memory overhead.