Thank you Laz. But one more doubt. If we issue the bgp always-compare med command on the router receiving all 3 paths. According to Cisco documentation it states, that by default BGP will only look at the MED if the originating AS is the same. That bahaviour can be changed by using the bgp always-compare med command. This would cause the router to look at the MED(since the AS_PATH is a tie) value eventhough the orginating AS is not the same. In this case regarless of what we put in place of the ? ,it would still choose Path3. For instance, if we have two ASes with subnet 192.168.1.0/30 on their directed connected link, and both ASes want to advertise that network down to their BGP peers. The downstram router which received that route(assuming that the WEIGH to AS_PATH length is a tie). In this case the network is being originated from two differenc ASes, in which the router wont look at the MED since the originating AS is not the same. We can force the downtream route to look the the MED by ussuing the bgp always-compare med. In this case refering back to the image, the placeholder of the ? can be whichever.
Hello John
We must make sure we understand what the phrase âoriginating AS is the sameâ. In the table you shared, the AS_PATH indicates that the three paths are learned from different ASes. Path 1 is learned from AS 50, path 2 from AS 20 and path three from AS 10. Note these are the first ASes in each of the AS paths, which means they are the directly connected ASes. AS Path when read from left to right shows the ASes you pass through to get to the destination.
To clarify this, take a look at the following diagram:
R5 advertises the 1.1.1.1/32 network, and AS1 sees three paths:
- 2 4 via R2
- 3 4 via R3
- 3 4 via R4
If those paths are equal, and we reach the MED attribute, then by default it wonât be used to compare the MED between the paths via R3 and R4, because both are advertised to R1 from the same AS, namely AS3. It is the leftmost AS in the AS_PATH that matters for the comparison of MED.
So going back to your scenario, since all three paths are learned from different ASes, the bgp always-compare-med command will make no difference in the behavior. That means that for Path 3, you can put anything you like in the place of the ?, and the MED will choose Path 3. This is true whether bgp always-compare-med is used or not.
I hope this has been helpful!
Laz
Hello, everyone!
Could someone please enlighten me here?
The OCG mentions the following:
An organization may expect its different SPs to advertise a MED value for every prefix. If a MED is missing, the path without a MED is preferred over a path that contains a MED. An organization can modify the default behaviour so that prefixes without a MED are always selected as last
What exactly does this even mean?
An organization may expect the service providers to advertise a MED?
Theyâve described this as âMissing MED Behaviourâ but I donât seem to understand the purpose of it at all.
Kind regards,
David
Hello David
Hmm, thatâs a bit strange. The phrase âIf a MED is missingâŚâ is a bit misleading in my opinion. If no MED is sent, then the default value of 0 is used. For this reason, the rest of the sentence is true: ââŚthe path without a MED is preferred over a path that contains a MED.â If we can say this another way, the path without a MED actually has a MED of 0, and since the lower MED is preferred, that path will be preferred over another one that has a non-zero MED.
I would have phrased the whole thing like so:
âAn organization may expect its different SPs to advertise a MED value for every prefix. MED has a default value of 0, so if the MED of a particular prefix is not modified, the path with a MED of 0 will be preferred over a path with a non-zero value, simply because the lower MED is preferred. However, an organization can modify the default behaviour so that prefixes with a MED of 0 are always selected as last.â
The last phrase simply reinforces the fact that MED is considered an optional attribute, so BGP routers are not obligated to honor it, so you can configure your router to ignore MED values completely.
I hope this has been helpful!
Laz
Hello Laz
That makes much more sense, thank you. However, one thing that isnât clear is the âAn organization may expect its different SPs to advertise a MED value for every prefixâ.
Why and how exactly does this work? As far as I am concerned, MED doesnât pass between autonomous systems, itâs only sent to the neighboring ones, so how can an organization expect a MED value included in the route advertisements sent by the SPs?
If one of the SPâs customers was to configure MED, only the SP would see that but that attribute would not be passed onto other autonomous systems, would it?
Thank you for your help
David
Hello David
MED is an attribute that can be added to any prefix when being advertised via an eBGP peering. You are correct that MED is non-transitive so it is not conveyed to other ASes. However, your ISP can send you prefixes to which it adds a particular MED using route-maps. So the MED is not necessarily set by the owner of the prefix, but by the AS of your ISP that is directly connected to you.
That is absolutely correct. This does not deter an ISP or an enterprise network for that matter from manipulating the MED for whatever prefix it shares with its directly connected AS neighbors. Does that make sense?
I hope this has been helpful!
Laz
Hello Rene and Laz.
Ever since I covered BGP, I never understood the following OCG explanation related to some further MED configuration?:
Missing MED Behaviour
An organization may expect its different SPs to advertise a MED value for every prefix. If a MED is missing, the path without a MED is preferred over a path that contains a MED. An organization can modify the default behaviour so that prefixes without a MED are always selected as last.
Always Compare MED
The default MED comparison mechanism requires the AS_PATH values to be identical because the policies used to set the MED could vary from AS to AS. This means that the MED can influence traffic only when multiple links are from the same SP. Typically, organizations use different SPs for redundancy. In these situations, the default BGP rules for MED comparison need to be relaxed to compare MEDs between different service providers.
Honestly, I understand very little from this explanation. Why should an organization expect the SPs to advertise a MED value for every prefix? Why would we want to select prefixes without a MED as the last? How does all this work? 
I understand that thereâs commands like missing-med-as-worst but I never understood how these commands work and when or why would I even want to use them.
Thatâs all. thank you.
David
Hello David
I agree, the writing is a little bit vague. Let me try to more clearly explain what I believe they are saying.
First of all, everything hinges on the fact that MED, by default, is used as a mechanism to influence incoming traffic into an AS from multiple entry points. By default, the comparison is always done between two or more entry points into the same AS.
This is not a hard and fast rule, but a common practice that you should be prepared for. In this case, MED values are used by the ISPs to influence the inbound traffic (from the ISPs point of view) . By having a MED value for each prefix, ISPs can more effectively manage how traffic is distributed across multiple entry points into their network. This may be a method of attempting to load balance incoming traffic across those multiple entry points. But note, that this makes sense only if that same ISP has two entry points into its AS. See below.
MED is an optional attribute, which means it may or may not be included in the BGP update. When there is no MED, a MED of 0 is assumed, and because lower MED values are preferred, a MED value of 0 will always be preferred over any other value (assuming the MED attribute is the tie-breaker in the path selection). You can indeed modify this behavior by using the missing-med-as-worst keyword. Why would you do this? Well, Iâll tell you shortly.
Now here, what is being said in simpler terms is that by default, MED is only compared between routes that come from the same AS (requires the AS_PATH values to be identical). Thatâs its purpose. However, because most enterprises will use two or more different ISPs for their multiple connections to the Internet, this by default means that they are coming from two different ASes. Thus, MED will never be compared. If you want to use MED as part of your path selection mechanism, even if that MED comes from different ASes, then you must ârelax BGP rulesâ and compare MED from different ASes.
Hereâs a scenario where all of this comes together:
Imagine you have two ISPs, each with a single link to your enterprise network. ISP A chose to use the default behavior of MED and didnât set a MED for some routes, while ISP B choose to relax BGP rules and added a MED value. By default, routes from ISP A (without MED) would be preferred if MED becomes the tie breaker. However, this may not align with your traffic engineering goals. Using missing-med-as-worst, you can ensure that routes from ISP B, where MED is defined and indicating a specific preference, are chosen first.
This is simply one more mechanism we can use to route BGP traffic, and it can be used based on what you need. In almost all such cases, you would negotiate with your ISPs concerning what kind of BGP attributes they share with your network, and all of this is typically agreed upon beforehand. Itâs rare that youâll see an ISP or an enterprise modify such parameters without having some sort of agreement on paper that states how BGP networks will interface with each other.
I hope this has been helpful!
Laz
If MED is used to tell your neighbour which route the should use to reach your AS. Could you increase the MED value on R1 that is sent to R2, this would be higher than the MED value R3 would send to R2 which would influence the path taken to reach 1.1.1.0/24 from R2?
Hello Harry
Yes, MED is indeed used by an AS to let other ASes know through which router they should route traffic to get to a network inside that AS. You can indeed increase the MED value on R1 and make it a higher MED value than that advertised by R3. That would influence R2âs decision to route traffic destined to the 1.1.1.0/24 network through R1 and not through R3.
I hope this has been helpful!
Laz
Hello Team,
This is my lab where i tested MED behaviour between AS-1 and AS-2. I have preferred ingress traffic from R4 to R3 for AS-1 so i advertised from R3 9999 and increased MED from R1 to R2 for AS-1 as 666666 but the output is quite strange, may be i am wrong. please clarify on it.
R1(AS-1) -------MED 666666 -------- R3(AS-2)
R3(AS-1) ------MED 9999 --------R4(AS-2)
R3----iBGPâR4
In AS-2 the best outbound supposed to be via R4 to reach 1.1.1.1/32 in AS-1 since it has lowest MED 9999, but R2 prefers the path ( route learned via eBGP) which has the highest MED 666666 .
If AS-2 has single router then the behaviour is same as per the lesson.
R2-AS-2#sh ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 8
Paths: (2 available, best #2, table default)
Advertised to update-groups:
1 2
Refresh Epoch 2
1
192.168.34.3 (inaccessible) from 192.168.24.4 (192.168.25.4)
Origin IGP, metric 9999, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
1
192.168.12.1 from 192.168.12.1 (1.1.1.1)
Origin IGP, metric 666666, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0R4-AS-2#sh ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 7
Paths: (2 available, best #1, table default)
Advertised to update-groups:
1 2
Refresh Epoch 2
1
192.168.34.3 from 192.168.34.3 (1.1.1.1)
Origin IGP, metric 9999, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 2
1
192.168.24.2 from 192.168.24.2 (192.168.23.2)
Origin IGP, metric 666666, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0Hello Sathish
This is expected behavior. When R2 wants to determine the best path to 1.1.1.1/32, it will compare the two possible paths:
- via R2 â R4 â R3
- via R2 â R1
Even though in the output of the show ip bgp 1.1.1.1 command you see the MED appearing in both possible routes, it is not actually being used to determine the best path. Why? Because the MED is only taken into account for routes learned from eBGP peers.
So R2 sees the following:
R2-AS-2#sh ip bgp 1.1.1.1
BGP routing table entry for 1.1.1.1/32, version 8
Paths: (2 available, best #2, table default)
Advertised to update-groups:
1 2
Refresh Epoch 2
1
192.168.34.3 (inaccessible) from 192.168.24.4 (192.168.25.4)
Origin IGP, metric 9999, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Refresh Epoch 2
1
192.168.12.1 from 192.168.12.1 (1.1.1.1)
Origin IGP, metric 666666, localpref 100, valid, external, best
rx pathid: 0, tx pathid: 0x0
The route via R4 is internal (iBGP) thus the Metric of 9999 is irrelevant, and is thus not checked. It is considered a tie, and it goes on to the next attribute which is "prefer eBGP routes over iBGP routes. Since the route via R1 is an eBGP route, it is chosen as best.
In the second case, where you have one router in AS2 that connects to both R1 and R3, both peerings are eBGP peerings, and thus the MED is considered in the process, and that is why R3 is chosen over R1.
I hope this has been helpful!
Laz
Lazarus - this behavior you described regarding the MED and its genesis in iBGP vs eBGP is an important detail that I had not considered but now seems obvious once you highlighted its âconditionalâ participation in the path attribute selection.
I actually have been meaning to write to you about your bgp videos on YouTube which have been an enormous help for my ENCOR studies. In fact I was just reviewing the MED earlier this week.
There is another interesting detail about MED that I just discovered - this is contained in the Cisco Press ENCOR/ENARSI configuration commands portable handbook.
They provide an example of a bgp topology where the MED is sent into the target AS from two different ASs. The MED in this case is for the same destination route. And the point of the example is to illustrate that the MED comparison is only made on the MED values that arrive from the same autonomous system. It goes on to explain that this is the default behavior on Cisco routers.
Hello Sandro
I am always amazed at the elegance of BGP, and the intricate details that are involved in its functioning. Iâm encouraged to hear that you are benefiting from my work!
Yes, this is indeed a useful detail. You can actually override this default behavior of comparing MED values that come from the same AS. You can find more info about that at this NetworkLessons note.
I hope this has been helpful!
Laz
I learned that MED is applied to outbound updates, dictating the best inbound traffic but we can also do vice-versa. Like we can also maipulate inbound update dictating outbound traffic via creating the rout-map on R2 in out direction itâs the same thing??
Hello Speedosuper111
The truth is that the âinboundâ and âoutboundâ directions have always been confusing concerning how BGP modifies attributes and how traffic itself is influenced. Let me attempt to clarify this:
The inbound and outbound directions refer to two different things: the directions of the BGP updates sent, and the direction of the traffic being influenced. When we use route maps and configure a direction, weâre referring to the direction of the BGP update being sent from one neighbor to the other, not the traffic itself. The traffic that is influenced by that update travels in the opposite direction!
Stating it simply:
- Outbound BGP updates influence inbound traffic (traffic coming TO you)
- Inbound BGP updates influence outbound traffic (traffic leaving from you)
Now when we talk about MED specifically, it is an attribute you send to your neighbors in adjacent ASes to tell them which of your entry points they should prefer when sending traffic into your AS.
You configure MED using a route-map in the OUT direction toward an eBGP neighbor in another AS. The neighbor receives your routes with the attached MED values. If the neighbor receives multiple updates for the same destination, it uses the MED values in the BGP path selection process, where a lower MED is preferred. This influences how traffic comes INTO your AS (inbound traffic).
Now, can we apply this âvice-versa?â
Well, no, itâs not quite the same thing. If you apply a route-map on R2 (from the topology in the lab) in the outbound direction with MED, this will be applied to BGP updates sent from R2 to R1 (or R3). Such updates would not be applied to the networks within AS1, but should be applied to some networks that may exist in R2, and this would influence how traffic enters AS2 for some network within AS2.
If you want to control YOUR Outbound Traffic, this is quite simple to do, because you have full control of your own AS, and you can route traffic however you like, even overwriting any of the MED or other attributes that other ASes may send you. You can do this with various attributes, including Local Preference, Weight, and AS-Path manipulation, to name a few. Does that make sense?
I hope this has been helpful!
Laz