skip to content

Why does a BGP speaker compare MED only between paths from the same neighbouring AS, and how can that make its choice depend on comparison order?

level: seniorimportance: nice to knowfreq 12%

answer

  1. each AS's own metric scale
  2. neighbouring AS read from AS_PATH
  3. not a total order
  4. group by neighbouring AS first

basics

~20 s

MED is one neighbouring AS's own metric for its entry points, meaningless on another AS's scale, so RFC 4271 compares it only within that AS. That breaks total ordering: pairwise comparison can pick different winners in different orders.

solid answer

~50 s

`MULTI_EXIT_DISC` exists so one neighbouring AS can say which of its several links to you it prefers you to use; its values are that AS's internal metric, so comparing them with another AS's MEDs compares different scales. RFC 4271 therefore removes a route only when another route **from the same neighbouring AS** (read from the first AS in `AS_PATH`) has a lower MED, and treats a missing MED as 0. The catch: MED now eliminates some routes but not others, so the ranking is no longer a total order. A speaker that compares paths two at a time, in arrival order, can reach a different winner than one that applies the rule across the whole set — the result depends on order. Implementations offer to group paths by neighbouring AS first, and RFC 4451 describes how MED with route reflection or confederations can oscillate persistently.

go deeper

for a junior

Recall that MED is a neighbouring network's hint about which of its links to use, that lower wins, and that it is compared only among routes from that one network.

for a middle

Explain why: each AS's MED is its own metric scale; then place the MED step after AS_PATH length and ORIGIN, with a missing MED counting as 0.

for a senior

Show the failure mode: pairwise comparison giving order-dependent winners, the fix of grouping by neighbouring AS, and normalising MED on ingress.

for a principal

Decide whether MED belongs in your design at all, weighing better entry-point choice against non-determinism and oscillation risk alongside route reflection.

## What MED is for `MULTI_EXIT_DISC` (MED) is an optional attribute that a neighbouring AS attaches to the routes it sends you. RFC 4271 §5.1.4 says it is **intended to discriminate among multiple exit or entry points to the same neighbouring AS**: if provider AS 64501 connects to you in two cities, it can send a lower MED on the link it would rather you use. The value is a four-octet number, and **lower is preferred**. The number means whatever AS 64501 wants — often derived from its own IGP cost. AS 64502's MEDs come from a different network with a different scale. Comparing 10 from one with 50 from the other is comparing kilometres with minutes. ## The rule in RFC 4271 Tie-breaker c (§9.1.2.2) removes route *m* only if some other route *n* still under consideration came from the **same neighbouring AS** and has a lower MED: - The **neighbouring AS** is taken from the `AS_PATH`; for a route learned over iBGP it is the AS the other iBGP speaker learned it from. - A route **without** a MED counts as the lowest possible value, **0**. RFC 4451 records that earlier versions of the specification said the opposite (the highest value), and implementations differed. - MED is compared after `AS_PATH` length and `ORIGIN`, and before eBGP over iBGP. ## Why the ranking loses total order Most of the decision compares every route on one scale. MED does not: it splits routes into groups by neighbouring AS and ranks only inside each group. That makes "better than" **non-transitive**, and the outcome can depend on which routes are compared with which. Take a router inside AS 64500 with three iBGP-learned paths to `198.51.100.0/24`, all with equal `LOCAL_PREF`, `AS_PATH` length and `ORIGIN`: | Path | Neighbouring AS | MED | Interior cost to `NEXT_HOP` | |---|---|---|---| | A | 64501 | 10 | 20 | | B | 64501 | 5 | 30 | | C | 64502 | 0 | 25 | **RFC 4271, applied to the whole set:** B removes A (same AS, lower MED). C is from another AS, so it survives. Interior cost: C (25) beats B (30). **Winner: C.** **Two at a time, in arrival order** (a common implementation shortcut): 1. Order A, C, B: A against C — different ASes, MED skipped, cost 20 beats 25, keep A. A against B — same AS, MED 5 beats 10, keep B. **Winner: B.** 2. Order B, C, A: B against C — cost 25 beats 30, keep C. C against A — different ASes, cost 20 beats 25, keep A. **Winner: A.** Identical inputs, three different winners. RFC 4451 §3.7 describes implementations whose MED handling depended on route age and order this way and calls the resulting non-determinism undesirable. ## How operators and implementations cope - **Group by neighbouring AS first.** Many implementations offer an option that compares MED inside each neighbouring-AS group, then compares the group winners, reproducing the RFC's set-wide result regardless of arrival order. - **Compare MED across all ASes.** Implementations also offer to drop the same-AS condition. That restores a total order but compares unlike scales; RFC 4451 §3.3 warns operators to be wary of the side effects. - **Normalise on ingress.** RFC 4451 notes many operators reset MEDs to a fixed value on routes they receive, and avoid 0 and 2^32-1, so implementation differences stop mattering. - **Beware route reflection and confederations.** RFC 4451 §3.4 explains that MED combined with these scaling designs can cause **persistent route oscillation**, because routers that see only part of the paths reach decisions that keep invalidating each other. ## Where MED sits relative to its neighbours in the order MED is tie-breaker c. It is reached only when degree of preference, `AS_PATH` length and `ORIGIN` all tie, and it runs before the eBGP-over-iBGP step and the interior-cost step. That placement is why the example above can turn on interior cost: once MED has removed what it can within each neighbouring AS, the survivors from different ASes go on to the next steps, and those steps compare them on one common scale. ## What to say in an interview 1. MED is one neighbouring AS's metric, so it is compared only within that AS; lower wins, missing counts as 0 in RFC 4271. 2. That partial comparison breaks total ordering, so pairwise evaluation can depend on arrival order. 3. The fixes are grouping by neighbouring AS, normalising MED on ingress, or not relying on MED at all.

  • How does RFC 4271 treat a BGP path that carries no MED?
    As MED 0, the lowest and therefore most preferred value. RFC 4451 notes that earlier versions of the specification assigned the highest value instead, and implementations differed, which is why many operators set every received MED to one fixed value on ingress and avoid 0 and 2^32-1.
  • Why can MED combined with BGP route reflection oscillate?
    A reflector passes on only the path it selected, so different routers decide from different subsets of paths. Because MED gives no total order, each router's choice can change what another advertises, which changes the first router's choice again. RFC 4451 §3.4 describes this persistent oscillation and suggests not comparing MED across neighbouring ASes, or not relying on MED.
  • What does enabling MED comparison across different neighbouring ASes trade away?
    It restores a total order, so arrival order stops mattering, but it compares metrics set by different networks on different scales. RFC 4451 warns operators to be wary of the side effects; it suits only cases where the neighbouring ASes share one MED scheme, such as several ASes run by one organisation.

saying these in an interview costs you the question

  • BGP compares MED across all paths, whatever AS they came from.
  • A higher MED is preferred, as with LOCAL_PREF.
  • RFC 4271 treats a path with no MED as having the worst MED.
  • BGP's decision is always a total order, so arrival order cannot matter.
  • MED is passed on to every AS downstream, like AS_PATH.