BGP MED Attribute Configuration Example

I receive a lot of queries related to the BGP MED attribute in BGP path selection so today, Before you begin to learn MED, you should know what is BGP and how does it work, this is a prerequisite for understanding this topic.

I decided to take up this topic in my blog article. As a part of our Cisco training, this article will cover the BGP MED Attribute Configuration with an example.

"BGP Best Path Selection Criteria"

Here I am assuming that all of you know the BGP best path selection criteria up to MED attribute.

All other attributes (Weight, Local Preference, AS_PATH length) should be the same for the prefixes. 

BGP Topology Diagram

To explain the BGP MED attribute for selecting the best bgp path using MED.

I have taken a topology to make you better understand the concept better.

"BGP MED Scenario"

In this topology, there are 3 AS (Autonomous Systems) AS 100, AS 200, and AS 54.

AS 100 has R1, R4 and R6 Routers.

AS 200 has R3, R5 and R8 Routers.

AS 54 has only one router R10.

Here R1 (AS 100) is directly connected to R3 (AS 200), R4 (AS 100) is directly connected with R5 (AS 200), R8 (AS 200) is also directly connected to R10 (AS 54). 

Locally originated prefixes in AS 54 are being advertised, these prefixes first reach AS 200 then AS 100.

Now AS 100 wants to send traffic to these prefixes,

this AS 100 has 2 paths to choose its exit point I.e., via the R4-R5 link or via the R1-R3 link.  

Here we are assuming that the BGP path attributes (Weight, Local Preference, and AS_PATH) of the prefixes received are the same for both exit points.

Then AS 100 must decide based on the MED values of these prefixes. 

BGP MED Attribute

When several paths exist for the same BGP prefix with equal weight, local preference, AS_PATH length, and Origin Code.

The BGP path selection will compare the next-less-influential attribute which is MED or Multi Exit Discriminator.

This attribute is optional and nontransitive, and its value is an unsigned 32 integer.

"Multi Exit Discriminator is called Metric."

It is often called “metric” and is used on eBGP peering links to select the entry point to the neighboring AS. 

The AS that originates the prefixes may attach different metric values to them on different exit points from the AS.

This gives the neighboring AS a hint to select the best path based on the smallest metric value because all other attributes usually match (weight, LP, AS_PATH length). 

Non-Transitive BGP Path Selection Attribute

This BGP MED attribute is non-transitive, so the receiving AS will not propagate it across its AS borders.

However, the receiving AS may reset the metric value if it wants.

Cisco BGP implementation automatically assigns the value of the MED attribute based on the IGP metric value for the locally originated prefixes.  

The explanation for this follows.

Most often, BGP prefixes are advertised by the border eBGP speakers.

If there are redundant connections between two ASs, multiple BGP speakers may originate the same prefix, attaching the MED attribute copied from the IGP metric of the advertised prefix.

The neighboring AS may then apply the bgp best path selection for the peer’s prefixes based on the smallest metric value.  

This makes sense if the following is true:

1. The peer (originator) AS uses a single IGP across its network; that is, metric values are numerically comparable.

2. MED values are only compared for the prefixes coming from the same AS.

3. Prefixes originated from the peer’s AS.  

Cold Potato vs Hot Potato Routing 

Based on these assumptions, the MED attribute simply gives the neighboring AS a hint to select the prefixes with the shortest IGP metric value in the peer’s AS.

This routing behavior is called “cold potato routing,” in contrast to the “hot potato” routing model.

The “hot potato” model is effectively in use when MED values are not considered during the best path selection.

When MED values are filtered or are the same among all paths,

The router will select the path with the lowest IGP cost for its next hop (if the prefixes are of the same type)

For example, both learned via iBGP, comparing IGP costs is the next step in the BGP best path selection process.

This means selecting the path through the closest exit point, based on the IGP metrics of the local AS.

This is analogous to a group of people trying to get rid of a “hot potato” as fast as possible.

The “cold potato” routing model considers the metric hint information from the adjacent AS to make the final routing decision.  

The Command - bgp best path med missing-as-worst

Often you may see the MED attribute used to influence the exit point selection for prefixes not originating in the local AS.

This is perfectly legal, but you must assign some artificial metric values to these prefixes because they don’t belong to the IGP from the local AS. Remember that this sort of path attribute manipulation only affects the paths chosen by the directly connected neighboring AS.

Finally, the MED attribute is optional and thus may not be present or attached to all updates/prefixes.

By default, the BGP path selection process assumes the MED value of zero for such prefixes, which will make them more preferred during the selection based on a metric.

If you want to change this behavior, you must enter the command bgp best path med missing-as-worst.

This instructs the local router to impose the maximum MED value on the prefixes that do not carry the MED attribute, making these prefixes least preferable.

The use of this logic was specified in earlier drafts of the BGP specification, whereas the most recent instructions to assign the MED value of zero to the prefixes lack the metric attribute.  

Scenario - BGP MED Configuration Example

In our scenario, we configure AS 200 border routers (R3 and R5) peering with AS 100 to assign metric values for prefixes learned from AS 54.

The metrics are assigned so that the exit point through R3 is less preferred (higher metric).

Notice that we configure both R3 and R5, whereas it is possible to configure just R3 because routes advertised by R5 will have the default MED value of 0. 

R3:

R5:

To learn more about the BGP and its configurations, check out more about the IT infrastructure courses.