MED

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 two 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 and run the apply cost-type internal command to configure an apply clause for the export policy.	This method enables a device to set MED values for the BGP routes that are learned from IBGP peers and to be advertised to EBGP peers and match the export policy to the costs of the IGP routes to which the BGP routes are iterated.

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.

In Figure 1, ISP1 and ISP2 can learn the route 1.1.1.9/32 from Switch C or Switch D.

Figure 1 Networking diagram for MED applications

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

[HUAWEIA] display bgp routing-table

 BGP Local router ID is 10.1.1.1
 Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete


 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

[HUAWEIB] display bgp routing-table

 BGP Local router ID is 10.1.2.1
 Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete


 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 Switch C as the optimal route. As a result, Switch C and Switch D cannot load-balance the traffic from ISP1 or ISP2 to 1.1.1.1/32.

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

[HUAWEIB] 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/0/2
 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/0/0
 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 Switch B selects the route learned from Switch C because the router ID (10.1.1.2) of Switch C is smaller than that (10.1.2.2) of Switch D. Table 2 describes the attribute comparison of the routes learned from Switch C and Switch D.

**Table 2** Attribute comparison of the routes learned from Switch C and Switch D
Route Attribute	Route Learned from Switch C	Route Learned from Switch 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 Switch C is optimal.

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

For the traffic from ISP1 to 1.1.1.9/32, the link Switch A -> Switch C is active and the link Switch A -> Switch D is backup.
For the traffic from ISP2 to 1.1.1.9/32, the link Switch B -> Switch D is active and the link Switch B -> Switch C is backup.

To meet the preceding requirements, ensure that ISP1 selects the route learned from Switch C and that ISP2 selects the route learned from Switch D. Figure 2 shows the networking in which MED is used to control route selection.

Figure 2 Networking diagram for MED applications

Configure route-policies to set different MED values for the routes learned from different peers. Detailed configurations are as follows:

Configurations on Switch 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 Switch D:

The following configurations are intended to ensure that Switch A selects the route learned from Switch C. However, Switch A has already selected the route learned from Switch C because the router ID of Switch C is smaller than that of Switch D. Therefore, the following configurations on Switch D 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 Switch B as an example.

# Display the routing table of Switch B.

[HUAWEIB] display bgp routing-table

 BGP Local router ID is 10.1.2.1
 Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete


 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 Switch B.

[HUAWEIB] 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/0/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/0/2
 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 Switch B and that only the route with next hop address 10.1.2.2 is selected as the optimal route.

Table 3 describes the attribute comparison of the routes learned from Switch C and Switch D.

**Table 3** Attribute comparison of the routes learned from Switch C and Switch D
Route Attribute	Route Learned from Switch C	Route Learned from Switch 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 Switch D carries no MED value, and therefore, the default value (0) is used. The route learned from Switch D is optimal.

Figure 2 shows that the route learned from Switch D does not carry the MED value. During route selection, BGP uses the default value (0) as the MED of the route. Therefore, this route is selected as the optimal route. To change the route selection result on Switch B, run the bestroute med-none-as-maximum command on Switch B. Detailed configurations are as follows:

[HUAWEIB] display bgp routing-table

 BGP Local router ID is 10.1.2.1
 Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete


 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

[HUAWEIB] 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/0/2
 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/0/0
 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 Switch 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. The leftmost AS number in the AS_Path of route A1 is 65001, which is different from its counterpart in route B (65002). Therefore, BGP does not compare the MED values, and prefers route B to route A1 because the IGP cost (12) of route B is smaller than that of route A1 (13).
- BGP then compares route A2 and route B. The leftmost AS number in the AS_Path of route A2 is 65001, which is different from its counterpart in route B (65002). Therefore, BGP does not compare the MED values, and selects route A2 as the optimal route because its IGP cost (11) is smaller than that of route B (12).
Case 2: Route A2 is received first, followed by route B, and then route A1.
- BGP then compares route A2 and route B. The leftmost AS number in the AS_Path of route A2 is 65001, which is different from its counterpart in route B (65002). Therefore, BGP does not compare the MED values and prefers route A2 to route B because the IGP cost (11) of route A2 is smaller than that of route B (12).
- BGP then compares route A1 and route A2. The leftmost AS number in the AS_Path of route A1 is the same as its counterpart in route A2 (65001). In this situation, BGP selects route A1 as the optimal route because its MED value (100) is smaller than that of route A2 (150).
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 in the AS_Path of route A1 is the same as its counterpart in route A2 (65001). In this situation, BGP selects route A1 as the optimal route because its MED value (100) is smaller than that of route A2 (150).
- BGP then compares route A1 and route B. The leftmost AS number in the AS_Path of route A1 is 65001, which is different from its counterpart in route B (65002). Therefore, BGP does not compare the MED values and selects route B as the optimal route because the IGP cost (12) of route B is smaller than that of route A1 (13).

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.