Origin and MED — the IGP/EGP/incomplete origin and the MED tie-break between same-AS paths

Steps 5 and 6 of the BGP best-path algorithm are the two attributes that an operator uses to influence the path selection between peers — Local Preference is the operator’s AS-wide policy (step 2), Weight is the per-router override (step 1), but Origin and MED are the path properties that the operator can adjust on outbound advertisements to influence how the upstream evaluates the route.

Origin is the well-known mandatory attribute that says how the route was injected into BGP at the origin AS. MED is the optional non-transitive attribute that one AS uses to hint to a neighbouring AS “please send me traffic via this link”. The two attributes are evaluated at adjacent steps (5 and 6) but they have very different semantics and very different operational consequences.

Origin — the IGP/EGP/incomplete code

The Origin attribute has three values, defined by RFC 4271 Section 5.1.5:

The ordering is fixed by the protocol. The operator cannot re-rank Origin values; the operator can only choose how to inject the route to influence the value.

flowchart LR
  subgraph "Origin determination"
    N["address-family ipv4-unicast<br/>network 192.0.2.0/24"] --> I["Origin IGP (i)<br/>preferred"]
    A["address-family ipv4-unicast<br/>aggregate-address 192.0.2.0/22"] --> I
    R["address-family ipv4-unicast<br/>redistribute static"] --> Q["Origin incomplete (?)<br/>least preferred"]
  end

All three injection mechanisms live under the address family on VyOS 1.5, not under the ASN:

set protocols bgp system-as 64512
set protocols bgp address-family ipv4-unicast network '192.0.2.0/24'
set protocols bgp address-family ipv4-unicast aggregate-address '192.0.2.0/22' summary-only
set protocols bgp address-family ipv4-unicast redistribute static

and they produce three different Origin values:

• network <prefix> produces Origin IGP. The operator explicitly enumerates the prefix. The route is a “first-class” BGP route.
• aggregate-address <prefix> produces Origin IGP for the aggregate itself. The component routes (the more-specifics that were aggregated) may have other Origin values; the aggregate inherits IGP from the aggregate statement.
• redistribute <proto> produces Origin incomplete. The route was learned from another routing protocol (OSPF, static, connected, etc.) and injected into BGP.

The standard production pattern is network for prefixes the operator owns and can enumerate, and redistribute only for routes that cannot be enumerated (very large tables or dynamic peers). The Origin difference is the canonical reason: network produces IGP, redistribute produces incomplete, and the upstream preference (step 5) is IGP < incomplete.

The MED attribute — the optional inbound-traffic hint

MED is the optional non-transitive attribute (RFC 4271 Section 5.1.4) that lets one AS hint to a neighbouring AS “please send me traffic via this link”. The semantics:

• Lower MED wins. MED is the opposite of Local Preference: lower is preferred.
• MED is optional. A route without MED is treated as having MED 0 by default (or as having MED 4294967295 if set protocols bgp parameters bestpath med missing-as-worst is configured).
• MED is non-transitive. A route with MED set is re-advertised to iBGP peers without the MED (the MED is for the direct neighbouring AS only).
• MED is only compared between paths from the same neighbouring AS. The standard practice is to compare MED only when the paths came from the same AS. Comparing MED across ASes is non-standard and configurable with bgp always-compare-med.

The MED is the canonical inbound-traffic-engineering tool between two ASes. The operator who runs AS 64512 and peers with AS 65001 at two locations (e.g., London and New York) sets MED 50 on routes advertised to the London link and MED 100 on routes advertised to the New York link. AS 65001’s border routers see the two routes and prefer the lower MED (London) — assuming they do the standard comparison.

Configuring MED on VyOS 1.5 LTS

The route-map applies the MED on the outbound direction (the advertisement to the peer):

configure
set policy route-map MED-PRIMARY rule 10 action 'permit'
set policy route-map MED-PRIMARY rule 10 description 'TE: prefer the London link inbound'
set policy route-map MED-PRIMARY rule 10 set metric '50'

set policy route-map MED-BACKUP rule 10 action 'permit'
set policy route-map MED-BACKUP rule 10 description 'TE: New York is the backup inbound path'
set policy route-map MED-BACKUP rule 10 set metric '100'

set protocols bgp system-as 64512
set protocols bgp neighbor 192.0.2.2 remote-as '65001'
set protocols bgp neighbor 192.0.2.2 address-family ipv4-unicast route-map export 'MED-PRIMARY'
set protocols bgp neighbor 198.51.100.1 remote-as '65001'
set protocols bgp neighbor 198.51.100.1 address-family ipv4-unicast route-map export 'MED-BACKUP'
commit
save

Both peers are in the same AS (65001). The local router advertises routes to 192.0.2.2 with MED 50 and to 198.51.100.1 with MED 100. AS 65001’s border routers see the two routes and prefer the lower MED (50) — inbound traffic to the local AS flows preferentially through 192.0.2.2 (the primary link).

The operator can also set MED on a per-prefix basis:

set policy prefix-list CUSTOMER-A rule 10 action 'permit'
set policy prefix-list CUSTOMER-A rule 10 prefix '198.51.100.0/24'

set policy route-map MED-LOW rule 10 action 'permit'
set policy route-map MED-LOW rule 10 match ip address prefix-list 'CUSTOMER-A'
set policy route-map MED-LOW rule 10 set metric '20'

set policy route-map MED-LOW rule 99 action 'permit'
set policy route-map MED-LOW rule 99 description 'everything else, unmodified'

set protocols bgp neighbor 192.0.2.2 address-family ipv4-unicast route-map export 'MED-LOW'

Only 198.51.100.0/24 is advertised with MED 20; rule 99 passes every other prefix through with whatever MED it already had.

Why MED is only compared between paths from the same AS

The protocol’s MED comparison rule (RFC 4271) is conservative: compare MED only when the paths are from the same neighbouring AS. The reason is policy. The AS that sets MED is hinting to its neighbour; the neighbour is the only AS that should compare that hint. Mixing MED from different ASes would compare hints from different neighbours, which is not what the operator intended.

In practice, the comparison is done by the receiver’s BGP table. The receiver checks the “leftmost” AS in the AS_PATH (the most recent AS that advertised the route). If the leftmost AS is the same for two paths, the MED is compared. If not, the MED is ignored.

The default in FRR is to NOT compare MED across ASes. The knob that enables cross-AS comparison is set protocols bgp parameters always-compare-med, which renders as FRR’s bgp always-compare-med. The operator who configures it is opting into a behaviour the neighbouring ASes are not obliged to match — and because it is a local decision, two routers in the same AS can disagree about which path wins simply because one of them has it and the other does not. Configure it estate-wide or not at all.

The MED-ignored failure mode

The most common MED failure is: the operator sets MED on routes advertised to upstream A and expects the upstream to compare. The upstream does not, because the paths are from different ASes (the operator’s MED is on routes advertised to AS A, but the upstream is comparing two routes from AS A and AS B, both advertising the same prefix).

# Wrong: MED is not compared across ASes
set protocols bgp neighbor 192.0.2.2 address-family ipv4-unicast route-map export 'MED-LOW'
set protocols bgp neighbor 198.51.100.1 address-family ipv4-unicast route-map export 'MED-HIGH'

Upstream’s view:

• Route 1: from AS 65001 (peer 192.0.2.2), MED 50
• Route 2: from AS 65002 (peer 198.51.100.1), MED 100

The upstream sees two routes from different ASes. MED is not compared (the leftmost AS is different). The upstream falls through to step 7 (eBGP over iBGP), step 8 (IGP cost), and step 9 (router-id).

The fix is to use MED only when the upstreams are in the same AS (the canonical multihomed-to-one-ISP scenario). The operator who peers with two different ASes cannot use MED to influence the upstream’s selection — they need AS Path prepending (lesson vyos-xxvii-03-as-path-prepending) for that.

The deterministic-med knob

The default MED comparison order is router-dependent. The first path seen by the router is the “best” (after steps 1-5); later paths are compared against the best. If two routers in the same AS see the same paths in different orders, they may pick different “best” paths.

The bgp deterministic-med knob (RFC 4098 and Cisco-influenced) makes the comparison order-independent. With deterministic-med, the router sorts all paths by leftmost AS, then by MED, then by router-id, before evaluating the best-path algorithm. The result: all routers in the AS pick the same path.

set protocols bgp parameters deterministic-med

The VyOS renderer generates:

router bgp 64512
 bgp deterministic-med

Note the shape of the CLI path. deterministic-med sits directly under parameters, not under parameters bestpath — it mirrors FRR, where bgp deterministic-med is a global BGP command while bgp bestpath med ... is a bestpath sub-command. The two MED knobs in the next sections are under bestpath. Guessing the placement from the name gets it wrong roughly half the time; the tab-completion at set protocols bgp parameters is the answer.

The knob is recommended for any multihomed AS with multiple border routers. Without it, operators may see different best-path winners on different routers — a divergence that produces asymmetric traffic and is hard to attribute, because both routers are behaving correctly according to the order they happened to receive updates in.

The med missing-as-worst knob

The default behaviour for a route with no MED is to treat the missing MED as 0 (the most preferred). The bestpath med missing-as-worst knob inverts the default: a route with no MED is treated as MED 4294967295 (the least preferred).

The use case: an upstream sends routes without MED (because the operator did not set MED) and the operator wants those routes to be deprioritised. The knob is the operator’s way to say “no MED is the worst MED”.

set protocols bgp parameters bestpath med missing-as-worst

The operator who configures this knob and then sees their peers’ routes lose to paths they did not expect needs to check that the peers are actually setting MED at all. The knob is global: it affects every path with a missing MED, from every peer, in every address family — not just the peer whose behaviour prompted it. If the intent is “deprioritise routes from this peer”, the tool is a route-map import that sets a lower Local Preference on that peer’s routes, which is scoped to the peer and evaluated three steps earlier.

The med confed knob

For confederation ASes, set protocols bgp parameters bestpath med confed extends the MED comparison to include confederation sub-ASes. Without it, MED is only compared between paths from the same sub-AS. With it, MED is compared across the entire confederation.

The knob is only relevant for confederation deployments. The operator who is not running a confederation does not need it — and configuring it anyway is not harmless clutter, because the next operator will read it as evidence that a confederation exists somewhere in the design and go looking for it.

How the result is validated

show ip bgp 198.51.100.0/24
show ip bgp neighbors 192.0.2.2 advertised-routes

The first shows the Origin code and the Metric column for each candidate path in the local table — the i, e or ? at the end of the path line is the Origin, and Metric is the MED. The second is the one that answers the question this lesson is about: it lists what the local router is actually sending to that peer, with the MED the export map produced. Read it after every MED change, and count the prefixes, because an outbound map that dropped its terminating permit rule shows up here as a short list rather than as an error.

For deep debugging:

vtysh -c 'show ip bgp 198.51.100.0/24'

How it fails

The production failure modes the engineer must recognise:

• Origin incomplete everywhere because of redistribute. The operator uses redistribute static for prefixes they own. The upstream sees Origin incomplete and deprioritises them. The fix is network.
• MED set on routes to upstreams in different ASes. The operator sets MED on a route-map applied to AS A and AS B. The upstream’s algorithm does not compare MED across ASes. The MED has no effect.
• MED set to a value the upstream does not honour. The upstream has a per-peer Local Preference that overrides MED. The MED is set but the upstream ignores it. The operator sees no effect.
• Different best-path winners on different routers. The AS is multihomed with multiple border routers and deterministic-med is not configured. The routers see the paths in different orders and pick different winners. The fix is set protocols bgp parameters deterministic-med on every border router, followed by a session reset so the existing entries are re-compared.
• Missing MED treated as 0 (most preferred). The upstream sends a route without MED. The operator’s router treats it as MED 0 (the most preferred) and installs it. The fix is set protocols bgp parameters bestpath med missing-as-worst if “no MED is the worst MED” is the intended policy — remembering that it is global, not per-peer.
• The export map is bound to the wrong address family. route-map export sits under address-family ipv4-unicast; the same peer’s IPv6 advertisements are governed by the ipv6-unicast binding. A MED configured once and expected to cover both families covers one, and the symptom is “the upstream honours my MED for v4 and ignores it for v6”.
• The export map has no terminating permit rule. The implicit deny at the end of a route-map withdraws every prefix the map did not explicitly match. The session stays up and the advertisement set collapses, which reads as a peer problem rather than a local one.
• MED advertised but stripped by a downstream peer. The MED is non-transitive; an iBGP speaker that receives a route with MED strips it before re-advertising. The operator expecting MED to flow iBGP-wide is surprised.

Rollback

Origin and MED changes are configuration changes. The standard rollback path applies:

• compare before commit to see the route-map addition, and read it for what the map does not match as well as what it does.
• commit-confirm <timeout> for any remote change. An outbound policy change can withdraw the prefixes carrying your own management traffic.
• The narrow revert, which is usually the right one: delete protocols bgp neighbor 192.0.2.2 address-family ipv4-unicast route-map export detaches the map without touching anything else, and restores full advertisement to that peer immediately. Reach for this first during a live incident.
• load /config/archive/<known-good-file>, then compare, then commit-confirm, to revert to a specific snapshot. load only fills the candidate, so compare is where you find out what else the snapshot would undo.

Prefer either of those to rollback N, which applies the stored revision and then restarts the router — on a border router that converts one unwanted MED into every session down for the length of a boot. vyos-vi-06-remote-change-discipline covers the reasoning.

Production discipline

Cross-course references

The Linux course’s XIX-Linux-NetFoundations covers the kernel FIB. The OPNsense course’s XXX-OPNsense-DynamicRouting covers the same FRR route-map pattern on the firewall side. The BGP lessons vyos-xxvi-03-origin (the Origin attribute in detail), vyos-xxvi-04-med (the MED attribute in detail), and vyos-xxvii-01-best-path-algorithm (the eleven-step algorithm) cover the broader context. The lesson vyos-xxvii-03-as-path-prepending covers the complementary inbound traffic-engineering tool for paths from different ASes. The lesson vyos-xxvii-06-best-path-troubleshoot walks the debugging of wrong-path-wins failures.

Quiz