CISCO 8000 Series Routers Modular QoS Configuration User Guide

CISCO 8000 Series Routers Modular QoS Configuration

Product Information

Specifications

• Product Name: Modular QoS Configuration Guide for Cisco 8000
  Series Routers

• IOS XR Release: 7.3.x

• First Published: 2021-02-01

• Last Modified: 2022-01-01

• Manufacturer: Cisco Systems, Inc.

• Headquarters: San Jose, CA, USA

• Website: http://www.cisco.com

• Contact Tel: 408 526-4000, 800 553-NETS (6387)

• Fax: 408 527-0883

Product Usage Instructions

Chapter 1: New and Changed QoS Features
This chapter provides an overview of the new and changed Quality of Service (QoS) features in the Modular QoS Configuration Guide for Cisco 8000 Series Routers.

Chapter 2: Traffic Management Overview
This chapter explains the scope of traffic management, including traditional traffic management, traffic management on your router, limitations of the VoQ model, QoS policy inheritance, and the use of Cisco Modular QoS CLI to deploy QoS.

Scope
The scope of traffic management involves controlling and prioritizing network traffic to ensure efficient and reliable data transmission.

Traditional Traffic Management
Traditional traffic management involves implementing various techniques to manage network traffic, such as traffic shaping, policing, and queuing.

Traffic Management on Your Router
This section explains how traffic management is implemented on Cisco 8000 Series Routers, including the use of Modular QoS CLI (MQC) to define and apply QoS policies.

Limitations of the VoQ Model
The Voice over Quantum (VoQ) model has certain limitations in terms of scalability and complexity. This section discusses these limitations and provides insights into managing QoS in such scenarios.

QoS Policy Inheritance

QoS policy inheritance refers to the ability to inherit QoS configurations from parent policies. This section explains the concept of QoS policy inheritance and its benefits.

Cisco Modular QoS CLI to Deploy QoS
The Cisco Modular QoS CLI (MQC) is a command-line interface used to configure and deploy QoS policies on Cisco 8000 Series Routers. This section provides important information about using MQC for QoS deployment.

Chapter 3: Important Points about MQC Egress Queuing Policy
This chapter highlights important considerations and points to note when configuring the MQC egress queuing policy for effective QoS implementation.

Frequently Asked Questions (FAQ)

Q: What is traffic management?
A: Traffic management involves controlling and prioritizing network traffic to ensure efficient and reliable data transmission.

Q: How can I configure QoS policies on Cisco 8000 Series Routers?
A: You can use the Cisco Modular QoS CLI (MQC) to configure and deploy QoS policies on Cisco 8000 Series Routers.

Q: What are the limitations of the VoQ model?
A: The VoQ model has limitations in terms of scalability and complexity. It is important to understand these limitations when managing QoS in VoQ-based networks.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x
First Published: 2021-02-01 Last Modified: 2022-01-01
Americas Headquarters
Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000
800 553-NETS (6387) Fax: 408 527-0883

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE- NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
All printed copies and duplicate soft copies of this document are considered uncontrolled. See the current online version for the latest version.
Cisco has more than 200 offices worldwide. Addresses and phone numbers are listed on the Cisco website at www.cisco.com/go/offices.
The documentation set for this product strives to use bias-free language. For purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on standards documentation, or language that is used by a referenced third-party product.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/c/en/us/about/legal/trademarks.html. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1721R)
© 2021­2022 Cisco Systems, Inc. All rights reserved.

PREFACE CHAPTER 1 CHAPTER 2

CHAPTER 3

Preface vii Changes to This Document vii Communications, Services, and Additional Information vii
New and Changed QoS Features 1 New and Changed QoS Features 1
Traffic Management Overview 3 Scope 3 Traditional Traffic Management 3 Traffic Management on Your Router 3 Limitations of the VoQ Model 4 QoS Policy Inheritance 5 Cisco Modular QoS CLI to Deploy QoS 6 Important Points about MQC Egress Queuing Policy 6
Classify Packets to Identify Specific Traffic 9 Classify Packets to Identify Specific Traffic 9 Packet Classification Overview 9 Specification of the CoS for a Packet with IP Precedence 10 IP Precedence Bits Used to Classify Packets 10 IP Precedence Value Settings 10 IP Precedence Compared to IP DSCP Marking 11 Packet Classification on Your Router 11 Improve ACL Scaling Using Peering QoS 12 Essential Points about Merging ACLs 12

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x iii

Contents

CHAPTER 4 CHAPTER 5

Guidelines and Restrictions for Peering QoS 12 Configuring Peering QoS for ACL Scaling 13 Classify and Remark Layer 3 Header on Layer 2 Interfaces 19 Traffic Class Elements 20 Default Traffic Class 21 Create a Traffic Class 21 Traffic Policy Elements 23 Create a Traffic Policy 24 Attach a Traffic Policy to an Interface 24
Mark Packets to Change Priority Settings 29 Packet Marking Overview 29 Default Marking 29 QoS Behavior for Generic Routing Encapsulation (GRE) Tunnels 30 Packet Marking 30 QoS Behavior for Generic Routing Encapsulation (GRE) Tunnels 31 Class-based Unconditional Packet Marking Feature and Benefits 31 Configure Class-based Unconditional Packet Marking 32 Class-based Unconditional Packet Marking: Examples 33 IP Precedence Marking Configuration: Example 33 IP DSCP Marking Configuration: Example 34 QoS Group Marking Configuration: Example 34 CoS Marking Configuration: Example 34 MPLS Experimental Bit Imposition Marking Configuration: Example 35 MPLS Experimental Topmost Marking Configuration: Example 35 IP Precedence Compared to IP DSCP Marking 35 Configure DSCP CS7 (Precedence 7) 36 In-Place Policy Modification 36 Recommendations for Using In-Place Policy Modification 36
Congestion Avoidance 39 Congestion Avoidance 39 Queuing Modes 39 Main Interface Queuing Policy 40

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x iv

Contents

CHAPTER 6

Sub-Interface Queuing Policy 40 Congestion Avoidance in VOQ 40
Sharing of VOQ Statistics Counters 41 Configuring Sharing of VOQ Statistics Counters 41
Dual Queue Limit 42 Restrictions 43
Equitable Traffic Flow Using Fair VOQ 44 Fair VOQ: Why 44 Fair VOQ: How 45 Fair VOQ Modes and Sharing of Counters 46 Fair VOQs and Slice (or Normal) VOQs: Key Differences 47 Guidelines and Limitations 47 Configure Fair VOQ 48
Modular QoS Congestion Avoidance 50 Tail Drop and the FIFO Queue 50
Configure Tail Drop 50 Random Early Detection and TCP 52
Configure Random Early Detection 52 Explicit Congestion Notification 54
Configure Priority Flow Control 57 Priority Flow Control Overview 57 buffer- internal mode 59 Restrictions and Guidelines 59 buffer-extended mode 59 Important Considerations 60 Hardware Support for Priority Flow Control 61 Configure Priority Flow Control 61 Configurable ECN Threshold and Maximum Marking Probability Values 66 ECN Threshold and Maximum Marking Probability Values 66 Benefits of Configurable ECN Threshold and Maximum Marking Probability Values 67 ECN Threshold and Maximum Marking Probability Values: FAQs 68 Guidelines and Limitations 68 Configure ECN Threshold and Maximum Marking Probability Values 69

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x v

Contents

CHAPTER 7 CHAPTER 8

Priority Flow Control Watchdog Overview 71 Configure a Priority Flow Control Watchdog Interval 72
Congestion Management 75 Congestion Management Overview 75 Low-Latency Queueing with Strict Priority Queueing 75 Configure Low Latency Queueing with Strict Priority Queueing 75 Traffic Shaping 78 Configure Traffic Shaping 78 Traffic Policing 80 Committed Bursts and Excess Bursts 80 Single-Rate Policer 81 Two-Rate Policer 83 References for Modular QoS Management 85 Committed Bursts 85 Excess Bursts 86 Two-Rate Policer Details 87
Configure Modular QoS on Link Bundles 89 QoS on Link Bundles 89 Load Balancing 89 Configure QoS on Link Bundles 90

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x vi

Preface

This preface contains these sections:
· Changes to This Document, on page vii · Communications, Services, and Additional Information, on page vii

Changes to This Document

This table lists the technical changes made to this document since it was first published.
Table 1: Changes to this Document

Date January 2022
October 2021
May 2021 February 2021

Change Summary Republished with documentation updates for Release 7.3.3
Republished with documentation updates for Release 7.3.2
Republished for Release 7.3.15
Initial release of this document.

Communications, Services, and Additional Information
· To receive timely, relevant information from Cisco, sign up at Cisco Profile Manager. · To get the business impact you’re looking for with the technologies that matter, visit Cisco Services. · To submit a service request, visit Cisco Support. · To discover and browse secure, validated enterprise-class apps, products, solutions and services, visit
Cisco Marketplace. · To obtain general networking, training, and certification titles, visit Cisco Press. · To find warranty information for a specific product or product family, access Cisco Warranty Finder.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x vii

Preface

Preface
Cisco Bug Search Tool Cisco Bug Search Tool (BST) is a web-based tool that acts as a gateway to the Cisco bug tracking system that maintains a comprehensive list of defects and vulnerabilities in Cisco products and software. BST provides you with detailed defect information about your products and software.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x viii

1 C H A P T E R

New and Changed QoS Features

· New and Changed QoS Features, on page 1

New and Changed QoS Features

Table 2: QoS Features Added or Modified in IOS XR Release 7.3.x

Feature Equitable Traffic Flow Using Fair VOQ
Improve ACL Scaling Using Peering QoS

Description

Changed in Release

Configuring this feature Release 7.3.3 ensures that ingress traffic from various source ports on every network slice of an NPU is assigned a unique virtual output queue (VOQ) for every source port and destination port pair.

This feature merges the Release 7.3.2 functions of QoS and security access control lists (ACLs). This combination enables using the ACL filter with the Object Group ACL, which provides a vastly improved ACL scale due to much lower TCAM usage.

Where Documented Equitable Traffic Flow Using Fair VOQ, on page 44
Improve ACL Scaling Using Peering QoS , on page 12

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 1

New and Changed QoS Features

New and Changed QoS Features

Feature QoS Policy Inheritance

Description

Changed in Release

The functionality is based Release 7.3.15 on an inheritance model, where you create and apply a QoS policy to a main interface. The subinterfaces that are attached to the main interface automatically inherit the policy.

Priority Flow Control These line cards support Release 7.3.15 Support on Cisco 8800 the Priority Flow Control 36×400 GbE QSFP56-DD feature. Line Cards (88-LC0-36FH-M)

QoS Behavior for Generic With the introduction of Release 7.3.1 Routing (GRE) Tunnels support for GRE
encapsulation and decapsulation tunnel interfaces, there are some important updates to QoS behavior for GRE tunnels during encapsulation and decapsulation.

Where Documented QoS Policy Inheritance, on page 5
Priority Flow Control Overview, on page 57
Default Marking, on page 29 and Packet Marking, on page 30

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 2

2 C H A P T E R

Traffic Management Overview

Scope

· Scope, on page 3 · Traditional Traffic Management, on page 3 · Traffic Management on Your Router, on page 3 · Limitations of the VoQ Model, on page 4 · QoS Policy Inheritance, on page 5 · Cisco Modular QoS CLI to Deploy QoS, on page 6
Read this configuration guide to understand the overall architecture that powers the Cisco Quality of Service (QoS) technology, and also how to use its features to configure and manage the traffic bandwidth and packet loss parameters on your network.

Traditional Traffic Management
In traditional methods of traffic management, traffic packets are sent to the egress output queues without taking into consideration the egress interface availability to transmit.
Therein lies the problem as well. In case of a traffic congestion, the traffic packets may get dropped at the egress port. Which means that the network resources spent getting the packets from the ingress input queue across the switch fabric to the output queues at egress are wasted. That is not all–input queues buffer traffic meant for different egress ports, so congestion on one egress port could affect traffic on another port, an event referred to as head-of-line-blocking.

Traffic Management on Your Router
Your router’s Network Processing Unit (NPU) uses a coupled ingress-egress virtual output queuing (VoQ)-based forwarding architecture to manage traffic.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 3

Limitations of the VoQ Model Figure 1: Traffic flow from ingress port on slice 0 to an egress port on slot 3

Traffic Management Overview

Here, each ingress traffic class has a one-to-one VoQ mapping from each ingress slice (pipeline) to each egress port. Which means that every egress interface (#5 in the figure) has earmarked buffer space on every ingress pipeline (#1 in the figure) for each of its VoQs. Here is how the story of packet travel in times of congestion on your router system unravels: #1: Packets A (colored green), B (colored pink), and C (colored brown) are at the ingress interface. This is where packet marking, classification, and policing takes place. (For details, see Mark Packets to Change Priority Settings, on page 29, Classify Packets to Identify Specific Traffic, on page 9, and Congestion Management, on page 75 .) #2: These packets are stored in separate buffer storage spaces in dedicated VoQs. This is where queuing, VoQ transmit, and drop packet and byte counters come into play. (For details, see Congestion Avoidance, on page 39 .) #3: Depending on the bandwidth available on the egress interface, these packets are subjected to egress scheduling, where egress credit and transmit schedulers are configured. In other words, the packets and the sequence in which they will now proceed towards the egress interface is determined here. This is where the fabric bandwidth is taken into consideration for egress scheduling. #4: The packets are switched through the fabric. #5: In the final phase, the egress marking and classification takes place, and the congestion is managed in a way that at this stage there is no packet dropped, and all the packets are transmitted to the next hop.
Limitations of the VoQ Model
While the VoQ model of traffic management offers distinct advantages (reducing memory bandwidth requirements, providing end-to-end QoS flow), it has this limitation: The total egress queue scale is lower because each egress queue must be replicated as an ingress VoQ on each slice of each NPU/ASIC in the system. This means that with the addition of 1 NPU with 20 interfaces, the
Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 4

Traffic Management Overview

QoS Policy Inheritance

number of VoQs used on each and every NPU in the system will increase by 20 x 8 (queue/interface) = 160. There is also an increase in the number of credit connectors from each scheduler for each egress port on pre-existing NPUs to each slice in the newly inserted NPU.

QoS Policy Inheritance

Table 3: Feature History Table

Feature Name QoS Policy Inheritance

Release Information Release 7.3.15

Feature Description
To create QoS policies for subinterfaces, you had to apply the policy on each subinterface manually. From this release, all you do is create and apply a single QoS policy on the main interface and the subinterfaces automatically inherit the policy.
The inheritance model provides an easily maintainable method for applying policies, enabling you to create targeted policies for a group of interfaces and their subinterfaces. This model saves your time and resources while creating QoS policies.

· What is this functionality all about?–As the name suggests, the functionality is based on an inheritance model, where you create and apply a QoS policy to a main interface. The subinterfaces that are attached to the main interface automatically inherit the policy. The inheritance model applies to all QoS operations including: · Classification
· Marking
· Policing
· Shaping

· How does the inheritance model help?–Previously, if you had, for example, eight subinterfaces, you created and applied policies to each of those subinterfaces separately. With the inheritance model, you save on time and resources, with just one policy automatically applied across a main interface and its subinterfaces.
· Do I need to do anything more to enable the inheritance model?–No, you don’t. The inheritance model is the default option.
· What if I want to override the inheritance option?–Technically, you can’t override this option. However, you can remove the policy from main interface and add policies to the subinterfaces except to the ones where you don’t want the policy to be inherited.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 5

Cisco Modular QoS CLI to Deploy QoS

Traffic Management Overview

· What about policy-map statistics?–There’s no change to this behavior. Running the show policy-map interface command displays the cumulative statistics for an interface, and these numbers include the subinterfaces as well.
· Any limitations I need to be aware of?–There’s no support for ECN marking and egress marking policy on the same interface and subinterface combination. However, the QoS policy inheritance functionality accepts these multiple policies causing the ECN markings to fail. To prevent such failures: · Don’t configure an egress marking policy on a subinterface and apply an ECN-enabled policy on the main interface.
· Don’t apply an ECN policy on a subinterface and configure an egress marking policy on the main interface.
Cisco Modular QoS CLI to Deploy QoS
Cisco Modular QoS CLI (MQC) framework is the Cisco IOS QoS user language that enables: · a standard Command Line Interface (CLI) and semantics for QoS features.
· simple and accurate configurations.
· QoS provisioning within the context of an extensible language.
For your router, in the egress direction, two types of MQC policies are supported: queuing and marking. You use the queuing policy to configure credit scheduling hierarchy, rates, priority, buffering, and congestion avoidance. You use the marking policy to classify and mark packets that have been scheduled for transmission. Even when a queuing policy is not applied, there is an implicit queuing policy with TC7 – P1, TC6 – P2, TC5 – TC0 (6 x Pn), so packets marked with TC7 and control inject packets are always prioritized over other packets. In the ingress, only one policy is supported for classification and marking. You can apply queuing and marking policy independent of each other or together in the egress direction. If you apply both policies together, the queuing policy actions are provisioned first, followed by marking policy actions.
Important Points about MQC Egress Queuing Policy
These are important points that you must know about the MQC egress queuing policy: · The MQC queuing policy consists of a set of class maps, which are added to a policy map. You control queuing and scheduling parameters for that traffic class by applying actions to the policy.
· class-default always matches traffic-class 0. Also, no other class can match traffic-class 0.
· If a traffic class has no matching class in the applied policy map, it always matches class-default. In other words, it uses the traffic-class 0 VoQ.
· Each unique combination of traffic classes that match class-default require a separate traffic class (TC) profile. The number of TC profiles are limited to 8 for main interfaces and 8 for sub-interfaces.
· You cannot configure multiple traffic classes with the same priority level.
· Each priority level, when configured, must be configured to the class that matches the corresponding TC as shown in the following table.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 6

Traffic Management Overview

Important Points about MQC Egress Queuing Policy

Priority Level P1 P2 P3 P4 P5 P6 P7

Traffic Class 7 6 5 4 3 2 1

· If all the priority levels configured in a policy-map are sorted, they must be contiguous. In other words, you cannot skip a priority level. For example, P1 P2 P4 (skipping P3), is not allowed.
· From IOS XR Release 7.3.1 onwards, you can create a single set of contiguous priority TCs. Ensure that you assign priority levels that increase for every TC or remain the same, but don’t decrease. Also, make sure that you assign priority level 1 for traffic class 7. You need not configure unused traffic classes, so you can create only those many TCs that you require on the egress policy-map.
· MQC supports up to two levels (parent, child) of queuing policy. The parent level aggregates all the traffic classes and whereas the child level differentiates traffic classes using MQC classes.
· Only these actions are supported in the queuing policy: · priority
· shape
· bandwidth remaining ratio
· queue-limit
· Random Early Detection (RED)
· Priority flow control

· You can have only one match traffic-class value in the class map. · You cannot apply a queuing policy to a main interface and its sub-interfaces.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 7

Important Points about MQC Egress Queuing Policy

Traffic Management Overview

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 8

3 C H A P T E R
Classify Packets to Identify Specific Traffic
· Classify Packets to Identify Specific Traffic, on page 9 · Packet Classification Overview, on page 9 · Packet Classification on Your Router, on page 11 · Traffic Class Elements, on page 20 · Default Traffic Class, on page 21 · Create a Traffic Class, on page 21 · Traffic Policy Elements, on page 23 · Create a Traffic Policy, on page 24 · Attach a Traffic Policy to an Interface, on page 24
Classify Packets to Identify Specific Traffic
Read this section to get an overview of packet classification and the different packet classification types for your router.
Packet Classification Overview
Packet classification involves categorizing a packet within a specific group (or class) and assigning it a traffic descriptor to make it accessible for QoS handling on the network. The traffic descriptor contains information about the forwarding treatment (quality of service) that the packet should receive. Using packet classification, you can partition network traffic into multiple priority levels or classes of service. When traffic descriptors are used to classify traffic, the source agrees to adhere to the contracted terms and the network promises a quality of service. This is where traffic policers and traffic shapers come into the picture. Traffic policers and traffic shapers use the traffic descriptor of a packet–that is, its classification–to ensure adherence to the contract. The Modular Quality of Service (QoS) command-line interface (MQC) is used to define the traffic flows that must be classified, where each traffic flow is called a class of service, or class. Later, a traffic policy is created and applied to a class. All traffic not identified by defined classes fall into the category of a default class.
Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 9

Specification of the CoS for a Packet with IP Precedence

Classify Packets to Identify Specific Traffic

Note From Cisco IOS XR Release 7.2.12 onwards, you can classify packets on Layer 2 transport interfaces using Layer 3 header values. However, this feature applies only to the main interface (physical and bundle interfaces), and not on the sub-interfaces.
Specification of the CoS for a Packet with IP Precedence
Use of IP precedence allows you to specify the CoS for a packet. You can create differentiated service by setting precedence levels on incoming traffic and using them in combination with the QoS queuing features. So that, each subsequent network element can provide service based on the determined policy. IP precedence is usually deployed as close to the edge of the network or administrative domain as possible. This allows the rest of the core or backbone to implement QoS based on precedence.
Figure 2: IPv4 Packet Type of Service Field

You can use the three precedence bits in the type-of-service (ToS) field of the IPv4 header for this purpose. Using the ToS bits, you can define up to eight classes of service. Other features configured throughout the network can then use these bits to determine how to treat the packet in regard to the ToS to grant it. These other QoS features can assign appropriate traffic-handling policies, including congestion management strategy and bandwidth allocation. For example, queuing features such as LLQ can use the IP precedence setting of the packet to prioritize traffic.
IP Precedence Bits Used to Classify Packets
Use the three IP precedence bits in the ToS field of the IP header to specify the CoS assignment for each packet. You can partition traffic into a maximum of eight classes and then use policy maps to define network policies in terms of congestion handling and bandwidth allocation for each class. Each precedence corresponds to a name. IP precedence bit settings 6 and 7 are reserved for network control information, such as routing updates. These names are defined in RFC 791.
IP Precedence Value Settings
By default, the routers leave the IP precedence value untouched. This preserves the precedence value set in the header and allows all internal network devices to provide service based on the IP precedence setting. This policy follows the standard approach stipulating that network traffic should be sorted into various types of service at the edge of the network and that those types of service should be implemented in the core of the network. Routers in the core of the network can then use the precedence bits to determine the order of transmission, the likelihood of packet drop, and so on. Because traffic coming into your network can have the precedence set by outside devices, we recommend that you reset the precedence for all traffic entering your network. By controlling IP precedence settings, you
Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 10

Classify Packets to Identify Specific Traffic

IP Precedence Compared to IP DSCP Marking

prohibit users that have already set the IP precedence from acquiring better service for their traffic simply by setting a high precedence for all of their packets. The class-based unconditional packet marking and LLQ features can use the IP precedence bits.
IP Precedence Compared to IP DSCP Marking
If you need to mark packets in your network and all your devices support IP DSCP marking, use the IP DSCP marking to mark your packets because the IP DSCP markings provide more unconditional packet marking options. If marking by IP DSCP is undesirable, however, or if you are unsure if the devices in your network support IP DSCP values, use the IP precedence value to mark your packets. The IP precedence value is likely to be supported by all devices in the network. You can set up to 8 different IP precedence markings and 64 different IP DSCP markings.
Packet Classification on Your Router
On your router, there are two types of packet classification systems: · In the ingress direction, QoS map and Ternary Content Addressable Memory (TCAM).
Note TCAM is not supported on fixed-configuration routers (where router interfaces are built in). It is supported only on modular routers (that have multiple slots that allow you to change the interfaces on the router).
· In the egress direction, QoS map.
When a policy is matching only on Differentiated Services Code Point (DSCP) or precedence value (also called DSCP or Precedence-based classification), the system selects map-based classification system; else, it selects TCAM. The TCAM is an extension of the Content Addressable Memory (CAM) table concept. A CAM table takes in an index or key value (usually a MAC address) and looks up the resulting value (usually a switch port or VLAN ID). Table lookup is fast and always based on an exact key match consisting of two input values: 0 and 1 bits. The QoS map is a table-based classification system for traffic packets.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 11

Improve ACL Scaling Using Peering QoS

Classify Packets to Identify Specific Traffic

Improve ACL Scaling Using Peering QoS

Table 4: Feature History Table

Feature Name
Improve ACL Scaling Using Peering QoS

Release Information Release 7.3.2

Feature Description
This feature merges the functions of QoS and security access control lists (ACLs). This combination enables using the ACL filter with the Object Group ACL, which provides a vastly improved ACL scale due to much lower TCAM usage.
Before this functionality was introduced, ACLs applied for QoS group actions consumed a sizeable number of TCAM entries, reducing the available scale of the feature.

Peering QoS is an ingress QoS classification feature that allows you to merge the functions of QoS ACLs and security ACLs. It does so by enabling you to set QoS group actions for every access control entry (ACE) in a security ACL, thus avoiding multiple entries (for QoS and security) per ACE. You can then use this merged ACL with the Object Group ACL feature to apply the ACL filter (permit or deny) for ACEs. Object Group ACLs are also known as ‘compressed ACLs’ because the object group compresses multiple individual IP addresses into object groups. Also, in an object group-based ACL, you can create a single ACE that uses an object group name instead of creating many ACEs. This ability to ‘merge’ and ‘compress’ ACLs saves significant TCAM space and provides a vastly improved ACL scale for QoS policies.

Essential Points about Merging ACLs
· Ensure that you merge the ACLs (set QoS group actions for every ACE in the security ACL) before attaching them to the interface.
· The ACL merge is order-dependent. This means that ACEs are programmed in the order they appear in the ACL.

Guidelines and Restrictions for Peering QoS
· Only Layer 3 interfaces support peering QoS. Configurations on Layer 2 are rejected.
· Peering QoS is supported only in the ingress direction.
· Peering QoS policies and regular QoS policies can coexist on the same line card, but only if you attach them to different interfaces.
· You can attach the same peering QoS policy to multiple interfaces on the same line card.
· To account for IPv4 and IPv6 traffic separately, configure unique QoS group values for IPv4 and IPv6 security ACLs.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 12

Classify Packets to Identify Specific Traffic

Configuring Peering QoS for ACL Scaling

· Traffic marked with MPLS EXP bits on a peering QoS-configured interface is matched with class-default in a class map configured as match-any (default) for MPLS MPLS flows.
· Subinterfaces inherit peering QoS policies applied to main interfaces, but they don’t inherit ACLs. Ensure that you configure security ACLs (matching those on main interfaces) on all subinterfaces; otherwise, all subinterfaces traffic is subjected to class-default action, thus affecting their priority weightage.
· You can only configure match qos-group for peering QoS policies. Any other qos-group command is rejected.
· You can insert, delete, and modify ACEs in security ACLs.
Configuring Peering QoS for ACL Scaling
To configure peering QoS on an interface:
1. Configure security ACL and set qos-group per ACE. Else, qos-group is set to its default value of 0, affecting the priority weightage for traffic on the interface.
2. Configure peering QoS policy matching on qos-group that you set in the security ACL. Set QoS group actions such as remark, policer, traffic-class, DSCP, precedence, and discard-class.
3. Attach the security ACL and peering QoS ACL to the interface.
/Configure security ACL, in this example: ipv4-sec-acl/ Router(config)#ipv4 access-list ipv4-sec-acl
/set qos-group per ACE; you can do this because of peering QoS that enables the use of a single entry per ACE instead of multiple entries / Router (config-ipv4-acl)#10 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence priority set qos-group 1
Router(config-ipv4-acl)#20 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence immediate set qos-group 2
Router(config-ipv4-acl)30 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence flash set qos-group 3 Router(config-ipv4-acl)40 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence flash-override set qos-group 4 Router(config-ipv4-acl)50 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence critical set qos-group 5 Router (config-ipv4-acl)#60 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence internet set qos-group 6 Router(config-ipv4-acl)#70 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence network set qos-group 7 Router(config-ipv4-acl)#exit
/Configure peering QoS policy matching for each qos-group that you set in security ACL/ Router(config)#class-map match-any grp-7 Router(config- cmap)#match qos-group 7 Router(config-cmap)#end-class-map Router(config )#class-map match-any grp-6 Router(config-cmap)#match qos-group 6 Router (config-cmap)#end-class-map Router(config)#class-map match-any grp-5 Router (config-cmap)#match qos-group 5 Router(config-cmap)#end-class-map Router(config)#class-map match-any grp-4 Router(config-cmap)#match qos-group 4 Router(config-cmap)#end-class-map Router(config)#class-map match-any grp-3 Router(config-cmap)#match qos-group 3

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 13

Configuring Peering QoS for ACL Scaling

Classify Packets to Identify Specific Traffic

Router(config-cmap)#end-class-map Router(config)#class-map match-any grp-2 Router(config-cmap)#match qos-group 2 Router(config-cmap)#end-class-map Router(config)#class-map match-any grp-1 Router(config-cmap)#match qos-group 1 Router(config-cmap)#end-class-map Router(config)#class-map match-any class- default Router(config-cmap)#end-class-map
/Set Qos actions in the policy map configured, in this example: set prec, set tc, and set dscp/
Router(config)#policy-map ingress_qosgrp_to_Prec-TC Router(config-pmap)#class grp-7 Router(config-pmap-c)#set precedence 1 Router(config-pmap-c)#set traffic-class 7 Router(config-pmap-c)#exit Router(config-pmap)#class grp-6 Router(config-pmap-c)#set precedence 1 Router(config-pmap-c)#set traffic-class 6 Router(config-pmap-c)#exit Router(config-pmap)#class grp-5 Router(config- pmap-c)#set precedence 2 Router(config-pmap-c)#set traffic-class 5 Router (config-pmap-c)#exit Router(config-pmap)#class grp-4 Router(config-pmap-c)#set precedence 2 Router(config-pmap-c)#set traffic-class 4 Router(config- pmap-c)#exit Router(config-pmap)#class grp-3 Router(config-pmap-c)#set traffic-class 3 Router(config-pmap-c)#set dscp ef Router(config-pmap-c)#exit Router(config-pmap)#class grp-2 Router(config-pmap-c)#set precedence 3 Router (config-pmap-c)#set traffic-class 2 Router(config-pmap-c)#exit Router(config- pmap)#class grp-1 Router(config-pmap-c)#set precedence 4 Router(config- pmap-c)#set traffic-class 1 Router(config-pmap-c)#exit Router(config- pmap)#class class-default Router(config-pmap-c)#set precedence 5 Router (config-pmap-c)#exit Router(config-pmap)#end-policy-map
/Attach the security acl with match qos-groups, to the interface/ Router(config)#int bundle-Ether 350 Router(config-if)#ipv4 access-group ipv4 -sec-acl ingress
/Attach the policy map with qos actions that you set in the security acl, to the interface/ Router(config-if)#service-policy input ingress_qosgrp_to_DSCP_TC_qgrp Router(config-if)#commit Router(config-if)#exit
You have successfully used peering QoS to merge and compress security and QoS ACLs and achieved vastly improved ACL scales for QoS policies.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 14

Classify Packets to Identify Specific Traffic

Configuring Peering QoS for ACL Scaling

Running Configuration
ipv4 access-list ipv4-sec-acl 10 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence priority set qos-group 1 20 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence immediate set qos-group 2 30 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence flash set qos-group 3 40 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence flash-override set qos-group 4 50 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence critical set qos-group 5 60 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence internet set qos-group 6 70 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence network set qos-group 7
! class-map match-any grp-7
match qos-group 7 end-class-map ! class-map match-any grp-6 match qos-group 6 end-class-map ! class-map match-any grp-5 match qos-group 5 end-class-map ! class-map match-any grp-4 match qos-group 4 end-class-map ! class-map match- any grp-3 match qos-group 3 end-class-map ! class-map match-any grp-2 match qos-group 2 end-class-map ! class-map match-any grp-1 match qos-group 1 end- class-map ! class-map match-any class-default end-class-map ! policy-map ingress_qosgrp_to_Prec-TC class grp-7
set precedence 1 set traffic-class 7 ! class grp-6 set precedence 1 set traffic-class 6 ! class grp-5 set precedence 2 set traffic-class 5 ! class grp-4 set precedence 2 set traffic-class 4 ! class grp-3 set traffic-class 3 set dscp ef ! class grp-2

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 15

Peering QoS for ABF

Classify Packets to Identify Specific Traffic

set precedence 3 set traffic-class 2 ! class grp-1 set precedence 4 set traffic-class 1 ! class class-default set precedence 5 ! end-policy-map ! int bundle-Ether 350 ipv4 access-group ipv4-sec-acl ingress ! int bundle-Ether 350 service-policy input ingress_qosgrp_to_DSCP_TC_qgrp

Verification
Run the show interface command for the interface to which you attached the security and QoS ACLs.
Router#show run int bundle-Ether 350 interface Bundle-Ether350 service-policy input ingress_qosgrp_to_DSCP_TC_qgrp ipv4 address 11.25.0.1 255.255.255.0 ipv6 address 2001:11:25:1::1/64 ipv4 access-group ipv4-sec-acl ingress !

Peering QoS for ABF
Table 5: Feature History Table

Feature Name
ACL-Based Forwarding (ABF) support with peering QoS

Release Information Release 7.3.3

Feature Description
This feature gives you the flexibility to configure next-hop addresses for ACEs in the merged (QoS and security) ACL instead of the route that is selected by a routing protocol. You can configure VRF-select or VRF-aware next-hop addresses.
This feature enables you to have QoS and ABF functionalities within the same ACEs.

Starting with Release 7.3.3, the Cisco 8000 Series Routers support ACL-based forwarding with peering QoS. ACL-Based Forwarding (ABF) is a policy-based routing feature wherein the router forwards traffic matching specific ACL rules to a user-specified next-hop instead of the route selected by a routing protocol. The Peering QoS feature merges the QoS ACLs and security ACLs to avoid multiple entries (QoS and security) per ACE. In ABF support with peering QoS, you could configure next-hop addresses for ACEs in the merged (QoS and security) ACL. The next-hop address is made use for forwarding the incoming packets matching the permit ACEs to their destination. Here, ABF supports both VRF-select and VRF-aware redirect. In VRF-select, the next-hop consists of VRF only, and the VRF-aware next-hop consists of both VRF and IP addresses.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 16

Classify Packets to Identify Specific Traffic

Peering QoS for ABF

Configuration
1. Configure security ACL, in this example: abf-acl
Router(config)#ipv4 access-list abf-acl
2. Set qos-group per ACE; you can do this because of peering QoS that enables the use of a single entry per ACE instead of multiple entries.
Router(config-ipv4-acl)#10 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence priority set qos-group 1 nexthop1 vrf VRF1 nexthop2 vrf VRF2 nexthop3 vrf VRF3 Router(config-ipv4-acl)#20 permit tcp 135.0.0.0/8 217.0.0.0/8 precedence priority set qos-group 2 nexthop1 vrf vrf3 nexthop2 vrf vrf2 Router(config- ipv4-acl)#30 permit tcp 135.0.0.0/8 217.0.0.0/8 match-all +ack +psh set qos- group 3 nexthop1 vrf vrf2 nexthop2 vrf vrf3 nexthop3 vrf vrf1 Router(config- ipv4-acl)#40 permit tcp 135.0.0.0/8 217.0.0.0/8 precedence priority set qos- group 4 nexthop1 vrf vrf1 nexthop2 vrf vrf2 nexthop3 vrf vrf3 Router(config- ipv4-acl)#exit
3. Configure peering QoS policy matching for each qos-group that you set in security ABF ACL.
Router(config)#class-map match-any grp-4 Router(config-cmap)#match qos-group 4 Router(config-cmap)#end-class-map Router(config)#class-map match-any grp-3 Router(config-cmap)#match qos-group 3 Router(config-cmap)#end-class-map Router(config)#class-map match-any grp-2 Router(config-cmap)#match qos-group 2 Router(config-cmap)#end-class-map Router(config)#class-map match-any grp-1 Router(config-cmap)#match qos-group 1 Router(config-cmap)#end-class-map Router(config)#class-map match-any class-default Router(config-cmap)#end- class-map
4. Set QoS actions in the policy map configured, in this example: set prec, set tc, and set dscp
Router(config)#policy-map edge_qos_policy Router(config-pmap)#class grp-4 Router(config-pmap-c)#set precedence 2 Router(config-pmap-c)#set traffic-class 4 Router(config-pmap-c)#exit Router(config-pmap)#class grp-3 Router(config- pmap-c)#set traffic-class 3 Router(config-pmap-c)#set dscp ef Router(config- pmap-c)#exit Router(config-pmap)#class grp-2 Router(config-pmap-c)#set precedence 3 Router(config-pmap-c)#set traffic-class 2 Router(config- pmap-c)#exit Router(config-pmap)#class grp-1 Router(config-pmap-c)#set precedence 4 Router(config-pmap-c)#set traffic-class 1 Router(config- pmap-c)#exit Router(config-pmap)#class class-default Router(config-pmap-c)#set precedence 5 Router(config-pmap-c)#exit Router(config-pmap)#end-policy-map
5. Attach the security acl with set qos-groups, to the interface.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 17

Peering QoS for ABF

Classify Packets to Identify Specific Traffic

Router(config)#int bundle-Ether 350 Router(config-if)#ipv4 access-group abf- acl ingress
6. Attach the policy map with QoS actions that you set in step 4, to the interface.
Router(config-if)#service-policy input edge_qos_policy Router(config- if)#commit Router(config-if)#exit
You have successfully configured peering QoS with ABF.
Running Configuration
ipv4 access-list abf-acl 10 permit ipv4 135.0.0.0/8 217.0.0.0/8 precedence priority set qos-group 1 nexthop1 vrf VRF1 nexthop2 vrf VRF2 nexthop3 vrf VRF3 20 permit tcp 135.0.0.0/8 217.0.0.0/8 precedence priority set qos-group 2 nexthop1 vrf vrf3
nexthop2 vrf vrf2 30 permit tcp 135.0.0.0/8 217.0.0.0/8 match-all +ack +psh set qos-group 3 nexthop1 vrf vrf2
nexthop2 vrf vrf3 nexthop3 vrf vrf1 40 permit tcp 135.0.0.0/8 217.0.0.0/8 precedence priority set qos-group 4 nexthop1 vrf vrf1
nexthop2 vrf vrf2 nexthop3 vrf vrf3 ! class-map match-any grp-4 match qos- group 4 end-class-map ! class-map match-any grp-3 match qos-group 3 end-class- map ! class-map match-any grp-2 match qos-group 2 end-class-map ! class-map match-any grp-1 match qos-group 1 end-class-map ! class-map match-any class- default end-class-map ! policy-map edge_qos_policy class grp-4 set precedence 2 set traffic-class 4 ! class grp-3 set traffic-class 3 set dscp ef ! class grp-2 set precedence 3 set traffic-class 2 ! class grp-1 set precedence 4 set traffic-class 1 ! class class-default set precedence 5 ! end-policy-map
Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 18

Classify Packets to Identify Specific Traffic

Classify and Remark Layer 3 Header on Layer 2 Interfaces

! int bundle-Ether 350 ipv4 access-group abf-acl ingress ! int bundle-Ether 350 service-policy input edge_qos_policy
Verification
Run the show interface command for the interface to which you attached the security and QoS ABF ACLs.
Router#show run int bundle-Ether 350 interface Bundle-Ether350 service-policy input edge_qos_policy ipv4 address 11.25.0.1 255.255.255.0 ipv6 address 2001:11:25:1::1/64 ipv4 access-group abf-acl ingress !
Classify and Remark Layer 3 Header on Layer 2 Interfaces
When you need to mark packets for Layer 2 interface traffic that flows across bridge domains and bridge virtual interfaces (BVIs), you can create a mixed QoS policy. This policy has both map-based and TCAM-based classification class-maps. The mixed policy ensures that both bridged (Layer 2) and Bridge Virtual Interface (BVI, or Layer 3) traffic flows are classified and remarked.
Guidelines
· A class-map with TCAM classification may not match bridged traffic. TCAM entries match only routed traffic while map entries match both bridged and BVI traffic.
· A class-map with map-based classification matches both bridged and BVI traffic.
Example
ipv4 access-list acl_v4 10 permit ipv4 host 100.1.1.2 any 20 permit ipv4 host 100.1.100.2 any ipv6 access-list acl_v6 10 permit tcp host 50:1:1::2 any 20 permit tcp any host 50:1:200::2 class-map match-any c_match_acl match access- group ipv4 acl_v4 ! This entry does not match bridged traffic match access- group ipv6 acl_v6 ! This entry does not match bridged traffic match dscp af11 This entry matches bridged and BVI traffic class-map match-all c_match_all match protocol udp ! This entry does not match bridged traffic match prec 7 class-map match-any c_match_protocol match protocol tcp ! This entry, and hence this class does not match bridged traffic class-map match-any c_match_ef match dscp ef ! This entry/class matches bridged and BVI traffic class-map match-any c_qosgroup_1 This class matches bridged and BVI traffic ! match qos- group 1 policy-map p_ingress class c_match_acl set traffic-class 1 set qos- group 1

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 19

Traffic Class Elements

Classify Packets to Identify Specific Traffic

! class c_match_all set traffic-class 2 set qos-group 2 ! class c_match_ef set traffic-class 3 set qos-group 3 ! class c_match_protocol set traffic-class 4 set qos-group 4 policy-map p_egress class c_qosgroup_1 set dscp af23 interface FourHundredGigE0/0/0/0 l2transport service-policy input p_ingress service- policy output p_egress ! ! interface FourHundredGigE0/0/0/1 ipv4 address 200.1.2.1 255.255.255.0 ipv6 address 2001:2:2::1/64 service-policy input p_ingress service-policy output p_egress

Traffic Class Elements

The purpose of a traffic class is to classify traffic on your router. Use the class-map command to define a traffic class. A traffic class contains three major elements:
· A name
· A series of match commands – to specify various criteria for classifying packets.
· An instruction on how to evaluate these match commands (if more than one match command exists in the traffic class)

Packets are checked to determine whether they match the criteria specified in the match commands. If a packet matches the specified criteria, that packet is considered a member of the class and is forwarded according to the QoS specifications set in the traffic policy. Packets that fail to meet any of the matching criteria are classified as members of the default traffic class.
This table shows the details of match types supported on the router.

Match Type Supported

Min, Max Max Entries Support for Support for Direction Supported on Interfaces Match NOT Ranges

IPv4 DSCP (0,63)

64

IPv6 DSCP

DSCP

Yes

Yes

Ingress Egress

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 20

Classify Packets to Identify Specific Traffic

Default Traffic Class

Match Type Supported

Min, Max

IPv4 Precedence (0,7) IPv6 Precedence

Precedence

MPLS

(0,7)

Experimental

Topmost

Access-group Not applicable

QoS-group

(1,7)

Protocol

(0, 255)

Max Entries Support for Support for Direction Supported on Interfaces Match NOT Ranges

8

Yes

No

Ingress

Egress

8

Yes

No

Ingress

Egress

8

No

Not

Ingress

applicable

7

No

No

Egress

1

Yes

Not

Ingress

applicable

Default Traffic Class
Unclassified traffic (traffic that does not meet the match criteria specified in the traffic classes) is treated as belonging to the default traffic class.
If the user does not configure a default class, packets are still treated as members of the default class. However, by default, the default class has no enabled features. Therefore, packets belonging to a default class with no configured features have no QoS functionality.
For egress classification, match on qos-group (1-7) is supported. Match qos- group 0 cannot be configured. The class-default in the egress policy maps to qos-group 0.
This example shows how to configure a traffic policy for the default class:
configure policy-map ingress_policy1 class class-default police rate percent 30 !

Create a Traffic Class
To create a traffic class containing match criteria, use the class-map command to specify the traffic class name, and then use the match commands in class- map configuration mode, as needed.
Guidelines
· Users can provide multiple values for a match type in a single line of configuration; that is, if the first value does not meet the match criteria, then the next value indicated in the match statement is considered for classification.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 21

Create a Traffic Class

Classify Packets to Identify Specific Traffic

· Use the not keyword with the match command to perform a match based on the values of a field that are not specified.
· All match commands specified in this configuration task are considered optional, but you must configure at least one match criterion for a class.
· If you specify match-any, one of the match criteria must be met for traffic entering the traffic class to be classified as part of the traffic class. This is the default. If you specify match-all, the traffic must match all the match criteria.
· For the match access-group command, QoS classification based on the packet length or TTL (time to live) field in the IPv4 and IPv6 headers is not supported.
· For the match access-group command, when an ACL list is used within a class- map, the deny action of the ACL is ignored and the traffic is classified based on the specified ACL match parameters.
· The match qos-group, traffic-class, DSCP/Prec, and MPLS EXP are supported only in egress direction, and these are the only match criteria supported in egress direction
· The egress default class implicitly matches qos-group 0.
· Multicast takes a system path that is different than unicast on router, and they meet later on the egress in a multicast-to-unicast ratio of 20:80 on a per interface basis. This ratio is maintained on the same priority level as that of the traffic.
· Egress QoS for multicast traffic treats traffic classes 0-5 as low-priority and traffic classes 6-7 as high priority. Currently, this is not user- configurable.
· Egress shaping does not take effect for multicast traffic in the high priority (HP) traffic classes. It only applies to unicast traffic.
· If you set a traffic class at the ingress policy and do not have a matching class at egress for the corresponding traffic class value, then the traffic at ingress with this class will not be accounted for in the default class at the egress policy map.
· Only traffic class 0 falls in the default class. A non-zero traffic class assigned on ingress but with no assigned egress queue, falls neither in the default class nor any other class.
Configuration Example
You have to accomplish the following to complete the traffic class configuration: 1. Creating a class map
2. Specifying the match criteria for classifying the packet as a member of that particular class (For a list of supported match types, see Traffic Class Elements, on page 20.)
Router# configure Router(config)# class-map match-any qos-1 Router(config- cmap)# match qos-group 1 Router(config-cmap)# end-class-map Router(config- cmap)# commit
Use this command to verify the class-map configuration:

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 22

Classify Packets to Identify Specific Traffic

Traffic Policy Elements

Router#show class-map qos-1 1) ClassMap: qos-1 Type: qos
Referenced by 2 Policymaps
Also see, Attach a Traffic Policy to an Interface, on page 24.
Related Topics · Traffic Class Elements, on page 20 · Traffic Policy Elements, on page 23

Traffic Policy Elements

A traffic policy contains three elements: · Name · Traffic class · QoS policies

After choosing the traffic class that is used to classify traffic to the traffic policy, the user can enter the QoS features to be applied to the classified traffic.
The MQC does not necessarily require that the users associate only one traffic class to one traffic policy.
The order in which classes are configured in a policy map is important. The match rules of the classes are programmed into the TCAM in the order in which the classes are specified in a policy map. Therefore, if a packet can possibly match multiple classes, only the first matching class is returned and the corresponding policy is applied.
The router supports 8 classes per policy-map in the ingress direction and 8 classes per policy-map in the egress direction.
This table shows the supported class-actions on the router.

Supported Action Types

Direction supported on Interfaces

bandwidth-remaining

egress

mark

See Packet Marking, on page 30

police

ingress

priority

egress (level 1 to level 7)

queue-limit

egress

shape

egress

red

egress

RED supports the discard-class option; the only values to be passed to the discard-class being 0 and 1.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 23

Create a Traffic Policy

Classify Packets to Identify Specific Traffic

Create a Traffic Policy
The purpose of a traffic policy is to configure the QoS features that should be associated with the traffic that has been classified in a user-specified traffic class or classes. To configure a traffic class, see Create a Traffic Class, on page 21. After you define a traffic policy with the policy-map command, you can attach it to one or more interfaces to specify the traffic policy for those interfaces by using the service-policy command in interface configuration mode. With dual policy support, you can have two traffic policies, one marking and one queuing attached at the output. See, Attach a Traffic Policy to an Interface, on page 24.
Configuration Example You have to accomplish the following to complete the traffic policy configuration: 1. Creating a policy map that can be attached to one or more interfaces to specify a service policy 2. Associating the traffic class with the traffic policy 3. Specifying the class-action(s) (see Traffic Policy Elements, on page 23)
Router# configure Router(config)# policy-map test-shape-1 Router(config-pmap)# class qos-1
/ Configure class-action (‘shape’ in this example). Repeat as required, to specify other class-actions / Router(config-pmap-c)# shape average percent 40 Router(config-pmap-c)# exit
/ Repeat class configuration as required, to specify other classes /
Router(config-pmap)# end-policy-map Router(config)# commit
Related Topics · Traffic Policy Elements, on page 23 · Traffic Class Elements, on page 20
Attach a Traffic Policy to an Interface
After the traffic class and the traffic policy are created, you must attach the traffic policy to interface, and specify the direction in which the policy should be applied.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 24

Classify Packets to Identify Specific Traffic

Attach a Traffic Policy to an Interface

Note Hierarchical policies are not supported. When a policy-map is applied to an interface, the transmission rate counter of each class is not accurate. This is because the transmission rate counter is calculated based on the exponential decay filter.
Configuration Example You have to accomplish the following to attach a traffic policy to an interface: 1. Creating a traffic class and the associated rules that match packets to the class (see Create a Traffic Class,
on page 21 ) 2. Creating a traffic policy that can be attached to one or more interfaces to specify a service policy (see
Create a Traffic Policy, on page 24 ) 3. Associating the traffic class with the traffic policy 4. Attaching the traffic policy to an interface, in the ingress or egress direction
Router# configure Router(config)# interface fourHundredGigE 0/0/0/2 Router (config-int)# service-policy output strict-priority Router(config-int)# commit
Running Configuration
/ Class-map configuration /
class-map match-any traffic-class-7 match traffic-class 7 end-class-map
!class-map match-any traffic-class-6 match traffic-class 6 end-class-map
class-map match-any traffic-class-5 match traffic-class 5 end-class-map
class-map match-any traffic-class-4 match traffic-class 4 end-class-map
class-map match-any traffic-class-3 match traffic-class 3
class-map match-any traffic-class-2 match traffic-class 2 end-class-map
class-map match-any traffic-class-1 match traffic-class 1 end-class-map
Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 25

Attach a Traffic Policy to an Interface

Classify Packets to Identify Specific Traffic

/ Traffic policy configuration /
policy-map test-shape-1 class traffic-class-1 shape average percent 40 !
policy-map strict-priority class tc7 priority level 1 queue-limit 75 mbytes ! class tc6 priority level 2 queue-limit 75 mbytes ! class tc5 priority level 3 queue-limit 75 mbytes ! class tc4 priority level 4 queue-limit 75 mbytes ! class tc3 priority level 5 queue-limit 75 mbytes ! class tc2 priority level 6 queue-limit 75 mbytes ! class tc1 priority level 7 queue-limit 75 mbytes ! class class-default queue-limit 75 mbytes ! end-policy-map
—–
/ Attaching traffic policy to an interface in egress direction / interface fourHundredGigE 0/0/0/2
service-policy output strict-priority !

Verification

Router# #show qos int fourHundredGigE 0/0/0/2 output

NOTE:- Configured values are displayed within parentheses Interface FourHundredGigE0/0/0/2 ifh 0xf0001c0 — output policy

NPU Id: Total number of classes: Interface Bandwidth: Policy Name:

0 8 400000000 kbps strict-priority

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 26

Classify Packets to Identify Specific Traffic

Attach a Traffic Policy to an Interface

VOQ Base:

2400

Accounting Type:

Layer1 (Include Layer 1 encapsulation and above)

——————————————————————————

Level1 Class (HP1)

= tc7

Egressq Queue ID

= 2407 (HP1 queue)

Queue Max. BW.

= no max (default)

TailDrop Threshold

= 74999808 bytes / 2 ms (75 megabytes)

WRED not configured for this class

Level1 Class (HP2) Egressq Queue ID Queue Max. BW. TailDrop Threshold WRED not configured for this class

= tc6 = 2406 (HP2 queue) = no max (default) = 74999808 bytes / 2 ms (75 megabytes)

Level1 Class (HP3) Egressq Queue ID Queue Max. BW. TailDrop Threshold WRED not configured for this class

= tc5 = 2405 (HP3 queue) = no max (default) = 74999808 bytes / 2 ms (75 megabytes)

Level1 Class (HP4) Egressq Queue ID Queue Max. BW. TailDrop Threshold WRED not configured for this class

= tc4 = 2404 (HP4 queue) = no max (default) = 74999808 bytes / 2 ms (75 megabytes)

Level1 Class (HP5) Egressq Queue ID Queue Max. BW. TailDrop Threshold WRED not configured for this class

= tc3 = 2403 (HP5 queue) = no max (default) = 74999808 bytes / 2 ms (75 megabytes)

Level1 Class (HP6) Egressq Queue ID Queue Max. BW. TailDrop Threshold WRED not configured for this class

= tc2 = 2402 (HP6 queue) = no max (default) = 74999808 bytes / 2 ms (75 megabytes)

Level1 Class (HP7) Egressq Queue ID Queue Max. BW. TailDrop Threshold WRED not configured for this class

= tc1 = 2401 (HP7 queue) = no max (default) = 74999808 bytes / 2 ms (75 megabytes)

Level1 Class Egressq Queue ID Queue Max. BW. Inverse Weight / Weight TailDrop Threshold WRED not configured for this class

= class-default = 2400 (Default LP queue) = no max (default) = 1 / (BWR not configured) = 74999808 bytes / 150 ms (75 megabytes)

!

Related Topics · Traffic Policy Elements, on page 23 · Traffic Class Elements, on page 20

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 27

Attach a Traffic Policy to an Interface

Classify Packets to Identify Specific Traffic

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 28

4 C H A P T E R
Mark Packets to Change Priority Settings
· Packet Marking Overview, on page 29 · Class-based Unconditional Packet Marking Feature and Benefits, on page 31 · Configure Class-based Unconditional Packet Marking, on page 32 · Class-based Unconditional Packet Marking: Examples, on page 33 · IP Precedence Compared to IP DSCP Marking, on page 35 · In-Place Policy Modification, on page 36
Packet Marking Overview
You can use packet marking in input policy maps to set or modify the attributes for traffic belonging to a specific class. For example, you can change the CoS value in a class or set IP DSCP or IP precedence values for a specific type of traffic. These new values are then used to determine how the traffic should be treated.
Note From Cisco IOS XR Release 7.2.12 onwards, support for marking packets on Layer 2 transport interfaces is the same as the support for marking on Layer 3 interfaces. However, this support applies only to the main interface (physical and bundle interfaces), and not on the sub-interfaces.
Default Marking
When an ingress or egress interface adds VLAN tags or MPLS labels, it requires a default value for the class of service and EXP values that go into those tags and labels. On the router, one ingress default QoS mapping profile and one egress default QoS mapping profile are created and configured per device during initialization.
Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 29

QoS Behavior for Generic Routing Encapsulation (GRE) Tunnels

Mark Packets to Change Priority Settings

QoS Behavior for Generic Routing Encapsulation (GRE) Tunnels

Table 6: Feature History Table

Feature Name

Release Information

QoS Behavior for Generic Routing Release 7.3.1 Encapsulation (GRE) Tunnels: Default Marking

Feature Description
With the support for GRE encapsulation and decapsulation tunnel interfaces, there are some important updates to QoS behavior for GRE tunnels. These updates are applicable for default packet marking and involve Type of Service (ToS) and MPLS experimental bits.

GRE Encapsulation
If you do not configure Type of Service (ToS), the outer IP precedence value or the differentiated services code point (DSCP) value is copied from the inner IP header. If you configure ToS, the outer IP precedence value or DCSP value is as per the ToS configuration.
GRE Decapsulation
During decapsulation, the MPLS experimental bits (EXP) are derived from the outer IP packet. For more information on GRE tunnels, see the Interfaces Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x.

Packet Marking
The packet marking feature, also called explicit marking, provides users with a means to differentiate packets based on the designated markings. The router supports ingress and egress packet marking.

Supported Packet Marking Operations This table shows the supported packet marking operations.

Supported Mark Types Range

Support for Unconditional Marking

set discard-class

0-1

ingress

set dscp

0-63

ingress

set mpls experimental 0-7 topmost

ingress

set precedence

0-7

ingress

set qos-group

0-7

ingress

Support for Conditional Marking No No No
No No

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 30

Mark Packets to Change Priority Settings

QoS Behavior for Generic Routing Encapsulation (GRE) Tunnels

QoS Behavior for Generic Routing Encapsulation (GRE) Tunnels

Table 7: Feature History Table

Feature Name

Release Information

QoS Behavior for Generic Routing Release 7.3.1 Encapsulation (GRE) Tunnels: Explicit Marking

Feature Description
With the support for GRE encapsulation and decapsulation tunnel interfaces, there are some important updates to QoS behavior for GRE tunnels. These updates are applicable for explicit packet marking and involve QoS behavior during ingress and egress.

GRE Encapsulation
During encapsulation of IPv4/IPv6 payload inside the GRE header, QoS behavior is as follows:
· Ingress: QoS supports classification on the payload Layer 3 fields or EXP and remarking payload IP header DSCP.
· Egress: QoS supports setting outer GRE IP header DSCP. It doesn’t overwrite the Tunnel Type of Service (ToS) configuration and doesn’t remark GRE IP header DCSP.

GRE Decapsulation
During decapsulation of the outer GRE header (during which the inner IPv4/IPv6/MPLS payload is forwarded to the next-hop router), QoS behavior is as follows:
· Ingress: QoS supports classification on Layer 3 fields of outer GRE using the set qos-group command. Setting DSCP on the ingress interface sets DSCP for the inner headers.
· Egress: QoS supports classification using qos-group to set DSCP or EXP for egress packets.
For more information on GRE tunnels, see the Interfaces Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x.

Class-based Unconditional Packet Marking Feature and Benefits
The packet marking feature allows you to partition your network into multiple priority levels or classes of service, as follows:
· Use QoS unconditional packet marking to set the IP precedence or IP DSCP values for packets entering the network. Routers within your network can then use the newly marked IP precedence values to determine how the traffic should be treated.
On ingress direction, after matching the traffic based on either the IP Precedence or DSCP value, you can set it to a particular discard-class. Weighted random early detection (WRED), a congestion avoidance technique, thereby uses discard-class values to determine the probability that a packet is dropped.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 31

Configure Class-based Unconditional Packet Marking

Mark Packets to Change Priority Settings

· Use QoS unconditional packet marking to assign MPLS packets to a QoS group. The router uses the QoS group to determine how to prioritize packets for transmission. To set the QoS group identifier on MPLS packets, use the set qos-group command in policy map class configuration mode.
Note Setting the QoS group identifier does not automatically prioritize the packets for transmission. You must first configure an egress policy that uses the QoS group.
· Mark Multiprotocol Label Switching (MPLS) packets by setting the EXP bits within the imposed or topmost label.
· Mark packets by setting the value of the qos-group argument. · Mark packets by setting the value of the discard-class argument.
Note qos-group and discard-class are variables internal to the router, and are not transmitted.
The configuration task is described in the Configure Class-based Unconditional Packet Marking, on page 32.
Configure Class-based Unconditional Packet Marking
This configuration task explains how to configure the following class-based, unconditional packet marking features on your router:
· IP precedence value · IP DSCP value · QoS group value (ingress only) · CoS value (egress only on Layer 3 subinterfaces) · MPLS experimental value · Discard class
Note IPv4 and IPv6 QoS actions applied to MPLS tagged packets are not supported. The configuration is accepted, but no action is taken.
Configuration Example Follow these steps to configure unconditional packet marking features on your router. 1. Create or modify a policy map that can be attached to one or more interfaces to specify a service policy
and enter the policy map configuration mode. 2. Configure an interface and enter the interface configuration mode.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 32

Mark Packets to Change Priority Settings

Class-based Unconditional Packet Marking: Examples

3. Attach a policy map to an input or output interface to be used as the service policy for that interface.
Configuration Example
router# configure router(config)# interface hundredGigE 0/0/0/24 router (config-pmap)# policy-map policy1 Router(config-int)# commit
Running Configuration
router(config)# policy-map policy1
class-map match-any class1 match protocol ipv4 end-class-map
! ! policy-map policy1
class class1 set precedence 1
! class class-default ! end-policy-map ! interface HundredGigE0/0/0/24 service-policy input policy1
!
Verification Run this command to display policy configuration information for all classes configured for all service policies on the specified interface.
router# show run interface hundredGigE 0/0/0/24
Class-based Unconditional Packet Marking: Examples
These are typical examples for class-based unconditional packet marking.
IP Precedence Marking Configuration: Example
In this example, a service policy called policy1 is created. This service policy is associated to a previously defined class map called class1 through the use of the class command, and then the service policy is attached to the output HundredGigE interface 0/7/0/1. The IP precedence bit in the ToS byte is set to 1:
policy-map policy1 class class1 set precedence 1
!

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 33

IP DSCP Marking Configuration: Example

Mark Packets to Change Priority Settings

interface HundredGigE 0/7/0/1 service-policy output policy1
IP DSCP Marking Configuration: Example
In this example, a service policy called policy1 is created. This service policy is associated to a previously defined class map through the use of the class command. In this example, it is assumed that a class map called class1 was previously configured and new class map called class2 is created. In this example, the IP DSCP value in the ToS byte is set to 5:
policy-map policy1 class class1 set dscp 5
class class2 set dscp ef
After you configure the settings shown for voice packets at the edge, all intermediate routers are configured to provide low-latency treatment to the voice packets, as follows:
class-map voice match dscp ef
policy-map qos-policy class voice priority level 1 police rate percent 10
QoS Group Marking Configuration: Example
In this example, a service policy called policy1 is created. This service policy is associated to a class map called class1 through the use of the class command, and then the service policy is attached in the input direction on a HundredGigE 0/7/0/1. The qos-group value is set to 1.
class-map match-any class1 match protocol ipv4 match access-group ipv4 101
policy-map policy1 class class1 set qos-group 1 !
interface HundredGigE 0/7/0/1 service-policy input policy1
Note The set qos-group command is supported only on an ingress policy.
CoS Marking Configuration: Example
In this example, a service policy called policy1 is created. This service policy is associated to a class map called class1 through the use of the class command, and then the service policy is attached in the output direction on a HundredGigE 0/7/0/1.100. The IEEE 802.1p (CoS) bits in the Layer 2 header are set to 1.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 34

Mark Packets to Change Priority Settings

MPLS Experimental Bit Imposition Marking Configuration: Example

class-map match-any class1 match protocol ipv4 match access-group ipv4 101
policy-map policy1 class class1 set cos 1 !
interface HundredGigE 0/7/0/1.100 service-policy input policy1
MPLS Experimental Bit Imposition Marking Configuration: Example
In this example, a service policy called policy1 is created. This service policy is associated to a class map called class1 through the use of the class command, and then the service policy is attached in the input direction on a HundredGigE 0/7/0/1. The MPLS EXP bits of all imposed labels are set to 1.
class-map match-any class1 match protocol ipv4 match access-group ipv4 101
policy-map policy1 class class1 set mpls exp imposition 1
! interface HundredGigE 0/7/0/1
service-policy input policy1
Note The set mpls exp imposition command is supported only on an ingress policy.
MPLS Experimental Topmost Marking Configuration: Example
In this example, a service policy called policy1 is created. This service policy is associated to a class map called class1 through the use of the class command, and then the service policy is attached in the output direction on a HundredGigE 0/7/0/1. The MPLS EXP bits on the TOPMOST label are set to 1:
class-map match-any class1 match mpls exp topmost 2
policy-map policy1 class class1 set mpls exp topmost 1 !
interface HundredGigE 0/7/0/1 service-policy output policy1
IP Precedence Compared to IP DSCP Marking
If you need to mark packets in your network and all your devices support IP DSCP marking, use the IP DSCP marking to mark your packets because the IP DSCP markings provide more unconditional packet marking
Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 35

Configure DSCP CS7 (Precedence 7)

Mark Packets to Change Priority Settings

options. If marking by IP DSCP is undesirable, however, or if you are unsure if the devices in your network support IP DSCP values, use the IP precedence value to mark your packets. The IP precedence value is likely to be supported by all devices in the network. You can set up to 8 different IP precedence markings and 64 different IP DSCP markings.
Configure DSCP CS7 (Precedence 7)
See the following example to configure options in DSCP for a particular source address in IPv4 packets.
Configuration Example
policy-map policy1 class class1 set dscp cs7 !

In-Place Policy Modification
The In-Place policy modification feature allows you to modify a QoS policy even when the QoS policy is attached to one or more interfaces. A modified policy is subjected to the same checks that a new policy is subject to when it is bound to an interface. If the policy-modification is successful, the modified policy takes effect on all the interfaces to which the policy is attached. However, if the policy modification fails on any one of the interfaces, an automatic rollback is initiated to ensure that the pre- modification policy is in effect on all the interfaces.
You can also modify any class map used in the policy map. The changes made to the class map take effect on all the interfaces to which the policy is attached.

Note

· The QoS statistics for the policy that is attached to an interface are lost (reset to 0) when the policy is

modified.

· When a QoS policy attached to an interface is modified, there might not be any policy in effect on the interfaces in which the modified policy is used for a short period of time.

· An in-place modification of an ACL does not reset the policy-map statistics counter.

Verification If unrecoverable errors occur during in-place policy modification, the policy is put into an inconsistent state on target interfaces. No new configuration is possible until the configuration session is unblocked. It is recommended to remove the policy from the interface, check the modified policy and then re-apply accordingly.
Recommendations for Using In-Place Policy Modification
For a short period of time while a QoS policy is being modified, there might not be any policy in effect on the interfaces in which the modified policy is used. For this reason, modify QoS policies that affect the fewest

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 36

Mark Packets to Change Priority Settings

Recommendations for Using In-Place Policy Modification

number of interfaces at a time. Use the show policy-map targets command to identify the number of interfaces that will be affected during policy map modification.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 37

Recommendations for Using In-Place Policy Modification

Mark Packets to Change Priority Settings

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 38

5 C H A P T E R
Congestion Avoidance
· Congestion Avoidance, on page 39 · Queuing Modes, on page 39 · Congestion Avoidance in VOQ, on page 40 · Equitable Traffic Flow Using Fair VOQ, on page 44 · Modular QoS Congestion Avoidance , on page 50 · Tail Drop and the FIFO Queue, on page 50 · Random Early Detection and TCP, on page 52 · Explicit Congestion Notification , on page 54
Congestion Avoidance
Queuing provides a way to temporarily store data when the received rate of data is larger than what can be sent. Managing the queues and buffers is the primary goal of congestion avoidance. As a queue starts to fill up with data, it is important to try to make sure that the available memory in the ASIC/NPU does not fill up completely. If this happens, subsequent packets coming into the port are dropped, irrespective of the priority that they received. This could have a detrimental effect on the performance of critical applications. For this reason, congestion avoidance techniques are used to reduce the risk of a queue from filling up the memory completely and starving non-congested queues for memory. Queue thresholds are used to trigger a drop when certain levels of occupancy are exceeded. Scheduling is the QoS mechanism that is used to empty the queues of data and send the data onward to its destination. Shaping is the act of buffering traffic within a port or queue until it is able to be scheduled. Shaping smoothens traffic, making traffic flows much more predictable. It helps ensure that each transmit queue is limited to a maximum rate of traffic.
Queuing Modes
Two network queuing modes are supported for network interface queuing: the default mode of 8xVOQ (virtual output queuing) and 4xVOQ. To change the mode from one to another requires that you must first reload all line cards in the system.
Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 39

Main Interface Queuing Policy

Congestion Avoidance

In the 8xVOQ mode, eight VoQs and their associated resources are allocated for each interface. These queues are allocated regardless of the exact policy configuration on that interface. This mode supports a separate VOQ for each of the eight internal traffic classes. In the 4xVOQ mode, four VoQs and their associated resources are allocated to each interface, and these queues are allocated regardless of the exact policy applied. In this mode the system supports twice the number of logical interfaces, but the eight traffic classes must be mapped down by configuration to four VoQs, not eight VoQs.
Note From Cisco IOS XR Release 7.2.12 onwards, all the queuing features that are supported on Layer 3 interfaces are also supported on Layer 2 interfaces. However, these features apply only to the main interface (physical and bundle interfaces), and not on the sub-interfaces.
Main Interface Queuing Policy
The main interface default queues are created as part of the main interface creation. When you apply a queuing policy to the main interface, it will override the default queuing and scheduling parameters for the traffic classes you have configured. In the 8xVOQ mode, a P1+P2+6PN hierarchy is used for the main interface queues (default queuing and scheduling). The default queues are used for all traffic to the main interface and traffic to any sub-interface without a queuing policy applied. The control/protocol traffic uses traffic class 7 (TC7), priority 1 (P1) to avoid drops during congestion.
Sub-Interface Queuing Policy
Each sub-interface supports up to three policies: an ingress policy, an egress marking policy, and an egress queuing policy. To create and configure a separate set of VoQs for a sub-interface, apply a queuing policy on that sub- interface. When you remove the sub-interface queuing policy, the associated VoQs are freed and the sub-interface traffic reverts to using the main interface VoQs.
Congestion Avoidance in VOQ
Congestion avoidance within a VOQ block is done by applying a congestion management profile to a VOQ. This profile defines the admission criteria and checks performed at the enqueue time. Under normal traffic conditions the packet is enqueued into the Shared Memory System (SMS) buffers. (The shared memory system is the primary packet storage area.) If the SMS VOQ is congested beyond a set threshold, the VOQ is moved to the external High Band Memory (HBM) block. When the HBM queue drains, it is returned to the on-chip SMS. The queue size in HBM is adaptive and decreases when the total HBM usage is high.
Note Random Early Detect (RED) is available only for VOQs in HBM. The hardware does not support Weighted Random Early Detect (WRED).

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 40

Congestion Avoidance

Sharing of VOQ Statistics Counters

Sharing of VOQ Statistics Counters
Every network processor on the router has multiple slices (or pipelines), and every slice has a set of VOQs associated with every interface on the router. To maintain counters at high packet rates, two sets of counters are associated with each interface on each network slice. As an example, consider a device with six slices (12 interfaces), each with 24,000 VOQs, where you want both transmitted and dropped events counted. In this scenario, you would require 12 x 24, 000 x 2 = 5, 76,000 counters, which alone exceeds the counter capacity of the device. It is to mitigate such a scenario that the router supports configurable sharing of VOQ counters. You can configure the sharing such that a counter is shared by {1,2,4,8} VOQs. Each set of VoQs sharing counters has two counters that measure:
· Enqueued packets count in packets and bytes units.
· Dropped packets count in packets and bytes units.
For the feature to take effect: · Delete egress queuing policy-map configuration from all interfaces.
· Run the command # reload location all to reload all the nodes on your router.

Configuring Sharing of VOQ Statistics Counters
To configure VOQs sharing counters, use the #hw-module profile stats voqs- sharing-counters and specify the number of VOQ counters for each queue.
RP/0/RP0/CPU0:ios(config)#hw-module profile stats ? voqs-sharing-counters Configure number of voqs (1, 2, 4) sharing counters
RP/0/RP0/CPU0:ios(config)#hw-module profile stats voqs-sharing-counters ? 1 Counter for each queue 2 2 Queues share counters 4 4 Queues share counters
RP/0/RP0/CPU0:ios(config)#hw-module profile stats voqs-sharing-counters 1 RP/0/RP0/CPU0:ios(config)#hw-module profile stats voqs-sharing-counters 2 RP/0/RP0/CPU0:ios(config)#commit RP/0/RP0/CPU0:ios#reload location all

Running Configuration
RP/0/RP0/CPU0:ios#show run | in hw-mod Mon Feb 10 13:57:35.296 UTC Building configuration… hw-module profile stats voqs-sharing-counters 2 RP/0/RP0/CPU0:ios#

Verification
RP/0/RP0/CPU0:ios#show controllers npu stats voq ingress interface hundredGigE 0/0/0/16 instance all location 0/RP0/CPU0 Mon Feb 10 13:58:26.661 UTC

Interface Name =

Interface Handle =

Location

=

Asic Instance

=

VOQ Base

=

Hu0/0/0/16 f0001b0
0/RP0/CPU0 0
10288

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 41

Dual Queue Limit

Congestion Avoidance

Port Speed(kbps) = 100000000

Local Port

=

local

VOQ Mode

=

8

Shared Counter Mode =

2

ReceivedPkts ReceivedBytes DroppedPkts

DroppedBytes

——————————————————————-

TC_{0,1} = 114023724

39908275541

113945980

39881093000

TC_{2,3} = 194969733

68239406550

196612981

68814543350

TC_{4,5} = 139949276

69388697075

139811376

67907466750

TC_{6,7} = 194988538

68242491778

196612926

68814524100

Related Commands hw-module profile stats voqs-sharing-counters

Dual Queue Limit
The dual queue limit option is added to queue-limit command on the CLI of your router and displays as discard-class. What the discard-class option does is give you the flexibility to configure two queue limits on a single policy map–one for high-priority traffic and the other for low-priority traffic. This option ensures that the high priority traffic flow continues unaffected (up to the derived threshold from the discard-class 0 queue-limit) while the low- priority traffic continues up to the lower threshold (per discard-class 1 queue-limit).

Tell Me More You can configure the two queue limits per these details:
· One for flow that you mark as discard-class 0 (higher priority) on ingress via ingress-policy. · second, for flow that you mark as discard-class 1 (lower priority) on ingress via ingress policy.

The discard-class 1 flow (for low-priority traffic) begins to drop when the queue length hits the size limit that you configured for discard-class 1. Conversely, the flow for discard-class 1 stops dropping when queue-length falls below its configured value.

As an example, consider this configuration:

policy-map egress_pol_dql class tc7
queue-limit discard-class 0 100 mbytes queue-limit discard-class 1 50 mbytes priority level 1 ! class class-default bandwidth remaining ratio 1 ! end- policy-map !

Also consider the verification:

RP/0/RP0/CPU0:ios#

RP/0/RP0/CPU0:ios#show qos interface hundredGigE 0/0/0/30 output

NOTE:- Configured values are displayed within parentheses

Interface HundredGigE0/0/0/30 ifh 0xf000210 — output policy

NPU Id:

0

Total number of classes:

2

Interface Bandwidth:

100000000 kbps

Policy Name:

egress_pol_dql

VOQ Base:

464

Accounting Type:

Layer1 (Include Layer 1 encapsulation and above)

VOQ Mode:

8

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 42

Congestion Avoidance

Restrictions

Shared Counter Mode:

1

——————————————————————————

Level1 Class (HP1)

= tc7

Egressq Queue ID

= 471 (HP1 queue)

Queue Max. BW.

= no max (default)

Discard Class 1 Threshold

= 25165824 bytes / 2 ms (50 mbytes)

Discard Class 0 Threshold

= 75497472 bytes / 5 ms (100 mbytes)

WRED not configured for this class

Level1 Class Egressq Queue ID Queue Max. BW. Inverse Weight / Weight TailDrop Threshold WRED not configured for this class

= class-default = 464 (Default LP queue) = no max (default) = 1 / (1) = 749568 bytes / 6 ms (default)

In the preceding example, there are two traffic flows that are marked as discard-class 0 (higher priority) and discard-class 1 (lower priority).

As long as the queue length of the two flows remains below 25165824 bytes (the threshold for discard-class 1), packets from both flows continue without any drops. When the queue length reaches 25165824 bytes, discard-class 1 packets are not enqueued, ensuring all remaining bandwidth is used for the higher priority flow (discard-class 0).

The higher priority flow drops only when the queue length reaches 75497472 bytes.

Note

· This option protects the high-priority traffic from loss due to congestion, but not necessarily from latency

due to congestion.

· These thresholds are derived from hardware-specific queue regions.

Restrictions

Ensure that you read these restrictions about the dual queue limit option. · Both the queue-limits must use the same unit of measurement.
· The queue limit for discard-class 0 must always be greater than that for discard-class 1.
· When the discard-class option is not used to configure the queue-limit, packets marked with discard-class 0 and discard-class 1 have the same queue- limit; in other words, they receive identical treatment.
· A queue-limit that is configured with only discard-class 0 or discard-class 1 is rejected.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 43

Equitable Traffic Flow Using Fair VOQ

Congestion Avoidance

Equitable Traffic Flow Using Fair VOQ

Table 8: Feature History Table

Feature Name

Release Information

Equitable Traffic Flow Using Fair Release 7.3.3 VOQ

Feature Description
Configuring this feature ensures that ingress traffic from various source ports on every network slice of an NPU is assigned a unique virtual output queue (VOQ) for every source port and destination port pair. This action ensures that the bandwidth available at the destination port for a given traffic class is distributed equally to all source ports requesting bandwidth.
In earlier releases, the traffic wasn’t distributed equitably because each slice wasn’t given its fair share of the output queue bandwidth.
This feature introduces the fair-4 and fair-8 keywords in the hw-module profile qos voq-mode command.

Fair VOQ: Why
Per default behavior, every network slice of an NPU is assigned a set of 4 or 8 Virtual Output Queues (VOQ) per destination port. With such an assignment, it’s challenging to ensure that the right amount of buffering is available via VOQs. With this configuration, the ingress traffic from various source ports on a slice (or pipeline) on an NPU destined to a destination port is assigned to a VOQ per slice. In other words, multiple source ports sending traffic to the same destination port use the same VOQ. However, when sending traffic to different destination ports, traffic is enqueued to different VOQs. This means that the traffic isn’t distributed equitably because each slice doesn’t get its fair share of the output queue bandwidth. In a scenario where one slice has two ports and another slice has only one port, the bandwidth drops for the ports sharing a slice, even though the two ports handle more traffic than the single port.
Consider the following example where two 100G ports–port-0 and port-1–that belong to the same slice (slice-0) are sending traffic to port-3 on the output queue (OQ). You have a 100G port on another slice (slice-1) on the same NPU that is also scheduled to send traffic to port-3. The ingress VOQ is shared between the two ports in slice-0, whereas the ingress VOQ in slice-1 is available exclusively for port-3. This arrangement results in port-0 and port-1 getting 25% of the buffer traffic, while port-3 receives 50% of the buffer traffic.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 44

Congestion Avoidance Figure 3: Existing behavior : Source ports on slice share one VOQ per destination port

Fair VOQ: How

The fair VOQ feature solves this disparity in traffic distribution.
Fair VOQ: How
The fair VOQ feature tackles the default behavior that treats source ports on each NPU slice equally, regardless of the number of active source ports. It does so by redesigning the way bandwidth is allocated from the output queue. Rather than distributing bandwidth at a slice level, fair VOQ distributes bandwidth directly to the source ports. When you configure the command hw- module profile qos voq-mode and reload your router, the functionality creates a dedicated VOQ for every source port and destination port pair. This arrangement ensures that bandwidth available at the destination port for a given traffic class is distributed equally to all source ports requesting bandwidth.
Extending the preceding example to understand the fair VOQ functionality, there are now dedicated VOQs for each ingress port that connect to the port on the output queue. Thus, port-0 and port-1 now don’t share a VOQ, and port-3 has its VOQ as before, as shown in the following figure. This fair VOQ arrangement results in traffic queued on dedicated queues, thus improving the traffic performance.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 45

Fair VOQ Modes and Sharing of Counters

Congestion Avoidance

Figure 4: Fair VOQ behavior: each source port on slice has one dedicated VOQ per destination port

Fair VOQ Modes and Sharing of Counters
You can configure fair VOQ for 8xVOQ mode (fair-8) and 4xVOQ mode (fair-4) using the following options in the hw-module profile qos voq-mode command:
· hw-module profile qos voq-mode fair-8
· hw-module profile qos voq-mode fair-4

You can also share VOQ statistics counters in both fair VOQ modes, as shown in the following table. (For details on why sharing counters is essential and how to configure counters sharing, see Sharing of VOQ Statistics Counters, on page 41.)
Table 9: Fair VOQ Modes and Sharing Counters

Fair VOQ Mode fair-8

Sharing Counters Mode 2, 4

Important Notes
· Eight VOQs configured per source port and destination pair
· Counters are shared by {2, 4} VOQs.
· fair-8 mode doesn’t support dedicated counter mode (counter mode1, where there’s a counter for every queue)

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 46

Congestion Avoidance

Fair VOQs and Slice (or Normal) VOQs: Key Differences

Fair VOQ Mode fair-4

Sharing Counters Mode 1, 2, 4

Important Notes
· Four VOQs configured per source port and destination pair
· Counters are shared by {1, 2, 4} VOQs.

Fair VOQs and Slice (or Normal) VOQs: Key Differences
The following table is a snapshot to outline the key differences between fair VOQs and slice or regular VOQs.
Table 10: Fair VOQs and Normal VOQs

Fair VOQ

Normal VOQ

fair-8 mode: eight VOQs configured per source port 8:

and destination pair

· Eight VOQs per destination port per slice

· These VOQs are shared by all source ports within an NPU slice.

fair-4 mode: four VOQs configured per source port 4:

and destination pair

· Four VOQs per destination port per slice

· These VOQs are shared by all source ports within an NPU slice.

Guidelines and Limitations
· The fair VOQ feature is supported on the Cisco 8202 router (12 QSFP56-DD 400G and 60 QSFP28 100G ports).
· The following table details the maximum interfaces (with basic IPv4 configurations and no other scale configuration such as QoS policy, ACL, and subinterface configuration) allowed based on VOQ mode and sharing counter mode.
Table 11: Maximum Interfaces Based on Fair VOQ Mode and Sharing Counter Mode

VOQ Mode fair-8

Sharing Counter Mode 1

Maximum Interfaces
The router doesn’t support this combination.
(This is because in default counter mode, 72 interfaces aren’t created.)

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 47

Configure Fair VOQ

Congestion Avoidance

VOQ Mode fair-8
fair-8 fair-4
fair-4 fair-4

Sharing Counter Mode 2
4 1
2 4

Maximum Interfaces
96 = 60 (100G) + 8×4 + 4 (400G) ==> you can configure only eight 400G interfaces in 4x10G or 4x25G breakout mode.
108 = 60 + 12 x 4 (breakout on all 12 ports – 400G)
96 = 60(100G) + 8×4 + 4 (400G) ==> you can configure only eight 400 G interfaces in 4x10G or 4x25G breakout mode.
108 = 60 + 12 x4 (breakout on all 12 ports – 400G)
108 = 60 + 12 x4 (breakout on all 12 ports – 400G)

Note We recommend using sharing counter mode 4 in breakout modes and sharing counter mode 2 for nonbreakout modes.

Note Breakout mode isn’t supported on 100G interfaces.
· Ensure that you reload the router for the configuration to take effect.
· Layer 2 traffic isn’t supported in fair-voq mode (fair-4 and fair-8).
· Subinterface queueing isn’t supported. (This applies to bundle sub- interfaces as well). This means that you can’t attach egress service-policies that require dedicated VOQs. However, egress marking is supported for subinterfaces.
· hw-module profile stats voqs-sharing-counters 1 isn’t supported in fair-8 mode. Ensure that you configure hw-module profile voq sharing-counters 2 or hw-module profile voq sharing-counters 4 along with hw-module profile qos voq- mode fair-4 or hw-module profile qos voq-mode fair-8 before reloading the router.
· Breakout is supported only on 400G interfaces in fair-voq mode (both fair-4 and fair-8) on the Cisco 8202 router.
· src-interface and src-slice keywords in show controller npu stats are visible only when you configure the VOQ mode to either fair-8 or fair-4.
Configure Fair VOQ
To configure fair VOQ:

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 48

Congestion Avoidance

Configure Fair VOQ

1. Configure sharing of VOQ statistics counters. This example configures 2 counters.

Note Configuring fair-8 mode without counter sharing may cause configuration failure or other unexpected behavior.
2. Configure fair VOQ mode. This example shows how to configure fair-8 mode.
3. Restart the router for the configuration to take effect.
4. You have successfully enabled the fair VOQ feature to ensure equitable traffic distribution between every source port and destination port pair.
/Configure sharing of VOQ statistics counters; we’re configuring 2 counters per queue/ Router(config)#hw-module profile stats ?
voqs-sharing-counters Configure number of voqs (1, 2, 4) sharing counters Router(config)#hw-module profile stats voqs-sharing-counters ?
1 Counter for each queue 2 2 Queues share counters 4 4 Queues share counters Router(config)#hw-module profile stats voqs-sharing-counters 2
/Configure fair-voq mode; we’re configuring fair-8 VOQ mode here/ Router#config Router(config)#hw-module profile qos voq-mode fair-8 Router(config)#commit Router#reload location all
Running Configuration
hw-module profile stats voqs-sharing-counters 2 ! hw-module profile qos voq- mode fair-8 !
Verification
Run the show controller npu stats voq ingress interface <> instance <> location <> command to verify the fair VOQ configuration.
Router#show controllers npu stats voq ingress interface hundredGigE 0/0/0/20 instance 0 location 0/RP0/CPU0

Interface Name

= Hu0/0/0/20

Interface Handle

=

f000118

Location

= 0/RP0/CPU0

Asic Instance

=

0

Port Speed(kbps)

= 100000000

Local Port

=

local

Src Interface Name =

ALL

VOQ Mode

=

Fair-8

Shared Counter Mode =

2

ReceivedPkts ReceivedBytes DroppedPkts

DroppedBytes

——————————————————————-

TC_{0,1} = 11110

1422080

0

0

TC_{2,3} = 0

0

0

0

TC_{4,5} = 0

0

0

0

TC_{6,7} = 0

0

0

0

RP/0/RP0/CPU0:ios#

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 49

Modular QoS Congestion Avoidance

Congestion Avoidance

Associated Commands hw-module profile qos voq-mode
Modular QoS Congestion Avoidance
Congestion avoidance techniques monitor traffic flow in an effort to anticipate and avoid congestion at common network bottlenecks. Avoidance techniques are implemented before congestion occurs as compared with congestion management techniques that control congestion after it has occurred. Congestion avoidance is achieved through packet dropping. The router supports these QoS congestion avoidance techniques:
· Tail Drop and the FIFO Queue, on page 50 · Random Early Detection and TCP, on page 52
Tail Drop and the FIFO Queue
Tail drop is a congestion avoidance technique that drops packets when an output queue is full until congestion is eliminated. Tail drop treats all traffic flow equally and does not differentiate between classes of service. It manages the packets placed into a first-in, first-out (FIFO) queue, and forwarded at a rate determined by the available underlying link bandwidth.
Configure Tail Drop
Packets satisfying the match criteria for a class accumulate in the queue reserved for the class until they are serviced. The queue-limit command is used to define the maximum threshold for a class. When the maximum threshold is reached, the enqueued packets to the class queue result in tail drop (packet drop).
Restrictions · When configuring the queue-limit command, you must configure one of the following commands: priority, shape average, or bandwidth remaining, except for the default class.
Configuration Example You have to accomplish the following to complete the tail drop configuration: 1. Creating (or modifying) a policy map that can be attached to one or more interfaces to specify a service
policy 2. Associating the traffic class with the traffic policy 3. Specifying the maximum limit the queue can hold for a class policy configured in a policy map. 4. Specifying priority to a class of traffic belonging to a policy map. 5. (Optional) Specifying the bandwidth allocated for a class belonging to a policy map or specifying how
to allocate leftover bandwidth to various classes. 6. Attaching a policy map to an output interface to be used as the service policy for that interface.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 50

Congestion Avoidance

Configure Tail Drop

Router# configure Router(config)# policy-map test-qlimit-1 Router(config- pmap)# class qos-1 Router(config-pmap-c)# queue-limit 100 us Router(config- pmap-c)# priority level 7 Router(config-pmap-c)# exit Router(config-pmap)# exit
Router(config)# interface HundredGigE 0/6/0/18 Router(config-if)# service- policy output test-qlimit-1 Router(config-if)# commit

Running Configuration
policy-map test-qlimit-1 class qos-1 queue-limit 100 us priority level 7 ! class class-default ! end-policy-map
!

Verification

Router# show qos int 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:

2

Interface Bandwidth:

100000000 kbps

VOQ Base:

11176

VOQ Stats Handle:

0x88550ea0

Accounting Type:

Layer1 (Include Layer 1 encapsulation and above)

——————————————————————————

Level1 Class (HP7)

= qos-1

Egressq Queue ID

= 11177 (HP7 queue)

TailDrop Threshold

= 1253376 bytes / 100 us (100 us)

WRED not configured for this class

Level1 Class Egressq Queue ID Queue Max. BW. Queue Min. BW. Inverse Weight / Weight TailDrop Threshold WRED not configured for this class

= class-default = 11176 (Default LP queue) = 101803495 kbps (default) = 0 kbps (default) = 1 (BWR not configured) = 1253376 bytes / 10 ms (default)

Related Topics · Tail Drop and the FIFO Queue, on page 50

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 51

Random Early Detection and TCP

Congestion Avoidance

Random Early Detection and TCP
The Random Early Detection (RED) congestion avoidance technique takes advantage of the congestion control mechanism of TCP. By randomly dropping packets prior to periods of high congestion, RED tells the packet source to decrease its transmission rate. Assuming the packet source is using TCP, it decreases its transmission rate until all packets reach their destination, indicating that the congestion is cleared. You can use RED as a way to cause TCP to slow transmission of packets. TCP not only pauses, but it also restarts quickly and adapts its transmission rate to the rate that the network can support. RED distributes losses in time and maintains normally low queue depth while absorbing traffic bursts. It achieves this by taking action on the average queue size, and not the instantaneous queue size. When enabled on an interface, RED begins dropping packets when congestion occurs at a rate you select during configuration.
Configure Random Early Detection
The random-detect command with the minimum threshold and maximum threshold keywords must be used to enable random early detection (RED).
Guidelines · If you configure the random-detect <max threshold> command on any class including class-default, configure one of the following commands: shape average or bandwidth remaining. · If you configure a queue-limit that is lesser than the minimum supported value, the configured value automatically adjusts to the supported minimum value. While configuring random-detect, if you set the and values lesser than the minimum supported threshold value: · The value automatically adjusts to the minimum supported value. · The value doesn’t autoadjust to a value above the minimum supported threshold value. This results in a failed random-detect configuration. To prevent this error, configure the value such that it exceeds the <min threshold> value that your system supports.
Configuration Example Accomplish the following to complete the random early detection configuration: 1. Creating (or modifying) a policy map that can be attached to one or more interfaces to specify a service
policy 2. Associating the traffic class with the traffic policy 3. Enabling RED with minimum and maximum thresholds. 4. Configure one of the following:
· Specifying how to allocate leftover bandwidth to various classes. OR
· Shaping traffic to the specified bit rate or a percentage of the available bandwidth.
5. Attaching a policy map to an output interface to be used as the service policy for that interface.
Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 52

Congestion Avoidance

Configure Random Early Detection

Router# configure Router(config)# policy-map red-abs-policy Router(config- pmap)# class qos-1 Router(config-pmap-c)# random-detect <max threshold> Router(config-pmap-c)# shape average percent 10 Router(config- pmap-c)# end-policy-map Router(config)# commit Router(config)# interface HundredGigE0/0/0/12 Router(config-if)# service-policy output red-abs-policy Router(config-if)# commit
Running Configuration
policy-map red-abs-policy class tc7
priority level 1 queue-limit 75 mbytes ! class tc6 priority level 2 queue- limit 75 mbytes ! class tc5 shape average 10 gbps queue-limit 75 mbytes ! class tc4 shape average 10 gbps queue-limit 75 mbytes ! class tc3 shape average 10 gbps queue-limit 75 mbytes ! class tc2 shape average 10 gbps queue- limit 75 mbytes ! class tc1 shape average 10 gbps random-detect ecn random- detect 100 mbytes 200 mbytes ! class class-default shape average 10 gbps random-detect 100 mbytes 200 mbytes ! end-policy-map !
interface HundredGigE0/0/0/12 service-policy output red-abs-policy shutdown !
Verification
Router# show qos int hundredGigE 0/6/0/18 output

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 53

Explicit Congestion Notification

Congestion Avoidance

NOTE:- Configured values are displayed within parentheses

Interface HundredGigE0/0/0/12 ifh 0x3000220 — output policy

NPU Id:

3

Total number of classes:

2

Interface Bandwidth:

100000000 kbps

VOQ Base:

11176

VOQ Stats Handle:

0x88550ea0

Accounting Type:

Layer1 (Include Layer 1 encapsulation and above)

——————————————————————————

Level1 Class

= qos-1

Egressq Queue ID

= 11177 (LP queue)

Queue Max. BW.

= 10082461 kbps (10 %)

Queue Min. BW.

= 0 kbps (default)

Inverse Weight / Weight

= 1 (BWR not configured)

Guaranteed service rate

= 10000000 kbps

TailDrop Threshold

= 12517376 bytes / 10 ms (default)

Default RED profile RED Min. Threshold RED Max. Threshold

= 12517376 bytes (10 ms) = 12517376 bytes (10 ms)

Level1 Class Egressq Queue ID Queue Max. BW. Queue Min. BW. Inverse Weight / Weight Guaranteed service rate TailDrop Threshold WRED not configured for this class

= class-default = 11176 (Default LP queue) = 101803495 kbps (default) = 0 kbps (default) = 1 (BWR not configured) = 50000000 kbps = 62652416 bytes / 10 ms (default)

Related Topics · Random Early Detection and TCP, on page 52

Explicit Congestion Notification
Random Early Detection (RED) is implemented at the core routers of a network. Edge routers assign IP precedences to packets, as the packets enter the network. With RED, core routers then use these precedences to determine how to treat different types of traffic. RED provides a single threshold and weights per traffic class or queue for different IP precedences.
ECN is an extension to RED. ECN marks packets instead of dropping them when the average queue length exceeds a specific threshold value. When configured, ECN helps routers and end hosts to understand that the network is congested and slow down sending packets. However, if the queue length is above the maximum threshold for the extended memory, packets are dropped. This is the identical treatment that a packet receives when RED is enabled without ECN configured on the router.
RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP, states that with the addition of active queue management (for example, RED) to the Internet infrastructure, routers are no longer limited to packet loss as an indication of congestion.

Note You cannot use this feature when you have set qos-group or mpls experimental along with a traffic class in the ingress policy.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 54

Congestion Avoidance

Explicit Congestion Notification

Implementing ECN
Implementing ECN requires an ECN-specific field that has two bits–the ECN- capable Transport (ECT) bit and the CE (Congestion Experienced) bit–in the IP header. The ECT bit and the CE bit can be used to make four code points of 00 to 11. The first number is the ECT bit and the second number is the CE bit.
Table 12: ECN Bit Setting

ECT Bit 0 0
1
1

CE Bit 0 1
0
1

Combination Indicates
Not-ECN-capable.
Endpoints of the transport protocol are ECN-capable.
Endpoints of the transport protocol are ECN-capable.
Congestion experienced.

The ECN field combination 00 indicates that a packet is not using ECN. The code points 01 and 10–Called ECT(1) and ECT(0), respectively–are set by the data sender to indicate that the endpoints of the transport protocol are ECN- capable. Routers treat these two code points identically. Data senders can use either one or both of these two combinations. The ECN field combination 11 indicates congestion to the endpoints. Packets arriving a full queue of a router will be dropped.

Packet Handling When ECN Is Enabled
When ECN is enabled, all packets between and <max tail drop threshold> are marked with ECN. Three different scenarios arise if the queue length is between the minimum threshold and the maximum threshold:
· If the ECN field on the packet indicates that the endpoints are ECN-capable (that is, the ECT bit is set to 1 and the CE bit is set to 0, or the ECT bit is set to 0 and the CE bit is set to 1)–and the RED algorithm determines that the packet should have been dropped based on the drop probability–the ECT and CE bits for the packet are changed to 1, and the packet is transmitted. This happens because ECN is enabled and the packet gets marked instead of dropped.
· If the ECN field on the packet indicates that neither endpoint is ECN- capable (that is, the ECT bit is set to 0 and the CE bit is set to 0), the packet is transmitted. If, however, the max tail drop threshold is exceeded, the packet is dropped. This is the identical treatment that a packet receives when RED is enabled without ECN configured on the router.
· If the ECN field on the packet indicates that the network is experiencing congestion (that is, both the ECT bit and the CE bit are set to 1), the packet is transmitted. No further marking is required.

Configuration Example
Router# configure Router(config)# policy-map policy1 Router(config-pmap)# class class1 Router(config-pmap-c)# bandwidth percent 50 Router(config- pmap-c)# random-detect 1000 packets 2000 packets Router(config-pmap-c)# random-detect ecn Router(config-pmap-c)# exit

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 55

Explicit Congestion Notification

Congestion Avoidance

Router(config-pmap)# exit Router(config)# commit

Verification Use the show policy-map interface to verify the configuration.

Router# show policy-map int hu 0/0/0/35 output TenGigE0/0/0/6 output: pm-out- queue

HundredGigE0/0/0/35 output: egress_qosgrp_ecn

Class tc7

Classification statistics

Matched

:

Transmitted

:

Total Dropped

:

Queueing statistics

Queue ID

Taildropped(packets/bytes)

(packets/bytes)

(rate – kbps)

195987503/200691203072

0

188830570/193362503680

0

7156933/7328699392

0

: 18183 : 7156933/7328699392

WRED profile for

RED Transmitted (packets/bytes)

: N/A

RED random drops(packets/bytes)

: N/A

RED maxthreshold drops(packets/bytes)

: N/A

RED ecn marked & transmitted(packets/bytes): 188696802/193225525248

Class tc6

Classification statistics

(packets/bytes)

(rate – kbps)

Matched

:

666803815/133360763000

0

Transmitted

:

642172362/128434472400

0

Total Dropped

:

24631453/4926290600

0

Queueing statistics

Queue ID

: 18182

Taildropped(packets/bytes)

: 24631453/4926290600

WRED profile for

RED Transmitted (packets/bytes)

: N/A

RED random drops(packets/bytes)

: N/A

RED maxthreshold drops(packets/bytes)

: N/A

RED ecn marked & transmitted(packets/bytes): 641807908/128361581600

Class tc5

Classification statistics

(packets/bytes)

(rate – kbps)

Matched

:

413636363/82727272600

6138

Transmitted

:

398742312/79748462400

5903

Total Dropped

:

14894051/2978810200

235

Queueing statistics

Queue ID

: 18181

Taildropped(packets/bytes)

: 14894051/2978810200

WRED profile for

RED Transmitted (packets/bytes)

: N/A

RED random drops(packets/bytes)

: N/A

RED maxthreshold drops(packets/bytes)

: N/A

RED ecn marked & transmitted(packets/bytes): 398377929/79675585800

Note The RED ecn marked & transmitted(packets/bytes) row displays the statistics for ECN marked packets. To begin with, it displays 0/0.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 56

6 C H A P T E R

Configure Priority Flow Control

· Priority Flow Control Overview, on page 57 · Configurable ECN Threshold and Maximum Marking Probability Values, on page 66 · Priority Flow Control Watchdog Overview, on page 71

Priority Flow Control Overview

Table 13: Feature History Table
Feature Name
Priority Flow Control on Cisco 8808 and Cisco 8812 Modular Chassis Line Cards

Release Information Release 7.5.3

Shortlink Priority Flow Control Release 7.3.3

Feature Description
Priority Flow Control is now supported on the following line card in the buffer-internal mode:
· 88-LC0-34H14FH
The feature is supported in the buffer-internal and buffer-extended modes on:
· 88-LC0-36FH
Apart from the buffer-external mode, support for this feature now extends to the buffer-internal mode on the following line cards:
· 88-LC0-36FH-M
· 8800-LC-48H
This feature and the hw-module profile priority-flow-control command are supported on 88-LC0-36FH line card.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 57

Priority Flow Control Overview

Configure Priority Flow Control

Feature Name

Release Information

Priority Flow Control Support on Cisco 8800 36×400 GbE QSFP56-DD Line Cards (88-LC0-36FH-M)

Release 7.3.15

Priority Flow Control

Release 7.3.1

Feature Description
This feature and the hw-module profile priority-flow-control command are supported on 88-LC0-36FH-M and 8800-LC-48H line cards.
All previous functionalities and benefits of this feature are available on these line cards. However, the buffer-internal mode is not supported.
In addition, to use the buffer-extended mode on these line cards, you are required to configure the performance capacity or headroom values. This configuration requirement ensures that you can better provision and balance workloads to achieve lossless behavior, which in turn ensures efficient use of bandwidth and resources.
This feature and the hw-module profile priority-flow-control command are not supported.

Priority-based Flow Control (IEEE 802.1Qbb), which is also referred to as Class-based Flow Control (CBFC) or Per Priority Pause (PPP), is a mechanism that prevents frame loss that is due to congestion. PFC is similar to 802.x Flow Control (pause frames) or link-level flow control (LFC). However, PFC functions on a per class-of-service (CoS) basis.
During congestion, PFC sends a pause frame to indicate the CoS value to pause. A PFC pause frame contains a 2-octet timer value for each CoS that indicates the length of time to pause the traffic. The unit of time for the timer is specified in pause quanta. A quanta is the time required for transmitting 512 bits at the speed of the port. The range is from 0 through 65535 quanta.
PFC asks the peer to stop sending frames of a particular CoS value by sending a pause frame to a well-known multicast address. This pause frame is a one-hop frame and isn’t forwarded when received by the peer. When the congestion mitigates, the router stops sending the PFC frames to the upstream node.
You can configure PFC for each line card using the hw-module profile priority- flow-control command in one of two modes:
· buffer-internal
· buffer-extended

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 58

Configure Priority Flow Control

buffer-internal mode

Note PFC threshold configurations are deprecated in pause command. Use the hw- module profile priority-flow-control command to configure PFC threshold configurations.
Related Topics · Configure Priority Flow Control, on page 61
· Priority Flow Control Watchdog Overview, on page 71
buffer-internal mode
Use this mode if PFC-enabled devices aren’t more than 1 km apart. You can set values for pause-threshold, headroom (both related to PFC), and ECN for the traffic class using the hw-module profile priority-flow-control command in this mode. The buffer-internal configuration applies to all ports that the line card hosts, which mean that you can configure a set of these values per line card. The existing queue limit and ECN configuration in the queueing policy attached to the interface has no impact in this mode. The effective queue limit for this mode = pause-threshold + headroom (in bytes)
Restrictions and Guidelines
The following restrictions and guidelines apply while configuring the PFC threshold values using the buffer-internal mode.
· The PFC feature isn’t supported on fixed chassis systems. · Ensure that there’s no breakout configured on a chassis that has the PFC configured. Configuring PFC
and breakout on the same chassis may lead to unexpected behavior, including traffic loss. · The feature isn’t supported on bundle and non-bundle sub- interface queues. · The feature is supported on 40GbE, 100 GbE, and 400 GbE interfaces. · The feature isn’t supported in the 4xVOQ queueing mode. · The feature isn’t supported when sharing of VOQ counters is configured.
buffer-extended mode
Use this mode for PFC-enabled devices with long-haul connections. You can set the value for pause-threshold using the hw-module profile priority-flow- control command in this mode. You must, however, configure the queuing policy attached to the interface to set the ECN and queueing limits. The buffer- extended configuration applies to all ports that the line card hosts, which mean that you can configure a set of these values per line card.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 59

Important Considerations

Configure Priority Flow Control

Configuration Guidelines · Important points while configuring the buffer- extended mode on 88-LC0-36FH-M line cards: · Apart from pause-threshold, you must also configure values for headroom. · The headroom value range is from 4 through 75000. · Specify pause-threshold and headroom values in units of kilobytes (KB) or megabytes (MB).
· Important points while configuring the buffer-extended mode on 8800-LC-48H line cards: · Configure values only for pause-threshold. Don’t configure headroom values. · Configure pause-threshold in units of milliseconds (ms) or microseconds. · Don’t use units of kilobytes (KB) or megabytes (MB) units, even though the CLI displays them as options. Only use units of milliseconds (ms) or microseconds.

(Also see Configure Priority Flow Control, on page 61)

Important Considerations
· If you configure PFC values in the buffer-internal mode, then the ECN value for the line card is derived from the buffer-internal configuration. If you configure PFC values in the buffer-extended mode, then the ECN value is derived from the policy map. (For details on the ECN feature, see Explicit Congestion Notification , on page 54.)
· The buffer-internal and buffer-extended modes can’t coexist on the same line card.
· If you add or remove traffic-class actions on a line card, you must reload the line card.
· When using the buffer-internal mode, you can change values of the following parameters without having to reload the line card. However, if you add a new traffic class and configure these values for the first time on that traffic class, you must reload the line card for the values to come into effect.
· pause-threshold
· headroom
· ECN

· If you add or remove ECN configuration using the hw-module profile priority- flow-control command, you must reload the line card for the ECN changes to take effect.
· The PFC threshold value ranges for the buffer-internal mode are as follows.

Threshold

Configured (bytes)

pause (min)

307200

pause (max)

422400

headroom (min)

345600

headroom (max)

537600

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 60

Configure Priority Flow Control

Hardware Support for Priority Flow Control

Threshold ecn (min) ecn (max)

Configured (bytes) 153600 403200

· For a traffic-class, the ECN value must always be lesser than the configured pause-threshold value.
· The combined configured values for pause-threshold and headroom must not exceed 844800 bytes. Else, the configuration is rejected.
· The pause-threshold value range for buffer-extended mode is from 2 milliseconds (ms) through 25 ms and from 2000 microseconds through 25000 microseconds.

Hardware Support for Priority Flow Control
The table lists the PIDs that support PFC per release and the PFC mode in which the support is available.
Table 14: PFC Hardware Support Matrix

Release Release 7.3.15

PID · 88-LC0-36FH-M · 88-LC0-36FH

PFC Mode buffer-extended

Release 7.0.11

8800-LC-48H

buffer-internal

Configure Priority Flow Control
You can configure PFC to enable the no-drop behavior for the CoS as defined by the active network QoS policy.

Note The system enables shortlink PFC by default when you enable PFC.
Configuration Example You must accomplish the following to complete the PFC configuration: 1. Enable PFC at the interface level. 2. Configure ingress classification policy. 3. Attach the PFC policy to the interface. 4. Configure PFC threshold values using either the buffer-internal or buffer-extended mode.
Router# configure Router(config)# priority-flow-control mode on /Configure ingress classification policy/

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 61

Configure Priority Flow Control

Configure Priority Flow Control

Router(config)# class-map match-any prec7 Router(config-cmap)# match precedence Router(config)# class-map match-any tc7 /Ingress policy attach/ Router(config-if)# service-policy input QOS_marking /Egress policy attach/ Router(config-if)# service-policy output qos_queuing Router(config-pmap-c)# exit Router(config-pmap)# exit Router(config)#show controllers npu priority- flow-control location
Running Configuration
Interface Level interface HundredGigE0/0/0/0
priority-flow-control mode on
Ingress: class-map match-any prec7
match precedence 7
end-class-map
!
class-map match-any prec6
match precedence 6
end-class-map
!
class-map match-any prec5
match precedence 5
end-class-map
!
class-map match-any prec4
match precedence 4
end-class-map
!
class-map match-any prec3 match precedence 3 end-class-map ! class-map match- any prec2 match precedence 2 end-class-map ! class-map match-any prec1 match precedence 1 end-class-map ! ! policy-map QOS_MARKING

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 62

Configure Priority Flow Control
class prec7 set traffic-class 7 set qos-group 7
! class prec6
set traffic-class 6 set qos-group 6 ! class prec5 set traffic-class 5 set qos- group 5 ! class prec4 set traffic-class 4 set qos-group 4 ! class prec3 set traffic-class 3 set qos-group 3 ! class prec2 set traffic-class 2 set qos- group 2 ! class prec1 set traffic-class 1 set qos-group 1 ! class class- default set traffic-class 0 set qos-group 0 !
Egress: class-map match-any tc7
match traffic-class 7 end-class-map ! class-map match-any tc6 match traffic- class 6 end-class-map ! class-map match-any tc5 match traffic-class 5 end- class-map
!
class-map match-any tc4
match traffic-class 4
end-class-map
!
class-map match-any tc3
match traffic-class 3
end-class-map
!

Configure Priority Flow Control

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 63

Configure Priority Flow Control

Configure Priority Flow Control

class-map match-any tc2 match traffic-class 2 end-class-map ! class-map match- any tc1 match traffic-class 1 end-class-map ! policy-map QOS_QUEUING class tc7
priority level 1 shape average percent 10 ! class tc6 bandwidth remaining ratio 1 queue-limit 100 ms ! class tc5 bandwidth remaining ratio 20 queue- limit 100 ms ! class tc4 bandwidth remaining ratio 20 random-detect ecn random-detect 6144 bytes 100 mbytes ! class tc3 bandwidth remaining ratio 20 random-detect ecn random-detect 6144 bytes 100 mbytes ! class tc2 bandwidth remaining ratio 5 queue-limit 100 ms ! class tc1 bandwidth remaining ratio 5 queue-limit 100 ms ! class class-default bandwidth remaining ratio 20 queue- limit 100 ms ! [buffer-extended] hw-module profile priority-flow-control location 0/0/CPU0 buffer-extended traffic-class 3 pause-threshold 10 ms buffer-extended traffic-class 4 pause-threshold 10 ms
!
[buffer-internal] hw-module profile priority-flow-control location 0/1/CPU0 buffer-internal traffic-class 3 pause-threshold 403200 bytes headroom 441600 bytes ecn
224640 bytes buffer-internal traffic-class 4 pause-threshold 403200 bytes headroom 441600 bytes ecn
224640 bytes
Verification
Router#sh controllers hundredGigE0/0/0/22 priority-flow-control Priority flow control information for interface HundredGigE0/0/0/22:

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 64

Configure Priority Flow Control

Configure Priority Flow Control

Priority Flow Control:

Total Rx PFC Frames : 0

Total Tx PFC Frames : 313866

Rx Data Frames Dropped: 0

CoS Status Rx Frames

— —— ———-

0 on

0

1 on

0

2 on

0

3 on

0

4 on

0

5 on

0

6 on

0

7 on

0

/[buffer-internal]/ Router#show controllers hundredGigE 0/9/0/24 priority- flow-control

Priority flow control information for interface HundredGigE0/9/0/24:

Priority Flow Control:

Total Rx PFC Frames : 0

Total Tx PFC Frames : 313866

Rx Data Frames Dropped: 0

CoS Status Rx Frames

— —— ———-

0 on

0

1 on

0

2 on

0

3 on

0

4 on

0

5 on

0

6 on

0

7 on

0

…

/[buffer-internal, tc3 & tc4 configured. TC4 doesn’t have ECN]/

Router#show controllers npu priority-flow-control location

Location Id:

0/1/CPU0

PFC:

Enabled

PFC-Mode:

buffer-internal

TC Pause

Headroom

ECN

——————————————————-

3 86800 bytes

120000 bytes 76800 bytes

4 86800 bytes

120000 bytes Not-configured

/[buffer-extended PFC, tc3 & tc4 configured]/

Router#show controllers npu priority-flow-control location

Location Id:

0/1/CPU0

PFC:

Enabled

PFC-Mode:

buffer-extended

TC Pause

———–

3 5000 us

4 10000 us

/[No PFC]/

Router#show controllers npu priority-flow-control location

Location Id:

0/1/CPU0

PFC:

Disabled

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 65

Configurable ECN Threshold and Maximum Marking Probability Values

Configure Priority Flow Control

Related Topics · Priority Flow Control Overview, on page 57
Related Commands hw-module profile priority-flow-control location

Configurable ECN Threshold and Maximum Marking Probability Values

Table 15: Feature History Table

Feature Name

Release Information

Configurable ECN Threshold and Release 7.5.4 Maximum Marking Probability Values

Feature Description
While configuring PFC in the buffer-internal mode, you can now optimize congestion notification from the end router to the transmitting router, thus preventing the aggressive throttle of the source traffic. This optimization is possible because we’ve provided the flexibility to configure the minimum and maximum values for the ECN threshold and the maximum value for marking probability. With these values configured, the probability percentage marking is applied linearly, starting at the ECN minimum threshold till the ECN Max threshold.
Earlier releases fixed the maximum ECN marking probability at 100% at the maximum ECN threshold.
This functionality adds the following options to the hw-module profile priority-flow-control command:
· max-threshold
· probability-percentage

ECN Threshold and Maximum Marking Probability Values
So far, the maximum ECN marking probability was not configurable and was fixed at 100%. You couldn’t configure the ECN maximum threshold value either. Such an arrangement of preset marking probabilities and

Modular QoS Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.3.x 66

Configure Priority Flow Control

Benefits of Configurable ECN Threshold and Maximum Marking Probability Values

fixed maximum threshold values meant traffic rates began to drop as a function of the queue length. Because of the linear increase in the ECN marking probability–and the consequent congestion signaling from the end host to the transmitting host–traffic rates could begin slowing down even if your link had the necessary bandwidth.
W

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>