We will now look at the Multi-Exit Discriminator more often called MED, or as some people call it, the BGP metric. Now the Multi-Exit Discriminator is kind of like local preference but used in the opposite direction. Again if you refer to the diagram you'll see two Autonomous Systems AS 200 and AS 400. We're sitting in AS 400, we're originating a prefix And we have two paths from our AS to our neighboring AS 200. How do we tell AS 200 which path traffic should take to reach our Again, if I use the previous sample with local pref, us as a human being we can look at this and we can, maybe we do router C to router A one day router D to router B another day, just depending what our feeling is, but we can't exactly go and tell the router, "Oh just pick something whatever works best." What we do is, we set a Multi-Exit Discriminator on the announcement on each link from AS 400 to AS 200. Right, so referring to the diagram, on the AC link we announce, with say metric 2000. And the BD peering we announce with metric 1000. So when we take a view in AS 200 again we see two paths to One has a metric 2000, the other one has a metric 1000. Now, with MED lowest MED wins, so just a reminder highest local preference wins, lowest MED wins. If you think MED and the old way that was described as a metric, well in an IGP like IS-IS and OSPF lowest metric wins. So lowest metric in BGP would win as well. It's a useful tip for trying to remember which size of MED wins. So lowest MED wins, which means traffic from AS 200 to AS 400 will follow the D to B link. Now MED is inter-AS, so it's used between two Autonomous Systems. It's a non-transitive attribute though, this is only used between the two ASes. An MED that you set and announced to your neighboring AS will not be propagated to any other Autonomous System. And it's an optional attribute as well, you don't have to set it. It's used to convey the relative preference of entry points, and so it determines the best path for inbound traffic. It's comparable only if paths are from the same Autonomous System, that's the BGP specification. However several vendors have added an optional feature in, to let you compare the MED even if the path is from different Autonomous Systems. So not all vendors support this, but some vendors have allowed that optional extra. [In] Cisco IOS it is: `bgp always-compare-med`. Path with the lowest MED wins and the absence of an MED attribute implies MED value of 0. That's per RFC. Now if you think about it, what happens if you're trying to compare a path where the MED is set say to 1000, versus a parallel path where there's no MED set at all? Well the original BGP specification didn't specify anything at all. So different equipment vendors had different ideas. Maybe if they didn't set a MED then they consider that path really unimportant. Or maybe if they didn't set MED they consider the path the most important. And this led to some early interesting conflicts when different network operators in some of the earlier internet were interconnecting. Assuming defaults for MEDs when there were no defaults, really resulted in some poor traffic engineering outcomes. And so for this reason RFC4271 stipulates that the absence of an MED implies an MED value of 0. Now one thing, that again, has developed over time is how we compare MEDs. Now Cisco IOS compares paths in the order that they were received. Which actually can look as though you end up with inconsistent decisions being made. Now most Autonomous Systems probably only have one, maybe two, connections between each other. But some of the really big network operators may have dozens of connections between each other. And when you're trying to do balancing over these dozens of connections between the ASes, the order that the paths were received in over these multiple connections becomes very very important. Now most recent BGP implementations would have a specific way of ordering these paths before they actually calculated the MED. Cisco IOS stores these paths in the order they're received. The oldest first to the newest last, and so when it does the best path selection, it will compare for the first two, the winner of that is then compared to the next one and so on all the way through the list. So every time you may cycle a link such that your best path no longer becomes the best path. The best path selection would end up with a different result each time. Not a bug in the software, just the fact that the BGP specification didn't say how the path should be ordered. The solution to all this is what's called the deterministic MED. Recommendation today, as has been for several years, is to configure this on all BGP speaking routers in the Autonomous System. We order the paths according to the neighboring AS number, starting with the lowest AS number all the way up to the largest. We calculate the best path, in other words the best MED, lowest metric for each neighbor ASN group, and then compare all of these to get a winner. And this is a sure way of ensuring that we always get the best path when they're multiple links between neighboring Autonomous Systems. The Cisco IOS configuration is: `bgp deterministic-med`. Other implementations tend to implement something like this by default. Finally, if you wish, in Cisco IOS you can convey the IGP metric as an MED as well. This lets operators determine accessibility to their network from peers based on the bandwidth or at least the IGP metric values within their backbone. And this really allows operators to do more fine-grained load balancing, certainly when their backbone is made up of many different sized links Finally we've got a configuration example, if you refer to the slide. Again this is a configuration of router B which we showed earlier in the diagram. We implement a route map which is the Cisco policy language out-bound on that interface. All that configuration is doing, is looking for the IP address that we have originated and we're sending to the neighbor and attaching a metric value of 1000 to it. There'll be equivalent configuration for the other router connecting to AS 200 which sets the metric to be 2000. you

© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.

Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.