External BGP Neighbors
The physical topology between eBGP peers is often a single link, mainly because the connection
is between different companies in different autonomous systems. As a result, eBGP peering can
simply use the interface IP addresses for redundancy, because if the link fails, the TCP connection
will fail because there is no longer an IP route between the peers. For instance, in Figure 11-2, the
R1-R6 eBGP peering uses interface IP addresses defined in the neighbor commands.
When IP redundancy exists between two eBGP peers, the eBGP neighbor commands should use
loopback IP addresses to take advantage of that redundancy. For example, two parallel links exist
between R3 and R4. With neighbor commands that reference loopback addresses, either of
these links could fail, but the TCP connection would remain. Example 11-2 shows additional
configuration for the network in Figure 11-2, showing the use of loopbacks between R3 and R4,
and interface addresses between R1 and R6.
Example 11-2 Basic eBGP Configuration of Neighbors
! R1 Config—This example shows only commands added since Example 11-1.
router bgp 123
neighbor 172.16.16.6 remote-as 678
! R1 does not have a neighbor 172.16.16.6 update-source command configured. R1
! uses its s0/0/0.6 IP address, 172.16.16.1, because R1’s route to 172.16.16.6
! uses s0/0/0.6 as the outgoing interface, as seen below.
R1# show ip route 172.1.16.6
Routing entry for 172.16.16.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via Serial0/0/0.6
Route metric is 0, traffic share count is 1
R1# show ip int brief | include 0/0/0.6
Serial0/0/0.6 172.16.16.1 YES manual up
350 Chapter 11: BGP
The eBGP configurations differ from iBGP configuration in a couple of small ways. First, the
neighbor remote-as commands refer to a different AS than does the router bgp command, which
implies that the peer is an eBGP peer. Second, R3 had to configure the neighbor 4.4.4.4 ebgpmultihop
2 command (and R4 with a similar command) or the peer connection would not have
formed. For eBGP connections, Cisco IOS defaults the IP packet’s TTL field to a value of 1, based
on the assumption that the interface IP addresses will be used for peering (like R1-R6 in Example 11-2).
In this example, if R3 had not used multihop, it would have sent packets to R4 with TTL 1.
R4 would have received the packet (TTL 1 at that point), then attempt to route the packet to its
loopback interface—a process that would decrement the TTL to 0, causing R4 to drop the packet.
So, even though the router is only one hop away, think of the loopback as being on the other side
of the router, requiring that extra hop.
Checks Before Becoming BGP Neighbors
Similar to IGPs, BGP checks certain requirements before another router may become a neighbor,
reaching the BGP established state. Most of the settings are straightforward; the only tricky part
relates to the use of IP addresses. The following list describes the checks that BGP performs when
forming neighbor relationships:
1. The router must receive a TCP connection request with a source address that the router finds
in a BGP neighbor command.
! R3 Config—Because R3 refers to R4’s loopback (4.4.4.4), and R4 is an eBGP
! peer, R3 and R4 have added the neighbor ebgp-multihop command to set TTL to 2.
! R3’s update source must be identified as its loopback in order to match
! R4’s neighbor 3.3.3.3 commands.
router bgp 123
neighbor 4.4.4.4 remote-as 45
neighbor 4.4.4.4 update-source loopback1
neighbor 4.4.4.4 ebgp-multihop 2
! R3 now has three working neighbors. Also note the three TCP connections, one for
! each BGP peer. Note that because R3 is listed using a dynamic port number, and
! R4 as using port 179, R3 actually initiated the TCP connection to R4.
R3# show ip bgp summary
BGP router identifier 3.3.3.3, 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
1.1.1.1 4 123 247 247 0 0 0 03:14:49 0
2.2.2.2 4 123 263 263 0 0 0 03:15:07 0
4.4.4.4 4 45 17 17 0 0 0 00:00:11 0
R3# show tcp brief
TCB Local Address Foreign Address (state)
649DD08C 3.3.3.3.179 2.2.2.2.43521 ESTAB
649DD550 3.3.3.3.179 1.1.1.1.27222 ESTAB
647D928C 3.3.3.3.21449 4.4.4.4.179 ESTAB
Example 11-2 Basic eBGP Configuration of Neighbors (Continued)
Building BGP Neighbor Relationships 351
2. A router’s ASN (on the router bgp asn command) must match the neighboring router’s
reference to that ASN with its neighbor remote-as asn command. (This requirement is not
true of confederation configurations.)
3. The BGP RIDs of the two routers must not be the same.
4. If configured, MD5 authentication must pass.
Figure 11-3 shows the first three items in the list graphically, with R3 initiating a BGP TCP
connection to R1. The circled numbers 1, 2, and 3 in the figure correspond to the item numbers in
the previous list. Note that R1’s check at Step 2 uses the neighbor command R1 identified as part
of Step 1.
Figure 11-3 BGP Neighbor Parameter Checking
In Figure 11-3, R3 initiates a TCP connection with its update source IP address (3.3.3.3) as the
source address of the packet. The first check occurs when R1 receives the first packet, looks at the
source IP address of the packet (3.3.3.3), and finds that address in a neighbor command. The
second check has R1 comparing R3’s stated ASN (in R3’s BGP Open message) to R1’s neighbor
command it identified at Step 1. Step 3 checks to ensure the BGP RIDs are unique, with the BGP
Open message stating the sender’s BGP RID.
While the check at Step 1 might seem intuitive, interestingly, the reverse bit of logic does not have
to be true for the neighbors to come up. For instance, if R1 did not have a neighbor 3.3.3.3
update-source 1.1.1.1 command, the process shown in Figure 11-3 would still work. Succinctly
put, only one of the two routers’ update source IP addresses needs to be in the other router’s
neighbor command for the neighbor to come up. Examples 11-1 and 11-2 showed the correct
update source on both routers, and that makes good sense, but it works with only one of the two.
R3 R1
RID
3.3.3.3
BGP Open
Message
RID
111.111.111.111
Note: R3’s Loopback IP Address is 3.3.3.3
Src.-IP
3.3.3.3
Dest.-IP
1.1.1.1
Dest.-Port
179
Syn
RID
3.3.3.3
ASN
123
TCP Reply (SYN, ACK)
TCP Connection Up (ACK)
router bgp 123
neigh 1.1.1.1 update-source loopback1
neigh 1.1.1.1 remote-as 123 neighbor 3.3.3.3 remote-as 123
1
2
3
BGP uses a keepalive timer to define how often that router sends BGP keepalive messages, and a
Hold timer to define how long a router will wait without receiving a keepalive message before
resetting a neighbor connection. The Open message includes each router’s stated keepalive timer.
If they do not match, each router uses the lower of the values for each of the two timers,
respectively. Mismatched settings do not prevent the routers from becoming neighbors.