How to configure BGP Weight

Contents

Intro

In this tutorial I’ll show you how to configure BGP weight. The weight attribute is a Cisco-specific parameter. It is local to the router you configure it on and doesn’t get sent to any peers. It’s the first attribute BGP looks at in the best path selection algorithm. The default weight for locally originated prefixes is 32,768 and for learned prefixes it’s 0. The higher weight value is preferred. Weight is best used when you want to influence outbound path selection on a single router while not influencing any other BGP routers. I’ll show you how to configure BGP weight on R1 to influence outbound traffic. 

Topology

Topology diagram for BGP weight attribute tutorial showing three routers R1 in AS1, R2 in AS2, and R3 in AS3.
The last octet is the router number unless specified otherwise. Example: R1's G0/1 is 10.10.13.1/24. Don't forget to download the EVE-NG topology file for this tutorial below.

Initial Configs

Configuration Steps

1. Setup BGP peerings between the routers and advertise R3's Lo3 prefix into BGP.

I’ll start by getting all of the BGP peerings up using their respective AS numbers and R2’s Lo2 prefix advertised into BGP.

R1:

router bgp 1
 neighbor 10.10.12.2 remote-as 2
 neighbor 10.10.13.3 remote-as 3

R2:

router bgp 2
 neighbor 10.10.12.1 remote-as 1
 neighbor 10.10.23.3 remote-as 3

R3:

router bgp 3
 neighbor 10.10.13.1 remote-as 1
 neighbor 10.10.23.2 remote-as 2
 network 3.3.3.3 mask 255.255.255.255

All of the BGP peerings should be up and the 3.3.3.3/32 prefix should be in the BGP tables on all routers. Let’s check. 

R1:

R1#show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.12.2      4            2       8       8        2    0    0 00:04:54        1
10.10.13.3      4            3       8       8        2    0    0 00:04:39        1

R1 has both peerings up and is learning 1 prefix from each neighbor.

R2:

R2#show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.12.1      4            1       8       8        2    0    0 00:04:54        1
10.10.23.3      4            3       8       8        2    0    0 00:04:38        1

Same thing for R2. It’s peering with R1 and R3 are up and 1 prefix is being received from each neighbor.

R3:

R3#show ip bgp summary | begin Neighbor
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.13.1      4            1       8       8        2    0    0 00:04:39        0
10.10.23.2      4            2       8       8        2    0    0 00:04:38        0

Lastly, R3’s peerings with R1 and R2 are up and no prefixes are being received. This is the expected behavior. Let’s check the BGP table of R1. 

R1:

R1#show ip bgp
BGP table version is 2, local router ID is 10.10.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *    3.3.3.3/32       10.10.12.2                             0 2 3 i
 *>                    10.10.13.3               0             0 3 i

R1 is learning the 3.3.3.3/32 prefix from R2 and from R3. It selected the path via R3 as best because it has the shortest AS-Path. The BGP best path selection algorithm will prefer the path with the highest weight first, in this case the weights have an identical value of 0. The next step is to prefer the path with the highest Local Preference. The local preference is identical as well with a default value of 100. After that BGP will prefer the path that was locally originated with the network command, aggregation or redistribution, this is a tie as well since the network command was used. The next attribute looked at is the AS Path. BGP prefers the path with the shortest AS_PATH. That’s where the tie breaker is. The path directly to R3 in AS3 is shorter than the path through R2 in AS2, then R3 in AS3. 

We can change this behavior by manuipulating the Weight. I’ll set a higher wieight on prefixes received from R2. I can use any value as long as it’s higher than 0. I’ll set it to 1000 and check R1’s BGP table again. 

2. Configure BGP Weight

R1:

router bgp 1
 neighbor 10.10.12.2 weight 1000

All prefixes R1 receives from R2 will have a weight value of 1000. This will make R1 prefer the path through R2 for the 3.3.3.3/32 prefix. 

Don't forget to do a clear ip bgp * soft to speed things up. 
R1#show ip bgp      
BGP table version is 5, local router ID is 10.10.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *    3.3.3.3/32       10.10.13.3               0             0 3 i
 *>                    10.10.12.2                          1000 2 3 i

When I check the BGP table again I can see that the path via R2 is now the best path because it has a higher weight.

Configuring weight at the neighbor level works great but it affects all prefixes learned from that neighbor. If I’m receiving more than one prefix I might want to have more control on exactly what prefixes have a higher weight, I can do that by using a prefix-list and a route-map. I’ll show you that now. Let me remove the current weight configuration and after that I’ll create an additional Loopback on R3 and advertise it into BGP. 

R1:

router bgp 1
 no neighbor 10.10.12.2 weight 1000

R3:

interface Loopback4
 ip address 4.4.4.4 255.255.255.255

router bgp 3
 network 4.4.4.4 mask 255.255.255.255

R1:

R1#sh ip bgp
BGP table version is 7, local router ID is 10.10.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   3.3.3.3/32       10.10.13.3               0             0 3 i
 *                     10.10.12.2                             0 2 3 i
 *    4.4.4.4/32       10.10.12.2                             0 2 3 i
 *>                    10.10.13.3               0             0 3 i

After I removed the weight command I created a new Loopback 4 interface on R3. I assigned it an IP of 4.4.4.4/32 and advertised this into BGP. 

When I check the BGP table of R1, I can see both prefixes being learned from R2 and R3 and the path via R3 is preferred because of the short AS-PATH. What I’ll do now is set the weight in such a way so R1 prefers the path via R2 to reach 4.4.4.4/32. If R1 wants to go directly to R3 to reach 3.3.3.3/32 thats fine. 

R1:

ip prefix-list R3-LO4 per 4.4.4.4/32

I created a prefix-list named R3-LO4 which matches R3’s Lo4 prefix. 

R1:

route-map FROM-R2 permit 10
 match ip address prefix-list R3-LO4
 set weight 1000
route-map FROM-R2 permit 20

Then I created a route-map that will set the weight to 1000 if a a BGP update comes in and the prefix matches the prefix-list. If it doesn’t match the prefix-list then it will be allowed and no weight will be set. 

R1:

router bgp 1
 neighbor 10.10.12.2 route-map FROM-R2 in

Lastly, I applied the route-map on R1 to it’s neighbor R2. I set the route-map in the inbound direction. I want to apply this policy for prefixes received inbound from R2. Now I’ll check the BGP table on R1 to see if anything changed. 

R1:

R1#show ip bgp
BGP table version is 8, local router ID is 10.10.13.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, 
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, 
              x best-external, a additional-path, c RIB-compressed, 
              t secondary path, 
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>   3.3.3.3/32       10.10.13.3               0             0 3 i
 *                     10.10.12.2                             0 2 3 i
 *>   4.4.4.4/32       10.10.12.2                          1000 2 3 i
 *                     10.10.13.3               0             0 3 i

The route-map worked. The weight value of 1000 was set on the 4.4.4.4/32 prefix only, as it was received from R2. You can see the best path to that network is via R2 which is what we want. The other prefix 3.3.3.3/32 was unaffected. It still prefers the path directly to R3 because of the short AS-Path. That’s all there is to it. I hope you found this tutorial helpful. Be sure to lab it out in EVE-NG using the topology file below. If you have any questions please let me know. 

EVE-NG Lab File

To download the EVE-NG topology file you'll need to be a member. You can register here. It will be right here once you log in.

Full Configs

Here are the full configs from all routers if you want to try it out yourself.

Discussion

You'll need to be a member if you want to participate in the discussion. You can register right here. The discussion will be visible here once you log in.