Overview

Describes support for processing DMZ transitive-bandwidth extended communities in BGP to enable bandwidth-aware routing decisions using UCMP and multivendor interoperability.

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 1. 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.

Policy-based bandwidth assignment: A BGP router assigns a DMZ transitive-bandwidth value to BGP routes using an egress or ingress RPL.
Propagation of the bandwidth attribute: The router propagates the transitive-bandwidth extended community along with the route to its BGP peers.
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.

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

	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`
	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`
	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 ! ! !`
	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
	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)
	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.`
	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

BGP DMZ transitive-bandwidth extended community support

Overview

Benefits of BGP DMZ transitive-bandwidth extended community

How BGP DMZ transitive-bandwidth extended communities work

Summary

Workflow

Result

Topology for BGP path selection using UCMP

Configure BGP DMZ transitive-bandwidth extended community

Before you begin

Procedure

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Need help?