The most common reason for failing to establish either eBGP or iBGP neighbor relationships are due to misconfigurations. However, in addition to misconfigurations, the following factors can also prevent BGP adjacencies from establishing:
- Access Control Lists Filtering BGP Packets
- Layer 1 and Layer 2 Issues
- Device Resource Consumption
As with other routing protocols, ACLs can also prevent BGP neighbor adjacencies from being established. Given that BGP allows both internal and external peers to be more than one hop away, when configuring BGP between devices that are more than a single hop away, be sure that there are no ACLs on any intermediate devices that are preventing TCP packets. If any such ACLs exist, they should be modified to allow the BGP session, using TCP port 179, to be established between the desired peers. You can verify applied ACLs using the show ip access-lists or show running-config commands on local and intermediate devices.
Layer 1 and Layer 2 issues can also prevent BGP adjacencies from being established. You can check interface errors using the show interfaces and show counters interface commands. Layer 2 issues, such as VLANs and STP can be validated following the sequence of steps described in the previous chapters. Commands that can be used to troubleshoot such issues include the show vlan and show spanning-tree suite of commands.
And finally, it is important to remember that BGP itself is designed to support large amount of prefixes, which in turn equates to greater resource, e.g. memory, consumption than traditional routing protocols. Additionally, the more peers or neighbors that are configured, the more memory BGP will consume. If device resources are already over-taxed, it is possible that some BGP adjacencies may not be established. Use the show processes suite of commands to troubleshoot device resource utilization if you suspect that this may be preventing adjacencies.
In addition to the potential causes described above, common misconfigurations include:
- Using the Incorrect Autonomous System Number for the Peer
- Using the Incorrect IP Address for the Peer
- Incorrect Authentication Parameters
- No IP Connectivity between Indirectly Connected Peers
Using the Incorrect Autonomous System Number for the Peer
A common BGP misconfiguration is specifying the incorrect autonomous system number for the peer. If the neighbor [address] remote-as [autonomous system] command does not match the autonomous system number configured on the remote peer using the router bgp [autonomous system] command, the adjacency will not be established. Instead, the Cisco IOS software will print the following error message on the console:
| *Mar 12 16:58:29.991: %BGP-3-NOTIFICATION: sent to neighbor 10.0.0.1 2/2 (peer in wrong AS) 2 bytes 0001 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 002D 0104 0001 00B4 0101 0101 1002 0601 0400 0100 0102 0280 0002 0202 00 |
On the remote router, the following error message will be printed on the console:
| *Mar 19 04:58:09.535: %BGP-3-NOTIFICATION: received from neighbor 10.0.0.3 2/2 (peer in wrong AS) 2 bytes 0001 |
In such cases, the BGP speakers will remain in the active state, indicating that that they are both actively trying to establish a TCP session with the specified peer. This issue can be resolved by specifying the correct autonomous system number.
Using the Incorrect IP Address for the Peer
While specifying an incorrect autonomous system number for the peer will result in error messages being printed on the console, if you specify the incorrect IP address, no error messages will be printed. It is important to ensure that you double-check that the IP address that has been specified for the peer is indeed the IP address of that device.
If the peers are indirectly connected, i.e. will be peering using Loopback or other interfaces, then it is important to ensure that you specify the correct IP address. This address should match the address of the interface used in the update-source [interface] configuration command. In the event that these parameters are mismatched, the TCP session will never be established.
Incorrect Authentication Parameters
BGP supports Message Digest 5 authentication which is used to secure or verify the security of the TCP segments between two BGP peers. When the BGP TCP MD5 shared password is configured between two peers, the Cisco IOS software checks the MD5 digest of every segment sent on the TCP connection. If MD5 authentication is invoked and a segment fails authentication, then an error message will be displayed. The type of message printed varies depending on whether authentication is enabled on only one of the peers or whether both peers are configured for authentication but are using different passwords. In the event that authentication is configured on the local BGP speaker but not the peer, the following error message will be printed on the console of the local BGP speaker:
| *Mar 12 17:06:27.235: %TCP-6-BADAUTH: No MD5 digest from 1.0.0.1(179) to 1.0.0.3(46132) *Mar 12 17:06:27.239: %TCP-6-BADAUTH: No MD5 digest from 1.0.0.1(179) to 1.0.0.3(46132) |
However, if authentication is configured on both peers, but the passwords are mismatched:
| *Mar 12 17:08:56.243: %TCP-6-BADAUTH: Invalid MD5 digest from 1.0.0.1(52991) to 1.0.0.3(179) *Mar 12 17:09:04.243: %TCP-6-BADAUTH: Invalid MD5 digest from 1.0.0.1(52991) to 1.0.0.3(179) |
In order to resolve this issue, the same password must be used when configuring authentication between the BGP peers. This is applicable to both internal and external BGP peers.
No IP Connectivity between Indirectly Connected Peers
While configuring BGP between directly connected peers is a straightforward task, additional configuration is required to ensure that BGP adjacencies between indirectly configured peers establish. Consider the basic network topology that is illustrated in Figure 7-1 for example:
Figure 6-28 shows a basic network with two routers. R1 resides in AS 65001 and R2 resides in AS 2. The two routers have two physical point-to-point links between them. An eBGP session will be established between the routers using the Loopback addresses for peering:
Fig. 7-1. Understanding BGP Multihop Implementation
Referencing Figure 7-1, external BGP is to be configured between R1 and R2 using the Loopback interfaces of either router for peering, allowing for load balancing across the physical links. When implementing BGP is such situations, there are several additional configuration commands that are required. The first is the use of the ebgp-multihop command. By default, external BGP packets are sent out with an IP TTL of 1. The ebgp-multihop command allows administrators to modify this default behavior and specify the packet TTL value. If a value is not specified, the default TTL of 255 will be used instead.
The second is ensuring that there is IP connectivity between the Loopback interfaces. This may be performed using either dynamic or static routes; with the latter being the most commonly used method. Referencing the topology illustrated in Figure 7-1, two static routes can be configured between the routers across the Serial0/0 interfaces using the ip route [remote loopback address] [mask] serial [name/number] global configuration command.
The third requirement is specifying the update source. By default, BGP expects that the update source will be an IP address on a directly connected subnet. If the specified neighbor address is indirectly connected, e.g. a Loopback, then interface the update-source [interface] BGP configuration command must also be specified on both speakers. If any of these parameters are not specified, the adjacency will not be established. This can be validated using the show ip bgp neighbors [address] command as follows:
| R4#show ip bgp neighbors 3.3.3.3 BGP neighbor is 3.3.3.3, remote AS 3, external link BGP version 4, remote router ID 0.0.0.0 BGP state = Active Last read 00:00:14, last write 00:00:14, hold time is 180, keepalive interval is 60 seconds Message statistics: InQ depth is 0 OutQ depth is 0 Sent Rcvd Opens: 1 1 Notifications: 0 0 Updates: 0 0 Keepalives: 16 16 Route Refresh: 0 0 Total: 17 17 Default minimum time between advertisement runs is 30 secondsFor address family: IPv4 Unicast BGP table version 1, neighbor version 0/0 Output queue size : 0 Index 1, Offset 0, Mask 0x2 1 update-group member Sent Rcvd Prefix activity: —- —- Prefixes Current: 0 0 Prefixes Total: 0 0 Implicit Withdraw: 0 0 Explicit Withdraw: 0 0 Used as bestpath: n/a 0 Used as multipath: n/a 0Outbound Inbound Local Policy Denied Prefixes: ——– ——- Total: 0 0 Number of NLRIs in the update sent: max 0, min 0Connections established 1; dropped 1 Last reset 00:00:20, due to User reset External BGP neighbor may be up to 2 hops away. No active TCP connection |
From the output printed above, we can determine that the ebgp-multihop 2 command has been issued on the local router; however, the BGP session is not established. This leaves two possibilities: either the update-source command is missing or there is no IP connectivity between the two Loopback addresses. You can troubleshoot this issue by simply verifying the device configurations on both routers.
While Cisco IOS software assumes that external BGP peers are directly connected, the same is not assumed for internal BGP peers. This negates the need for the multihop command when configuring internal BGP peers. However, the peer IP addresses must still have connectivity and the update-source command must still be used. If this command is not specified, the BGP session will never establish as can be seen in the following output:
| R4#show ip bgp neighbors 3.3.3.3 BGP neighbor is 3.3.3.3, remote AS 3, internal link BGP version 4, remote router ID 0.0.0.0 BGP state = Active Last read 00:02:50, last write 00:02:50, hold time is 180, keepalive interval is 60 seconds Message statistics: InQ depth is 0 OutQ depth is 0 Sent Rcvd Opens: 0 0 Notifications: 0 0 Updates: 0 0 Keepalives: 0 0 Route Refresh: 0 0 Total: 0 0 Default minimum time between advertisement runs is 0 secondsFor address family: IPv4 Unicast BGP table version 1, neighbor version 0/0 Output queue size : 0 Index 1, Offset 0, Mask 0x2 1 update-group member Sent Rcvd Prefix activity: —- —- Prefixes Current: 0 0 Prefixes Total: 0 0 Implicit Withdraw: 0 0 Explicit Withdraw: 0 0 Used as bestpath: n/a 0 Used as multipath: n/a 0Outbound Inbound Local Policy Denied Prefixes: ——– ——- Total: 0 0 Number of NLRIs in the update sent: max 0, min 0Connections established 0; dropped 0 Last reset never No active TCP connection |