The documentation set for this product strives to use bias-free language. For the 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 RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Read this section to get an overview of packet classification and the different packet classification types for your router.
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.
|
Feature Name |
Release Information |
Feature Description |
|
QoS Support for VPWS |
Release 7.7.1 |
Now, you can apply QoS packet classification on Layer 2 subinterfaces, and for VPWS traffic. This feature provides ingress classification support for L2 attachment circuit (AC) traffic based on the 802.1p field priority value. With this feature, you can use QoS policies on VPWS traffic in your network on Cisco 8000 Series routers. |
EVPN-VPWS is a BGP control plane solution for point-to-point services. It implements the signaling and encapsulation techniques for establishing an EVPN instance between a pair of PEs. It has the ability to forward traffic from one network to another without a MAC lookup.
By configuring QoS, you can provide preferential treatment to specific types of traffic at the expense of other traffic types. Without QoS, the device offers best-effort service for each packet, regardless of the packet contents or size. The device sends the packets without any assurance of reliability, delay bounds, or throughput.
The 802.1Q standard (and 802.1ad, a subset of 802.1Q) defines a system of VLAN tagging for Ethernet frames and also contains a provision for a QoS prioritization scheme known as 802.1p, which indicates the priority level of the frame, as shown in the figure. For more information on IEEE standards, browse the IEEE website.
VLAN Tag Priority Field Based Classification
The QoS term class of service (CoS) is a 3-bit field called Priority Code Point (PCP) which specifies a priority value between 0 and 7 that is used by QoS to differentiate traffic. Drop Eligible Indicator (DEI) is a 1-bit field that is used to indicate frames eligible to be dropped during traffic congestion.
MQC allows configuration of class-map match condition based on the PCP and DEI fields. The classification is supported on 802.1Q and 802.1ad interfaces.
 Note |
The ingress classification supports AC-to-AC traffic flow and AC-to-PWE traffic flow. |
Follow these steps to enable this feature:
Enable VPWS configuration. Refer the L2VPN Configuration Guide for details.
Configure ingress traffic classification, based on the PCP and DEI fields in the VLAN header.
Create class maps for different traffic classes.
Associate them with a policy map.
Configure ingress traffic remarking.
Configure Ingress Traffic Classification Based on PCP and DEI Fields in the VLAN Header
/* Create class maps for different traffic classes */
Router# configure terminal
Router(config)# class-map match-all CONTROL_PLANE
Router(config-cmap)# match cos 7
Router(config-cmap)# end-class-map
Router(config)# class-map match-all VOIP
Router(config-cmap)# match cos 6
Router(config-cmap)# end-class-map
Router(config)# class-map match-all VIDEO_STREAM
Router(config-cmap)# match cos 5
Router(config-cmap)# end-class-map
Router(config)# class-map match-all TRANSACTIONAL_DATA
Router(config-cmap)# match cos 4
Router(config-cmap)# end-class-map
Router(config)# class-map match-all DB_SYNC
Router(config-cmap)# match cos 3
Router(config-cmap)# match dei 1
Router(config-cmap)# end-class-map
Router(config)# class-map match-all BULK_DATA
Router(config-cmap)# match cos 2
Router(config-cmap)# match dei 1
Router(config-cmap)# end-class-map
Router(config)# class-map match-all SCAVENGER
Router(config-cmap)# match cos 1
Router(config-cmap)# match dei 1
Router(config-cmap)# end-class-map
Router(config)# commit
/* Create a policy map and associate the class maps to it */
Router# configure terminal
Router(config)# policy-map INGRESS_L2_AC
Router(config-pmap)# class CONTROL_PLANE
Router(config-pmap-c)# set traffic-class 7
Router(config-pmap-c)# exit
Router(config-pmap)# class VOIP
Router(config-pmap-c)# set traffic-class 6
Router(config-pmap-c)# exit
Router(config-pmap)# class VIDEO_STREAM
Router(config-pmap-c)# set traffic-class 5
Router(config-pmap-c)# exit
Router(config-pmap)# class TRANSACTIONAL_DATA
Router(config-pmap-c)# set traffic-class 4
Router(config-pmap-c)# exit
Router(config-pmap)# class DB_SYNC
Router(config-pmap-c)# set traffic-class 3
Router(config-pmap-c)# exit
Router(config-pmap)# class BULK_DATA
Router(config-pmap-c)# set traffic-class 2
Router(config-pmap-c)# exit
Router(config-pmap)# class SCAVENGER
Router(config-pmap-c)# set traffic-class 1
Router(config-pmap-c)# exit
Router(config-pmap)# class class-default
Router(config-pmap-c)# exit
Router(config-pmap)# end-policy-map
Router(config)# commit
Configure Ingress Traffic Remarking
/* Set CoS and DEI values for traffic classes, as needed */
Router# configure terminal
Router(config)# policy-map INGRESS_L2_AC
Router(config-pmap)# class CONTROL_PLANE
Router(config-pmap-c)# set traffic-class 7
Router(config-pmap-c)# exit
Router(config-pmap)# class VOIP
Router(config-pmap-c)# set traffic-class 6
Router(config-pmap-c)# set cos 7
Router(config-pmap-c)# exit
Router(config-pmap)# class VIDEO_STREAM
Router(config-pmap-c)# set traffic-class 5
Router(config-pmap-c)# set cos 5
Router(config-pmap-c)# exit
Router(config-pmap)# class TRANSACTIONAL_DATA
Router(config-pmap-c)# set traffic-class 4
Router(config-pmap-c)# set cos 5
Router(config-pmap-c)# exit
Router(config-pmap)# class DB_SYNC
Router(config-pmap-c)# set traffic-class 3
Router(config-pmap-c)# set dei 0
Router(config-pmap-c)# exit
Router(config-pmap)# class BULK_DATA
Router(config-pmap-c)# set traffic-class 2
Router(config-pmap-c)# set cos 3
Router(config-pmap-c)# set dei 0
Router(config-pmap-c)# exit
Router(config-pmap)# class SCAVENGER
Router(config-pmap-c)# set traffic-class 1
Router(config-pmap-c)# exit
Router(config-pmap)# class class-default
Router(config-pmap-c)# set dei 1
Router(config-pmap-c)# end-policy-map
Router(config)# commit
/* Associate Policy-Map INGRESS_L2_AC With the Designated Subinterface */
Before you enable the subinterface, ensure that the parent interface state is up.
Router(config)# interface hundredGigE 0/11/0/31.102
Router(config-subif)# service-policy input INGRESS_L2_AC
Router(config-subif)# commit Verify ingress QoS policy configuration. In the output, you can see that traffic is classified and transmitted for some categories.
Router# show policy-map interface Hu0/11/0/31.102 input
HundredGigE0/11/0/31.102 input: INGRESS_L2_AC
Class CONTROL_PLANE
Classification statistics (packets/bytes) (rate - kbps)
Matched : 9813350/13738690000 936847
Transmitted : 9813350/13738690000 936847
Total Dropped : 0/0 0
Class VOIP
Classification statistics (packets/bytes) (rate - kbps)
Matched : 117760245/164864343000 11242157
Transmitted : 117760245/164864343000 11242157
Total Dropped : 0/0 0
Class VIDEO_STREAM
Classification statistics (packets/bytes) (rate - kbps)
Matched : 49066792/68693508800 4684233
Transmitted : 49066792/68693508800 4684233
Total Dropped : 0/0 0
Class TRANSACTIONAL_DATA
Classification statistics (packets/bytes) (rate - kbps)
Matched : 225707344/315990281600 21547467
Transmitted : 225707344/315990281600 21547467
Total Dropped : 0/0 0
Class DB_SYNC
Classification statistics (packets/bytes) (rate - kbps)
Matched : 0/0 0
Transmitted : 0/0 0
Total Dropped : 0/0 0
Class BULK_DATA
Classification statistics (packets/bytes) (rate - kbps)
Matched : 0/0 0
Transmitted : 0/0 0
Total Dropped : 0/0 0
Class SCAVENGER
Classification statistics (packets/bytes) (rate - kbps)
Matched : 0/0 0
Transmitted : 0/0 0
Total Dropped : 0/0 0
Class class-default
Classification statistics (packets/bytes) (rate - kbps)
Matched : 500482413/700675378200 47779164
Transmitted : 500482413/700675378200 47779164
Total Dropped : 0/0 0
Policy Bag Stats time: 1657528790084 [Local Time: 07/11/22 08:39:50.084]
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.
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.
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.
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 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.
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.
|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
Ingress and Egress Packet Classification |
Release 24.3.1 |
Introduced in this release on: Modular Systems (8800 [LC ASIC: P100]) (select variants only*), Fixed Systems (8200) (select variants only*), Fixed Systems (8700 (P100, K100)) (select variants only*) You can categorize packets into specific groups or classes and assign them traffic descriptors for QoS to classify and manage network traffic effectively. *This feature is supported on:
|
|
Ingress and Egress Packet Classification |
Release 24.2.1 |
Introduced in this release on: Modular Systems (8800 [LC ASIC: P100])(select variants only*) Categorizing packets into specific groups or classes and assigning them traffic descriptors for QoS helps classify and manage network traffic effectively. At the ingress, the QoS map and TCAM are used for classification. The QoS map is used for classification at the egress when policy matches only on DSCP, while TCAM is used for other criteria such as MPLS. *This feature is supported on 88-LC1-36EH. |
On your router, there are two types of packet classification systems:
In the ingress direction, QoS map and Ternary Content Addressable Memory (TCAM).
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.
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.
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.
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
!
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
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 Match NOT |
Support for Ranges |
Direction Supported on Interfaces |
|---|---|---|---|---|---|
|
IPv4 DSCP IPv6 DSCP |
(0,63) |
64 |
Yes |
Yes |
Ingress |
|
DSCP |
Egress |
||||
|
IPv4 Precedence IPv6 Precedence |
(0,7) |
8 |
Yes |
No |
Ingress |
|
Precedence |
Egress |
||||
|
MPLS Experimental Topmost |
(0,7) |
8 |
Yes |
No |
Ingress Egress |
|
Access-group |
Not applicable |
8 |
No |
Not applicable |
Ingress |
|
Match qos-group |
(1-31) |
7 + class-default |
No |
No |
Egress |
|
Protocol |
(0, 255) |
1 |
Yes |
Not applicable |
Ingress |
|
CoS |
(0,7) |
8 |
Yes |
No |
Ingress and Egress |
|
DEI |
(0,1) |
2 |
Yes |
No |
Ingress and Egress |
Unclassified traffic (traffic that doesn’t meet the match criteria specified in the traffic classes) is treated as belonging to the default traffic class.
If the user doesn’t 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 for seven groups with range (1-31) is supported. Match qos-group 0 can’t 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
!
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.
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.
You have to accomplish the following to complete the traffic class configuration:
Creating a class map
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.)
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:
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.
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 |
|
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.
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.
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.
You have to accomplish the following to complete the traffic policy configuration:
Creating a policy map that can be attached to one or more interfaces to specify a service policy
Associating the traffic class with the traffic policy
Specifying the class-action(s) (see Traffic Policy Elements)
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
|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
Enhanced Running Configuration Display for Policy Maps and Class Maps |
Release 24.2.11 |
You can view each class map or policy map running configuration instance on a separate line. The feature modifies the output display of this command: CLI: show run formal |
The class maps DSCP and MPLS are associated with the policy map p1.
After the configuration, its show run formal running configuration is displayed.
/* class map DSCP */
Router# config
Router(config)# class-map match-any DSCP
Router(config-cmap)# match dscp 1
Router(config-cmap)# end-class-map
/* class map MPLS */
Router(config)# class-map match-any MPLS
Router(config-cmap)# match mpls experimental topmost 2
Router(config-cmap)# end-class-map
/* DSCP-to-p1 association */
Router(config)# policy-map p1
Router(config-pmap)# class DSCP
Router(config-pmap-c)# bandwidth remaining ratio 80
Router(config-pmap-c)# root
/* MPLS-to-p1 association */
Router(config)# policy-map p1
Router(config-pmap)# class MPLS
Router(config-pmap-c)# bandwidth remaining ratio 60
Router(config-pmap-c)# exit
Router(config-pmap)# end-policy-map
Router(config)# commitVerification
The show run formal running configuration displays each class map and policy map running configuration instance on a separate line:
Router# show run formal
..
class-map match-any DSCP match dscp 1
class-map match-any MPLS match mpls experimental topmost 2
policy-map p1 class DSCP bandwidth remaining ratio 80
policy-map p1 class MPLS bandwidth remaining ratio 60
..show run and show run formal running configuration comparison:
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.
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. |
You have to accomplish the following to attach a traffic policy to an interface:
Creating a traffic class and the associated rules that match packets to the class (see Create a Traffic Class )
Creating a traffic policy that can be attached to one or more interfaces to specify a service policy (see Create a Traffic Policy )
Associating the traffic class with the traffic policy
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
/* 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
/* 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
!
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: 0
Total number of classes: 8
Interface Bandwidth: 400000000 kbps
Policy Name: strict-priority
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) = tc6
Egressq Queue ID = 2406 (HP2 queue)
Queue Max. BW. = no max (default)
TailDrop Threshold = 74999808 bytes / 2 ms (75 megabytes)
WRED not configured for this class
Level1 Class (HP3) = tc5
Egressq Queue ID = 2405 (HP3 queue)
Queue Max. BW. = no max (default)
TailDrop Threshold = 74999808 bytes / 2 ms (75 megabytes)
WRED not configured for this class
Level1 Class (HP4) = tc4
Egressq Queue ID = 2404 (HP4 queue)
Queue Max. BW. = no max (default)
TailDrop Threshold = 74999808 bytes / 2 ms (75 megabytes)
WRED not configured for this class
Level1 Class (HP5) = tc3
Egressq Queue ID = 2403 (HP5 queue)
Queue Max. BW. = no max (default)
TailDrop Threshold = 74999808 bytes / 2 ms (75 megabytes)
WRED not configured for this class
Level1 Class (HP6) = tc2
Egressq Queue ID = 2402 (HP6 queue)
Queue Max. BW. = no max (default)
TailDrop Threshold = 74999808 bytes / 2 ms (75 megabytes)
WRED not configured for this class
Level1 Class (HP7) = tc1
Egressq Queue ID = 2401 (HP7 queue)
Queue Max. BW. = no max (default)
TailDrop Threshold = 74999808 bytes / 2 ms (75 megabytes)
WRED not configured for this class
Level1 Class = class-default
Egressq Queue ID = 2400 (Default LP queue)
Queue Max. BW. = no max (default)
Inverse Weight / Weight = 1 / (BWR not configured)
TailDrop Threshold = 74999808 bytes / 150 ms (75 megabytes)
WRED not configured for this class
!
|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
QoS Policy Propagation via BGP |
Release 7.5.2 |
You now have the ability to install a BGP route in the routing table with a QoS Group so that IP packets that match the route receive the QoS policies associated with the QoS group. This functionality enables convenient classification and marking when BGP is deployed, overcoming the administrative challenges of classifying based on ACLs. |
QoS Policy Propagation via Border Gateway Protocol (QPPB via BGP) is a mechanism that allows propagation of quality of service (QoS) policy and classification by the sending party that is based on the following:
Access lists
Community lists
Autonomous system paths in the BGP
QPPB thus helps in classification that is based on the destination address instead of the source address.
QoS policies that differentiate between different types of traffic are defined for a single enterprise network. For instance, one enterprise may want to treat important web traffic, not-important web traffic, and all other data traffic as three different classes. And thereafter, use the different classes for the voice and video traffic.
Hence, QPPB overcomes:
the administrative challenges of classifying that is based on ACLs.
the administrative problems of just listing the networks that need premium services.
QPPB allows marking of packets that are based on QoS group value that is associated with a Border Gateway Protocol (BGP) route.
Benefits of QPPB
QPPB provides an IP prefix-based QoS capability.
Traffic to IP addresses that have specific IP prefixes can be prioritized above other IP addresses.
IP prefixes of interest are tagged through the control plane that uses common BGP route-map techniques, including the community attribute.
Traffic to the tagged BGP prefixes is then classified and prioritized via the data forwarding plane by using the IOS-XR MQC (Modular QoS CLI) mechanisms, such as remarking.
QPPB provides the glue between the BGP control plane and the IP data forwarding plane in support of IP prefix-based QoS.
BGP configuration within QPPB uses a table map to match specific prefixes learned through BGP neighbors, and then sets the router’s local QoS Group variable that is maintained within the Forwarding Information Base (FIB) for those specific prefixes.
Guidelines and Limitations
While configuring QPPB in the route policy for BGP, the range of the QoS group value that you can set using the set qos-group command is between 0 through 7.
IP precedence-based QPPB isn't supported; only QoS group-based QPPB is supported.
The order of precedence among ACL features (in ascending order):
With QoS-based group policy:
Security ACL (0), BGP-FS (1), QPPB (2), Peering QoS (3)
With ACL-based policy:
Security ACL (0), ACL based QoS (1), BGP-FS (2), QPPB (3)
You can configure QPPB on the following interface types:
Physical
Bundle
Physical subinterface
Bundle subinterface
QPPB is not supported on Q100-based routers or line cards.
QPPB overwrites the QoS Group value set by Security ACL.
If you configure ACL-based Switched Port Analyzer (SPAN) on an interface, you can't enable QPPB on that interface. To enable QPPB, remove the ACL-based SPAN from the interface.
If you configure QPPB on an interface, you can't enable ACL-based SPAN on that interface. To enable ACL-based SPAN, remove QPPB from the interface.
Peering QoS overwrites the QoS Group value set by QPPB.
Peering QoS and QPPB overwrite BGP FlowSpec actions except setting Drop and Policer. Currently, BGP FlowSpec sets DSCP and Meter.
Remarking support is the same that QoS currently supports.
Ingress policing support is the same that QoS currently supports.
Egress policing is not supported.
The router supports a subset of full QPPB options—only IP destination prefix mode on input policy is supported.
Router A learns routes from AS 200 and AS 100. QoS policy is applied to any ingress interface of Router A to match the defined route maps with destination prefixes of incoming packets. Matching packets on Router A to AS 200 or AS 100 are sent with the appropriate QoS policy from Router A.
BGP maintains a scalable database of destination prefixes, QPPB, by using BGP table maps. BGP adds the ability to map a qos-group value to desired IP destinations. These qos-group values are used in QoS policies applied locally on ingress interfaces. Whenever a packet that is bound for such destinations is encountered, the qos-group value matching that destination route looks up with work inside the policy classmap, and marks that packet for any configured policy actions.
Use the following configuration workflow for QPPB:
Define routing policy.
Put routing policy at table-policy attach point under BGP.
Define classmaps and ingress policy to use the qos-groups that are used in table-policy.
Enable IPv4 or IPv6 QPPB configuration under the desired interfaces.
A routing policy instructs the router to inspect routes, filter them, and potentially modify their attributes as they are accepted from a peer, advertised to a peer, or redistributed from one routing protocol to another.
The routing policy language (RPL) provides a language to express routing policy. You must set up destination prefixes either to match inline values or one of a set of values in a prefix set.
prefix-set prefix-list-v4
70.1.1.1,
70.2.1.0/24,
70.2.2.0/24 ge 28,
70.2.3.0/24 le 28
end-set
prefix-set prefix-list-v6
2001:300::2,
2003:200::3
end-set
route-policy qppb1
if destination in (60.60.0.2/24) then
set qos-group 5
elseif destination in prefix-list-v4 then
set qos-group 4
else
set qos-group 1
pass
endif
end-policy
route-policy qppb2
if destination in prefix-list-v6 then
set qos-group 5
elseif destination in (2001:300::2) then
set qos-group 4
else
set qos-group 1
pass
endif
end-policy
The table-policy attach point permits the routing policy to perform actions on each route as they are installed into the RIB routing table. QPPB uses this attachment point to intercept all routes as they are received from peers. Ultimately the RIB will update the FIB in the hardware forwarding plane to store destination prefix routing entries, and in cases where table policy matches a destination prefix, the qos-group value is also stored with the destination prefix entry for use in the forwarding plane.
router bgp 900
[vrf <name>]
bgp router-id 22.22.22.22
address-family ipv4 unicast
table-policy qppb1
address-family ipv6 unicast
table-policy qppb2
neighbor 30.2.2.1
remote-as 500
address-family ipv4 unicast
route-policy pass in
route-policy pass out
address-family ipv6 unicast
route-policy pass in
route-policy pass outQPPB is enabled per interface and individually for IPv4 and IPv6. An ingress policy matches on the QoS groups marked by QPPB and takes the required action.
If a packet is destined for a destination prefix on which BGP route policy has stored a qos-group , but it ingresses on an interface on which QPPB is not enabled, it would not be remarked with qos-group .
class-map match-any qos-group5
match qos-group 5
end-class-map
class-map match-any qos-group4
match qos-group 4
end-class-map
policy-map ingress-marker-po1
class qos-group5
set precedence 0
set discard-class 0
set traffic-class 1
class qos-group4
set precedence 1
set discard-class 1
set traffic-class 2
class class-default
end-policy-map
Interface hun 0/0/0/0
[vrf vrfA]
ipv4 address 25.1.1.1/24
ipv6 address 2001:db8:a0b:12f0::1/64
ipv4 bgp policy propagation input qos-group destination
ipv6 bgp policy propagation input qos-group destination
service-policy input ingress-marker-pol
The traffic-class set on ingress has no existence outside the device. Also, traffic-class is not a part of any packet header but is associated internal context data on relevant packets. It can be used as a match criteria in an egress policy to set up various fields on the outgoing packet or shape flows.
class-map match-any level1
match traffic-class 1
end-class-map
class-map match-any level2
match traffic-class 2
end-class-map
policy-map output-po1
class level1
bandwidth percent 50
class level2
bandwidth percent 20
queue-limit 50 ms
end-policy-map
interface hun 0/5/0/0
ipv4 address 30.1.1.1/24
ipv6 address 2001:da8:b0a:12f0::1/64
service-policy output output-po1|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
QoS on PWHE |
Release 24.3.1 |
Introduced in this release on: Modular Systems (8800 [LC ASIC: P100])(select variants only*) You can now prioritize critical services like voice, video, and real-time applications for network traffic entering a Pseudowire Headend (PWHE) interface, which then forwards the prioritized traffic into the pseudowire to be transported over a packet-switched network, such as an IP or MPLS network. The feature introduces the show qos-ea default-queue command. The feature modifies the *This feature is supported on:
|
QoS on Pseudowire Headend (PWHE) is a technology that
applies QoS mechanisms to pseudowire headend interfaces in a network
ensures that traffic transported over pseudowires is managed and prioritized effectively, and
enhances the performance and reliability of Layer 2 and Layer 3 VPN services on an edge router.
Pseudowires—Pseudowires (PWs) are virtual point-to-point connections that emulate the properties of traditional physical wires. They allow for the transport of various types of data over a packet-switched network, such as an IP or MPLS network. Pseudowires enable the extension of Layer 2 services over a Layer 3 infrastructure, providing a seamless and transparent connection between two endpoints.
PWHE— PWHE refers to the technology and configuration used to extend Layer 2 services over a Layer 3 network by creating virtual point-to-point connections known as pseudowires. The headend is the starting point of the pseudowire, typically located at the service provider's edge router. PWHE enables the seamless transport of various data types, such as Ethernet, Frame Relay, or asynchronous transfer mode (ATM), over an IP or MPLS backbone.
For more information on PWHE, see the chapter Configure Point-to-Point Layer 2 Services in the L2VPN Configuration Guide for Cisco 8000 Series Routers.
Before configuring QoS on PWHE interfaces, it's essential to understand the features and functionalities this technology provides and the restrictions that accompany them. These include:
Supported Features: Features supported on PWHE interfaces, including IPv4 and IPv6 support, policy maps for both ingress and egress traffic, and how policies are replicated across PWHE members.
Bandwidth Distribution: How PWHE and non-PWHE traffic share scheduling resources, and configuring bandwidth to manage excess distribution effectively.
Classification and Marking: Support for packet classification and marking based on Layer 2 and Layer 3 headers and specific configurations for PW-Ether main and PW-Ether subinterfaces.
Policing and Queuing: The policing features supported on PWHE interfaces and subinterfaces, including the replication of policies on bundle members and the effect of these policies on traffic management.
PWHE Aggregate Shaper Policies: PWHE aggregate shaper policies co-existing with subinterface policies, and various policy configurations and their implications on traffic flow.
IPv4 and IPv6 Support: The feature supports both address families.
QoS Policies:
Ingress: Support for policing and marking.
Egress: Support for marking and queuing.
Subinterface Policies:
You can apply policy maps on PW-Ether subinterfaces.
PW-Ether subinterfaces inherit policies from their main PW-Ether interface.
The table summarizes the policies you can configure on PWHE main and subinterfaces for egress.
|
On the egress PWHE main interface, when you configure... |
On the egress PWHE subinterface, you can configure... |
|---|---|
|
no policies. |
|
no policies. |
|
|
aggregate shaper, you can't configure a second policy. |
marking policy, but you can't set traffic class. You can set bandwidth allocation in the queuing policy. |
Simultaneous Policies: Policies at the port for transit traffic can be applied simultaneously with policies for PWHE interfaces.
Traffic Mapping for PWHE Interfaces to Pin-Down Members:
All the flows for a PWHE interface are mapped to single pin-down member.
Pinning down a member is a technique used to ensure that specific network resources remain consistently in use, providing stability, predictability, and control over network operations. This can be particularly useful in complex network environments where dynamic changes could lead to performance issues or disruptions.
For example, consider a case where the generic interface list has 10G and 100G interfaces, and 2 PWHE interfaces named PWHE-1 and PWHE-2 use this generic list.
|
If... |
Then... |
|---|---|
|
the traffic for PWHE-1 is hashed (or assigned) to the 10G interface |
all the traffic for PWHE-1 will exclusively use the pinned-down 10G interface. |
|
the traffic for PWHE-2 is hashed to the 100G interface |
all the traffic for PWHE-2 will exclusively use the pinned-down 100G interface. |
To summarize: Each PWHE interface's traffic is confined to a single physical interface from the generic interface list, ensuring that all data flows for that PWHE interface are routed through the same physical path.
Port Shaping Effect: A port shaping policy on a member interface influences the amount of traffic that can pass through that port. This is especially important when traffic is routed through specific physical interfaces or pin-down members.
For example, if a pin-down member (a specific interface) has a shaping policy set to 10G on its default traffic class (TC-0 ), then the maximum bandwidth allowed on that interface is 10G. Consider a PWHE interface (named PWHE-1 ) that has a shaping policy that allows it to use up to 50% of the available bandwidth but its traffic is hashed to the pin-down member with 10G shaping policy. In such a case, the maximum bandwidth for PWHE-1 traffic on that pin-down member will be 5G.
To summarize: The port shaping policy on a pin-down member directly determines the amount of PWHE traffic that can pass through that port. Even if a PWHE interface has its own shaping policy, the actual bandwidth used will be constrained by the shaping policy of the pin-down member it is hashed to.
You can fine-tune how leftover bandwidth is distributed among various traffic classes after the highest-priority traffic has received its guaranteed bandwidth. This functionality helps maintain fairness and efficiency in bandwidth utilization across different traffic classes.
PWHE and non-PWHE traffic on the same pin-down member share scheduling resources. We recommend that you configure bandwidth remaining in the parent class-default of PWHE policies to control the distribution of excess bandwidth:
between PWHE and non-PWHE traffic and
between various PWHE interfaces and physical interfaces.
QoS Accounting
QoS accounting provides the data necessary to assess whether the bandwidth remaining ratio effectively distributes resources according to policy, allowing for informed adjustments to optimize network performance.
Some key points about QoS accounting for PWHE are:
The packet length when performing QoS functions (such as policing, shaping, and gathering statistics) is based on the customer IP packet, customer L2 header and the configured additional overhead.
QoS statistics include the customer IP packet, customer L2 header and configured additional overhead.
Outer MPLS headers (such as VC labels and transport labels) and outer L2 header (Layer 2 encap of the underlying physical interface) will not be included in the packet length when performing QoS on the PWHE virtual interface.
Proper packet marking on both ingress and egress interfaces is critical for maintaining QoS across the network for PW-Ether traffic. Ingress marking involves classifying, marking, and policing traffic as it enters the pseudowire, while egress marking focuses on preserving or adjusting those markings as traffic exits. To that end, knowing the supported QoS markings for PWHE traffic at the ingress and egress is essential.
Restrictions for Marking PW-Ether in Ingress and Egress Directions
Marking of customer IP header, qos-group and discard-class are supported.
Marking of CoS bits in transport L2 header are not supported.
Depending on whether you want to apply conditional or unconditional markings and the traffic direction, you have different options.
|
Type of Marking |
For Traffic Type |
Supported Markings |
|---|---|---|
|
Unconditional |
Ingress and egress |
|
|
Conditional policer |
Ingress |
At most two from
|
|
Unconditional policer |
Egress |
DSCP or precedence value and discard-class |
All the policing features supported on normal L3 interfaces are also supported on the PWHE main interface and subinterface.
Depending on whether you attach a policy map to the PWHE interface or not, the queuing behavior changes for ingress and egress traffic.
| Policy Map | Egress Queues | Ingress Policers |
|---|---|---|
| PWHE interface with no policy map |
Each PWHE member has per port default queues. Egress traffic will use the member's port default queue. Queueing is supported only in the egress direction when you attach a service policy in the output direction. |
Not applicable |
| PWHE interface with a policy map |
Egress queues in the policy maps would be replicated on each PWHE member. |
Policer bandwidth is calculated based on active members per slice, that is, members attached to the generic interface list on the PWHE interface. |
Note |
If PWHE member is a bundle, policy maps will be replicated on bundle members. |
Statistics
Show commands for a PWHE virtual interface and PWHE subinterface QoS policy provide egress statistics per pin-down member and per bundle member if the bundle is a pin-down member.
PWHE aggregate shaper statistics aggregate queuing statistics of all subinterfaces for every pin-down member.
You can configure a line card to allow PWHE aggregate shaper policy to co-exist with subinterface policies. The PWHE aggregate shaper policy will only have a class-default with shape and bandwidth remaining actions.
The PWHE aggregate shaper policy can have
only shape action, or
only bandwidth remaining action or,
shape and bandwidth remaining actions (recommended).
policy-map pwhe-aggregate-shaper
class class-default
shape average 1 gbps
!
end-policy-map
!
end
policy-map pwhe-aggregate-shaper
class class-default
bandwidth remaining ratio 20
!
end-policy-map
!
end
policy-map pwhe-aggregate-shaper
class class-default
shape average 1 gbps
bandwidth remaining ratio 20
!
end-policy-map
!
end
Note |
We recommend that you configure shape and bandwidth remaining actions for PWHE aggregate shaper policy. |
You can apply QoS policies on PW-Ether subinterfaces when there is no policy applied on the main PW-Ether interface.
You can set bandwidth limits using percentage values at the most granular level within the policy hierarchy applied to a PW-Ether subinterface. This allows for flexible and precise bandwidth management on subinterfaces.
For example, if you have a policy that manages traffic on a PW-Ether subinterface, you can specify that a particular class of traffic should use, say, 20% of the available bandwidth. This configuration is supported at the most granular level of the policy.
QoS on PWHE supports 256 PWHE interfaces with either ingress or egress policies per line card.
Note |
The scale numbers are applicable only if you apply configurations such that the queuing resource is not exhausted. |
These cases represent the default behavior of PWHE interfaces without QoS policies:
PWHE ingress to core facing egress (access to core) - DSCP or precedence value from customer IP packet is copied to EXP of all imposed labels (VPN and transport) in the core-facing direction.
PWHE egress (core to access) - DSCP or precedence value from customer IP packet is copied to EXP in the access-facing direction.
You can configure PWHE in Layer 3 mode on PWHE-Ether main and subinterfaces.
QoS accounting, which measures and records the packet length when performing QoS functions such as policing, shaping, and gathering statistics, doesn't include PW headers.
match commands are optional when configuring QoS on PWHE. However, you must configure at least one match criterion for a class.
When using the match access-group command to configure the match criteria for a class map on the basis of the specified access control list (ACL), QoS classification based on the packet length or time to live (TTL) field in the IPv4 and IPv6 headers is not supported.
L2 header classification and marking are not supported on L3 PWHE interfaces.
Note |
The classification and marking applied on PW-Ether main interface are inherited by its subinterfaces without policy. |
Depending on your network's specific requirements and goals, you have different options for configuring QoS on PWHE interfaces.
The table calls out some of the suitable scenarios for different configuration options.
| Configuration option |
Suitable for... |
|---|---|
|
Flat QoS on PWHE |
simple traffic management and basic prioritization without hierarchical structuring. Recommended for small to medium-sized networks with uniform traffic. |
|
Hierarchical QoS (H-QoS) on PWHE |
complex traffic management with multiple levels of QoS policies. Recommended for large networks requiring granular control and hierarchical structuring. |
|
QoS with aggregate shaper on PWHE |
controlling total bandwidth usage and smoothing traffic bursts. Recommended for networks needing to manage overall bandwidth and prevent congestion. |
This task configures QoS policies for a physical interface and a PWHE interface.
Determine which types of traffic are critical and need prioritization with finer control. Also, see General Features and Support Information for QoS on PWHE for important information about the policies you can configure on PWHE main and subinterfaces for egress.
|
Step 1 |
Apply an input service policy named MAIN_IN_PMAP5 to the HundredGigE0/0/0/59 physical interface. Example: |
|
Step 2 |
Apply two output service policies named shape_flat_bwrr and MAIN_OUT_PMAP5_Q_TC_MARK to the PWHE interface named PW-Ether1 . Example: |
|
Step 3 |
Configure bandwidth remaining ratio in the shape_flat_bwrr service policy on the PW-Ether1 interface for different traffic classes. Example: |
|
Step 4 |
Set traffic classes in the MAIN_OUT_PMAP5_Q_TC_MARK policy on the PW-Ether1 interface. Example: |
|
Step 5 |
Set traffic classes and QoS groups in the MAIN_IN_PMAP5 policy on the HundredGigE0/0/0/59 physical interface. Example: |
|
Step 6 |
Verify the flat QoS configuration for the PWHE interface named PW-Ether1 . Example: |
This task sets up H-QoS on a PW-Ether interface. The configuration involves applying a parent policy map to the PW-Ether interface, which includes shaping and bandwidth management rules. The parent policy map references a child policy map that further defines bandwidth allocation and queuing for different traffic classes.
Determine which types of traffic are critical and need prioritization with finer control. Also, see General Features and Support Information for QoS on PWHE for important information about QoS policies on PWHE interfaces for egress.
|
Step 1 |
Apply an output service policy named parent_shape_hqos_bwrr to the PW-Ether1 interface. Example:This policy includes shaping and bandwidth management rules. |
|
Step 2 |
Define a policy map named parent_shape_hqos_bwrr for QoS. Example:Within the policy map, specify the class type as class-default and apply traffic shaping to it. |
|
Step 3 |
Reference a child policy map named shape_hqos_bwrr within class-default of the parent policy map. Example: |
|
Step 4 |
Define the child policy map shape_hqos_bwrr by specifying different classes within the map. Example:Configure QoS parameters such as bandwidth remaining ratio and traffic shaping for these classes depending on the control you want to achieve. |
|
Step 5 |
Verify the H-QoS configuration for the PW-Ether1 interface. Example: |
This task configures QoS policies for a PWHE interface and its subinterface. The main interface policy has a class-default (TC_0 ) with aggregate shaper with traffic shaping and bandwidth remaining rules.
Determine which types of traffic are critical and need prioritization with finer control. Also, see General Features and Support Information for QoS on PWHE for important information about the policies you can configure on PWHE main and subinterfaces for egress. Also, see PWHE Aggregate Shaper for details about aggregate shaper policies.
|
Step 1 |
Apply an output service policy with aggregate shaper named port_shaper_combination_hqos_bwrr to the PW-Ether1 main interface. Example: |
|
Step 2 |
Apply an output service policy named MAIN_OUT_DSCP_MARK to the PW-Ether1.1 subinterface. Example:Use this policy to mark DSCP values on outgoing traffic. |
|
Step 3 |
Define a policy map named MAIN_OUT_DSCP_MARK for QoS. Define a class map named MAIN_OUT_MARK_DSCP_CMAP_1 within the policy map. Example:Set the DSCP value to af11 for traffic matching the MAIN_OUT_MARK_DSCP_CMAP_1 class, and so on for class maps MAIN_OUT_MARK_DSCP_CMAP_2 through MAIN_OUT_MARK_DSCP_CMAP_6 . For the class map named MAIN_OUT_MARK_DSCP_CMAP_7 , set the DSCP value to ef for traffic matching the MAIN_OUT_MARK_DSCP_CMAP_7 class. This step sets specific DSCP values for different traffic classes. This policy is applied to the subinterface to ensure that outgoing traffic is marked with the appropriate DSCP values for QoS. |
|
Step 4 |
Verify that the aggregate shaper is enforced on the default traffic class TC_0 for the egress traffic from PW-Ether1 main interface. Example: |
|
Step 5 |
View detailed QoS statistics and configuration information for output traffic from the PW-Ether1 main interface. Example: |
|
Step 6 |
View detailed information about the QoS policy maps applied to the egress traffic on a specific member interface (HundredGigE0/7/0/2 ) on the PW-Ether1 main interface. Example: |
Feedback