Short answer: BGP Weight is a local path-selection value used by Cisco-style BGP implementations to make one router prefer one BGP path over another. Higher Weight wins, Cisco documents it as the first best-path comparison step, and Cisco also states that Weight is local to the router where it is configured.[1][2]
Use Weight when one router needs a local outbound preference. Use LOCAL_PREF when the whole autonomous system should agree on an outbound exit. Do not use Weight when you expect a policy to propagate through iBGP, influence inbound Internet traffic, or become a portable standards-based BGP attribute.
Where Weight fits in BGP
RFC 4271 defines BGP as an inter-AS routing protocol that exchanges reachability information and path attributes such as ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, LOCAL_PREF, ATOMIC_AGGREGATE and AGGREGATOR; Weight is not one of the standard BGP path attributes in that RFC.[4] Cisco treats Weight as an implementation-specific path-selection parameter, not as a transitive BGP attribute carried in UPDATE messages.[2]
That distinction matters operationally. If Router R1 sets Weight 500 for routes learned from ISP-A, only R1 uses that value during its own best-path calculation. R2, R3 and route reflectors do not automatically inherit R1's Weight decision.
Best-path order: why Weight is powerful
In Cisco's published best-path algorithm, the first comparison is highest Weight, followed by highest LOCAL_PREF and then locally originated routes.[2] This means a non-zero Weight can override what many engineers expect to be the normal AS-wide policy signal: LOCAL_PREF.
| Attribute / value | Scope | Higher or lower wins? | Typical use |
|---|---|---|---|
| Weight | Single local router | Higher wins | Router-specific outbound preference |
| LOCAL_PREF | Inside the AS through iBGP | Higher wins | AS-wide outbound exit policy |
| AS_PATH length | Advertised between ASes | Shorter usually wins after earlier checks | Loop prevention and coarse inbound influence |
| MED | Neighboring AS hint | Lower wins when compared | Suggest preferred ingress to a neighboring AS |
Default Weight values
Cisco documents a default Weight of 32768 for locally originated prefixes and 0 for routes learned from a BGP neighbor.[1] That is why a route injected with a network statement or redistribution can stay preferred locally even when another route appears after a failure is repaired.
Network Next Hop Metric LocPrf Weight Path
*> 10.10.10.0/24 0.0.0.0 0 32768 i
* 10.20.20.0/24 203.0.113.1 0 0 64501 i
The first route is locally originated, so the local router gives it Weight 32768. The second route is learned from a peer, so it shows Weight 0 unless policy changes it.
Traffic-engineering impact
Outbound control
Weight controls outbound forwarding only on the router where it is configured. If Edge-1 receives 198.51.100.0/24 from ISP-A and ISP-B, setting a higher Weight on ISP-A makes Edge-1 choose ISP-A for traffic that Edge-1 forwards toward that prefix.
Inbound influence
Weight does not influence how another AS sends traffic toward you. It is not advertised to eBGP neighbors, not distributed through iBGP as an AS-wide policy, and not seen by a provider, cloud edge or upstream transit network. For inbound influence, use tools such as AS_PATH prepending, MED toward the same neighboring AS, provider communities, more-specific advertisements where appropriate, or commercial traffic-engineering controls.
What Weight cannot control
- It cannot make the Internet enter your AS through a chosen circuit.
- It cannot create a consistent exit policy across many routers unless you configure every relevant router consistently.
- It cannot fix a missing route to the BGP NEXT_HOP; Cisco's best-path process ignores paths with inaccessible next hops before comparing attributes.[2]
- It cannot replace route filtering, RPKI/ROV policy, max-prefix protection or prefix-list hygiene.
Dual-ISP example: local override on one edge router
Assume a small AS has one edge router connected to two ISPs. ISP-A should normally be preferred by this one router for all outbound Internet routes, but the rest of the AS does not need to learn a new policy value.
AS 65010
+------------+
| Edge-1 |
| |-- eBGP -- ISP-A AS 64501
| |-- eBGP -- ISP-B AS 64502
+------------+
Cisco-style neighbor Weight
router bgp 65010
neighbor 203.0.113.1 remote-as 64501
neighbor 203.0.113.1 description ISP-A primary-for-this-router
neighbor 203.0.113.1 weight 500
neighbor 198.51.100.1 remote-as 64502
neighbor 198.51.100.1 description ISP-B backup-for-this-router
This is blunt but clear: all routes learned from ISP-A get a higher local Weight than routes learned from ISP-B. Cisco documents that Weight can be changed per peer with the weight command or with a route map.[1]
Prefix-specific Weight with a route map
ip prefix-list SaaS-PREFIXES seq 10 permit 203.0.113.0/24
ip prefix-list SaaS-PREFIXES seq 20 permit 198.51.100.0/24
!
route-map WEIGHT-SaaS-VIA-ISP-A permit 10
match ip address prefix-list SaaS-PREFIXES
set weight 700
route-map WEIGHT-SaaS-VIA-ISP-A permit 100
!
router bgp 65010
neighbor 203.0.113.1 route-map WEIGHT-SaaS-VIA-ISP-A in
The final empty permit term is intentional. Without it, many route-map implementations deny routes that do not match earlier permit entries. FRRouting's route-map documentation describes route maps as ordered entries that can apply set actions and notes that the default action is deny if no entry matches.[3]
FRRouting-style note
FRRouting route maps support set actions and include set weight WEIGHT as a route-map action.[3] The syntax may differ from IOS, but the operational idea is the same: apply the policy inbound so the local BGP decision process sees the Weight before choosing the best path.
ip prefix-list SaaS seq 10 permit 203.0.113.0/24
!
route-map FROM-ISP-A permit 10
match ip address prefix-list SaaS
set weight 700
route-map FROM-ISP-A permit 100
!
router bgp 65010
neighbor 203.0.113.1 remote-as 64501
neighbor 203.0.113.1 route-map FROM-ISP-A in
Walkthrough: Weight beats LOCAL_PREF
Imagine Edge-1 has two paths to 203.0.113.0/24:
| Path | Weight | LOCAL_PREF | AS_PATH | Expected result |
|---|---|---|---|---|
| Via ISP-A | 500 | 100 | 64501 64496 | Best |
| Via ISP-B | 0 | 200 | 64502 64496 | Not best |
Engineers sometimes expect the ISP-B path to win because LOCAL_PREF 200 is higher than 100. On Cisco-style logic, the comparison stops earlier: Weight 500 beats Weight 0 before LOCAL_PREF is considered.[2]
Verification commands
Cisco IOS / IOS XE / NX-OS style
show ip bgp 203.0.113.0/24
show bgp ipv4 unicast 203.0.113.0/24
show ip bgp neighbors 203.0.113.1 received-routes
show ip route 203.0.113.0
show run | section router bgp
Expected logic:
- The selected BGP path should have the
>best marker. - The preferred path should show the higher Weight value.
- If the RIB does not install the BGP best path, check administrative distance, recursive next-hop resolution and competing static/IGP routes.
- If a route map was changed, use a soft inbound refresh where supported:
clear ip bgp 203.0.113.1 soft in.
FRRouting style
show bgp ipv4 unicast 203.0.113.0/24
show bgp ipv4 unicast neighbors 203.0.113.1 routes
show route-map FROM-ISP-A
show running-config bgpd
Expected logic is the same: confirm that the intended prefix matched the route map, that the route remains permitted, and that the selected best path matches the higher local Weight.
Troubleshooting checklist
- Wrong path still wins: check whether the higher Weight was applied inbound to the correct neighbor and address family.
- Route disappeared: check for a route-map permit problem; unmatched routes may be denied depending on platform behavior.
- Only one router changed behavior: that is normal for Weight. Use LOCAL_PREF for AS-wide policy.
- Locally redistributed route stays best after failback: look for Weight 32768 on locally originated or redistributed routes, a failure scenario Cisco specifically documents around BGP Weight behavior.[1]
- Policy appears correct but route is invalid: verify NEXT_HOP reachability and whether inbound policy rejected the route before best-path selection.[2]
- Unexpected inbound traffic: remember that Weight is not sent to the upstream provider. Troubleshoot upstream policy, AS_PATH, MED, provider communities and prefix advertisement instead.
Modern usage: data center, cloud edge and fabrics
In a data center EVPN/VXLAN or leaf-spine fabric, prefer standards-based and platform-supported policy that is consistent across the fabric. Weight can be useful in a lab, a single border leaf, or a migration exception, but it is usually a poor primary design tool for multi-device fabrics because it does not propagate.
At a cloud or colocation edge, Weight can be useful for a single router choosing between direct connect, transit and backup Internet paths. If the decision must be consistent across two edge routers or visible to route reflectors, LOCAL_PREF is normally cleaner.
Common interview answer
Question: What is BGP Weight and when would you use it?
Answer: Weight is a local Cisco-style BGP path-selection value. Higher Weight is preferred and it is checked before LOCAL_PREF in Cisco's best-path order. It affects only the router where it is configured, so I use it for a single-router outbound preference or a temporary migration override. If I need the whole AS to prefer one exit, I use LOCAL_PREF instead. If I need to influence inbound traffic, Weight is the wrong tool.
Related reading
- BGP attribute AS_PATH
- BGP LOCAL_PREF Explained: Outbound Traffic Control, Policy and Troubleshooting
- BGP MED Explained: Inbound Traffic Influence, Limits and Troubleshooting
- BGP Table Watch
Summary
BGP Weight is simple but sharp. It is excellent when one Cisco-style router needs to prefer one outbound path, and dangerous when engineers forget that it overrides LOCAL_PREF locally, does not propagate, and says nothing to upstream networks. For stable designs, document every Weight exception and prefer LOCAL_PREF for AS-wide outbound policy.
Post a Comment