BGP MED (Multi-Exit Discriminator)

Learn how the BGP MED (Multi-Exit Discriminator) attribute influences path selection in multi-homed networks. Understand its configuration, verification, and impact on inbound traffic for optimized routing.

In the previous blogs, we explored several BGP path selection attributes such as Weight, Local Preference, Locally Originated, AS Path Length, and Origin Code. Moving forward in the selection order, we now come to the Multi-Exit Discriminator (MED) attribute.

The MED attribute plays an important role in influencing inbound traffic when two Autonomous Systems (AS) are connected via multiple links. Unlike Local Preference, which is set inside an AS, the MED is exchanged between different ASes to suggest which entry point should be preferred.

---

What is MED?

• MED (Metric) is a non-transitive, optional BGP attribute.
• It indicates to external neighbors the preferred path into an AS when there are multiple entry points.
• Lower MED values are preferred over higher ones.
• By default, MED is only compared if routes are received from the same neighboring AS.
• To compare MED values across different ASes, the command bgp always-compare-med can be used.

---

MED in Path Selection Order

The order so far is:

1. Weight (Cisco-specific)
2. Local Preference
3. Locally Originated
4. AS Path Length
5. Origin Code
   ➡ 6. Multi-Exit Discriminator (MED)

Configuration Example –

After completing the basic interface and BGP configuration, the sessions with both neighbors are now established

Next, we will verify how the prefix 10.10.10.10 is being received on R1.

As seen in the above image, the BGP attributes up to the Origin Code are identical, and even the Metric values from both neighbors are the same. To influence the path selection, we will now experiment with the MED (Metric) attribute.

Let’s configure the route-maps with different MED values. Currently, R1 selects the best path via R2. To test MED influence, we will set a lower metric on R3 and a higher metric on R2. As a result, R1 should prefer the prefixes from R3 due to the lower MED. Let’s apply the following configuration on both routers:

R2(config)#ip prefix-list MED permit 10.10.10.10/32 R2(config)#route-map MED R2(config-route-map)#match ip address MED R2(config-route-map)#se metric 150 R2(config)#router bgp 200 R2(config-router)#neighbor 12.1.1.1 route-map MED out

R3(config)#ip prefix-list MED permit 10.10.10.10/32 R3(config)#route-map MED R3(config-route-map)#match ip address MED R3(config-route-map)#se metric 100 R3(config)#router bgp 300 R3(config-router)#neighbor 13.1.1.1 route-map MED out

Since the neighbors belong to different AS numbers (R2-AS200 and R3-AS300), we need to configure the following command on R1 to enable MED comparison across different ASes:

R1#conf t R1(config)#router bgp 100 R1(config-router)#bgp always-compare-med

Wow! After applying the MED attribute, we can see in the BGP table below that R1 now selects the best path via R3. Refer to the snapshot for details.

Advanced MED Behavior

• Same-AS comparison only:
  By default, MED values are compared only if the routes come from the same AS.
  Example: If R1 receives the same prefix from AS200 (MED 50) and AS300 (MED 20), the MEDs will not be compared by default.
• Changing default behavior:
  Use the bgp always-compare-med command if you want to compare MED values across different ASes.
• Non-transitive attribute:
  MED is not passed beyond the first neighboring AS. For example, if AS200 sends a MED to AS100, AS100 will not forward that MED to AS300.

Use Cases of MED

1. Multi-homing with the same ISP
   • Your AS is connected to the same ISP at multiple points. MED helps the ISP decide which entry point your traffic should use.
2. Traffic engineering
   • ISP can direct traffic through primary and backup links.
   • Can help balance traffic between data centers or sites.
3. Load balancing
   • Different prefixes can be advertised with different MED values to balance traffic across multiple links.

Key Points about MED

• Lower MED is preferred.
• Used for inbound traffic engineering between different ASes.
• Only compared when routes come from the same neighboring AS (unless bgp always-compare-med is enabled).
• It is non-transitive — not passed beyond the neighboring AS.
• Best used when your AS is multi-homed to the same ISP.

---

Summary

The MED attribute is a powerful way to control inbound BGP traffic flow when multiple entry points exist between ASes. Unlike Local Preference (which controls outbound traffic within your AS), MED lets you signal your preference to external neighbors. Always remember that the lower the MED, the better the path.