Understanding BGP Path Preference and Best Path Selection
BGP path preference and best path selection follow a strict, ordered sequence of attributes that every CCNP ENARSI candidate must master. This post walks through all twelve decision criteria, explains how to tune Weight, Local Preference, AS_PATH, and MED in production, and covers systematic troubl
When BGP receives multiple paths to the same destination prefix, it doesn't forward traffic across all of them simultaneously. It selects a single best path and installs that route into the routing table. Understanding exactly how that decision gets made is not just an exam requirement for ENARSI 1.11.c; it's essential operational knowledge for anyone tuning traffic flows in a multi-homed enterprise or service provider environment.
The BGP Best Path Selection Process
BGP evaluates candidate paths through a deterministic, ordered sequence of attributes and tiebreakers. Cisco IOS applies these criteria in order, stopping as soon as one path is preferred over another. If you reach the end of the list with all attributes equal, the router picks the path with the lowest Router ID. Memorize this sequence. On the exam and in production, you need to know exactly which knob controls which step.
The canonical decision sequence on Cisco IOS is:
- Prefer the highest Weight (Cisco proprietary, local to the router)
- Prefer the highest Local Preference (scope: local AS)
- Prefer locally originated routes (network or aggregate commands over iBGP-learned)
- Prefer the shortest AS_PATH
- Prefer the lowest Origin code (IGP < EGP < Incomplete)
- Prefer the lowest MED (compared only between paths from the same neighboring AS by default)
- Prefer eBGP over iBGP paths
- Prefer the path through the lowest IGP metric to the BGP next-hop
- Prefer the oldest eBGP path (stability tiebreaker)
- Prefer the path from the lowest BGP Router ID
- Prefer the path with the shortest cluster list (relevant in route reflector topologies)
- Prefer the path from the lowest neighbor IP address
The mnemonic We Love Oranges AS Oranges Mean Pure Refreshment maps to Weight, Local Preference, Originate, AS_PATH, Origin, MED, Prefer eBGP, and IGP metric. Add the final tiebreakers mentally and you have the full sequence.
Attribute Deep-Dive: The Four You'll Tune Most Often
Weight
Weight is Cisco proprietary and never propagated to any peer. It influences outbound path selection only on the local router. Use it when one router in your AS needs to prefer a specific exit without impacting any other router's decision. Assign weight in a route-map applied to a neighbor:
route-map SET-WEIGHT permit 10
set weight 200
!
router bgp 65001
neighbor 203.0.113.1 route-map SET-WEIGHT inLocal Preference
Local Preference is the primary tool for AS-wide outbound path control. It is exchanged between iBGP peers but stripped at eBGP boundaries. A higher value wins. The default is 100. Raising Local Preference on routes received from a preferred upstream peer signals all routers in the AS to exit through that peer.
route-map SET-LOCPREF permit 10
set local-preference 150
!
router bgp 65001
neighbor 203.0.113.1 route-map SET-LOCPREF inAS_PATH
BGP path selection inherently prefers shorter AS_PATH lengths. You can influence inbound traffic from external ASes by prepending your own AS number to routes you advertise outbound, making specific paths appear longer and less attractive to remote peers. Use set as-path prepend in an outbound route-map:
route-map PREPEND-PATH permit 10
set as-path prepend 65001 65001 65001Be conservative with prepending. Excessive prepending can cause routing instability and may be filtered by some providers beyond three or four prepends.
MED
MED (Multi-Exit Discriminator) is the tool for influencing which entry point a neighboring AS uses when entering your AS. It is non-transitive and, by default, Cisco only compares MEDs between paths originating from the same neighboring AS. A lower MED is preferred. Enable bgp always-compare-med only when all peers agree on a consistent MED policy, otherwise you risk determinism issues:
router bgp 65001
bgp always-compare-medVerifying Best Path Selection
The most important verification command is show bgp ipv4 unicast followed by the specific prefix. The output annotates the best path with > and shows all candidate paths with their attributes side by side.
R1# show bgp ipv4 unicast 10.10.10.0/24
BGP routing table entry for 10.10.10.0/24, version 12
Paths: (2 available, best #1, table default)
Advertised to update-groups:
1
Refresh Epoch 1
65002
203.0.113.1 from 203.0.113.1 (203.0.113.1)
Origin IGP, metric 0, localpref 150, weight 0, valid, external, best
rx pathid: 0, tx pathid: 0x0
65003
203.0.113.5 from 203.0.113.5 (203.0.113.5)
Origin IGP, metric 0, localpref 100, weight 0, valid, external
rx pathid: 0, tx pathid: 0The best keyword appears inline with the winning path. If you want the router to explain exactly why it selected the best path, use debug ip bgp 10.10.10.0/24 during a soft clear or peer reset. That output walks through each criterion that was evaluated.
Troubleshooting Path Selection Anomalies
When best path selection behaves unexpectedly, work through these checks systematically:
- Check Weight first: A misconfigured inbound route-map setting weight on the wrong neighbor is the most common silent culprit. Weight is local and invisible in the BGP table of any other router.
- Verify next-hop reachability: A path with superior attributes is still unusable if the next-hop IP is not in the routing table. IOS marks it as invalid and skips it entirely.
- MED comparison scope: Paths from different ASes are not MED-compared by default. If you expect MED to break a tie between paths from two different upstream ASes, you must configure
bgp always-compare-med. - Confirm iBGP next-hop: iBGP does not change the next-hop by default. A route learned from an eBGP peer and reflected via iBGP retains the external next-hop. Use
neighbor x.x.x.x next-hop-selfon the iBGP session if IGP reachability to that external next-hop is missing. - Route reflector cluster list: In route reflector topologies, a longer cluster list counts against a path at step 11. This is rarely the issue but becomes relevant in large-scale designs with nested reflectors.
What's Next
With best path selection mechanics solidified, the next logical step is understanding how BGP route filtering and policy tools shape which prefixes enter and leave your BGP table in the first place. Prefix lists, route-maps, and AS_PATH access lists give you the precision to control what gets advertised, what gets accepted, and what gets modified before the best path algorithm even runs. That topic builds directly on everything covered here.
Tools and resources for this topic
- CCNP ENARSI 300-410 Official Cert Guide — The definitive ENARSI study resource by Raymond Lacoste. Covers advanced routing, services, and troubleshooting.