Stream of Knowledge: Day 13 — Cisco BGP Weight: Local-Only Best-Path Policy Without AS-Wide Propagation

Day 13 — Cisco BGP Weight: Local-Only Best-Path Policy Without AS-Wide Propagation

at September 08, 2026

Learning objective

Use Cisco Weight to prefer one path on a single IOS XE router, prove that the decision remains local to that router, and distinguish Weight from standards-based attributes such as LOCAL_PREF.

Cisco BGP Weight: Local-Only Best-Path Policy Without AS-Wide Propagation

1. Opening — a powerful knob with a deliberately small scope

An enterprise edge router receives the same destination from two external peers. Both routes are valid. Both have reachable next hops. Their standard BGP attributes are otherwise equal enough that the router reaches late tie-breakers.

The operator wants only this router to prefer ISP-A. Other routers in the autonomous system must not inherit that preference.

Cisco Weight is designed for exactly that kind of local decision.

Weight is evaluated before LOCAL_PREF in Cisco's best-path sequence. The higher value wins. The important operational boundary is that Weight is local to the Cisco router: it is not a BGP path attribute defined by RFC 4271 and it is not advertised to BGP peers.

That makes Weight useful—and dangerous. It can create a preference that is invisible to the rest of the AS unless engineers deliberately inspect the router where it was applied.

2. Standards behavior versus Cisco behavior

RFC 4271 defines the standard BGP path attributes used by interoperable BGP speakers. Weight is not among them.

Cisco IOS and IOS XE add Weight as a local selection value. Cisco documentation places it at the beginning of the Cisco best-path algorithm: among otherwise eligible paths, the path with the highest Weight is preferred before the algorithm evaluates LOCAL_PREF and later attributes.

Two consequences follow:

A Weight change can override a LOCAL_PREF difference on the same router.
The Weight change does not travel in an UPDATE to another router.

Do not describe Weight as a transitive, non-transitive, well-known or optional BGP attribute. Those classifications apply to BGP path attributes; Weight is a Cisco-local selection property.

3. Common sources of Weight

Cisco IOS XE can assign Weight in more than one way.

Neighbor-level Weight

A neighbor-level setting applies a local Weight to routes learned from that peer:

neighbor 192.0.2.1 weight 250

This is simple but broad: every applicable route from the neighbor receives the configured value.

Route-map `set weight`

A route map can set Weight selectively based on prefix, AS path, community or another supported match:

route-map PREFER-SERVICE permit 10
 match ip address prefix-list SERVICE
 set weight 300

Cisco documentation notes that a Weight assigned by set weight can override Weight assigned with the neighbor-level command for matching routes.

Locally originated routes

Cisco commonly displays Weight 32768 for locally originated BGP routes. Received routes normally show Weight 0 unless policy changes it. Day 15 will isolate the separate “locally originated” best-path step rather than relying only on the default Weight difference.

4. Scope comparison: Weight versus LOCAL_PREF

| Property | Weight | LOCAL_PREF |

|---|---|---|

| Standard BGP attribute | No | Yes |

| Cisco-local selection value | Yes | No |

| Advertised to iBGP peers | No | Yes, within the AS |

| Advertised to ordinary eBGP peers | No | No |

| Higher value preferred | Yes | Yes |

| Best use | One-router preference | AS-wide exit policy |

If several routers must agree on the preferred exit, LOCAL_PREF is normally the more appropriate mechanism. If only one Cisco router should prefer a path, Weight can be intentionally narrow.

5. Scenario — Harbor Edge Local Preference

Illustrative lab — not a real incident.

Topology

Cisco BGP Weight: Local-Only Best-Path Policy Without AS-Wide Propagation

        ISP-A R1                    ISP-B R2
         AS65010                     AS65020
     192.0.2.1/30              198.51.100.1/30
            \                      /
             \ eBGP          eBGP /
              \                  /
               EDGE-R3 AS65030
       192.0.2.2/30   198.51.100.2/30
                       |
                203.0.113.0/24
              learned from both peers

Both providers advertise 203.0.113.0/24. In the closed lab, both paths are deliberately constructed with equal higher-priority standard attributes so the Weight change is easy to observe.

Objective

Establish both eBGP sessions.
Verify both paths are eligible.
Apply Weight 250 to routes from ISP-A.
Confirm R3 prefers ISP-A locally.
Confirm no BGP UPDATE contains “Weight”.
Remove the setting and verify the original decision process returns.

6. Prerequisites

Three IOS XE-capable nodes.
IOS XE 17.18.x documentation baseline.
Direct eBGP from R3 to R1 and R2.
Both provider next hops reachable.
Console or out-of-band management.
A lab-only prefix, 203.0.113.0/24, originated by each provider for controlled comparison.

The dual origination is intentionally artificial for attribute training. Do not model real prefix ownership from it.

7. Baseline configuration

R1 — AS65010

hostname R1
interface GigabitEthernet0/0
 ip address 192.0.2.1 255.255.255.252
 no shutdown
!
ip route 203.0.113.0 255.255.255.0 Null0
!
router bgp 65010
 bgp router-id 10.10.10.1
 neighbor 192.0.2.2 remote-as 65030
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
  neighbor 192.0.2.2 activate
 exit-address-family

R2 — AS65020

hostname R2
interface GigabitEthernet0/0
 ip address 198.51.100.1 255.255.255.252
 no shutdown
!
ip route 203.0.113.0 255.255.255.0 Null0
!
router bgp 65020
 bgp router-id 10.20.20.2
 neighbor 198.51.100.2 remote-as 65030
 address-family ipv4 unicast
  network 203.0.113.0 mask 255.255.255.0
  neighbor 198.51.100.2 activate
 exit-address-family

R3 — AS65030

hostname R3
interface GigabitEthernet0/0
 ip address 192.0.2.2 255.255.255.252
 no shutdown
interface GigabitEthernet0/1
 ip address 198.51.100.2 255.255.255.252
 no shutdown
!
router bgp 65030
 bgp router-id 10.30.30.3
 neighbor 192.0.2.1 remote-as 65010
 neighbor 198.51.100.1 remote-as 65020
 address-family ipv4 unicast
  neighbor 192.0.2.1 activate
  neighbor 198.51.100.1 activate
 exit-address-family

8. Verification before modification

On R3:

show ip bgp summary
show ip bgp 203.0.113.0
show ip route 203.0.113.0
show ip route 192.0.2.1
show ip route 198.51.100.1

Confirm:

both sessions are Established;
both paths to the prefix exist;
both next hops resolve;
received Weight is the unmodified default for both paths;
whichever path is best before the experiment is recorded as baseline evidence.

Do not invent which peer wins the late tie-breakers. The selected image and exact router IDs can influence the baseline result.

9. Controlled modification — prefer ISP-A locally

On R3:

configure terminal
router bgp 65030
 address-family ipv4 unicast
  neighbor 192.0.2.1 weight 250
 end

Use an inbound soft refresh or appropriate safe reprocessing method if the selected image requires routes to be re-evaluated for the new neighbor Weight.

Then verify:

show ip bgp 203.0.113.0
show ip route 203.0.113.0

Expected result

The path learned from 192.0.2.1 should display Weight 250 and become preferred if it remains otherwise eligible.

The peer does not receive an UPDATE containing Weight because Weight is not transmitted as a BGP path attribute.

10. Fault injection

Illustrative lab — not a real incident.

Lab name

Harbor Hidden Weight Override

Fault

An engineer applies Weight 400 to ISP-B while an existing AS-wide LOCAL_PREF policy intends ISP-A to be preferred.

router bgp 65030
 address-family ipv4 unicast
  neighbor 198.51.100.1 weight 400

Expected symptoms

R3 chooses ISP-B locally.
Other routers in AS65030 do not learn “Weight 400”.
A troubleshooting engineer who checks only route policy on another router may see no reason for R3's decision.

Lesson

A local implementation knob can override a standards-based policy on one router without creating an obvious AS-wide policy artifact.

11. Step-by-step troubleshooting

Confirm the affected prefix.
Verify both BGP paths are valid and next hops reachable.
Inspect the full BGP path detail, including Weight and LOCAL_PREF.
Determine whether Weight came from a neighbor command or route map.
Check route-map precedence and matches.
Compare R3's decision with another router in the AS.
Remember that packet captures of BGP UPDATE messages will not show Weight.
Identify whether the intended policy is router-local or AS-wide.
Remove the smallest incorrect Weight policy.
Re-evaluate the route and verify forwarding.

12. Root cause and correction

Root cause

The router-local Weight value took precedence over later selection attributes.

Correction

Remove or narrow the Weight policy if the intent is not local to that router. If the intended decision must be shared throughout the AS, implement an appropriately designed LOCAL_PREF policy instead.

Why the correction works

It removes the earlier Cisco-local selection override, allowing the path to be compared using the intended standard attributes and later tie-breakers.

13. Post-fix verification

show ip bgp 203.0.113.0
show running-config | section router bgp
show route-map
show ip route 203.0.113.0

Record:

Weight on each path;
selected best path;
next-hop resolution;
route installed in the RIB;
any change in traffic path if a forwarding endpoint is added.

14. Rollback

router bgp 65030
 address-family ipv4 unicast
  no neighbor 192.0.2.1 weight 250
  no neighbor 198.51.100.1 weight 400

If Weight was set by route map, rollback the route-map clause rather than only removing a neighbor command.

Preserve before/after show ip bgp evidence because the local-only nature of Weight can otherwise make the original cause hard to reconstruct.

15. Production lessons

Design lesson

Use Weight only when router-local policy is actually desired.

Operations lesson

A distributed troubleshooting workflow must include local path-selection state; an AS-wide policy review alone can miss Weight.

Change-management lesson

Because Weight is evaluated early, a small configuration change can redirect large traffic volumes immediately on that router.

Portability lesson

Weight is Cisco-specific. Designs intended to remain vendor-neutral should prefer standards-based policy mechanisms when possible.

Security lesson

Unexpected local preference overrides can defeat carefully designed containment or preferred-exit policy. Treat path-selection changes as high-impact routing changes.

16. Knowledge check

Q1

Why does another iBGP router not see the Weight value configured on R3?

Answer: Weight is a Cisco-local selection property, not a BGP path attribute carried in UPDATE messages.

Q2

Which path wins if one path has Weight 300 and another has higher LOCAL_PREF but Weight 0, assuming both are eligible?

Answer: On Cisco's documented selection order, the path with Weight 300 is evaluated as better before LOCAL_PREF is considered.

Q3

When is LOCAL_PREF usually a better tool than Weight?

Answer: When the preferred exit should be communicated consistently to other BGP speakers inside the same AS.

17. Sources

RFC 4271 — *A Border Gateway Protocol 4 (BGP-4)* — standard BGP path attributes and Decision Process.
Cisco — *IP Routing Configuration Guide, Cisco IOS XE 17.18.x: Configuring BGP* — Cisco path-selection ordering.
Cisco — *Connecting to a Service Provider Using External BGP, IOS XE 17.x* — configuring neighbor Weight and policy examples.
Cisco — *Cisco IOS IP Routing: BGP Command Reference* — neighbor weight syntax and behavior.

Accessed: 2026-08-11.