When a BGP router has multiple paths to the same destination prefix, it runs a deterministic 11-step algorithm to pick the best one. Most tutorials list the steps. This one walks through them — Socratic — so you understand why each step exists and when each one decides the winner in a real network.
At each step I'll ask you what you'd expect. Then I'll tell you what BGP actually does, show you how to verify on a real router, and move to the next step.
The one-line framing: BGP's path selection algorithm is a tiebreaker cascade. Most paths never reach step 10 — one of the earlier steps decides. Understanding which step decides in which scenario is the skill. The 11-step mnemonic is the scaffolding; the reasoning is the content.
The 11 Steps (So You Have the Shape)
Before we walk through, here's the full list in order:
- Weight (Cisco-proprietary, local to the router, higher wins)
- Local Preference (within an AS, higher wins)
- Originated locally via
networkoraggregate-address(wins over learned paths) - AS-Path length (shorter wins)
- Origin type (IGP < EGP < Incomplete; lower wins)
- MED (Multi-Exit Discriminator; lower wins, across paths from same neighbor AS)
- eBGP over iBGP (external paths win over internal)
- IGP cost to the BGP next-hop (lower wins)
- Oldest path (oldest eBGP path wins; stability)
- Router-ID of neighbor (lowest wins; deterministic tiebreaker)
- Neighbor IP address (lowest wins; absolute final tiebreaker)
Your memory aid: We Love Oranges And Oranges Mean Everything Is Often Really Nice. (W, L, O, A, O, M, E, I, O, R, N.) Sticky enough that you'll remember it under exam pressure.
Now let's walk each step.
Step 1 — Weight
Ask yourself: Why would Cisco invent a proprietary attribute on top of the standard BGP attributes?
Because sometimes you want to influence BGP on a single router without advertising that preference to anyone else. Weight is local to one router — it doesn't travel in BGP updates. Higher weight wins. Default weight on a path you originated is 32768; on paths learned from a neighbor, it's 0.
When does weight decide? When you want to force one router to prefer a specific exit without impacting any other router in your AS. Classic use: a remote office with two ISPs, where only the local router should prefer ISP A.
Verify on real IOS: show ip bgp — the weight column. You'll see 32768 on self-originated prefixes.
Step 2 — Local Preference
Ask yourself: Now we need BGP to influence behavior across an AS (not just one router). How does that work?
Local preference is the answer. It's carried in iBGP updates within an AS. Every iBGP router sees the same local-pref for a given path. Higher wins. Default is 100.
When does local-pref decide? When you want consistent AS-wide exit selection. If ISP A is generally better than ISP B, you set local-pref 200 on paths from ISP A at the eBGP edge; every iBGP router inside your AS sees local-pref 200 and prefers A.
Mental model: Weight is selfish ("this router prefers this"). Local-pref is cooperative ("our AS prefers this").
Verify: show ip bgp — LocPrf column. Or show ip bgp <prefix> for detail.
Step 3 — Originated Locally
Ask yourself: What if multiple paths tie on weight and local-pref, and one of them is a prefix you're originating yourself (via network or aggregate-address)?
BGP prefers the locally-originated path. Rationale: your own prefix, announced by your own router, is usually the most trustworthy view.
When does this decide? Rare in transit scenarios. More common when you're aggregating a summary prefix and also hearing a more specific from an external peer — your aggregate wins on this step.
Step 4 — AS-Path Length
Ask yourself: Now we're comparing paths that are equal in weight, local-pref, and origin. They came from different neighbors via different routes. What's the fairest comparison?
AS-Path length. Shorter is better. A path that traverses 3 autonomous systems (AS-path 65001 65002 65003) is shorter than one that traverses 5 (65001 65002 65003 65004 65005).
When does AS-path decide? All the time on the public internet. If your router has two paths to 8.8.8.8 — one via AS 1299 → 15169 (length 2), another via AS 3257 → 3356 → 15169 (length 3) — BGP picks length 2.
Gotcha: AS-path prepending is the most common way engineers influence BGP across AS boundaries (where local-pref and weight don't travel). You prepend your own AS 3 times to make your AS-path artificially longer, encouraging others to prefer a different path to your network.
Verify: show ip bgp <prefix> — look at the Path column.
Step 5 — Origin Type
Ask yourself: Why does BGP care how a route was originated?
Origin type records the route's lineage: was it learned from an IGP (network statement — most trustworthy), from an external gateway protocol (legacy EGP — obsolete), or is it incomplete (typically meaning "redistributed from another protocol" — least trustworthy)?
Lower wins: i (IGP) < e (EGP) < ? (incomplete).
When does origin decide? Rarely. Most paths have origin "incomplete" (from redistribution) or "IGP" (from a network statement). It's usually settled by earlier steps, but when two paths tie on everything before, origin breaks it.
Step 6 — MED (Multi-Exit Discriminator)
Ask yourself: Your AS has two eBGP peerings with the same neighbor AS — one at the east coast, one at the west coast. How does the neighbor AS tell you which of its two entry points is better for each prefix?
MED. The neighbor AS sends different MEDs on each peering — lower MED wins, advertising which entry point is better per-prefix. It's a suggestion, not a mandate; you can override with local-pref on your side.
When does MED decide? When you have multiple eBGP sessions with the same neighbor AS (not just any two ASes). That's an important constraint — by default, BGP only compares MEDs between paths from the same neighbor AS. Some implementations can be configured to compare always, but that's a departure from RFC.
Verify: show ip bgp <prefix> — the Metric column is MED.
Step 7 — eBGP over iBGP
Ask yourself: You have two iBGP neighbors inside your AS. One has learned a path via eBGP from outside the AS. The other received that path from the first via iBGP. Which do you prefer?
The eBGP path. Rationale: the router with direct external reachability has the freshest view. The iBGP "copy" is one hop further from external reality.
Verify: show ip bgp <prefix> — look at "best" path markers. External-learned paths will typically have a non-zero "Path" AS.
Step 8 — IGP Cost to the BGP Next-Hop
Ask yourself: Two iBGP paths, both learned from different external sources. You need to reach the BGP next-hop — which means running SPF over your IGP to figure out the cost. Prefer the lower-IGP-cost next-hop?
Yes. This step asks: "of the remaining paths, which next-hop is closest in terms of our internal routing protocol cost?" The answer wins.
When does this decide? Commonly in large enterprise networks with multiple exits. If two eBGP exits have identical attributes so far, the one whose next-hop is closer (in OSPF/EIGRP/IS-IS cost) wins.
Step 9 — Oldest Path
Ask yourself: We've exhausted merit-based steps. Now we need a stability tiebreaker — so that BGP doesn't flap between equally good paths.
The oldest eBGP path wins. If you already elected a best path and a new, tied path arrives — the old one stays. Rationale: reduce BGP churn.
Step 10 — Router-ID of Neighbor
Ask yourself: We need a completely deterministic final answer. Two paths still tie. Pick something.
The path received from the neighbor with the lowest BGP router-ID wins.
Mental model: This isn't about merit anymore — it's just a coin flip using deterministic rules so every router in the AS agrees on the same answer.
Step 11 — Neighbor IP Address
Ask yourself: What if even the router-IDs tie (say, two peering sessions with the same neighbor)?
Lowest neighbor IP wins. Final tiebreaker. You will basically never see this decide unless you're running multiple parallel sessions with the same peer.
Which Step Usually Decides?
In most networks, steps 1-4 decide. Here's the distribution, roughly:
- Weight + Local-Pref — ~60% of decisions (engineer-imposed policy)
- AS-Path length — ~30% (internet-scale paths naturally vary in length)
- MED — ~5% (specific multi-homed scenarios)
- Everything else (steps 5-11) — ~5%
If you understand steps 1-4 deeply, you understand 90% of real-world BGP decisions. The other 7 steps are the tiebreakers that keep the algorithm deterministic.
Lab Check: See All 11 Steps in Action
Cisco Packet Tracer's BGP support is limited — it simulates basic iBGP/eBGP and AS-path but omits confederations, extended communities, full route-maps, and some MED comparison behaviors. For serious BGP practice, you need real IOS.
Option 1 — Cisco CML Free (5 nodes max). Option 2 — GNS3 (4-8 hours setup). Option 3 — NetPilot: describe a 3-AS eBGP topology in plain English, get a working lab on real Cisco IOL in ~2 min, SSH in and watch each path-selection step unfold with show ip bgp <prefix> output.
The 11 steps make sense on paper. They make intuitive sense only after you've seen a path lose at step 4 because AS-Path was longer by one, then won after you prepended your own AS.
FAQ
What is the order of BGP path selection attributes?
The order is: (1) Weight (higher wins, Cisco-local), (2) Local Preference (higher wins, AS-wide), (3) Originated locally, (4) AS-Path length (shorter wins), (5) Origin (IGP < EGP < Incomplete), (6) MED (lower wins, same-neighbor-AS only by default), (7) eBGP over iBGP, (8) IGP cost to next-hop (lower wins), (9) Oldest eBGP path (stability), (10) Lowest neighbor router-ID, (11) Lowest neighbor IP. Weight and Local Preference decide most real-world BGP choices; the rest are tiebreakers.
Why does weight come before local preference in BGP?
Weight is Cisco-proprietary and router-local — it doesn't propagate in BGP updates. Local preference is standard BGP and propagates in iBGP updates throughout the AS. Cisco placed weight first so that a single router can override AS-wide policy when needed. If local-pref came first, you'd have no per-router override mechanism.
What's the difference between BGP weight and local preference?
Weight is local to one Cisco router — it never leaves that router and doesn't appear in BGP updates. Local preference is carried in iBGP updates and applies AS-wide. Rule of thumb: use weight when only one router needs the preference; use local-pref when the entire AS should agree. Both are higher-is-better.
Explain BGP MED vs local preference with an example.
Local preference is internal — you set it at your own router to influence your AS's exit choice. MED is external — your neighbor AS sets it to influence which of their entry points you prefer. Example: you have two eBGP peerings with AS 65100. For prefix 10.0.0.0/24, AS 65100 sends MED 50 on peering A and MED 200 on peering B. Lower MED wins, so you prefer peering A for that prefix. Separately, you might set local-pref 200 on paths from AS 65100 (vs local-pref 100 on a different ISP) — that's your AS saying "we generally prefer AS 65100 as our provider."
Does Cisco Packet Tracer accurately simulate BGP path selection?
Basic steps (weight, local-pref, AS-path, eBGP-over-iBGP) simulate correctly. MED behavior, route-reflector attributes, communities beyond standard, BGP confederations, and some edge cases in step ordering diverge from real Cisco IOS. For CCNA-level BGP awareness PT is sufficient; for CCNP/CCIE BGP practice, use real Cisco IOL via CML, GNS3, or NetPilot.
Related reading
- OSPF Area Types Explained for CCNA — the interior routing prerequisite
- Why Did My OSPF Lab Work in Packet Tracer but Fail on Real Routers? — simulator vs real IOS
- Cisco Packet Tracer vs Real IOS Cheat Sheet — BGP divergences section
- CCNA Practice Lab — NetPilot's CCNA-focused product page
Copy-paste ready: Build a 3-AS eBGP topology on real Cisco IOL with the eBGP Three-AS prompt.
Want to see all 11 path-selection steps decide on real hardware? Open NetPilot — describe the topology, SSH into the routers, watch each step narrow the winner.