Hi Gilson
Thanks for the valuable feedback, I’ll let @ReneMolenaar know!
Laz
Hi Gilson,
I agree, just added and highlighted this.
Rene
Hello Rene,
All the MED examples I have seen are between two autonomous systems. What if there are two routers (belonging to the same company but different sites) having different ASN’s advertising identical routes to an external organization.
I want the external organization to send traffic via only one of the sites. Only if the link fails can it be sent to via the other site. Can this still be done by MED values?
So can i configure a route-map on site 1’s router where the MED value is 100 and a route-map on site 2 router where the MED value is 200. Can this ensure that the external routers always sends traffic via site 1?
Thanks
Hello William
The purpose of MED is to advertise to your neighbouring AS how they should enter your AS. This by definition requires that you have at least two connections to a particular AS. MED is then used by their BGP routers to determine via which path connectivity to your AS will be achieved. A prerequisite of the use of MED is that the two alternative paths into your network must be in the same AS. Note here that MED is propagated to all routers within a neighbouring AS but is not passed along to any other autonomous systems.
If you have the topology that you describe, then each AS, even if it belongs to the same entity, will have only one single entry point into your AS. Therefore there is no issue as to which path will be taken, since there is only one choice per AS.
So to answer your question, MED cannot be used to modify the way in which traffic from different AS’es enter your network.
Having said that, however, there is an exception to this rule. If two AS’es exist as two alternate paths to a third single AS, then yes, you can have a situation where you must compare MED values from multiple AS’es. But this involves outgoing traffic, and not incoming traffic. Take a look at this topology for example:
Here we have a network 10.1.1.0/24 that exists in AS 10. The path to this network is advertised by R4 and R5 which are in different AS’es to R6 in AS40 using a different MED. By default, R6 will not take the MEDs into account because they are from different AS’es, however, you can configure R6 with the
bgp always-comare-med command, and only then will it compare them. However, keep in mind that the destination is still a single network, and exists within a single AS 10.
Such a configuration , informs R6 of how to reach the particular network, and does not inform the other AS’es of how to reach networks behind R6, so this situation is the other way around.
I hope this has been helpful!
Laz
1 Like
Thanks Laz,
This was very useful. I configured it in the lab and it was able to work only after I configured the compare med command.
Is this compare med feature only in Cisco or is it a mandatory feature in BGP that used across all vendors?
Thanks
Hello William
Your question puts us in a little bit of a grey area between the definition of a protocol and the implementation of that protocol. According to RFC 4271:
MULTI_EXIT_DISC is only comparable between routes learned from the same neighboring AS (the neighboring AS is determined from the AS_PATH attribute).
I haven’t found any evidence in the RFC that the operation of BGP in the strictest sense, “allows” the use of the MED value to be compared from two different AS’es. This may be an additional feature that Cisco has introduced, similar to the introduction of the WEIGHT attribute.
Doing a bit of research, I have found that other vendors, such as Juniper, also have this feature available, and I get the feeling that you will find it in most mid to high end equipment providers. Once again, it’s not strictly defined in the RFC, but it seems that it is a useful feature in practice, and has thus been implemented in this way on networking devices.
I hope this has been helpful!
Laz
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
1 Like
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
1 Like
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