How BGP Best-Path Selection Works

When a BGP router receives multiple routes to the same destination prefix from different neighbors, it must pick exactly one to install in the forwarding table and, in most deployments, advertise onward. The decision is deterministic and follows a strict ordered sequence of criteria — commonly called the BGP best-path selection algorithm. Understanding this process is fundamental to diagnosing traffic asymmetry, planning traffic engineering, and debugging unexpected routing behavior.

The Decision Process at a Glance

The algorithm runs the competing routes through a series of comparisons in fixed order. The first criterion that produces a winner ends the comparison — lower-numbered criteria carry more weight than higher-numbered ones. The canonical sequence used by Cisco IOS (and mirrored closely by most vendors) is:

RFC 4271 mandates only some of these steps; weight is a Cisco extension, and vendor implementations differ slightly in the lower tiebreakers. Junos, for instance, calls local-pref step one and skips weight entirely by default.

Weight (Cisco-Only, Step 1)

Weight is a 16-bit unsigned integer assigned locally on the router — it is never carried in BGP UPDATE messages and has no meaning beyond the single router where it is configured. Cisco's default weight for learned routes is 0; locally originated routes get weight 32768. A higher weight wins.

Operators use weight to prefer a specific upstream on a dual-homed router without touching any attribute that propagates. A common pattern: set weight 200 on all routes from Transit-A and leave Transit-B at 0 — all outbound traffic leaves via Transit-A until it fails.

Local Preference (Step 2)

Local preference (LOCAL_PREF) is the most operationally significant attribute for outbound traffic engineering inside an AS. It is a well-known discretionary attribute carried in iBGP UPDATEs but stripped at eBGP boundaries. Default is 100; higher values win. Because it propagates to all iBGP speakers, a single route-map change at one edge router affects the entire AS's exit decision for a prefix.

Classic usage patterns:

• Transit vs peer vs customer — Set local-pref 50 on routes learned from transit (paid), 100 on routes from peers (settlement-free), 150 on routes from customers (revenue-generating). This ensures traffic to customer-originated prefixes exits through customer-facing links, not through expensive transit.
• Primary/backup links — Set local-pref 200 on the primary upstream and 50 on the backup. Traffic floods the primary link and only falls back when that link goes down.

Local preference interacts with BGP communities: large ISPs expose community values that let customers remotely request a specific local-pref in the ISP's network. For example, sending community 64512:150 to a transit provider might instruct it to set local-pref 150 for your prefixes, biasing their traffic toward you.

Locally Originated Routes (Step 3)

Routes injected into BGP via network statements, redistribute, or aggregate-address are preferred over routes learned from peers when weight and local-pref are equal. This is rarely a tiebreaker in practice but matters in route-reflector topologies where a route-reflector might originate a summary and also reflect a more-specific learned route.

AS Path Length (Step 4)

Shorter AS paths are preferred. This is the primary lever for inbound traffic engineering. If AS 64500 wants to bias inbound traffic to arrive via its New York link rather than its London link, it announces its prefixes to London with the path prepended:

64500 64500 64500

Peers seeing the London announcement (3 hops) will prefer the New York announcement (1 hop). See AS path prepending for full details. Note that AS_SET elements count as one regardless of how many ASes they contain, and confederation sequences are counted differently by some implementations.

Origin Code (Step 5)

The ORIGIN attribute has three values: IGP (i) — the route was injected from an IGP via a network statement; EGP (e) — legacy, from the predecessor protocol; Incomplete (?) — redistributed from a non-BGP source. IGP beats EGP beats Incomplete. In modern networks almost everything is IGP or Incomplete, and this step rarely acts as a tiebreaker unless you're mixing redistribution sources.

MED — Multi-Exit Discriminator (Step 6)

MED (MULTI_EXIT_DISC) is an optional non-transitive attribute that one AS can use to hint to an adjacent AS which of its entry points to prefer. Lower MED wins. Unlike local-pref, MED is sent to the neighbor and influences their inbound selection — it is an inbound traffic engineering tool from the sender's perspective.

MED is only compared between routes from the same neighboring AS by default. A router will not compare a MED of 100 from AS 1234 against a MED of 50 from AS 5678 unless bgp always-compare-med is configured (with care — this can cause instability). The classic use case is a dual-homed enterprise telling its upstream "prefer to send traffic to my New York router (MED 10) over my Chicago router (MED 100)".

This is sometimes called cold-potato routing: by setting MED, the origin network asks the upstream to hand off traffic as close to the destination as possible, keeping it on the origin's network longer rather than the upstream's.

eBGP Over iBGP (Step 7)

Routes learned from an external BGP peer are preferred over routes learned via internal BGP. This prevents a router from forwarding traffic to an iBGP peer when it has a direct eBGP path to the destination. In practice, this step is often reached in route-reflector topologies where multiple reflectors might propagate the same external route inward.

IGP Metric to Next-Hop (Step 8)

If two routes still tie through step 7, the router compares the IGP (OSPF, IS-IS, EIGRP) cost to reach each route's next-hop address. Lower is better. This is how a network naturally selects the nearest exit point — a form of hot-potato routing. Traffic is handed off to the next AS as early as possible, minimizing the originating AS's transit cost.

Route Age, Router ID, and Final Tiebreakers (Steps 9–12)

Step 9 prefers the oldest eBGP route — this is a stability mechanism to avoid unnecessary churn when two external routes are otherwise equal. Steps 10–12 (router ID, cluster list, neighbor IP) are deterministic tiebreakers that guarantee a single winner without oscillation. The router ID is typically the highest loopback IP or configured explicitly; operators sometimes set router IDs deliberately to influence which route wins on shared-medium peering links.

Worked Example

AS 64500 has two upstreams: Transit-A (AS 3356) and Transit-B (AS 174). Both advertise a route to 203.0.113.0/24. Applying the algorithm:

If an operator now wants to shift traffic to Transit-B despite the longer path, the cleanest tool is local-pref: set local-pref 150 on routes from Transit-B and leave Transit-A at 100. The algorithm stops at step 2, and Transit-B wins.

ECMP and Multipath

Most production routers support BGP multipath, allowing multiple equal-cost paths to be installed simultaneously when routes tie through all steps up to (and including) the IGP metric. This enables load balancing across multiple upstreams or iBGP paths without selecting a single best. The conditions for multipath eligibility vary by vendor — Cisco requires equal AS path length and the same neighboring AS for eBGP multipath; Junos is configurable.

Advertising the Best Path

By default a BGP router advertises only its best path to eBGP peers. To iBGP peers it also advertises only the best path, which is why route reflectors and confederations exist — to avoid the O(n²) full-mesh requirement. Add-path (RFC 7911) allows advertising multiple paths to iBGP peers, improving redundancy and enabling faster failover.

Vendor Differences

While the algorithm's spirit is consistent, vendors differ in details:

Junos notably does not implement weight by default. Nokia SR OS calls local-pref step 1, matching the RFC 4271 recommendation more closely. These differences rarely matter in homogeneous environments but can produce unexpected behavior in multi-vendor networks where both sides are running best-path selection simultaneously.

Best-Path and Route Leaks

The best-path algorithm has no inherent sense of routing policy correctness. A route leak occurs when a network advertises routes it should not — for example, a customer re-advertising routes learned from one transit provider to another transit provider, turning itself into an unintended transit. From the best-path algorithm's perspective, the leaked route may appear shorter or have a higher local-pref than the legitimate path, so remote networks may prefer it. This is why prefix filtering and RPKI are necessary complements to the best-path algorithm.

Determinism and Oscillation

The tiebreakers at the bottom of the algorithm (router ID, neighbor address) exist specifically to prevent route oscillation — a situation where two routers in an AS alternate their best-path selection between two equivalent routes, causing continuous BGP UPDATE churn. The lowest-router-ID and lowest-neighbor-address tiebreakers are stable properties that do not change as long as the session is up, guaranteeing convergence.

A subtler oscillation risk appears with MED. If always-compare-med is enabled and routes from different ASes have MEDs, the comparison can be non-transitive: A > B, B > C, C > A. This causes persistent oscillation in some topologies. RFC 5004 documents the problem and recommends solutions including deterministic-med and route-reflection path selection consistency requirements.

Practical Debugging

When a router selects an unexpected best path, the standard debugging approach is to run show bgp ip X.X.X.X/Y (Cisco) or show route X.X.X.X/Y detail (Junos). The output lists all received paths and annotates the winner with a > marker, showing which step in the algorithm chose it. Look for the first criterion where the values differ between paths — that is the decisive step. Common surprises:

• A route that should win on AS path length is losing because local-pref was accidentally set differently on two edge routers.
• A backup link is being used as primary because MED from the backup upstream happens to be lower than the primary's MED, and always-compare-med is on.
• Two routes look identical in the table but the router ID tiebreaker is driving traffic to the physically farther router.

Explore It Live

Use this tool to watch best-path selection in action. Look at a well-connected prefix and compare the AS paths chosen by different route collectors:

• 8.8.8.8 — observe how different vantage points see different AS paths to Google
• 1.1.1.1 — Cloudflare's extensive peering yields unusually short paths
• AS6939 — Hurricane Electric, a major transit AS, appears in many best paths

The BGP looking glass shows live route data ingested from RIPE RIS, letting you trace which attributes drove each best-path decision.