BGP · · 4 min read

BGP MED (Multi-Exit Discriminator): Influencing Inbound Traffic

MED tries to influence how traffic enters your AS by suggesting which of your entry points the neighbor should prefer. It is optional non-transitive and easy to misuse. How MED actually works, and how to set it safely.

BGP MED (Multi-Exit Discriminator): Influencing Inbound Traffic - PingLabz BGP article title card

Local preference controls where your traffic leaves your AS. MED (Multi-Exit Discriminator) tries to control where traffic enters your AS - by suggesting to your neighbor which of your multiple connections they should prefer. The key word is "suggesting" - MED is optional non-transitive, evaluated at step 6 of best path selection, and your neighbor is free to ignore it entirely.

(This article is part of the PingLabz BGP series - the full BGP guide maps the whole cluster in reading order.)

How MED Works

  • Direction: Set on outbound advertisements to an eBGP peer. The receiving AS uses it to choose between multiple entry points into your network.
  • Value: Lower is better (opposite of local-pref). Default is 0 when explicitly set, or missing (treated as 0 or infinity depending on config).
  • Comparison scope: By default, MED is only compared between paths received from the same neighboring AS. Paths from different ASes ignore each other's MED.
  • Transitivity: Non-transitive - MED is only meaningful to the directly connected AS. It's not passed further.

Configuration

Set MED on outbound to suggest which entry point ISP-A should prefer:

! R1-HQ: prefer this entry point (lower MED = better)
route-map TO-ISP-A permit 10
 set metric 100
!
router bgp 65001
 neighbor 172.16.0.2 route-map TO-ISP-A out

If you have a second border router (R2-HQ) also peering with ISP-A, set a higher MED there:

! R2-HQ: less preferred entry point
route-map TO-ISP-A permit 10
 set metric 200
!
router bgp 65001
 neighbor 172.16.0.4 route-map TO-ISP-A out

ISP-A now sees the same prefix from two entry points: R1-HQ with MED 100 and R2-HQ with MED 200. At step 6 of best path selection, ISP-A prefers R1-HQ (lower MED).

Setting MED from IGP Metric

A common pattern is to set MED to the IGP metric, so external traffic naturally flows to the closest entry point:

route-map SET-MED-FROM-IGP permit 10
 set metric-type internal
!
router bgp 65001
 neighbor 172.16.0.2 route-map SET-MED-FROM-IGP out

Or use the redistribute or network command behavior: when a BGP route is originated from an IGP route, the IGP metric is automatically carried as the MED (unless overridden).

MED Comparison Rules

This is where MED gets tricky:

Default: Same-AS Comparison Only

By default, MED is only compared between paths learned from the same neighboring AS. If R1-HQ learns 100.64.0.0/18 from both ISP-A (AS 65010, MED 100) and ISP-B (AS 65020, MED 50), MED is NOT compared because the paths come from different ASes.

! Enable comparison across all ASes
R1-HQ(config-router)# bgp always-compare-med

With bgp always-compare-med, MED is compared regardless of the originating AS. This is commonly needed in networks that peer at multiple IXPs or have complex multi-AS peering arrangements.

Missing MED Treatment

What if one path has a MED and another doesn't? By default, a missing MED is treated as 0 (best possible). This can cause unexpected behavior:

! Treat missing MED as the worst (highest value)
R1-HQ(config-router)# bgp bestpath med missing-as-worst

With missing-as-worst, paths without MED are treated as MED 4294967295 (max uint32), making them the least preferred. This is generally a safer default in production.

Why MED Is "Just a Suggestion"

MED is evaluated at step 6 - after weight (1), local-pref (2), locally originated (3), AS-path length (4), and origin (5). If your neighbor has set local-pref on their inbound route-map, or if the AS-path lengths differ, MED never gets a chance to influence the decision.

In practice, many ISPs configure inbound local-pref on customer sessions, effectively overriding any MED the customer sets. MED is most effective when:

  • Both paths have the same local-pref on the receiving side
  • Both paths have the same AS-path length
  • The receiving AS actually pays attention to MED (some strip it on ingress)

Verification

! What ISP-A sees for our prefix
ISP-A-PE1# show ip bgp 10.1.0.0/16
BGP routing table entry for 10.1.0.0/16, version 34
Paths: (2 available, best #1, table default)
  65001
    172.16.0.1 from 172.16.0.1 (1.1.1.1)
      Origin IGP, metric 100, valid, external, best
  65001
    172.16.0.5 from 172.16.0.5 (2.2.2.2)
      Origin IGP, metric 200, valid, external

ISP-A prefers the path via 172.16.0.1 (R1-HQ) because MED 100 < 200.

! Verify MED on our outbound advertisements
R1-HQ# show ip bgp neighbors 172.16.0.2 advertised-routes
   Network          Next Hop         Metric LocPrf Weight Path
*> 10.1.0.0/16      172.16.0.1          100         32768 i

MED vs Other Inbound Traffic Engineering Tools

MED
ScopeSingle neighboring AS
Strength
Weak - only a suggestion, evaluated at step 6
AS-Path Prepending
ScopeAll ASes
Strength
Moderate - affects step 4 globally, but crude
Communities
Scope
Depends on upstream policy
Strength
Strong - if upstream supports action communities (e.g., set local-pref)
More-specific prefixes
ScopeGlobal
Strength
Strongest - longest match always wins in forwarding

For reliable inbound traffic engineering, communities (if supported by your upstream) or more-specific prefix advertisements are more effective than MED. See BGP AS-Path Prepending for the next option.

Troubleshooting

MED set but neighbor ignoring it
Cause
Neighbor's local-pref or AS-path length difference decides before step 6
Fix
MED can't override higher-priority steps. Use communities or AS-path prepending instead.
MED not being compared between paths from different ASes
Cause
Default behavior - MED only compared within same AS
Fix
Enable bgp always-compare-med if cross-AS comparison is needed.
Path without MED winning over path with lower MED
Cause
Missing MED treated as 0 (best) by default
Fix
Configure bgp bestpath med missing-as-worst.

Key Takeaways

  • MED suggests to a neighboring AS which entry point to prefer - lower MED is better. But it's only evaluated at step 6 and can be overridden by local-pref, weight, or AS-path length.
  • By default, MED is only compared between paths from the same AS. Use bgp always-compare-med for cross-AS comparison.
  • MED is non-transitive - it only reaches your direct neighbor, not their upstreams.
  • For stronger inbound traffic control, use communities (if your upstream supports them) or selective prefix advertising over MED.
  • Configure bgp bestpath med missing-as-worst to avoid paths with no MED unexpectedly winning.

Read next

Terminal card showing a repeating CDP native VLAN mismatch log naming Ethernet0/0 native VLAN 1 against SW2 Ethernet0/0 native VLAN 99
VLANs ·

Native VLAN Mismatch: Read the CDP Log, Fix the Trunk

%CDP-4-NATIVE_VLAN_MISMATCH hands you both interfaces and both native VLANs in one line. The real damage is underneath it: untagged frames get re-homed at the trunk boundary and two VLANs quietly become one. Captured live on IOS XE 17.18.2 in CML.