Bandwidth remaining percent for class-based queuing | Congestion Management | Modular QoS Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

Describes how bandwidth remaining percent enables percentage-based sharing of available remaining egress bandwidth among class-based queues on supported Cisco 8000 Series routers.

Bandwidth remaining percent for class-based queuing is an egress congestion-management feature that

uses the bandwidth remaining percent percentage command to configure percentage-based sharing of available remaining bandwidth for a traffic class,
lets you express class-based queue bandwidth shares with values from 1 to 100 instead of ratio values, and
supports egress class-based queuing on supported main interfaces and subinterfaces for Layer 2 and Layer 3 use cases.

Use bandwidth remaining percent when you want the configured QoS policy to reflect how service classes, customer classes, AI workload traffic classes, or data center front-end traffic classes share available remaining egress bandwidth during congestion.

Bandwidth remaining percent does not guarantee bandwidth. It distributes available remaining bandwidth among eligible queues after priority traffic and explicit bandwidth reservations are serviced.

Before Cisco IOS XR Release 26.3.1 , supported Cisco 8000 Series routers used bandwidth remaining ratio for remaining-bandwidth allocation. With bandwidth remaining percent, you can configure percentage values directly and avoid translating service intent into ratio values.

The following table provides release information for bandwidth remaining percent.

Table 1. Feature History Table
Feature Name	Release Information	Feature Description
Bandwidth remaining percent for class-based queuing	Release 26.3.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100, K100], 8010 [ASIC: A100]); Centralized Systems (8400 [ASIC: K100]); Modular Systems (8800 [LC ASIC: P100, K100]) You can configure percentage-based sharing of remaining egress bandwidth among class-based queues on supported main interfaces and subinterfaces. This helps service provider and data center operators express bandwidth-sharing policies for customer services, AI workloads, and application traffic more intuitively without calculating scheduler ratios.

Bandwidth remaining percent and bandwidth remaining ratio both define how eligible class-based queues share available remaining egress bandwidth. Choose one method in a policy map.

Table 2. Bandwidth remaining percent and bandwidth remaining ratio
Bandwidth Remaining Percent	Bandwidth Remaining Ratio
Uses percentage values, such as bandwidth remaining percent 10 , to express the remaining-bandwidth share for a class.	Uses ratio values to express the relative remaining-bandwidth share for a class.
Helps align class-based queue bandwidth shares with service or workload intent that is already defined in percentages.	Helps define relative class weights when the policy design uses ratio-based scheduling values.
Is mutually exclusive with bandwidth remaining ratio in the same policy map.	Is mutually exclusive with bandwidth remaining percent in the same policy map.

The following table summarizes how bandwidth remaining percent relates to shaping and policing.

Table 3. Bandwidth remaining percent, shaping, and policing
Bandwidth Remaining Percent	Traffic Shaping	Traffic Policing
Shares available remaining egress bandwidth among eligible queues during congestion.	Controls the egress transmission rate by scheduling packets to a configured rate.	Enforces an ingress or egress traffic contract by transmitting, marking, or dropping traffic.
Uses bandwidth remaining percent percentage .	Uses commands such as shape average .	Uses commands such as police rate .

In show qos interface output, the configured percentage appears in parentheses in the Inverse Weight / Weight field.

Class-based remaining-bandwidth allocation

An operator wants to share available remaining egress bandwidth across service classes on a supported Cisco 8000 Series router. The policy assigns 10 percent shares to several traffic classes, a 5 percent share to another traffic class, and a priority level to latency-sensitive traffic.

During congestion, the bandwidth remaining percent classes share available remaining egress bandwidth according to the configured percentage values. The priority class uses priority queuing behavior, and the configured percentage values appear in the show qos interface output for the bandwidth remaining percent classes.

What bandwidth remaining percent is not

Bandwidth remaining percent is not to be confused with traffic shaping. It does not configure a fixed output rate for a class. Use shaping when you need to cap or smooth egress traffic to a configured rate.

Bandwidth remaining percent is not to be confused with traffic policing. It does not enforce a token-bucket traffic contract or define conform, exceed, or violate actions. Use policing when you need to enforce traffic rates by transmitting, marking, or dropping traffic.

Bandwidth remaining percent is also not a bandwidth guarantee or a tuning interface for the internal inverse-weight conversion. Configure the percentage value that matches the intended remaining-bandwidth sharing policy and use verification output to confirm the programmed value.

Benefits of bandwidth remaining percent for class-based queuing

Use this reference to identify the benefits, supported scope, and verification behavior for bandwidth remaining percent on supported Cisco 8000 Series routers.

Bandwidth remaining percent provides these benefits:

Percentage-based policy expression: You can configure remaining-bandwidth sharing with percentage values instead of calculating scheduler ratios.
Clearer service intent: QoS policies clarify how customer services, service classes, and application traffic share available remaining egress bandwidth during congestion.
Operational readability: Percentage values in policy maps are easier to review, communicate, and audit than ratio-only scheduling values.
AI and data center traffic planning: You can express bandwidth-sharing policies for competing non-priority flows, such as inference, storage, telemetry, checkpointing, and data center front-end traffic.
Main-interface and subinterface coverage: You can use bandwidth remaining percent on supported main interfaces and subinterfaces for Layer 2 and Layer 3 use cases.
Verification clarity: The show qos interface output displays the configured percentage in parentheses in the Inverse Weight / Weight field.

The following table lists the supported scope and behavior for bandwidth remaining percent.

Verification commands for bandwidth remaining percent

The following table shows what to verify in the command output for bandwidth remaining percent.

Table 4. Verification commands and output cues
Command	What the Output Shows	What to Check
show policy-map type qos interface interface output pmap-name policy-map-name	Classification statistics, transmitted traffic, dropped traffic, and queueing statistics for each class.	Check the queue ID and tail-drop counters for each class that is part of the egress queuing policy.
show qos interface interface output	Programmed queue details, including queue type and the Inverse Weight / Weight field.	Check that configured bandwidth remaining percent values appear in parentheses in the Inverse Weight / Weight field.
show policy-map pmap-name policy-map-name detail	The policy-map definition, class maps, bandwidth remaining percent values, and priority configuration.	Confirm that the configured policy contains the expected classes, bandwidth remaining percent values, and any priority class.

The following table shows the visible variations from the sample show qos interface output.

Table 5. Output variations for bandwidth remaining percent
Policy Configuration	Queue Type in Output	Inverse Weight / Weight Output	User Interpretation
bandwidth remaining percent 10	LP queue	5 / (10%)	The class is configured for a 10 percent share of available remaining egress bandwidth.
bandwidth remaining percent 5	LP queue	9 / (5%)	The class is configured for a 5 percent share of available remaining egress bandwidth.
priority level 1	HP1 queue	Not displayed for bandwidth remaining percent	The class uses priority queuing behavior and is not a bandwidth remaining percent class.
class-default without bandwidth remaining percent	Default LP queue	1 / (BWR not configured)	The default class does not have bandwidth remaining percent configured in the sample policy.

Guidelines for bandwidth remaining percent for class-based queuing

Use bandwidth remaining percent for bandwidth-sharing policies

Use bandwidth remaining percent when you want to express how eligible class-based queues share available remaining egress bandwidth during congestion.

Choose this option when service intent is easier to describe as percentage-based sharing than as scheduler ratios.
Apply it for competing non-priority flows, such as customer services, application traffic, inference, storage, telemetry, checkpointing, and data center front-end traffic.

This guideline applies to egress class-based queuing policies on supported main interfaces and subinterfaces for Layer 2 and Layer 3 use cases.

Percentage values make the policy intent easier to review, communicate, and audit than ratio-only scheduling values.

Bandwidth remaining percent does not guarantee bandwidth. The scheduler distributes available remaining bandwidth among eligible queues after priority traffic and explicit bandwidth reservations are serviced.

If you require a fixed maximum egress rate, configure shaping separately. For traffic-contract enforcement, use policing. For strict latency, use priority queuing.

Choose one remaining-bandwidth method per policy map

Configure either bandwidth remaining percent or bandwidth remaining ratio in a policy map.

Use bandwidth remaining percent when the policy design uses percentage-based sharing.
Use bandwidth remaining ratio when the policy design uses ratio-based scheduling weights.

This guideline applies within a single policy map.

In two-level queuing, the parent policy performs only traffic shaping. Bandwidth remaining ratio and bandwidth remaining percent apply to the child policy that performs class-based scheduling.

Mixing remaining-bandwidth ratio and percent across parent and child policies is not a valid use case.

Remove one remaining-bandwidth method from the policy map, and keep only the method that matches the policy design.

Configure supported values and interface scope

Configure bandwidth remaining percent percentage with a value from 1 to 100 on supported egress class-based queuing policies.

Ensure that the sum of all bandwidth remaining percent values configured across classes in the same policy map does not exceed 100 percent.
Apply the policy in the output direction.
Use the feature on supported main interfaces and subinterfaces for Layer 2 and Layer 3 scenarios.
For subinterface bandwidth distribution, configure bandwidth remaining percent in the parent policy map.

This guideline applies to supported A100, K100, and P100-based Cisco 8000 Series routers.

Staying within the supported value range, direction, and interface scope keeps the policy aligned with the documented feature behavior.

For unsupported interfaces, directions, or platforms, use an existing supported QoS mechanism for the policy goal.

Use shaping only for maximum-rate behavior

Add shaping only when the policy design requires peak information rate (PIR) or maximum-rate behavior.

Use bandwidth remaining percent for percentage-based sharing of available remaining egress bandwidth.
Use shape average when a class or parent policy must cap egress traffic to a configured rate.
Use shaping separately when the policy design requires peak information rate (PIR) or maximum-rate behavior.

This guideline applies when determining whether the bandwidth remaining percent configuration example or deployment policy also needs a shaper.

The bandwidth remaining percent example in this content does not include shape average , and shaping is not always required for this feature. This feature adds percentage-based remaining-bandwidth sharing; it does not add committed information rate (CIR) configuration with the bandwidth command.

Keeping remaining-bandwidth sharing and maximum-rate behavior separate helps users understand whether the policy is sharing remaining bandwidth, capping traffic, or doing both.

If the deployment requires a PIR or maximum-rate behavior, add the appropriate shaping configuration and verify it separately from the bandwidth remaining percent values.

Do not modify parent-class bandwidth remaining percent in place on subinterfaces

You cannot modify the parent-class bandwidth remaining percent value in place when it is configured for a subinterface.

This guideline applies to parent-level bandwidth remaining percent configuration specific to subinterface scheduling.

In-place modification is not supported for this subinterface parent-class configuration.

If you try to modify the value in place, the router displays this error: !!% Unsupported class-action: In Place modification of parent BRR not supported for sub-interfaces: InPlace Modify Error:

To change the value, detach the service policy, update the configuration, and then reapply the service policy.

Configure bandwidth remaining percent for class-based queuing

Use this task to configure percentage-based sharing of available remaining egress bandwidth among class-based queues.

Use percentage values when the policy intent is easier to express as service, customer, application, or AI workload bandwidth-sharing percentages than as scheduler ratios.
The configured percentage is a share of available remaining bandwidth during congestion. It is not a fixed bandwidth guarantee.

This example matches traffic by traffic-class values and and configures bandwidth remaining percent values to egress queues: 10 percent to traffic classes 1 through 5, 5 percent to class 6, and priority queuing to class 7.

The example does not include shape average . Add shaping only when the policy design requires peak information rate (PIR) or maximum-rate behavior.

Replace the class names, policy-map name, interface, traffic classes, and percentage values with values for your network.

Before you begin

Verify that your router supports bandwidth remaining percent on egress class-based queuing policies.
Identify the traffic classes that must share available remaining egress bandwidth.
Determine the percentage value for each class. The valid range is 1 to 100, and the sum of all bandwidth remaining percent values for classes in the same policy map must not exceed 100 percent.
Do not configure bandwidth remaining ratio and bandwidth remaining percent in the same policy map.
Identify the interface or subinterface where you want to attach the egress policy.

Follow these steps to configure bandwidth remaining percent for class-based queuing.

Procedure

Enter global configuration mode.
Example:
```
Router#configure 
```

Create class maps to identify the traffic classes that require bandwidth remaining percent or priority queuing.

Example:

Router(config)#class-map match-any classmap_1_1_1_0 
Router(config-cmap)#match traffic-class 1 
Router(config-cmap)#exit 
Router(config)#class-map match-any classmap_1_2_1_0 
Router(config-cmap)#match traffic-class 2 
Router(config-cmap)#exit 
Router(config)#class-map match-any classmap_1_3_1_0 
Router(config-cmap)#match traffic-class 3 
Router(config-cmap)#exit 
Router(config)#class-map match-any classmap_1_4_1_0 
Router(config-cmap)#match traffic-class 4 
Router(config-cmap)#exit 
Router(config)#class-map match-any classmap_1_5_1_0 
Router(config-cmap)#match traffic-class 5 
Router(config-cmap)#exit 
Router(config)#class-map match-any classmap_1_6_1_0 
Router(config-cmap)#match traffic-class 6 
Router(config-cmap)#exit 
Router(config)#class-map match-any classmap_1_7_1_0 
Router(config-cmap)#match traffic-class 7 
Router(config-cmap)#exit

This example uses traffic-class values as the match criteria. Use the match criteria that apply to your QoS design.

The class maps identify the traffic that the egress policy uses for bandwidth-sharing and priority treatment.

Create a policy map and configure bandwidth remaining percent values for the required traffic classes.

Example:

Router(config)#policy-map policymap_1_1_0 
Router(config-pmap)#class classmap_1_1_1_0 
Router(config-pmap-c)#bandwidth remaining percent 10 
Router(config-pmap-c)#exit 
Router(config-pmap)#class classmap_1_2_1_0 
Router(config-pmap-c)#bandwidth remaining percent 10 
Router(config-pmap-c)#exit 
Router(config-pmap)#class classmap_1_3_1_0 
Router(config-pmap-c)#bandwidth remaining percent 10 
Router(config-pmap-c)#exit 
Router(config-pmap)#class classmap_1_4_1_0 
Router(config-pmap-c)#bandwidth remaining percent 10 
Router(config-pmap-c)#exit 
Router(config-pmap)#class classmap_1_5_1_0 
Router(config-pmap-c)#bandwidth remaining percent 10 
Router(config-pmap-c)#exit 
Router(config-pmap)#class classmap_1_6_1_0 
Router(config-pmap-c)#bandwidth remaining percent 5 
Router(config-pmap-c)#exit 
Router(config-pmap)#class classmap_1_7_1_0 
Router(config-pmap-c)#priority level 1 
Router(config-pmap-c)#exit 
Router(config-pmap)#class class-default 
Router(config-pmap-c)#exit 
Router(config-pmap)#end-policy-map

Classes configured with bandwidth remaining percent share available remaining egress bandwidth after priority traffic and explicit bandwidth reservations are serviced. The class configured with priority level 1 uses priority queuing behavior and is not a bandwidth remaining percent class.

The policy map defines percentage-based remaining-bandwidth shares for the eligible traffic classes.

Apply the policy map to the interface in the egress direction.
Example:
```
Router(config)#interface HundredGigE0/0/0/4/0 
Router(config-if)#service-policy output policymap_1_1_0 
```
The output direction is the egress direction. Apply the policy to the supported interface or subinterface where you want the scheduler to share available remaining bandwidth by percentage.
Commit the configuration.
Example:
```
Router(config-if)#commit 
Router(config-if)#end 
```
The router attaches the egress QoS policy to the interface.

Verify traffic and queueing statistics for the egress policy.

Example:

Router#show policy-map type qos interface HundredGigE0/0/0/4/0 output pmap-name policymap_1_1_0 

HundredGigE0/0/0/4/0 output: policymap_1_1_0

Class classmap_1_1_1_0
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :          1845070012/674656525964         17297419
    Transmitted         :          1501200962/548657330452         14067302
    Total Dropped       :           343869050/125999195512          3230117
  Queueing statistics
    Queue ID                             : 929
    Taildropped(packets/bytes)           : 343869050/125999195512

Class classmap_1_6_1_0
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :          1845071526/674681793280         17299080
    Transmitted         :           834389984/304799226144          7814944
    Total Dropped       :          1010681542/369882567136          9484136
  Queueing statistics
    Queue ID                             : 934
    Taildropped(packets/bytes)           : 1010681542/369882567136

Class classmap_1_7_1_0
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :          1845071797/674708349485         17300036
    Transmitted         :          1845071797/674708349485         17300036
    Total Dropped       :                   0/0                    0
  Queueing statistics
    Queue ID                             : 935
    Taildropped(packets/bytes)           : 0/0

Class class-default
  Classification statistics          (packets/bytes)     (rate - kbps)
    Matched             :                   0/0                    0
    Transmitted         :                   0/0                    0
    Total Dropped       :                   0/0                    0

The output excerpt shows active classes, queue IDs, transmitted traffic, and tail-drop counters. Use these counters to confirm that the egress policy is active during congestion.

The statistics confirm that the configured classes are participating in egress queuing, which is where the bandwidth remaining percent policy applies.

Verify the programmed queue behavior and configured percentages.

Example:

Router#show qos interface HundredGigE0/0/0/4/0 output 
NOTE:- Configured values are displayed within parentheses
Interface HundredGigE0/0/0/4/0 ifh 0x78000408  -- output policy
NPU Id:                        0
Total number of classes:       8
Interface Bandwidth:           100000000 kbps
Policy Name:                   policymap_1_1_0
VOQ Base:                      928
Accounting Type:               Layer1 (Include Layer 1 encapsulation and above)
VOQ Mode:                      8
Shared Counter Mode:           1
------------------------------------------------------------------------------
Level1 Class                             =   classmap_1_1_1_0
Egressq Queue ID                         =   929 (LP queue)
Queue Max. BW.                           =   no max (default)
Inverse Weight / Weight                  =   5 / (10%)
TailDrop Threshold                       =   608256 bytes / 5 ms (default)
WRED not configured for this class

Level1 Class                             =   classmap_1_2_1_0
Egressq Queue ID                         =   930 (LP queue)
Queue Max. BW.                           =   no max (default)
Inverse Weight / Weight                  =   5 / (10%)
TailDrop Threshold                       =   608256 bytes / 5 ms (default)
WRED not configured for this class

Level1 Class                             =   classmap_1_3_1_0
Egressq Queue ID                         =   931 (LP queue)
Queue Max. BW.                           =   no max (default)
Inverse Weight / Weight                  =   5 / (10%)
TailDrop Threshold                       =   608256 bytes / 5 ms (default)
WRED not configured for this class

Level1 Class                             =   classmap_1_4_1_0
Egressq Queue ID                         =   932 (LP queue)
Queue Max. BW.                           =   no max (default)
Inverse Weight / Weight                  =   5 / (10%)
TailDrop Threshold                       =   608256 bytes / 5 ms (default)
WRED not configured for this class

Level1 Class                             =   classmap_1_5_1_0
Egressq Queue ID                         =   933 (LP queue)
Queue Max. BW.                           =   no max (default)
Inverse Weight / Weight                  =   5 / (10%)
TailDrop Threshold                       =   608256 bytes / 5 ms (default)
WRED not configured for this class

Level1 Class                             =   classmap_1_6_1_0
Egressq Queue ID                         =   934 (LP queue)
Queue Max. BW.                           =   no max (default)
Inverse Weight / Weight                  =   9 / (5%)
TailDrop Threshold                       =   608256 bytes / 5 ms (default)
WRED not configured for this class

Level1 Class (HP1)                       =   classmap_1_7_1_0
Egressq Queue ID                         =   935 (HP1 queue)
Queue Max. BW.                           =   no max (default)
TailDrop Threshold                       =   59996160 bytes / 5 ms (default)
WRED not configured for this class

Level1 Class                             =   class-default
Egressq Queue ID                         =   928 (Default LP queue)
Queue Max. BW.                           =   no max (default)
Inverse Weight / Weight                  =   1 / (BWR not configured)
TailDrop Threshold                       =   608256 bytes / 5 ms (default)
WRED not configured for this class

Check the percentage in parentheses in the Inverse Weight / Weight field. The classes configured with bandwidth remaining percent 10 display 5 / (10%) . The class configured with bandwidth remaining percent 5 displays 9 / (5%) .

The priority class appears as an HP1 queue instead of a bandwidth remaining percent queue. The class-default class displays BWR not configured because this example does not configure bandwidth remaining percent under class-default .

The output confirms that the scheduler programmed the configured bandwidth remaining percent values for the eligible queues and preserved priority behavior for the priority class.

Verify the configured policy definition.

Example:

Router#show policy-map pmap-name policymap_1_1_0 detail 
class-map match-any classmap_1_1_1_0
 match traffic-class 1
 end-class-map
!
class-map match-any classmap_1_2_1_0
 match traffic-class 2
 end-class-map
!
class-map match-any classmap_1_3_1_0
 match traffic-class 3
 end-class-map
!
class-map match-any classmap_1_4_1_0
 match traffic-class 4
 end-class-map
!
class-map match-any classmap_1_5_1_0
 match traffic-class 5
 end-class-map
!
class-map match-any classmap_1_6_1_0
 match traffic-class 6
 end-class-map
!
class-map match-any classmap_1_7_1_0
 match traffic-class 7
 end-class-map
!
policy-map policymap_1_1_0
 class classmap_1_1_1_0
  bandwidth remaining percent 10
 !
 class classmap_1_2_1_0
  bandwidth remaining percent 10
 !
 class classmap_1_3_1_0
  bandwidth remaining percent 10
 !
 class classmap_1_4_1_0
  bandwidth remaining percent 10
 !
 class classmap_1_5_1_0
  bandwidth remaining percent 10
 !
 class classmap_1_6_1_0
  bandwidth remaining percent 5
 !
 class classmap_1_7_1_0
  priority level 1
 !
 class class-default
 !
 end-policy-map
!

The policy definition confirms that the configured bandwidth remaining percent values and priority level 1 setting match the policy that is attached to the interface.

The interface has an egress class-based queuing policy that shares available remaining bandwidth among eligible queues by percentage. During congestion, the configured bandwidth remaining percent values make the service-class intent easier to verify without calculating bandwidth remaining ratios.

What to do next

After you deploy the policy, monitor the queue statistics for the configured traffic classes and adjust the percentage values if the bandwidth-sharing policy changes.

Use show qos interface to confirm that the configured percentages remain visible in the Inverse Weight / Weight field.
If you need to cap traffic to a maximum egress rate, configure shaping separately and verify the shaping behavior separately.