Last verified: 2026-09-07
This report covers implementations that cumulatively regenerate the BGP Link Bandwidth Extended Community when advertising a route with a changed next hop.
The relevant layer is the Link Bandwidth Extended Community carried in the BGP Extended Communities path attribute. The cumulative calculation is performed by the advertising BGP speaker before the route is placed in Adj-RIB-Out. The receiver continues to interpret the resulting scalar as bandwidth available through the advertised next hop.
| Implementation | Verified version | Status | Documented behavior | References |
|---|---|---|---|---|
| FRRouting (FRR) | 10.6 | Documented | Sums the Link Bandwidth values of installed multipaths when regenerating the community for a next-hop-changing advertisement. The current source does not show automatic discovery of local interface bandwidth or the optional per-path MIN(local-link-bandwidth, received-bandwidth) calculation. |
FRR documentation, multipath aggregation source, next-hop-change processing |
| Arista EOS | 4.36.2F | Documented | send-community link-bandwidth aggregate advertises the sum of the Link Bandwidth values associated with the routes contributing to the multipath set. It advertises MIN(SUM(received link-bandwidth values), bandwidth toward the advertising peer).The divide alternative partitions cumulative bandwidth among advertisements. |
EOS BGP manual, Link Bandwidth feature documentation |
| Cisco IOS XR | 6.0 and later; verified in 7.9.x and 25.x documentation | Documented | ebgp-send-extcommunity-dmz cumulative advertises the sum of the Link Bandwidth values of the egress multipaths. Current releases also document automatic aggregation under specified next-hop-self and policy conditions. |
IOS XR 7.9 documentation, ASR 9000 25.x documentation, command history |
| Cisco NX-OS | 10.5(1)F and later | Documented | link-bandwidth cumulative advertises MIN(SUM(received link-bandwidth values), bandwidth toward the advertising peer). This is cumulative aggregation with a local peer-link cap. |
Nexus 9000 NX-OS BGP documentation |
| Juniper Junos OS and Junos OS Evolved | 17.4R1 and later | Documented | aggregate-bandwidth advertises the sum of the Link Bandwidth values associated with multipaths. limit-bandwidth can cap the advertised aggregate. |
Junos BGP load-balancing documentation, Junos 24.2 release documentation |
| Nokia SR OS | Verified in 24.7 documentation | Documented | aggregate-used-paths sums the Link Bandwidth values of the multipaths actually used for forwarding when a route is re-advertised with next-hop-self. |
SR OS BGP documentation, command reference |
| Nokia SR Linux | Verified in 25.10 documentation | Documented | link-bandwidth aggregate-used-paths true sums the Link Bandwidth values of used multipaths when advertising the route with next-hop-self. |
SR Linux 25.10 BGP documentation, SR Linux 26.3 BGP documentation |
These products expose or deploy the FRR implementation. They are useful deployment evidence but should not be counted as separate protocol-code implementations unless the vendor identifies independent cumulative-processing code.
| Product | Verified version | Status | Evidence | References |
|---|---|---|---|---|
| NVIDIA Cumulus Linux | 5.18; worked example in 5.2 | FRR-derived | Supports cumulative and num-multipaths. The worked example shows four contributing paths with values 2, 2, 1, 1 being advertised as an aggregate value of 6. |
Cumulus Linux 5.18 documentation, Cumulus Linux 5.2 cumulative example, NVUE route-policy reference |
| SONiC | Current FRR-based distribution | FRR-derived | The implementation was reported to BESS as available in SONiC/FRR. Current SONiC configuration templates expose FRR weighted-ECMP configuration. | IETF implementation statement, SONiC FRR configuration template, SONiC configuration model |
| VyOS | 1.4 | FRR-derived | Exposes cumulative and num-multipaths as Link Bandwidth Extended Community policy values. The underlying BGP implementation is FRR. |
VyOS route-map documentation |
| Implementation | Verified version | Status | Publicly documented behavior | References |
|---|---|---|---|---|
| Huawei CloudEngine VRP | V200R024C00 | Partial | apply extcommunity bandwidth aggregate sums upstream bandwidth and optionally limits the result. The public documentation does not establish the complete wire format, next-hop-change trigger, or interoperability behavior required to claim full eBGP-DMZ implementation. |
Huawei routing-policy command reference |
| H3C Comware | Current public configuration guide | Partial | Supports Link Bandwidth advertisement and, in one Add-Path mode, advertises the total bandwidth of the UCMP set on the single advertised route. The documentation also says that a received Link Bandwidth community is removed when the next hop changes; therefore, this is not documented as general eBGP-DMZ cumulative regeneration. | H3C BGP configuration guide |
Public documentation establishes several interoperable implementations of cumulative SUM processing and, in some products, a cap on the resulting aggregate. Except where stated above, it does not establish implementation of the optional per-path calculation:
contributing-bandwidth_i = MIN(local-link-bandwidth_i, received-bandwidth_i)
followed by:
advertised-bandwidth = SUM(contributing-bandwidth_i)
Accordingly, the table distinguishes documented cumulative aggregation from complete implementation of every processing option described by draft-ietf-bess-ebgp-dmz.