BGP is a complex routing protocol and there are quite some things that could go possibly wrong. Besides being complex it’s also completely different compared to our IGPs (OSPF and EIGRP). In this lesson we’ll start with troubleshooting BGP neighbor adjacencies. Once the neighbor adjacency is working, you can focus on troubleshooting missing route advertisements.
Key to troubleshooting BGP is understanding how BGP forms a neighbor adjacency. If you are unsure how this process works exactly you might want to check my lesson about BGP states first before you continue. Having said that, let’s look at some scenarios.
BGP Interface Issues
Here’s the first topology:
Two BGP routers which are connected and configured for EBGP. Unfortunately we are seeing this when check the BGP neighbor adjacency:
R1#show ip bgp summary BGP router identifier 192.168.12.1, local AS number 1 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.12.2 4 2 8 8 0 0 0 00:00:06 Active
R2#show ip bgp summary BGP router identifier 192.168.12.2, local AS number 2 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 192.168.12.1 4 1 8 8 0 0 0 00:00:59 Active
When two EBGP routers that are directly connected do not form a working BGP neighbor adjacency there could be a number of things that are wrong:
- Layer 2 down preventing us from reaching the other side.
- Layer 3 issue: wrong IP address on one of the routers.
- Access-list blocking TCP port 179 (BGP).
- Wrong IP address configured for BGP neighbor router.
The IP addresses that were used for the neighbor adjacency look OK so something else might be the issue. Let’s try a quick ping:
R1#ping 192.168.12.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
I can do a quick ping and I’ll see that I’m unable to reach the other side. Since layer 3 isn’t working, let’s take a look at layer 1 and 2:
R1#show ip int brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 192.168.12.1 YES manual up up
R2#show ip int brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 192.168.12.2 YES manual administratively down down
We’ll check the interfaces and find out that someone left a shutdown command on the interface…let’s fix it:
R2(config)#interface FastEthernet 0/0 R2(config-if)#no shutdown
After enabling the interface you should see this:
R1# %BGP-5-ADJCHANGE: neighbor 192.168.12.2 Up
R2# %BGP-5-ADJCHANGE: neighbor 192.168.12.1 Up
That’s what we like to see. Our BGP neighbor adjacency is established…
Lesson learned: Make sure your interfaces are up and running.
Same topology but another issue. The goal in this scenario is to establish the EBGP neighbor adjacency between the IP addresses on the loopback interfaces.
Let me show you what the BGP configuration looks like:
R1#show run | section bgp router bgp 1 no synchronization bgp log-neighbor-changes neighbor 18.104.22.168 remote-as 2 no auto-summary
R2#show run | section bgp router bgp 2 no synchronization bgp log-neighbor-changes neighbor 22.214.171.124 remote-as 1 no auto-summary
Here’s the BGP configuration, you can see that we are using the loopback interfaces to establish a BGP neighbor adjacency. There’s no BGP neighbor adjacency:
R1#show ip bgp summary BGP router identifier 192.168.12.1, local AS number 1 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 126.96.36.199 4 2 0 0 0 0 0 never Idle
R2#show ip bgp summary BGP router identifier 192.168.12.2, local AS number 2 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 188.8.131.52 4 1 0 0 0 0 0 never Idle
Both routers show their BGP neighbor as idle. There are a number of things we have to check here:
- Is the IP address of the BGP neighbor reachable? We are not using the directly connected links so we might have routing issues.
- The TTL of IP packets that we use for external BGP is 1. This works for directly connected networks but if it’s not directly connected we need to change this behavior.
- By default BGP will source its updates from the IP address that is closest to the BGP neighbor. In our example that’s the FastEthernet interface. This is something we’ll have to change.
Let’s check if the IP address of the remote neighbor is reachable, take a look at the routing tables:
R1#show ip route C 192.168.12.0/24 is directly connected, FastEthernet0/0
R2#show ip route C 192.168.12.0/24 is directly connected, FastEthernet0/0
Both routers only know about their directly connected networks. In order to reach each other’s loopback interfaces we’ll use static routing:
R1(config)#ip route 184.108.40.206 255.255.255.255 192.168.12.2
R2(config)#ip route 220.127.116.11 255.255.255.255 192.168.12.1
Two static routes should do the job. Let’s give it a try:
R1#ping 18.104.22.168 source loopback 0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 22.214.171.124, timeout is 2 seconds: Packet sent with a source address of 126.96.36.199 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
Sending a ping to IP address 188.8.131.52 and sourcing it from my own loopback interface proves that both routers know how to reach each other’s loopback interface. Since we don’t use the directly connected interfaces for the peering, we also have to increase the TTL:
R1(config-router)#neighbor 184.108.40.206 ebgp-multihop 2
R2(config-router)#neighbor 220.127.116.11 ebgp-multihop 2
The ebgp-multihop command changes the TTL to 2. Now take a look at a debug:
R2#debug ip bgp BGP debugging is on for address family: IPv4 Unicast BGPNSF state: 18.104.22.168 went from nsf_not_active to nsf_not_active BGP: 22.214.171.124 went from Active to Idle BGP: 126.96.36.199 went from Idle to Active BGP: 188.8.131.52 open active delayed 31810ms (35000ms max, 28% jitter) BGP: 184.108.40.206 open active, local address 192.168.12.2 BGP: 220.127.116.11 open failed: Connection refused by remote host, open active delayed 34480ms (35000ms max, 28% jitter)
We can enable a debug to see the progress. You can clearly see that R2 is using IP address 192.168.12.2 and that R1 is refusing the connection. This is because we use the wrong source IP address. We have to tell BGP to use another IP address:
R1(config-router)#neighbor 18.104.22.168 update-source loopback 0
R2(config-router)#neighbor 22.214.171.124 update-source loopback 0
Use the update-source command to change the source IP address for the BGP updates. After making these changes, the problem should be fixed:
R1# %BGP-5-ADJCHANGE: neighbor 126.96.36.199 Up
R2# %BGP-5-ADJCHANGE: neighbor 188.8.131.52 Up
There goes! A working BGP neighbor adjacency.
Lesson learned: BGP routers don’t have to establish a neighbor adjacency using the directly connected interfaces. Make sure the BGP routers can reach each other, that BGP packets are sourced from the correct interface and in case of EBGP don’t forget to use the multihop command.
BGP TCP Port Filtering
Let’s take a look at an IBGP issue:
Two routers in the same AS and here’s the configuration:
R1#show run | section bgp router bgp 1 no synchronization bgp log-neighbor-changes neighbor 192.168.12.2 remote-as 1 no auto-summary
R2#show run | section bgp router bgp 1 no synchronization bgp log-neighbor-changes neighbor 192.168.12.1 remote-as 1 no auto-summary
Plain and simple. The routers use the directly connected IP addresses for the BGP neighbor adjacency. Let’see if we have neighbors: