Thanks Laz for researching and giving your views. Greatly appreciate it.
My previous scenario can be achieved with BGP communities by having different communities for each Data Center. So when traffic comes from one DC it will be tagged with a community and the core will redirect the replies towards the same DC.
Thanks
Hello William
Yes, this just goes to show you that there are often multiple ways of implementing what you want, especially with a protocol that is so diverse, flexible, and robust as BGP.
Thanks for sharing your experience!
Laz
Hi Laz,
I think we can also configure two route maps on R2 for each neighbor and apply them in Inbound direction and same for the AS path prepend case. Am i right?
Hello Pradyumna
Yes, you can apply this in an inbound direction on R2 and thus cause R2 to choose one route over the other. However, this implementation is not so common because MED is used to communicate to other AS’es and let them know how to enter your AS. By configuring this on R2, you are essentially overriding whatever was sent from AS1.
This should only be done in cooperation with the owner of the other AS, otherwise you are overriding a configuration that the administrator of the other AS requires. This can be considered a “hostile” act especially if you are interconnecting with an ISP or another enterprise network. Be sure to coordinate your efforts with the admins of the other networks before doing something like that.
I hope this has been helpful!
Laz
Hi Rene/Laz,
I have a question regarding the attribute selection.
In your MED scenario you did not change any of previous attributes that BGP use for path selection and therefore BGP is using the attribute MED to forward packets to R2 via R3?
But let’s say that you setup local preference and path length …Which one BGP will choose in order to forward a packet down R2?
Many thanks
Hello Carlos
Yes, that is correct. BGP attributes are compared in a very specific order. If a particular attribute is the same, then the next one in the order is examined, until there is a difference, and one outweighs the other.
In this particular case, all the attributes before MED, such as weight, local preference, originate, AS path length, and origin code, are all the same. This is why the MED attribute is used. However, if local preference was different, then local preference would be used, regardless of what the MED was.
More information on this can be found in the following lesson that describes this path selection using these attributes:
I hope this has been helpful!
Laz
Can we compare MED between two different Autonomous System number as per below Pic??
what is bgp always compare med and deterministic med ??
Hello Narad
For more information on how MED is compared in such scenarios, take a look at this post:
Concerning deterministic MED, this documentation from Cisco adds some additional insight into how this works:
I hope this has been helpful!
Laz
Hi Rene/Laz,
Can you please share us the configuration of all BGP attributes wrt Nokia and juniper routers also.
BR// - AM
Hello Ajay
For the time being, the site is focusing on topics that lead to Cisco certification. For this reason, we’re not able to provide any information concerning similar configurations on devices of other vendors. I suggest you explore the online resources that these vendors provide for their users. Sorry about that!
Laz
Hello Guys
I am doing LAB with MED , why you putting 500 on R3 if you just put route map on R1 with metric 700 that should work as well as R3 will have lower value then R1 .Am I correct ?
Hello Metodija
Yes you are correct, if the MED was changed only on R1 with a metric of 700, R3 would have a default metric of 0. Whether R3’s metric is 0 or 500 will have the same result, since it is still less than 700.
Even so, making R3’s metric 500 is preferrable in a production environment because it gives you more flexibility in adjusting the metric of other routers that may connect to R2 as well. That way, you will be able to configure a metric that is even better than R3’s if you have more routers.
I hope this has been helpful!
Laz
Hello there:
I came across the scenario shown above while studying some BGP. BGP MED is only looked at when the originating ASN number is the same by default. When can change this behaviour by issuing the bgp always-compare med , which will then allow BGP to comapre the MED when the same route shows as being originated for two different AS. In the scenario above if we were to issue the bgp always-compare med command on the receiving router. Does that mean that for Path3 the originating AS ( in place of the ?) could be whatever ASN . This would cause the AS_PATH to be the same lengh and BGP would then look at the MED value in which PAth3 would be chosed as best. Is this the right thing to say or is there more to the story?
Thank you
John
Hello John
Remember that BGP attributes are checked one at a time in order, and if there is a tie, the next attribute is checked.
In the table you shared, the first attribute that is different is the Local Originate Source attribute. This attribute says that a locally sourced route is preferred to one that is learned from another BGP speaker. Since Path 3 was installed using the network command, Path 3 will be preferred and no further attributes will be checked.
However, the question in your post says “what should be the value for the missing ASN represented by a question mark in the table so that Path 3 becomes the best path between routers A and B based on their MED values?” In other words, assuming all previous attributes are equal, what must the AS_PATH be so that the MED will be used as a tie breaker? We must put a value in there that makes all AS_PATHs equal. Since ASN 40 is the last ASN in both Path 1 and Path 2, then it makes sense that ASN 40 should also be the value of the question mark.
Now could that ASN be anything? Well, strictly speaking, yes it could be anything. We can manipulate that AS path to be anything we like with AS_PATH prepending. However, you must keep in mind that, that AS_PATH is used to get to a particular destination. If it is anything, and that anything is incorrect, BGP will not route traffic correctly.
So strictly speaking, it can be anything, but it should be 40 since that’s the ASN needed to get to the proper destination.
I hope this has been helpful!
Laz
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:
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
