# Troubleshooting BGP Best-Path Calculation Issues

## Troubleshooting BGP Best-Path Calculation Issues

Chapter 14 discusses in detail how the BGP best-path algorithm works to select a single best route out of many to install in the IP routing table and to advertise to other BGP neighbors. This section discusses a few cases that deal with scenarios in which best-path selection does not work as intended.

The following are the cases discussed in this section:

When the router ID (RID) selects the best path, BGP does not always select the lowest RID path as best, as described in the best-path algorithm.

Two BGP neighbors in the same AS advertise a different MED for the same prefix, but the lowest MED is not selected as best, as described in the best-path algorithm.

### Problem: Path with Lowest RID Is Not Chosen as Best

This is the scenario in which two or more paths from EBGP neighbors have identical BGP attributes and BGP best-path selection is done based on the RID. The BGP best-path selection rule states that, in case all other attributes are identical, the path with the lowest RID should be selected as best. In this case, the path with the highest RID is selected as best.

In Cisco IOS Software, if BGP selects a best path based on the RID and a new path comes in with a lower RID, with all other attributes being equal, the previously selected best path will not be toggled and will remain unchanged. This is done intentionally in Cisco IOS Software to maintain stability in BGP paths because newly selected paths must be advertised to all BGP neighbors, and the previous one must be withdrawn. To avoid this churn, BGP in Cisco IOS Software does not select a new best path if the previous path selected was done based on RID.

Figure 15-49 shows the flowchart to follow to resolve this problem.

Debugs and Verification
Figure 15-50 shows a network composed of R1 in AS 109, and R3 and R5 in AS 110. Both R3 and R5 are advertising 100.100.100.0/24. The RIDs of R3 and R5 are 3.3.3.3 and 5.5.5.5, respectively.

shows the necessary configuration in R1, R3, and R5 to form a BGP neighbor relationship, and for R3 and R5 to advertise 100.100.100.0/24.

Example 15-91 Configuring R3 and R5 to Advertise 100.100.100.0/24 and to Form an EBGP Neighbor Relationship with R1

The highlighted commands show how RID can be configured manually in BGP. Each router is configured with recognizable RIDs. This is done to ease in understanding BGP outputs later in this section.

Now, R1 will receive 100.100.100.0/24 from R3 and R5. The output in Example 15-92 shows that R1 is receiving both the updates and that it prefers the update from R5.

All BGP attributes (LOCAL_PREF, MED, ORIGIN CODE, and EXTERNAL versus INTERNAL) are identical. According to BGP best-path calculation rules, as described in

Example 15-92 BGP Output in R1 to Show the Best Path for 100.100.100.0/24

Chapter 14, the best path should be the one with the lowest RID if all other attributes are identical. In this output, the path from RID 3.3.3.3 (R3) should have been the best, but the output in Example 15-92 shows that the best path is from 5.5.5.5 (R5).

To explain this problem, you must understand the sequence of events in R1. In R1, the path from R5 must have been received before the path from R3. If R1 has selected the path from R5 as best, when the path from R3 comes and the deciding factor for the best-path calculation is RID, R1 will keep R5 as the best even though R3 offered a lower RID.

Solution
If R1 wants the proper RID to be the deciding factor in best-path calculation, it must add a BGP knob in Cisco IOS Software, as shown in Example 15-93.

Example 15-93 BGP Knob to Compare RID in Best-Path Selection

The highlighted command enables R1 to compare the RIDs of all the paths and pick the lowest RID as the best in BGP best-path calculation. The effect of this configuration change takes place when the BGP scanner runs. (It runs every minute in Cisco IOS Software.)

The output in Example 15-94 shows that R1 has selected the R3 path as best because the R3 path has a lower RID (3.3.3.3) than the R5 path (5.5.5.5).

Example 15-94 BGP Best-Path Selection Using RID

Origin IGP, metric 0, localpref 100, valid, external

### Problem: Lowest MED Not Selected as Best Path

In some scenarios, the router does not select the lowest MED advertised by neighbors as the best path.

Figure 15-51 shows a network setup that has AS 109 (R1) connected to AS 110 at two BGP peering points (R3 and R5); AS 109 has one connection with AS 111 (R4). R1 is receiving 100.100.100.0/24 from all three EBGP connections. All neighbors are advertising MEDs to influence return traffic from AS 109. R3 and R5 are advertising MEDs of 50 and 30, respectively, whereas R4 is sending a MED of 40.

R1 receives all three advertisements but failed to select the path from R5 (lowest MED) as the best path; instead, it selected the path from R3 (highest MED) as the best. This might cause traffic policy disturbance from the perspective of both AS 109 and AS 110 because the link between R1 and R3 could be smaller, and the link between R1 and R5 might be bigger; both autonomous systems want R1 and R5 to use for all traffic.

In Figure 15-51, both AS 109 and AS 110 expect that R1 will select the path from R5 as best because R5 clearly is advertising a MED of 30, as compared to a MED of 50 from R3. By BGP best-path calculation, the path from the lower MED should be selected as best. In addition, R4 is advertising 100.100.100.0/24 with a MED of 40.

One BGP rule that must be kept in mind is the rule of MED comparison. By default, Cisco IOS Software will not compare the MEDs if two paths came from different autonomous systems. R1 will ignore the MED when it is comparing the paths between R5 and R4. The tiebreaker in R1 to select a best path between R4 and R5 will be something other than the MED. If no other BGP attributes are used, the RID breaks the tie to select the best path. The “Debugs and Verification” section shows the sequence of events and output from the R1 BGP table to show that best path is indeed not the one that has the lowest MED (R5).

Figure 15-52 shows the flowchart to follow to resolve this problem.

Debugs and Verification
Example 15-95 shows the output from R1 for 100.100.100.0/24.

Example 15-95 Selection of Best Path, Ignoring Lowest MED

The output in 15-95 shows that R1 has three paths in this order:

• Path 1: This path is from R5 (RID 5.5.5.5), with a MED of 30.
• Path 2: This path is from R4 (RID 4.4.4.4), with a MED of 40.
• Path 3: This path is from R3 (RID 3.3.3.3) with a MED of 50.

If the best-path selection algorithm described in Chapter 14 were run, the following would be the selection process:

Path 1 is compared with Path 2. All BGP attributes are the same except for the MED. However, these two paths came from different autonomous systemsâ€”110 and 111, respectivelyâ€”so the MED will not be the tiebreaker and will be ignored. The tiebreaker will be the RID. Based on the RID, path 2 has a lower RID (4.4.4.4) than path 1 (5.5.5.5). Therefore, path 2 is the winner.

The winner of Step 1, path 2, is compared with path 3. Again, the MED will be ignored because of a different AS_PATH. The lower RID of path 3 (3.3.3.3) will win again path 2’s RID (4.4.4.4).

Path 3 is selected as best even though it has a higher MED than any of the paths (MED 50).

Solution
To solve this problem, Cisco IOS Software must allow comparison of MEDs between different autonomous systems. Example 15-96 shows the configuration knob that can be added in R1 to achieve that.

Example 15-96 Knob to Compare MED from Different Autonomous Systems

The highlighted command enables R1 to compare MEDs in BGP best-path selection even though the paths came from different autonomous systems.

Example 15-97 shows the BGP table for 100.100.100.0/24 after the change.

Example 15-97 Desired BGP Path Selection After Comparing MEDs Between Different Autonomous Systems

The best path is the one that has the lowest MED. As stated earlier, choosing the path with the lowest MED could be crucial if links between autonomous systems are of different bandwidth and a path from a higher-bandwidth neighbor is sending a lower MED.

In addition, one important design recommendation is that the command bgp always-compare-med should be enabled on all the routes in an AS running BGP; otherwise, packet forwarding loops might occur. For example, Router A running this command might point its best path to Router B, whereas Router B without this command might point the best path back to Router A, resulting in a routing loop.