Blog

BGP for CCNP ENCOR, Part 4: The Best Path Selection Algorithm

When BGP knows several paths to the same prefix, it picks exactly one. Not the fastest, not a load-shared set — one. That decision runs through a fixed, ordered list of comparisons, and the algorithm stops at the first step that produces a difference. Everything below that step is never evaluated.

This is the part of BGP the CCNP ENCOR 350-401 v1.2 blueprint names explicitly, and it is the most reliably examined BGP topic there is. It is also the one most often half-learned: people memorize the list but never practise walking it, so they cannot say which step decided a given outcome. That distinction is what this post drills.

Parts 1, 2, and 3 covered fundamentals, neighbor relationships, and the path attributes this algorithm consumes.

Two Gates Before the Algorithm Runs

A path must clear two checks before it is even a candidate. Both are common exam traps precisely because they happen before step 1.

  • The NEXT_HOP must be reachable. If the routing table has no route to the next hop, the path is marked valid but can never be best. This is the (inaccessible) case from part 3, and it is the leading cause of “BGP has the route but it is not in the RIB.”
  • The AS_PATH must not contain the local AS. Checked on receipt, before any policy. A route failing this is discarded outright, not merely deprioritized.

A path that clears both is valid and shows a * in the table. Only valid paths enter the comparison.

The Algorithm

Before step 1 — a path must be VALIDNEXT_HOP reachable · local AS not already in AS_PATH1WEIGHThighestthis router only2LOCAL_PREFhighestwhole local AS3Locally originatedprefer selfnetwork / aggregate4AS_PATH lengthshortestglobal5ORIGINi < e < ?global6MEDLOWESTsame neighbour AS only7eBGP over iBGPexternal winslocal decision8IGP metric to NEXT_HOPlowesthot potato9Multipath checkif configuredforwarding only10Oldest eBGP pathlongest upstability11Lowest router-IDlowestdeterministic12Shortest cluster listshortestroute reflectors13Lowest neighbor addresslowestfinal tie-breakBEST PATHfirst difference wins — stop hereThe algorithm stops at the first step that differentiates. Everything below it is never evaluated.
Figure 1 — The BGP best path decision ladder. A tie falls through to the next step; the first difference selects the path and ends the comparison.
# Compare Winner Scope of influence
1 WEIGHT Highest This router only (Cisco-proprietary)
2 LOCAL_PREF Highest Whole local AS
3 Locally originated Prefer self-originated network / aggregate / redistribute beats learned
4 AS_PATH length Shortest Global
5 ORIGIN IGP (i) < EGP (e) < Incomplete (?) Global
6 MED Lowest Same neighbouring AS only, by default
7 eBGP over iBGP External wins Local decision
8 IGP metric to NEXT_HOP Lowest “Hot potato” — nearest exit
9 Multipath check Install multiple paths if configured Only with maximum-paths
10 Oldest eBGP path Longest established Stability tie-breaker
11 Lowest router-ID Lowest Deterministic tie-break
12 Shortest cluster list Shortest Route-reflector environments
13 Lowest neighbor address Lowest Final tie-break

Remembering the Order

The widely used mnemonic covers the first eight steps, which decide virtually every real comparison:

We     — Weight               (highest)
Love   — Local preference     (highest)
Oranges— Originated locally   (prefer self)
AS     — AS_PATH              (shortest)
Oranges— Origin               (i < e < ?)
Mean   — MED                  (lowest)
Pure   — Paths, eBGP over iBGP
Refreshment — RIB / IGP metric to next hop (lowest)

Two sanity checks that catch most mistakes: the first three steps are all “highest wins” except step 3 which is a preference rather than a number, and MED is the odd one out at lowest-wins. If you find yourself thinking “higher MED is better,” you have it backwards.

The Steps Worth Understanding, Not Just Memorizing

Step 3 — locally originated. A path this router put into BGP itself, via network, aggregate-address, or redistribute, beats one learned from a peer. Locally originated paths carry weight 32768, so in practice step 1 usually decides this first; step 3 matters when weight has been manipulated.

Step 6 — MED’s comparison rule. By default MED is only compared between paths whose first AS in the path is the same. Two paths from different providers never reach a MED comparison at all, and the algorithm falls through to step 7. Two commands change this:

bgp always-compare-med          ! compare MED across all ASes — use with care
bgp deterministic-med           ! group paths by AS before comparing (recommended)

Without deterministic-med, the outcome can depend on the order in which paths were received, which is why the same topology can select different best paths on two routers. Cisco recommends enabling it consistently across the AS.

Step 8 — hot potato routing. When everything above ties, the router picks the exit with the lowest IGP metric to the next hop — that is, it hands the traffic off to the neighbouring AS as quickly as possible. This is deliberate: carrying someone else’s traffic across your own backbone costs you money. “Cold potato” routing, holding traffic longer to hand it off closer to the destination, requires overriding this with LOCAL_PREF.

Step 9 — multipath. BGP installs one path by default. maximum-paths permits several, but only for paths that are equal in every attribute from step 1 through step 8:

router bgp 65001
 address-family ipv4 unicast
  maximum-paths 4              ! eBGP
  maximum-paths ibgp 4         ! iBGP

Even with multipath, exactly one path remains the best path, and only that one is advertised onward. Multipath affects forwarding, not advertisement.

Steps 10 and 11 — an ordering subtlety. Step 10 prefers the oldest eBGP path on the grounds that a long-established session is more stable. Because “oldest” is non-deterministic across reboots, many networks disable it so the deterministic router-ID comparison decides instead:

bgp bestpath compare-routerid

Reading the Decision from the Router

show bgp ipv4 unicast prefix is the command that answers “why this path?” Everything needed to reconstruct the decision is in its output.

R1# show bgp ipv4 unicast 203.0.113.0/24
BGP routing table entry for 203.0.113.0/24, version 12
Paths: (3 available, best #2, table default)

  Refresh Epoch 1
  65002 65010
    192.0.2.2 from 192.0.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, external
      rx pathid: 0, tx pathid: 0

  Refresh Epoch 1
  65003 65010
    198.51.100.2 from 198.51.100.2 (3.3.3.3)
      Origin IGP, metric 0, localpref 200, valid, external, best
      rx pathid: 0, tx pathid: 0x0

  Refresh Epoch 1
  65004 65020 65010
    10.0.0.5 from 10.0.0.5 (4.4.4.4)
      Origin incomplete, metric 0, localpref 100, valid, internal

Working the algorithm by hand on that output:

Step 1  Weight       all 0                         → tie
Step 2  Local pref   100 / 200 / 100               → path 2 wins (200)

Decision made at step 2. AS_PATH, origin, and MED are never examined.

The header line Paths: (3 available, best #2) states the verdict directly, and the word best appears on the winning path. Reconstructing why is a matter of walking the list until the first difference.

Useful Supporting Commands

show bgp ipv4 unicast                       ! *> marks the best path
show bgp ipv4 unicast 203.0.113.0/24        ! all paths and their attributes
show bgp ipv4 unicast 203.0.113.0/24 bestpath
show ip route 203.0.113.0                   ! confirm it reached the RIB
show bgp ipv4 unicast neighbors 192.0.2.2 advertised-routes
show bgp ipv4 unicast summary

Worked Examples

Each example gives the candidate paths and asks which wins and at which step. Work them before reading the answer — that is the skill the exam tests.

Example 1 — Decided at Step 4

Path A:  weight 0,  localpref 100,  AS_PATH 65002 65010,        origin i,  MED 0
Path B:  weight 0,  localpref 100,  AS_PATH 65003 65020 65010,  origin i,  MED 0
Step 1  weight     0 = 0        tie
Step 2  localpref  100 = 100    tie
Step 3  neither locally originated
Step 4  AS_PATH    2 vs 3       → PATH A WINS

Note what is irrelevant here: if path B ran over 10 Gbps links and path A over a 10 Mbps link, path A still wins. BGP has no concept of bandwidth.

Example 2 — The MED Trap

Path A:  from AS 65002,  localpref 100,  AS_PATH 65002 65010,  MED 50
Path B:  from AS 65003,  localpref 100,  AS_PATH 65003 65010,  MED 10

The tempting answer is path B, because 10 is lower than 50. It is wrong.

Steps 1–3  tie
Step 4     AS_PATH lengths both 2                  tie
Step 5     both origin i                           tie
Step 6     MED — first AS differs (65002 vs 65003)
           → NOT COMPARED. Skip to step 7.
Step 7     both external                           tie
Step 8     IGP metric to next hop                  → decides

MED never enters into it, because the paths come from different neighbouring ASes. Adding bgp always-compare-med would make path B win — which is exactly why that command changes behaviour in ways people do not expect.

Example 3 — Decided at Step 7

Path A:  learned via eBGP,  localpref 100,  AS_PATH 65002 65010,  origin i, MED 0
Path B:  learned via iBGP,  localpref 100,  AS_PATH 65002 65010,  origin i, MED 0
Steps 1–6  identical in every respect
Step 7     eBGP beats iBGP     → PATH A WINS

This is the step that makes a border router prefer its own external link over reaching the same prefix through a colleague inside the AS, and it is why the administrative distances (20 for eBGP, 200 for iBGP) reinforce the same preference in the RIB.

Example 4 — All the Way to Step 11

Path A:  eBGP from 192.0.2.2,     router-ID 2.2.2.2,  everything else identical
Path B:  eBGP from 198.51.100.2,  router-ID 3.3.3.3,  everything else identical
Steps 1–8   identical
Step 9      multipath not configured
Step 10     oldest eBGP path — if A's session came up first, A WINS here
            (with "bgp bestpath compare-routerid", step 10 is skipped)
Step 11     lowest router-ID: 2.2.2.2 < 3.3.3.3  → PATH A WINS

Both routes are genuinely equivalent, so the algorithm simply needs a deterministic answer. If the goal is a predictable answer rather than an arbitrary one, disable step 10 with bgp bestpath compare-routerid so the router-ID decides consistently after a reload.

Example 5 — Influencing the Outcome Deliberately

Two providers, and the requirement is that the entire AS prefers ISP-B for 203.0.113.0/24 while everything else continues to prefer ISP-A.

ip prefix-list SPECIFIC seq 5 permit 203.0.113.0/24
!
route-map FROM-ISP-B permit 10
 match ip address prefix-list SPECIFIC
 set local-preference 200
route-map FROM-ISP-B permit 20          <-- everything else unchanged at 100
!
router bgp 65001
 address-family ipv4 unicast
  neighbor 198.51.100.2 route-map FROM-ISP-B in
!
clear bgp ipv4 unicast * soft in

LOCAL_PREF is the right tool because the decision must hold across the whole AS, and it is evaluated at step 2 — early enough to override AS_PATH length at step 4, which means it beats any prepending the providers may be doing. The trailing permit 20 is what stops the route-map from discarding every other prefix.

Lab Exercises

These run on CML, EVE-NG, GNS3, or physical gear with IOSv, CSR1000v, or Catalyst 8000v. Attempt each task before opening the answer.

Lab 1 — Walk the Algorithm

Topology: R1 (AS 65001) has eBGP sessions to R2 (AS 65002) on 192.0.2.0/30 and R3 (AS 65003) on 198.51.100.0/30. Both advertise 203.0.113.0/24. R2’s path is 65002 65010; R3’s is 65003 65020 65010.

Tasks:

  1. Determine which path R1 selects and, crucially, at which step.
  2. Make R1 prefer R3 using the attribute evaluated at step 2, and confirm which step now decides.
  3. Remove that and achieve the same outcome using step 1 instead.
  4. Remove both and instead lengthen R2’s path so step 4 decides.
  5. Explain which of the three is most appropriate in a multi-router AS.
Show answer 
! Task 1
R1# show bgp ipv4 unicast 203.0.113.0/24
  65002 65010
    192.0.2.2 ... localpref 100, valid, external, best
  65003 65020 65010
    198.51.100.2 ... localpref 100, valid, external

Steps 1–3 tie; step 4 AS_PATH 2 vs 3 → R2's path wins at STEP 4.

! Task 2 — step 2, LOCAL_PREF
route-map PREFER-R3 permit 10
 set local-preference 200
router bgp 65001
 address-family ipv4 unicast
  neighbor 198.51.100.2 route-map PREFER-R3 in
clear bgp ipv4 unicast * soft in
! Now decided at STEP 2 — AS_PATH is never evaluated.

! Task 3 — step 1, WEIGHT
router bgp 65001
 address-family ipv4 unicast
  no neighbor 198.51.100.2 route-map PREFER-R3 in
  neighbor 198.51.100.2 weight 500
clear bgp ipv4 unicast * soft in
! Now decided at STEP 1.

! Task 4 — step 4, prepending (applied on R2 outbound)
route-map LENGTHEN permit 10
 set as-path prepend 65002 65002
router bgp 65002
 address-family ipv4 unicast
  neighbor 192.0.2.1 route-map LENGTHEN out
! R2's path becomes 65002 65002 65002 65010 (length 4) → R3 wins at STEP 4.

Task 5: LOCAL_PREF. Weight is local to R1, so every other router in AS 65001 would still choose R2 and the AS would route inconsistently. Prepending depends on a neighbouring AS’s cooperation and is evaluated later, so anyone setting LOCAL_PREF upstream overrides it. LOCAL_PREF propagates to all iBGP peers and is evaluated early, which is exactly what an AS-wide exit policy needs.

Lab 2 — Prove the MED Rule

Topology: R1 (AS 65001) has two eBGP sessions to the same provider AS 65002 — via R2 on 192.0.2.0/30 and via R4 on 203.0.113.0/30 — plus a third session to R3 in AS 65003. All three advertise 198.18.0.0/24 with identical AS_PATH lengths.

Tasks:

  1. Have R2 advertise with MED 200 and R4 with MED 50; determine which R1 prefers and why.
  2. Have R3 advertise with MED 10 and explain why it does not win.
  3. Add bgp always-compare-med and re-check.
  4. Remove it, add bgp deterministic-med, and explain what problem that solves.
  5. State why most providers reset MED on ingress.
Show answer 
! Task 1 — on R2 and R4 (both in AS 65002)
route-map SET-MED permit 10
 set metric 200        ! R2
 set metric 50         ! R4
! Applied outbound toward R1.

R1 prefers R4's path — MED 50 beats 200 at STEP 6.
Both paths have first-AS 65002, so MED IS compared.

Task 2: R3’s MED of 10 is the lowest of all three, but its first AS is 65003, not 65002. MED is only compared between paths from the same neighbouring AS, so R3’s path is never MED-compared against the others and falls through to step 7 and beyond.

! Task 3
router bgp 65001
 bgp always-compare-med
clear bgp ipv4 unicast * soft
! R3's path (MED 10) now wins at STEP 6 — MED is compared across all ASes.

Task 4: bgp deterministic-med makes the router group all paths by neighbouring AS and compare within each group before comparing across groups. Without it, the best path can depend on the order in which the paths happened to arrive, so two routers with identical configuration and identical information can choose differently, and a router can change its mind after a session reset. Enable it consistently across the AS.

Task 5: MED lets a customer influence a provider’s internal routing, which costs the provider money by dictating where traffic enters and how far it is carried. Providers therefore usually strip or reset MED on ingress and apply their own LOCAL_PREF policy instead — which, being step 2, overrides everything the customer tried to express at step 6.

Lab 3 — eBGP vs iBGP and Hot Potato

Topology: R1 and R2 are iBGP peers in AS 65001 with OSPF between them. R1 has an eBGP session to R3 (AS 65002) and R2 has an eBGP session to R4 (AS 65002). Both external peers advertise 198.18.0.0/24 with identical attributes.

Tasks:

  1. Determine which path R1 selects and at which step.
  2. Determine the same for R2 and explain why they differ.
  3. Raise the OSPF cost on R1’s path to its own next hop above the cost to R2’s, then re-check R1.
  4. Explain the term “hot potato routing” using this lab.
  5. Describe how to implement cold potato routing instead.
Show answer

Tasks 1 and 2: R1 has one external path (from R3) and one internal path (from R2 over iBGP). Steps 1 through 6 tie, so step 7 decides: eBGP beats iBGP, and R1 uses its own external link. R2 reaches the identical conclusion for its own link. Each border router prefers its own exit — which is correct, and is why the two differ.

! Task 3
! Step 7 still resolves before step 8, so R1 continues to prefer its own eBGP
! path regardless of IGP cost. Step 8 only applies when both candidates are
! internal, or when step 7 has already tied.

Task 3: Nothing changes. This is the point of the exercise — step 8 is below step 7, so an IGP cost change cannot override the eBGP-over-iBGP preference. Step 8 matters when a router is choosing between two internal paths to different exits, which is the situation for a non-border router inside the AS.

Task 4: Hot potato routing means handing traffic to the neighbouring AS as quickly as possible, using the nearest exit. Step 8 encodes this by preferring the lowest IGP metric to the next hop. The economic logic is that carrying another network’s traffic across your own backbone costs you money, so you get rid of it early.

Task 5: Cold potato means deliberately carrying traffic further inside your own AS to hand it off closer to its destination, usually to control the quality of the path. Because step 8 always prefers the nearest exit, you override it higher up the list with LOCAL_PREF at step 2, setting a higher value on routes received at the preferred distant exit.

Lab 4 — Multipath and the Final Tie-Breakers

Topology: R1 (AS 65001) has two eBGP sessions to AS 65002 — via 192.0.2.2 (peer router-ID 2.2.2.2) and via 198.51.100.2 (peer router-ID 3.3.3.3) — both advertising 198.18.0.0/24 with completely identical attributes.

Tasks:

  1. Determine which path wins and at which step, then verify against the router.
  2. Add bgp bestpath compare-routerid and explain what changes.
  3. Enable maximum-paths 2 and check both the BGP table and the RIB.
  4. Confirm how many paths are advertised to an iBGP peer, and explain.
  5. State the requirement for two paths to qualify for multipath.
Show answer 
! Task 1
Steps 1–8 all tie. Step 9 multipath not enabled.
Step 10 prefers the OLDEST eBGP session — whichever came up first.
If both came up together, step 11 decides: 2.2.2.2 < 3.3.3.3.

R1# show bgp ipv4 unicast 198.18.0.0/24

Task 2: bgp bestpath compare-routerid disables the step 10 “oldest path” rule, so the decision falls to the router-ID at step 11 and becomes deterministic. Without it, a reload can silently change which path wins, because session establishment order is not guaranteed.

! Task 3
router bgp 65001
 address-family ipv4 unicast
  maximum-paths 2

R1# show bgp ipv4 unicast 198.18.0.0/24
    192.0.2.2    ... valid, external, multipath, best
    198.51.100.2 ... valid, external, multipath

R1# show ip route 198.18.0.0
  Known via "bgp 65001", distance 20
  Routing Descriptor Blocks:
  * 192.0.2.2
    198.51.100.2                  <-- both installed, traffic load-shared

Task 4: Exactly one — the path marked best. Multipath changes forwarding only; BGP still advertises a single best path per prefix. This is why a downstream router never learns that its upstream is load-sharing.

Task 5: The paths must be equal in every attribute evaluated in steps 1 through 8 — weight, local preference, AS_PATH length, origin, MED, and IGP metric to the next hop — and must both be external or both internal. By default the AS_PATH contents must match too, not merely the length; bgp bestpath as-path multipath-relax relaxes that to compare length only, which is what makes multipath across two different providers possible.

Common Mistakes and Exam Traps

  • The algorithm stops at the first difference. If step 2 decides, nothing below it is ever evaluated — a question asking “which step decided” has exactly one right answer.
  • MED is lowest-wins while weight and local-pref are highest-wins.
  • MED is only compared between paths from the same neighbouring AS unless always-compare-med is configured. This is the most common trap in the whole topic.
  • An unreachable next hop disqualifies a path before step 1.
  • BGP ignores bandwidth completely. A shorter AS_PATH wins over a faster link.
  • AS_PATH comparison counts length, not content, and an AS_SET counts as one entry.
  • Weight is Cisco-only and never advertised, so it cannot produce AS-wide consistency.
  • Step 7 sits above step 8, so IGP cost cannot override the eBGP-over-iBGP preference.
  • Multipath still advertises only one path.
  • Prepending is evaluated at step 4, so it loses to anyone else’s LOCAL_PREF at step 2.
  • Without deterministic-med, results can depend on arrival order.

Check Your Understanding

Ten questions on the material in Part 4. Each answer is explained as you go, so a wrong answer is worth as much as a right one.

1. 

Which attribute is compared FIRST in the BGP best path selection algorithm?

2. 

Two paths have identical attributes except MED: path A is from AS 65002 with MED 50, path B is from AS 65003 with MED 10. Which wins on MED?

3. 

Which of these best path attributes is LOWEST-wins rather than highest-wins?

4. 

Two paths are identical through step 6. One is learned via eBGP, the other via iBGP. Which is selected and at which step?

5. 

What does step 8 of the algorithm — lowest IGP metric to the NEXT_HOP — implement?

6. 

Which condition disqualifies a path BEFORE step 1 of the algorithm is reached?

7. 

With 'maximum-paths 4' configured and four equal paths installed, how many paths does BGP advertise to a peer?

8. 

Two paths are identical except AS_PATH: 65002 65010 versus 65003 65020 65010. The shorter path runs over a 10 Mbps link and the longer over 10 Gbps. Which wins?

9. 

What does 'bgp bestpath compare-routerid' change?

10. 

A prefix has three paths with local preferences of 100, 200 and 100. At which step is the decision made?

1 out of 1

Summary

BGP selects exactly one best path per prefix by walking an ordered list and stopping at the first comparison that differentiates. Weight, then local preference, then locally originated, then AS_PATH length, origin, MED, eBGP over iBGP, and IGP metric to the next hop settle almost every real case; the remaining steps exist to guarantee a deterministic answer when paths are genuinely equivalent.

The practical skill is not reciting the list but reading show bgp ipv4 unicast prefix and naming the step that decided. That single habit turns BGP troubleshooting from guesswork into a short, mechanical check — and it is exactly what the exam asks for.

This completes the four-part BGP series for CCNP ENCOR. Parts 1, 2, and 3 cover fundamentals, neighbor relationships, and path attributes respectively.

Tags: , , ,

Leave a Reply