Neighbor Relationships

BGP requires a neighbor relationship to be established before any information is exchanged between BGP speakers . BGP does not dynamically discover routers interested in running BGP; instead, BGP is configured with a specific neighbor IP address.

Like most other dynamic protocols, BGP uses periodic keepalive messages to ensure availability of BGP neighbors.

The keepalive timer is one third of the holdtime. If three consecutive keepalive messages are missed from a particular BGP neighbor, the holdtime expires and that neighbor is considered dead. In RFC 1771, the suggested value for the holdtime is 90 seconds, and the suggested value for the keepalive timer is 30 seconds. These values are negotiated between BGP neighbors when the neighbors first come up. RFC 1771 also requires that "an implementation of BGP must allow these timers to be configurable."

When BGP is configured with a neighbor IP address, it goes through a series of stages before it reaches the desired Established state in which BGP has negotiated all the required parameters and is willing to exchange BGP routes. BGP goes through the following stages of neighbor relationship, per RFC 1771:

1. Idle ‚ No BGP resources are allocated in Idle state, and no incoming BGP connections are allowed.

2. Connect ‚ BGP waits for a TCP connection to be completed. If successful, the BGP state machine moves into OpenSent state after sending the OPEN message to the peer. Failure in this state could result in either going into Active state or Connect state, or reverting back to Idle state, depending on the failure reasons.

3. Active ‚ In this state, a TCP connection is initiated to establish a BGP peer relationship. If successful, BGP sends its OPEN message to the peer and moves to OpenSent state. Failure can result in going to the Active or Idle states.

4. OpenSent ‚ After sending an OPEN message to the peer, BGP waits in this state for the OPEN reply.

   If a successful reply comes in, the BGP state moves to OpenConfirm and a keepalive is sent to the peer. Failure can result in sending the BGP state back to Idle or Active.

5. OpenConfirm ‚ The BGP state machine is one step away from reaching its final state (Established).

   BGP waits in this state for keepalives from the peer. If successful, the state moves to Established; otherwise , the state moves back to Idle based on the errors.

6. Established ‚ This is the state in which BGP can exchange information between the peers. The information can be updates, keepalives, or notification.

Figure 14-2 highlights a simple BGP state machine that runs while BGP is in operation. Some details are left out for simplicity. Refer to RFC 1771 for a more detailed examination of the BGP state machine operation.

Figure 14-2. BGP State Machine

External BGP Neighbor Relationships

This section explains a sample configuration of EBGP sessions. In Figure 14-3, R1 and R2 belong to different autonomous systems ‚ 109 and 110, respectively.

Figure 14-3. External BGP Neighbor Relationship Example

There are two ways to configure when peering EBGP:

• Case 1 ‚ R1 and R2 are peering with a physical interface.

• Case 2 ‚ R1 and R2 are indirectly connected or they are peering with each other's loopback interfaces.

The peering relationship with R1 and R2 in Case 1 means that the R1 peering IP address is in the same subnet as its own physical interface.

The configuration for this case is as follows :

 R1#:  router bgp 109   neighbor 131.108.1.2 remote-as 110  

R1 in Figure 14-3 has an interface with an IP address of 131.108.1.1.

Figure 14-4 shows two scenarios of multihop EBGP sessions indicative of the peering relationship in Case 2. In this figure, EBGP peering between R1 and R2 is done with each other's loopback addresses. This is typically seen when multiple connections exist between the two autonomous systems and both links should carry traffic. Either each AS runs two separate BGP neighbor relationships on two separate physical interfaces, or they can configure one BGP neighbor to the loopback and configure two static routes to reach each other's loopback. The latter method is preferable because it saves an extra BGP neighbor relationship.

Figure 14-4. EBGP Peering Relationship Through Loopback Interfaces

In Figure 14-5, R3 in AS 110 might not be capable of running BGP, so R1 and R2 must peer with each going through R3.

Figure 14-5. EBGP Peering Relationship Through a Third-Party Router

In both cases of Figure 14-4 and Figure 14-5, it is assumed that all routers have reachability to R1 and R2's loopback addresses.

Loopback addresses are used because they are virtual interfaces and they never go down like physical interfaces do. Even if one physical interface goes down, BGP between loopbacks remains up as long as they exist as redundant paths to each other's loopbacks.

Example 14-1 shows a sample configuration of R1 to configure multihop EBGP session.

Example 14-1 Sample Configuration of R1 to Show Multihop EBGP Session

 R1#: router bgp 109   neighbor 131.108.10.2 remote-as 110  neighbor 131.108.10.2  ebgp-multihop 5  neighbor 131.108.10.2  update-source Loopback0  

ebgp-multihop 5 means that neighbor 131.108.10.2 can be only five hops away from R1, and the Time To Live (TTL) field in the IP header is set to 5.

update-source Loopback0 means that all BGP updates are sourced from the Loopback 0 address of R1. R2 uses 131.108.10.1 as the next -hop address for all routes learned through R1.

Internal BGP Neighbor Relationships

Assume that R1 and R2 belong to the same AS, 109, as shown in Figure 14-6.

Figure 14-6. Internal BGP Neighbor Relationship Example

If R1 and R2 are IBGP neighbors, meaning that they are BGP neighbors in the same AS, the configuration cases can be any of the following:

• Case 1 ‚ R1 and R2 are peering with a physical interface of each other, and peering is done with the IP address that belongs to the subnet that they both share. The configuration of R1 is as follows:

    router bgp 109   neighbor 131.108.1.2 remote-as 109  

• Case 2 ‚ R1 and R2 are either indirectly connected or they are peering with each other's loopback interfaces. The configuration of R1 is as follows:

    router bgp 109   neighbor 131.108.10.2 remote-as 109   neighbor 131.108.10.2 update-source Loopback0  

NOTE

The neighbor 131.108.10.2 ebgp-multihop command is not needed. In cases of IBGP, the TTL in the IP header is set to 255 in Cisco IOS Software because it is assumed that IBGP neighbors might not be physically directly connected. In addition, an IBGP neighbor relationship can also be established between loopback addresses that are considered a multihop away from each other. In case of a physical failure in the network, IBGP can use alternate physical paths, if they exist, to reach the loopback of the BGP neighbor. This way, IBGP remains intact, even in the case of physical failures along the way.