Hands-On Lab: Configuring BGP MED (Multi-Exit Discriminator)

This hands-on lab configures the MED attribute on two eBGP paths advertised to the same neighboring AS, verifying it influences that neighbor's inbound path selection only when AS-path length and other higher-priority attributes are already equal.

BGP MED AttributeMulti-Exit DiscriminatorLowest MED Preferred

~4 min read · Updated Sep 26, 2026

Lab Objective

Configure different MED values on two routes advertised to the same neighboring AS via two separate connections, verify the neighbor prefers the path with the lower MED, and confirm MED is only consulted when AS-path length between the two candidate routes is already identical.

Lab Purpose

AS-path prepending, covered in the previous lab, influences inbound traffic by artificially lengthening the AS-path. MED offers a more direct mechanism for the specific case of two connections to the very same neighboring AS, letting that AS know which entry point is preferred without needing to distort the AS-path itself — but MED's influence is much more limited in scope than AS-path length.

Lab Topology

AS 65050 connects to the SAME neighboring
AS 65060 via two separate links:

R1 (AS 65050) ---- eBGP ---- R3 (AS 65060)
R2 (AS 65050) ---- eBGP ---- R3 (AS 65060)
                              (same AS 65060,
                               different router
                               or same router,
                               multiple links)

Goal: make R3 prefer the R1 path for traffic
toward 192.168.250.0/24

Task 1: Verify Both Paths Currently Appear Equal to R3

Confirm R3 sees both paths to 192.168.250.0/24 with identical AS-path length and no MED difference yet.

Task 2: Configure a Lower MED on R1's Advertisement

Configure R1 to advertise 192.168.250.0/24 with a MED value of 50.

Task 3: Configure a Higher MED on R2's Advertisement

Configure R2 to advertise the same network with a MED value of 150.

Task 4: Verify R3 Prefers the Lower-MED Path

Confirm R3 selects the R1 path as best, specifically due to its lower MED value.

Task 5: Demonstrate MED's Limited Scope

Introduce a third path via a completely different neighboring AS with a shorter AS-path but a higher MED, and confirm AS-path length still wins, since MED is only compared among paths from the same neighboring AS.

Solution and Verification

R1(config)# router bgp 65050
R1(config-router)# neighbor [R3 address] route-map SET-MED-LOW out

R1(config)# route-map SET-MED-LOW permit 10
R1(config-route-map)# set metric 50

R2(config)# router bgp 65050
R2(config-router)# neighbor [R3 address] route-map SET-MED-HIGH out

R2(config)# route-map SET-MED-HIGH permit 10
R2(config-route-map)# set metric 150

R3# show ip bgp 192.168.250.0

   Network              Next Hop         Metric  Path
*> 192.168.250.0/24    [via R1]          50      65050 i
*  192.168.250.0/24    [via R2]          150     65050 i
-- Both paths show the identical AS-path
-- (just "65050"), so MED becomes the
-- deciding factor -- the lower value (50,
-- via R1) is selected as best, since BGP
-- treats a lower MED as more preferred

-- Introducing a third path via a different
-- neighboring AS (65070), with a shorter
-- AS-path length but a higher configured MED:

R3# show ip bgp 192.168.250.0

   Network              Next Hop         Metric  Path
*> 192.168.250.0/24    [via AS65070]     500     65070 i
   192.168.250.0/24    [via R1]           50     65050 i
   192.168.250.0/24    [via R2]          150     65050 i
-- The AS65070 path wins overall despite a
-- MED of 500 -- since it comes from a
-- DIFFERENT neighboring AS, its shorter
-- AS-path (length 1 vs 2) is compared and
-- wins before MED is ever considered
-- between it and the other two paths

Key Takeaway

MED comparison, by default, only occurs between routes learned from the same neighboring AS — this default behavior (sometimes called the "MED comparison only among same-AS paths" rule) means MED is a much narrower tool than AS-path prepending, useful specifically for load-sharing or preferring one entry point over another when a network is multi-homed to a single neighboring AS through more than one connection, but it exerts zero influence when comparing paths that arrived via genuinely different neighboring autonomous systems.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue