Why Is BGP Choosing the Wrong Path? Troubleshooting Best Path

You've set up your BGP policy — local-pref, route maps, communities — and traffic is still going the wrong way. BGP is deterministic: it follows the 13-step best path algorithm exactly (see BGP Best Path Selection Algorithm). When the result isn't what you expect, it means one of two things: either your policy isn't applied where you think it is, or a higher-priority step is deciding before your intended step gets evaluated.

Step 1: Identify All Candidate Paths

R1-HQ# show ip bgp 100.64.0.0/18
BGP routing table entry for 100.64.0.0/18, version 22
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1
  65020 65010
    198.51.100.1 from 198.51.100.1 (198.51.100.1)
      Origin IGP, metric 0, localpref 100, weight 0, valid, external
      rx pathid: 0, tx pathid: 0
  65010
    203.0.113.1 from 203.0.113.1 (203.0.113.1)
      Origin IGP, metric 0, localpref 100, weight 0, valid, external, best
      rx pathid: 0, tx pathid: 0x0

Read every attribute for each path: weight, localpref, AS-path length, origin, metric (MED), source (external/internal), next-hop. The deciding attribute is the first one that differs.

Step 2: Walk Through the Algorithm

Compare the two paths manually against each step:

Path 2 (ISP-A) wins at step 4 — shorter AS-path. If you expected ISP-B to win, you need to either set a higher local-pref for ISP-B routes (step 2) or prepend the ISP-A path to make it longer.

Common "Wrong Path" Scenarios

Scenario 1: Local-pref set but not taking effect

You configured local-pref 200 on ISP-A routes but BGP still prefers ISP-B.

R1-HQ# show ip bgp 100.64.0.0/18
  65010
    203.0.113.1 ... localpref 100 ... external
  65020
    198.51.100.1 ... localpref 200 ... external, best

Wait — ISP-B has local-pref 200, not ISP-A. Check which route-map is applied to which neighbor:

R1-HQ# show ip bgp neighbors 172.16.0.2 | include route-map
  Route map for incoming advertisements is *not set*
R1-HQ# show ip bgp neighbors 172.16.0.6 | include route-map
  Route map for incoming advertisements is PREFER-PRIMARY

The route-map was applied to ISP-B (172.16.0.6) instead of ISP-A (172.16.0.2). Simple misconfiguration — fix by applying to the correct neighbor.

Scenario 2: Weight overriding local-pref

R1-HQ# show ip bgp 100.64.0.0/18
  65010
    203.0.113.1 ... localpref 200, weight 0 ... external
  65020
    198.51.100.1 ... localpref 100, weight 500 ... external, best

Weight (step 1) is evaluated before local-pref (step 2). Weight 500 beats 0, regardless of the local-pref difference. Check for neighbor weight or a route-map setting weight.

Scenario 3: eBGP beating iBGP despite better attributes

R2-HQ# show ip bgp 100.64.0.0/18
  65010
    172.16.0.4 from 172.16.0.4 ... localpref 100, valid, external, best
  65010
    1.1.1.1 from 1.1.1.1 ... localpref 200, valid, internal

Why does the eBGP path (localpref 100) beat the iBGP path (localpref 200)? It doesn't — check again. If local-pref truly is 200 on the iBGP path, it should win at step 2. More likely, the iBGP path has an issue: next-hop unreachable (making it invalid), or the local-pref isn't actually propagated (check if next-hop-self and the route-map are correctly configured on R1-HQ).

Scenario 4: MED comparison not happening

! Path from ISP-A: MED 50
! Path from ISP-B: MED 200
! ISP-B path is selected

MED is only compared between paths from the same neighboring AS by default. ISP-A (AS 65010) and ISP-B (AS 65020) are different ASes — MED comparison is skipped. Enable bgp always-compare-med if you need cross-AS MED comparison.

Using bestpath-compare (IOS XE)

Some IOS XE versions support a detailed comparison output:

R1-HQ# show ip bgp bestpath 100.64.0.0/18

This shows step-by-step which attribute decided the winner. Not available on all platforms — check your version.

Debugging Path Selection

R1-HQ# debug ip bgp bestpath 100.64.0.0/18
*Mar 27 10:30:15: BGP: bestpath for 100.64.0.0/18: comparing paths
*Mar 27 10:30:15: BGP:   path 1 via 203.0.113.1: weight 0, localpref 100, as-path length 1
*Mar 27 10:30:15: BGP:   path 2 via 198.51.100.1: weight 0, localpref 100, as-path length 2
*Mar 27 10:30:15: BGP:   Winner: path 1 (shorter AS-path)

Troubleshooting Checklist

1. show ip bgp [prefix] — read ALL attributes for ALL paths
2. Walk through the 13 steps manually — find the first difference
3. Verify policy application: show ip bgp neighbors [ip] | include route-map
4. Check if the route-map is actually matching: show route-map [name] with hit counts
5. After policy changes: clear ip bgp [peer] soft in/out to re-evaluate
6. Check for weight — it's the silent override at step 1 that's easy to forget

Key Takeaways

• When BGP picks the "wrong" path, it's always because a higher-priority step in the algorithm decided before your intended attribute was evaluated.
• show ip bgp [prefix] with all paths visible is your primary tool — read every attribute for every path.
• Weight (step 1) overrides local-pref (step 2) overrides AS-path (step 4) overrides MED (step 6). Know the order.
• MED only compares within the same AS by default — this catches many people off guard.
• After any policy change, always do a soft reset to trigger re-evaluation. Stale best-path decisions persist until routes are re-processed.