One prefix, several candidates, one winner
In the course network R1 learns 203.0.113.0/24 from ISP A and, over iBGP, from R2. Both are valid paths. The routing table can hold only one BGP route for that prefix, so the BGP process runs the best-path algorithm and marks the winner with > in the table. Everything else stays in the BGP table as a backup, ready to take over the moment the winner disappears.
Before any comparison, a path must be valid: its next hop must be reachable and no inbound policy may have rejected it. An invalid path is never a candidate, whatever its attributes say. This is the single most common reason a path you configured to win does not.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
The algorithm stops at the first step where the paths differ, so a step that matters never gets undone by a later one. That is why a high local preference beats a short AS path, and why tuning a later attribute can have no effect at all.
Watching candidates drop out
The easiest way to understand the order is to follow a field of paths down the list. Five paths exist for one prefix. Each is compared with the best one so far, and the router stops comparing a pair as soon as they differ.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
| Path | Weight | Local pref | AS_PATH length | Origin | Result |
|---|---|---|---|---|---|
| A | 0 | 100 | 1 | i | Out at step 2: local preference |
| B | 0 | 100 | 2 | i | Out at step 2: local preference |
| C | 0 | 200 | 3 | i | Out at step 4: AS_PATH length |
| D | 0 | 200 | 2 | i | Wins at step 5: origin |
| E | 0 | 200 | 2 | ? | Out at step 5: origin |
Path A has the shortest AS path of all five and still loses first. That is the lesson: the order is a ranking of whose opinion matters most, with your own policy (weight, local preference) ahead of anything the rest of the internet says about the route.
The steps, with what each one means and how you use it
On small screens, swipe sideways or focus the diagram and use the arrow keys.
| # | Step | Winner | Why it exists | How you change it |
|---|---|---|---|---|
| 1 | Weight | Highest | Per-router override, Cisco only | neighbor weight or set weight |
| 2 | Local preference | Highest | The AS-wide choice of exit | set local-preference in an inbound route map |
| 3 | Locally originated | Local route | A router trusts what it injected | network, aggregate-address, redistribute |
| 4 | AS_PATH length | Shortest | Fewer ASes is a rough measure of closer | as-path prepend (adds length) |
| 5 | ORIGIN | i, then e, then ? | Trust how the route entered BGP | set origin |
| 6 | MED | Lowest | A neighbour's preferred entry point | set metric |
| 7 | eBGP over iBGP | External | Leave the AS sooner rather than later | Which sessions exist |
| 8 | IGP metric to next hop | Lowest | Use the closest exit | IGP cost, next-hop-self |
| 9 | Tie-breakers | Oldest, lowest router ID, lowest address | Make the choice stable | Rarely tuned |
Steps 1 to 3: your own policy
Weight is for one router and never leaves it. Local preference is carried to every iBGP peer, so every router in the AS agrees on the exit. Locally originated means a path this router put into BGP itself beats anything it learned, which stops a router from preferring a longer trip through someone else to a prefix it owns. These three are the steps you control directly, which is why they come first.
Steps 4 to 6: how good the path looks
AS_PATH length is the default proxy for distance. Origin and MED rarely decide anything on their own. MED is compared only between paths from the same neighbouring AS unless you configure bgp always-compare-med.
Steps 7 and 8: leave the AS the nearest way
If the paths are still equal, an external path wins over an internal one, and then the exit with the lowest IGP cost to its next hop wins. Together these give hot-potato routing: hand the packet to the neighbour as soon as you can.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Step 9: making the answer stable
If everything is still equal, the router prefers the oldest eBGP path, so a path that has been working is not displaced by a new one that appears later. After that come the lowest router ID of the advertising neighbour, the shortest cluster list, and the lowest neighbour address. None of these reflect quality, and a design that depends on them has an unplanned outcome.
A second worked example: MED and the neighbouring AS
MED is the step people get wrong, because whether it is compared depends on where the paths came from.
| Path | Neighbouring AS | Local pref | AS_PATH length | MED |
|---|---|---|---|---|
| P | 64501 | 100 | 2 | 200 |
| Q | 64501 | 100 | 2 | 50 |
| R | 64502 | 100 | 2 | 10 |
P and Q come from the same neighbouring AS, so their MEDs are compared and Q beats P. R has the lowest MED of all, but it comes from a different AS, so by default its MED is not compared with Q's. Q and R then go on to the later steps. With bgp always-compare-med, R would win here. Mixed comparisons can also make the result depend on the order paths arrived, which is what bgp deterministic-med fixes.
router bgp 64500
bgp always-compare-med
bgp deterministic-medGlobal BGP configuration. Compares MED across different neighbouring ASes, and orders paths from the same AS together before comparing, so the choice no longer depends on arrival order. Use only when you control or trust the MED values from every neighbour.
Reading the result on the router
R1#show ip bgp 203.0.113.0 BGP routing table entry for 203.0.113.0/24, version 9 Paths: (3 available, best #3, table default) 64501 64510 192.0.2.1 from 192.0.2.1 (11.11.11.11) Origin IGP, metric 0, localpref 100, valid, external 64502 10.255.0.2 from 10.255.0.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal 64502 64511 64512 10.255.0.3 from 10.255.0.3 (3.3.3.3) Origin IGP, metric 0, localpref 200, valid, internal, best
On small screens, swipe sideways or focus the diagram and use the arrow keys.
Why did my path lose?
When the wrong path wins, do not change attributes at random. Find the step where your path lost, then change that attribute.
On small screens, swipe sideways or focus the diagram and use the arrow keys.
show ip bgp 203.0.113.0
show ip route 10.255.0.2
show ip bgp neighbors 192.0.2.1 routes
show ip bgp neighbors 192.0.2.1 received-routesThe first lists every path with its attributes. The second checks the next hop is reachable. The third shows what passed inbound policy, and the last, with soft-reconfiguration inbound, what the neighbour actually sent.
Once you know the step, the fix is the tool from the table above. When a path lost on local preference, prepending or MED will not help. When it lost on AS_PATH length, a bigger weight will help only on that one router.
Technical reference: Cisco, BGP best path selection algorithm, and RFC 4271, section 9.1.2. Example output is illustrative.
Predict the winner
Path X has local preference 150 and AS_PATH length 4. Path Y has local preference 100 and AS_PATH length 1. Weights tie. Which wins?
Two paths tie on weight, local preference, AS_PATH length, origin and MED. One is from an eBGP peer and one from an iBGP peer. Which wins?
You raise the weight on a path that is not the best. The best path does not change. What is the most likely reason?
Two paths are from different neighbouring ASes and tie up to MED. One has MED 10, the other MED 500. No extra commands are configured. What happens at the MED step?
R1 and R2 both hold two equal paths, one via ISP A and one via ISP B, tied through the eBGP step. R1 is much closer to ISP A in the IGP, R2 closer to ISP B. What happens?