What is MED (Multi-Exit Discriminator)?

MED (Multi-Exit Discriminator), labeled METRIC in some vendors' tooling, is a non-binding hint to a neighboring autonomous system about which of several shared links inbound traffic to your network should use. A lower MED value is preferred. Under RFC 4271 it is an optional, non-transitive attribute, so by default it is not propagated beyond the adjacent AS.

How MED works

When you connect to the same neighboring AS in two locations, you can advertise the same prefix from each point with a different MED value. If the neighbor chooses to honor MED, it picks the link with the lower value as the entry point. This is one of the few standard BGP mechanisms that lets the originator of a prefix influence the path of inbound traffic.

• Lower MED = higher preference (the opposite of local-preference).
• Range: 32-bit unsigned integer, 0 to 4,294,967,295.
• Optional, non-transitive attribute: it does not leave the adjacent AS.
• By default compared only between routes from the same neighboring AS.
• A missing MED is often treated as 0, though the exact behavior is vendor-dependent.

MED vs local-preference

These are two different tools acting on opposite sides of a link. Local-preference is a well-known attribute, carried only inside your own AS, and steers outbound traffic: you decide which link traffic leaves on. MED is a signal sent outward and concerns inbound traffic, since you hint to the neighbor where to come in. In the BGP route selection order, local-preference is evaluated far earlier than MED, so your own policy almost always overrides a MED received from others.

Limitations and pitfalls

MED is only a suggestion. The neighbor can ignore it, override it with its own policy (local-preference, AS-path), and by default does not even compare MED across different neighboring ASes unless it enables always-compare-med. Because MED sits low in the route selection order, it is often dominated by earlier steps. For that reason, AS-path prepending or BGP communities agreed with a provider or IXP are more commonly used for real inbound traffic engineering.

MED on the AS202520 SkyPass network

On AS202520 SkyPass we honor MED on IP transit and peering sessions wherever it makes sense, letting customers with PoPs in Warsaw and Wrocław balance inbound traffic across locations. For multihomed customers and those using remote IXP access (THINX, TPIX, WRIX, POZIX, 1-IX) we also expose BGP communities for AS-path prepending and local-preference control, usually more effective than MED alone. If you are planning traffic engineering, our team will help pick the right mix of MED, communities and prepends for your topology.