The countdown to Elevate 2026 is on. Join us in Chicago, London, or Sydney.

Register here

Partners

Docs

LM Academy

LM Community

Pricing

Platform
Solution
Industry
Role
There is no result.
Try it free

14-day access to the full LogicMonitor platform

The countdown to Elevate 2026 is on. Join us in Chicago, London, or Sydney.

Register here

BGP MONITORING

BGP MED Attribute

BGP MED lets you suggest which entry point a neighboring AS should use when sending traffic to you. Learn how it works, when it matters, and the common pitfalls to avoid when using it for traffic engineering.

6–10 minutes
Denton Chikura

CHAPTERS

    NEWSLETTER

    Subscribe to our newsletter

    Get the latest blogs, whitepapers, eGuides, and more straight into your inbox.

    SHARE

    The quick download:

    BGP MED lets you hint to a neighboring AS which of your entry points to prefer, but it only works when both parties agree to respect it, and it’s only compared between routes from the same neighbor AS by default.

    • MED is evaluated after LOCAL_PREF and AS_PATH in the path selection order, it only comes into play when both attributes are equal.

    • By default, MEDs are only compared between routes from the same AS; enabling always-compare-med allows cross-AS MED comparison but can cause unexpected routing changes.

    • MED is non-transitive, it is not passed to downstream peers, limiting its influence to the directly adjacent AS.

    • Explicitly agree on MED policies with your neighboring ASes before relying on it for traffic engineering, a neighbor that ignores your MED values will not behave as expected.

    Many activities essential to modern life depend on the internet, and the internet depends on the Border Gateway Protocol (BGP). That means BGP performance can have an impact on a global scale. If BGP performance significantly degrades or there is an issue with the routing protocol, economies around the globe can lose massive amounts of productivity and dollars. 

    As a result, BGP monitoring is a vital aspect of modern networking. In simple terms, BGP monitBGP 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.

    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.

    Peering 1 MEDPeering 2 MEDMED Honored?Result
    00YesTraffic is load-balanced
    020YesPeering 1 is primary; peering 2 is backup
    9378YesPeering 2 is primary; peering 1 is backup
    5447NoMED ignored, so MEDs are each treated as 0

    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.

    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:n your internet routing.

    # 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

    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.

    See exactly how your inbound traffic is flowing.

    LogicMonitor’s network observability provides your team visibility into active BGP paths, attribute states, and traffic distribution across your peering points so you can validate inbound routing policy and detect unexpected changes.

    FAQs

    What is BGP MED?

    BGP MED (Multi Exit Discriminator) is an optional, non-transitive BGP attribute used to influence how a neighboring AS routes inbound traffic to your network. When you have multiple connections to the same neighboring AS, setting different MED values on each connection suggests which one the neighbor should prefer. A lower MED value is preferred. MED is sometimes called the BGP metric.

    When is MED compared in BGP path selection?

    MED is evaluated relatively late in the BGP path selection process, after WEIGHT (Cisco-specific), LOCAL_PREF, locally originated routes, AS_PATH length, and ORIGIN code. This means MED only influences path selection when all preceding attributes are equal. By default, MED is only compared between routes learned from the same neighboring AS; the always-compare-med option (available on most platforms) enables MED comparison across different ASes.

    Why is MED only compared between routes from the same AS?

    The default restriction to same-AS MED comparison is a safety measure. Different ASes may use different MED scales or semantics, so comparing MEDs across ASes could produce unintuitive or incorrect routing decisions. For example, AS A might use MED to indicate link bandwidth while AS B uses it for geographic preference, comparing them directly would be meaningless. The restriction ensures MED is only used as intended: as a hint from a specific neighbor about its own entry points.

    Does MED guarantee traffic will enter through my preferred link?

    No. MED is a suggestion, not a guarantee. Neighboring ASes are free to ignore MED values or use routing policies that override them. Factors like the neighbor’s own routing policy, their LOCAL_PREF settings, or their AS_PATH length preferences may take precedence over your MED hints. For predictable inbound traffic engineering, coordination with your neighboring AS about how they handle MED is essential.

    By Denton Chikura

    Technical Writer

    Denton Chikura is a technical writer and longtime observability advocate focused on helping site reliability engineers and engineering teams discover the tools and capabilities that strengthen internet resilience. He works at the intersection of monitoring, performance, and infrastructure to make complex systems more understandable and usable, bridging the gap between deep technical detail and real‑world operations. His goal is to help teams build faster, detect issues earlier, and recover smarter, ultimately making the internet a better, more reliable place for everyone.

    Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.

    © LogicMonitor 2026 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.