BGP MED Explained
- By Joe Astorino
- May 1, 2011
- 14 Comments
As you probably know, the BGP protocol has many different attributes that can be used to influence path selection. These many attributes have different characteristics and are used for many different things. Today, we are going to be taking a look specifically at the BGP MED attribute. The BGP MED attribute is one that is typically used to influence how traffic comes back into your own autonomous system. We can usually accomplish the same thing with the BGP AS_PATH attribute by utilizing AS Path Prepending, but let’s focus in on MED. I have found through my experience and studies that the MED is one of the most confusing topics for people and that it is often misunderstood. Let’s take a look at some of the misconceptions and how we can actually use MED to our advantage in the real world or in a CCIE lab situation. Let’s take a look at our topology today
We have four routers, each in their own AS. R1 is going to be advertising it’s loopback0 interface 1.1.1.1/32 into BGP to both R2 and R4 (Yes, I know there is no R3…a carry over from my days with IPexpert. My home lab is still built around that topology. Call it bad practice, call it habit…whatever). R5 will therefore receive the prefix 1.1.1.1/32 from both R2 and R4. If we leave everything at the defaults which path will it choose? In this case it actually depends…let’s walk through the BGP best-path selection algorithm. If you are studying for a CCNP or a CCIE there is no reason you should not have the following link bookmarked: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml
1) Highest Weight
2) Highest Local Preference
3) Prefer Locally Originated routes over externally learned routes
4) Shortest AS Path
5) Lowest Origin Type
6) Lowest MED
7) Prefer eBGP over iBGP
8) Prefer the path with the lowest IGP metric to the BGP next-hop
9) Determine if multiple paths need installed (BGP multipath)
10) When both paths are external prefer the one that was learned first
…
Well, we have not done anything yet so everything is going to be the same. Since R2 happened to boot up first and peer with R5 first, R5 prefers the path via R2. Let’s see that in action:
R5#show ip bgp BGP table version is 2, local router ID is 45.45.45.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 1.1.1.1/32 45.45.45.4 0 400 100 i *> 25.25.25.2 0 200 100 i
OK great. Now, let’s say that we need R5 to prefer the path via R4 instead. For whatever reason (uncooperative ISP, people that don’t know how to do their job, policies, or simply a lab requirement) you are not allowed to use weight or local preference on any router. You are not allowed to change the BGP origin type or use AS Path Prepending on any router. That leaves us with MED. OK, well the BGP path selection says lowest MED wins. Default MED is 0. That is kind of irritating, but OK. Sounds simple — Let’s just make the MED on the R1/R2 peering higher. How about 100? R2 should get a MED of 100 from R1 while R4 will get the default MED of 0. When R2 and R4 relay the prefixes to R5 the prefix with the MED of 0 that passed through R4 should win right? Perfect, let’s try that out
R1(config)#route-map SET-MED-100 permit 10 R1(config-route-map)#set metric 100 R1(config-route-map)#exit R1(config)#router bgp 100 R1(config-router)#neighbor 12.12.12.2 route-map SET-MED-100 out R1(config-router)#end R1#clear ip bgp * soft
Let’s verify on R2 and R4
R2#show ip bgp BGP table version is 3, local router ID is 25.25.25.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 12.12.12.1 100 0 100 i
R4#show ip bgp BGP table version is 2, local router ID is 45.45.45.4 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 1.1.1.1/32 45.45.45.5 0 500 200 100 i *> 14.14.14.1 0 0 100 i
We can see that R2 has the metric set to 100 on the prefix 1.1.1.1/32. We can see that R4 still has the default metric of 0 but …hmmmm that is pretty interesting why is R4 learning the prefix from both R1 and R5?! Let’s look at R5
R5#sh ip bgp BGP table version is 2, local router ID is 45.45.45.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path * 1.1.1.1/32 45.45.45.4 0 400 100 i *> 25.25.25.2 0 200 100 i
Oh. Well, first of all our MED doesn’t appear to have done anything! the metric is not set on the prefix that went from R1 to R2 and up to R5. This also answers our question from above. Since R5 still prefers the path via R2 that path is the valid and best path in it’s BGP table. Because of that fact, R5 advertises it’s valid and best path over to R4 which is why on R4 we see the prefix twice.
OK, so after all that what have we learned? Well, if you read the BGP best path selection very carefully you will see the following under the MED section:
This comparison only occurs if the first (the neighboring) AS is the same in the two paths. Any confederation sub-ASs are ignored.
In other words, MEDs are compared only if the first AS in the AS_SEQUENCE is the same for multiple paths. Any preceding AS_CONFED_SEQUENCE is ignored.
So basically what it says is that the BGP MED value is not even looked at in the sequence if the prefix came from two separate autonomous systems. In other words, to actually be able to use MED the same prefix has to be coming from the same autonomous system. The MED attribute was designed for AS’ that are directly connected. Now, this is ONE problem people usually have with understanding MED. The second misunderstanding I usually see is that people fail to remember that the BGP MED attribute is a BGP optional non-transitive attribute. What does that mean? Optional means that first of all not all BGP implementations are required to support it. Non-transitive is the more interesting one though. This means that if an AS learns a prefix with a non-transitive attribute that attribute will not be passed to it’s peers. Oh.
Let’s put that into perspective in our situation. First of all, we are setting an optional non-transitive attribute on R1. So right away we are screwed because R2 and R4 will not “reflect” that attribute up to R5. Secondly, even if they did pass the MED up to R5 it wouldn’t matter because as we saw the MED is only compared if the prefixes are coming from the same AS. What to do, what to do? First lets clean up R1
R1(config)#router bgp 100 R1(config-router)#no neighbor 12.12.12.2 route-map SET-MED-100 out R1(config-router)#do clear ip bgp * soft
So, to solve problem #1 why don’t we set the MED outbound from R2 to R5 instead. Great. But what about problem #2? Even if R5 gets the MED from R2 it won’t matter because it will be getting the same 1.1.1.1/32 prefix from two different AS’s. Well, there is a little well-known command we can use to fix that on R5. That would be the bgp always-compare-med command under the BGP process. Let’s get to work then
First, we set R2 to set the MED to 100 on it’s peering to R5:
R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)#route-map SET-MED-100 permit 10 R2(config-route-map)#set metric 100 R2(config-route-map)#router bgp 200 R2(config-router)#neighbor 25.25.25.5 route-map SET-MED-100 out R2(config-router)#do clear ip bgp * soft
Next, we tell R5 to always compare the MED values even if the prefixes come from two different AS’s.
R5(config)#router bgp 500 R5(config-router)#bgp always-compare-med R5(config-router)#do clear ip bgp * soft
Let’s check it out now
R5#show ip bgp BGP table version is 3, local router ID is 45.45.45.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 1.1.1.1/32 45.45.45.4 0 400 100 i * 25.25.25.2 100 0 200 100 i
NICE!!!
There are two lessons to remember when dealing with MED
1) Remember, it is an optional non-transitive attribute. It won’t “bounce” through more than one AS
2) By default, the MED is only compared if the same prefix is learned more than once from the same AS. If the prefix is learned from two different AS’ and we still want to look at MED we need to configure the bgp always-compare-med command!
I hope this blog has been informative and useful for you all! Until next time keep studying hard!
Joe Astorino, CCIE #24347
Hi Joe,
Thanks. Indeed this is first and only explanation I have ever read, describing about MED Concept.
Overwhelming. My heartly appreciation
sairam
Great Explanation! Thanks
I liked your blog . You have a great ability to put things properly so that people understand the very basics of concepts you are trying to explain.
This is really great explanation, However I still have some problem with bgp-deterministic-med command.
Your description regarding non-transitive attributes not being passed to peers is incorrect, they are passed to iBGP peers but not eBGP peers.
You are correct. In this article I am talking specifically about not passing the non-transitive attributes on to eBGP peers. Thanks.
Sir,
Thanks a lot for MED explanation. It help a lot…..
Its Very Very Nice explanation for the MED understanding Thanks.
I was searching for a good explanation for ” Always Compare MED ” for long time. This is the best i found. Thank you very much.
Thanks Nithin,
If you want a thorough in depth understanding of BGP, check out my BGP course over at Pluralsight. http://www.pluralsight.com/courses/ccie-routing-switching-implement-bgp
Really you have cleared my prolonged doubts…i had gone through N no.of blogs but all attempts became vain..Thank you dude
First ever explanation which helped me understand MED clearly.. Thanks a bunch for sharing.
Thanks for the explanation that you gave about MED. which clear my concept about MED. but i have read lots of books in which the MED is applied between Ebgp peers. but i have seen the scenario where it is deployed between IBGP peers having two links between E1 Router to E2 router. so then why its not explained in IBGP peers. all the books have explanation of MED through eBGP peers.
needs your comment its only to clear my concept.
Very well explained, thank you for your efforts. I was very confused about this attribute and your explanation cleared it. Much appreciated