BGP Weighted ECMP
This chapter provides information about BGP weighted ECMP.
Topics in this chapter include:
Applicability
The CLI in the latest update is based on SR Linux Release 26.7.1.
Overview
Equal-cost multipath (ECMP) is a routing strategy that allows the installation of multiple next hops for an IP destination in the routing table. When used in conjunction with BGP multipath, the ingress router can forward traffic to an IP prefix destination in a load-balanced fashion across the available ECMP next hops.
In the standard implementation, ECMP distributes traffic as evenly as possible across all the ECMP next hops. Standard ECMP - Equal bandwidth links shows an example scenario where CE-4 is dual-homed to two PE routers and advertises the prefix 10.0.0.0/8. This prefix is then advertised within AS 64496 and received by PE-3, which in turn advertises it to CE-6 in AS 64501. PE-3 has BGP multipath and ECMP enabled, so the traffic toward destinations in 10.0.0.0/8 sent by CE-6 is load-balanced toward PE-1 and PE-2 as evenly as possible.
The behavior of equally distributing across the ECMP next hops may not be suitable under specific circumstances. Consider the same topology with the connection between CE-4 and PE-1 replaced with a 10GE link, while the CE-4 to PE-2 connection still is a 1GE link, as shown in Standard ECMP - Unequal bandwidth links. In standard ECMP operation, when PE-3 sends 50% of traffic to PE-1 and 50% to PE-2, this may result in an under-utilization of the link between CE-4 and PE-1 or an over-utilization of the link between CE-4 and PE-2.
BGP Weighted ECMP, also known as Unequal-Cost Multipath (UCMP), allows for the distribution of traffic in proportion to the relative bandwidth of each equal-cost path. This feature uses a BGP community called the Link Bandwidth Extended Community. Link bandwidth extended community advertisement shows that PE-1 and PE-2, with this functionality, can add a Link Bandwidth Extended Community to the BGP routes advertised toward other routers within AS 64496 that indicates the bandwidth of their PE-CE link.
PE-3 can use the information in the Link Bandwidth Extended Community to distribute the traffic according to the relative bandwidth, or the "weight" of each path. Weighted ECMP - Unequal bandwidth links shows that 91% of traffic is sent toward PE-1 with the 10GE link and 9% is sent toward PE-2 with the 1GE link.
Weighted ECMP - Link aggregation group shows another example where the CE-4-to-PE-1 link is composed of four 1GE links that are part of a Link Aggregation Group (LAG) and the CE-4-to-PE-2 link is 1GE. Weighted ECMP can be used here to achieve an 80% to 20% distribution of traffic sent from PE-3 to PE-1 and PE-2, respectively.
Standard ECMP - Unequal bandwidth links with EBGP shows an example where PE-1 is connected to two EBGP routers in neighbor AS 64500. Using the weighted ECMP functionality, 91% of traffic is sent to CE-4 and 9% to CE-5, according to the relative bandwidth values.
Weighted ECMP - Unequal bandwidth links with IP-VRF shows an example with a Layer 3 IP-VRF service. PE-1 receives prefix 10.0.0.0/8 from CE-4 via EBGP, and also from PE-2 via IBGP. PE-1 sets the Link Bandwidth Extended Community indicating 3GE on the route received from CE-4. PE-2 sets the community value indicating 1GE on the route it advertises to PE-1. With combined ECMP within the IP-VRF, PE-1 can send 75% of traffic on the direct LAG link to CE-4 and 25% to PE-2, which then forwards that traffic to CE-4.
Link Bandwidth Extended Community is defined in RFC 10005 and has the following characteristics:
Signals the link bandwidth of a BGP path
Has the following format: bandwidth:<as-number>:<value>
bandwidth is the community type
<as-number> is the local AS number
<value> is a fixed/static bandwidth in Mb/s (converted to IEEE floating point format in a BGP Update message)
-
Optional attribute.
-
By default non-transitive attribute (not sent to other EBGP peers upon receipt), but the transitive true option allows the community to cross an AS boundary.
If a node changes the route next hop, it does not propagate the Link Bandwidth Extended Community
A route can only have a single Link Bandwidth Extended Community
SR Linux routers automatically perform weighted load balancing if all the BGP updates received for a destination contain the Link Bandwidth Extended Community (when ECMP and BGP multipath are enabled)
Link Bandwidth Extended Community can be added to a BGP route with the following methods:
link-bandwidth command
routing policy action in an import or export policy
The link-bandwidth command has the following characteristics:
Configurable per AFI-SAFI per BGP group or BGP neighbor in default network instance or IP-VRF
Adds a Link Bandwidth Extended Community to the routes (of the AFI-SAFIs that have link-bandwidth enabled) received from directly connected EBGP peers
Bandwidth value is based on the speed of port or active LAG members
Bandwidth is automatically adjusted for LAG interfaces based on the number of active LAG member ports
If BGP multipath and ECMP are configured and all the eligible multipaths have a Link Bandwidth Extended Community, then weighted ECMP is performed on the relative bandwidth of each path.
Configuration
The following configuration examples for BGP weighted ECMP are covered in this chapter:
Example topology - BGP Weighted ECMP for IPv4 family shows the example topology for BGP Weighted ECMP for IPv4 family with the following characteristics:
CE-4 in AS 64500 advertises both prefixes 10.1.2.3/32 and 10.2.4.6/32 to its EBGP peers PE-1 and PE-2 in AS 64496. The export policy on CE-4 adds standard community 4:0.
RR-5 is route reflector for all PEs in AS 64496.
add-paths is configured on all PE routers and RR-5 with a send limit of 2.
CE-6 in AS 64501 advertises both prefixes 10.3.4.5/32 and 10.4.6.8/32 to its EBGP peer PE-3 in AS 64496. The export policy on CE-6 adds standard community 6:0.
Initial configuration
The initial configuration on all nodes includes:
-
Interfaces and subinterfaces
LAG configured for the link between CE-4 and PE-1 with two member links
-
Default network instance interfaces
IS-IS as IGP on all interfaces within AS 64496 (alternatively, OSPF can be used)
BGP is configured on all the nodes. CE-4 peers with PE-1 and PE-2 and exports the 10.1.2.3/32 and 10.2.4.6/32 loopback prefixes to both EBGP peers, as follows:
# on CE-4:
routing-policy {
community-set cs-4-0 {
member [
4:0
]
}
community-set cs-6-0 {
member [
6:0
]
}
prefix-set ps-10.0.0.0 {
prefix 10.0.0.0/8 mask-length-range 32..32 {
}
}
policy rp-export-4-0 {
statement stmt-10 {
match {
prefix {
prefix-set ps-10.0.0.0
}
}
action {
policy-result accept
bgp {
communities {
add cs-4-0
}
}
}
}
}
policy rp-import-6-0 {
statement stmt-10 {
match {
bgp {
community-set cs-6-0
}
}
action {
policy-result accept
}
}
}
}
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 64500
router-id 192.0.2.4
afi-safi ipv4-unicast {
admin-state enable
}
group grp-EBGP {
admin-state enable
peer-as 64496
export-policy [
rp-export-4-0
]
import-policy [
rp-import-6-0
]
}
neighbor 172.16.14.1 {
peer-group grp-EBGP
}
neighbor 172.16.24.1 {
peer-group grp-EBGP
}
}
The BGP configuration on CE-6 is similar.
PE-1 peers with CE-4 in AS 65400 and RR-5 in AS 64496. add-paths is enabled for AFI-SAFI ipv4-unicast on the grp-IBGP group to advertise redundant BGP paths to the route reflector. The BGP configuration on PE-1 is as follows:
# on PE-1:
routing-policy {
community-set cs-4-0 {
member [
4:0
]
}
community-set cs-6-0 {
member [
6:0
]
}
policy rp-import-4-0 {
statement stmt-10 {
match {
bgp {
community-set cs-4-0
}
}
action {
policy-result accept
}
}
}
policy rp-export-6-0 {
statement stmt-10 {
match {
bgp {
community-set cs-6-0
}
}
action {
policy-result accept
}
}
}
}
network-instance default {
protocols {
bgp {
admin-state enable
autonomous-system 64496
router-id 192.0.2.1
afi-safi ipv4-unicast {
admin-state enable
}
group grp-EBGP {
admin-state enable
peer-as 64500
export-policy [
rp-export-6-0
]
import-policy [
rp-import-4-0
]
}
group grp-IBGP {
next-hop-self true
peer-as 64496
afi-safi ipv4-unicast {
add-paths {
receive true
send true
send-max 2
}
}
}
neighbor 172.16.14.2 {
peer-group grp-EBGP
}
neighbor 192.0.2.5 {
peer-group grp-IBGP
}
}
The BGP configuration on PE-2 and PE-3 is similar to that on PE-1.
RR-5 acts as a route reflector to all the PEs in AS 64496 with a cluster ID of 192.0.2.5. add-paths is enabled to advertise redundant BGP paths to the PEs. The configuration on RR-5 is as follows:
# on RR-5:
network-instance default {
protocols {
bgp {
admin-state enable
router-id 192.0.2.5
autonomous-system 64496
afi-safi ipv4-unicast {
admin-state enable
}
route-reflector {
client true
cluster-id 192.0.2.5
}
group grp-IBGP {
peer-as 64496
afi-safi ipv4-unicast {
add-paths {
receive true
send true
send-max 2
}
}
}
neighbor 192.0.2.1 {
peer-group grp-IBGP
}
neighbor 192.0.2.2 {
peer-group grp-IBGP
}
neighbor 192.0.2.3 {
peer-group grp-IBGP
}
}
BGP weighted ECMP for IPv4 family using the link-bandwidth command
PE-3 receives the prefixes 10.1.2.3/32 and 10.2.4.6/32 from PE-1 and PE-2 via the route reflector and indicates the ones received from PE-1 as the "used" or active routes, as follows:
A:admin@PE-3# show network-instance default protocols bgp routes ipv4 summary | grep -v 0.0.0.0
------------------------------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
------------------------------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
------------------------------------------------------------------------------------------------------------------------------------
+-------+------------------------------+------------------------------+-------+-------+------------------------------------------+
| Statu | Network | Next Hop | MED | LocPr | Path Val |
| s | | | | ef | |
+=======+==============================+==============================+=======+=======+==========================================+
| u*> | 10.1.2.3/32 | 192.0.2.1 | | 100 | i[64500] |
| * | 10.1.2.3/32 | 192.0.2.2 | | 100 | i[64500] |
| u*> | 10.2.4.6/32 | 192.0.2.1 | | 100 | i[64500] |
| * | 10.2.4.6/32 | 192.0.2.2 | | 100 | i[64500] |
| u*> | 10.3.4.5/32 | 172.16.36.2 | | | i[64501] |
| u*> | 10.4.6.8/32 | 172.16.36.2 | | | i[64501] |
| u*> | 192.0.2.1/32 | 192.168.13.1 | 10 | | i |
| u*> | 192.0.2.2/32 | 192.168.23.1 | 10 | | i |
| u*> | 192.0.2.5/32 | 192.168.13.1 | 20 | | i |
| u*> | 192.168.12.0/30 | 192.168.13.1 | 20 | | i |
| u*> | 192.168.15.0/30 | 192.168.13.1 | 20 | | i |
| u*> | 192.168.25.0/30 | 192.168.23.1 | 20 | | i |
+-------+------------------------------+------------------------------+-------+-------+------------------------------------------+
------------------------------------------------------------------------------------------------------------------------------------
16 received BGP routes: 14 used, 16 valid, 0 stale
14 available destinations: 2 with ECMP multipaths
------------------------------------------------------------------------------------------------------------------------------------
ECMP and BGP multipath are enabled on PE-3 with the following commands. In the following (non-transitive) example, the EBGP multipath configuration is optional, but the IBGP multipath configuration is required.
# on PE-3:
network-instance default {
protocols {
bgp {
afi-safi ipv4-unicast {
multipath {
ebgp {
maximum-paths 2
weighted-ecmp {
admin-state enable
}
}
ibgp {
maximum-paths 2
weighted-ecmp {
admin-state enable
}
}
}
}
}
isis {
instance 0 {
max-ecmp-paths 2
}
}
As a result, PE-3 installs the routes from PE-2 as active, in addition to those from PE-1:
A:admin@PE-3# show network-instance default protocols bgp routes ipv4 summary | grep -v 0.0.0.0
------------------------------------------------------------------------------------------------------------------------------------
Show report for the BGP route table of network-instance "default"
------------------------------------------------------------------------------------------------------------------------------------
Status codes: u=used, *=valid, >=best, x=stale, b=backup, w=unused-weight-only
Origin codes: i=IGP, e=EGP, ?=incomplete
------------------------------------------------------------------------------------------------------------------------------------
+-------+------------------------------+------------------------------+-------+-------+------------------------------------------+
| Statu | Network | Next Hop | MED | LocPr | Path Val |
| s | | | | ef | |
+=======+==============================+==============================+=======+=======+==========================================+
| u*> | 10.1.2.3/32 | 192.0.2.1 | | 100 | i[64500] |
| u*> | 10.1.2.3/32 | 192.0.2.2 | | 100 | i[64500] |
| u*> | 10.2.4.6/32 | 192.0.2.1 | | 100 | i[64500] |
| u*> | 10.2.4.6/32 | 192.0.2.2 | | 100 | i[64500] |
| u*> | 10.3.4.5/32 | 172.16.36.2 | | | i[64501] |
| u*> | 10.4.6.8/32 | 172.16.36.2 | | | i[64501] |
| u*> | 192.0.2.1/32 | 192.168.13.1 | 10 | | i |
| u*> | 192.0.2.2/32 | 192.168.23.1 | 10 | | i |
| u*> | 192.0.2.5/32 | 192.168.13.1 | 20 | | i |
| u*> | 192.168.12.0/30 | 192.168.13.1 | 20 | | i |
| u*> | 192.168.15.0/30 | 192.168.13.1 | 20 | | i |
| u*> | 192.168.25.0/30 | 192.168.23.1 | 20 | | i |
+-------+------------------------------+------------------------------+-------+-------+------------------------------------------+
------------------------------------------------------------------------------------------------------------------------------------
16 received BGP routes: 16 used, 16 valid, 0 stale
16 available destinations: 0 with ECMP multipaths
------------------------------------------------------------------------------------------------------------------------------------
The multiple next hops are also visible in the route table of PE-3:
--{ + running }--[ ]--
A:admin@PE-3# show network-instance default ipv4 route type bgp
========================================================================================
IPv4-unicast route table for default network-instance
----------------------------------------------------------------------------------------
Flags: > (best), * (unviable), ! (failed)
: L (leaked route from another network-instance)
: B (backup NHG active and displayed)
: S (statistics supported)
: D (dynamic LB), R (resilient LB)
----------------------------------------------------------------------------------------
Prefix Route Type Metric Pref Flags Next-Hop(s)
----------------------------------------------------------------------------------------
10.1.2.3/32 bgp 10 170 > 192.0.2.1(route:isis)
192.0.2.2(route:isis)
10.2.4.6/32 bgp 10 170 > 192.0.2.1(route:isis)
192.0.2.2(route:isis)
10.3.4.5/32 bgp 0 170 > 172.16.36.2(route:local)
10.4.6.8/32 bgp 0 170 > 172.16.36.2(route:local)
The following command shows that the routes received on PE-3 only have community 4:0 added. This community 4:0 is added by the export policy on CE-4 and accepted by the import policies on PE-1 and PE-2.
--{ + running }--[ ]--
A:admin@PE-3# show network-instance default protocols bgp routes ipv4 prefix 10.1.2.3/32 detail
------------------------------------------------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.1.2.3/32" network-instance "default"
------------------------------------------------------------------------------------------------------------------------------------
Network: 10.1.2.3/32
Received Paths: 2
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference : MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i [64500]
Communities : 4:0
RR Attributes : Originator-ID 192.0.2.1, Cluster-List is [ 192.0.2.5 ]
Aggregation : Not an aggregate route
Unknown Attr : None
Invalid Reason : None
Tie Break Reason : none
Route Flap Damping: None
Path 2: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference : MED is -, LocalPref is 100
BGP next-hop : 192.0.2.2
Path : i [64500]
Communities : 4:0
RR Attributes : Originator-ID 192.0.2.2, Cluster-List is [ 192.0.2.5 ]
Aggregation : Not an aggregate route
Unknown Attr : None
Invalid Reason : None
Tie Break Reason : originator-id
Route Flap Damping: None
Path 2 was advertised to:
[ 172.16.36.2 ]
Route Preference: MED is -, No LocalPref
Path : i [64496, 64500]
Communities : 4:0
RR Attributes : No Originator-ID, Cluster-List is [ - ]
Aggregation : Not an aggregate route
Unknown Attr : None
------------------------------------------------------------------------------------------------------------------------------------
The following command is executed on both PE-1 and PE-2 to automatically add a Link Bandwidth Extended Community on routes received from their EBGP neighbor CE-4. By default, the Link Bandwidth Extended Community is not transitive, so in this example, the community is not propagated across EBGP AS boundaries to CE-4).
# on PE-1 and on PE-2:
network-instance default {
protocols {
bgp {
group grp-EBGP {
afi-safi ipv4-unicast {
ipv4-unicast {
link-bandwidth {
auto-from-interface-speed {
admin-state enable
}
}
}
PE-3 now receives the routes from PE-1 and PE-2 with Link Bandwidth Extended Communities corresponding to the interface bandwidth for each CE-PE link:
A:admin@PE-3# show network-instance default protocols bgp routes ipv4 prefix 10.1.2.3/32 detail
-----------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.1.2.3/32" network-instance "default"
-----------------------------------------------------------------------------------------------
Network: 10.1.2.3/32
Received Paths: 2
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference : MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i [64500]
Communities : 4:0, link-bandwidth:64496:200000M
RR Attributes : Originator-ID 192.0.2.1, Cluster-List is [ 192.0.2.5 ]
Aggregation : Not an aggregate route
Unknown Attr : None
Invalid Reason : None
Tie Break Reason : none
Route Flap Damping: None
Path 2: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference : MED is -, LocalPref is 100
BGP next-hop : 192.0.2.2
Path : i [64500]
Communities : 4:0, link-bandwidth:64496:100000M
RR Attributes : Originator-ID 192.0.2.2, Cluster-List is [ 192.0.2.5 ]
Aggregation : Not an aggregate route
Unknown Attr : None
Invalid Reason : None
Tie Break Reason : originator-id
Route Flap Damping: None
Path 2 was advertised to:
[ 172.16.36.2 ]
Route Preference: MED is -, No LocalPref
Path : i [64496, 64500]
Communities : 4:0 ## non-transitive: link-bandwidth community not propagated
RR Attributes : No Originator-ID, Cluster-List is [ - ]
Aggregation : Not an aggregate route
Unknown Attr : None
-----------------------------------------------------------------------------------------------To see the ECMP weight value, the Next-Hop-Group (NHG) ID and the NH IDs are required. The following IPv4 route detailed information includes these IDs:
A:admin@PE-3# show network-instance default ipv4 route 10.1.2.3/32 detail
============================================================================
Prefix: 10.1.2.3/32
----------------------------------------------------------------------------
Active : yes
Route Type : bgp
Route Owner : bgp_mgr, 2026-08-26T06:51:42.223Z (41 seconds ago)
Id : 0
Leakable : no
Leaked : no
Metric : 10
Preference : 170
Internal Tags : none
Dynamic LB : no
Resilient Hash : no
FIB Suppressed : no
FIB Failed : no
Next-Hop-Group : 31796531
Net-Instance : default
FIB Failed : no
Primary NH Count : 2
Backup NH Count : 0
Primary NH : 31796522
LB Weight : 2
Type : indirect
IP Address : 192.0.2.1
Resolved : yes
Resolving Route : 192.0.2.1/32(isis)
Primary NH : 31796524
LB Weight : 1
Type : indirect
IP Address : 192.0.2.2
Resolved : yes
Resolving Route : 192.0.2.2/32(isis)The following command output shows that the ECMP weight value assigned to next hop 192.0.2.1 is 2, relative to its two member interfaces in the LAG, whereas the ECMP weight value of 192.0.2.2 is still 1, because it has a single interface to CE-4:
--{ + running }--[ ]--
A:admin@PE-3# info from state with-context network-instance default route-table next-hop-group 31796531
network-instance default {
route-table {
next-hop-group 31796531 {
backup-next-hop-group 0
backup-active false
fib-programming {
last-successful-operation-type add
last-successful-operation-timestamp "2026-08-26T06:51:42.224Z (a minute ago)"
pending-operation-type none
last-failed-operation-type none
}
next-hop 0 {
next-hop 31796522 # PE-1
weight 2
resolved true
resource-allocation-failed false
}
next-hop 1 {
next-hop 31796524 # PE-2
weight 1
resolved true
resource-allocation-failed false
}
}
}
}If a tester tool is available, it can be used to test the traffic load-balancing behavior by using it to replace CE-4 and CE-6 in the topology. This would be the preferred option to get better results in observing the effect of weighted ECMP. Multiple flows (preferably a couple of hundred or thousands) should be created and sent between the tester ports. For a simple test, the ping tool can be used to create traffic between the loopback interfaces of CE-6 and CE-4.
At least three flows need to be created to see traffic distributed over the two LAG links between CE-4 and PE-1 and the single link between CE-4 and PE-2. The loopback IP addresses on CE-4 and CE-6 have been specifically chosen to demonstrate the expected load balancing. The behavior may be different if different loopback IP addresses are used, because it affects the load-balancing algorithm.
To facilitate the test, two more SSH sessions are initiated to CE-6 (three in total) and the following commands are executed in each separate session:
First session:
ping network-instance default 10.1.2.3 -I 10.3.4.5 -s 1200 -i 0.01 -c 100000Second session:
ping network-instance default 10.1.2.3 -I 10.3.4.5 -s 1200 -i 0.01 -c 100000Third session:
ping network-instance default 10.2.4.6 -I 10.4.6.8 -s 1200 -i 0.01 -c 100000The monitor command outputs on PE-1 and PE-2 show the traffic from CE-6 to CE-4 is being distributed over the two LAG links on PE-1 and the single link on PE-2. In the ideal case, PE-1 would receive 67% and PE-2 would receive 33% of total traffic; however, it may not be possible to observe this effectively with only three ICMP flows.
On the PE-1 LAG link to CE-4, the following traffic is monitored. In each monitoring interval, the number of input packets is 1500 and the number of output packets is 1000 (or more if other traffic is sent in parallel).
A:admin@PE-1# monitor interface lag1 subinterface 0 statistics in-packets out-packets
[2026-08-26 06:56:41.681633]: update /interface[name=lag1]/subinterface[index=0]/statistics/in-packets:0
[2026-08-26 06:56:41.681633]: update /interface[name=lag1]/subinterface[index=0]/statistics/out-packets:0
[2026-08-26 06:56:42.231616]: update /interface[name=lag1]/subinterface[index=0]/statistics/in-packets:1503
[2026-08-26 06:56:42.231616]: update /interface[name=lag1]/subinterface[index=0]/statistics/out-packets:1002
[2026-08-26 06:56:47.240645]: update /interface[name=lag1]/subinterface[index=0]/statistics/in-packets:3007
[2026-08-26 06:56:47.240645]: update /interface[name=lag1]/subinterface[index=0]/statistics/out-packets:2006
[2026-08-26 06:56:52.251092]: update /interface[name=lag1]/subinterface[index=0]/statistics/in-packets:4510
[2026-08-26 06:56:52.251092]: update /interface[name=lag1]/subinterface[index=0]/statistics/out-packets:3008
[2026-08-26 06:56:57.261494]: update /interface[name=lag1]/subinterface[index=0]/statistics/in-packets:6013
[2026-08-26 06:56:57.261494]: update /interface[name=lag1]/subinterface[index=0]/statistics/out-packets:4010
[2026-08-26 06:57:02.272020]: update /interface[name=lag1]/subinterface[index=0]/statistics/in-packets:7516
[2026-08-26 06:57:02.272020]: update /interface[name=lag1]/subinterface[index=0]/statistics/out-packets:5012
---snip---On the PE-2 to CE-4 link, the following traffic is monitored. In each interval, the number of input packets is 0 (there is no loadsharing configured in that direction) and the number of output packets is 500 (or more if other traffic is sent in parallel):
A:admin@PE-2# monitor interface ethernet-1/4 subinterface 0 statistics in-packets out-packets
[2026-08-26 06:56:56.769084]: update /interface[name=ethernet-1/4]/subinterface[index=0]/statistics/in-packets:0
[2026-08-26 06:56:56.769084]: update /interface[name=ethernet-1/4]/subinterface[index=0]/statistics/out-packets:0
[2026-08-26 06:56:56.774805]: update /interface[name=ethernet-1/4]/subinterface[index=0]/statistics/out-packets:501
[2026-08-26 06:57:01.787099]: update /interface[name=ethernet-1/4]/subinterface[index=0]/statistics/out-packets:1003
[2026-08-26 06:57:06.797774]: update /interface[name=ethernet-1/4]/subinterface[index=0]/statistics/out-packets:1504
[2026-08-26 06:57:11.808256]: update /interface[name=ethernet-1/4]/subinterface[index=0]/statistics/out-packets:2005
[2026-08-26 06:57:16.818810]: update /interface[name=ethernet-1/4]/subinterface[index=0]/statistics/in-packets:2
[2026-08-26 06:57:16.818810]: update /interface[name=ethernet-1/4]/subinterface[index=0]/statistics/out-packets:2508
---snip---BGP weighted ECMP for IPv4 family using BGP import policy
The link-bandwidth command, which was enabled in the previous step, is removed on PE-1 and PE-2:
# on PE-1 and on PE-2:
network-instance default {
protocols {
bgp {
group grp-EBGP {
afi-safi ipv4-unicast {
ipv4-unicast {
link-bandwidth {
delete auto-from-interface-speed # by default disabled
}
It is possible to keep the link-bandwidth command, because the following policy takes precedence anyway.
The following policy is configured on PE-1 to manually add the Link Bandwidth Extended Community "bandwidth:64500:20000" to routes received from CE-4:
# on PE-1:
routing-policy {
community-set cs-4-0 {
member [
4:0
]
}
extended-community-set ecs-BW-20G {
member [
link-bandwidth:64500:20000
]
}
prefix-set ps-10.0.0.0 {
prefix 10.0.0.0/8 mask-length-range 32..32 {
}
}
policy rp-import-4-0-BW-20G {
statement stmt-10 {
match {
prefix {
prefix-set ps-10.0.0.0
}
bgp {
community-set cs-4-0
}
}
action {
policy-result accept
bgp {
extended-community {
operation add
method reference
referenced-sets [
ecs-BW-20G
]
}
}
}
}
}
}
The policy replaces the import policy for the grp-EBGP group on PE-1, as follows:
# on PE-1:
network-instance default {
protocols {
bgp {
group grp-EBGP {
delete import-policy
import-policy [
rp-import-4-0-BW-20G
]The following policy is configured on PE-2 to manually add the Link Bandwidth Extended Community "bandwidth:64500:10000" to routes received from CE-4:
# on PE-2:
routing-policy {
community-set cs-4-0 {
member [
4:0
]
}
extended-community-set ecs-BW-10G {
member [
link-bandwidth:64500:10000
]
}
prefix-set ps-10.0.0.0 {
prefix 10.0.0.0/8 mask-length-range 32..32 {
}
}
policy rp-import-4-0-BW-10G {
statement stmt-10 {
match {
prefix {
prefix-set ps-10.0.0.0
}
bgp {
community-set cs-4-0
}
}
action {
policy-result accept
bgp {
extended-community {
operation add
method reference
referenced-sets [
ecs-BW-10G
]
}
}
}
}
}
The policy is applied on PE-2 for the grp-EBGP group in the import direction:
# on PE-2:
network-instance default {
protocols {
bgp {
group grp-EBGP {
delete import-policy
import-policy [
rp-import-4-0-BW-10G
]PE-3 receives the routes from PE-1 and PE-2 with Link Bandwidth Extended Communities as configured in the previous step:
A:admin@PE-3# show network-instance default protocols bgp routes ipv4 prefix 10.1.2.3/32 detail
-----------------------------------------------------------------------------------------------
Show report for the BGP routes to network "10.1.2.3/32" network-instance "default"
-----------------------------------------------------------------------------------------------
Network: 10.1.2.3/32
Received Paths: 2
Path 1: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference : MED is -, LocalPref is 100
BGP next-hop : 192.0.2.1
Path : i [64500]
Communities : 4:0, link-bandwidth:64500:20k
RR Attributes : Originator-ID 192.0.2.1, Cluster-List is [ 192.0.2.5 ]
Aggregation : Not an aggregate route
Unknown Attr : None
Invalid Reason : None
Tie Break Reason : none
Route Flap Damping: None
Path 2: <Best,Valid,Used,>
Route source : neighbor 192.0.2.5
Route Preference : MED is -, LocalPref is 100
BGP next-hop : 192.0.2.2
Path : i [64500]
Communities : 4:0, link-bandwidth:64500:10k
RR Attributes : Originator-ID 192.0.2.2, Cluster-List is [ 192.0.2.5 ]
Aggregation : Not an aggregate route
Unknown Attr : None
Invalid Reason : None
Tie Break Reason : originator-id
Route Flap Damping: None
Path 2 was advertised to:
[ 172.16.36.2 ]
Route Preference: MED is -, No LocalPref
Path : i [64496, 64500]
Communities : 4:0, link-bandwidth:64500:20k
RR Attributes : No Originator-ID, Cluster-List is [ - ]
Aggregation : Not an aggregate route
Unknown Attr : None
-----------------------------------------------------------------------------------------------
Again, the following command output shows that the ECMP-weight output assigned to next hop 192.0.2.1 has become 2:
A:admin@PE-3# show network-instance default ipv4 route 10.1.2.3/32 detail
==========================================================================
Prefix: 10.1.2.3/32
--------------------------------------------------------------------------
Active : yes
Route Type : bgp
Route Owner : bgp_mgr, 2026-08-26T07:00:53.744Z (a minute ago)
Id : 0
Leakable : no
Leaked : no
Metric : 10
Preference : 170
Internal Tags : none
Dynamic LB : no
Resilient Hash : no
FIB Suppressed : no
FIB Failed : no
Next-Hop-Group : 31796533
Net-Instance : default
FIB Failed : no
Primary NH Count : 2
Backup NH Count : 0
Primary NH : 31796522
LB Weight : 2
Type : indirect
IP Address : 192.0.2.1
Resolved : yes
Resolving Route : 192.0.2.1/32(isis)
Primary NH : 31796524
LB Weight : 1
Type : indirect
IP Address : 192.0.2.2
Resolved : yes
Resolving Route : 192.0.2.2/32(isis)
A:admin@PE-3# info from state with-context network-instance default route-table next-hop-group 31796533
network-instance default {
route-table {
next-hop-group 31796533 {
backup-next-hop-group 0
backup-active false
fib-programming {
last-successful-operation-type add
last-successful-operation-timestamp "2026-08-26T07:00:53.744Z (2 minutes ago)"
pending-operation-type none
last-failed-operation-type none
}
next-hop 0 {
next-hop 31796522
weight 2
resolved true
resource-allocation-failed false
}
next-hop 1 {
next-hop 31796524
weight 1
resolved true
resource-allocation-failed false
}
}
}
}Any dynamic changes to the Link Bandwidth Extended Community upon failure or bandwidth change of a LAG link are not possible with the policy functionality, as opposed to using the link-bandwidth command.
Similar tests can be run using the ping facility or an external tester tool as described in the previous section to check the packet forwarding behavior.
Conclusion
BGP Weighted ECMP allows modification of the standard load-balancing behavior to accommodate the relative link bandwidth values of different BGP next hops. This allows better utilization of the links in the network with different capacities. The bandwidth values are advertised by edge routers and carried within a BGP community called the Link Bandwidth Extended Community. SR Linux routers automatically perform load balancing if all the BGP routes to a destination contain this community.