BGP MED Recap

References:
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13759-37.html
https://www.cisco.com/c/en/us/td/docs/ios/iproute_bgp/command/reference/irg_book/irg_bgp1.html
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/16046-bgp-med.html

 

RFC4261 Section 5.1.4. MULTI_EXIT_DISC

The MULTI_EXIT_DISC is an optional non-transitive attribute that is
intended to be used on external (inter-AS) links to discriminate
among multiple exit or entry points to the same neighboring AS. The
value of the MULTI_EXIT_DISC attribute is a four-octet unsigned
number, called a metric. All other factors being equal, the exit
point with the lower metric SHOULD be preferred. If received over
EBGP, the MULTI_EXIT_DISC attribute MAY be propagated over IBGP to
other BGP speakers within the same AS (see also 9.1.2.2). The
MULTI_EXIT_DISC attribute received from a neighboring AS MUST NOT be
propagated to other neighboring ASes.

A lower MED is preferred over a higher MED.
The lowest MED (0) may be seen as less preferable than no MED but still valid, or it may be seen as invalid/unusable, it may also be seen as the most preferred MED.
The maximum MED (2^32-1) may be been seen as an invalid/unusable, or simple the lest preferred MED.

 

missing-as-worst

On IOS and IOS-XR, routes without a MED are assigned MED 0 by default, which on IOS is the most preferred MED value. The IOS command "bgp bestpath med missing-as-worst" / IOS-XR command "bgp bestpath med missing-as-worst" sets a missing MED value to 2^32-1, which is the least preferred value.

Before CSCef34800, IOS command "bgp bestpath med missing-as-worst" assigned 2^32-2 to a route without a MED because 2^32-1 was considered an invalid route. Post CSCef3480, 2^32-1 is a valid value on IOS so "bgp bestpath med missing-as-worst" assigns 2^32-1 to routes without a MED value.

 

deterministic-med

With all factors on received paths from the same peer AS, the MED may not actually be compared:

RFC4277 Section 7.1.4 MEDs and Temporal Route Selection

Some implementations have hooks to apply temporal behaviour in MED-
based best path selection. That is, all things being equal up to MED
consideration, preference would be applied to the "oldest" path,
without preference for the lower MED value. The reasoning for this
is that "older" paths are presumably more stable, and thus
preferable. However, temporal behaviour in route selection results in
non-deterministic behaviour, and as such, may often be undesirable.

^ IOS does this by default; two routes from the same peer ASN (so the MEDs would be compared) with all aspects equal, but the newer route has a lower MED, the older route will remain the best path because it is considered more stable.

The IOS command "bgp deterministic-med" / IOS-XR command "bgp deterministic med" forces the BGP process to compare MEDs of newer paths (where all other attributes are equal) with the MED of older ones, which were received from the same peer ASN, rather then preferring an older path with a higher MED over a newer path with a lower MED.

 

always-compare

By default, the MED is only compared on IOS and IOS-XR for routes received from the same peer AS. The IOS command "bgp always-compare-med" / IOS-XR command "bgp bestpath med always" can be used to compare MEDs for routes from different peer ASNs. Care should be taken when comparing MEDs from different peer ASNs because various BGP implementations simply reflect the IGP value or AIGP value in the MED value. If networks don't explicitly set a MED on egress or have different IGP metric mechanisms, comparing the MED across different peer ASNs may have undesired results.

 

deterministic vs always compare

With "bgp deterministic-med" but without "bgp always-compare-med", MED is used in the path selection algorithm for paths from the same peer ASN, but not for the selection of paths from different peer ASNs.

With "bgp always-compare-med" but without "bgp deterministic-med", MEDs on paths from different peer ASNs are compared but if the choise is between two paths from the same peer ASN the oldest route is preferred.

 

Hot Potato "closest exit" Routing vs Colt Potato "best exit" Routing

RFC4277 Section 7.1.1. MEDs and Potatoes

Where traffic flows between a pair of destinations, each is connected
to two transit networks, each of the transit networks has the choice
of sending the traffic to the peering closest to another transit
provider or passing traffic to the peering that advertises the least
cost through the other provider. The former method is called "hot
potato routing" because, like a hot potato held in bare hands,
whoever has it tries to get rid of it quickly. Hot potato routing is
accomplished by not passing the EBGP-learned MED into the IBGP. This
minimizes transit traffic for the provider routing the traffic. Far
less common is "cold potato routing", where the transit provider uses
its own transit capacity to get the traffic to the point in the
adjacent transit provider advertised as being closest to the
destination. Cold potato routing is accomplished by passing the
EBGP-learned MED into IBGP.

If one transit provider uses hot potato routing and another uses cold
potato routing, traffic between the two tends to be symmetric.
Depending on the business relationships, if one provider has more
capacity or a significantly less congested transit network, then that
provider may use cold potato routing.
...
Seemingly more intuitive references, which fall outside the vegetable
kingdom, refer to cold potato routing as "best exit routing", and hot
potato routing as "closest exit routing".

---