BGP MED Attribute

What MED Is

MULTI_EXIT_DISC (MED, Type code 4) is the optional non-transitive path attribute that tells a neighbouring AS which entry point to use to reach the local AS (BGP Path Attributes and Best Path Selection). RFC 4271 section 5.1.4 says a MED received from a neighbouring AS must not be propagated to other neighbouring ASes: MED does not 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

Lower is preferred, the opposite of LOCAL_PREF. It feels like an IGP metric, and IOS XR shows it in the Metric column of show bgp.

What It Communicates

When AS 65001 connects to AS 65002 at both R1 and R2, the routers deciding “come in through R2” belong to AS 65002. So AS 65001 attaches a low MED to the routes it advertises from R2 and a high MED to those from R1. MED is only a request. The receiver can ignore or overwrite it (RFC 4271 section 5.1.4 requires a mechanism to remove it), and it sits below LOCAL_PREF and AS_PATH length in best path selection (6th).

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

The scope of each attribute.

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 neighbouring AS (must not be passed beyond it)
`AS_PATH`	Every AS the route traverses

By Default It Only Compares Paths From the Same Neighboring AS

By default MED is compared only between paths received from the same neighbouring AS (RFC 4271 section 9.1.2.2; RFC 4451 works through the condition). Each AS picks its MED from its own internal circumstances, so the “50” from AS 65001 and the “10” from AS 65003 share no yardstick. In the lab, 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 AS_PATH length 2, so the comparison reaches MED. The paths via R1 and R2 share neighbouring AS 65001 and are compared, but the path via R5 comes from a different AS, so no matter how small its MED, it never enters the comparison.

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, right after ORIGIN.

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

A MED has no effect if something higher up has settled the contest. That is why all three paths in the lab have AS_PATH length 2.

What Happens to MED on Re-advertisement

Handling differs inside the AS (iBGP) and towards another AS (eBGP) (RFC 4271 section 5.1.4).

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 towards eBGP because it is meaningless to the AS beyond, and it is carried on iBGP because every router in the AS needs the same view. STEP 1 places the two side by side for one prefix.

Configuration

On IOS XR, set med in a route-policy is applied outbound on the neighbour.

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

IOS XE’s bgp deterministic-med does not exist on IOS XR 26.1.1 (% Invalid input detected); IOS XR always groups paths from the same AS before comparing.

Without missing-as-worst, a path with no MED is treated as the lowest value (0) (RFC 4271 section 9.1.2.2), so the one without a MED wins. Take care when attaching a MED on only one side.

Verification on Real Hardware

Six XRd 26.1.1 routers in AS 65001 (R1, R2, R3), AS 65002 (R4), AS 65003 (R5) and AS 65004 (R6).

AS 65001 connects to R4 over eBGP in two places, R1 and R2; R3 is internal, with an iBGP full mesh (next-hop-self) and OSPF
R4 also connects to R5; R5 to R6; R6 back to R1
R6 advertises 192.168.6.0/24, which R4 learns via R1, R2 and R5, all with AS_PATH length 2

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

STEP 0: No MED anywhere (initial state)

With no MED configured, 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)

No path shows a metric, and nothing separates them through the first five comparisons, so Path #1 (via R1) is best on a later tiebreak (keeping the existing best path, or router ID).

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

200 is configured outbound on R1 and 50 outbound on R2. MED 77 from R6 towards R1 is configured as well, for the re-advertisement check.

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

On R4 the path via R1 shows 200, via R2 50 and via R5 no MED, and the best path moves to the one via R2.

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)

The two paths from neighbouring AS 65001 were compared by MED and the lower Path #2 (metric 50) won. R4 now comes in through R2, as AS 65001 intended.

Over iBGP, MED Is Carried Through Unchanged

Now follow the MED 77 that R6 attached towards R1. R1 receives it as metric 77, and the value is unchanged after crossing iBGP to R3.

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

The (metric 2) is the IGP cost to the NEXT_HOP; the MED is the metric 77 after Origin IGP,. The iBGP UPDATE R1 sent to R3 confirms it.

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 (with LOCAL_PREF: 100, since this is iBGP).

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

Over eBGP, MED Is Not Carried Over

The same 192.168.6.0/24 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 from R6 was not carried over; R1’s own outbound policy replaced it.

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

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)

Without set med on R1, the eBGP UPDATE would carry no MULTI_EXIT_DISC at all. The other route in No.143, 192.168.5.0/24 (received with no MED), has none: absent stays absent into iBGP.

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

MED 10 is attached from R5 towards R4: smaller than 200 and 50, but from neighbouring AS 65003, different from the other two.

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 carries metric 10, but the best path stays at best #2. The smallest MED is not chosen because MED is compared only between paths from the same neighbouring AS.

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

Add bgp bestpath med always on R4.

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 #3, the path via R5 with the smallest MED, is now best. Prefixes such as 192.168.1.0/24 that have only two paths from AS 65001 do not change.

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

Remove the MED on R5→R4 and add bgp bestpath med missing-as-worst on R4 (med always stays).

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 now shows metric 4294967295 (the 4-byte maximum) and the best path is back on Path #2. Without this setting a missing MED counts as 0, and with med always in effect Path #3 would win outright.

STEP 5: Removing everything (final state)

Delete every set med policy and both bgp bestpath med lines.

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 is gone and the best path is back to best #1 (via R1).

Verification Configurations and show Output

Each STEP captures three kinds of file from all six routers. The verification config is the ..._run.txt (final state: STEP 5).

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)

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 captures 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.