BGP Link Bandwidth Extended Community Explained

2026年9月19日 LOG admin

ECMP is a tidy solution until the exit links are not equal: two 10G uplinks and one 100G uplink load-balanced at 1:1:1 sends a third of your traffic down a pipe that is ten times smaller. The BGP link bandwidth extended community exists for exactly this case. It advertises the bandwidth of an AS exit link as a 4-byte extended community, letting each router weight its multipath selection proportionally to the available bandwidth. This guide covers how the attribute works, how to configure it, and where it quietly does not apply.

What the attribute does and does not do

It advertises the bandwidth of the directly connected eBGP exit link, expressed in bytes per second.
Receiving routers use it as a relative weight when multiple paths are installed in the forwarding table — traffic is shared in proportion to bandwidth instead of per-flow equality.
The weight can be derived from the remote bandwidth (what the neighbour advertised), the local link bandwidth, or a function of both, depending on local configuration.
It is not a metric and does not change best-path selection in the BGP decision process. If only one path is installed, link bandwidth changes nothing.

The practical benefit is that a 10G link and a 100G link to the same upstream are used in a 1:10 ratio rather than forcing you to equalise the links or accept 50% idle capacity.

Configuration on the egress routers

router bgp 65001
 address-family ipv4 unicast
  bgp dmzlink-bw                 ! enable use of link bandwidth for multipath weights
  maximum-paths 4
  neighbor 203.0.113.1 remote-as 65010
  neighbor 203.0.113.1 dmzlink-bw
  neighbor 203.0.113.1 send-community extended
 !
! address-family vpnv4 unicast
!  bgp dmzlink-bw               ! also supported for VPNv4 (MPLS L3VPN)

Requirements to keep in mind:

Multipath (load balancing) must already be configured — link bandwidth only affects weights for paths that both exist and are eligible.
Extended community exchange must be enabled towards iBGP peers if the attribute has to travel across your AS: neighbor x.x.x.x send-community extended.
The feature is supported under IPv4 and VPNv4 address families; the local router can only originate the community for directly connected eBGP links.
Both eBGP and iBGP load balancing are supported.

Verifying that it is working

router# show ip bgp 198.51.100.0/24
  Extended Community: LB:100000000 ; link bandwidth 100000000 bytes/sec

router# show ip bgp neighbors 203.0.113.1 | include Extended community
router# show ip cef 198.51.100.0/24 internal
  # per-path weights are visible in the CEF internal view

If the community does not appear on the received prefix, the chain to check is: dmzlink-bw configured under the neighbour, extended communities being sent, and the receiving side configured with bgp dmzlink-bw so it actually uses the value.

Where engineers get this wrong

Expecting it to work with a single path. One path means one path; nothing to weight.
Forgetting support for unequal paths in the IGP-facing case. Link bandwidth pairs with multipath, not with interior metrics.
Using it as a traffic-engineering tool. It is proportional weighting, not a policy engine — if you need "never use the transit unless the primary is down", that is local preference or a route map.
Ignoring the return path. Link bandwidth controls how you send traffic out. Your upstream has its own policy for the traffic returning, which you influence only by AS-path prepending or communities they honour.

Design pattern: DMZ and multi-exit sites

The classic deployment is a pair of exit routers on links of different speeds — for example 10G and 1G, or 100G and 10G — where the customer wants the fast link used almost exclusively without running it as a strict backup. Advertising link bandwidth, plus an equal-cost multipath configuration, gives a proportional split; a small local-preference or MED adjustment on top biases the split further without ever hard-failing the slower link.

On modern designs the same idea appears in the BGP link-bandwidth use cases now standardised for data-centre and DMZ topologies, where each router adds its own accumulated bandwidth when re-advertising so that downstream routers see the real end-to-end capacity rather than a single hop's worth.