> ## Content Index
> Fetch the complete content index at: https://www.pinglabz.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Why Is BGP Choosing the Wrong Path? Troubleshooting Best Path
- URL: https://www.pinglabz.com/troubleshoot-bgp-path-selection/
- Published: 2026-03-28T06:51:58.000Z
- Updated: 2026-08-24T17:02:09.000Z
- Description: You set local-pref, route maps, and communities, and traffic still goes the wrong way. BGP is deterministic; a surprise path means either policy is not applied where you think, or a higher priority step decided first.
- Author: Jaime
- Tags: BGP, #Import 2026-08-01 19:54

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](https://www.pinglabz.com/bgp-best-path-selection/)). 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.

If you want the bigger picture first, the [BGP complete guide](https://www.pinglabz.com/bgp/) covers the architecture this article plugs into.

## 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:

Weight

Step1

Path 1 (ISP-B)0

Path 2 (ISP-A)0

Winner?Tie

Local-Pref

Step2

Path 1 (ISP-B)100

Path 2 (ISP-A)100

Winner?Tie

Locally originated?

Step3

Path 1 (ISP-B)No

Path 2 (ISP-A)No

Winner?Tie

AS-Path Length

Step4

Path 1 (ISP-B)2 (65020 65010)

Path 2 (ISP-A)1 (65010)

Winner?Path 2 wins

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
```

Read the output before reaching for the config: the 200 is sitting on ISP-B's path (198.51.100.1), not ISP-A's. The policy landed on the wrong neighbor. Check which route-map is applied where:

```
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.

Get the BGP Field Reference - 9 pages, free

Everything you'd want to remember about BGP on nine printable pages. FSM diagram, all 13 best-path steps with gotchas, troubleshooting decision tree, copy-paste IOS XE templates, and real lab captures. Free for PingLabz members - just sign up with your email.

[Get the BGP cheat-sheet](https://www.pinglabz.com/bgp-cheatsheet/)

## 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.