Lesson Contents
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 advertisem*nts.
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 1BGP table version is 1, main routing table version 1Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd192.168.12.2 4 2 8 8 0 0 0 00:00:06 ActiveR2#show ip bgp summary BGP router identifier 192.168.12.2, local AS number 2BGP table version is 1, main routing table version 1Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd192.168.12.1 4 1 8 8 0 0 0 00:00:59 ActiveWhen 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.2Type 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 briefInterface IP-Address OK? Method Status ProtocolFastEthernet0/0 192.168.12.1 YES manual up upR2#show ip int briefInterface IP-Address OK? Method Status ProtocolFastEthernet0/0 192.168.12.2 YES manual administratively down downWe’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/0R2(config-if)#no shutdownAfter enabling the interface you should see this:
R1# %BGP-5-ADJCHANGE: neighbor 192.168.12.2 UpR2# %BGP-5-ADJCHANGE: neighbor 192.168.12.1 UpThat’s what we like to see. Our BGP neighbor adjacency is established…
Lesson learned: Make sure your interfaces are up and running.
EBGP Requirements
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 bgprouter bgp 1 no synchronization bgp log-neighbor-changes neighbor 2.2.2.2 remote-as 2 no auto-summaryR2#show run | section bgprouter bgp 2 no synchronization bgp log-neighbor-changes neighbor 1.1.1.1 remote-as 1 no auto-summaryHere’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 1BGP table version is 1, main routing table version 1Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd2.2.2.2 4 2 0 0 0 0 0 never IdleR2#show ip bgp summary BGP router identifier 192.168.12.2, local AS number 2BGP table version is 1, main routing table version 1Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd1.1.1.1 4 1 0 0 0 0 0 never IdleBoth 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/0R2#show ip routeC 192.168.12.0/24 is directly connected, FastEthernet0/0Both 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 2.2.2.2 255.255.255.255 192.168.12.2R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1Two static routes should do the job. Let’s give it a try:
R1#ping 2.2.2.2 source loopback 0Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:Packet sent with a source address of 1.1.1.1 !!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 msSending a ping to IP address 2.2.2.2 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 2.2.2.2 ebgp-multihop 2R2(config-router)#neighbor 1.1.1.1 ebgp-multihop 2The 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 UnicastBGPNSF state: 1.1.1.1 went from nsf_not_active to nsf_not_activeBGP: 1.1.1.1 went from Active to IdleBGP: 1.1.1.1 went from Idle to ActiveBGP: 1.1.1.1 open active delayed 31810ms (35000ms max, 28% jitter)BGP: 1.1.1.1 open active, local address 192.168.12.2BGP: 1.1.1.1 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 2.2.2.2 update-source loopback 0R2(config-router)#neighbor 1.1.1.1 update-source loopback 0Use 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 2.2.2.2 UpR2#%BGP-5-ADJCHANGE: neighbor 1.1.1.1 UpThere 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 bgprouter bgp 1 no synchronization bgp log-neighbor-changes neighbor 192.168.12.2 remote-as 1 no auto-summaryR2#show run | section bgprouter bgp 1 no synchronization bgp log-neighbor-changes neighbor 192.168.12.1 remote-as 1 no auto-summaryPlain and simple. The routers use the directly connected IP addresses for the BGP neighbor adjacency. Let’see if we have neighbors:
