Summary

  • BGP's MULTI_EXIT_DISC is a weak, optional and non-transitive suggestion about which of several links into the advertising AS should be preferred. A lower value matters only after stronger local criteria remain equal.
  • The receiving network retains control: it can remove or alter an inbound MED before route selection, and the ordinary rule compares values only among paths learned from the same neighboring AS.
  • Correct use depends on a shared bilateral meaning, complete enough candidate visibility and running proof. Treating unrelated MED scales as one global ranking can create inconsistent choices or persistent oscillation in specific topologies.

Suppose AS 65001 meets AS 65002 in Singapore and Frankfurt. For the same prefix, 65001 advertises MED 20 in Singapore and MED 80 in Frankfurt. The message is intelligible: if the other important path attributes are equal, 65001 would rather receive this traffic in Singapore. It may have more capacity there, a shorter internal path, a cheaper facility or a maintenance constraint elsewhere.

AS 65002 still chooses. It may give the Singapore route a lower LOCAL_PREF because of its own contract. It may accept MED only for selected relationships. It may strip the attribute, replace its value or lack the alternate route at the router making the decision. The smaller number is not a remote write into another network's policy. It is a piece of advice evaluated inside a separately governed system.

RFC 4271 encodes that modest authority in the MULTI_EXIT_DISC attribute. MED is an optional non-transitive four-octet unsigned number. All other factors being equal, the lower metric should be preferred. It may travel from an EBGP edge through IBGP inside the receiving AS, but it must not be forwarded onward to another neighboring AS. The advice is designed to stop at the relationship that gives it context.

The receiver's powers are explicit. A BGP implementation must offer a locally configured mechanism to remove a received MED before calculating preference and selecting a route. An implementation may also alter the received value at that same stage. The sender owns what it announced. The receiver owns whether the number survives and what local consequence follows.

This division was deliberate. RFC 1773 described the former inter-AS metric as a weak factor late in selection. The design sought to prevent a remote operator from making another network absorb or shed traffic when that network had declared a stronger preference. LOCAL_PREF, AS_PATH length and other earlier criteria are not defects that interfere with MED; they are the local authority boundary that keeps the suggestion conditional.

That is why “the lowest MED wins” is wrong. A route with MED 10 can lose to a route with MED 100 when the second route has a better LOCAL_PREF or wins an earlier selection step. RFC 8326 makes the limitation operationally visible: raising MED on a link is an incomplete graceful-maintenance method because it cannot move traffic when the alternate differs in LOCAL_PREF or AS_PATH length before MED is considered.

The ordinary comparison scope is narrower still. RFC 4271 compares MED only among routes learned from the same neighboring AS, as determined from AS_PATH. If three routes come from AS 65001, its values can express a coherent ordering of its three entry points. If another route comes from AS 65003, the number attached by that separate operator was probably calculated from a different topology, cost base or policy. Twenty in one relationship need not mean less than forty in another.

MED therefore does not create a total order. Route A may be preferable to B because both came from one neighboring AS and A has lower MED. Route B may be compared with C on later criteria because C came from a different AS. That does not guarantee that A, B and C form a single transitive ranking. The result can depend on which candidates are grouped, which group winner advances and which information a router can see.

Cisco IOS XR documentation makes the grouping model concrete. Candidate paths are grouped by neighboring AS for MED comparison. A winner emerges from each group, then ordinary selection continues among group winners. This is not merely an implementation trick. It reflects the protocol's limited comparison domain and explains why the order and completeness of candidates can affect the result.

Some products offer an option to compare MED across different neighboring ASes. The option may look like increased consistency because every number enters one contest. In reality it enlarges the authority assigned to remote values. Juniper warns against broad comparison when metric derivations are unrelated, while RFC 3345 calls the approach ill-advised as a general remedy. A uniform numeric field is not proof of a uniform scale.

An organization can deliberately create a common scale. It might rewrite all inbound MED values under its own policy or maintain agreements in which participating neighbors calculate the attribute from an understood service metric. In that case the comparison is local because the receiver supplied the meaning. The governance obligation is to document the group, derivation, missing-value treatment and precedence—not to assume that four octets arriving from the Internet already share a unit.

Missing MED needs the same discipline. Because the attribute is optional, one path may carry a number while another does not. Products and policy controls can treat absence differently. An operator must verify the actual rule rather than infer that missing always means zero, infinity or one particular vendor's chosen value. A silent path attribute still participates through the receiver's interpretation of silence.

Visibility complicates the decision. A full IBGP mesh lets speakers receive more candidate exits. Route reflection and confederations reduce that distribution burden by showing selected paths rather than every candidate everywhere. RFC 4456 warns that, because MED is not always comparable and IGP distance differs by router, some reflected topologies can choose differently from a full mesh.

This is not an argument that routing hierarchy is unsafe. It is an instruction to include candidate visibility in the proof. If one route reflector sees exits A and B, another sees B and C, and the comparisons are not transitive, each can make a locally reasonable choice that invalidates information available elsewhere. Scale savings have altered the decision surface.

RFC 3345 documents bounded cases where this interaction becomes persistent route oscillation. The conditions include particular reflector or confederation structures, partial exit visibility and MED-sensitive decisions. The problem is deterministic under those conditions, not a superstition attached to every deployment. It also cannot be dismissed as random Internet noise: locally valid choices can repeatedly withdraw the information that made another choice valid.

Several mitigations exist, but each changes authority or visibility. Operators can redesign reflector placement, make relevant border routers see one another, assign LOCAL_PREF at the edge, normalize or remove MED, limit which relationships supply it, or deploy path-distribution enhancements. “Always compare” is not a universal cure because it may compare incomparable policy spaces. Eliminating MED everywhere discards useful bilateral advice. The repair must match the proven failure mechanism.

RFC 5004 addresses a related, narrower churn pattern. When an existing external best path and a proposed replacement both survive until a late identifier comparison, the speaker can keep the existing external path rather than switch gratuitously. This reduces some forwarding transitions and can stop the example it analyzes. The RFC explicitly does not claim to remove every persistent oscillation described by RFC 3345.

Temporal behavior supplies another warning. RFC 4451 records implementation problems in which route arrival order and preference for an older path affected MED selection. A stable result should follow defined inputs and policy, not the accident of which UPDATE reached memory first. Deterministic processing controls matter, but the word “deterministic” on a configuration line still needs route-level verification.

The evidence chain begins before traffic. Record the raw route received from each peer, neighboring AS used for grouping, whether MED was present, the post-policy value, LOCAL_PREF, AS_PATH and every candidate visible at the decision point. Ask the router why it selected the winner. Compare border routers and route reflectors rather than relying on one looking glass.

Then cross into forwarding. The selected BGP path must produce the expected FIB next hop, and traffic telemetry must show the intended interconnection carrying the relevant destination flow. A lower MED received and displayed does not prove that it won. A best path in one RIB does not prove that packets at another ingress used it. A quiet link may indicate rerouting, dropped traffic or no demand.

Changes should be tested in both directions. First alter the sender's value for a bounded prefix and observe whether the peer's received and selected states change. Then remove or rewrite the value on the receiver and confirm that local choice follows the declared policy. Test absence, equal values, unequal earlier attributes, multiple neighboring ASes, route withdrawals, reflection paths and rollback. The objective is not to make the number move; it is to prove the scope of its authority.

The relationship contract matters more than the command syntax. If a customer expects its provider to honor MED for two private interconnections, the parties should record which prefixes, address families, links and metric ranges participate; which local preferences precede it; how missing values are treated; when the provider may override it; and which telemetry settles a dispute. Without that context, the attribute remains syntactically valid but commercially ambiguous.

Heng Lu's principle of minimum initial specification fits MED unusually well. The protocol supplies the smallest useful common object: an optional metric, bounded propagation and a conditional comparison. It does not decide what capacity, cost or policy the number represents. Those future choices remain with the networks that operate the routers and bear the consequence.

Running-code primacy defines the acceptance test. A policy document and a successful configuration commit are representations. Received attributes, effective rewrites, visible candidates, selection reasons, FIB next hops and delivered traffic are the system. If the intended door did not receive the packets, the advertised metric did not exercise practical authority.

Data sovereignty here is not ownership of the remote route. It is the ability of each autonomous system to control its own operational state. The sender may describe its preferred ingress. The receiver may accept that advice when it aligns with its contracts and risk. Neither must surrender its decision machinery for coordination to work.

MED succeeds when both parties understand its modesty. A lower number can recommend a door. It cannot guarantee the corridor exists, that every internal router sees it, that stronger local policy agrees or that traffic crossed it. The weak attribute is not unfinished authority. Its weakness is the safeguard that allows one network to advise another without ruling it.

Sources