Configuring Modular QoS Congestion Management

Chapter Topics

• Congestion Management Overview
• Class-based Weighted Fair Queueing (CBWFQ)
• Low-Latency Queuing with Strict Priority Queuing (LLQ)
• Bandwidth Remaining
• Overhead Accounting
• Traffic Shaping
• Traffic Policing (Single-Rate, Two-Rate, Packets-Per-Second)
• Shared Policer
• Prioritize Traffic during Oversubscription
• References for Modular QoS Congestion Management

Congestion Management Overview

Congestion management features enable control over network congestion by prioritizing traffic based on assigned priorities. This involves creating queues, classifying packets into these queues, and scheduling them for transmission.

Supported traffic regulation mechanisms include:

• Class-based Weighted Fair Queueing (CBWFQ)
• Low-Latency Queuing with Strict Priority Queuing (LLQ)
• Traffic Shaping
• Traffic Policing

Class-based Weighted Fair Queueing (CBWFQ)

CBWFQ allows defining traffic classes based on customer match criteria. It enables the assignment of guaranteed minimum bandwidth to these classes and supports a strict priority queue for delay-sensitive traffic.

Bandwidth Remaining

The CBWFQ algorithm uses the 'bandwidth remaining' value to derive weights for each class. After servicing priority queues, leftover bandwidth is distributed based on the bandwidth remaining ratio (BWRR) or percentage. If not configured, BWRR defaults to 1. For 'bandwidth remaining percent', the remaining bandwidth is equally distributed among other classes to reach 100%.

Restrictions

• The bandwidth remaining command is supported only for egress policies.

Configuring Bandwidth Remaining

This procedure configures minimum bandwidth and bandwidth remaining on the router.

Supported Platforms: Cisco NCS 540 Series Routers.

Note: bandwidth, bandwidth remaining, shaping, queue-limit, and wred commands can be configured together in the same class. However, priority cannot be configured with bandwidth, bandwidth remaining, or wred.

Configuration Example:

To configure bandwidth remaining, follow these steps:

1. Create or modify a policy-map.
2. Specify the traffic class.
3. Allocate leftover bandwidth for the class.
4. Attach the policy-map to an output interface.

Router# configure
Router(config)#class-map qos-6
Router(config-cmap)#match traffic-class 4
Router(config-cmap)#exit
Router(config-cmap)#commit
Router(config)#class-map qos-5
Router(config-cmap)#match traffic-class 5
Router(config-cmap)#commit
Router(config)# policy-map test-bw-bw-rem
Router(config-pmap)# class qos-6
Router(config-pmap-c)# bandwidth percent 60
Router(config-pmap-c)# bandwidth remaining percent 60
Router(config-pmap)#class qos-5
Router(config-pmap-c)#bandwidth percent 20
Router(config-pmap-c)#bandwidth remaining percent 40
Router(config-pmap-c# exit
Router(config-pmap)# exit
Router(config)# interface HundredGigE 0/6/0/18
Router(config-if)# service-policy output test-bw-bw-rem
Router(config-if)# commit

Running Configuration

policy-map test-bw-bw-rem
 class qos-6
  bandwidth percent 60
  bandwidth remaining percent 60
 !
 class qos-5
  bandwidth percent 20
  bandwidth remaining percent 40
 !
 class class-default
 !
end-policy-map
!
interface HundredGigE0/6/0/18
 service-policy output test-bw-bw-rem
!

Verification

Use the show qos interface <interface_name> output command to verify.

Router# show qos interface HundredGigE 0/6/0/18 output
NOTE:- Configured values are displayed within parentheses
Interface HundredGigE0/6/0/18 ifh 0x3000220 -- output policy

NPU Id:
3
Total number of classes:
3
Interface Bandwidth:
100000000 kbps
VOQ Base:
11176
VOQ Stats Handle:
0x88550ea0
Accounting Type:
Layer1 (Include Layer 1 encapsulation and above)
------------------------------------------------------------------------------
Level1 Class
= qos-6
Egressq Queue ID
= 11182 (LP queue)
Queue Max. BW.
= 100824615 kbps (default)
Queue Min. BW.
= 60494769 kbps (60 %)
Inverse Weight / Weight
= 2 (60%)
Guaranteed service rate
= 71881188 kbps
TailDrop Threshold
= 90177536 bytes / 10 ms (default)
WRED not configured for this class

Level1 Class
= qos-5
Egressq Queue ID
= 11181 (LP queue)
Queue Max. BW.
= 100824615 kbps (default)
Queue Min. BW.
= 20164923 kbps (20 %)
Inverse Weight / Weight
= 3 (40%)
Guaranteed service rate
= 27920792 kbps
TailDrop Threshold
= 35127296 bytes / 10 ms (default)
WRED not configured for this class

Level1 Class
= class-default

Low-Latency Queuing with Strict Priority Queuing (LLQ)

LLQ integrates strict priority queuing (PQ) into CBWFQ, ensuring that delay-sensitive traffic (like voice) is dequeued and sent before other traffic. This can potentially starve lower-priority queues if bandwidth is limited.

Guidelines

• Priority levels 1-7 are supported (1 highest, 7 lowest). CoSQ 0 is the lowest priority.
• Egress policing is not supported.
• shape average and queue-limit commands can be used with priority.

Configuration Example:

To configure LLQ with strict priority queuing:

1. Create or modify a policy-map.
2. Specify the traffic class.
3. Specify priority for the traffic class.
4. (Optional) Shape traffic to a specific bit rate.
5. Attach the policy-map to an output interface.

Router# configure
Router(config)#class-map qos-1
Router(config-cmap)#match traffic-class 1
Router(config-cmap)#commit
Router(config)#class-map qos-2
Router(config-cmap)#match traffic-class 2
Router(config-cmap)#commit
Router(config)# policy-map test-priority-1
Router(config-pmap)# class qos1
Router(config-pmap-c)# priority level 7
Router(config-pmap-c)# shape average percent 2
Router(config-pmap-c)# class qos-2
Router(config-pmap-c)# priority level 6
Router(config-pmap-c)# shape average percent 1
Router(config-pmap-c)# commit
Router(config-pmap-c# exit
Router(config-pmap)# exit
Router(config)# interface HundredGigE 0/0/0/20
Router(config-if)# service-policy output test-priority-1
Router(config-if)# commit

Running Configuration

policy-map test-priority-1
 class qos-1
  priority level 7
  shape average percent 2
 !
 class qos-2
  priority level 6
  shape average percent 1
 !
 class class-default
 !
end-policy-map
!
interface HundredGigE0/0/0/20
 service-policy output test-priority-1
!

Verification

Use show qos int <interface_name> output.

Overhead Accounting

QoS overhead accounting allows operators to account for header bytes added or removed by intermediate hops, ensuring accurate QoS measurements. It can adjust policing and shaping rates accordingly, either increasing (negative accounting) or decreasing (positive accounting) them.

Guidelines and Restrictions

• Ingress shaping does not support overhead accounting.
• Only one compensation value per NPU or router is allowed.
• The same egress compensation can be used for different egress ports.

Configuring for Overhead Accounting

Steps:

1. Create a policy-map with QoS actions.
2. Configure overhead accounting and attach the map to an interface.

/* create QoS policy */
Router#configure terminal
Router(config)#policy-map policer
Router(config-pmap)#class class-default
Router(config-pmap-c)#police rate percent 10
Router(config-pmap-c-police)#commit
/* configure account overhead value while attaching the QoS policy to interface */
Router(config)#int hundredGigE 0/0/0/2
Router(config-if)#service-policy input policer account user-defined 12
Router(config-if)#commit
Router(config-if)#root
Router(config)#end

Running Configuration

interface HundredGigE0/0/0/2
 service-policy input policer account user-defined 12
!

Example for Negative Overhead Accounting:

Router#conf
Router(config)#int hundredGigE 0/0/0/2
Router(config-if)#service-policy input policer account user-defined -12
Router(config-if)#commit

To modify an overhead accounting value:

1. Remove the existing QoS policy and re-add it.
2. Configure the new overhead accounting value.

Traffic Shaping

Traffic shaping controls the traffic flow exiting an interface to match the speed of the remote target interface, ensuring compliance with contracted policies. It helps eliminate bottlenecks in topologies with data-rate mismatches.

Note: Traffic shaping is supported only in egress direction.

Configure Traffic Shaping

Shaping is performed at Layer 1 and includes the Layer 1 header in rate calculation.

Guidelines

• Only egress traffic shaping is supported.
• All eight traffic classes (including class-default) must be configured for egress policies.
• shape average can be configured with priority.

Configuration Example:

To configure traffic shaping:

1. Create or modify a policy-map.
2. Specify the traffic class.
3. Shape traffic to a specific bit rate and set peak burst size.
4. Attach the policy-map to an output interface.

Router# configure
Router(config)#class-map c5
Router(config-cmap)#match traffic-class 5
Router(config-cmap)#commit
Router(config)# policy-map egress_policy1
Router(config-pmap)# class c5
Router(config-pmap-c)# shape average 40 percentpercent 50 1000
Router(config-pmap-c# exit
Router(config-pmap)# exit
Router(config)# interface HundredGigE 0/1/0/0
Router(config-if)# service-policy output egress_policy1
Router(config-if)# commit

Running Configuration

class-map c5
 match traffic-class 5
commit
policy-map egress_policy1
 class c5
  shape average percent 40
 !
 class class-default
 !
end-policy-map
!
interface HundredGigE0/6/0/18
 service-policy output egress_policy1
!

Verification

Use show qos interface <interface_name> output.

Traffic Policing

Traffic policing controls the maximum rate of traffic sent or received on an interface using a token bucket algorithm. It helps manage bandwidth by setting committed information rate (CIR) and burst sizes (Bc, Be).

Supported policing modes:

• Single-Rate Two-Color (SR2C)
• Single-Rate Three-Color (SR3C)
• Two-Rate Three-Color (2R3C)

Restrictions

• Policing is supported only in ingress direction and color-blind mode.
• Policing rate accuracy may vary by +/-2%.

Committed Bursts and Excess Bursts

Policers use committed burst (bc) and excess burst (be) values to ensure the CIR is met. Burst parameters are recommended to be equal to the round-trip time bit-rate.

Single-Rate Policer

Single-Rate Two-Color (SR2C): Uses one token bucket with conform and exceed actions.

Single-Rate Three-Color (SR3C): Uses one token bucket with conform, exceed, and violate actions, based on CBS and EBS.

Workflow of Single-Rate Two-Color Policer:

A packet of size B arrives. The token bucket is checked against the Committed Information Rate (CIR) and Committed Burst (Bc). If B is less than or equal to the available tokens in the bucket (B <= Tc), the packet conforms and an action is performed. If B is greater than the available tokens (B > Tc), the packet exceeds, and a different action is performed.

Configure Traffic Policing (Single-Rate Two-Color)

Configuration Example:

Router# configure
Router(config)# policy-map test-police-1
Router(config-pmap)# class ipv6-6
Router(config-pmap-c)# set dscp cs2 (optional)
Router(config-pmap-c)# set qos-group 7 (optional)
Router(config-pmap-c)# police rate percent 20 burst 10000 bytes
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface HundredGigE 0/6/0/18
Router(config-if)# service-policy input test-police-1
Router(config-if)# commit

Configure Traffic Policing (Single-Rate Three-Color)

Configuration Example:

Router# configure
Router(config)# policy-map test-police-1R3C
Router(config-pmap)# class ipv4-5
Router(config-pmap-c)# set qos-group 2 (optional)
Router(config-pmap-c)# police rate percent 20 burst 100000 bytes peak-burst 190000 bytes
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface HundredGigE 0/6/0/18
Router(config-if)# service-policy input test-police-1R3C
Router(config-if)# commit

Two-Rate Policer

The two-rate policer uses two token buckets (committed and peak) to manage traffic rates (CIR and PIR). It provides three actions: conform, exceed, and violate.

Figure 2: Marking Packets and Assigning Actions—Two-Rate Policer:

This diagram illustrates the two-rate policer's packet marking process. A packet of size B arrives. It is compared against the Peak Information Rate (PIR) and Committed Information Rate (CIR) using their respective burst sizes (Be and Bc). If B exceeds PIR, it's marked 'Violate' (action). If B exceeds CIR but not PIR, it's marked 'Exceed' (action). If B does not exceed CIR, it's marked 'Conform' (action).

Configure Traffic Policing (Two-Rate Three-Color)

Configuration Example:

Router(config-pmap)# class ipv4-7
Router(config-pmap-c)# set qos-group 4
Router(config-pmap-c)# police rate percent 20 burst 100000 bytes peak-rate percent 50 peak-burst 200000 bytes
Router(config-pmap-c-police)# exit
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# interface HundredGigE 0/6/0/18
Router(config-if)# service-policy input policy1
Router(config-if)# commit

Packets-Per-Second-Based Policer

This feature allows configuring policer rates in packets per second (pps) in addition to bits per second (bps). It is effective against certain types of network attacks that use a high volume of small packets.

Restrictions and Guidelines

• Applicable only for ingress.
• Burst size must be configured in packets when using pps.
• Parent and child policy maps must use the same unit-based policer (bps or pps).

Configure pps-based policer

Steps:

1. Configure a class map.
2. Create a service policy map and configure pps values.
3. Attach the service policy to an interface.

/*Configure a class map*/
Router(config)#class-map prec1
Router(config-cmap)#match precedence 1
Router(config-cmap)# exit
Router(config)# commit
/*Create a service policy map*/
Router(config)# policy-map policy1
Router(config-pmap)# class prec1
Router(config-pmap-c)#police rate 1000 pps burst 300 packets
Router(config-pmap-c-police)#exit
Router(config-pmap-c)#exit
Router(config-pmap)#exit
Router(config)# commit
/*Attach the service policy to an interface*/
Router#int hundredGigE 0/7/0/2
Router(config-if)service-policy input policy1
Router(config-if)#exit
Router(config)#commit

Shared Policer

The shared policer feature allows sharing a single policer bucket instance among multiple classes within a QoS policy map. This ensures that classes sharing the policer use the same token bucket.

Policer Bucket Shared

Defines and shares a policer bucket instance among multiple classes.

Policer Bucket Referred

Refers to a defined policer bucket instance. Shared policer is not supported across policy levels (e.g., parent/child policies cannot share a bucket).

Shared Policer Statistics

Statistics can be accessed in Aggregate Mode (combined stats) or Per-Class Mode (individual stats, disables PBTS).

Restrictions and Guidelines

• Per-class mode disables PBTS.
• Not supported across policy levels or in ingress peering mode.
• Supported within classes of the same policy.

Configuring Shared Policer

Steps:

1. Create class maps for matching packets.
2. Create a policy map.
3. Specify class names.
4. Define and share a policer bucket.
5. Refer a shared policer bucket.

RP/0/RSP0/CPU0:ios(config)#class-map match-any c1
RP/0/RSP0/CPU0:ios(config-cmap)#match precedence 1
RP/0/RSP0/CPU0:ios(config-cmap)#end-class-map
RP/0/RSP0/CPU0:ios(config)#class-map match-any c2
RP/0/RSP0/CPU0:ios(config-cmap)#match precedence 2
RP/0/RSP0/CPU0:ios(config-cmap)#end-class-map
RP/0/RSP0/CPU0:ios(config)#policy-map s-pol
RP/0/RSP0/CPU0:ios(config-pmap)#class c1
RP/0/RSP0/CPU0:ios(config-pmap-c)#police bucket shared 1 rate 10 mbps
RP/0/RSP0/CPU0:ios(config-pmap-c-police)#exit
RP/0/RSP0/CPU0:ios(config-pmap-c)#exit
RP/0/RSP0/CPU0:ios(config-pmap)#class c2
RP/0/RSP0/CPU0:ios(config-pmap-c)#police bucket referred 1
RP/0/RSP0/CPU0:ios(config-pmap-c-police)#class class-default
RP/0/RSP0/CPU0:ios(config-pmap-c)#exit
RP/0/RSP0/CPU0:ios(config-pmap)#exit
RP/0/RSP0/CPU0:ios(config)#interface HundredGigE 0/6/0/18
RP/0/RSP0/CPU0:ios(config-if)#service-policy input s-pol
RP/0/RSP0/CPU0:ios(config-if)#commit

Prioritize Traffic during Oversubscription

Oversubscription occurs when the Packet Processing Unit (PPU) in the ASIC is overloaded. This feature allows prioritizing traffic based on Class of Service (CoS) values to protect high-priority traffic during such events.

Configuring Traffic Priorities on Tagged Interface

Configuration Example:

Router#configure
Router(config)#policy-map egress
Router(config-pmap)#class qos1
Router(config-pmap-c)#priority level 1
Router(config-pmap-c)#low-latency-profile
Router(config-pmap-c)#class class-default
Router(config-pmap-c)#end-policy-map
Router(config)#commit
Router(config)#end
Router#configure
Router(config)#hw-module profile qos hqos-enable
Router(config)#hw-module oversubscription
Router(config-oversubscription)#prioritize cos 1 interface tenGigE 0/0/0/0
Router(config-oversubscription)#commit

Configuring Traffic Priorities on Untagged Interface

Configuration Example:

Router#configure
Router(config)#hw-module profile qos hqos-enable
Router(config)#hw-module oversubscription
Router(config-oversubscription)#prioritize untagged interface tenGigE 0/0/0/10
Router(config-oversubscription)#commit

References for Modular QoS Congestion Management

Committed Bursts

The committed burst (bc) parameter defines the size of the conforming (green) token bucket. It determines how many bytes can be sent before the CIR is exceeded.

Excess Bursts

The excess burst (be) parameter defines the size of the exceeding (yellow) token bucket. It allows borrowing tokens when the conforming bucket is insufficient.