Problem: Directly Connected External BGP Neighbors Not Initializing

This section discusses issues when a directly connected EBGP neighbor relationship is unsuccessful . 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, as described in Chapter 14, "Understanding Border Gateway Protocol Version 4 (BGP-4)." 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 15-1 shows a network in which an external BGP neighbor relationship is configured between AS 109 and AS 110.

Figure 15-1. External BGP Neighbor Relationship

The most common possible causes of this problem are as follows :

• Layer 2 is down, preventing communication with a directly connected EBGP neighbor.

• An incorrect neighbor IP address is in the BGP configuration.

Directly Connected External BGP Neighbors Not Coming Up ‚ Cause: Layer 2 Is Down, Preventing Communication with Directly Connected BGP Neighbor

IP connectivity cannot occur until Layer 2 in the OSI reference model is up. Whether this Layer 2 information is learned dynamically or is configured statically, each router must have a correct Layer 2 rewrite information of adjacent routers. Ethernet, Frame Relay, ATM, and so on are most commonly used Layer 2 technologies. Most network administrators configure Layer 2 parameters in router configurations correctly; sometimes, basic cabling issues also can cause Layer 2 issues. Among cabling issues, misconfiguration in router configuration can cause ARP, DLCI mapping, and VPI/VIC encapsulation failures, which are the most common Layer 2 failures. It is beyond the scope of this book to address how this Layer 2 information is obtained. Case(s) in this section try to address how to troubleshoot BGP problems when the cause of the EBGP neighbor relationship failure is Layer 2.

Figure 15-2 shows the flowchart to follow to fix this problem.

Figure 15-2. Problem-Resolution Flowchart

Debugs and Verification

Example 15-1 shows the relevant configuration of R1 and R2, respectively.

Example 15-1 R1 and R2 Configuration

 R1#  router bgp 109   neighbor 131.108.1.2 remote-as 110   interface Ethernet0   ip address 131.108.1.1 255.255.255.0  _____________________________________________________________________________________ R2#  router bgp 110   neighbor 131.108.1.1 remote-as 109   interface Ethernet0  ip address 131.108.1.2 255.255.255.0 

You can verify the BGP neighbor relationship on Cisco IOS Software by using the commands in Example 15-2.

Example 15-2 Verifying BGP Neighbor Relationship

 R1#  show ip bgp summary  BGP router identifier 206.56.89.6, local AS number 109 BGP table version is 1, main routing table version 1 Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd 131.108.1.2     4   110       3       7        0    0    0 00:03:14  Active  R1#  show ip bgp neighbors 131.108.1.2  BGP neighbor is 131.108.1.2,  remote AS 110, external link   BGP version 4, remote router ID 0.0.0.0  BGP state = Active  Last read 00:04:23, hold time is 180, keepalive interval is 60 seconds   Received 3 messages, 0 notifications, 0 in queue   Sent 7 messages, 1 notifications, 0 in queue   Route refresh request: received 0, sent 0   Minimum time between advertisement runs is 30 seconds  For address family: IPv4 Unicast   BGP table version 1, neighbor version 0   Index 1, Offset 0, Mask 0x2   0 accepted prefixes consume 0 bytes   Prefix advertised 0, suppressed 0, withdrawn 0   Connections established 1; dropped 1   Last reset 00:04:44, due to BGP Notification sent, hold time expired  No active TCP connection  

The output in Example 15-2 shows that the BGP neighbor is in the Active state. This state indicates that no successful communication between the neighbors has taken place and that BGP has failed to form neighbor relationship.

You can use ping to verify IP connectivity between R1 and R2. Example 15-3 shows that R1 cannot ping R2's IP address.

Example 15-3 R1 Ping of R2's IP Address Fails

 R1#  ping 131.108.1.2  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 131.108.1.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) 

Solution

In this example, the ping failure from R1 to R2 was the result of Layer 2 on R2 being down. Example 15-4 shows the output indicating a Layer 2 problem.

Example 15-4 show interface Command Output Pinpoints That This Is a Layer 2 Problem

 R2#  show interface ethernet 0  Ethernet0 is down, line protocol is down 

This might be because of cable issues or a hardware problem.

Apart from the interface being down, as in Example 15-4, Layer 2 encapsulation failure can also cause IP connectivity to break. Layer 2 encapsulation failure can occur because of corruption in the ARP table in case of Ethernet or an incorrect DLCI ‚ VPI/VCI mapping in cases of Frame Relay and ATM, respectively. Fixing these should enable basic IP connectivity, and the BGP neighbor relationship should initialize.

Directly Connected External BGP Neighbors Not Coming Up ‚ Cause: Incorrect Neighbor IP Address in BGP Configuration

Figure 15-3 shows the flowchart to follow to fix this problem.

Figure 15-3. Problem-Resolution Flowchart

Debugs and Verification

Example 15-5 shows the relevant configuration of R1 and R2, respectively.

Example 15-5 R1 and R2 Configuration

 R1#  router bgp 109   neighbor 131.108.1.2 remote-as 110   interface Ethernet0   ip address 131.108.1.1 255.255.255.0  _____________________________________________________________________________________ R2#  router bgp 110   neighbor    131.108.1.11    remote-as 109   interface Ethernet0  ip address 131.108.1.2 255.255.255.0 

Misconfiguration of the neighbor address is a fairly common mistake, and it can be caught with visual inspection of the configuration. However, in a large IP network, this might not be a trivial task. Example 15-6 shows how to capture this mistake using debugs in Cisco IOS Software.

Example 15-6 debug ip bgp Command Output Helps Pinpoint Incorrectly Configured Neighbor Addresses

 R2#  debug ip bgp  BGP debugging is on R2# Nov 28 13:25:12: BGP: 131.108.1.11 open active, local address 131.108.1.2 Nov 28 13:25:42: BGP: 131.108.1.11 open failed: Connection timed out; remote host         not responding 

The output in Example 15-6 clearly points out that R2 is having difficulty communicating with host 131.108.1.11.

Solution

The correct neighbor address should be configured when establishing BGP neighbor relationship. Therefore, R2's BGP configuration must look like Example 15-7.

Example 15-7 Correcting R2's BGP Configuration

 R2#  router bgp 110  neighbor 131.108.1.1 remote-as 109 

A similar problem can occur when the incorrect AS number is configured.