BGP DMZ Bandwidth Management

This chapter describes the various aspects of BGP Demilitarized Zone (DMZ) bandwidth management, including aggregate bandwidth, link bandwidth for unequal cost recursive load balancing, and transitive-bandwidth extended community support.

BGP DMZ aggregate bandwidth

BGP DMZ aggregate bandwidth is a feature that aggregates the link-bandwidth values of DMZ eBGP multipaths when advertising routes to iBGP peers, and enables accurate internal bandwidth representation for better routing decisions.

BGP DMZ aggregate bandwidth operation

BGP aggregates bandwidth without an explicit command if these conditions are met:

  • The network has multipaths and all multipaths have link-bandwidth values.

  • You set the next-hop attribute to next-hop-self . The next-hop attribute for all routes advertised to the specified neighbor is the address of the local router.

  • You do not configure an outbound policy that might change the DMZ link-bandwidth value.

DMZ link bandwidth aggregation rules

DMZ link bandwidth aggregation follows these rules:

  • If BGP does not know the DMZ link-bandwidth value (dmz-link-bandwidth ) for any one of the multipaths (eBGP or iBGP), BGP does not download the DMZ link-bandwidth value for all multipaths, including the best path, to the routing information base (RIB).

  • BGP does not consider the DMZ link-bandwidth value of iBGP multipath during aggregation.

  • BGP can advertise the route with an aggregate value as a best path or an add-path.

  • Add-path does not qualify for DMZ link bandwidth aggregation as the next hop is preserved. BGP does not support configuring next-hop-self for add-path.

  • For VPNv4 and VPNv6 address family identifiers (AFIs), if you configure the DMZ link-bandwidth value using an outbound route-policy, specify the route table or use the additive keyword. Otherwise, the system does not import routes on the receiving end of the peer.

Configure BGP DMZ aggregate bandwidth

Configure BGP DMZ aggregate bandwidth in a sample topology.

This example uses a topology of R1---(iBGP)---R2---(iBGP)---R3 to demonstrate how aggregated DMZ link-bandwidth values are sent between routers. The routers in the topology advertise and receive aggregated DMZ link-bandwidth values.

  • On R1, BGP prefix has:

    • path 1 (bestpath) with link-bandwidth value 100

    • path 2 (eBGP multipath) with link-bandwidth value 30, and

    • path 3 (eBGP multipath) with link-bandwidth value 50.

    When the best path is advertised to R2, R1 sends an aggregated DMZ link-bandwidth value of 180; this is the aggregated value of paths 1, 2, and 3.

  • On R2, BGP prefix has:

    • path 1 (bestpath) with link-bandwidth value 60

    • path 2 (eBGP multipath) with link-bandwidth value 200, and

    • path 3 (eBGP multipath) with link-bandwidth value 50.

    When the best path is advertised to R3, R2 sends an aggregated DMZ link-bandwidth value of 310; this is the aggregated value of paths 1, 2, and 3.

  • On R3, BGP prefix has:

    • path 1 (bestpath) with LB 180 (learned from R1)

    • path 2 (iBGP multipath) with LB 310 (learned from R2)

This sample configuration demonstrates how to set the link-bandwidth extended community on a per-path basis at either the neighbor-in or neighbor-out policy attach points. The dmz-link-bandwidth command is configured under eBGP neighbor configuration mode. All paths received from that particular neighbor are marked with the link-bandwidth extended community when sent to iBGP peers.

Procedure

Step 1

Configure an inbound or outbound route-policy.

Example:

Router(config)# extcommunity-set bandwidth dmz_ext
Router(config-ext)# 1:1290400000
Router(config-ext)# end-set
Router(config)#route-policy dmz_rp
Router(config-rpl)#set extcommunity bandwidth dmz_ext 
Router(config-rpl)#pass
Router(config-rpl)#end-policy
Router(config)#router bgp 65000
Router(config-bgp)#neighbor 10.0.101.1
Router(config-bgp-nbr)#remote-as 1001
Router(config-bgp-nbr)#address-family ipv4 unicast
Router(config-bgp-nbr-af)#route-policy dmz_rp in
Router(config-bgp-nbr-af)#route-policy pass out
Router(config-bgp-nbr-af)#commit

Step 2

Configure the dmz-link-bandwidth command for the BGP neighbor.

Example:

Router(config)#router bgp 65000
Router(config-bgp)#neighbor 10.0.101.2
Router(config-bgp-nbr)#remote-as 1001
Router(config-bgp-nbr)#dmz-link-bandwidth
Router(config-bgp-nbr)#address-family ipv4 unicast
Router(config-bgp-nbr-af)#route-policy pass in
Router(config-bgp-nbr-af)#route-policy pass out
Router(config-bgp-nbr-af)#commit

The system applies policy-based link bandwidth settings to BGP neighbors.

BGP DMZ transitive-bandwidth extended community support

BGP DMZ transitive-bandwidth extended community is a feature that allows BGP to process and make routing decisions based on the available transitive-bandwidth extended community using UCMP.

Benefits of BGP DMZ transitive-bandwidth extended community

Table 3. Feature History Table

Feature Name

Release Information

Feature Description

BGP DMZ transitive-bandwidth extended community support

Release 25.1.1

Introduced in this release on: Fixed Systems (8200 [ASIC: Q200, P100], 8700 [ASIC: P100, K100], 8010 [ASIC: A100]); Centralized Systems (8600 [ASIC: Q200]); Modular Systems (8800 [LC ASIC: Q100, Q200, P100])

You can now enable BGP to process incoming DMZ transitive-bandwidth extended community, allowing bandwidth-aware routing decisions using Unequal Cost Multi-Path (UCMP). The feature allows RPL to manually set the DMZ transitive-bandwidth extended community for BGP neighbors.

This extended propagation supports multivendor interoperability, optimizes traffic distribution, prevents link over utilization, and balances load across available paths.

Previously, BGP supported only the non-transitive extended community.

The feature introduces these changes:

CLI:

The transitive-bandwidth type is introduced as an extended community in RPL.

YANG Data Models:

  • Cisco-IOS-XR-um-route-policy-cfg

  • Cisco-IOS-XR-policy-repository-cfg

(see GitHub, YANG Data Models Navigator)

You can now configure BGP to process incoming DMZ transitive-bandwidth extended communities, enabling bandwidth-aware routing decisions through UCMP. This enhancement allows the router to interpret linked bandwidth values that are attached to incoming BGP routes and use them to distribute traffic proportionally across multiple paths based on available capacity.

In addition, the feature extends RPL support to manually set the DMZ transitive-bandwidth extended community for inbound and outbound BGP updates. This extended propagation supports multivendor interoperability, optimizes traffic distribution, and prevents link over utilization.

The key benefits of the feature are:

  • Ensures multivendor interoperability and utilizes the DMZ bandwidth value across heterogeneous networks.

  • Adds a weight that enables RIB or FIB to intelligently load balance traffic across multiple paths.

  • Ensures consistent network policies across domains.

How BGP DMZ transitive-bandwidth extended communities work

Summary

The key components involved in the process are:

  • BGP router: Assigns and propagates DMZ transitive-bandwidth values.

  • BGP peers: Receive and utilize the propagated bandwidth attributes.

  • RIB/FIB: Use bandwidth values to make intelligent load balancing decisions.

The BGP DMZ transitive-bandwidth extended community workflow involves assigning bandwidth values, propagating them, and then using these values for traffic load balancing.

Workflow

These stages describe how BGP DMZ transitive-bandwidth extended community works.

  1. Policy-based bandwidth assignment: A BGP router assigns a DMZ transitive-bandwidth value to BGP routes using an egress or ingress RPL.
  2. Propagation of the bandwidth attribute: The router propagates the transitive-bandwidth extended community along with the route to its BGP peers.
  3. Traffic is load balanced based on the bandwidth: Routers use the bandwidth values to balance traffic across multiple paths, favoring higher-capacity links.

Result

The system achieves optimized traffic distribution and load balancing across available paths based on bandwidth.

Topology for BGP path selection using UCMP

To describe a sample network configuration that demonstrates bandwidth-aware BGP path selection using UCMP.

The figure shows an example topology for bandwidth-aware BGP path selection using UCMP.

Figure 1. Example topology for bandwidth-aware BGP path selection using UCMP
Example topology

The topology consists of three BGP routers: RTR-1, RTR-2, and RTR-3. All the routers are within the same AS (65000), forming an Internal Border Gateway Protocol network.

  • RTR-1 and RTR-2 learn and advertise an external prefix 192.168.1.0/24. The routers apply an RPL outbound toward RTR-3, setting the link-bandwidth value through the transitive-bandwidth extended community.

  • RTR-3 receives the prefix from RTR-1 and RTR-2, evaluates their advertised Link Bandwidth (LB) values, and uses UCMP to make routing decisions.

    Consider a scenario where RTR-1 advertises an LB value of 65000:1250000000, and RTR-2 advertises 65000:2500000000. Based on these LB values, RTR-3 forwards approximately 33% of the traffic to RTR-1 and 67% to RTR-2, effectively sending twice as much traffic to RTR-2. This traffic distribution allows RTR-3 to balance the load according to the relative bandwidth of each link.

Configure BGP DMZ transitive-bandwidth extended community

Before you begin

Ensure that the network supports DMZ bandwidth extended communities for signaling link bandwidth.

Procedure

Step 1

Configure the transitive-bandwidth extended community for a specific prefix.

  • Configure the transitive-bandwidth extended community directly within the route policy.

    In the sample configuration for RTR-1, the route policy for RTR-1 advertises prefix 192.168.1.0/24, and attaches a transitive-bandwidth extended community to that route. The ASN is 65000 and the link-bandwidth is 1,250,000,000 bytes per second. 

    RTR-1#config
RTR-1(config)#route-policy SET-LB
RTR-1(config-rpl)#if destination in (192.168.1.0/24) then
RTR-1(config-rpl-if)#set extcommunity transitive-bandwidth (65000:1250000000)
RTR-1(config-rpl-if)#endif
RTR-1(config-rpl)#end-policy
  • Configure the transitive-bandwidth extended community using the extcommunity-set command, and create a route policy that applies the transitive-bandwidth extended community to the route.

    In the sample configuration for RTR-2, the extended community set is LB that matches the transitive-bandwidth extended community. The route policy SET-LB applies the transitive-bandwidth extended community that is defined by the named set LB to RTR-2. 

    RTR-2#config
RTR-2(config)#extcommunity-set transitive-bandwidth LB
RTR-2(config-ext)#65000:2500000000
RTR-2(config-ext)#end-set
RTR-2(config)#route-policy SET-LB
RTR-2(config-rpl)#if destination in (192.168.1.0/24) then
RTR-2(config-rpl-if)#set extcommunity transitive-bandwidth LB
RTR-2(config-rpl-if)#endif
RTR-2(config-rpl)#end-policy

Step 2

Run the router bgp command on RTR-1 and RTR-2 to enable BGP for the required ASN, and apply the configured route policy to outbound updates for the required neighbor.

Example:

In the sample configuration, BGP is enabled for AS 65000 on RTR-1 and RTR-2, and applies the SET-LB route policy to outbound updates to the neighbor RTR-3 (10.0.0.3). 

Router(config)#router bgp 65000
Router(config-bgp)#neighbor 10.0.0.3
Router(config-bgp-nbr)#remote-as 65000
Router(config-bgp-nbr)#address-family ipv4 unicast
Router(config-bgp-nbr-af)#route-policy SET-LB out

Step 3

Run the show running-config command to verify the running configuration for RTR-1 and RTR-2.

Example:

This is a sample output from RTR-1.
route-policy SET-LB
  if destination in (192.168.1.0/24) then
    set extcommunity transitive-bandwidth (65000:1250000000)
  endif
end-policy
!
router bgp 65000
 neighbor 10.0.0.3
  remote-as 65000
  address-family ipv4 unicast
   route-policy SET-LB out
  !
 !
!

Example:

This is a sample output from RTR-2.

extcommunity-set transitive-bandwidth LB
  65000:2500000000
end-set
!
route-policy SET-LB
  if destination in (192.168.1.0/24) then
    set extcommunity transitive-bandwidth LB
  endif
end-policy
!
router bgp 65000
 neighbor 10.0.0.3
  remote-as 65000
  address-family ipv4 unicast
   route-policy SET-LB out
  !
 !
!

Step 4

Run the show bgp ipv4 unicast advertised neighbor command to verify the routes that are advertised from RTR-1 to RTR-3, and RTR-2 to RTR-3.

Example:

The sample show output displays the routes that are advertised from RTR-1 to RTR-3. The next-hop and router ID 10.0.0.1 indicates that the route came from RTR-1. The extended community: LB_TRANS:65000:10000000 value in kbps confirms that RTR-1 supports and advertises the link-bandwidth attribute. 

RTR-1#show bgp ipv4 unicast advertised neighbor 10.0.0.3 
Fri Apr  4 08:09:06.297 UTC
192.168.1.0/24 is advertised to 10.0.0.3
  Path info:
    neighbor: Local           neighbor router id: 10.0.0.1
    valid  redistributed  best  
Received Path ID 0, Local Path ID 1, version 5
  Attributes after inbound policy was applied:
    next hop: 0.0.0.0
    MET ORG AS 
    origin: incomplete  metric: 0  
    aspath: 
  Attributes after outbound policy was applied:
    next hop: 10.0.0.1
    MET ORG AS EXTCOMM 
    origin: incomplete  metric: 0  
    aspath: 
    extended community: LB_TRANS:65000:10000000

Example:

The sample show output displays the routes that are advertised from RTR-2 to RTR-3. The next-hop and router ID 10.0.0.2 indicates that the route came from RTR-2. The extended community: LB_TRANS:65000:20000000 value in kbps confirms that RTR-2 supports and advertises the link-bandwidth attribute. 

RTR-2#show bgp ipv4 unicast advertised neighbor 10.0.0.3 
Fri Apr  4 08:12:03.484 UTC
192.168.1.0/24 is advertised to 10.0.0.3
  Path info:
    neighbor: Local           neighbor router id: 10.0.0.2
    valid  redistributed  best  
Received Path ID 0, Local Path ID 1, version 5
  Attributes after inbound policy was applied:
    next hop: 0.0.0.0
    MET ORG AS 
    origin: incomplete  metric: 0  
    aspath: 
  Attributes after outbound policy was applied:
    next hop: 10.0.0.2
    MET ORG AS EXTCOMM 
    origin: incomplete  metric: 0  
    aspath: 
    extended community: LB_TRANS:65000:20000000

Step 5

Run the show bgp ipv4 unicast command on RTR-3, to verify the multiple paths and extended community attributes for load-balancing bandwidth advertisement.

Example:

In the sample show output from RTR-3, the highlighted values refer to the transitive-bandwidth extended communities, which are used to make routing decisions using UCMP. 

RTR-3#show bgp ipv4 unicast 192.168.1.0/24
Fri Apr  4 08:03:49.333 UTC
BGP routing table entry for 192.168.1.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                  8            8
Last Modified: Apr  4 08:03:43.608 for 00:00:05
Paths: (2 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  Local
    10.0.0.1 (metric 10) from 10.0.0.1 (10.0.0.1)
      Origin incomplete, metric 0, localpref 100, valid, internal, best, group-best, multipath
      Received Path ID 0, Local Path ID 1, version 8
      Extended community: LB_TRANS:65000:10000000 
                          (LB transitive     AS:bytes/sec:65000:1250000000.0)
  Path #2: Received by speaker 0
  Not advertised to any peer
  Local
    10.0.0.2 (metric 10) from 10.0.0.2 (10.0.0.2)
      Origin incomplete, metric 0, localpref 100, valid, internal, multipath
      Received Path ID 0, Local Path ID 0, version 0
      Extended community: LB_TRANS:65000:20000000 
                          (LB transitive     AS:bytes/sec:65000:2500000000.0)

Step 6

Run the show route command on RTR-3, to verify that the routing decision reflects the intended path preferences set by the BGP policies, when using transitive-bandwidth extended communities for UCMP-based load balancing.

Example:

The sample show output from RTR-3 indicates that the router has learned route 192.168.1.0/24 through BGP (AS 65000), and is using BGP multipath to forward traffic across the two next-hops.

RTR-1 (10.0.0.1) has a weight of 10000000, and RTR-2 (10.0.0.2) has a weight of 20000000. The router uses these values to load balance traffic, sending more traffic through RTR-2 because of the higher weight. 

RTR-3#show route 192.168.1.0/24           
Fri Apr  4 08:03:53.280 UTC

Routing entry for 192.168.1.0/24
  Known via "bgp 65000", distance 200, metric 0, type internal
  Installed Apr  4 08:03:43.605 for 00:00:09
  Routing Descriptor Blocks
    10.0.0.1, from 10.0.0.1, BGP multi path
      Route metric is 0, Wt is 10000000
    10.0.0.2, from 10.0.0.2, BGP multi path
      Route metric is 0, Wt is 20000000
  No advertising protos.

Step 7

Run the show cef command on RTR-3, to view detailed information about the CEF entry for the IP prefix 192.168.1.0/24.

Example:

In the sample show output, slot 0 is assigned 1 out of 3 buckets, and slot 1 is assigned 2 out of 3 buckets. In other words, the router forwards traffic in a 1:2 ratio, sending approximately 33% through slot 0 and 67% through slot 1. 

RTR-3#show cef 192.168.1.0/24 
Fri Apr  4 08:04:03.111 UTC
192.168.1.0/24, version 20, internal 0x5000001 0x40 (ptr 0x9c449908) [1], 0x0 (0x0), 0x0 (0x0)
 Updated Apr  4 08:03:43.610
 Prefix Len 24, traffic index 0, precedence n/a, priority 4
  gateway array (0x9c2b0798) reference count 1, flags 0x2010, source rib (7), 0 backups
                [1 type 3 flags 0x48441 (0x9c3557d8) ext 0x0 (0x0)]
  LW-LDI[type=0, refc=0, ptr=0x0, sh-ldi=0x0]
  gateway array update type-time 1 Apr  4 08:03:43.610
 LDI Update time Apr  4 08:03:43.633

    Weight distribution:
    slot 0, weight 10000000, normalized_weight 1
    slot 1, weight 20000000, normalized_weight 2

  Level 1 - Load distribution: 0 1 1
  [0] via 10.0.0.1/32, recursive
  [1] via 10.0.0.2/32, recursive
  [2] via 10.0.0.2/32, recursive

   via 10.0.0.1/32, 3 dependencies, recursive, bgp-multipath [flags 0x6080]
    path-idx 0 NHID 0x0 [0x9c449818 0x0], Internal 0xb329c0a0
    next hop 10.0.0.1/32 via 10.0.0.1/32

    Load distribution: 0 (refcount 1)

    Hash  OK  Interface                 Address
    0     Y   FourHundredGigE0/0/0/0    10.10.13.1     

   via 10.0.0.2/32, 3 dependencies, recursive, bgp-multipath [flags 0x6080]
    path-idx 1 NHID 0x0 [0x9c449728 0x0], Internal 0xb329c220
    next hop 10.0.0.2/32 via 10.0.0.2/32

    Load distribution: 0 (refcount 1)

    Hash  OK  Interface                 Address
    1     Y   FourHundredGigE0/0/0/1    10.10.23.2

Policy-based cumulative bandwidth advertisements

Policy-based cumulative bandwidth advertisement is a BGP routing protocol feature that allows you to

  • enable cumulation for selected prefixes

  • suppress minor cumulative bandwidth changes by applying configurable thresholds

  • limit cumulative bandwidth calculations to local link bandwidths at domain boundaries

  • control how the bandwidth used for unequal-cost multipath (UCMP) is determined

  • round cumulative bandwidth changes to the nearest multiple of a configured number, and

  • set outbound policy actions based on bandwidth comparator result.

Cumulative bandwidth is the total available bandwidth that is calculated by summing the bandwidths of all eBGP multipath routes.

Table 4. Feature History Table

Feature Name

Release Information

Feature Description

Policy-based cumulative bandwidth advertisements

 Release 25.4.1

Introduced in this release on: Fixed Systems (8200 [ASIC: Q100, Q200, P100], 8700 [ASIC: P100, K100], 8010 [ASIC: A100]); Centralized Systems (8600 [ASIC: Q200]); Modular Systems (8800 [LC ASIC: Q100, Q200, P100])

You can now reduce unnecessary BGP updates, such as frequent route advertisements caused by small, insignificant bandwidth changes, and improve network stability by suppressing minor bandwidth changes, rounding advertised bandwidth to a specified value, and setting outbound policy actions based on bandwidth thresholds.

This feature introduces these changes:

CLIs:

Policy-based cumulative bandwidth advertisements

 Release 25.3.1

Introduced in this release on: Fixed Systems (8200 [ASIC: Q100, Q200, P100], 8700 [ASIC: P100, K100], 8010 [ASIC: A100]); Centralized Systems (8600 [ASIC: Q200]); Modular Systems (8800 [LC ASIC: Q100, Q200, P100])

You can now reduce routing churn by selectively advertising cumulative bandwidth for specific BGP prefixes, customizing bandwidth calculation per route, and containing updates within your local domain.

This feature introduces these changes:

CLIs:

Key features

These are the key capabilities of the policy-based cumulative bandwidth advertisement feature:

  • Selective cumulation for prefixes: You can choose which BGP prefixes advertise cumulative bandwidth instead of applying it to all routes. Using route policy criteria, such as BGP communities, you can target only selected prefixes. This reduces unnecessary routing churn and helps you focus on critical traffic paths.

  • Granular control of bandwidth type: You can control how the bandwidth used for unequal-cost multipath (UCMP) is determined. The bandwidth value can come from:

    • The local link

    • A value received from a BGP neighbor

    • A mathematical function combining both

    You can also apply scaling factors. This flexibility allows more precise traffic distribution and better overall network efficiency.

  • Cumulative bandwidth by link-bandwidth (domain boundary): You can limit cumulative bandwidth calculations to local link bandwidths at domain boundaries. This ensures that only local changes affect advertised bandwidth, preventing remote network events from causing unnecessary routing updates.

  • Suppression of non-significant bandwidth changes: You can configure a threshold below which bandwidth changes are not advertised. By suppressing small or insignificant changes, the feature reduces control plane load and routing churn, while still propagating meaningful updates.

  • Rounding of advertised bandwidth: You can round cumulative bandwidth values to the nearest operator-defined increment before they are advertised. This increases consistency, and avoids oscillations caused by minor fluctuations.

  • Policy-based outbound actions: You can apply route policies that take specific actions-such as modifying BGP communities or AS-path attributes-based on the bandwidth advertised to the peer. This enables automated, policy-driven responses to bandwidth changes and supports advanced routing and dynamic traffic engineering.

How policy-based cumulative bandwidth advertisements work

Summary

Administrators use route policies to select specific prefixes for cumulative bandwidth advertisement. The policy then defines how bandwidth is summed. It either aggregates effective bandwidth across all eBGP multipath routes or, in domain boundary scenarios, sums only local link bandwidth.

Workflow

These stages describe the policy-based cumulative bandwidth advertisement process:

  1. Defining targeted prefixes: The administrator creates a route policy that matches specific prefixes which should participate in cumulative bandwidth advertisement.

  2. Attaching the policy to BGP multipath computation: The router attaches the route policy to the relevant BGP instances, ensuring those policies are consulted during multipath route calculation.

  3. Determining the basis for bandwidth summation: The BGP process uses policy instructions to aggregate either the effective bandwidth of all eBGP multipaths or, in domain boundary scenarios, sums only the local link bandwidth for each path.

    • Default (effective bandwidth): The router sums the effective bandwidth of each eBGP multipath, a flexible value that can itself be influenced by other policy criteria (such as combining local and received bandwidths).

    • Link-bandwidth option (domain boundaries): The administrator can override the default and instruct the router to aggregate only the local link-bandwidth of each path. This approach ensures that local load balancing considers both received and local bandwidth. However, cumulative bandwidth advertisements to other domains are restricted to local changes, which prevents destabilizing updates triggered by changes in remote parts of the network.

  4. If suppression is configured, BGP compares the new cumulative bandwidth with the last advertised value. If the change is below the configured threshold, the update is suppressed and not advertised.

    Only significant changes for selected prefixes or domains are advertised to neighbors.

Configuring policy-based cumulative bandwidth advertisement in BGP

These sections describe how to configure each aspect of policy-based cumulative bandwidth advertisement in BGP.

Configure selective cumulation

Enable selective cumulation so that cumulative bandwidth is advertised only for specific BGP prefixes, based on operator-defined policies.

Procedure

Step 1

Define a route-policy that matches the BGP prefixes for which you want to enable cumulative bandwidth advertisement.

Example:
Router(config)# route-policy mp_rpl
Router(config-rpl)# if community matches-any (1:1) then
Router(config-rpl-if)# set multipath advertise cumulative-bandwidth
Router(config-rpl-if)# else
Router(config-rpl-else)# pass
Router(config-rpl-else)# endif
Router(config-rpl)# end-policy

Step 2

Apply the route policy to selectively advertise cumulative bandwidth to BGP neighbors.

Example:
Router(config)# router bgp 1
Router(config-bgp)# maximum-paths ebgp 16 selective route-policy mp_rpl bestpath-only
Router(config-bgp)# neighbor 192.0.2.1
Router(config-bgp-nbr)# ebgp-send-extcommunity-dmz cumulative

The bestpath-only keyword optimizes multipath computation when you only need to customize bandwidth cumulation and suppression. Without bestpath-only , any bandwidth change forces BGP to walk all paths to evaluate cumulation and suppression for a prefix.

Step 3

Use the show bgp command to verify if selective cumulation is enabled.

Example:
Router# show bgp 10.1.0.0

BW cumulation enabled
Paths: (2 available, best #1)
Path #1: Received by speaker 0
10.3.0.4 from 10.3.0.7 (10.3.3.3)
  Community: 1:1
Path #2: Received by speaker 0
10.4.0.4 from 10.4.0.4 (10.3.3.3)
   Community: 1:1

In this example, cumulation is enabled because the route has matched the community 1:1.

Configure effective bandwidth

Configure how BGP calculates effective bandwidth for UCMP routing.

Effective bandwidth impacts route selection in UCMP by assigning appropriate weights to each route.

Procedure

Step 1

Create a route-policy specifying how the effective bandwidth should be calculated for each route.

You can use local link bandwidth, received bandwidth, or a function (multiplication or division) of both. You can also apply a scaling factor.

  • To use local link bandwidth:

    Router# configure
Router(config)# route-policy effective-bw
Router(config-rpl)# set effective-bandwidth install value link-bandwidth

  • To use received bandwidth:

    Router# configure
Router(config)# route-policy effective-bw
Router(config-rpl)# set effective-bandwidth install value received-bandwidth

  • To use a function with scaling:

    Router# configure
Router(config)# route-policy effective-bw
Router(config-rpl)# set effective-bandwidth install value function (link-bandwidth * received-bandwidth)
Router(config-rpl)# set effective-bandwidth install value / 12500000000

    12500000000 is the minimum interface LBW in a bundle interface (100 Gps = 1.25 x 10^10 byte/s)

Step 2

Use the show bgp command to verify if effective bandwidth is configured.

Example:
Router# show bgp 10.0.0.0/8
Path #1: Received by speaker 0
10.1.0.1 from 10.1.0.1 (10.1.1.1)
  Community: 1:1
  Extended community: LB:23456:399999991.808 
  Eff-bw: Link-BW times Received-BW, BW factor 0.000000
Path #2: Received by speaker 0
10.2.0.2 from 10.2.0.2 (10.1.1.1)
  Community: 1:1
  Extended community: LB:23456:399999991.808 
  Eff-bw: Link-BW times Received-BW, BW factor 8.000000e-11

Step 3

Use the show route command to verify the path weight assignment in RIB.

Example:
Router# show route 10.0.0.0/8
10.1.0.1, from 10.1.0.1, BGP external, BGP multi path
      Route metric is 0, Wt is 800000000
    …

In this sample output, the Wt (weight) value is derived from the effective bandwidth calculation as specified in the policy.

Effective bandwidth = (Received-bandwidth * link-bandwidth ∗ number of PHY for each bundle) / link-bandwidth. For example,

Received BW = 400G
Link-bandwidth = 200000000
Number of PHY in bundle = 2
Effective BW = 400G * 2 = 800G

The bandwidth value in Kbps should be used as the path weight in the RIB. If the bandwidth is greater than 4,294,967,040, it is scaled down, so the path weight in the RIB no longer matches the effective bandwidth calculated by BGP.

Configure suppression of insignificant bandwidth changes

Suppress the advertisement of cumulative bandwidth changes that are below a specified threshold, ensuring only significant changes are sent to BGP peers.

Procedure

Create a route-policy that enables cumulative bandwidth advertisement and specifies a suppression threshold (delta value). You can configure suppression for link-bandwidth, received-bandwidth, or effective bandwidth. Different thresholds can be set for each type.

  • Example: (Received bandwidth)
    Router# configure
Router(config)# route-policy supr1
Router(config-rpl)# set multipath advertise cumulative-bw suppress received-bandwidth delta-value 100
Router(config-rpl)# exit
  • Example: (Link bandwidth)
    Router# configure
Router(config)# route-policy supr1
Router(config-rpl)# set multipath advertise cumulative-bandwidth suppress link-bandwidth delta-value 500
Router(config-rpl)# exit
  • Example: (Effective bandwidth)
    Router# configure
Router(config)# route-policy supr1
Router(config-rpl)# set multipath advertise cumulative-bandwidth suppress delta-value 190000000
Router(config-rpl)# set multipath advertise cumulative-bandwidth suppress delta-value *125
Router(config-rpl)# exit

    In the effective bandwidth example, the threshold is calculated as 190,000,000 * 125.

    The delta-value setting applies to all combinations of effective bandwidth type and cumulation type.

Note

 

  • Suppression of bandwidth changes takes effect only when cumulation is enabled.

  • Suppression applies to all prefixes selected by the multipath policy.

  • The suppression threshold is global per prefix, not per neighbor.

  • The link-bandwidth or received-bandwidth delta-value applies only when using the effective bandwidth function with cumulative bandwidth.

Configure advertised bandwidth rounding to the nearest multiple

Standardize BGP-advertised bandwidth by rounding each value to the nearest configured multiple, maintaining operational consistency and supporting interoperability with peers or hardware that require specific increments (for example, 100G, 200G).

Before you begin

  • Identify the rounding multiple required for your network environment (for example, 10000000000).

  • Ensure that a route-policy for the BGP neighbor is created and available or ready to be created.

Procedure

Set the advertised bandwidth to round to the nearest specified multiple.

Example:
Router# route-policy nbr-outbnd-plcy
Router(config-rpl)# set bandwidth round-to-nearest multiple 10000000000 floor
Router(config-rpl)# end-policy

  • ceiling rounds up to the next multiple.

  • floor rounds down.

  • If neither is specified, system default behavior applies.

Configure outbound policy actions based on advertised bandwidth

Set up a BGP outbound route-policy that applies actions such as setting communities or AS path prepending, based on the value of the bandwidth being advertised to a BGP neighbor.

This configuration enables you to use the bandwidth value as a condition in outbound route-policies. Actions can be triggered if the bandwidth is less than, equal to, or greater than a specific value. This approach is useful for dynamic signaling or marking of routes according to available bandwidth.

Procedure

Use the if bandwidth command to specify the bandwidth threshold and the actions to take.

Example:
Router# route-policy ngbr-outbnd-polcy
Router(config-rpl)# if bandwidth ge 40000000000 then
Router(config-rpl-if)# set community 123:400 additive
Router(config-rpl-if)# elseif bandwidth le 10000000000 then
Router(config-rpl-elseif)# as-path prepend 65000 4
Router(config-rpl-elseif)# set community 123:100 additive
Router(config-rpl-elseif)# endif

In this example, a community is set when the bandwidth is greater than or equal to 40000000000. If the bandwidth is less than or equal to 10000000000, the AS path is prepended and a different community is set.