In previous articles, we have learned how to face OSPF and EIGRP routing issues. If you haven’t already, please check out my previous articles. It is a very challenging and responsible task to maintain Border Gateway Protocol (BGP) properly because we have to deal with external routing; if any breakdown occurs it should be resolved quickly.

Let’s have a quick look at functionalities and properties of BGP.

BGP is an Exterior Gateway Protocol (EGP) used for routing between autonomous systems. TCP port 179 is used to establish session and BGP neighbors are not discovered; rather, they must be configured manually so we have to configure unicast routing using “neighbor command” on both sides.

We can use BGP in the following conditions:

  • Customer connected to multiple Internet service providers (ISPs).
  • Service provider networks (transit autonomous system).
  • In very large enterprise networks, where we can use BGP at core layer as a redundant routing protocol.

Common Neighbor Stability Problems of BGP:

  • Misconfigured neighbor’s IP address and AS number.
  • Reachability issues when interfaces other than directly connected interfaces are used while peering (update-source issue).
  • Authentication must be properly implemented (if configured).
  • Router ID must be unique.

BGP often stuck in idle or active state; some common issues are described below.

For the IDLE state, common issues are:

  • TCP port 179 is not open.
  • Misconfigured Peer address under BGP.
  • Misconfigured AS number under BGP (remote-as).
  • BGP misconfiguration for peers.

For the ACTIVE state, common issues are:

  • TCP connection is initiated and it is in ACTIVE state; Retry to establish TCP session.
  • Peer address configured is not directly connected interface (Missing update-source command).
  • Network congestion, so TCP is unable to establish session.
  • Interface flapping.

To resolve most common BGP routing issues I have designed a GNS3 Lab which is posted here for your hands-on practice so that you can start the implementation or trouble-shooting as per the described objective. You will also find a solution file so that you can tally your configuration.


In this GNS3 lab (as shown in Fig. 1), you will begin with preloaded configuration scripts on each of the routers. These scripts contain errors that will prevent end-to-end communication across the network, especially between Router LA and NY. This means you have to establish communication from to To achieve this task, you will need to troubleshoot each router to determine the configuration errors, and then use the appropriate commands to correct the configurations. When you have corrected all of the configuration errors, loopback on the router LA should be able to communicate with the loopback address of router NY, i.e.,, so at the end you should get a ping reply, as shown below:

LA# ping source

Sending 5, 100-byte ICMP Echos to, timeout is 2 seconds:
Packet sent with a source address of
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/126/168 ms

Learning Objectives of Working with GNS3 File:

Upon completion of this lab, you will be able to troubleshoot and resolve:

  • Next hop unchanged issue with BGP (for iBGP peers)
  • BGP split-horizon issues
  • BGP authentication issues
  • BGP neighborship stability issues
  • Router ID issue with BGP

You can also:

  • Gather information about the misconfigured portion of the network.
  • Analyze information to determine why communication is not possible.
  • Implement solutions to resolve network errors.

Download the GNS3 file and turn on all the devices. First we will check BGP peering using “sh ip bgp summary” on routers LA, WDC1, WDC2, WDC3, WDC4, WDC5 and NY. You will see that neighborship between WDC1–WDC4 ( to is in active state, as shown in Fig. 2.

But if you check the running configuration on routers WDC1 and WDC4, you will see that update-source command is missing from BGP configuration, as shown below:

router bgp 10
 no synchronization
 bgp log-neighbor-changes
 neighbor remote-as 10
 neighbor remote-as 20
 no auto-summary

So configure the update-source for respective neighbors using this command:

WDC1(config)#router bgp 10
WDC1(config-router)#neighbor update-source loopback 1

WDC4(config)#router bgp 10
WDC4(config-router)#neighbor update-source loopback 1

After configuring the above commands, your neighborship will comes up.

But on router WDC4, you will see the log messages of BAD Authentication for BGP neighbor, as shown below:

*Mar  1 00:04:49.731: %TCP-6-BADAUTH: No MD5 digest  from to
*Mar  1 00:04:49.871: %TCP-6-BADAUTH: No MD5 digest  from to

If you check the authentication parameters on both routers using “show run | section bgp,” you will find that router WDC4 is configured with password CISC0 instead of CISCO (which is configured on neighbor router NY).

Now you have all the BGP neighborships, as described in scenario, so you have won half of war with BGP. Now it’s time to check routing database and network reachability between BGP peers.

If you check the BGP database on routers WDC1 and WDC5, you will get on WDC1 and on WDC5 as best path but on router WDC4 you will find that you are getting both and but not best, as shown in Fig.3 . Why are both routes not best?

You can find the answer with next hop; if you closely look at the next hops, and, both are eBGP routes and we have not advertised or anywhere in BGP. That’s why both next hops are unreachable from WDC4, so the solution is to advertise on WDC1 under BGP and on WDC5 but this is not feasible solution to advertise eBGP networks.

A better and more feasible solution is to use “Next-hop-self” and you know very well when to use this command; if not, then the next line is for you.

To inject networks learned from eBGP peer to iBGP peer”

The next hop command is only for iBGP peers; now you can go to routers WDC1 and WDC5 to configure next-hop-self under BGP for router WDC4, as shown below:

                            WDC1(config-router)#neighbor next-hop-self
                            WDC5(config-router)#neighbor next-hop-self

Now if you check the BGP database on router WDC4 , you will get the result shown in Fig. 4.

Both networks are best, but you will not get on router WDC1 and on router WDC5 because of the BGP split-horizon rule, which says “Routes learned from iBGP peer will not be forwarded to other iBGP peer.” Feasible solutions of BGP split-horizon are:

  • * Route-reflector
  • * Confederation (sub-AS method)

The confederation method is not as popular as a solution of BGP split-horizon just because of its complex implementation and lack of flexibility for technology updating, whereas route reflector is a far better and more widely used solution for BGP split-horizon.

Route reflector is deployed over centralized routers in iBGP; as per our topology, WDC4 is a centralized router, so WDC4 will be configured as route reflector and WDC1-WDC5 will be router reflector clients so that WDC4 can exchange routing information with WDC1 and WDC2. You can use following commands to implement route reflector:

WDC4(config)#router bgp 10
WDC4(config-router)#neighbor route-reflector-client
WDC4(config-router)#neighbor route-reflector-client

Instantly you will get following log messages,

*Mar  1 01:19:59.099: %BGP-5-ADJCHANGE: neighbor Down RR client config change
*Mar  1 01:20:01.347: %BGP-5-ADJCHANGE: neighbor Up
*Mar  1 01:20:20.651: %BGP-5-ADJCHANGE: neighbor Down RR client config change
*Mar  1 01:20:22.931: %BGP-5-ADJCHANGE: neighbor Up

Now you can see the in LA’s BGP routing table as shown in Fig. 5.

Now you have end to end reachability between AS 20 & AS 30 and you can check the reachability using ping from router LA’ loopback to router NY’s loopback as shown in Fig. 6

Some Important Tips to Trouble-Shoot and Resolve BGP Issues:

  • Router-ID must be unique to establish BGP peering.
  • If certain BGP routes are missing from the routing table, then check if they exist in the BGP table:
    if yes : next hop reachability issue
    if not : non-availability of valid route in BGP
    Split-Horizon issue or Synchronization rule issue
  • If certain routes are missing from the BGP and routing table, then check the neighborship, using “show ip bgp summary,” or you can check for route filtering (ACLs, route-maps, etc.).
  • iBGP learned route is not advertised to other iBGP peers, so configuring a route reflector might be necessary.
  • Similarly, routes advertised by issuing a network command in BGP must be advertised with proper subnet mask.

Useful Commands to Monitor and Troubleshoot BGP:

  • show ip bgp summary—To check BGP neighbors with their respective states
  • show ip bgp—To check BGP routing database
  • show ip bgp neighbor [ip-address]—To check specific neighbors information
  • show ip bgp [particular route]—To check detailed information about specific route
  • debug ip bgp events—Displays significant BGP events
  • debug ip bgp keepalives—Displays BGP keepalive packets
  • debug ip bgp updates—Displays all incoming or outgoing BGP updates

I have also posted a solution file for BGP GNS3 lab so that you can tally your solutions with that file.

All of us know very well that it is not possible to describe BGP issues in a single article, but I have tried to discuss most common BGP problems with their solutions. I hope that now you can deal with BGP issues and resolve them quickly and thanks all for appreciating my previous articles. If you like this article, then say thanks to @ comment section for providing you with such technologies. Your feedback is also welcome.


  1. Cisco Certified Internetwork Expert by Wendell Odom and others,
  2. Routing TCP/IP Vol. 2 by Jeff Doyle
  3. CCNP – Route Quick Reference by Denis Donohou,
  4. Cisco Certified Internetwork Expert Quick Reference by Brad Ellis,