BGP Best Path Selection

BGP installs the first received path as the best path automatically. When additional paths are received for the same network prefix length, the newer paths are compared against the current best path. If there is a tie, processing continues until a best path winner is identified.

Prefer the path with the..

  1. Highest weight
  2. Highest local preference
  3. Locally originated route
  4. Shortest AIGP metric attribute
  5. Shortest AS Path
  6. Lowest origin type (IGP < EGP < Incomplete)
  7. Lowest MED
  8. EBGP over IBGP
  9. Closest IGP neighbor (lowest IGP metric to BGP next-hop)
  10. Oldest route for eBGP paths
  11. Lowest BGP RID
  12. Minimum cluster list length
  13. Lowest neighbor IP address

All BGP prefixes must pass the route validity check, and the next-hop IP address must be resolvable for the route to be eligible as a best path. Some vendors and publications consider this the first step.

BGP Best Path Prerequisites

  • Next-hop value must be in the RIB
    • Prevents route recursion failure
  • Synchronization rule must be met or disabled
    • Legacy black-hole prevention technique
  • AS_PATH must not contain Local AS
    • Normal EBGP loop prevention

Longest Prefix Lenght

The BGP best-path selection algorithm influences how traffic enters or leaves an autonomous system (AS). Some router configurations modify the BGP attributes to influence inbound traffic, outbound traffic, or inbound and outbound traffic, depending on the network design requirements.

Routers always select the path a packet should take by examining the prefix length of a network entry. The path selected for a packet depends on the prefix length, where the longest prefix length is always preferred. For example, /28 is preferred over /26, and /26 is preferred over /24. This logic is used to influence path selection in BGP.

Example:

Say that an organization owns the 100.64.0.0/16 network range but needs to advertise only two subnets (100.64.1.0/24 and 100.64.2.0/24) and must still provide resiliency in the event of a router failure. It could advertise both prefixes (100.64.1.0/24 and 100.64.2.0/24) from both of its routers (R1 and R2), but how can the company distribute the network traffic for each subnet if all traffic comes in on one router (that is, R1) because of the BGP best-path algorithm? Various BGP path attributes (PAs) could be modified as they are advertised externally, but a service provider (SP) could have a BGP routing policy that ignores those path attributes, resulting in random receipt of network traffic.

A more elegant way that guarantees that paths are selected deterministically outside the organization is to advertise a summary prefix (100.64.0.0/16) out both routers. Then advertise a longer matching prefix out the router for one prefix, and then advertise a longer matching prefix out the other router for the second prefix. This allows for traffic to enter a network in a deterministic manner while still providing a backup path to the other network in the event that the first router fails.

Regardless of a SP’s routing policy, the more specific prefixes are advertised out only one router. Redundancy is provided by advertising the summary address. If R1 crashes, devices use R2’s route advertisement of 100.64.0.0/16 to reach the 100.64.1.0/24 network.

Weight

  • Higher is better.
  • A Cisco-defined attribute and the first step in selecting the BGP best path.
  • Locally Significant.
  • Not advertised to other routers.
  • It can be set for specific routes with an inbound route map or for all routes learned from a specific neighbor.
  • Influences outbound path selection.

Example:

  • R4, sets the weight to 222 for the 172.16.0.0/24 prefix received from R2 to ensure that R4 uses R2 for outbound traffic to this prefix.
  • R6, sets the weight to 333 for the 172.24.0.0/24 prefix received from R3 to ensure that R6 uses R3 for outbound traffic to this prefix.
				
					// R4
ip prefix-list ROUTE172 permit 172.16.0.0/24
!
route-map AS200 permit 10
 match ip address prefix-list ROUTE172
 set weight 222
route-map AS200 permit 20
!
router bgp 400
 neighbor 10.24.1.2 remote-as 200
 neighbor 10.24.1.2 route-map AS200 in
 neighbor 192.168.5.5 remote-as 400
 neighbor 192.168.5.5 update-source Loopback0
 neighbor 192.168.5.5 next-hop-self
 neighbor 192.168.6.6 remote-as 400
 neighbor 192.168.6.6 update-source Loopback0
 neighbor 192.168.6.6 next-hop-self
				
			
				
					// R6
ip prefix-list ROUTE172 permit 172.24.0.0/24
!
route-map AS300 permit 10
 match ip address prefix-list ROUTE172
 set weight 333
route-map AS300 permit 20
!
router bgp 400
 no bgp default ipv4-unicast
 neighbor AS400 peer-group
 neighbor AS400 remote-as 400
 neighbor AS400 update-source Loopback0
 neighbor 10.36.1.3 remote-as 300
 neighbor 192.168.4.4 peer-group AS400
 neighbor 192.168.5.5 peer-group AS400
 !
 address-family ipv4
  neighbor AS400 next-hop-self
  neighbor 10.36.1.3 activate
  neighbor 10.36.1.3 route-map AS300 in
  neighbor 192.168.4.4 activate
  neighbor 192.168.5.5 activate
 exit-address-family
				
			
R4# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 * i 172.16.0.0/24    192.168.6.6              0    100      0 300 100 i
 *>                   10.24.1.2                            222 200 100 i
 * i 172.20.0.0/24    192.168.6.6              0    100      0 300 100 i
 *>                   10.24.1.2                              0 200 100 i
 * i 172.24.0.0/24    192.168.6.6              0    100      0 300 100 i
 *>                   10.24.1.2                              0 200 100 i
R4# show bgp ipv4 unicast 172.16.0.0/24
BGP routing table entry for 172.16.0.0/24, version 4
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     2
! Path #1
  Refresh Epoch 4
  300 100
    192.168.6.6 (metric 21) from 192.168.6.6 (192.168.6.6)
      Origin IGP, metric 0, localpref 100, valid, internal
! Path #2
  Refresh Epoch 2
  200 100
    10.24.1.2 from 10.24.1.2 (192.168.2.2)
      Origin IGP, localpref 100, weight 222, valid, external, best
R5# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4              0    100      0 200 100 i
 * i                  192.168.6.6              0    100      0 300 100 i
 *>i 172.20.0.0/24    192.168.4.4              0    100      0 200 100 i
 * i                  192.168.6.6              0    100      0 300 100 i
 *>i 172.24.0.0/24    192.168.4.4              0    100      0 200 100 i
 * i                  192.168.6.6              0    100      0 300 100 i
R6# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 * i 172.16.0.0/24    192.168.4.4              0    100      0 200 100 i
 *>                   10.36.1.3                              0 300 100 i
 * i 172.20.0.0/24    192.168.4.4              0    100      0 200 100 i
 *>                   10.36.1.3                              0 300 100 i
 * i 172.24.0.0/24    192.168.4.4              0    100      0 200 100 i
 *>                   10.36.1.3                            333 300 100 i

Local Preference

  • Higher is better, indicates the preference for exiting the AS to the destination network prefix.
  • A well-known discretionary path attribute and is included with path advertisements throughout an AS, to other iBGP peers.
  • Not advertised to eBGP peers.
  • Carried through confederation eBGP.
  • It can be set for specific routes by using a route map or for all routes received from a specific neighbor.
  • Default local preference value is 100.
  • Influences outbound path selection.

Example:

  • R4, sets the local preference to 222 for the 172.16.0.0/24 prefix received from R2, making it the preferred path for AS 400.
  • R6, sets the local preference to 333 for the 172.24.0.0/24 prefix received from R3, making it the preferred path for AS 400.
				
					// R4
ip prefix-list PRE172 permit 172.16.0.0/24
!
route-map AS200 permit 10
 match ip address prefix-list PRE172
 set local-preference 222
route-map AS200 permit 20
!
router bgp 400
 neighbor 10.24.1.2 remote-as 200
 neighbor 10.24.1.2 route-map AS200 in
 neighbor 192.168.5.5 remote-as 400
 neighbor 192.168.5.5 update-source Loopback0
 neighbor 192.168.5.5 next-hop-self
 neighbor 192.168.6.6 remote-as 400
 neighbor 192.168.6.6 update-source Loopback0
 neighbor 192.168.6.6 next-hop-self
				
			
				
					// R6
ip prefix-list PRE172 permit 172.24.0.0/24
!
route-map AS300 permit 10
 match ip address prefix-list PRE172
 set local-preference 333
route-map AS300 permit 20
!
router bgp 400
 no bgp default ipv4-unicast
 neighbor AS400 peer-group
 neighbor AS400 remote-as 400
 neighbor AS400 update-source Loopback0
 neighbor 10.36.1.3 remote-as 300
 neighbor 192.168.4.4 peer-group AS400
 neighbor 192.168.5.5 peer-group AS400
 !
 address-family ipv4
  neighbor AS400 next-hop-self
  neighbor 10.36.1.3 activate
  neighbor 10.36.1.3 route-map AS300 in
  neighbor 192.168.4.4 activate
  neighbor 192.168.5.5 activate
				
			
R4# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.0.0/24    10.24.1.2                     222      0 200 100 i
 * i 172.20.0.0/24    192.168.6.6              0    100      0 300 100 i
 *>                   10.24.1.2                              0 200 100 i
 *>i 172.24.0.0/24    192.168.6.6              0    333      0 300 100 i
 *                    10.24.1.2                              0 200 100 i
R5# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4              0    222      0 200 100 i
 * i 172.20.0.0/24    192.168.6.6              0    100      0 300 100 i
 *>i                  192.168.4.4              0    100      0 200 100 i
 *>i 172.24.0.0/24    192.168.6.6              0    333      0 300 100 i
R6# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4              0    222      0 200 100 i
 *                    10.36.1.3                              0 300 100 i
 * i 172.20.0.0/24    192.168.4.4              0    100      0 200 100 i
 *>                   10.36.1.3                              0 300 100 i
 *>  172.24.0.0/24    10.36.1.3                     333      0 300 100 i
Might see that only one path exists on R4 for the 172.16.0.0/24 network prefix, and think R4 deleted the path through AS 300 because it was inferior to the path through AS 200. However, this is not what has happened in this example. A router does not discard a path that is not chosen as the best path. The path is always maintained in the BGP Loc-RIB database and could be used later, in the event that the best path is no longer available. If a router identifies a different best path from the one advertised, it withdraws its previous best path advertisement to other routers and advertises the new best path.

Phase 1

  • R4 receives the prefix for 172.16.0.0/24 from R2 and sets the local preference to 222.
  • R4 receives the 172.20.0.0/24 and 172.24.0.0/24 prefixes from R2.
  • No other paths exist for these prefixes, so all paths are marked as best paths.
  • R4 advertises these paths to R5 and R6. (Routes without local preference set are advertised with the local preference 100.)
R4# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.0.0/24    10.24.1.2                     222      0 200 100 i
 *>  172.20.0.0/24    10.24.1.2                              0 200 100 i
 *>  172.24.0.0/24    10.24.1.2                              0 200 100 i
  • R6 receives the prefix for 172.24.0.0/24 from R3 and sets the local preference to 333.
  • R6 receives the 172.16.0.0/24 and 172.20.0.0/24 prefixes from R3.
  • No other paths exist for these prefixes, so all paths are marked as best paths.
  • R6 advertises these paths to R4 and R5.
R6# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.0.0/24    10.36.1.3                              0 300 100 i
 *>  172.20.0.0/24    10.36.1.3                              0 300 100 i
 *>  172.24.0.0/24    10.36.1.3                     333      0 300 100 i

Phase 2

Phase II is the phase when R4 and R6 have received each other’s routes and compare each path for a prefix.

R6 advertises a route withdrawal for the 172.16.0.0/24 network prefix, and R4 advertises a route withdrawal for the 172.24.0.0/24 network prefix. R5 receives routes from R4 and R6 at the same time, resulting in both paths being present in the BGP Loc-RIB table.

  • R4 receives R6’s paths for all the prefixes from R3.
  • R4 detects that the 172.16.0.0/24 path from R2 (AS 200) has a higher local preference than the path from R6 (AS 300). R4 keeps the path from R2 as the best path for the prefix.
  • R4 detects that the 172.20.0.0/24 path from R3 has the same local preference as the path from R2. (Routes without local preference use the default value 100.) Because of the tie, the best path is selected using steps after local preference in the best-path algorithm.
  • R4 detects that the 172.24.0.0/24 path from R6 (AS 300) has a higher local preference than the path from R2 (AS 200). R4 marks the path from R6 as the best path for the prefix and sends route withdrawals to R5 and R6 for the path from R2.
R4# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.0.0/24    10.24.1.2                     222      0 200 100 i
 * i                  192.168.6.6              0    100      0 300 100 i
 *>  172.20.0.0/24    10.24.1.2                              0 200 100 i
 * i                  192.168.6.6              0    100      0 300 100 i
 *   172.24.0.0/24    10.24.1.2                              0 200 100 i
 *>i                  192.168.6.6              0    333      0 300 100 i
  • R5 receives paths for all network prefixes from R4 and R6.
  • R5 detects that the 172.16.0.0/24 path from R4 (AS 200) has a higher local preference than the path from R6 (AS 300). R5 marks the path from R4 as the best path for the prefix. Both paths exist in the BGP table.
  • R5 detects that the 172.20.0.0/24 paths from R4 and R6 has identical local preference values and uses steps after local preference in the best-path algorithm. Both paths exist in the BGP table.
  • R5 detects that the 172.24.0.0/24 path from R6 (AS 300) has a higher local preference than the path from R2 (AS 200). R5 selects the path from R6 as the best path for the prefix. Both paths exist in the BGP table.
R5# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4              0    222      0 200 100 i
 * i                  192.168.4.4              0    100      0 200 100 i
 * i 172.20.0.0/24    192.168.6.6              0    100      0 300 100 i
 *>i                  192.168.4.4              0    100      0 200 100 i
 *>i 172.24.0.0/24    192.168.6.6              0    333      0 300 100 i
 * i                  192.168.4.4              0    100      0 200 100 i
  • R6 receives R4’s route advertisement for all the prefixes from R2.
  • R6 detects that the 172.16.0.0/24 path from R4 (AS 200) has a higher local preference than the path from R3 (AS 300). R6 selects the path from R4 as the best path for the prefix and sends route withdrawals to R4 and R5 for the paths from R3.
  • R6 detects that the 172.20.0.0/24 path from R3 has the same local preference as the path from R4. (Routes without local preference use the default value 100.) Because of the tie, the best path is selected using steps after local preference in the best-path algorithm.
  • R6 detects that the 172.24.0.0/24 path from R3 (AS 300) has a higher local preference than the path from R4 (AS 200). R6 keeps the path from R3 as the best path for the prefix.
R6# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *   172.16.0.0/24    10.36.1.3                              0 300 100 i
 *>i                  192.168.4.4              0    222      0 200 100 i
 *>  172.20.0.0/24    10.36.1.3                              0 300 100 i
 * i                  192.168.4.4              0    100      0 200 100 i
 *>  172.24.0.0/24    10.36.1.3                     333      0 300 100 i
 * i                  192.168.4.4              0    100      0 200 100 i

Phase 3

  • R4 and R5 receive R6’s withdrawal for the 172.16.0.0/24 network prefix and remove it from the BGP table.
  • R5 and R6 receive R4’s withdrawal for the 172.24.0.0/24 network prefix and remove it from the BGP table.
R4# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.0.0/24    10.24.1.2                     222      0 200 100 i
 * i 172.20.0.0/24    192.168.6.6              0    100      0 300 100 i
 *>                   10.24.1.2                              0 200 100 i
 *>i 172.24.0.0/24    192.168.6.6              0    333      0 300 100 i
 *                    10.24.1.2                              0 200 100 i
R5# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4              0    222      0 200 100 i
 * i 172.20.0.0/24    192.168.6.6              0    100      0 300 100 i
 *>i                  192.168.4.4              0    100      0 200 100 i
 *>i 172.24.0.0/24    192.168.6.6              0    333      0 300 100 i
R6# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4              0    222      0 200 100 i
 *                    10.36.1.3                              0 300 100 i
 * i 172.20.0.0/24    192.168.4.4              0    100      0 200 100 i
 *>                   10.36.1.3                              0 300 100 i
 *>  172.24.0.0/24    10.36.1.3                     333      0 300 100 i

Locally Originated Route

  • ..to determine whether the route was originated locally
  • Locally originated routes gets weight 32,768
  • Prefer locally originated

Preference is given in the following order:

  1. Routes that were advertised locally
  2. Networks that have been aggregated locally
  3. Routes received by BGP peers

Shortest AS_PATH

  • Smaller length is better
  • Influences inbound path selection

Prepending ASNs to AS_Path makes the AS_Path longer, thereby making that path less desirable compared with other paths. Typically, the AS_Path is prepended by the network owner, and the owner’s own ASN is used for the prepending. In general, paths that have had AS_Path prepended are not selected as the BGP best path because AS_Path is longer than the non-prepended path advertisement.

Inbound traffic is influenced by prepending AS_Path length in advertisements sent to other ASs, and outbound traffic is influenced by prepending advertisements received from other ASs.

Example:

  • R4 prepends AS 222 210 for the 172.24.0.0/24 path received from R2, making it the least preferred path for AS 400.
  • R6 prepends AS 333 321 for the 172.16.0.0/24 path received from R3, making it the least preferred path for AS 400.
				
					// R4
ip prefix-list PRE172 permit 172.24.0.0/24
!
route-map AS200 permit 10
 match ip address prefix-list PRE172
 set as-path prepend 222 210
route-map AS200 permit 20
!
router bgp 400
 neighbor 10.24.1.2 remote-as 200
 neighbor 10.24.1.2 route-map AS200 in
				
			
				
					// R6
ip prefix-list PRE172 permit 172.16.0.0/24
!
route-map AS300 permit 10
 match ip address prefix-list PRE172
 set as-path prepend 333 321
route-map AS300 permit 20
!
router bgp 400
 neighbor 10.36.1.3 remote-as 300
 neighbor 10.36.1.3 route-map AS300 in
				
			

All three routers have selected the path through R3 (AS 300) as the best path for the 172.24.0.0/24 network prefix because it has the shortest AS_Path length.

R4# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.0.0/24    10.24.1.2                              0 200 100 i
 *>  172.20.0.0/24    10.24.1.2                              0 200 100 i
 * i                  192.168.6.6              0    100      0 300 100 i
 *   172.24.0.0/24    10.24.1.2                              0 222 210 200 100 i
 *>i                  192.168.6.6              0    100      0 300 100 i
R5# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4              0    100      0 200 100 i
 * i 172.20.0.0/24    192.168.4.4              0    100      0 200 100 i
 *>i                  192.168.6.6              0    100      0 300 100 i
 *>i 172.24.0.0/24    192.168.6.6              0    100      0 300 100 i
R6# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4              0    100      0 200 100 i
 *                    10.36.1.3                              0 333 321 300 100 i
 * i 172.20.0.0/24    192.168.4.4              0    100      0 200 100 i
 *>                   10.36.1.3                              0 300 100 i
 *>  172.24.0.0/24    10.36.1.3                              0 300 100 i
Remember that BGP routers do not remove inferior routes. The routes must be withdrawn from a neighbor in order to be removed.

Origin Type

  • A well-known mandatory BGP attribute.
  • By default, networks that are advertised on Cisco routers using the network statement are set with i (for IGP) origin, redistributed networks are assigned the ? (incomplete) origin attribute.
  • IGP > EGP > Incomplete

Example:

  • R4 sets the origin to incomplete for the 172.24.0.0/24 path received from R2, making it the least preferred path for R4, R5, and R6.
  • R6 sets the origin to incomplete for the 172.16.0.0/24 path received from R3, making it the least preferred path for R4, R5, and R6.
				
					// R4
ip prefix-list PRE172 permit 172.24.0.0/24
!
route-map AS200 permit 10
 match ip address prefix-list PRE172
 set origin incomplete
route-map AS200 permit 20
!
router bgp 400
 neighbor 10.24.1.2 remote-as 200
 neighbor 10.24.1.2 route-map AS200 in
				
			
				
					// R6
ip prefix-list PRE172 permit 172.16.0.0/24
!
route-map AS300 permit 10
 match ip address prefix-list PRE172
 set origin incomplete
route-map AS300 permit 20
!
router bgp 400
 neighbor 10.36.1.3 remote-as 300
 neighbor 10.36.1.3 route-map AS300 in
				
			

A path with an incomplete origin is not selected as the best path because the IGP origin is preferred over the incomplete origin. Notice the origin codes (i and ?) on the far right, after the AS_Path information.

R4# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.0.0/24    10.24.1.2                              0 200 100 i
 * i 172.20.0.0/24    192.168.6.6              0    100      0 300 100 i
 *>                   10.24.1.2                              0 200 100 i
 *>i 172.24.0.0/24    192.168.6.6              0    100      0 300 100 i
 *                    10.24.1.2                              0 200 100 ?
R5# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4              0    100      0 200 100 i
 * i 172.20.0.0/24    192.168.4.4              0    100      0 200 100 i
 *>i                  192.168.6.6              0    100      0 300 100 i
 *>i 172.24.0.0/24    192.168.6.6              0    100      0 300 100 i
R6# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4              0    100      0 200 100 i
 *                    10.36.1.3                              0 300 100 ?
 * i 172.20.0.0/24    192.168.4.4              0    100      0 200 100 i
 *>                   10.36.1.3                              0 300 100 i
 *>  172.24.0.0/24    10.36.1.3                              0 300 100 i

Multi-Exit Discriminator (MED)

  • MED, non-transitive BGP attribute.
  • The MED uses a 32-bit value (0 to 4,294,967,295) called a metric.
  • BGP sets the MED automatically to the IGP path metric during network advertisement or redistribution. If the MED is received from an eBGP session, it can be advertised to other iBGP peers, but it should not be sent outside the AS that received it.
  • The MED’s purpose is to influence traffic flows inbound from a different AS.
  • In order for the MED to be an effective decision factor, the paths being decided upon must come from the same ASN.
  • A lower MED is preferred over a higher MED.
  • RFC 4451 guidelines state that a prefix without a MED value should be given priority and, in essence, should be compared with the value 0. Some organizations require that a MED be set to a specific value for all the prefixes and declare that paths without the MED should be treated as the least preferred. By default, if the MED is missing from a prefix learned from an eBGP peer, devices use a MED of 0 for the best-path calculation. IOS routers advertise a MED of 0 to iBGP peers.

Example:

  • AS 100 advertises the 172.16.0.0/24 and 172.20.0.0/24 network prefixes with different MED values at each edge router (R1 and R2).
  • AS 200 sends traffic out R3 to the 172.16.10.0/24 network prefix because R1’s MED (40) is lower than R2’s MED (60).
  • AS 200 sends traffic out R4 to the 172.20.0.0/24 network prefix because R2’s MED (30) is lower than R1’s MED (70).

Example:

  • R4 sets the MED to 40 for 172.16.0.0/24, 50 for 172.20.0.0/24, and 90 for 172.24.0.0/24.
  • R6 sets the MED to 80 for 172.16.0.0/24 and 10 for 172.24.0.0/24.
				
					// R4
ip prefix-list PRE172-01 permit 172.16.0.0/24
ip prefix-list PRE172-02 permit 172.20.0.0/24
ip prefix-list PRE172-03 permit 172.24.0.0/24
!
route-map AS200-R2 permit 10
 match ip address prefix-list PRE172-01
 set metric 40
route-map AS200-R2 permit 20
 match ip address prefix-list PRE172-02
 set metric 50
route-map AS200-R2 permit 30
 match ip address prefix-list PRE172-03
 set metric 90
route-map AS200-R2 permit 40
!
router bgp 400
 neighbor 10.24.1.2 remote-as 200
 neighbor 10.24.1.2 route-map AS200-R2 in
				
			
				
					// R6
ip prefix-list PRE172-01 permit 172.16.0.0/24
ip prefix-list PRE172-03 permit 172.24.0.0/24
!
route-map AS200-R3 permit 10
 match ip address prefix-list PRE172-01
 set metric 80
route-map AS200-R3 permit 20
 match ip address prefix-list PRE172-03
 set metric 10
route-map AS200-R3 permit 30
!
router bgp 400
 neighbor 10.36.1.3 remote-as 200
 neighbor 10.36.1.3 route-map AS200-R3 in
				
			
R4# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.0.0/24    10.24.1.2               40             0 200 100 i
 *>i 172.20.0.0/24    192.168.6.6              0    100      0 200 100 i
 *                    10.24.1.2               50             0 200 100 i
 *>i 172.24.0.0/24    192.168.6.6             10    100      0 200 100 i
 *                    10.24.1.2               90             0 200 100 i
R5# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4             40    100      0 200 100 i
 *>i 172.20.0.0/24    192.168.6.6              0    100      0 200 100 i
 *>i 172.24.0.0/24    192.168.6.6             10    100      0 200 100 i
R6# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4             40    100      0 200 100 i
 *                    10.36.1.3               80             0 200 100 i
 *>  172.20.0.0/24    10.36.1.3                              0 200 100 i
 *>  172.24.0.0/24    10.36.1.3               10             0 200 100 i

Missing MED Behavior

bgp bestpath med missing-as-worst

An organization may expect its different SPs to advertise a MED value for every prefix. If a MED is missing, the path without a MED is preferred over a path that contains a MED. An organization can modify the default behavior so that prefixes without a MED are always selected last.

In the above example, R6’s route map is configured to not set the MED on the 172.20.0.0/24 prefix when received by R3. When the MED is not advertised, the value is assumed to be zero (0). All three routers in AS 400 evaluate the MED of 0 (from R3) versus 50 (from R2). The routers select the path through R3 as the preferred path.

Scenarios like this could lead to some unintended routing behavior. The command bgp bestpath med missing-as-worst under the BGP router process sets the MED to infinity (4,294,967,295) if the MED is missing from a path. The command should be placed on all nodes in an AS.

The BGP configuration command default-metric metric sets the metric to the value specified when a path is received without a MED. This allows routers to calculate the BGP best path for prefixes without requiring that the MED attribute be set manually or be set to infinity.

R4# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>  172.16.0.0/24    10.24.1.2               40             0 200 100 i
 *>  172.20.0.0/24    10.24.1.2               50             0 200 100 i
 *>i 172.24.0.0/24    192.168.6.6             10    100      0 200 100 i
 *                    10.24.1.2               90             0 200 100 i
R5# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
 *>i 172.16.0.0/24    192.168.4.4             40    100      0 200 100 i
 *>i 172.20.0.0/24    192.168.4.4             50    100      0 200 100 i
 *>i 172.24.0.0/24    192.168.6.6             10    100      0 200 100 i
R6# show bgp ipv4 unicast | begin Network
     Network          Next Hop            Metric LocPrf Weight Path
*>i  172.16.0.0/24    192.168.4.4             40    100      0 200 100 i
 *                    10.36.1.3               80             0 200 100 i
 *>i 172.20.0.0/24    192.168.4.4             50    100      0 200 100 i
 *                    10.36.1.3       4294967295             0 200 100 i
 *>  172.24.0.0/24    10.36.1.3               10             0 200 100 i

Always Compared MED

bgp always-compare-med

The default MED comparison mechanism requires the AS_Path values to be identical because the policies used to set the MED could vary from AS to AS. This means that the MED can influence traffic only when multiple links are from the same service provider. Typically, organizations use different service providers for redundancy. In these situations, the default BGP rules for MED comparison need to be relaxed to compare MEDs between different service providers.

The bgp always-compare-med feature allows for the comparison of MED regardless of the AS_Path. Enable this feature on all BGP routers in the AS, or routing loops can occur.

BGP Deterministic MED

bgp deterministic-med

The best-path algorithm compares a route update to the existing best path and processes the paths in the order in which they are stored in the Loc-RIB table. The paths are stored in the order in which they are received in the BGP table. If always-compare-med is not enabled, the path MED is only compared against the existing best path and not against all the paths in the Loc-RIB table, which can cause variations in the MED best-path comparison process.

Example:

  • R4 advertises the 172.16.0.0/24 prefix with a MED of 200, and R5 selects R4’s path as the best path because no other paths exist.
  • R3 advertises the 172.16.0.0/24 prefix with a MED of 100. The AS_Path is from a different AS compared to R4’s, so the MED is not considered in the BGP best-path calculation. R4’s path remains the best path because it is the oldest eBGP-learned route.
  • R2 advertises the 172.16.0.0/24 prefix with a MED of 150. The AS_Path differs from R4’s, so MED is not considered in the BGP best-path calculation. R4’s path remains the best path because it is the oldest eBGP-learned route.

BGP deterministic MED corrects the problem by grouping together paths with identical AS_Path values as part of the best-path identification process. Each group’s MED is compared against the other group’s MED.

With BGP deterministic MED enabled, the best-path selection outcome is different.

  • R2’s and R3’s paths are grouped together because they have an identical AS_Path value (200 100).
  • R4 is placed into a separate group, by itself, because of its AS_Path (300 100).
  • The two AS_Path groups are then compared against each other, and because R3’s MED is lower than R4’s, R3’s path is chosen as the best path, regardless of the order in which the routes are advertised.

BGP deterministic MED is enabled with the BGP configuration command bgp deterministic-med and is recommended for all BGP deployments in the same AS.

EBGP over IBGP

  • eBGP peer (most desirable) > Confederation member AS peers > iBGP peers (least desirable)

Lowest IGP Metric

The next decision step is to use the lowest IGP cost to the BGP next-hop address.

Prefer the Oldest EBGP Path

BGP can maintain large routing tables, and unstable sessions result in the BGP best-path calculation executing frequently. BGP maintains stability in a network by preferring the path from the oldest (established) BGP session.

Lowest RID

The next step for the BGP best-path algorithm is to select the best path using the lowest router ID of the advertising EBGP router. If the route was received by a route reflector, then the originator ID is substituted for the router ID.

Minimum Cluster List Length

The next step in the BGP best-path algorithm is to select the best path using the lowest cluster list length.

  • The cluster list is a non-transitive BGP attribute that is appended (not overwritten) by a route reflector with its cluster ID.
  • Route reflectors use the cluster-id attribute as a loop-prevention mechanism.
  • The cluster ID is not advertised between ASs and is locally significant.
  • In simplest terms, this step locates the path that has traveled the smallest number of iBGP advertisement hops.

Lowest Neighbor Address

The last step of the BGP best-path algorithm involves selecting the path that comes from the lowest BGP neighbor address. This step is limited to iBGP peerings because eBGP peerings use the oldest received path as the tie breaker.

Leave a Reply

Related Post

BGP FundamentalsBGP Fundamentals

BGP A router’s primary function is to move packets from one network to a different network. A router learns about unattached networks through static configuration or through dynamic routing protocols

BGP PacketsBGP Packets

BGP uses a variety of messages for establishing the connection, exchanging routing information, checking if the remote BGP neighbor is still there and/or notifying the remote side if any errors