Hands-On Lab: Influencing BGP Path Selection with Weight and Local Preference

Lab Objective

Configure BGP weight on one router to prefer a specific outbound path locally, then configure local preference to influence path selection across an entire AS, verifying the scope and precedence differences between the two attributes.

Lab Purpose

BGP's default best-path algorithm, discussed conceptually earlier in this series, considers several attributes in a strict priority order. Weight and local preference are the two highest-priority attributes an administrator commonly manipulates, but they differ fundamentally in scope: weight is Cisco-proprietary and purely local to one router, while local preference is shared across an entire AS via iBGP.

Lab Topology

R1 (AS 65020) has two paths to reach
192.168.230.0/24 in a remote AS:

Path via R2 (eBGP neighbor)
Path via R3 (eBGP neighbor, different link)

Both paths currently appear equally
viable by default BGP attributes

Task 1: Verify the Default Best Path

Confirm which path R1 currently selects by default before any manipulation.

Task 2: Configure Weight to Prefer the R2 Path

On R1, configure a higher weight for routes learned from R2 specifically.

Task 3: Verify Weight Changed the Best Path

Confirm R1 now prefers the path via R2, and that this decision is purely local to R1.

Task 4: Configure Local Preference Instead

Remove the weight configuration, and instead configure a route-map setting local preference on routes learned from R3, applied where it can propagate via iBGP.

Task 5: Verify Local Preference Propagates Further Than Weight

Confirm an iBGP neighbor of R1 also inherits the local preference-based preference, something weight alone could never achieve.

Solution and Verification

R1# show ip bgp 192.168.230.0

BGP routing table entry for 192.168.230.0/24
  65030
    10.10.10.2 from 10.10.10.2 (2.2.2.2)
      Origin IGP, metric 0, weight 0, valid, external, best
  65030
    10.20.20.2 from 10.20.20.2 (3.3.3.3)
      Origin IGP, metric 0, weight 0, valid, external
-- Both paths show weight 0 (the default),
-- and BGP's tie-breaking rules happened
-- to select the R2 path as best here

R1(config)# router bgp 65020
R1(config-router)# neighbor 10.10.10.2 weight 200

-- Weight is set directly on the neighbor
-- statement -- no route-map required for
-- this simple per-neighbor case

R1# show ip bgp 192.168.230.0

BGP routing table entry for 192.168.230.0/24
  65030
    10.10.10.2 from 10.10.10.2 (2.2.2.2)
      Origin IGP, metric 0, weight 200, valid, external, best
  65030
    10.20.20.2 from 10.20.20.2 (3.3.3.3)
      Origin IGP, metric 0, weight 0, valid, external
-- R2's path now has weight 200 and remains
-- best -- but this preference exists ONLY
-- on R1; any other router in AS 65020 has
-- no visibility into this weight value at all,
-- since weight is never carried in BGP
-- updates between routers

R1(config)# router bgp 65020
R1(config-router)# no neighbor 10.10.10.2 weight 200
R1(config-router)# neighbor 10.20.20.2 route-map SET-LOCALPREF in

R1(config)# route-map SET-LOCALPREF permit 10
R1(config-route-map)# set local-preference 200

R1# clear ip bgp 10.20.20.2 soft in

R1# show ip bgp 192.168.230.0

BGP routing table entry for 192.168.230.0/24
  65030
    10.20.20.2 from 10.20.20.2 (3.3.3.3)
      Origin IGP, metric 0, localpref 200, valid, external, best
-- The R3 path is now preferred instead,
-- driven by local preference this time

R4# show ip bgp 192.168.230.0
-- (R4, an iBGP neighbor of R1 within the
--  same AS 65020)

BGP routing table entry for 192.168.230.0/24
  65030
    10.20.20.2 from 10.10.10.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 200, valid, internal, best
-- R4 sees the SAME localpref value (200)
-- that R1 set, since local preference is
-- explicitly carried within iBGP updates --
-- something weight, confined to R1 alone,
-- could never accomplish

Key Takeaway

Weight and local preference solve conceptually similar problems at different scopes: weight is the fastest, simplest way to influence one router's own path choice but stops entirely at that router's boundary, while local preference is the correct tool whenever every router within the AS needs to make a consistent, coordinated path decision — reaching for weight when the actual goal is AS-wide consistency is a common mistake that produces inconsistent path selection across different routers in the same AS.