Troubleshooting BGP Neighbor Adjacency

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:

BGP R1 R2 AS1 AS2 EBGP

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.

EBGP Requirements

BGP R1 R2 AS1 AS2 EBGP

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 2.2.2.2 remote-as 2
 no auto-summary
R2#show run | section bgp
router bgp 2
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 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
2.2.2.2         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
1.1.1.1         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 2.2.2.2 255.255.255.255 192.168.12.2
R2(config)#ip route 1.1.1.1 255.255.255.255 192.168.12.1

Two static routes should do the job. Let’s give it a try:

R1#ping 2.2.2.2 source loopback 0

Type 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 ms

Sending 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 2
R2(config-router)#neighbor 1.1.1.1 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: 1.1.1.1 went from nsf_not_active to nsf_not_active
BGP: 1.1.1.1 went from Active to Idle
BGP: 1.1.1.1 went from Idle to Active
BGP: 1.1.1.1 open active delayed 31810ms (35000ms max, 28% jitter)
BGP: 1.1.1.1 open active, local address 192.168.12.2
BGP: 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 0
R2(config-router)#neighbor 1.1.1.1 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 2.2.2.2 Up
R2#
%BGP-5-ADJCHANGE: neighbor 1.1.1.1 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:

R1 R2 IBGP AS 1

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:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 662 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

515 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Hi Rene

    Thank you for great article. I had a question though.
    Why didn’t R1 enter connect state and instead shifted to Active straight from idle? On the other hand i see R2 did enter connect state?

    thanks
    Kandhla

  2. Hei Rene,
    Thanks for the lesson, in my working experience, i am stuck in a situation for 2 sites. i have the ebgp peering up, but i am receiving 0 prefix from my isp. The isp said when they show ip bgp nei adverticed route that are hundreds of routes advertised, they can receive our route. Any good debug command to troule should this? We have plain bgp config, the same config (different peering ip though) is working with other sites.

    One interesting thing is that when i ping the isp with mtu 1500 it does not work, but it works with 1496. After reading cisco doc

    ... Continue reading in our forum

  3. Hi Jie,

    It’s possible that the MTU is causing your issue. Your ISP might be sending BGP updates of 1500 bytes which are dropped on your end. Here’s the default TCP segment size that is used for BGP:

    R1#show ip bgp neighbors 192.168.12.2 | include segment
    Maximum output segment queue size: 50
    Datagrams (max data segment is 1460 bytes):
    

    The segment size is 1460 bytes, add a TCP header (20 bytes) and IP header (20 bytes) and you have a 1500 byte packet. In other words, you should be able to send/receive up to 1500 bytes which is not possible at the moment.

    There’

    ... Continue reading in our forum

  4. OMG RENE! your FSM Diagram is so easy to understand.

    I bought this book called Routing TCP/IP, Volume II: CCIE Professional Development 2
    Great book but they have very complex descriptions on some things let me show you their chart lol… your chart below nocked it out of the ball park. don’t get me wrong that’s a great book but its hard as hex to understand and works better when paired with something like your website which can break it down in simple terms. I just had to laugh over the two diagrams though as yours was so easy to understand lol…

    //cdn-f

    ... Continue reading in our forum

  5. Hello Pinki

    It is possible to apply load balancing in BGP. BGP will not perform Equal Cost Multi-Path (ECMP) routing by default but it can be configured to do so. Specifically, you can use BGP multipath load sharing. You can see how to configure eBGP and iBGP to use more than one path in the following lesson:

    ... Continue reading in our forum

15 more replies! Ask a question or join the discussion by visiting our Community Forum