BGP WEIGHT Attribute

What WEIGHT Is

WEIGHT is a Cisco-proprietary parameter that ranks paths inside a single router only. Unlike LOCAL_PREF and MULTI_EXIT_DISC, covered in BGP Path Attributes and Best Path Selection, it is not a BGP path attribute defined by any RFC. There is no place for it in an UPDATE message, and it never reaches the neighboring router.

Item	Description
Type code	None (it is not a BGP path attribute)
Classification	A Cisco-proprietary local value
Value	A 16-bit unsigned integer (0-65535). Higher is preferred
Default	`0` for a received path, `32768` for a locally originated one
Scope	The local router only. It is never advertised
Definition	Understand the Importance of BGP Weight Path Attribute (Cisco)

Higher being preferred is the same direction as LOCAL_PREF and the opposite of MED. IOS XR shows it in the Weight column of show bgp.

It Is Never Advertised

Because WEIGHT is not a BGP path attribute, there is nowhere to put it in an UPDATE message. That holds whether the neighbor is an iBGP peer or an eBGP peer: the value never leaves the router it was configured on.

That makes WEIGHT the tool for “I want to change where this one router sends traffic, and only this router.” To line up the exit point across the whole AS, use LOCAL_PREF instead.

The Default Is 0, and 32768 for Locally Originated Paths

WEIGHT has two defaults.

Path	Default `WEIGHT`
Received from a BGP peer	`0`
Locally originated (a `network` statement, `redistribute`, aggregation)	`32768`

32768 is exactly the midpoint of the 16-bit range (0-65535). A locally originated path gets a value overwhelmingly larger than any received path, so when the same prefix is both originated locally and received from a peer, the local one wins unless you do something about it.

Best path selection has “prefer the locally originated path” as its third step, but WEIGHT is the first, so the decision is already made at 32768 before the third step is ever reached. The lab section below confirms this on a real device.

Where WEIGHT Sits in Best Path Selection

WEIGHT is the first step of best path selection - the very first thing that is looked at.

Rank	Condition
1	Highest `WEIGHT`
2	Highest `LOCAL_PREF`
3	Locally originated
4	Shortest `AS_PATH`
5	Lowest `ORIGIN` (IGP < EGP < incomplete)
6	Lowest MED
7	eBGP over iBGP
…	…

Sitting at the top means that once you create a difference in WEIGHT, nothing below it is examined at all. It does not matter how long the AS_PATH is or how large the MED is. That power is also the risk: when you use it, scope it to the prefixes you actually mean.

WEIGHT Compared with LOCAL_PREF

WEIGHT and LOCAL_PREF look similar - both prefer the higher value, and both decide the exit point out of the local AS. The difference is how far they reach.

Item	`WEIGHT`	`LOCAL_PREF`
A BGP path attribute?	No (Cisco proprietary)	Yes (well-known discretionary, Type 5)
Carried in advertisements?	No	To iBGP peers yes (to eBGP peers no)
Scope	The single router it is set on	The whole AS
Best path selection rank	1st	2nd
Default	0, or 32768 when locally originated	100

Use LOCAL_PREF to line up the exit across every router in the AS; use WEIGHT for “this router only” or “just switch this box for now.” Because WEIGHT does not reach the other routers in the AS, be aware that routers inside the AS can disagree about the best path and form a loop.

Configuration

IOS XR offers two ways to set it.

Per neighbor (the same value for every path received from that peer)

router bgp 65001
 neighbor 10.1.4.4
  address-family ipv4 unicast
   weight 200

Route policy (a different value for selected prefixes)

route-policy SET-WEIGHT
  if destination in (192.168.5.0/24) then
    set weight 200
  endif
  pass
end-policy
!
router bgp 65001
 neighbor 10.1.4.4
  address-family ipv4 unicast
   route-policy SET-WEIGHT in

When it is set per neighbor, show bgp neighbor reports Default weight 200.

Verification on Real Devices

A lab of six XRd routers (IOS XR 26.1.1) walks through how WEIGHT behaves in eight STEPs. The topology is the same one used for the MED verification.

The WEIGHT verification lab topology. R1 and R2 in AS 65001 peer eBGP with R4 in AS 65002, and R4 also peers with R5 in AS 65003. R5 peers with R6 in AS 65004, and R6 also peers with R1. R1 learns 192.168.5.0/24 over three paths: via R4, via R6, and via R2

AS	Router	Role
65001	R1, R2	AS border routers. iBGP full mesh with R3 over Loopback0 (`next-hop-self`) plus OSPF area 0
65001	R3	Internal. No eBGP peers
65002	R4	eBGP with R1, R2 and R5
65003	R5	eBGP with R4 and R6. Advertises `192.168.5.0/24`
65004	R6	eBGP with R5 and R1. Advertises `192.168.6.0/24`

STEPs 0 through 3 watch 192.168.5.0/24 as seen from R1. R1 receives that prefix from three directions, and all three have an AS_PATH of length 2.

From R4 (65002 65003)
From R6 (65004 65003)
From R2 over iBGP (65002 65003)

STEPs 4 through 7 switch to 192.168.6.0/24 as seen from R1. R1 starts originating that prefix itself, alongside the copy it receives from R6, so we can watch what the locally originated 32768 does.

STEP	Change	What to look for
0	No policy	Every path has `Weight 0`. Only the locally originated `192.168.1.0/24` has `32768`
1	`weight 200` toward R4 on R1	R1’s best path moves to R4. R3 is unaffected (router-local)
2	`LOCAL_PREF 200` inbound from R6 on R1	`WEIGHT` still wins over the preferred `LOCAL_PREF`
3	Remove `weight 200`	Only now does `LOCAL_PREF` take effect
4	Add a static plus `network` for `192.168.6.0/24` on R1	The locally originated `32768` beats the received path
5	Attach `set weight 0` to the `network` statement	Lowering `WEIGHT` still leaves the local path as best
6	`weight 40000` toward R6 on R1	The path via R6 wins, leaving the local path “floating”
7	Shut down R6’s `Loopback1` (final state)	The local path surfaces and becomes best again

STEP 0: Initial State

R1’s BGP table. Watch the Weight column.

R1: show bgp (STEP 0)
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0/24     0.0.0.0                  0         32768 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i
*>i192.168.3.0/24     10.0.0.3                 0    100      0 i
* i192.168.4.0/24     10.0.0.2                 0    100      0 65002 i
*>                    10.1.4.4                 0             0 65002 i
*                     10.1.6.6                               0 65004 65003 65002 i
* i192.168.5.0/24     10.0.0.2                      100      0 65002 65003 i
*                     10.1.4.4                               0 65002 65003 i
*>                    10.1.6.6                               0 65004 65003 i
*> 192.168.6.0/24     10.1.6.6                 0             0 65004 i

Processed 6 prefixes, 10 paths

Only 192.168.1.0/24, which R1 advertises from its own Loopback1 with a network statement, has 32768; every path received from a BGP peer has 0. Every prefix with more than one path is tied at 0, so best path selection does not settle at step 1 and falls through to the conditions below it.

192.168.5.0/24 has three paths and the one via R6 (10.1.6.6) is best. That outcome comes from a lower-ranked condition unrelated to WEIGHT, so we do not chase it here. The following STEPs move this path using nothing but WEIGHT.

STEP 1: Set `weight 200` Toward R4 on R1

On R1, give every path received from R4 (10.1.4.4) a WEIGHT of 200.

router bgp 65001
 neighbor 10.1.4.4
  address-family ipv4 unicast
   weight 200

R1: show bgp (STEP 1)
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.1.0/24     0.0.0.0                  0         32768 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i
*>i192.168.3.0/24     10.0.0.3                 0    100      0 i
* i192.168.4.0/24     10.0.0.2                 0    100      0 65002 i
*>                    10.1.4.4                 0           200 65002 i
*                     10.1.6.6                               0 65004 65003 65002 i
* i192.168.5.0/24     10.0.0.2                      100      0 65002 65003 i
*>                    10.1.4.4                             200 65002 65003 i
*                     10.1.6.6                               0 65004 65003 i
*> 192.168.6.0/24     10.1.6.6                 0             0 65004 i

Processed 6 prefixes, 10 paths

192.168.4.0/24 and 192.168.5.0/24, both received from R4, now carry a WEIGHT of 200, and the best path for 192.168.5.0/24 has moved from R6 to R4. Neither the AS_PATH length nor the LOCAL_PREF was touched. The decision was made at step 1, so nothing below it was consulted.

Putting routes (after the inbound policy) next to received routes (the raw paths before it) shows that WEIGHT is applied on receipt.

R1: show bgp neighbors 10.1.4.4 routes (after the policy)
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*> 192.168.4.0/24     10.1.4.4                 0           200 65002 i
*> 192.168.5.0/24     10.1.4.4                             200 65002 65003 i

Processed 2 prefixes, 2 paths

R1: show bgp neighbors 10.1.4.4 received routes (before the policy)
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*  192.168.4.0/24     10.1.4.4                 0             0 65002 i
*  192.168.5.0/24     10.1.4.4                               0 65002 65003 i

Processed 2 prefixes, 2 paths

The same paths are 0 as received and 200 by the time they enter R1’s BGP table.

Nothing Changed from R3’s Point of View

Here is the BGP table on R3, which sits in the same AS as R1.

R3: show bgp (STEP 1)
Status codes: s suppressed, d damped, h history, * valid, > best
              i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network            Next Hop            Metric LocPrf Weight Path
*>i192.168.1.0/24     10.0.0.1                 0    100      0 i
*>i192.168.2.0/24     10.0.0.2                 0    100      0 i
*> 192.168.3.0/24     0.0.0.0                  0         32768 i
*>i192.168.4.0/24     10.0.0.1                 0    100      0 65002 i
* i                   10.0.0.2                 0    100      0 65002 i
*>i192.168.5.0/24     10.0.0.1                      100      0 65002 65003 i
* i                   10.0.0.2                      100      0 65002 65003 i
*>i192.168.6.0/24     10.0.0.1                 0    100      0 65004 i

Processed 6 prefixes, 8 paths

For R3, 192.168.5.0/24 still has a WEIGHT of 0. The 200 that R1 applied never reached R3, because WEIGHT is a value that lives inside one router.

The UPDATE Carries No WEIGHT

BGP on the R1-R3 link was captured throughout. When R1’s best path moved to R4 in STEP 1, R1 re-advertised 192.168.5.0/24 to R3. No.111 in the attached capture is that UPDATE (a single TCP segment carries two UPDATEs; the one below is for 192.168.5.0/24).

No.111 R1 to R3 (iBGP), tshark -V
Border Gateway Protocol - UPDATE Message
    Marker: ffffffffffffffffffffffffffffffff
    Length: 64
    Type: UPDATE Message (2)
    Withdrawn Routes Length: 0
    Total Path Attribute Length: 41
    Path attributes
        Path Attribute - MP_REACH_NLRI
            Flags: 0x90, Optional, Extended-Length, Non-transitive, Complete
<snip>
            Type Code: MP_REACH_NLRI (14)
            Length: 13
            Address family identifier (AFI): IPv4 (1)
            Subsequent address family identifier (SAFI): Unicast (1)
            Next hop: 10.0.0.1
                IPv4 Address: 10.0.0.1
            Number of Subnetwork points of attachment (SNPA): 0
            Network Layer Reachability Information (NLRI)
                192.168.5.0/24
                    MP Reach NLRI prefix length: 24
                    MP Reach NLRI IPv4 prefix: 192.168.5.0
        Path Attribute - ORIGIN: IGP
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: ORIGIN (1)
            Length: 1
            Origin: IGP (0)
        Path Attribute - AS_PATH: 65002 65003 
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: AS_PATH (2)
            Length: 10
            AS Path segment: 65002 65003
                Segment type: AS_SEQUENCE (2)
                Segment length (number of ASN): 2
                AS4: 65002
                AS4: 65003
        Path Attribute - LOCAL_PREF: 100
            Flags: 0x40, Transitive, Well-known, Complete
<snip>
            Type Code: LOCAL_PREF (5)
            Length: 4
            Local preference: 100

The only path attributes present are MP_REACH_NLRI, ORIGIN, AS_PATH and LOCAL_PREF - nothing corresponds to WEIGHT. The 200 that R1 applied exists only inside R1’s BGP table, so there is simply nowhere in the UPDATE to put it.

Download the pcap of the packet in the tshark output above (No.111 UPDATE)

STEP 2: WEIGHT Beats a LOCAL_PREF of 200

On R1, apply LOCAL_PREF 200 to the 192.168.5.0/24 received from R6 (10.1.6.6) - a configuration that favors the path via R6.

route-policy LP-200
  if destination in (192.168.5.0/24) then
    set local-preference 200
  endif
  pass
end-policy
!
router bgp 65001
 neighbor 10.1.6.6
  address-family ipv4 unicast
   route-policy LP-200 in

R1: show bgp 192.168.5.0/24 (STEP 2)
RP/0/RP0/CPU0:R1#show bgp 192.168.5.0/24

Tue Sep  8 10:24:35.554 UTC
BGP routing table entry for 192.168.5.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 11           11
Last Modified: Sep  8 10:24:08.774 for 00:00:26
Paths: (5 available, best #2)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  Path #1: Received by speaker 0
  Not advertised to any peer
  65002 65003, (received & used)
    10.0.0.2 (metric 3) from 10.0.0.2 (10.0.0.2)
      Origin IGP, localpref 100, valid, internal
      Received Path ID 0, Local Path ID 0, version 0
  Path #2: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  65002 65003
    10.1.4.4 from 10.1.4.4 (10.0.0.4)
      Origin IGP, localpref 100, weight 200, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 10
      Origin-AS validity: (disabled)
  Path #3: Received by speaker 0
  Not advertised to any peer
  65002 65003, (received-only)
    10.1.4.4 from 10.1.4.4 (10.0.0.4)
      Origin IGP, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #4: Received by speaker 0
  Not advertised to any peer
  65004 65003
    10.1.6.6 from 10.1.6.6 (10.0.0.6)
      Origin IGP, localpref 200, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #5: Received by speaker 0
  Not advertised to any peer
  65004 65003, (received-only)
    10.1.6.6 from 10.1.6.6 (10.0.0.6)
      Origin IGP, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

Path #4 is the one via R6 with localpref 200; Path #2 is the one via R4 with localpref 100, weight 200. Path #2 is still best, and the path via R6 that LOCAL_PREF was supposed to favor is not chosen. The decision was made at step 1 (WEIGHT), so step 2 (LOCAL_PREF) was never examined.

Paths #3 and #5, marked (received-only), are the pre-inbound-policy copies kept by soft-reconfiguration inbound always; they do not take part in best path selection.

STEP 3: Remove WEIGHT and LOCAL_PREF Takes Over

Remove only weight 200, leaving the LOCAL_PREF 200 policy in place.

router bgp 65001
 neighbor 10.1.4.4
  address-family ipv4 unicast
   no weight 200

R1: show bgp 192.168.5.0/24 (STEP 3)
RP/0/RP0/CPU0:R1#show bgp 192.168.5.0/24

Tue Sep  8 10:28:08.555 UTC
BGP routing table entry for 192.168.5.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 13           13
Last Modified: Sep  8 10:27:04.774 for 00:01:03
Paths: (3 available, best #2)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  Path #1: Received by speaker 0
  Not advertised to any peer
  65002 65003, (received & used)
    10.1.4.4 from 10.1.4.4 (10.0.0.4)
      Origin IGP, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)
  Path #2: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  65004 65003
    10.1.6.6 from 10.1.6.6 (10.0.0.6)
      Origin IGP, localpref 200, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 13
      Origin-AS validity: (disabled)
  Path #3: Received by speaker 0
  Not advertised to any peer
  65004 65003, (received-only)
    10.1.6.6 from 10.1.6.6 (10.0.0.6)
      Origin IGP, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

The best path moves to R6 (Path #2), and the output shows localpref 200 as the reason. This confirms the ordering: LOCAL_PREF at step 2 was only evaluated once WEIGHT was out of the way.

STEP 4: Originate `192.168.6.0/24` on R1 as Well

From here the subject is 192.168.6.0/24. R1 starts originating the prefix that R6 advertises, using a static route to Null0 plus a network statement. Holding the same prefix locally as a fallback for when R6 goes away is a common arrangement.

router static
 address-family ipv4 unicast
  192.168.6.0/24 Null0
 !
!
router bgp 65001
 address-family ipv4 unicast
  network 192.168.6.0/24

R1: show bgp 192.168.6.0/24 (STEP 4)
RP/0/RP0/CPU0:R1#show bgp 192.168.6.0/24

Tue Sep  8 10:31:04.448 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 14           14
Last Modified: Sep  8 10:30:36.774 for 00:00:27
Paths: (2 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  Local
    0.0.0.0 from 0.0.0.0 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, weight 32768, valid, local, best, group-best
      Received Path ID 0, Local Path ID 1, version 14
  Path #2: Received by speaker 0
  Not advertised to any peer
  65004, (received & used)
    10.1.6.6 from 10.1.6.6 (10.0.0.6)
      Origin IGP, metric 0, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

The locally originated Path #1 is best with weight 32768. Path #2, received from R6, has a WEIGHT of 0 and loses at step 1. Best path selection does have “locally originated” as its third condition, but WEIGHT decides before it is ever reached.

What R1 advertises outward changes as well.

R1: show bgp neighbors 10.1.4.4 advertised-routes (STEP 4)
RP/0/RP0/CPU0:R1#show bgp neighbors 10.1.4.4 advertised-routes

Tue Sep  8 10:31:07.589 UTC
Network            Next Hop        From            AS Path
192.168.1.0/24     10.1.4.1        Local           65001i
192.168.2.0/24     10.1.4.1        10.0.0.2        65001i
192.168.3.0/24     10.1.4.1        10.0.0.3        65001i
192.168.4.0/24     10.1.4.1        10.1.4.4        65001 65002i
192.168.5.0/24     10.1.4.1        10.1.6.6        65001 65004 65003i
192.168.6.0/24     10.1.4.1        Local           65001i

Processed 6 prefixes, 6 paths

192.168.6.0/24 now shows Local in the From column and an AS_PATH of 65001. Through STEP 3 it relayed the path received from 10.1.6.6, so the AS_PATH read 65001 65004.

The RIB, however, needs a caveat.

R1: show route (STEP 4)
RP/0/RP0/CPU0:R1#show route

Tue Sep  8 10:31:02.368 UTC

Codes: C - connected, S - static, R - RIP, B - BGP, (>) - Diversion path
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
       U - per-user static route, o - ODR, L - local, G  - DAGR, l - LISP
       A - access/subscriber, a - Application route
       M - mobile route, r - RPL, t - Traffic Engineering, (!) - FRR Backup path
       s - local SRv6 route, z - local IID route

Gateway of last resort is not set

L    10.0.0.1/32 is directly connected, 00:18:58, Loopback0
O    10.0.0.2/32 [110/3] via 10.1.3.3, 00:18:18, GigabitEthernet0/0/0/0
O    10.0.0.3/32 [110/2] via 10.1.3.3, 00:18:24, GigabitEthernet0/0/0/0
C    10.1.3.0/24 is directly connected, 00:18:52, GigabitEthernet0/0/0/0
L    10.1.3.1/32 is directly connected, 00:18:52, GigabitEthernet0/0/0/0
C    10.1.4.0/24 is directly connected, 00:18:52, GigabitEthernet0/0/0/1
L    10.1.4.1/32 is directly connected, 00:18:52, GigabitEthernet0/0/0/1
C    10.1.6.0/24 is directly connected, 00:18:52, GigabitEthernet0/0/0/2
L    10.1.6.1/32 is directly connected, 00:18:52, GigabitEthernet0/0/0/2
O    10.2.3.0/24 [110/2] via 10.1.3.3, 00:18:24, GigabitEthernet0/0/0/0
O    10.2.4.0/24 [110/3] via 10.1.3.3, 00:18:18, GigabitEthernet0/0/0/0
C    192.168.1.0/24 is directly connected, 00:18:58, Loopback1
L    192.168.1.1/32 is directly connected, 00:18:58, Loopback1
B    192.168.2.0/24 [200/0] via 10.0.0.2, 00:16:58
B    192.168.3.0/24 [200/0] via 10.0.0.3, 00:16:58
B    192.168.4.0/24 [20/0] via 10.1.4.4, 00:03:58
B    192.168.5.0/24 [20/0] via 10.1.6.6, 00:03:58
S    192.168.6.0/24 is directly connected, 00:00:27, Null0

The static route’s administrative distance (1) is lower than that of an external BGP route (20), so the RIB keeps the S (static) entry pointing at Null0. R1 itself cannot forward traffic destined for 192.168.6.0/24 in this arrangement. The static is an anchor route whose purpose is purely to let the advertisement exist, and what “floats” in the STEPs that follow is the BGP table and the advertisement, which is worth keeping in mind.

STEP 5: Try Lowering the Locally Originated WEIGHT to 0

If weakening the locally originated path lets the one received from R6 win - that is the idea to test. Attach a route policy to the network statement that applies set weight 0.

route-policy SET-WEIGHT-0
  set weight 0
  pass
end-policy
!
router bgp 65001
 address-family ipv4 unicast
  network 192.168.6.0/24 route-policy SET-WEIGHT-0

R1: show bgp 192.168.6.0/24 (STEP 5)
RP/0/RP0/CPU0:R1#show bgp 192.168.6.0/24

Tue Sep  8 10:33:51.523 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 15           15
Last Modified: Sep  8 10:33:17.774 for 00:00:33
Paths: (2 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  Local
    0.0.0.0 from 0.0.0.0 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, local, best, group-best
      Received Path ID 0, Local Path ID 1, version 15
  Path #2: Received by speaker 0
  Not advertised to any peer
  65004, (received & used)
    10.1.6.6 from 10.1.6.6 (10.0.0.6)
      Origin IGP, metric 0, localpref 100, valid, external, group-best
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

The WEIGHT did drop - weight 32768 is gone from Path #1’s line. But Path #1 is still best.

That is because both conditions after the WEIGHT tie favor the locally originated path: step 3 (“locally originated”) and step 4 (“shortest AS_PATH”, where the local path has length 0 against 65004 at length 1). Since 0 is the floor for WEIGHT, there is no way to push the locally originated path any lower. To have the received path chosen, the received side’s WEIGHT has to be lifted above 32768 instead.

STEP 6: Set `weight 40000` Toward R6

Lift the received side. Set a WEIGHT of 40000 (larger than 32768) on R1’s neighbor toward R6.

router bgp 65001
 neighbor 10.1.6.6
  address-family ipv4 unicast
   weight 40000

R1: show bgp 192.168.6.0/24 (STEP 6)
RP/0/RP0/CPU0:R1#show bgp 192.168.6.0/24

Tue Sep  8 10:37:03.692 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 18           18
Last Modified: Sep  8 10:36:36.774 for 00:00:27
Paths: (3 available, best #2)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    0.0.0.0 from 0.0.0.0 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, local, group-best
      Received Path ID 0, Local Path ID 0, version 0
  Path #2: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  65004
    10.1.6.6 from 10.1.6.6 (10.0.0.6)
      Origin IGP, metric 0, localpref 100, weight 40000, valid, external, best, group-best
      Received Path ID 0, Local Path ID 1, version 18
      Origin-AS validity: (disabled)
  Path #3: Received by speaker 0
  Not advertised to any peer
  65004, (received-only)
    10.1.6.6 from 10.1.6.6 (10.0.0.6)
      Origin IGP, metric 0, localpref 100, valid, external
      Received Path ID 0, Local Path ID 0, version 0
      Origin-AS validity: (disabled)

Path #2, received from R6, is best with weight 40000, and the locally originated Path #1 is now present in the BGP table but not best - floating, in other words.

The advertisement reverts too.

R1: show bgp neighbors 10.1.4.4 advertised-routes (STEP 6)
RP/0/RP0/CPU0:R1#show bgp neighbors 10.1.4.4 advertised-routes

Tue Sep  8 10:37:07.009 UTC
Network            Next Hop        From            AS Path
192.168.1.0/24     10.1.4.1        Local           65001i
192.168.2.0/24     10.1.4.1        10.0.0.2        65001i
192.168.3.0/24     10.1.4.1        10.0.0.3        65001i
192.168.4.0/24     10.1.4.1        10.1.6.6        65001 65004 65003 65002i
192.168.5.0/24     10.1.4.1        10.1.6.6        65001 65004 65003i
192.168.6.0/24     10.1.4.1        10.1.6.6        65001 65004i

Processed 6 prefixes, 6 paths

The AS_PATH for 192.168.6.0/24 is back to 65001 65004, relaying the path via R6.

A per-neighbor WEIGHT applies to every prefix received from that peer, so as a side effect 192.168.4.0/24 and 192.168.5.0/24 have also moved to the path via R6 (65001 65004 65003 ...). To narrow it to specific prefixes, use set weight in an inbound route policy rather than writing weight directly on the neighbor.

STEP 7: Shut Down R6’s Loopback1 (Final State)

Shut down Loopback1 on R6, the original source of 192.168.6.0/24.

interface Loopback1
 shutdown

R1: show bgp 192.168.6.0/24 (STEP 7)
RP/0/RP0/CPU0:R1#show bgp 192.168.6.0/24

Tue Sep  8 10:39:59.616 UTC
BGP routing table entry for 192.168.6.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 19           19
Last Modified: Sep  8 10:39:28.774 for 00:00:30
Paths: (1 available, best #1)
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  Path #1: Received by speaker 0
  Advertised IPv4 Unicast paths to update-groups (with more than one peer):
    0.3 0.4 
  Local
    0.0.0.0 from 0.0.0.0 (10.0.0.1)
      Origin IGP, metric 0, localpref 100, valid, local, best, group-best
      Received Path ID 0, Local Path ID 1, version 19

The path received from R6 is gone, and the locally originated path that remains has surfaced as best.

R1: show bgp neighbors 10.1.4.4 advertised-routes (STEP 7)
RP/0/RP0/CPU0:R1#show bgp neighbors 10.1.4.4 advertised-routes

Tue Sep  8 10:40:02.832 UTC
Network            Next Hop        From            AS Path
192.168.1.0/24     10.1.4.1        Local           65001i
192.168.2.0/24     10.1.4.1        10.0.0.2        65001i
192.168.3.0/24     10.1.4.1        10.0.0.3        65001i
192.168.4.0/24     10.1.4.1        10.1.6.6        65001 65004 65003 65002i
192.168.5.0/24     10.1.4.1        10.1.6.6        65001 65004 65003i
192.168.6.0/24     10.1.4.1        Local           65001i

Processed 6 prefixes, 6 paths

The advertisement is back to Local with an AS_PATH of 65001, so AS 65001 is now originating 192.168.6.0/24 on its own. The path via R6 is used normally, and the local path only appears once R6 goes away - the same idea as a floating static route (raised administrative distance holding a route in reserve), built in BGP with WEIGHT.

As noted above, though, R1’s RIB stays on Null0 in this arrangement. The BGP table and the advertisement switch over, but R1 itself does not forward the traffic. In production this shape is for cases where issuing the advertisement is itself the goal, such as an anchor for an aggregate route.

Verification Configs and show Output

Each STEP was captured from all six routers, split into three files per router. The verification configs are these ..._run.txt files (the final state is the STEP 7 set).

File	Contents
`..._show.txt`	`show version` / `show interface description` / `show route` / `show bgp` / `show bgp neighbors <peer> advertised-routes, routes, received routes` and so on
`..._log.txt`	`show logging` narrowed to that STEP. A `logmsg` marker is written at the start of each STEP and its timestamp is passed to `show logging start`
`..._run.txt`	`show running-config` at that STEP (that is, the verification config for the STEP)

In the final state R1 carries the Null0 static for 192.168.6.0/24, network 192.168.6.0/24 route-policy SET-WEIGHT-0, weight 40000 toward R6, and the LP-200 policy that applies LOCAL_PREF 200 to 192.168.5.0/24. On R6, Loopback1 is shut down.

STEP 0: Initial state

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 1: Set weight 200 toward R4 on R1

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 2: Apply LOCAL_PREF 200 inbound from R6 on R1

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 3: Remove weight 200

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 4: Add a static plus network for 192.168.6.0/24 on R1

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 5: Attach set weight 0 to the network statement

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 6: Set weight 40000 toward R6 on R1

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

STEP 7: Shut down R6’s Loopback1 (final state)

Router	show output	syslog	running-config
R1	show	log	run
R2	show	log	run
R3	show	log	run
R4	show	log	run
R5	show	log	run
R6	show	log	run

The full capture on the R1-R3 link (iBGP).

Download the full capture (bgp-weight.pcap)

References

Source	Title	Summary
Cisco	Understand the Importance of BGP Weight Path Attribute	Explains that WEIGHT is Cisco proprietary and local to the router, defaults to 0, and becomes 32768 for locally originated paths.
Cisco	Select BGP Best-path Algorithm	The 13-step best path algorithm, where WEIGHT can be seen sitting first.
Cisco	Configure and Verify BGP Path Selection in IOS-XR	How to verify best path selection on IOS XR.