Oct
12

The BGP MED attribute, commonly referred to as the BGP metric, provides a means to convey to a neighboring Autonomous System (AS) a preferred entry point into the local AS.  BGP MED is a non-transitive optional attribute and thus the receiving AS cannot propagate it across its AS borders.  However, the receiving AS may reset the metric value upon receipt, if it so desires.

Previous versions of BGP (v2 and v3) defined this attribute as the inter-AS metric (INTER_AS_METRIC) but in BGPv4 it is defined as the multi-exit discriminator (MULTI_EXIT_DISC). The MED is an unsigned 32bit integer.  The MED value can be any from 0 to 4,294,967,295 (2^32-1) with a lower value being preferred.  Certain implementations of BGP will treat a path with a MED value of 4,294,967,295 as infinite and hence the path would be deemed unusable so the MED value will be reset to 4,294,967,294.  This rewriting of the MED value could lead to inconsistencies, unintended path selections or even churn. I’ll do a follow up article on how BGP MED can possibly cause an endless convergence loop in certain topologies.

Cisco’s BGP implementation automatically assign the value of the MED attribute based on the IGP metric value for any locally originate prefixes. The reasoning behind this is when there are multiple peering points with a neighboring AS the neighboring AS can use this metric to determine the best entry point into the local AS. This is the case when the originating AS’s network uses as single IGP. When multiple IGPs are used (i.e. OSPF and IS-IS) the metric value automatically copied into BGP will not be comparable. In this situation the metric values should be manually set before sending to the neighboring AS.

The MED value by default will only be used in Cisco’s BGP Best Path selection algorithm when comparing paths from the same AS.  If comparison is desired between different ASes the bgp always-compare-med router configuration command can be used. Use this command with caution as different ASes can have different policies regarding the setting of the MED value or in the case of the MED automatically being set they could be using different IGPs. Additionally by default MED is not compared between sub-autonomous systems in a BGP confederation. To enabled comparison between different sub-ASes within a confederation use the bgp bestpath med confed router configuration command.

As mentioned by default the MED values are compared for paths from the same AS but this presents a problem in the way BGP path comparison is done in the IOS.   Lets first examine how the path comparison is done to get a better understanding of the BGP Deterministic MED command and why Cisco recommends it to be enabled.

Here is the topology that we will use for this scenario:

BGP Deterministic MED

We will primarily look at the effects of BGP MED on the BGP best path decision process from R1’s perspective.   In this network AS 400 is advertising the 24.1.1.0/24 network.  R2, R3 and R4 are in AS 200 with R5 being in AS 300.  R2 is setting the MED for this network to 200, R3 to 300, R4 to 400 and R5 to 500 when the 24.1.1.0/24 network is advertised to R1.  R1’s BGP configuration is below:

Rack1R1# show run | sec router bgp 100
router bgp 100
no synchronization
bgp router-id 1.1.1.1
neighbor 54.1.12.2 remote-as 200
neighbor 54.1.13.3 remote-as 200
neighbor 54.1.14.4 remote-as 200
neighbor 54.1.15.5 remote-as 300
no auto-summary
Rack1R1#

The output of the show ip bgp on R1:

Rack1R1#show ip bgp
BGP table version is 2, local router ID is 1.1.1.1
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
*  24.1.1.0/24      54.1.12.2              200             0 200 400 ?
*                   54.1.14.4              400             0 200 400 ?
*                   54.1.15.5              500             0 300 400 ?
*>                  54.1.13.3              300             0 200 400 ?
Rack1R1#

Now lets look at the 24.1.1.0/24 network in a little more detail:

Rack1R1#show ip bgp 24.1.1.0/24
BGP routing table entry for 24.1.1.0/24, version 2
Paths: (4 available, best #4, table Default-IP-Routing-Table)
 Advertised to update-groups:
       2
 200 400
   54.1.12.2 from 54.1.12.2 (2.2.2.2)
     Origin incomplete, metric 200, localpref 100, valid, external
 200 400
   54.1.14.4 from 54.1.14.4 (4.4.4.4)
     Origin incomplete, metric 400, localpref 100, valid, external
 300 400
   54.1.15.5 from 54.1.15.5 (5.5.5.5)
     Origin incomplete, metric 500, localpref 100, valid, external
 200 400
   54.1.13.3 from 54.1.13.3 (3.3.3.3)
    Origin incomplete, metric 300, localpref 100, valid, external, best
Rack1R1#

As we can see R1 has selected R3’s (3.3.3.3) advertisement of the 24.1.1.0/24 as the best path.  The MED is 300 for this advertisement which isn’t the lowest of all advertisements from AS 200.  The advertisement from R2 is actually lower as it has a MED value of 200.  Remember that the lower MED value is preferred since this value is normally copied from the IGP metric and with IGPs the lower metric value is preferred.  Since the MED attribute is optional it may not be present in all paths. By default, BGP process will assume the MED value of zero for such paths, which will make them more preferred during the selection based on metric. If you want to change this behavior, use the bgp bestpath med missing-as-worst router configuration command.

Lets look at how R1 ended up selecting R3 as the best path.  First off the router will order the paths from the newest to the oldest.  By default all factors in the BGP best path decision process being the same, the oldest path will be selected as best.  BGP does to this reduce the amount of churn in the routing table.  To change this behavior and not use the oldest path as the best, the BGP router-ID can be used to determine the best path.  To enable this use the bgp bestpath compare-routerid router configuration command.

Below the bgp bestpath compare-routerid command is enabled on R1.  Now R1 has selected R2’s path as the best since it has the lowest BGP router ID.

Rack1R1#show run | sec router bgp
router bgp 100
 no synchronization
 bgp router-id 1.1.1.1
 bgp bestpath compare-routerid
 neighbor 54.1.12.2 remote-as 200
 neighbor 54.1.13.3 remote-as 200
 neighbor 54.1.14.4 remote-as 200
 neighbor 54.1.15.5 remote-as 300
 no auto-summary
Rack1R1#show ip bgp 24.1.1.0/24
BGP routing table entry for 24.1.1.0/24, version 3
Paths: (4 available, best #1, table Default-IP-Routing-Table)
Flag: 0x10840
 Advertised to update-groups:
       2
 200 400
   54.1.12.2 from 54.1.12.2 (2.2.2.2)
    Origin incomplete, metric 200, localpref 100, valid, external, best
 200 400
   54.1.14.4 from 54.1.14.4 (4.4.4.4)
    Origin incomplete, metric 400, localpref 100, valid, external
 300 400
   54.1.15.5 from 54.1.15.5 (5.5.5.5)
     Origin incomplete, metric 500, localpref 100, valid, external
 200 400
   54.1.13.3 from 54.1.13.3 (3.3.3.3)
     Origin incomplete, metric 300, localpref 100, valid, external
Rack1R1#

The bgp bestpath compare-routerid command is removed for the remainder of this scenario.  When the command is removed R3 is once again selected as best.

Rack1R1#show ip bgp 24.1.1.0/24
BGP routing table entry for 24.1.1.0/24, version 4
Paths: (4 available, best #4, table Default-IP-Routing-Table)
Flag: 0x10840
Advertised to update-groups:
      2
200 400
  54.1.12.2 from 54.1.12.2 (2.2.2.2)
    Origin incomplete, metric 200, localpref 100, valid, external
200 400
  54.1.14.4 from 54.1.14.4 (4.4.4.4)
    Origin incomplete, metric 400, localpref 100, valid, external
300 400
  54.1.15.5 from 54.1.15.5 (5.5.5.5)
    Origin incomplete, metric 500, localpref 100, valid, external
200 400
  54.1.13.3 from 54.1.13.3 (3.3.3.3)
    Origin incomplete, metric 300, localpref 100, valid, external, best
Rack1R1#

Additional RFC 4277 (Experience with the BGP-4 Protocol) mentions the following in regards to selecting a path based upon oldest path.

7.1.4.  MEDs and Temporal Route Selection

Some implementations have hooks to apply temporal behavior in MED-based best path selection.  That is, all things being equal up to MED consideration, preference would be applied to the "oldest" path, without preference for the lower MED value.  The reasoning for this is that "older" paths are presumably more stable, and thus   preferable.  However, temporal behavior in route selection results in non-deterministic behavior, and as such, may often be undesirable.

 

Rack1R1#show ip bgp 24.1.1.0/24
BGP routing table entry for 24.1.1.0/24, version 4
Paths: (4 available, best #4, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
      2
200 400
  54.1.12.2 from 54.1.12.2 (2.2.2.2)
    Origin incomplete, metric 200, localpref 100, valid, external
200 400
  54.1.13.3 from 54.1.13.3 (3.3.3.3)
    Origin incomplete, metric 300, localpref 100, valid, external
200 400
  54.1.14.4 from 54.1.14.4 (4.4.4.4)
    Origin incomplete, metric 400, localpref 100, valid, external
300 400
  54.1.15.5 from 54.1.15.5 (5.5.5.5)
    Origin incomplete, metric 500, localpref 100, valid, external, best
Rack1R1#

First off it’s important to understand that the paths are compared in pairs starting with the newest path and comparing it with the second newest.  The winning path between the first and second is then compared to the third and in our cause the winner of that comparison is finally compared with the fourth and final path.   On R1 for the 24.1.1.0/24 network, R2’s and R3’s paths are compared first.  Everything in the BGP best path decision algorithm is the same down to MED (weight, local preference, AS path, etc).  Since the advertisements by R2 and R3 are in the same AS the MED is compared and R2 is wins since it has a MED of 200 as opposed to R3’s MED of 300.  Next R2 is then compared to the third oldest entry which is R4’s.  R2 and R4 are in the same AS so R2 wins based upon the lower MED value. Finally R2 is compared with R5. Everything is equal but the MED, router ID and age of the advertisement.  Since R2 and R5 are in different ASes and the bgp always-compare-med isn’t enable, MED isn’t compared.  Additionally we do not have bgp bestpath compare-routerid enabled which leads the R1 to select the oldest advertisement.  Since R5 is listed below R2 we know that it is older and in turn wins out due to being the older advertisement and is installed as the best path to reach the 24.1.1.0/24 network.

As we can see the MED comparison between the paths advertised by AS 200 did not happen as intended by AS 200.   AS 200 was setting the MED so that AS 100 will use R2 as the ingress point into AS 200. This is only because R5’s advertisement was second to the oldest that in turn broke the MED comparison between the AS 200 routers (R2, R3 and R4).

Ideally we want the MED compared between advertisements from the same AS irrespective of their age.  This is where the bgp deterministic-med router configuration command is useful.  When this command is enabled the router will group all paths from the same AS and compare them together before comparing them to paths from different ASes.  Lets enable the command on R1.  We should see that R2 is selected as the preferred path between R2, R3 and R4 but this will mean that once R2 is compared to R5, R5 will be installed since it is an older advertisement.

Rack1R1#show run | sec router bgp
router bgp 100
no synchronization
bgp router-id 1.1.1.1
bgp log-neighbor-changes
bgp deterministic-med
neighbor 54.1.12.2 remote-as 200
neighbor 54.1.13.3 remote-as 200
neighbor 54.1.14.4 remote-as 200
neighbor 54.1.15.5 remote-as 300
no auto-summary
Rack1R1#show ip bgp 24.1.1.0/24
BGP routing table entry for 24.1.1.0/24, version 5
Paths: (4 available, best #4, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
      2
200 400
  54.1.12.2 from 54.1.12.2 (2.2.2.2)
    Origin incomplete, metric 200, localpref 100, valid, external
200 400
  54.1.13.3 from 54.1.13.3 (3.3.3.3)
    Origin incomplete, metric 300, localpref 100, valid, external
200 400
  54.1.14.4 from 54.1.14.4 (4.4.4.4)
    Origin incomplete, metric 400, localpref 100, valid, external
300 400
  54.1.15.5 from 54.1.15.5 (5.5.5.5)
    Origin incomplete, metric 500, localpref 100, valid, external, best
Rack1R1#

It we want to have R2 selected as best we can clear the BGP neighbor relationship with R5 which will in turn cause R5’s paths to be cleared out.  Once the neighbor relationship with R5 comes back up and R5 advertised the 24.1.1.0/24 path, it will be the newest advertisement and in turn be listed at the top.

Rack1R1#clear ip bgp 54.1.15.5
Rack1R1#
%BGP-5-ADJCHANGE: neighbor 54.1.15.5 Down User reset
Rack1R1#
%BGP-5-ADJCHANGE: neighbor 54.1.15.5 Up
Rack1R1#

Now as expected R2 was finally selected as the best path.

Rack1R1#show ip bgp 24.1.1.0
BGP routing table entry for 24.1.1.0/24, version 6
Paths: (4 available, best #2, table Default-IP-Routing-Table)
Flag: 0x820
Advertised to update-groups:
      2
300 400
  54.1.15.5 from 54.1.15.5 (5.5.5.5)
    Origin incomplete, metric 500, localpref 100, valid, external
200 400
  54.1.12.2 from 54.1.12.2 (2.2.2.2)
    Origin incomplete, metric 200, localpref 100, valid, external, best
200 400
  54.1.13.3 from 54.1.13.3 (3.3.3.3)
    Origin incomplete, metric 300, localpref 100, valid, external
200 400
  54.1.14.4 from 54.1.14.4 (4.4.4.4)
    Origin incomplete, metric 400, localpref 100, valid, external
Rack1R1#

Of course to always ensure R2 is selected in our network as the best path we could also use the bgp always-compare-med command to compare MED between different ASes but this command is normally not used in the real world unless MED policies are standardized between neighboring ASes.

Rack1R1#show run | sec router bgp
router bgp 100
 no synchronization
 bgp router-id 1.1.1.1
 bgp always-compare-med
 bgp deterministic-med
 neighbor 54.1.12.2 remote-as 200
 neighbor 54.1.13.3 remote-as 200
 neighbor 54.1.14.4 remote-as 200
 neighbor 54.1.15.5 remote-as 300
 no auto-summary
Rack1R1#
Rack1R1#clear ip bgp *
%BGP-5-ADJCHANGE: neighbor 54.1.12.2 Down User reset
%BGP-5-ADJCHANGE: neighbor 54.1.13.3 Down User reset
%BGP-5-ADJCHANGE: neighbor 54.1.14.4 Down User reset
%BGP-5-ADJCHANGE: neighbor 54.1.15.5 Down User reset
Rack1R1#
%BGP-5-ADJCHANGE: neighbor 54.1.12.2 Up
%BGP-5-ADJCHANGE: neighbor 54.1.13.3 Up
%BGP-5-ADJCHANGE: neighbor 54.1.14.4 Up
%BGP-5-ADJCHANGE: neighbor 54.1.15.5 Up
Rack1R1#show ip bgp 24.1.1.0 
BGP routing table entry for 24.1.1.0/24, version 4
Paths: (4 available, best #2, table Default-IP-Routing-Table)
Flag: 0x10860
Advertised to update-groups:
      2
300 400
  54.1.15.5 from 54.1.15.5 (5.5.5.5)
    Origin incomplete, metric 500, localpref 100, valid, external
200 400
  54.1.12.2 from 54.1.12.2 (2.2.2.2)
    Origin incomplete, metric 200, localpref 100, valid, external, best
200 400
  54.1.13.3 from 54.1.13.3 (3.3.3.3)
    Origin incomplete, metric 300, localpref 100, valid, external
200 400
  54.1.14.4 from 54.1.14.4 (4.4.4.4)
    Origin incomplete, metric 400, localpref 100, valid, external
Rack1R1#

If BGP Deterministic MED is used, it should be enabled on all BGP speaking devices within an AS to ensure a consistent policy regarding the use of MEDs.

We should now have a better understanding of how MED is used in the BGP route selection process and the BGP route selection process is general.

My next post will be in regards the Two Rate Three Color Marker (trTCM) as defined in RFC 2698 and implemented in the Cisco IOS. Also I hope to see many of you in my new RS Bootcamps.

About Brian Dennis, CCIE #2210:

Brian Dennis has been in the networking industry for more than 22 years, with a focus on Cisco networking for the past 16 years. Brian achieved his first CCIE in Routing & Switching in 1996, and is currently the only ten year CCIE that holds five CCIE certifications. Prior to working with INE, Brian taught and developed CCIE preparation courses for various well known training organizations. Brian not only brings his years of teaching experience to the classroom, but also years of real world enterprise and service provider experience.

Find all posts by Brian Dennis, CCIE #2210 | Visit Website


You can leave a response, or trackback from your own site.

26 Responses to “Understanding BGP MED and BGP Deterministic MED”

 
  1. Thanks for the write up, Brian. I passed my R&S written yesterday and finally plan to study hard for the lab. This will be a good resource.

  2. Pete Templin says:

    When did IOS begin setting MED to match the IGP metric by default? I’ve always been thinking that I’d have to ‘set metric-type internal’ on the egress route-map for the BGP advertisements to inherit a MED value that matches the IGP cost to the “next”-hop.

    • When did it not is the question ;-)

      Rack1R1(config)#int fa0/0.12
      Rack1R1(config-subif)#ip ospf cost 555
      Rack1R1(config-subif)#do sho2 ip route 54.1.26.0
      Routing entry for 54.1.26.0/24
      Known via “ospf 1″, distance 110, metric 556, type intra area
      Advertised by bgp 100
      Last update from 54.1.12.2 on FastEthernet0/0.12, 00:00:29 ago
      Routing Descriptor Blocks:
      * 54.1.12.2, from 150.1.2.2, 00:00:29 ago, via FastEthernet0/0.12
      Route metric is 556, traffic share count is 1

      Rack1R1(config-subif)#exit
      Rack1R1(config)#router bgp 100
      Rack1R1(config-router)#network 54.1.26.0 mask 255.255.255.0
      Rack1R1(config-router)#do sho ip bgp 54.1.26.0
      BGP routing table entry for 54.1.26.0/24, version 3
      Paths: (1 available, best #1, table Default-IP-Routing-Table)
      Flag: 0×10820
      Advertised to update-groups:
      2
      Local
      54.1.12.2 from 0.0.0.0 (1.1.1.1)
      Origin IGP, metric 556, localpref 100, weight 32768, valid, sourced, local, best
      Rack1R1(config-router)#

  3. abx says:

    Hi Brian

    Im struggling to understand, in the previous paragraph, you state its r2 MED v r3 MED, r2 MED v r4 MED, r2 MED v r5 MED, r5 WINS as the oldest route, yet in the output example you give at the beginngin, r3 is the best route. So when does the following you describe below take place?

    “This is only because R5’s advertisement was second to the oldest that in turn broke the MED comparison between the AS 200 routers (R2, R3 and R4)”

    thanks
    abx

  4. John Smith says:

    I am still confused? Why did R3 ever get selected in the first place as a best path – You go on to show why R5 is selected over R2 and I understand this and how you eventually got R2 perferred. fine…

    But why did R3 get selcted orginally – I am not sure you explained this? Why didnt R1 compare the MED of R2,R3,R4 and select R3

    You said – “Lets look at how R1 ended up selecting R3 as the best path. First off the router will order the paths from the newest to the oldest. By default all factors in the BGP best path decision process being the same, the oldest path will be selected as best” –

    Fine – I can understand R3 would have got selected orgnally if all factors were the same; but all factors weren’t the same; R2 has the lower med of 200 so why did R3 ever get selecteed witnin AS200??

    • > Fine – I can understand R3 would have got selected orgnally if all factors were the same; but all factors weren’t the same; R2 has the lower med of 200 so why did R3 ever get selecteed witnin AS200??

      The reason is that MED is never compared between R2 and R3 since R5 which is in another AS is compared with R2. The outcome of this comparison has R5 winning since everything is the same except the age. Then finally R5 is compared with R3. R3 and R5 are in different ASes so MED isn’t compared and R3 wins and is installed as the best path. This is why if MED is going to be used in the selection process, Cisco recommends that BGP deterministic MED should be enabled. When it’s enabled all paths from AS 200 (R2, R3 and R4) are compared together and you do not have the problem like we have when R5 is thrown into the mix.

  5. vicky says:

    Hi Brian,

    I guess there is a typo and hence the confusion, you said “On R1 for the 24.1.1.0/24 network, R2’s and R3’s paths are compared first. ”

    But i dont think that is the case, first R2 and R4 are compared, R2 wins, then R2 and R5 are compared and R5 wins and then R5 and R3 are compared and R3 wins

    please correct me if I have got it wrong

    • There was an output from the show ip bgp 24.1.1.0/24 command that’s in my MS Word version but didn’t get pasted in to the blog post. I pasted it in above that paragraph and it should make it clearer as it wasn’t clear what output the paragraph was referring to.

  6. Hemanth Raj says:

    Hi Brian, Correct me in my understanding

    In ur first case, you haven’t enabled both bgp determinstic-med , bgp always-compare-med and bgp bestpath compare-routerid.

    Then all paths from AS 200 is checked in AS 100 and compares all the attributes and see that R2 has the lowest MED and then it also receives the same route from AS 300 . So now R1 cant take a decision based on MED because it knows that MED cant be compared if there are two routes from different AS. So the next thing is the oldest route. When comparing the oldest routes , R3 wins over everyone.
    ( MED cant be compared because of two different AS )

    Now the second case is when you enable bgp deterministic-med , then all paths from AS 200 will be evaluate and then the best one will be R2 ( since it has lower MED) . and now it has another route via AS 300, so now again MED cannot be compared because there are paths from two different AS. So now again the oldest route will be preferred . Now the fight is between the best paths between two AS ( selected by lowest MED) so the fight is between R2 and R5 and R5 wins the race ( oldest route when compared to R2 )

    So basically the job of bgp deterministic-med is to select the best path via MED and then compare with all other routers in another AS and select them via the oldest route

    If u wont configure bgp deterministic-med , then all the paths from all the AS will be taken into account for selecting the best path via the oldest route checking

    Correct me if i am wrong

    • > Then all paths from AS 200 is checked in AS 100 and compares all the attributes and see that R2 has the lowest MED and then it > also receives the same route from AS 300 . So now R1 cant take a decision based on MED because it knows that MED cant be
      > compared if there are two routes from different AS. So the next thing is the oldest route. When comparing the oldest routes ,
      > R3 wins over everyone. ( MED cant be compared because of two different AS )

      Correct. By default MED isn’t compared between different ASes.

      > Now the second case is when you enable bgp deterministic-med , then all paths from AS 200 will be evaluate and then the best
      > one will be R2 ( since it has lower MED) . and now it has another route via AS 300, so now again MED cannot be compared because
      > there are paths from two different AS. So now again the oldest route will be preferred . Now the fight is between the best
      > paths between two AS ( selected by lowest MED) so the fight is between R2 and R5 and R5 wins the race ( oldest route when
      > compared to R2 )

      Correct.

      > So basically the job of bgp deterministic-med is to select the best path via MED and then compare with all other routers in
      > another AS and select them via the oldest route.

      Correct.

      > If u wont configure bgp deterministic-med , then all the paths from all the AS will be taken into account for selecting the
      > best path via the oldest route checking.

      Everything else being equal then the oldest path will win out. If all paths are learned from the same AS then deterministic MED isn’t needed but when two different ASes are advertising the same path with the same AS path length and MED is going to be used (i.e. not reset inbound) then deterministic MED should be enabled.

  7. Mark Lah says:

    Awesome explanation! I’d been looking for a better explanation, as most other documentation is clouded and/or incomplete.

    Thanks for the post!

  8. mukul says:

    Great Job Brian !!
    Hemanth thnx for explanation

  9. Evaldo says:

    Nice explanation, thank you!

    Evaldo.
    Curitiba, PR – Brazil.

  10. nbhduoc says:

    This is great blog!!!

    But I got 1 question.
    When use command bgp deterministic-med, router will order routes by group. Can you give me the rule to order these groups?
    Why group AS (300 400) is oldest and group AS (200 400) is newest?

    Thanks for your post, Brian!!!

  11. dcancerian says:

    Great post!!!

  12. Raheel says:

    wow!! thanks Brain and Hemanth!

  13. luis says:

    I’ve needed one hour and read and re-read and draw and.. so on to understand it. I thought MED was smarter…
    Very good explanation Brian, good work.

  14. J says:

    should be called Multi_Entry_disc
    multi exit disc is misleading..

    in anycase…excellent blog..really appreciate you writing this..saves me the annoying read in Doyle vol 2 and having to keep up with router names like “sugarbush” and “starburst” and “henderikson” and “clusterf…no..wait..

    Tox!

  15. J says:

    1a) ALL attributes being equal till a MED comparison is made the path which is OLDEST is chosen when dealing with a paths for the same NLRI coming from a SINGLE AS.
    1b) ALL attributes being equal till a MED comparison is made the path with the LOWEST MED is chosen when dealing with a paths coming from a SINGLE AS, for the same NLRI with DETERMINISTIC MED enabled.

    ==================================================

    2a) ALL attributes being equal till a MED comparison is made the path which is OLDEST is chosen when dealing with a 2 different paths from 2 different ASes for the same NLRI .This happens because the default behavior of the IOS is to chose the oldest path since MED isn’t compared by default between ASes.

    2b) ALL attributes being equal till a MED comparison is made the path with the LOWEST MED is chosen when dealing with a 2 different paths from 2 different ASes for the same NLRI, with ALWAYS_COMPARE_MED AND DETERMINISTIC_MED
    enabled

    RIGHT?

    J

  16. Avinash says:

    Simply brilliant :) i was so confused before ,now after reading this one i can confidently say that i know something about MED .thanks brian ..

  17. Muhammad Lotfi Abbas says:

    bgp deterministic-med command compares the MED values of the routers within the same AS and decides to select the path with the lowest MED value,but when there is another path through another AS which in this case is AS 300 then R2′s MED and R5′s MED cannot be compared and R5 will be selected as the best path because its the oldest entry and it is finally installed in the Routing table as as it is the best route to 24.1.1.0 network.

  18. Alex says:

    All understood, thanks. But where is “oldest wins” rule in the best path selection process listed in Cisco?

  19. Fedya says:

    “BGP MED is a non-transitive optional attribute and thus the receiving AS cannot propagate it across its AS borders.”

    The attribute cannot cross AS borders because RFC says so, not because it’s non-transitive. (The non-transitive bit has nothing to do with crossing ASs)

 

Leave a Reply

Categories

CCIE Bloggers