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 دقیقه مطالعه · آخرین به‌روزرسانی ۴ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه