In the Internet's complex mesh of interconnected networks, any given destination may be reachable via dozens or even hundreds of different paths. BGP's best path selection algorithm is the decision engine that chooses which path to use for forwarding traffic—a decision with enormous implications for performance, cost, and reliability.

Unlike interior gateway protocols that typically optimize for a single metric (like shortest path or lowest cost), BGP must balance multiple objectives: respect business relationships, honor policy preferences, minimize path length, and maximize stability. The result is a sophisticated multi-step algorithm that evaluates routes through a sequence of criteria, selecting the optimal path for each destination prefix.

BGP's best path selection is a deterministic algorithm that compares candidate routes step by step until a single winner remains. Understanding this process is essential for predicting routing behavior and implementing traffic engineering.

When Is Best Path Selection Triggered?

1. New Route Learned: When a peer advertises a previously unknown prefix
2. Route Update: When a peer advertises new attributes for an existing prefix
3. Route Withdrawal: When the current best path is withdrawn
4. Configuration Change: When policy or preference settings change
5. IGP Metric Change: When the path to NEXT_HOP changes
6. Timer Expiry: Some implementations re-evaluate periodically

Key Principles:

1. Single Best Path: Standard BGP selects exactly one best path per prefix (some implementations support multipath).

2. Deterministic Outcome: Given the same inputs, the algorithm always produces the same result.

3. Incremental Evaluation: Routes are compared pairwise until only one remains.

4. Local Decision: Each router makes independent decisions based on its local view.

Before the formal selection algorithm runs, routes must pass basic validity checks. These are not "preferences"—they're requirements. A route that fails any of these checks is not considered a candidate.

Validity Check 1: NEXT_HOP Reachability

The router must have a valid route to the NEXT_HOP address. For iBGP routes, this typically means the NEXT_HOP must be reachable via IGP. If the IGP route to NEXT_HOP disappears, the BGP route becomes invalid.

! Example: Show routes and their NEXT_HOP status
R1# show ip bgp 192.0.2.0/24
  10.0.0.5 from 10.1.1.1 (10.1.1.1)
    NEXT_HOP: inaccessible
    → This route will NOT be used in best path selection

Validity Check 2: AS-Path Loop Detection

Routes containing the local AS number in the AS_PATH are rejected (unless allowas-in is configured). This prevents routing loops.

Validity Check 3: Route in Adj-RIB-In

The route must have been received from a peer and stored in the incoming route table. Routes filtered on inbound are never considered.

Validity Check 4: No ORIGINATOR_ID Match

For route reflector environments, if the ORIGINATOR_ID matches the router's own Router ID, the route is rejected (loop prevention).

Validity Check 5: Cluster List Loop Detection

If the CLUSTER_LIST contains the router's Cluster ID, the route is rejected (RR loop prevention).

Common Validity Failures:

Diagnostic Approach:

When a route isn't being used as expected:

1. Check if the route exists: show ip bgp <prefix>
2. Check NEXT_HOP reachability: show ip route <next-hop>
3. Check best path selection output: show ip bgp <prefix> (shows why selected or not)
4. Verify no AS loop: Look at AS_PATH
5. Check inbound filters: May need debug or filter analysis

The first true selection criteria are administratively controlled preferences. These give network operators explicit control over path selection.

Weight (Cisco Proprietary)

Weight is a Cisco-specific attribute that takes precedence over all other criteria. It's purely local—never sent to any peer—and affects only the router where it's configured.

Configuration Examples:

! Set weight for all routes from a neighbor
neighbor 10.0.0.2 weight 200

! Set weight via route-map (more flexible)
route-map PREFER-PRIMARY permit 10
  set weight 500

neighbor 10.0.0.1 route-map PREFER-PRIMARY in

When to Use Weight:

• Override all other attributes for specific peers
• Implement strict primary/backup without affecting other routers
• Quick, local-only traffic engineering

LOCAL_PREF Attribute

LOCAL_PREF is the primary tool for AS-wide policy. Unlike Weight, LOCAL_PREF is shared with all iBGP peers, ensuring consistent egress selection throughout the AS.

Configuration Examples:

! Set LOCAL_PREF on inbound from eBGP peer
route-map SET-LOCALPREF permit 10
  set local-preference 150

neighbor 203.0.113.1 route-map SET-LOCALPREF in

! Community-based LOCAL_PREF (common with transit providers)
route-map CUSTOMER-IN permit 10
  match community CUSTOMER
  set local-preference 200
route-map CUSTOMER-IN permit 20
  match community PEER
  set local-preference 100
route-map CUSTOMER-IN permit 30
  match community TRANSIT
  set local-preference 50

Typical LOCAL_PREF Values (Example Policy):

After administrative preferences (Weight, LOCAL_PREF) and local origination preference, BGP evaluates path-based criteria:

Locally Originated Routes

Routes originated by the local router (via network command, redistribution, or aggregation) are preferred over routes learned from peers. This ensures a router prefers its own announcements.

AS_PATH Length

The AS_PATH is the list of ASes a route has traversed. Shorter paths are preferred, representing a "closer" destination in terms of AS hops.

Important AS_PATH Counting Rules:

1. AS_SEQUENCE: Each AS in the sequence counts as 1
2. AS_SET: The entire set counts as 1 (regardless of how many ASes)
3. AS_CONFED_SEQUENCE: Does NOT count toward length
4. AS_CONFED_SET: Does NOT count toward length

This means aggregated routes with AS_SET may appear shorter than their contributing routes.

AS_PATH Prepending:

Network operators can influence path selection across the Internet by artificially lengthening the AS_PATH:

! Prepend own AS 3 times when advertising to neighbor
route-map PREPEND-OUT permit 10
  set as-path prepend 65001 65001 65001

neighbor 10.0.0.2 route-map PREPEND-OUT out

After prepending, the AS_PATH might look like: 65001 65001 65001 65001 65002 65003

Remote ASes will see a longer path via this link, potentially preferring alternative paths.

Prepending Considerations:

Best Practice: Don't prepend more than 3-4 times. Excessive prepending looks suspicious and may be filtered.

ORIGIN Attribute

The ORIGIN attribute indicates how the route was originally introduced into BGP. Lower values are preferred:

In practice, ORIGIN rarely breaks ties since most routes are either IGP or INCOMPLETE, and other criteria usually decide first. However, it can matter for routes learned via different mechanisms:

! Route A: Learned from eBGP with ORIGIN IGP
! Route B: Redistributed locally with ORIGIN INCOMPLETE
! If all else is equal, Route A wins

Modifying ORIGIN:

route-map SET-ORIGIN permit 10
  set origin igp

This is rarely needed but can be useful to prefer network statements over redistribution.

The Multi-Exit Discriminator (MED) is one of BGP's most nuanced attributes. It allows an AS to communicate preferences to neighboring ASes about inbound traffic. Understanding MED behavior is crucial for traffic engineering.

MED Fundamentals:

How MED Works:

Consider AS 65001 connected to AS 65002 via two links:

           MED=100          MED=200
R1 (65001) ======== R3 (65002)
R2 (65001) ======== R4 (65002)

AS 65002 sets MED=100 on routes via R3 and MED=200 on routes via R4. AS 65001, when receiving routes for the same prefix via both links, will prefer the R3 path (lower MED=100).

The "Same Neighbor AS" Rule:

By default, MED is only compared between routes received from the same neighboring AS. This is because MED values from different ASes are not meaningfully comparable—each AS sets MED independently.

Route 1: AS_PATH 65002, MED 500
Route 2: AS_PATH 65003, MED 100

→ MED is NOT compared (different origin ASes)
→ AS_PATH length compared instead (both length 1, next criterion)

MED Handling Configurations:

1. bgp always-compare-med: Compare MED even across different ASes. Useful when you control MED setting for all sources. Requires consistent MED handling across the network.

2. bgp deterministic-med: Group routes by AS before comparing. Ensures consistent best path selection across routers. Highly recommended to avoid oscillation.

3. bgp bestpath med missing-as-worst: Treat routes with no MED as having the highest (worst) MED value. Alternative: treat as 0 (best).

4. bgp bestpath med confed: Compare MED for routes learned via confederation peers.

MED Oscillation Problem:

Without deterministic-med, the order in which routes are compared can affect the outcome:

Route A (AS 65002): MED 100
Route B (AS 65002): MED 200  
Route C (AS 65003): MED 150

Comparison order [A,B,C]: A beats B (MED), A vs C: skip MED → Result depends on next criteria
Comparison order [A,C,B]: A vs C: skip MED → winner vs B → Different result possible!

Deterministic MED groups routes by AS first: [(A,B), (C)] → A beats B → A vs C → Consistent result.

After administrative and path attributes, BGP considers the protocol type and internal path cost.

eBGP over iBGP Preference:

Routes learned via eBGP are preferred over routes learned via iBGP. The rationale:

1. eBGP routes are directly received from the external source
2. iBGP routes are relayed by another router in the AS
3. Preferring eBGP typically means shorter AS-internal paths

Scenario: Two paths to 192.0.2.0/24

Path 1 (eBGP): Learned directly from AS 65002 peer
Path 2 (iBGP): Learned from iBGP peer who learned from AS 65002

→ Path 1 wins (eBGP preferred)

This preference makes intuitive sense: if you can reach a destination directly via your eBGP peer, why relay through another router?

IGP Metric (Hot Potato Routing):

When multiple routes have the same external AS_PATH and attributes, BGP considers the IGP metric to the NEXT_HOP. Lower is preferred.

This implements hot potato routing: traffic is handed off at the closest exit point (lowest IGP cost), minimizing the distance traffic travels within your AS.

[AS 65001]                                 [AS 65002]

R1 -----(IGP cost 10)----> R3 ==eBGP== R5
   \                        ^
    \-----(IGP cost 50)--> R4 ==eBGP== R6

For prefix 192.0.2.0/24 in AS 65002:
- R3 path: NEXT_HOP reachable with IGP cost 10
- R4 path: NEXT_HOP reachable with IGP cost 50

R1 prefers R3 path (lower IGP metric)

Hot Potato vs Cold Potato Routing:

Modifying IGP Metric Influence:

You can indirectly influence this criterion by:

1. Adjusting IGP metrics to border routers
2. Using next-hop-self to change the NEXT_HOP (changes which IGP path matters)
3. Preferring different attributes first (LOCAL_PREF overrides IGP metric consideration)

IGP Metric Calculation Details:

The IGP metric is the cost to reach the NEXT_HOP address according to the IGP routing table. This could be:

• OSPF cost to the NEXT_HOP subnet
• IS-IS metric to the NEXT_HOP
• EIGRP composite metric
• Static route cost

If the NEXT_HOP is resolved via a recursive lookup (e.g., BGP route pointing to another BGP route), some implementations may not correctly calculate the metric.

When all policy-relevant criteria are equal, BGP must still select a single best path. The tie-breaking criteria ensure deterministic selection, though they carry little policy significance.

Oldest Route (Stability Preference):

Some implementations (if configured) prefer routes that have been stable longer. This "oldest route" or "prefer-external" preference reduces churn by not switching to a new path unless it's clearly better.

! Cisco IOS configuration
bgp bestpath compare-routerid
bgp bestpath as-path ignore   ! (if configured)

Router ID Comparison:

If routes are still tied, prefer the route from the peer with the lower Router ID (BGP Identifier). The Router ID is typically:

1. Explicitly configured
2. Highest loopback IP address
3. Highest interface IP address

This is purely a tie-breaker with no operational significance, but it ensures consistent selection.

Cluster List Length (Route Reflector):

For routes reflected through Route Reflectors, shorter CLUSTER_LIST indicates fewer RR hops. Prefer shorter CLUSTER_LIST.

Neighbor IP Address:

The final tie-breaker: prefer routes from the peer with the lower IP address. This should rarely be reached if Router IDs are unique.

Ensuring Deterministic Selection:

For consistent routing across the network, ensure:

1. Unique Router IDs: No two routers should have the same Router ID (this would cause inconsistent tie-breaking)

2. Consistent policy configuration: All routers should apply the same LOCAL_PREF for the same route sources

3. bgp deterministic-med: Enable to prevent MED comparison order issues

4. Understand multipath: If equal-cost multipath is enabled, understand which criteria must match

Common Tie-Breaking Surprises:

Scenario: Two routes appear identical, but different routers select different paths.

Possible causes:

• Different IGP metrics (each router has different distance to NEXT_HOPs)
• Missing deterministic-med causing order-dependent MED comparison
• Different LOCAL_PREF due to missing/inconsistent policy
• One router has fresher information (timing issue)

Traditional BGP selects exactly one best path per prefix. However, modern networks often benefit from using multiple paths simultaneously. Two mechanisms enable this.

BGP Multipath:

BGP Multipath allows multiple paths to the same prefix to be installed in the forwarding table, enabling load balancing.

! Enable multipath for eBGP routes
router bgp 65001
  maximum-paths 4

! Enable multipath for iBGP routes
router bgp 65001
  maximum-paths ibgp 4

! Enable mixed eBGP/iBGP multipath
router bgp 65001
  maximum-paths eibgp 4

Multipath Requirements:

For paths to be considered equal for multipath, they must match all best path criteria up to the point of tie-breaking:

With bgp bestpath as-path multipath-relax, paths with different AS_PATHs (but same length) can be multipath.

ADD-PATH Capability (RFC 7911):

ADD-PATH addresses a different limitation: by default, a BGP speaker only advertises its best path to each peer. ADD-PATH enables advertising multiple paths.

Why ADD-PATH Matters:

Consider a Route Reflector scenario:

[Without ADD-PATH]
RR receives 2 paths to 192.0.2.0/24 from clients C1 and C2
RR selects C1's path as best
RR advertises only C1's path to all clients
C2 doesn't learn its own path (received from RR), but C3 only knows C1's path
If C1 fails, C3 must wait for RR to select C2's path

[With ADD-PATH]
RR advertises BOTH paths (from C1 and C2) to all clients
C3 knows about both paths immediately
If C1 fails, C3 switches to C2's path instantly (already in table)

ADD-PATH Configuration:

! Enable sending additional paths to neighbor
neighbor 10.0.0.2 advertise additional-paths all

! Enable receiving additional paths from neighbor
neighbor 10.0.0.2 additional-paths receive

ADD-PATH Benefits:

1. Faster Convergence: Backup paths pre-computed
2. Better Visibility: Route collectors see more paths
3. Improved Multipath: More paths available for selection
4. RR Limitations Mitigated: Clients see all paths, not just RR's best

The BGP best path selection algorithm is the core decision engine that determines how traffic flows across the Internet. Understanding this algorithm enables effective traffic engineering and troubleshooting.

What's Next:

With best path selection mastered, the next page explores policy routing—how network operators use communities, route maps, and other mechanisms to implement complex routing policies that reflect business relationships and traffic engineering requirements.