MED

MED attributes of routes can be configured as required to control traffic forwarding path for the purpose of load balancing.

The MED attribute is transmitted only within an AS or between two neighboring ASs. The AS that receives the MED attribute does not advertise it to a third AS.

Similar to the cost used by an IGP, the MED is used to determine the optimal route when traffic enters an AS. When a BGP peer learns multiple routes that have the same destination address but different next hop addresses from EBGP peers, the route with the smallest MED value is selected as the optimal route if all the other attributes are the same.

Table 1 lists three methods used to modify the MED value.

**Table 1** Methods to modify the MED value
Method	Usage Scenario
Run the default med command.	This method sets a default MED for all the routes that the local device advertises to its BGP peers. The default med command takes effect only with the routes imported locally using the import-route command and BGP summarized routes.
Configure an import or export policy and run the apply cost command to configure an apply clause for the policy.	This method sets different MED values for different routes advertised by the local device to its EBGP peers.
Configure an export policy in which the apply cost-type internal command is run.	The router sets the MED of each BGP route advertised to a peer to the cost of the IGP route to which the BGP route recurses. This method takes effect only on EBGP peers.
Configure an export policy in which the apply cost-type internal-inc-ibgp command is run.	The router sets the MED of each BGP route advertised to a peer to the cost of the IGP route to which the BGP route recurses. This method takes effect both on IBGP and EBGP peers.
Configure an export policy in which the apply cost-type med-plus-igp command is run.	The router sets the MED of each BGP route advertised to a peer to the cost of the IGP route to which the BGP route recurses plus the original MED. This method takes effect both on IBGP and EBGP peers.
Configure an export policy in which the apply cost-type med-inherit-aigp command is run.	The router sets the MED of each route to be advertised to a peer to the AIGP of the route. This method takes effect on both IBGP and EBGP peers. The policy applies only to BGP VPN peers.

The major points about MED attributes that require consideration are as follows:

If routes are received from different ASs, traffic will be sent to different ASs. In addition, BGP selects the optimal route only from the routes destined for the same address. Therefore, BGP only compares the MEDs of routes that are from the same AS (excluding confederation sub-ASs). MEDs of two routes are compared only if the leftmost AS number in the AS_Sequence (excluding AS_Confed_Sequence) of one route is the same as its counterpart in the other route.
If the compare-different-as-med command is run, BGP compares MEDs of routes even when the routes are received from peers in different ASs. Do not run this command unless the ASs use the same IGP and route selection mode. Otherwise, a routing loop may occur.
If a route does not carry MED, BGP uses the default value (0) as the MED of the route during route selection. If the bestroute med-none-as-maximum command is run, BGP considers the largest MED value (4294967295) to be the MED of the route. After route selection is complete, the MED is restored to the original value.
After the bestroute med-confederation command is configured, BGP compares the MEDs of routes only when the AS_Path attributes of the routes carry no external AS numbers (ASs that do not belong to the confederation) and the leftmost AS numbers in each AS_Confed_Sequence are the same.
After the deterministic-med command is configured, routes will not be selected in the same sequence they are received.

Figure 1 is used as an example to describe how the MED attribute is used in BGP route selection. In Figure 1, ISP1 and ISP2 can access 1.1.1.9/32 from DeviceC or DeviceD.

Figure 1 Networking diagram for MED applications

Scenario 1: Check the BGP routing tables of Device A and Device B before Device C and Device D are configured to modify the MED of the route 1.1.1.9/32.

[~DeviceA] display bgp routing-table
 BGP Local router ID is 10.1.1.1
 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete
 RPKI validation codes: V - valid, I - invalid, N - not-found

 Total Number of Routes: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   1.1.1.9/32         10.1.1.2                              0      65001i
 *                       10.1.3.2                              0      65001i
[~DeviceB] display bgp routing-table
 BGP Local router ID is 10.1.2.1
 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete
 RPKI validation codes: V - valid, I - invalid, N - not-found

 Total Number of Routes: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   1.1.1.9/32         10.1.4.2                              0      65001i
 *                       10.1.2.2                              0      65001i

The preceding command output shows that both ISP1 and ISP2 select the route learned from DeviceC as the optimal route. That is, the traffic from ISP1 and ISP2 to 1.1.1.9/32 enters AS 65001 through DeviceC, not through DeviceD, indicating that load balancing is not implemented.

Run the display bgp routing-table ip-address command on Device B to check the reason why Device B chooses the route learned from Device C.

[~DeviceB] display bgp routing-table 1.1.1.9
 BGP local router ID : 10.1.2.1
 Local AS number : 200
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.4.2 (10.1.1.2)
 Route Duration: 00h00m58s
 Direct Out-interface: GigabitEthernet0/1/0
 Original nexthop: 10.1.4.2
 Qos information : 0x0
 AS-path 65001, origin igp, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.2.2
    10.1.4.2
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 00h01m07s
 Direct Out-interface: GigabitEthernet0/1/8
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path 65001, origin igp, pref-val 0, valid, external, pre 255, not preferred for router ID
 Not advertised to any peer yet

The preceding command output shows that DeviceB selects the route learned from DeviceC because the router ID (10.1.1.2) of DeviceC is smaller than that (10.1.2.2) of DeviceD. Table 2 describes the attribute comparison of the routes learned from DeviceC and DeviceD.

**Table 2** Attribute comparison of the routes that DeviceB learns from DeviceC and DeviceD
Route Attribute	Route Learned from Device C	Route Learned from Device D	Comparison
PrefVal	0	0	The same.
Local_Pref	-	-	The same.
Route type	Learned from a peer	Learned from a peer	The same.
AIGP	-	-	The same.
AS_Path	65001	65001	The same length.
Origin	IGP	IGP	The same.
MED	-	-	The same.
Peer type	EBGP	EBGP	The same.
IGP cost	-	-	The same.
Cluster_List	-	-	The same length.
Router ID	10.1.1.2	10.1.2.2	The route learned from Device C is optimal.

Scenario 2: The requirements of the administrator of AS 65001 are as follows:

The traffic from ISP1 to 1.1.1.9/32 enters AS 65001 preferentially through DeviceC, with DeviceD as a backup option.
The traffic from ISP2 to 1.1.1.9/32 enters AS 65001 preferentially through DeviceD, with DeviceC as a backup option.

To meet the preceding requirements, ensure that ISP1 selects the route learned from DeviceC to access 1.1.1.9/32 and that ISP2 selects the route learned from DeviceD to access 1.1.1.9/32. Figure 2 shows the networking.

Figure 2 Networking diagram for MED applications

The MED attribute can be used to meet the preceding requirement. However, the MED attribute needs to be set for different peers. Therefore, a route-policy must be used. Detailed configurations are as follows:

Configurations on Device C:

#
bgp 65001
 #
 ipv4-family unicast
  undo synchronization
  peer 10.1.4.1 route-policy addmed100 export          //Apply export policy named addmed100 to the routes to be advertised to 10.1.4.1 and use addmed100 to modify the MED value.
#
route-policy addmed100 permit node 10                  //Define the first node of addmed100 and set the MED of the route 1.1.1.9/32 to 100.
 if-match ip-prefix p1
 apply cost 100
#
route-policy addmed100 permit node 20                  //Define the second node of addmed100 to allow addmed100 to permit all other routes.
#
ip ip-prefix p1 index 10 permit 1.1.1.9 32             //Configure an IP prefix list to match the route 1.1.1.9/32.

Configurations on DeviceD:

The following configurations are intended to ensure that DeviceA selects the route learned from DeviceC. However, DeviceA has already selected the route learned from DeviceC because the router ID of DeviceC is smaller than that of DeviceD. Therefore, the following configurations on DeviceD are optional.

#
bgp 65001
 #
 ipv4-family unicast
  undo synchronization
  peer 10.1.3.1 route-policy addmed200 export          //Apply export policy named addmed200 to the routes to be advertised to 10.1.3.1 and use addmed200 to modify the MED value.
#
route-policy addmed200 permit node 10                  //Define the first node of addmed200 and set the MED of the route 1.1.1.9/32 to 200.
 if-match ip-prefix p1
 apply cost 200
#
route-policy addmed200 permit node 20                  //Define the second node of addmed200 to allow addmed200 to permit all other routes.
#
ip ip-prefix p1 index 10 permit 1.1.1.9 32             //Configure an IP prefix list to match the route 1.1.1.9/32.

Run the display bgp routing-table [ ip-address ] command to check the configurations. Use Device B as an example.

# Display the routing table of Device B.

[~DeviceB] display bgp routing-table
 BGP Local router ID is 10.1.2.1
 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete
 RPKI validation codes: V - valid, I - invalid, N - not-found

 Total Number of Routes: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   1.1.1.9/32         10.1.2.2                              0      65001i
 *                       10.1.4.2        100                   0      65001i

# Display detailed information about the route 1.1.1.9/32 on Device B.

[~DeviceB] display bgp routing-table 1.1.1.9 32
 BGP local router ID : 10.1.2.1
 Local AS number : 200
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 01h20m38s
 Direct Out-interface: GigabitEthernet0/1/0
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path 65001, origin igp, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.2.2
    10.1.4.2
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.4.2 (10.1.1.2)
 Route Duration: 01h16m28s
 Direct Out-interface: GigabitEthernet0/1/8
 Original nexthop: 10.1.4.2
 Qos information : 0x0
 AS-path 65001, origin igp, MED 100, pref-val 0, valid, external, pre 255, not preferred for MED
 Not advertised to any peer yet

The preceding command output shows that two routes 1.1.1.9/32 are available in the BGP routing table of DeviceB and that only the route with next hop address 10.1.2.2 is selected as the optimal route. The other route with next hop address 10.1.4.2 is not selected due to the MED issue.

Table 3 compares the attributes of the routes that DeviceB learns from DeviceC and DeviceD.

**Table 3** Attribute comparison of the routes that DeviceB learns from DeviceC and DeviceD
Route Attribute	Route Learned from Device C	Route Learned from Device D	Comparison
PrefVal	0	0	The same.
Local_Pref	-	-	The same.
Route type	Learned from a peer	Learned from a peer	The same.
AIGP	-	-	The same.
AS_Path	65001	65001	The same length.
Origin	IGP	IGP	The same.
MED	100	-	The route learned from Device D carries no MED value, and therefore, the default value (0) is used. The route learned from DeviceD is optimal.

Figure 2 shows that the route learned from DeviceD does not carry the MED attribute. In this case, the default MED value 0 is used by this route. Therefore, this route is selected as the optimal route. To change the route selection result on DeviceB, you can run the bestroute med-none-as-maximum command on DeviceB. Detailed configurations are as follows:

[~DeviceB] display bgp routing-table
 BGP Local router ID is 10.1.2.1
 Status codes: * - valid, > - best, d - damped, x - best external, a - add path,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete
 RPKI validation codes: V - valid, I - invalid, N - not-found

 Total Number of Routes: 2
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   1.1.1.9/32         10.1.4.2        100                   0      65001i
 *                       10.1.2.2                              0      65001i
[~DeviceB] display bgp routing-table 1.1.1.9
 BGP local router ID : 10.1.2.1
 Local AS number : 200
 Paths:   2 available, 1 best, 1 select
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.4.2 (10.1.1.2)
 Route Duration: 00h08m42s
 Direct Out-interface: GigabitEthernet0/1/0
 Original nexthop: 10.1.4.2
 Qos information : 0x0
 AS-path 65001, origin igp, MED 100, pref-val 0, valid, external, best, select, active, pre 255
 Advertised to such 2 peers:
    10.1.2.2
    10.1.4.2
 BGP routing table entry information of 1.1.1.9/32:
 From: 10.1.2.2 (10.1.2.2)
 Route Duration: 16h33m10s
 Direct Out-interface: GigabitEthernet0/1/8
 Original nexthop: 10.1.2.2
 Qos information : 0x0
 AS-path 65001, origin igp, pref-val 0, valid, external, pre 255, not preferred for MED
 Not advertised to any peer yet

The preceding command output shows that two routes 1.1.1.9/32 are available in the BGP routing table of Device B. The MED of the route with the next hop address 10.1.4.2 is 100, and the MED of the route with the next hop address 10.1.2.2 is considered as 4294967295 because it carries no MED. Therefore, the route with the next hop address 10.1.4.2 is selected as the optimal route.

In addition, BGP selects routes in the same sequence they are received. Therefore, the route selection result is relevant to the sequence in which the routes are received. For example, the following three BGP routes are available on a device:

Route A1: AS_Path { 65001 200 }, med 100, igp cost 13, internal, Router id 4.4.4.4
Route A2: AS_Path { 65001 100 }, med 150, igp cost 11, internal, Router id 5.5.5.5
Route B: AS_Path { 65002 300 }, med 0, igp cost 12, internal, Router id 6.6.6.6

If the compare-different-as-med (BGP) command is run, route B is the optimal route, regardless of the sequence in which the routes are received. If the compare-different-as-med (BGP) command is not configured, BGP does not compare the MED values of routes learned from different ASs. The route selection is described in the following cases:

Case 1: Route A1 is received first, followed by route B, and then route A2.
- BGP first compares route A1 and route B. Because the leftmost ASs of route A1 and route B are different, the device does not compare the MEDs of the two routes and prefers the route (route B) with the smallest IGP metric (IGP cost).
- BGP then compares route A2 and route B. Because the leftmost ASs of route A2 and route B are different, the device does not compare the MEDs of the two routes and prefers the route (route A2) with the smallest IGP metric.
Case 2: Route A2 is received first, followed by route B, and then route A1.
- BGP then compares route A2 and route B. Because the leftmost ASs of route B and route A2 are different, the device does not compare the MEDs of the two routes and prefers the route (route A2) with the smallest IGP metric.
- BGP then compares route A1 and route A2. The leftmost AS number of route A1 is the same as its counterpart in route A2. In this situation, BGP selects route A1 as the optimal route because its MED value is smaller.
Case 3: If the deterministic-med command is run, BGP groups the routes that are learned from different ASs but are destined for the same network segment based on the leftmost AS number in the AS_Path, selects one optimal route from each group, and then compares the optimal routes of all the groups. Detailed steps are as follows:
- BGP first compares route A1 and route A2. The leftmost AS number of route A1 is the same as its counterpart in route A2. In this situation, BGP selects route A1 as the optimal route because its MED value is smaller.
- BGP then compares route A1 and route B. The leftmost AS number of route A1 is different from its counterpart in route B. Therefore, BGP does not compare the MED values and selects route B as the optimal route because the IGP cost is smaller.

Case 1 and case 2 show that the route selection result is relevant to the sequence in which routes are received if the deterministic-med is not configured. Case 3 shows that the route selection result is irrelevant to the sequence in which routes are received if the deterministic-med is configured.