Problem: Lowest MED Not Selected as Best Path

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.

Figure 15-51. Network in Which Lowest MED Is Omitted from Selection of Best Path

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.

Figure 15-52. Problem-Resolution Flowchart

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

 R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 3 Paths: (3 available, best #1, table Default-IP-Routing-Table)   Advertised to non peer-group peers:   1.1.7.5 1.1.3.4   110 200     1.1.7.5 from 1.1.7.5 (  5.5.5.5  )       Origin IGP, metric  30  , localpref 100, valid, external  111 200     1.1.3.4 from 1.1.3.4 (  4.4.4.4  )       Origin IGP, metric  40  , localpref 100, valid, external  110 200     1.1.2.3 from 1.1.2.3 (  3.3.3.3  )       Origin IGP, metric  50  , localpref 100, valid, external,  best  

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

1. Path 1: This path is from R5 (RID 5.5.5.5), with a MED of 30.

2. Path 2: This path is from R4 (RID 4.4.4.4), with a MED of 40.

3. 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:

1. 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.

2. 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

 R1#  router bgp 109   bgp router-id 1.1.1.1    bgp always-compare-med    neighbor 1.1.2.3 remote-as 110   neighbor 1.1.7.5 remote-as 110  neighbor 1.1.3.4 remote-as 111 

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

 R1#  show ip bgp 100.100.100.0  BGP routing table entry for 100.100.100.0/24, version 3 Paths: (3 available, best #1, table Default-IP-Routing-Table)   Advertised to non peer-group peers:   1.1.3.4 1.1.2.3   110 200     1.1.7.5 from 1.1.7.5 (  5.5.5.5  )       Origin IGP, metric  30  , localpref 100, valid, external,  best  111 200    1.1.3.4 from 1.1.3.4 (  4.4.4.4  )       Origin IGP, metric  40  , localpref 100, valid, external  110 200     1.1.2.3 from 1.1.2.3 (  3.3.3.3  )       Origin IGP, metric  50  , localpref 100, valid, external 

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.