Short answer: BGP MED, also called MULTI_EXIT_DISC, is an optional non-transitive BGP attribute used to suggest which entry point a neighboring autonomous system should use when it sends traffic into your AS. RFC 4271 defines it as a four-octet value that can help discriminate among multiple entry points to a neighboring AS, and Cisco and Juniper both document the operational rule most engineers remember: lower MED is preferred when MED is compared.[1][2][4]
The practical catch is important: MED is a hint, not a command. It can influence inbound traffic from a directly connected neighboring AS, but it does not override that neighbor's local policy, local preference, AS-path decisions, hot-potato routing, or provider-specific traffic-engineering rules.
What MED does in BGP
MED answers this design question: if my AS connects to the same neighbor AS in more than one place, which ingress link should that neighbor prefer for a specific prefix? A lower MED normally means "enter here first" and a higher MED means "use this as a less preferred entrance." Cisco describes MED as an optional, non-transitive hint to external neighbors about the preferred path into an AS with multiple entry points, and Juniper describes the purpose as influencing how other ASs enter your AS for a prefix.[2][4]
Because MED is non-transitive, it is not designed as an Internet-wide steering signal. Your directly connected neighbor may receive it and use it internally, but the attribute is not carried endlessly across unrelated autonomous systems.[1][4]
MED vs LOCAL_PREF vs AS_PATH
| Attribute | Typical use | Who controls it? | Traffic direction |
|---|---|---|---|
| LOCAL_PREF | Choose your own AS exit | Your AS | Outbound |
| MED | Suggest a neighbor's entrance into your AS | You advertise it; neighbor decides whether to honor it | Inbound influence from adjacent AS |
| AS_PATH prepending | Make one path look longer | You advertise a longer path; remote networks decide | Inbound influence, broader than MED but still not guaranteed |
This is why MED is usually not the first tool for choosing your own Internet exit. Use LOCAL_PREF for outbound path selection, use AS_PATH or provider communities when you need broader inbound influence, and use MED when you and the adjacent AS have multiple interconnects where the neighbor is willing to compare MED.
How MED controls traffic
Outbound control
MED does not directly control outbound traffic from your AS. If you receive two routes from upstreams and want your routers to exit ISP-A instead of ISP-B, set LOCAL_PREF, weight, or another local policy on your side. MED is normally something you advertise to the neighbor for prefixes you originate.
Inbound influence
MED can influence inbound traffic from an adjacent AS when that AS receives multiple paths to your prefix from the same neighboring AS. Cisco documents that BGP compares MED values by default only among paths received from the same neighboring AS, and its best-path documentation places lowest MED after weight, local preference, locally originated status, AS-path length and origin code in the selection process.[2][3]
Example: AS 65010 connects to Provider AS 64500 in Warsaw and Frankfurt. For prefix 198.51.100.0/24, you advertise MED 50 in Warsaw and MED 200 in Frankfurt. If Provider AS 64500 compares those two otherwise equal paths, it should prefer Warsaw for traffic toward that prefix.
What MED cannot control
- It cannot force a remote AS to honor your preference.
- It usually cannot influence paths several AS hops away because it is non-transitive.
- It cannot beat the neighbor's higher local preference policy.
- It may not be compared when the competing paths come from different neighboring ASNs, unless the receiving network has intentionally enabled an always-compare-MED style policy.[2][3]
- It cannot fix return-path symmetry through a firewall by itself; NAT, stateful firewall paths, route leaks and provider policies still matter.
Design example: dual interconnects to one provider
Assume an enterprise AS 65010 has two eBGP sessions to Provider AS 64500:
- R1 / Warsaw: best entrance for
198.51.100.0/24. - R2 / Frankfurt: backup or less preferred entrance for the same prefix.
- Goal: make Provider AS 64500 prefer Warsaw when it sends traffic to
198.51.100.0/24.
Provider AS 64500
+---------------------+
| |
MED 50| |MED 200
+----+----+ +----+----+
| R1 WAW | | R2 FRA |
+----+----+ +----+----+
\ /
\ /
Enterprise AS 65010
Prefix: 198.51.100.0/24Cisco IOS-style configuration example
This example sets a lower MED on the preferred Warsaw edge and a higher MED on the Frankfurt edge. The prefix list prevents accidentally applying the metric to every advertised route.
R1 Warsaw - preferred ingress
ip prefix-list OUR-PUBLIC-PREFIX seq 10 permit 198.51.100.0/24
route-map SET-MED-WAW permit 10
match ip address prefix-list OUR-PUBLIC-PREFIX
set metric 50
route-map SET-MED-WAW permit 100
router bgp 65010
neighbor 203.0.113.1 remote-as 64500
neighbor 203.0.113.1 description Provider-AS64500-Warsaw
neighbor 203.0.113.1 route-map SET-MED-WAW out
network 198.51.100.0 mask 255.255.255.0R2 Frankfurt - less preferred ingress
ip prefix-list OUR-PUBLIC-PREFIX seq 10 permit 198.51.100.0/24
route-map SET-MED-FRA permit 10
match ip address prefix-list OUR-PUBLIC-PREFIX
set metric 200
route-map SET-MED-FRA permit 100
router bgp 65010
neighbor 203.0.113.5 remote-as 64500
neighbor 203.0.113.5 description Provider-AS64500-Frankfurt
neighbor 203.0.113.5 route-map SET-MED-FRA out
network 198.51.100.0 mask 255.255.255.0The permit 100 sequence is deliberate. Without it, some route-map designs accidentally suppress all routes that do not match the first sequence. In production, make the catch-all behavior explicit and review it before applying the policy.
Junos-style configuration example
Juniper documents MED as the BGP metric and shows that policy can set the metric advertised in BGP updates.[4] A simplified Junos policy could look like this:
policy-options {
prefix-list OUR-PUBLIC-PREFIX {
198.51.100.0/24;
}
policy-statement SET-MED-WAW {
term OUR-PREFIX {
from {
prefix-list OUR-PUBLIC-PREFIX;
}
then {
metric 50;
accept;
}
}
term REST {
then accept;
}
}
}
protocols {
bgp {
group PROVIDER-AS64500 {
type external;
peer-as 64500;
export SET-MED-WAW;
neighbor 203.0.113.1;
}
}
}Use the same structure on the less preferred edge with a higher metric, for example 200. The exact syntax can vary by Junos release and existing policy structure, so treat this as a readable pattern, not a blind paste.
Packet and policy walkthrough
- Your router originates
198.51.100.0/24into BGP. - The outbound route policy matches that prefix.
- The policy attaches MED 50 on the preferred link and MED 200 on the less preferred link.
- The provider receives two paths from the same customer AS.
- If the provider's earlier best-path criteria are tied and MED comparison is active for those paths, the lower MED path is selected.
- Traffic from that provider AS enters your network through the lower-MED interconnect.
Step 5 is where many troubleshooting cases live. If the provider sets a higher local preference on Frankfurt, chooses hot-potato exit based on its IGP cost, ignores customer MED, or compares only a subset of routes, your MED values may be visible but operationally ineffective.
Verification commands and expected logic
On your advertising routers
show ip bgp neighbors 203.0.113.1 advertised-routes
show ip bgp 198.51.100.0/24
show route-map SET-MED-WAW
show ip prefix-list OUR-PUBLIC-PREFIXExpected logic: the prefix is advertised to the provider, the outbound route-map counter increments, and the path attributes show the intended metric/MED for the advertised route. Some platforms require soft clearing the BGP session or route refresh for a changed outbound policy to be resent.
On the receiving AS, if you can get a looking glass or provider output
show ip bgp 198.51.100.0/24
show bgp ipv4 unicast 198.51.100.0/24
show route receive-protocol bgp 203.0.113.2 198.51.100.0/24Expected logic: both paths are present, the lower MED path is selected only if earlier attributes do not override it, and the selected next hop corresponds to the intended ingress location. Cisco's best-path notes are useful here because MED is not the first criterion in the decision process.[3]
Troubleshooting checklist
- Confirm both routes are actually advertised. A missing
networkstatement, aggregate policy, RPKI rejection, prefix-list mismatch or max-prefix event can make MED irrelevant. - Check whether the route-map matches. Look at route-map counters and prefix-list counters, not just configuration text.
- Check direction. MED must be set outbound toward the neighbor that should use it.
- Check competing attributes. Weight, local preference, locally originated status, AS_PATH length and origin code may decide the path before MED is evaluated in common best-path logic.[3]
- Check same-AS comparison. By default, Cisco compares MED only among paths from the same neighboring AS, unless always-compare-MED behavior is configured.[2]
- Check missing MED behavior. Vendors and configurations differ in how missing MED is treated; avoid relying on implicit defaults when the policy matters.
- Ask the provider what they honor. Many providers prefer customer communities or local-pref products over MED.
- Validate the forwarding path, not only BGP. Use traceroute, flow logs, firewall session tables and interface counters to confirm that traffic really enters on the expected circuit.
Modern usage: data center, EVPN/VXLAN and cloud edge
In data center fabrics, MED is usually less important than underlay reachability, overlay route types, route-target import/export, ECMP, local preference and fabric-specific policy. EVPN/VXLAN designs normally steer tenant reachability with route targets, route type behavior, anycast gateway design, ECMP and local policy rather than Internet-style MED.
At cloud and WAN edges, MED can still be useful when two private links connect to the same provider or cloud interconnect partner and the provider honors MED. For dual-ISP Internet edges, MED is often less useful because the two upstreams are different ASNs; provider communities, prepending and more-specific advertisements usually become more realistic inbound tools.
Interview answer box
Q: What is BGP MED and when would you use it?
MED is an optional non-transitive BGP attribute used to suggest a preferred inbound entry point to a neighboring AS. Lower MED is preferred when it is compared. I would use it when my AS has multiple links to the same adjacent AS and I want to influence which link that neighbor uses to reach one of my prefixes. I would not use MED as my primary outbound-control tool; for outbound traffic I would normally use LOCAL_PREF or another local policy. I would also verify whether the neighbor actually honors MED, because local preference and other policies can override it.
Related reading
- BGP LOCAL_PREF Explained: Outbound Traffic Control, Policy and Troubleshooting
- BGP Attribute - AS_PATH
- How to Influence Inbound and Outbound BGP Traffic: LOCAL_PREF, Prepending and MED
- BGP Table Watch
Summary
MED is useful when the topology is right: multiple links to the same neighboring AS, an agreed policy model, and no earlier BGP attribute overriding the decision. Use it as a precise adjacent-AS inbound influence signal, not as a universal Internet traffic-engineering button.
Post a Comment