In everything I’ve been working on lately, a lot of it has revolved around BGP. Most of this has come from my CCIE studies. In practice labs and scenarios something I’ve become accustomed to seeing was a BGP scenario where there is a specific path the scenario wants traffic to take. The goal is the find the BGP path issues and resolve them so the traffic takes the preferred route. On the most basic level, there are two basic BGP commands that I use to begin troubleshooting the issue.
Is the BGP relationship established?
First thing you want to check for is if you have a connection established with your intended BGP neighbor. With this you can check if messages are being send and received as well as how long that neighbor relationship has been up. The command to look this up would be “show ip bgp summary”. Some of the output from the command would look like this:
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.2.0.2 4 65002 36 38 26 0 0 00:24:56 5 10.4.0.2 4 65002 36 38 26 0 0 00:24:55 5 10.5.0.2 4 65002 36 38 26 0 0 00:24:55 5
The quick things I am checking for with this output are that first off, the neighbor is showing up. Next I check that messages are being both sent and received. Lastly, in the far right column, I check that prefixes are being received. From that point, I know that I am receiving SOMETHING from my neighbor router as long as the issue is not with the basic BGP configuration.
So why is traffic taking the wrong path?
So you established that your neighbor router is online and working. You are sending and receiving messages and receiving prefixes through BGP. What is the next step in troubleshooting the BGP path issues? I normally begin by doing a traceroute and finding out where the incorrect path begins. That is how I know where to begin troubleshooting. I normally go to the last router in the path that is on the intended path that I am looking for. The next command I would run is a basic “show ip bgp”. From this, you’ll get a list of received BGP prefixes with some other very important information. It will look a bit like this (some output was omitted to make it easier to read):
BGP_LAB_R1#sh ip bgp BGP table version is 26, local router ID is 10.0.0.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * i 184.108.40.206/24 10.2.0.2 100 0 65002 i * i 10.5.0.2 50 100 0 65002 i *>i 10.5.0.2 50 100 0 65002 i
Take a look at this output. There are four pieces of information that I find very important:
- The status codes on the left
- LocPrf (Local Preference)
Say 220.127.116.11/24 is the prefix that I am focusing on. My traffic is taking the wrong route by going to the router with the id of 10.5.0.2 instead of 10.2.0.2. The first thing is the status code to see which next-hop has been marked as the best path. That is shown by the “>” symbol, as seen by the line with the next hop of 10.5.0.2. So I have confirmed that the wrong path is being used here so now I need to find out why. Next I check out the most common reasons and those would be Metric, LocPrf, and\or Weight. In this case, I need to find the differentiating factor. Weight is the same. Local Preference is the same at the default value of 100 for all paths. Metric is where things are different. The path with the next hop of 10.5.0.2 has a metric of 50, which is lower than the metric of 10.2.0.2 (100). With lower metric being preferred, that path was selected.
Fixing the issue.
We found out what the issue was on why the wrong path was being selected. Your troubleshooting (for now) is complete. You could go through and do multiple different things to resolve the issue. You could use a route map for instance on neighbor 10.5.0.2 to either block advertisements for 18.104.22.168/24 or change the weight to something higher than the value of 100 that 10.2.0.2 has. That’s just a couple of many possible resolutions.
Ultimately, you can see how these two commands can be the start of resolving common BGP path issues. Obviously this will not find all of the issues, but it is my go to method to begin my troubleshooting.