Content

| 5.9 |  | Troubleshooting BGP |
| 5.9.1 |  | Troubleshooting BGP neighbor relationships |

Troubleshooting neighbor relationship issues should follow the OSI reference model. First, Layer 1/2 should be checked, followed by IP connectivity (Layer 3), TCP connections (Layer 4), and finally the BGP configuration. 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 Loobback 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.