Stream of Knowledge: Day 18 — BGP MED: Same-AS Comparison, Deterministic MED and `always-compare-med`

Day 18 — BGP MED: Same-AS Comparison, Deterministic MED and `always-compare-med`

at September 13, 2026

Learning objective

Use MED to express a preferred entry point from one neighboring AS, explain Cisco's normal MED comparison scope, distinguish bgp deterministic-med from bgp always-compare-med, and troubleshoot a MED inversion without relying on arrival-order assumptions.

BGP MED: Same-AS Comparison, Deterministic MED and `always-compare-med`

1. Opening — MED is intentionally weaker than many engineers expect

An upstream AS connects to your network at two locations. It advertises the same prefix over both links and wants to tell you which entry point it prefers you to use when sending traffic toward that AS.

That is the classic role of the Multi-Exit Discriminator (MED).

Lower MED is preferred.

But MED is not a universal cross-provider metric. RFC and operational guidance treat it as a relatively weak hint, and Cisco normally limits comparison so MEDs learned from different neighboring ASes are not automatically compared as if they were a common metric.

This scope is the source of many troubleshooting mistakes.

2. What MED communicates

MED lets one AS indicate a preferred entry point to another AS when multiple interconnections exist.

Conceptually:

Upstream AS65010
   Link A MED 50  ---->
                       Enterprise AS65020
   Link B MED 150 ---->

If all earlier path-selection attributes tie and both advertisements are treated as comparable for MED, the lower value 50 is preferred.

MED is an optional non-transitive attribute in the base BGP attribute model. Its policy meaning is generally local between directly related ASes rather than something expected to cross the Internet unchanged.

3. Cisco best-path position

Cisco's documented sequence evaluates MED after earlier attributes such as:

Weight
LOCAL_PREF
local origination
AS_PATH length
ORIGIN

Therefore a lower MED does not rescue a path that already lost to a higher LOCAL_PREF.

This is why MED should not be explained as “BGP's metric” without qualification.

4. Normal comparison scope

A critical Cisco behavior is that MED is normally compared among paths received from the same neighboring AS under the documented best-path rules.

If Path A comes from AS65010 with MED 10 and Path B comes from AS65020 with MED 200, the router does not simply conclude that 10 is better than 200 in the same way it would for two paths from AS65010.

Cisco provides bgp always-compare-med when an operator intentionally wants MED compared across different neighboring ASes.

That command materially changes policy semantics and must not be enabled casually.

5. `bgp deterministic-med` is different

bgp deterministic-med does not mean “compare MED across all ASes.”

Its purpose is to make MED comparison deterministic among paths from the same neighboring AS by grouping/comparing those paths in a consistent way, rather than allowing path arrival order to influence which comparisons occur.

Cisco IOS command documentation states that deterministic MED comparison is not enabled by default in classic IOS behavior; verify the exact target platform/release before treating a default as universal. IOS XR and other implementations can differ.

The key distinction:

bgp deterministic-med → consistent same-neighbor-AS MED comparison ordering.
bgp always-compare-med → compare MED across paths from different neighboring ASes.

They solve different problems.

6. Scenario — Twin Gate MED

Illustrative lab — not a real incident.

Topology

         U1                      U2
       AS65010                 AS65010
       MED 50                  MED 150
          \                     /
           \ eBGP         eBGP /
            \                 /
                 E
              AS65020

Both U1 and U2 belong to the same upstream AS65010 and advertise 203.0.113.0/24 to enterprise router E.

Objective

Keep Weight, LOCAL_PREF, AS_PATH length and ORIGIN equal.
U1 advertises MED 50.
U2 advertises MED 150.
E prefers the lower MED path through U1.
Inject an incorrect MED 250 on U1 and observe the path move to U2.
Explain how deterministic MED matters when more same-AS paths and update-order interactions exist.

7. Prerequisites

Three routers.
U1 and U2 configured with the same ASN 65010 in the closed lab.
Separate directly connected eBGP sessions to E AS65020.
Both upstream routers originate or learn the same lab prefix with equal earlier attributes.
Reachable next hops.

Using two separate routers with one ASN is normal as a lab representation of a multi-router autonomous system, but the underlay between U1 and U2 is omitted because the focus is external MED behavior.

8. Topic-specific configuration excerpt

U1 — advertise MED 50

route-map MED-TO-E permit 10
 set metric 50
!
router bgp 65010
 neighbor 192.0.2.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 192.0.2.2 activate
  neighbor 192.0.2.2 route-map MED-TO-E out
 exit-address-family

U2 — advertise MED 150

route-map MED-TO-E permit 10
 set metric 150
!
router bgp 65010
 neighbor 198.51.100.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 198.51.100.2 activate
  neighbor 198.51.100.2 route-map MED-TO-E out
 exit-address-family

E — AS65020

router bgp 65020
 neighbor 192.0.2.1 remote-as 65010
 neighbor 198.51.100.1 remote-as 65010
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
  neighbor 198.51.100.1 activate
 exit-address-family

The companion lab files include complete interfaces and service-prefix origination.

9. Verification before modification

On E:

show ip bgp 203.0.113.0
show ip route 203.0.113.0
show ip bgp neighbors 192.0.2.1 routes
show ip bgp neighbors 198.51.100.1 routes

Confirm:

both paths are valid;
both next hops resolve;
Weight and LOCAL_PREF tie;
AS_PATH length and ORIGIN tie;
both paths were learned from the same neighboring AS65010;
MED differs: 50 versus 150.

Expected best path: U1 with MED 50, subject to the verified equality of all earlier criteria.

10. Controlled modification — invert U1's MED

On U1:

route-map MED-TO-E permit 10
 set metric 250

After a safe outbound refresh, E should receive:

U1 MED 250
U2 MED 150

If earlier attributes still tie, U2 becomes preferred because 150 is lower.

11. Fault injection

Illustrative lab — not a real incident.

Lab name

Twin Gate MED Inversion

Fault

A maintenance template changes U1's intended MED from 50 to 250.

Symptoms

both eBGP sessions remain Established;
all prefixes remain present;
traffic exits through the secondary interconnection;
no route withdrawal occurs;
the reason is visible only in path-attribute comparison.

This is a policy incident, not a session incident.

12. Troubleshooting sequence

Confirm the affected prefix and expected preferred interconnection.
Verify both eBGP sessions.
Compare Weight and LOCAL_PREF.
Compare AS_PATH length.
Compare ORIGIN.
Confirm the candidate paths came from the same neighboring AS for normal MED comparison.
Read the MED values.
Inspect outbound set metric policy on U1 and U2.
Check whether E has bgp always-compare-med or bgp deterministic-med configured.
Correct the policy and verify stable selection after refresh.

13. Different neighboring ASes: why `always-compare-med` matters

Now imagine U1 is AS65010 and U2 is AS65020.

The numeric values 50 and 150 are no longer automatically treated as a common cross-provider metric under normal Cisco behavior.

If the operator enables:

router bgp 65030
 bgp always-compare-med

Cisco can compare MED across different neighboring ASes.

That is a major policy change. It should be introduced only with a network-wide design rationale, consistency review and rollback plan.

14. Why deterministic MED exists

In networks with several paths from the same neighboring AS, the sequence in which routes arrive can interact with pairwise best-path comparisons. bgp deterministic-med groups same-AS paths so MED comparisons are performed in a deterministic order.

This becomes more important with:

multiple border routers;
route reflectors;
many paths from the same provider AS;
policy changes that cause routes to be reprocessed in different orders.

RFC 4451 discusses MED deployment considerations and the kinds of unexpected behavior that can appear in complex topologies.

A later route-reflector incident lab will revisit MED oscillation and path hiding at larger scale.

15. Root cause and correction

Root cause

U1 advertised a higher MED than intended, causing E to prefer U2 after all earlier criteria tied.

Correction

Restore the intended value:

route-map MED-TO-E permit 10
 set metric 50

Why it works

Both paths originate from the same neighboring AS and are equal through earlier selection stages, so the lower MED path through U1 becomes preferred again.

16. Post-fix verification

On E:

show ip bgp 203.0.113.0
show ip route 203.0.113.0
show running-config | include bgp.*med

On U1/U2:

show route-map MED-TO-E
show ip bgp neighbors <E-peer> advertised-routes

If the lab includes forwarding hosts, verify the actual path after the control-plane change.

17. Rollback

To remove MED rewriting from U1:

router bgp 65010
 address-family ipv4 unicast
  no neighbor 192.0.2.2 route-map MED-TO-E out

If bgp always-compare-med or bgp deterministic-med was introduced as part of an experiment, remove only after verifying the original behavior and network-wide dependency.

Preserve the pre-change route table because MED incidents can be difficult to reconstruct after route refreshes.

18. Production lessons

Protocol lesson

MED is a hint about a preferred entry point, not a universal Internet cost metric.

Selection lesson

Lower MED is preferred only after earlier best-path criteria tie and the paths are eligible for MED comparison.

Scope lesson

Normal Cisco behavior compares MED within the appropriate same-neighbor-AS context; always-compare-med expands that scope.

Determinism lesson

deterministic-med addresses comparison ordering among same-AS paths; it does not mean the same thing as always-compare-med.

Change-management lesson

MED defaults and deterministic behavior differ across platforms. Never assume IOS XE, IOS XR and NX-OS have identical defaults without release-specific documentation.

19. Knowledge check

Q1

Which MED is preferred, 50 or 150, when the paths are comparable and all earlier attributes tie?

Answer: 50, because lower MED is preferred.

Q2

Does bgp deterministic-med cause MED values from different neighboring ASes to be compared?

Answer: No. It makes same-neighbor-AS MED comparison deterministic. bgp always-compare-med is the Cisco feature that expands MED comparison across different neighboring ASes.

Q3

Why can a path with lower MED still lose?

Answer: An earlier best-path criterion such as higher Weight, higher LOCAL_PREF, local origination, shorter AS_PATH or better ORIGIN can decide first.

20. Sources

RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — MULTI_EXIT_DISC and Decision Process.
RFC 4451 — *BGP MULTI_EXIT_DISC (MED) Considerations* — MED deployment and comparison considerations.
Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.18.x: Configuring BGP* — MED in the Cisco best-path sequence.
Cisco — *Connecting to a Service Provider Using External BGP, IOS XE 17.x* — setting MED with set metric and bgp always-compare-med guidance.
Cisco — *Use Multi-Exit Discriminator to Select Best Path for BGP* — bgp deterministic-med behavior.
Cisco — *Cisco IOS IP Routing: BGP Command Reference* — bgp deterministic-med default and command semantics.

Accessed: 2026-08-11.