ccie blog

BGP Always-Compare-Med

BGP always-compare-med is useful when wanting to evaluate MED values from two different AS_PATH’s of equal length towards a prefix.  Take the diagram below; R5 is advertising his 55.55.55.0/24 prefix into BGP.  No matter which way you look at it, R1 is always 2 AS’s away from this network regardless of the route he takes (AS 20-AS 40, or via AS 30-AS 40).  Here R2, R3, or R4 can send MED values to R1 in order to influence his best path towards this prefix.  Normally, MED has a cheeky catch.  And that is, that MED is only compared by routers from the same AS.  In the diagram below, this means R1 would never compare the MED R4’s sent vs the MED R2 or R3 sent; even though every attribute prior to MED is the same.  BGP always-compare-med allows us to change this default behaviour, and force R1 to compare MED values from R4 against MED values from R2 & R3.

In this lab we are going to influence R1’s best path to the 55.55.55.0/24 network by sending different MED values to R1.  The goal is to make R1 pick R3 as the best path to reach this network.  Before I start modifying MED towards R1, let’s take a quick look at R1’s current BGP table for this prefix.

R1#sh ip bgp 55.55.55.0
BGP routing table entry for 55.55.55.0/24, version 11
Paths: (3 available, best #3, table Default-IP-Routing-Table)
  Advertised to update-groups:
     1
  30 40
    13.13.13.2 from 13.13.13.2 (33.33.33.33)
      Origin IGP, localpref 100, valid, external
  20 40
    14.14.14.2 from 14.14.14.2 (4.4.4.4)
      Origin IGP, localpref 100, valid, external
  30 40
    12.12.12.2 from 12.12.12.2 (22.22.22.22)
      Origin IGP, localpref 100, valid, external, best

R1 is currently using R2 (22.22.22.22) as the best-path to reach this prefix.  The BGP best path selection algorithm is calculated from the top town.  It compares the top two (most recent) paths, and picks the best path.  This winner is compared against the third path down.   When the top two paths were compared in our table, R3 (33.33.33.33) vs R4 (4.4.4.4), the winner was R4.  This is because R4 is older.  R4 vs R2 = R2 now wins because he is older (remember, if you are comparing eBGP peers then the age is the tie breaker.  If the peers aren’t both eBGP peers, then the router-id is compared instead).    You can make BGP completely exclude age from the best path selection algorithm by configuring #bgp best path compare-routerid.  Let’s make R3 the preferred path by configuring a lower MED.

R1(config)#router bgp 10
R1(config-router)#bgp always-compare-med

Let’s check our BGP table again to see the changes.  R1 should now see that R3 (33.33.33.33) is the best path because of the lower MED.

R1#sh ip bgp 55.55.55.0
BGP routing table entry for 55.55.55.0/24, version 13
Paths: (3 available, best #1, table Default-IP-Routing-Table)
Flag: 0x4800
  Advertised to update-groups:
     1
  30 40
    13.13.13.2 from 13.13.13.2 (33.33.33.33)
      Origin IGP, metric 10, localpref 100, valid, external, best
  20 40
    14.14.14.2 from 14.14.14.2 (4.4.4.4)
      Origin IGP, metric 30, localpref 100, valid, external
  30 40
    12.12.12.2 from 12.12.12.2 (22.22.22.22)
      Origin IGP, metric 20, localpref 100, valid, external

And there we have it!  So even though the AS paths to this network are different, MED is still compared!

Quick note

  • MED is an optional non-transitive attribute, so will only affect neighbor’s that are only one AS away.  In our topology above.  If we configure MED outbound on R5 towards AS 30, then AS 30 will NOT advertise this MED to R1 (in AS 10).

I have also done articles on BGP deterministic-med & normal BGP med

7 Comments

AKMApril 20th, 2016 at 2:27 pm

Thanks TOO MUCH..

I understand BGP COMPARED MED as soon as i read your article…i had too headache before coming your blog….

MKOctober 12th, 2016 at 1:21 am

Yes, I too understood the concepts perfectly after reading so many documents

MartinAugust 1st, 2017 at 1:11 pm

Agree with AKM’s comment. Nice blog and very well explained

FarApril 12th, 2018 at 4:49 pm

Thanks,

BalajiApril 26th, 2018 at 8:00 pm

Hi, Your link to deterministic-med is missing, Can you please fix it?

StephenGarbettMay 1st, 2018 at 1:01 am

Thanks. This is now fixed.

AungFebruary 23rd, 2019 at 6:18 pm

Good Blog.I refer your blog to lead my networking skills

Leave a comment

Your comment