BGP MED Attribute

BGP is the “protocol of the internet,” used to exchange routing information between autonomous systems (networks) comprising the global internet. In this article, we will explain the BGP attribute known as Multi Exit Discriminator, MED, or metric, and how it is used to influence routing decisions. 

BGP MED is an attribute used for traffic engineering and is set by an autonomous system advertising routes to another peer. It plays an important role in attempting to influence traffic ingress into an autonomous system. MED is evaluated after the local preference and AS path attributes. When comparing MEDs on one or more routes, the lowest MED wins the tie-breaker.

To understand more about route selection evaluation order and tie-breaking attributes, you can read our BGP path selection article here.

For a full understanding of how the Junos implementation of path selection operates, please see this page.

It is important to note that BGP MED is only used in the route selection process in the event that there are two or more routes learned from the same ASN and those routes are for the same destination (prefix). If there is only a single route learned from an ASN, BGP MED has no influence on route selection as there needs to be two or more MEDs to compare.

For example, suppose you have multiple peerings with a cloud or content provider, each advertising a similar set of routes. If the route 192.168.50.0/24 is received on all sessions, with the same local-preference and AS path length, then in this case, MED will be compared.

If you have a single peering with a different cloud or content provider, then there is only one route per destination prefix available via this ASN (as next-hop). In this situation, MED will not factor into the route selection process as there is no eligible alternate route with which to compare.

{{banner-14="/design/banners"}}

BGP MED Explained

By default, the BGP MED of an advertised route will either be 0 or equal to the IGP cost, unless otherwise configured by policy, depending on router vendor. Autonomous systems receiving BGP routes typically “honor” MED (i.e., factor MED into routing decisions) by default unless otherwise configured. The choice to ignore MED will be explained further into this article.

MED is a 4 byte / 32 bit field therefore values can range from 0 to 4,294,967,295, but typical values in use range from 0 up to the low thousands. These values can be arbitrarily chosen, e.g., in the range of 0 to 100. As shown in the table, we could set MED 0 on the peering we prefer as primary and MED 20 on the peering we prefer as backup.

Example configurations are listed in the table and will be explained further below. The numbers used are just examples, but note the relative differences between MED values to understand what the resulting behaviors are.

Values can also be set by the router to 0 or by copying the IGP metric to the BGP MED. For example, if the route to be advertised via BGP has an IGP cost of 54, the BGP MED may be set to 54.

MED does not propagate beyond the session it was received on. For example, a BGP MED announced from ASN A will be received by ASN B, but if B readvertises this route to ASN C, the BGP MED will be overridden to 0, the IGP metric, or an administratively configured value. 

The basic principles of the use of MED are as follows:

• The lowest MED “wins” (if MEDs are to be compared).
• Equal MEDs will potentially load share (depending on the receiver’s network configuration).
• Unequal MEDs advertised across sessions will typically result in primary and backup traffic distribution (or primary, backup, and tertiary with three sessions, etc.)

Unequal MEDs

A common practice is to configure one peering to use MED 0 and another to use a higher value, such as 50. You might do this if you have two peerings to a receiving network, where one has higher capacity, so you wish it to become the primary while the other functions as a backup.

The best practice would be to have equal capacity links in geographically diverse locations and then set BGP MED as equal to the IGP metric, thereby allowing the peer network insight into your IGP costs and the ability to make optimal routing decisions about their egress point into your network.

Equal MEDs

In the event that you do not wish to use either unequal-MED strategy, you can simply leave MED at the default or explicitly configure it to zero. This will result in “hot potato” routing in the peer’s network, whereby any traffic destined to your network will exit their network at the nearest possible exit, not necessarily the best path.

This simple strategy is in common use for several reasons:

• It’s a typical default setting to advertise metric 0.
• Carrying traffic for longer on a network is costly as it uses link bandwidth on every link it traverses, so it may be preferable to shift traffic off one’s network as early as possible, even though this may not be the optimal path in terms of latency or bandwidth/congestion. Accordingly, a network receiving your MEDs may choose to dishonor MED altogether and reset your MED to 0.

{{banner-15="/design/banners"}}

Recommendations

Think about the MED you are sending. How do you want the receiving network to treat its egress traffic: prefer one peering over another, follow your IGP metrics, or find the nearest exit?

Setting MED equal to your IGP metric is a good starting point if you are unsure. It can generally be changed without tearing down BGP sessions, so it’s possible to experiment to find the best tuning state with minimal risk.

Also consider received BGP route MEDs — how will you treat them? Will you honor the MED received, or set a policy to rewrite all MEDs to zero? Think about whether you want to shed traffic at the nearest exit or route traffic according to received MEDs.

Configuration Examples

Let’s look at Junos configuration examples for setting outbound MEDs in your export policy; see the comments in the code block for use cases:

# Announce MED = IGP
set policy-options policy-statement EXPORT-TO-ACME term ANNOUNCE then metric igp

# Announce MED = 0 on Peering 1, MED = 50 on Peering 2
set policy-options policy-statement EXPORT-TO-ACME-1 term ANNOUNCE <...>
set policy-options policy-statement EXPORT-TO-ACME-1 term ANNOUNCE then metric 0
set policy-options policy-statement EXPORT-TO-ACME-2 term ANNOUNCE then metric 20

For MEDs received inbound, the Junos default is to honor them unless otherwise specified. If you wish to override inbound MEDs and set them to 0, i.e., implement hot-potato routing in your import policy, you can do this:

# Override incoming MED, rewrite as 0
set policy-options policy-statement IMPORT-FROM-ACME term PERMIT then metric 0

Verification Commands

Here’s the command to view the MED of a received route:

@router> show route receive-protocol bgp 192.168.10.1 8.8.8.0/24 extensive

  8.8.8.0/24 (10 entries, 1 announced)
     Accepted
     Nexthop: 192.168.10.1
     MED: 42  <<<<<<<<<<<<<<<<<<<<<<<<<<< Received MED shown
     AS path: 15169 I
     Communities: 

Here’s how to view the MED of an advertised route:

@router> show route advertising-protocol bgp 192.168.10.1 172.16.0.0/12 extensive

* 172.16.0.0/12 (3 entries, 1 announced)
 BGP group PEERS type External
     Nexthop: Self
     MED: 0  <<<<<<<<<<<<<<<<<<<< Advertised MED shown
     AS path: I
     Communities: 64512:123

{{banner-sre="/design/banners"}}

Conclusion

Which MEDs you advertise and how you treat MEDs you receive affect routing decisions and therefore traffic flow in the receive direction of the advertiser and transmit direction of the receiver. 

It is best practice to advertise MED = IGP and honor all received MEDs. As explained above, some networks will choose to ignore your IGP MED; the best you can do is advertise the information you wish for them to use.

Some networks choose to advertise MED = 0 from every session, and this is a reasonable position to take as well.

While many networks follow the practice of honoring BGP MED (a.k.a. cold-potato routing), you will find that many networks ignore MED altogether, giving them a simplistic policy that can ease troubleshooting (every route follows the nearest exit from both perspectives, a.k.a hot potato routing). This can sometimes result in lower operating costs, for example, where capacity planning ensures that bandwidth is not a concern and where latency is less of a concern than consistent policy configuration and behavior. In this consideration, the skill of your support staff might be a factor.

It is recommended to review traffic patterns, link bandwidth, path latencies, and staff knowledge and then consider which policies work best for your network and your peer networks. In case of doubt, advertising MED = IGP and honoring received MEDs is a great place to start.