BGP

BGP Best Path Selection Algorithm — All 13 Steps

Cisco BGP picks the best path with a 13-step algorithm. Most real decisions resolve in steps 1 to 5, but troubleshooting unexpected path selection means knowing every step. A complete walkthrough with examples.
BGP Best Path Selection Algorithm — All 13 Steps
In: BGP

When a BGP router has multiple paths to the same prefix, it needs a deterministic way to pick one as the best. Cisco's BGP implementation uses a 13-step algorithm, evaluated top-to-bottom. The first step that produces a clear winner ends the evaluation. Most real-world decisions are made in the first four or five steps — but understanding all thirteen is critical for troubleshooting cases where BGP picks a path you didn't expect (covered in Why Is BGP Choosing the Wrong Path?).

Prerequisites for Path Consideration

Before a path even enters the best path algorithm, it must pass two checks:

  • Valid next-hop: The next-hop address must be reachable in the routing table. If it's not resolvable, the path is marked as "not valid" and excluded. This is the most common reason iBGP routes don't get installed — see BGP Next-Hop-Self.
  • Synchronized (if synchronization is enabled): The prefix must also exist in the IGP. Synchronization is disabled by default on modern IOS XE (no synchronization), so this check rarely applies.

The 13 Steps

Step 1: Highest Weight (Cisco-proprietary)

Weight is a Cisco-only attribute, local to the router — it's never advertised to any peer. Default is 0 for learned routes, 32768 for locally originated routes. Higher weight wins.

R1-HQ(config-router)# neighbor 203.0.113.1 weight 200

This sets weight 200 for all routes from ISP-A-PE1. Since 200 > 0 (default for routes from ISP-B), ISP-A paths win at step 1.

Use weight when you want to influence path selection on a single router without affecting any other router in your AS. Covered in Cisco BGP Weight Attribute.

Step 2: Highest Local Preference

LOCAL_PREF is an iBGP attribute (not sent to eBGP peers). Default is 100. Higher wins. Unlike weight, local-pref propagates to all iBGP peers in your AS, so it influences path selection network-wide.

route-map PREFER-ISP-A permit 10
 set local-preference 150
!
router bgp 65001
 neighbor 203.0.113.1 route-map PREFER-ISP-A in

All routes from ISP-A get local-pref 150, beating the default 100 from ISP-B across the entire AS. Covered in Manipulating BGP Local Preference.

Step 3: Locally Originated

Prefer routes originated locally via the network command, redistribution, or aggregation over routes learned from a peer. Locally originated routes have a weight of 32768 (which usually wins at step 1 anyway), but this step catches edge cases where weight was manually set to equal values.

Step 4: Shortest AS-Path

Count the number of ASes in the AS_PATH attribute. Fewer hops is preferred. A route through AS 65010 (one hop) beats a route through AS 65020 → AS 65010 (two hops).

This is where AS-path prepending comes in — artificially lengthening the AS-path to make a route less preferred. Covered in BGP AS-Path Prepending.

Note: bgp bestpath as-path ignore disables this step entirely. Some large networks do this to rely purely on local-pref and MED.

Step 5: Lowest Origin Type

IGP (i) < EGP (e) < Incomplete (?). Routes injected via the network command get IGP origin; redistributed routes get Incomplete. EGP origin is historic and rarely seen.

Step 6: Lowest MED

Multi-Exit Discriminator — a suggestion to your eBGP neighbor about which of your entry points to prefer. Lower MED wins. By default, MED is only compared between paths from the same neighboring AS.

bgp always-compare-med changes this behavior to compare MED across all paths regardless of the advertising AS. Covered in BGP MED: Influencing Inbound Traffic.

Step 7: eBGP over iBGP

Prefer eBGP-learned routes (AD 20) over iBGP-learned routes (AD 200). If R1-HQ learns 100.64.0.0/24 from ISP-A via eBGP and from R2-HQ via iBGP, the eBGP path wins here.

Step 8: Lowest IGP Metric to Next-Hop

If multiple paths have the same attributes through step 7, prefer the path whose BGP next-hop is closest in terms of IGP cost. This is "hot potato routing" — hand off the traffic to the nearest exit point.

This step is significant in large networks with multiple border routers. R1-HQ might prefer ISP-A because the IGP cost to 203.0.113.1 (ISP-A next-hop) is lower than the cost to reach R2-HQ's advertised next-hop for the ISP-B path.

Step 9: Multipath (if enabled)

If maximum-paths is configured and multiple paths are equal through step 8, install them all for ECMP load balancing. The algorithm continues below only to select the single "best" for advertisement purposes.

Step 10: Oldest eBGP Path

Prefer the path that has been in the BGP table the longest. This provides stability — don't flip between equally good paths just because a new one appeared. Only applies to eBGP paths.

Step 11: Lowest Router ID

Compare the BGP router IDs of the advertising peers. Lower router ID wins. If the route was learned from a route reflector, the ORIGINATOR_ID is used instead of the advertising peer's router ID.

Step 12: Shortest Cluster List

In route reflector environments, prefer the path with the fewest cluster IDs in the CLUSTER_LIST — meaning fewer RR hops.

Step 13: Lowest Neighbor Address

Final tiebreaker — prefer the path received from the peer with the lowest IP address. This guarantees a deterministic outcome even when everything else is identical.

Get the BGP Field Reference - 9 pages, free

Everything you'd want to remember about BGP on nine printable pages. FSM diagram, all 13 best-path steps with gotchas, troubleshooting decision tree, copy-paste IOS XE templates, and real lab captures. Free for PingLabz members - just sign up with your email.

Get the BGP cheat-sheet

Verifying the Decision

R1-HQ# show ip bgp 100.64.0.0/24
BGP routing table entry for 100.64.0.0/24, version 18
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1
  65010
    203.0.113.1 from 203.0.113.1 (203.0.113.1)
      Origin IGP, metric 0, localpref 150, weight 0, valid, external, best
      rx pathid: 0, tx pathid: 0x0
  65020 65010
    198.51.100.1 from 198.51.100.1 (198.51.100.1)
      Origin IGP, metric 0, localpref 100, weight 0, valid, external
      rx pathid: 0, tx pathid: 0

Path 1 wins because local-pref 150 > 100 (step 2). The AS-path is also shorter (1 vs 2 hops), but the algorithm never gets to step 4 — local-pref already decided it.

For more detail on why a specific path was chosen:

R1-HQ# show ip bgp 100.64.0.0/24 bestpath-compare
BGP routing table entry for 100.64.0.0/24
  Comparing 203.0.113.1 (best) and 198.51.100.1
  Step 1: Weight: Equal (0 vs 0)
  Step 2: Local Preference: 150 > 100 — first path wins

Common Gotchas

  • MED comparison scope: MED is only compared between paths from the same AS by default. If you have paths from AS 65010 and AS 65020, MED is ignored unless bgp always-compare-med is configured.
  • Weight is local: Setting weight on one router doesn't affect any other router in your AS. If you want AS-wide preference, use local-pref.
  • Next-hop unreachable: The path never enters the algorithm at all. Always verify next-hop reachability first.
  • AS-path length with prepending: Prepending adds artificial length but doesn't change the actual path. A prepended 3-hop path may not outweigh a high local-pref on the other path — local-pref is evaluated first.

Key Takeaways

  • BGP best path selection is a 13-step sequential algorithm — the first step to produce a winner ends evaluation.
  • The most commonly decisive steps are Weight (1), Local Preference (2), AS-Path Length (4), and eBGP over iBGP (7).
  • Weight is Cisco-proprietary and local to one router. Local-pref propagates AS-wide. MED is a suggestion to your neighbor.
  • A path must have a valid (reachable) next-hop to even enter the algorithm.
  • Use show ip bgp [prefix] and show ip bgp [prefix] bestpath-compare to understand exactly why BGP chose a specific path.
Written by
More from Ping Labz
MPLS L3VPN with MP-BGP and VPNv4
MPLS

MPLS L3VPN with MP-BGP and VPNv4

MPLS L3VPN architecture: VRFs, Route Distinguishers, Route Targets, MP-BGP for VPNv4, the two-label stack, PE-CE routing, and the Cisco IOS XE configuration.
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Ping Labz.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.