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 10.1.1.1 to 10.2.2.2. 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., 10.2.2.2, so at the end you should get a ping reply, as shown below:
LA# ping 10.2.2.2 source 10.1.1.1 Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds: Packet sent with a source address of 10.1.1.1 !!!!! 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 (22.214.171.124 to 126.96.36.199) 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 188.8.131.52 remote-as 10 neighbor 184.108.40.206 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 220.127.116.11 update-source loopback 1 WDC4(config)#router bgp 10 WDC4(config-router)#neighbor 18.104.22.168 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 22.214.171.124, as shown below:
*Mar 1 00:04:49.731: %TCP-6-BADAUTH: No MD5 digest from 126.96.36.199(179) to 188.8.131.52(14121) *Mar 1 00:04:49.871: %TCP-6-BADAUTH: No MD5 digest from 184.108.40.206(179) to 220.127.116.11(14121)
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 10.1.1.1 on WDC1 and 10.2.2.2 on WDC5 as best path but on router WDC4 you will find that you are getting both 10.1.1.1 and 10.2.2.2 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, 18.104.22.168 and 22.214.171.124, both are eBGP routes and we have not advertised 126.96.36.199 or 188.8.131.52 anywhere in BGP. That’s why both next hops are unreachable from WDC4, so the solution is to advertise 184.108.40.206 on WDC1 under BGP and 220.127.116.11 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 18.104.22.168 next-hop-self WDC5(config-router)#neighbor 22.214.171.124 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 10.2.2.2 on router WDC1 and 10.1.1.1 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 126.96.36.199 route-reflector-client WDC4(config-router)#neighbor 188.8.131.52 route-reflector-client
Instantly you will get following log messages,
*Mar 1 01:19:59.099: %BGP-5-ADJCHANGE: neighbor 184.108.40.206 Down RR client config change *Mar 1 01:20:01.347: %BGP-5-ADJCHANGE: neighbor 220.127.116.11 Up *Mar 1 01:20:20.651: %BGP-5-ADJCHANGE: neighbor 18.104.22.168 Down RR client config change *Mar 1 01:20:22.931: %BGP-5-ADJCHANGE: neighbor 22.214.171.124 Up
Now you can see the 10.2.2.2 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 intenseschool.com @ comment section for providing you with such technologies. Your feedback is also welcome.
Cisco Certified Internetwork Expert by Wendell Odom and others, Ciscopress.com
Routing TCP/IP Vol. 2 by Jeff Doyle
CCNP – Route Quick Reference by Denis Donohou, Ciscopress.com
Cisco Certified Internetwork Expert Quick Reference by Brad Ellis, Ciscopress.com