BGP MED Attribute

What MED Is

MULTI_EXIT_DISC (MED, Type code 4) is the path attribute used to tell a neighboring AS which entry point it should use to reach the local AS. As covered in BGP Path Attributes and Best Path Selection, it is classified as optional non-transitive.

“Optional” means not every implementation is required to understand it; “non-transitive” means an implementation that does not understand it discards the attribute instead of passing it on. In practice there is hardly an implementation that fails to understand MED, but being non-transitive maps directly onto how it behaves: MED does not automatically spread past the AS that receives it.

Item	Description
Type code	4
Classification	Optional non-transitive
Value	A 4-byte unsigned integer. Lower is preferred
Default	None (the attribute is simply absent)
Propagation scope	As far as the neighboring AS. Not carried when that AS advertises onward to another AS
Definition	RFC 4271 section 5.1.4

The direction — lower is preferred — is the opposite of LOCAL_PREF, where higher wins. Think of MED as a cost or a distance, the same feel as an IGP metric, and it is easier to remember. IOS XR shows it in the Metric column of show bgp.

What It Communicates

When the local AS has more than one point of contact with a neighboring AS, MED is the way to tell that neighbor which of those points to come in through.

Suppose AS 65001 connects to AS 65002 in two places, at R1 and at R2. Even if AS 65001 decides “the link at R2 is the fatter one, so please send traffic for our 192.168.0.0/24 in through R2,” the routers making that decision belong to AS 65002. So AS 65001 attaches a low MED to the routes it advertises from R2 and a high MED to the ones it advertises from R1. If AS 65002 looks at MED, the path via R2 wins.

The important part is that MED is only a request. The receiving side is free to ignore it or overwrite it with its own policy. It also sits below LOCAL_PREF and AS_PATH length in best path selection (6th), so if the neighbor has already picked an exit with LOCAL_PREF, MED never gets its turn.

Attribute	Who decides	What it steers
`LOCAL_PREF`	You (settled inside your own AS)	The exit out of your AS
`MULTI_EXIT_DISC` (MED)	The neighbor (you only ask)	The entry point from the neighboring AS into your AS

Each path attribute propagates over a different scope, and MED sits one step outside LOCAL_PREF.

Attribute	Propagation scope
WEIGHT	The local router only (never advertised; Cisco-specific, not an RFC attribute)
`LOCAL_PREF`	The local AS only (carried on iBGP, never on eBGP)
`MULTI_EXIT_DISC` (MED)	As far as the neighboring AS (by default not passed beyond it)
`AS_PATH`	Every AS the route traverses

By Default It Only Compares Paths From the Same Neighboring AS

This is the point about MED that is most often misunderstood. By default, MED is only compared between paths received from the same neighboring AS.

RFC 4271 section 9.1.2.2 restricts the MED comparison in best path selection to paths whose neighboring AS is the same. RFC 4451 is the document that works through that condition in more detail.

The reason is that each AS picks its MED values from its own internal circumstances — link capacity, IGP cost and so on. The “50” that AS 65001 attaches and the “10” that AS 65003 attaches share no common yardstick. Comparing them would be meaningless, so by default they are not compared.

In the verification lab below, R4 learns 192.168.6.0/24 over three paths.

Path	Received from	Neighboring AS	`AS_PATH`
via R1	R1 (10.1.4.1)	AS 65001	`65001 65004`
via R2	R2 (10.2.4.2)	AS 65001	`65001 65004`
via R5	R5 (10.4.5.5)	AS 65003	`65003 65004`

All three have an AS_PATH length of 2, so the comparison runs all the way down to MED. The paths via R1 and via R2 share the same neighboring AS 65001 and are compared by MED, but the path via R5 comes from a different neighboring AS, so no matter how small its MED is, it never enters the comparison. STEP 1 and STEP 2 demonstrate this on real hardware.

The MED verification lab topology. R1 and R2 in AS 65001 peer eBGP with R4 in AS 65002, and R4 also peers with R5 in AS 65003. R5 peers with R6 in AS 65004, and R6 also peers with R1. R4 learns the 192.168.6.0/24 that R6 advertises over three paths

Where It Sits in Best Path Selection

MED is evaluated 6th in best path selection. In the order given in BGP Path Attributes and Best Path Selection, it comes right after ORIGIN (5th).

Rank	Comparison
1	WEIGHT (higher wins; Cisco-specific)
2	`LOCAL_PREF` (higher wins)
3	Routes originated by the local AS
4	`AS_PATH` length (shorter wins)
5	`ORIGIN` (IGP < EGP < incomplete)
6	MED (lower wins; by default only among paths from the same neighboring AS)
7	eBGP-learned over iBGP-learned

Sitting that low means attaching a MED has no effect if something higher up has already settled the contest. To make MED matter, the paths you want compared have to be tied through the first five steps. That is why all three paths in the verification lab are built with an AS_PATH length of 2.

What Happens to MED on Re-advertisement

MED is an attribute that reaches “as far as the neighboring AS,” but how it is handled inside the AS (over iBGP) and what happens when it is handed to yet another AS have to be considered separately.

Direction of re-advertisement	How MED is handled
To an iBGP peer	The received value is carried through unchanged (absent stays absent)
To an eBGP peer	The received value is not carried over. Unless you attach one yourself, the attribute disappears

It disappears toward eBGP because MED describes how to choose an entry point into your AS, which is a meaningless value for the AS beyond. It is carried through on iBGP because every router in the AS needs to share the same view of which entry point the neighboring AS is recommending.

The two are placed side by side for the same prefix in STEP 1 of Verification on Real Hardware.

Configuration

To attach a MED on IOS XR, use set med in a route-policy and apply it outbound on the neighbor.

Advertising with a MED attached (R1 attaching 200 toward R4)
route-policy MED-200-OUT
  set med 200
  pass
end-policy
!
router bgp 65001
 neighbor 10.1.4.4
  address-family ipv4 unicast
   route-policy MED-200-OUT out

The settings that change the comparison scope go directly under router bgp.

Command	Effect
`bgp bestpath med always`	Compare MED even between paths from different neighboring ASes
`bgp bestpath med missing-as-worst`	Treat a path with no MED as the worst value (4294967295)
`bgp bestpath med confed`	Compare MED for paths within a confederation

Changing the comparison scope (applied on R4)
router bgp 65002
 bgp bestpath med always
 bgp bestpath med missing-as-worst

Note that bgp deterministic-med (the IOS XE setting that groups paths from the same AS before comparing them) does not exist on IOS XR 26.1.1. Entering it is rejected with % Invalid input detected. IOS XR always uses an equivalent comparison order, so the setting is unnecessary there.

Without missing-as-worst, the default behaviour is that a path with no MED is treated as 0. That means “the one without a MED wins,” which is the opposite of the intuition. Be careful when you attach a MED on only one side.

Verification on Real Hardware

Six XRd 26.1.1 routers were used, split across four ASes: AS 65001 (R1, R2, R3), AS 65002 (R4), AS 65003 (R5) and AS 65004 (R6).

AS 65001 connects to R4 in AS 65002 over eBGP in two places, at R1 and at R2. R3 is an internal router, and the three are tied together by an iBGP full mesh over Loopback0 (with next-hop-self) and OSPF area 0
R4 also connects to R5 in AS 65003; R5 connects to R6 in AS 65004, and R6 connects back to R1 over eBGP
R6 advertises 192.168.6.0/24. R4 learns it three ways — via R1, via R2 and via R5 — all with an AS_PATH length of 2
The eBGP neighbors carry route-policy PASS-ALL in/out (which only does pass) and soft-reconfiguration inbound always

The object under observation is consistently 192.168.6.0/24 as seen from R4.

STEP 0: No MED anywhere (initial state)

First, the state with no MED configured at all. R4 holds three paths.

R4: show bgp 192.168.6.0/24 (STEP 0)
RP/0/RP0/CPU0:R4#show bgp 192.168.6.0/24

Tue Sep  8 03:56:39.309 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 11           11
Last Modified: Sep  8 03:50:44.774 for 00:05:54
Paths: (3 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65001 65004, (received & used)
    10.1.4.1 from 10.1.4.1 (10.0.0.1)
      Origin IGP, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 11
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Not advertised to any peer
  65001 65004, (received & used)
    10.2.4.2 from 10.2.4.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #3: Received by speaker 0
  Not advertised to any peer
  65003 65004, (received & used)
    10.4.5.5 from 10.4.5.5 (10.0.0.5)
      Origin IGP, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

None of the three paths shows a metric. The attribute itself is absent. The AS_PATH length is 2 on all of them and ORIGIN is IGP on all of them, so nothing separates them through the first five comparisons, and Path #1 (via R1) ends up best on a later tiebreak such as router ID.

STEP 1: MED 200 on R1→R4, 50 on R2→R4 and 77 on R6→R1

AS 65001 tells R4 “please come in through R2.” 200 is configured outbound on R1 and 50 outbound on R2. MED 77 from R6 toward R1 is configured at the same time, for the re-advertisement check later on.

The configuration applied on R1 (R2 uses 50 and R6 uses 77, same shape)
route-policy MED-200-OUT
  set med 200
  pass
end-policy
!
router bgp 65001
 neighbor 10.1.4.4
  address-family ipv4 unicast
   route-policy MED-200-OUT out

Values appear in the Metric column of R4’s BGP table, and the best path moves to the one via R2.

R4: show bgp (STEP 1)
RP/0/RP0/CPU0:R4#show bgp

Tue Sep  8 04:05:33.326 UTC
BGP router identifier 10.0.0.4, local AS number 65002
BGP generic scan interval 60 secs
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000000   RD version: 21
BGP main routing table version 21
BGP NSR Initial initsync version 5 (Reached)
BGP NSR/ISSU Sync-Group versions 0/0
BGP scan interval 60 secs

Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*  192.168.1.0/24     10.1.4.1               200             0 65001 i
*>                    10.2.4.2                50             0 65001 i
*  192.168.2.0/24     10.1.4.1               200             0 65001 i
*>                    10.2.4.2                50             0 65001 i
*  192.168.3.0/24     10.1.4.1               200             0 65001 i
*>                    10.2.4.2                50             0 65001 i
*> 192.168.4.0/24     0.0.0.0                  0         32768 i
*> 192.168.5.0/24     10.4.5.5                 0             0 65003 i
*  192.168.6.0/24     10.1.4.1               200             0 65001 65004 i
*>                    10.2.4.2                50             0 65001 65004 i
*                     10.4.5.5                               0 65003 65004 i

Processed 6 prefixes, 11 paths

Looking at the three rows for 192.168.6.0/24: via R1 is 200, via R2 is 50, and via R5 has an empty Metric column (no MED). The *> (best) marker is on the row via R2.

The detailed view shows the same thing.

R4: show bgp 192.168.6.0/24 (STEP 1)
RP/0/RP0/CPU0:R4#show bgp 192.168.6.0/24

Tue Sep  8 04:05:34.769 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 21           21
Last Modified: Sep  8 04:02:44.774 for 00:02:50
Paths: (3 available, best #2)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Not advertised to any peer
  65001 65004, (received & used)
    10.1.4.1 from 10.1.4.1 (10.0.0.1)
      Origin IGP, metric 200, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65001 65004, (received & used)
    10.2.4.2 from 10.2.4.2 (10.0.0.2)
      Origin IGP, metric 50, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 21
      Origin-AS validity: (disabled)
  Path #3: Received by speaker 0
  Not advertised to any peer
  65003 65004, (received & used)
    10.4.5.5 from 10.4.5.5 (10.0.0.5)
      Origin IGP, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

best #1 has become best #2, and best is now on Path #2 (via R2, metric 50). The two paths that arrived from the same neighboring AS 65001 were compared by MED, and the lower value won. R4 now comes in through R2, exactly as AS 65001 intended.

Over iBGP, MED Is Carried Through Unchanged

Still in STEP 1, follow the MED 77 that R6 attached toward R1. First, what R1 received.

R1: show bgp 192.168.6.0/24 (STEP 1)
RP/0/RP0/CPU0:R1#show bgp 192.168.6.0/24

Tue Sep  8 04:04:04.364 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  9            9
Last Modified: Sep  8 04:02:56.774 for 00:01:07
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.4 
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.1.4.4        
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.4 
  Advertised IPv4 Unicast paths to peers (in unique update groups):
    10.1.4.4        
  65004, (received & used)
    10.1.6.6 from 10.1.6.6 (10.0.0.6)
      Origin IGP, metric 77, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 9
      Origin-AS validity: (disabled)

R1 received it as metric 77. Looking at the same route after it crossed iBGP to R3, the value is unchanged.

R3: show bgp 192.168.6.0/24 (STEP 1)
RP/0/RP0/CPU0:R3#show bgp 192.168.6.0/24

Tue Sep  8 04:05:10.332 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 10           10
Last Modified: Sep  8 04:02:56.774 for 00:02:13
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  65004, (received & used)
    10.0.0.1 (metric 2) from 10.0.0.1 (10.0.0.1)
      Origin IGP, metric 77, localpref 100, valid, internal, best, group-best
      Received Path ID 0, Local Path ID 1, version 10

Still metric 77. The (metric 2) near the start of that line is the IGP cost to the NEXT_HOP, a different thing entirely — do not confuse the two. The MED is the metric 77 that follows Origin IGP,.

The actual UPDATE packet confirms it. This is the iBGP UPDATE R1 sent to R3.

No.143 R1 → R3 (iBGP) tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 67
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 44
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.0.1
                IPv4 Address: 10.0.0.1
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.6.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.6.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65004 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 6
            AS Path segment: 65004
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 1
                AS4: 65004
        Path Attribute - MULTI_EXIT_DISC: 77
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 77
        Path Attribute - LOCAL_PREF: 100
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: LOCAL_PREF (5)
            Length: 4
            Local preference: 100

MULTI_EXIT_DISC: 77 is carried as is. Because this is headed for an iBGP peer, LOCAL_PREF: 100 rides along too.

Download the pcap of the packet in the tshark output above (No.143, an iBGP UPDATE)

Over eBGP, MED Is Not Carried Over

Now the same 192.168.6.0/24, this time as R1 hands it to R4 over eBGP.

No.75 R1 → R4 (eBGP) tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 64
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 41
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.1.4.1
                IPv4 Address: 10.1.4.1
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.6.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.6.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65001 65004 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: 65001 65004
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 2
                AS4: 65001
                AS4: 65004
        Path Attribute - MULTI_EXIT_DISC: 200
            Flags: 0x80, Optional, Non-transitive, Complete
<snip>
            Type Code: MULTI_EXIT_DISC (4)
            Length: 4
            Multiple exit discriminator: 200

It reads MULTI_EXIT_DISC: 200. The 77 received from R6 was not carried over; it was replaced by the value R1 attached with its own outbound policy (set med 200). LOCAL_PREF is absent because this is headed for an eBGP peer.

Download the pcap of the packet in the tshark output above (No.75, an eBGP UPDATE)

Summarising how R1 re-advertised the same prefix in the two directions:

Re-advertised to	Packet	MED value
R3 (iBGP)	No.143	77 (the value received from R6)
R4 (eBGP)	No.75	200 (the value from R1’s outbound policy)

Had R1 not been configured with set med, the eBGP UPDATE would carry no MULTI_EXIT_DISC attribute at all. In fact the other route inside that same No.143 UPDATE, 192.168.5.0/24 (which R1 received from AS 65002 with no MED), has no MULTI_EXIT_DISC on it: absent stays absent as it flows into iBGP.

STEP 2: A smaller MED on a path from a different neighboring AS

This is the heart of it. MED 10 is attached from R5 toward R4 — smaller than the 200 via R1 and the 50 via R2, but its neighboring AS is AS 65003, different from the other two (AS 65001).

R4: show bgp 192.168.6.0/24 (STEP 2)
RP/0/RP0/CPU0:R4#show bgp 192.168.6.0/24

Tue Sep  8 04:07:35.810 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 21           21
Last Modified: Sep  8 04:02:44.774 for 00:04:51
Paths: (3 available, best #2)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Not advertised to any peer
  65001 65004, (received & used)
    10.1.4.1 from 10.1.4.1 (10.0.0.1)
      Origin IGP, metric 200, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65001 65004, (received & used)
    10.2.4.2 from 10.2.4.2 (10.0.0.2)
      Origin IGP, metric 50, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 21
      Origin-AS validity: (disabled)
  Path #3: Received by speaker 0
  Not advertised to any peer
  65003 65004, (received & used)
    10.4.5.5 from 10.4.5.5 (10.0.0.5)
      Origin IGP, metric 10, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

Path #3 now carries metric 10, but the best path stays at best #2. The path with the smallest MED of the three is not chosen, and that result is the proof that by default MED is only compared between paths from the same neighboring AS.

From R4’s point of view, the comparison ran like this.

Path	Neighboring AS	MED	How it was treated
Path #1 (via R1)	AS 65001	200	Compared against Path #2 → loses
Path #2 (via R2)	AS 65001	50	Compared against Path #1 → wins → best
Path #3 (via R5)	AS 65003	10	No comparison (no counterpart from the same neighboring AS)

STEP 3: Applying bgp bestpath med always on R4

bgp bestpath med always is added on R4 so that MED is compared even when the neighboring AS differs.

The configuration applied on R4 (STEP 3)
router bgp 65002
 bgp bestpath med always

R4: show bgp 192.168.6.0/24 (STEP 3)
RP/0/RP0/CPU0:R4#show bgp 192.168.6.0/24

Tue Sep  8 04:10:53.495 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 23           23
Last Modified: Sep  8 04:10:17.774 for 00:00:35
Paths: (3 available, best #3)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Not advertised to any peer
  65001 65004, (received & used)
    10.1.4.1 from 10.1.4.1 (10.0.0.1)
      Origin IGP, metric 200, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Not advertised to any peer
  65001 65004, (received & used)
    10.2.4.2 from 10.2.4.2 (10.0.0.2)
      Origin IGP, metric 50, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #3: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65003 65004, (received & used)
    10.4.5.5 from 10.4.5.5 (10.0.0.5)
      Origin IGP, metric 10, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 23
      Origin-AS validity: (disabled)

best #2 has become best #3: the path via R5 (AS 65003), which holds the smallest MED, is now best. A single added line moved a best path that would not budge in STEP 2. This is “the set of paths MED compares depends on configuration,” shown directly.

Note that prefixes such as 192.168.1.0/24, which only ever had two paths from AS 65001, keep the same best path under this setting. Nothing was added to their comparison.

STEP 4: Treating a path with no MED as the worst value

The MED on R5→R4 is removed (back to route-policy PASS-ALL out), and bgp bestpath med missing-as-worst is added on R4 instead. bgp bestpath med always stays in place.

The configuration on R4 (STEP 4)
router bgp 65002
 bgp bestpath med always
 bgp bestpath med missing-as-worst

R4: show bgp 192.168.6.0/24 (STEP 4)
RP/0/RP0/CPU0:R4#show bgp 192.168.6.0/24

Tue Sep  8 04:14:35.524 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 26           26
Last Modified: Sep  8 04:13:54.774 for 00:00:40
Paths: (3 available, best #2)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Not advertised to any peer
  65001 65004, (received & used)
    10.1.4.1 from 10.1.4.1 (10.0.0.1)
      Origin IGP, metric 200, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65001 65004, (received & used)
    10.2.4.2 from 10.2.4.2 (10.0.0.2)
      Origin IGP, metric 50, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 26
      Origin-AS validity: (disabled)
  Path #3: Received by speaker 0
  Not advertised to any peer
  65003 65004, (received & used)
    10.4.5.5 from 10.4.5.5 (10.0.0.5)
      Origin IGP, metric 4294967295, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

Path #3, whose MED was removed, is displayed as metric 4294967295. That is the maximum of a 4-byte unsigned integer — the result of missing-as-worst reading “no MED” as the worst possible value. The best path is back on Path #2 (metric 50).

Without this setting, a missing MED is treated as 0. In this setup, where bgp bestpath med always is also in effect, leaving out missing-as-worst would make Path #3 win outright at a value of 0. Keep that default direction in mind whenever you attach a MED on only one side.

STEP 5: Removing everything (final state)

The set med policies on R1, R2 and R6 and both bgp bestpath med lines on R4 were deleted, returning the configuration to the same state as STEP 0.

R4: show bgp 192.168.6.0/24 (STEP 5)
RP/0/RP0/CPU0:R4#show bgp 192.168.6.0/24

Tue Sep  8 04:18:52.583 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 30           30
Last Modified: Sep  8 04:17:34.774 for 00:01:18
Paths: (3 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.2 
  65001 65004, (received & used)
    10.1.4.1 from 10.1.4.1 (10.0.0.1)
      Origin IGP, localpref 100, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 30
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Not advertised to any peer
  65001 65004, (received & used)
    10.2.4.2 from 10.2.4.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #3: Received by speaker 0
  Not advertised to any peer
  65003 65004, (received & used)
    10.4.5.5 from 10.4.5.5 (10.0.0.5)
      Origin IGP, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

Every metric display is gone, the best path is back to best #1 (via R1), and the state matches STEP 0.

Verification Configurations and show Output

At every STEP, three kinds of file were captured from all six routers, split per router. The verification configuration is these ..._run.txt files (the final state being the one from the last STEP).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route` / `show bgp` / `show bgp <prefix>` / `show bgp neighbor` / `show bgp neighbors <peer> advertised-routes\|routes\|received routes` / `show bgp update-group` / `show rpl route-policy` and so on
`..._log.txt`	`show logging` narrowed to that STEP’s range. A marker was written with `logmsg` at the start of each STEP, and its timestamp passed to `show logging start`
`..._run.txt`	`show running-config` at that STEP (that is, the verification configuration for that STEP)

The final state (STEP 5) is identical to STEP 0 and carries no MED-related configuration at all.

STEP 0: No MED anywhere (initial state)

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 1: MED 200 on R1→R4, 50 on R2→R4 and 77 on R6→R1

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 2: A smaller MED on a path from a different neighboring AS

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 3: Applying bgp bestpath med always on R4

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 4: Removing the MED on R5→R4 and adding bgp bestpath med missing-as-worst on R4

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 5: Removing everything (final state, identical to STEP 0)

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

The full captures are below. They contain every UPDATE from STEP 0 through STEP 5.

Download the full capture on the R1 - R4 link (eBGP)

Download the full capture on the R2 - R4 link (eBGP)

Download the full capture on the R4 - R5 link (eBGP)

Download the full capture on the R1 - R3 link (inside AS 65001, iBGP)

References

Document	Title	Overview
RFC 4271	A Border Gateway Protocol 4 (BGP-4)	Section 5.1.4 defines `MULTI_EXIT_DISC`. Section 9.1.2.2 restricts the MED comparison to paths whose neighboring AS is the same.
RFC 4451	BGP MULTI_EXIT_DISC (MED) Considerations	A document working through the conditions under which MED is compared, and the problems caused by implementation differences.
RFC 7454	BGP Operations and Security	Operational recommendations, including how to handle MED received from a neighboring AS.
IANA	Border Gateway Protocol (BGP) Parameters	The registry of path attribute type codes.