QoS Deployment across Network Scenarios

Information flow

This content explains how QoS can be deployed in various network scenarios. It focuses on how classification and queuing decisions are influenced by traffic type and tunneling methods. The content also describes configurations that extend QoS capabilities beyond standard interfaces, such as Border Gateway Protocol (BGP) policy propagation and pseudowire headends.

Table 1. Information flow
Deployment scenario	What it covers	What it helps you achieve
QoS Policy Propagation via BGP	Describes how QoS classification and marking can be derived from BGP route attributes instead of ACLs. Explains the process of mapping prefixes to QoS groups and applying policies through routing table integration.	Enables scalable, destination-based QoS classification and consistent marking across networks where BGP is the control plane. Reduces manual ACL management and improves classification accuracy.
QoS on Pseudowire Headend	Explains how QoS policies apply to traffic bridging between Layer 2 and Layer 3 domains through BVIs. Covers marking, policing, and shaping behavior for bridged and routed traffic.	Ensures differentiated service treatment for traffic traversing bridge domains, maintaining consistent QoS handling between L2 and L3 segments.

QoS Policy Propagation via BGP

A QoS Policy Propagation via BGP (QPPB) mechanism is a Quality of Service (QoS) classification technique that

enables QoS classification by leveraging BGP attributes distributed through the BGP control plane
facilitates destination-based (or source-based) traffic classification by associating BGP routes with QoS groups, and
simplifies packet marking and prioritization without relying solely on access control lists (ACLs).

A QoS group is a numeric value associated with a route in the forwarding information base (FIB). The router uses this value to determine the traffic class or priority for packets that match that route.

Table 2. Feature History Table
Feature Name	Release Information	Feature Description
QoS Policy Propagation via BGP	Release 25.2.1	Introduced in this release on: Centralized Systems (8400 [ASIC: K100]) (select variants only) This feature is now supported on the Cisco 8404-SYS-D routers.
QoS Policy Propagation via BGP	Release 25.1.1	Introduced in this release on: Fixed Systems (8010 [ASIC: A100])(select variants only) This feature is now supported on the Cisco 8011-4G24Y4H-I routers.
QoS Policy Propagation via BGP	Release 24.4.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100, K100])(select variants only); Modular Systems (8800 [LC ASIC: P100])(select variants only) *This feature is now supported on: 8212-48FH-M 8711-32FH-M 8712-MOD-M 88-LC1-36EH 88-LC1-52Y8H-EM 88-LC1-12TH24FH-E
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.

QPPB integration of BGP and QoS groups

QPPB integrates the BGP control plane with the IP data forwarding plane. It uses routing policies and table maps to match specific prefixes learned through BGP neighbors and assigns a QoS group value. The FIB retains this value so the data plane can apply QoS actions such as remarking, shaping, or policing.

QPPB for Prioritizing Business-Critical Traffic

In an enterprise network, an administrator may want to prioritize mission-critical traffic, such as web-based business applications, over general data traffic. Using QPPB, the administrator can tag destination prefixes representing these business applications within the BGP route policy. When packets arrive at the ingress interface, the router automatically classifies and marks them according to their associated QoS group, ensuring consistent prioritization across the network.

Benefits of QoS Policy Propagation via BGP

QPPB provides these benefits:

IP prefix–based classification: enables IP prefix-based QoS classification and marking to differentiate traffic based on destination networks.
Traffic prioritization: prioritizes traffic to specific destination prefixes over other traffic classes for predictable service delivery.
Control plane integration: leverages the BGP control plane to tag prefixes using standard route-map techniques, ensuring consistent policy propagation.
Flexible remarking and prioritization: uses Modular QoS CLI (MQC) mechanisms for flexible remarking, queuing, and prioritization actions.
Control and forwarding plane alignment: establishes a direct connection between the BGP control plane routing decisions and the IP data forwarding plane for QoS enforcement.

How QoS Policy Propagation via BGP works

When a router receives routes from BGP peers, it can classify traffic based on route attributes rather than source information. QoS Policy Propagation via BGP (QPPB) works within the BGP process to assign QoS group values to specific destination prefixes. These values are then propagated to the forwarding plane, where packet-level actions are applied based on your policy.

Summary

The key components that are involved in the QPPB process are:

BGP control plane: learns routes and applies the table map or route policy to assign QoS group values.
Routing policy: defines which prefixes receive which QoS group values.
Forwarding plane (FIB): stores the assigned QoS group for each route and uses it to classify incoming packets.
QoS policy: uses the assigned QoS group values for marking, queuing, and shaping actions.

Workflow

These stages describe how QPPB works:

Router A in the figure receives routes from BGP peers (for example, AS 100 and AS 200) and evaluates each route using the configured routing policy.
The routing policy (table map) matches the destination prefix against defined criteria such as community lists, prefix sets, or autonomous system (AS) paths and assigns a QoS group value.
The router installs the route, along with its assigned QoS group, into the routing information base (RIB) and then into the forwarding information base (FIB).
When an incoming packet’s destination matches one of these prefixes, the router retrieves the corresponding QoS group from the FIB and classifies the packet accordingly.
The ingress QoS policy uses this QoS group to apply marking, queuing, or other actions.

Result

The QPPB process results in a scalable, BGP-driven QoS model that reduces administrative complexity and ensures consistent policy enforcement for traffic toward specific destinations.

Best practices for configuring QoS Policy Propagation via BGP

Configuration best practices

Configure QPPB with supported QoS group values and destination-prefix policies to ensure valid, consistent, destination-based classification.

Define route policies using the set qos-group command to assign QoS group values between 0 and 7.
Use QoS group-based classification. IP precedence–based QPPB is not supported.
Use IP destination prefix mode on input policies. This is the supported mode for QPPB.

Interface and hardware recommendations

Apply QPPB to supported interfaces and platforms. This approach prevents configuration failures and ensures correct QoS group propagation.

Apply QPPB on physical interfaces, bundle interfaces, or their subinterfaces based on your topology.
Do not configure QPPB on Q100-based routers or line cards, which do not support this feature.

Interactions with other features

Coordinate QPPB with ACL, FlowSpec, Peering QoS, and policing behavior to maintain predictable precedence.

Plan your QoS and ACL configurations considering ascending order feature precedence.
- For QoS group-based policy, the order is: Security ACL (0), BGP FlowSpec (1), QPPB (2), Peering QoS (3)
- For ACL-based policy, the order is: Security ACL (0), ACL-based QoS (1), BGP FlowSpec (2), QPPB (3)
Do not configure QPPB on Q100-based routers or line cards, which do not support this feature.
QPPB overwrites QoS group values set by security ACLs.
Peering QoS overwrites QoS group values set by QPPB.
Peering QoS and QPPB overwrite BGP FlowSpec actions, except for drop and policer.
QPPB does not support egress policing.

Compatibility with SPAN and remarking features

Verify Switched Port Analyzer (SPAN) and remarking compatibility before enabling QPPB to prevent interface conflicts and preserve expected QoS behavior.

You cannot enable ACL-based SPAN on interfaces where QPPB is configured. Disable ACL-based SPAN before applying QPPB on interfaces.
QPPB supports the same remarking and policing behavior as the current QoS features.

Configure QoS Policy Propagation via BGP

Use this task to configure QoS Policy Propagation via BGP (QPPB) so that traffic classification and marking occur automatically based on BGP-learned destination prefixes.

QPPB integrates BGP routing information with QoS classification. You define route policies that assign QoS group values to specific prefixes and apply them to BGP through a table-policy. Ingress and egress QoS policies then use those values to apply differentiated treatment to packets.

Before you begin

Ensure BGP is configured and routes are being exchanged with peers.
Verify that the target interfaces support QoS configuration.
Confirm that no ACL-based SPAN sessions are active on the same interfaces.

Follow these steps to configure QPPB.

Procedure

Step 1	Define a routing policy. Use the Routing Policy Language (RPL) to set up destination prefixes and assign QoS groups. Example: Router#configure Router(config)#prefix-set prefix-list-v4 Router(config-prefix-set)#70.1.1.1 Router(config-prefix-set)#70.2.1.0/24 Router(config-prefix-set)#70.2.2.0/24 ge 28 Router(config-prefix-set)#70.2.3.0/24 le 28 Router(config-prefix-set)#end-set Router(config)#prefix-set prefix-list-v6 Router(config-prefix-set)#2001:300::2 Router(config-prefix-set)#2003:200::3 Router(config-prefix-set)#end-set Router(config)#route-policy qppb1 Router(config-route-policy)#if destination in (60.60.0.2/24) then Router(config-route-policy)#set qos-group 5 Router(config-route-policy)#elseif destination in prefix-list-v4 then Router(config-route-policy)#set qos-group 4 Router(config-route-policy)#else Router(config-route-policy)#set qos-group 1 Router(config-route-policy)#pass Router(config-route-policy)#endif Router(config-route-policy)#end-policy Router(config)#commit This step uses prefix sets and route policies to classify BGP learned routes and tag them with QoS groups. For example: prefix set prefix-list-v4 includes 70.1.1.1 , 70.2.1.0/24 , and ranges like 70.2.2.0/24 ge 28 . Route policy assigns qos-group 5 to destination 60.60.0.2/24 , qos-group 4 to prefixes in prefix-list-v4 , and qos-group 1 otherwise. This step enables granular classification of traffic based on destination prefixes, essential for scalable QoS enforcement.
Step 2	Attach the routing policy at the table-policy point under BGP to apply QoS group values. Example: Router#configure Router(config)#router bgp 900 Router(config-bgp)#bgp router-id 22.22.22.22 Router(config-bgp)#address-family ipv4 unicast Router(config-bgp-af)#table-policy qppb1 Router(config-bgp-af)#exit Router(config-bgp)#address-family ipv6 unicast Router(config-bgp-af)#table-policy qppb2 Router(config-bgp-af)#exit Router(config-bgp)#neighbor 30.2.2.1 Router(config-bgp-nbr)#remote-as 500 Router(config-bgp-nbr)#address-family ipv4 unicast Router(config-bgp-nbr-af)#route-policy pass in Router(config-bgp-nbr-af)#route-policy pass out Router(config-bgp-nbr-af)#exit Router(config-bgp-nbr)#address-family ipv6 unicast Router(config-bgp-nbr-af)#route-policy pass in Router(config-bgp-nbr-af)#route-policy pass out Router(config-bgp-nbr-af)#exit Router(config-bgp-nbr)#exit Router(config-bgp)#exit Router(config)#commit This step attaches the route policy to BGP address families so routes carry QoS group values when installed in the RIB and FIB. For example, for router bgp 900 , it applies table-policy qppb1 for IPv4 unicast and table-policy qppb2 for IPv6 unicast address families. This step ensures QoS group values propagate with routing information, aligning control and forwarding planes for QoS.
Step 3	Configure ingress QoS and enable IPv4 or IPv6 BGP propagation. Example: Router#configure Router(config)#class-map match-any qos-group5 Router(config-cmap)#match qos-group 5 Router(config-cmap)#exit Router(config)#class-map match-any qos-group4 Router(config-cmap)#match qos-group 4 Router(config-cmap)#exit Router(config)#policy-map ingress-marker-po1 Router(config-pmap)#class qos-group5 Router(config-pmap-c)#set precedence 0 Router(config-pmap-c)#set discard-class 0 Router(config-pmap-c)#set traffic-class 1 Router(config-pmap-c)#exit Router(config-pmap)#class qos-group4 Router(config-pmap-c)#set precedence 1 Router(config-pmap-c)#set discard-class 1 Router(config-pmap-c)#set traffic-class 2 Router(config-pmap-c)#exit Router(config-pmap)#class class-default Router(config-pmap)#exit Router(config-pmap)#exit Router(config)#interface HundredGigE0/0/0/0 Router(config-if)#ipv4 address 25.1.1.1/24 Router(config-if)#ipv6 address 2001:db8:a0b:12f0::1/64 Router(config-if)#ipv4 bgp policy propagation input qos-group destination Router(config-if)#ipv6 bgp policy propagation input qos-group destination Router(config-if)#service-policy input ingress-marker-po1 Router(config-if)#exit Router(config)#commit This step defines class-maps matching QoS groups, creates a policy-map to set packet markings, and applies this policy on ingress interfaces. It also enables BGP policy propagation for IPv4 and IPv6. Specifically: class-map qos-group5 matches qos-group 5 , class-map qos-group4 matches qos-group 4 . policy-map ingress-marker-po1 sets precedence 0 for qos-group5 and precedence 1 for qos-group4 . This step automates packet marking based on destination prefixes, eliminating manual ACLs and simplifying QoS enforcement.
Step 4	Configure the egress interface policy. Example: Router#configure Router(config)#class-map match-any level1 Router(config-cmap)#match traffic-class 1 Router(config-cmap)#exit Router(config)#class-map match-any level2 Router(config-cmap)#match traffic-class 2 Router(config-cmap)#exit Router(config)#policy-map output-po1 Router(config-pmap)#class level1 Router(config-pmap-c)#bandwidth percent 50 Router(config-pmap-c)#exit Router(config-pmap)#class level2 Router(config-pmap-c)#bandwidth percent 20 Router(config-pmap-c)#queue-limit 50 ms Router(config-pmap-c)#exit Router(config-pmap)#exit Router(config)#interface HundredGigE0/5/0/0 Router(config-if)#ipv4 address 30.1.1.1/24 Router(config-if)#ipv6 address 2001:da8:b0a:12f0::1/64 Router(config-if)#service-policy output output-po1 Router(config-if)#exit Router(config)#commit The egress interface policy uses the traffic class assigned at ingress as an internal match criterion. The router applies QoS treatments such as bandwidth allocation and queue limits based on this class. Because traffic class is internal and not part of the packet header, the router enforces QoS consistently within the device without modifying packets. This approach leads to scalable and effective traffic management on egress interfaces. This step enforces QoS treatment such as bandwidth guarantees and queue management, ensuring consistent traffic handling downstream.

Your router automatically classifies and marks packets based on BGP-learned destination prefixes. This enables scalable, policy-driven QoS control without manual ACL-based classification.

QoS on Pseudowire Headend

Quality of Service (QoS) on Pseudowire Headend (PWHE) is a network traffic management feature that

applies QoS classification, marking, policing, and queuing on pseudowire headend interfaces
ensures prioritized forwarding of customer traffic that enters a pseudowire, and
enhances the performance and reliability of Layer 2 and Layer 3 VPN services on edge routers.

Pseudowire (PW)—A pseudowire is a virtual, point-to-point connection that emulates the properties of a physical wire. It allows the transport of various Layer 2 services, such as Ethernet, Frame Relay, or Asynchronous Transmission Mode (ATM), over a Layer 3 packet-switched network like IP or MPLS.

Pseudowire Headend (PWHE)—PWHE refers to the interface and configuration at the start of a pseudowire connection on an edge router. It provides the logical boundary where traffic from a customer or access network is encapsulated into a pseudowire for transport across the core.

QoS on PWHE and the importance of headend

PWHE allows Layer 2 services to be extended over a Layer 3 network. By applying QoS at the headend, traffic entering the pseudowire can be policed, shaped, and marked to maintain consistent QoS treatment across the MPLS or IP backbone. This ensures that latency-sensitive traffic such as voice or video is forwarded with the appropriate priority.

Table 3. Feature History Table
Feature Name	Release Information	Feature Description
QoS on PWHE	Release 25.4.1	Introduced in this release on: Fixed Systems (8010 [ASIC: A100])(select variants only) This feature is supported on the Cisco 8011-32Y8L2H2FH routers.
QoS on PWHE	Release 25.3.1	Introduced in this release on: Centralized Systems (8400 [ASIC: K100])(select variants only) This feature is now supported on Cisco 8404-SYS-D routers.
QoS on PWHE	Release 25.1.1	Introduced in this release on: Fixed Systems (8700 [ASIC:K100])(select variants only) This feature is now supported on Cisco 8712-MOD-M routers.
QoS on PWHE	Release 24.3.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100])(select variants only); 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 `Cisco-IOS-XR-qos-ma-oper.yang` (see GitHub, YANG Data Models Navigator) data model. *This feature is supported on: 8212-48FH-M 8711-32FH-M 88-LC1-36EH 88-LC1-52Y8H-EM 88-LC1-12TH24FH-E

QoS on PWHE in practice

For example, a service provider can configure QoS on a PWHE interface so that voice and video services are prioritized when they enter the pseudowire. These packets are then transported across the MPLS core with markings that preserve their service class, ensuring consistent performance end-to-end.

How QoS on Pseudowire Headend works

Pseudowire Headend (PWHE) extends QoS control to pseudowire interfaces. This enables per-class differentiation and bandwidth management alongside core interfaces.

Summary

The key components in the QoS process on PWHE interfaces are:

Classification and marking: The router examines Layer 2 and Layer 3 header fields on ingress and egress to identify traffic classes and apply appropriate QoS group and traffic class markings.
Policing and queuing: The router applies policing on ingress to control traffic rates and uses queuing and shaping on egress to manage congestion and enforce bandwidth guarantees.
Bandwidth distribution: The system allocates excess bandwidth between PWHE and non-PWHE traffic that share the same interface.
Aggregate shaper: The line card supports an aggregate shaping policy that coexists with subinterface policies.
Traffic pin-down: Each PWHE interface maps its traffic to a single physical interface, known as a pin-down member.
QoS accounting: The router collects QoS statistics based on the customer IP packet, Layer 2 header, and any configured overhead.

Workflow

These stages describe how QoS on PWHE operates.

Ingress classification and policing: The router receives incoming traffic on the PWHE interface and classifies it based on Layer 2 and Layer 3 header fields. This stage ensures that packets entering the pseudowire are marked and rate-limited in alignment with service policies.
Pin-down selection: The router assigns each PWHE interface to a single physical interface called a pin-down member, selected from a generic interface list. This mapping remains constant for all traffic belonging to that PWHE interface. The pin-down mechanism ensures that traffic flows consistently through the same physical path, maintaining predictable forwarding and shaping behavior.
Port shaping interaction: The router enforces port-level shaping policies configured on the pin-down member. These shaping parameters limit the maximum bandwidth that all PWHE traffic mapped to that member can use. As a result, even if the PWHE interface allows a higher percentage of bandwidth, its effective throughput is constrained by the shaping policy on the pin-down member.
Egress queuing and shaping: When packets are forwarded toward the pseudowire egress, the router derives the egress queues and shaping actions from the QoS policies applied to the PWHE main or subinterfaces. These egress queues are replicated on each member or bundle interface as applicable, ensuring consistent queuing behavior across all physical members.
Bandwidth remaining distribution: After high-priority traffic receives its guaranteed bandwidth, the router distributes the remaining bandwidth among PWHE and non-PWHE traffic on the same pin-down member. It uses the bandwidth remaining ratios configured in the parent class-default of the PWHE policies to control how the excess bandwidth is shared across different classes and interfaces.
QoS accounting and verification: The router collects QoS accounting statistics that include the customer IP packet, customer Layer 2 header, and any configured additional overhead. It excludes outer transport and encapsulation headers. You can use these statistics to verify policy behavior, evaluate bandwidth distribution, and fine-tune configurations for optimal performance.

Result

QoS on PWHE ensures that traffic is consistently prioritized, shaped, and accounted for, maintaining predictable performance for pseudowire-based services and fair resource allocation across shared physical interfaces.

Functional details and behaviors of QoS on PWHE

QoS on PWHE provides the framework for applying consistent service differentiation to pseudowire-based traffic.

Each topic in this section explains a specific operational aspect, such as bandwidth distribution, aggregate shaping, or policing behavior, that contributes to the overall performance of QoS on PWHE interfaces.

Before configuring QoS on PWHE interfaces, it's essential to understand the features and functionalities this technology provides and the restrictions that accompany them.

Table 4. Reference Information about Functional Details and Behaviors
Information	What It Covers
General features and support information for QoS on PWHE	Lists address-family support, policy directions, and inheritance rules for main and subinterfaces.
Traffic mapping for Pseudowire Headend interfaces to pin-down members	Explains how PWHE traffic maps to a single physical interface (pin-down member) for predictable flow paths.
Port shaping effect on pin-down members	Describes how port-level shaping on a pin-down member constrains the total bandwidth available to mapped PWHE traffic.
Bandwidth distribution for QoS on Pseudowire Headend	Details how remaining bandwidth is distributed fairly among PWHE and non-PWHE traffic on shared members.
QoS accounting for Pseudowire Headend traffic	Defines how the router measures and reports PWHE traffic for policing, shaping, and statistics.
Marking for QoS on Pseudowire Headend	Summarizes supported marking types and restrictions for ingress and egress directions.
Policing and queuing for QoS on Pseudowire Headend	Explains ingress policing and egress queuing behavior with and without policy maps, including bundle replication
Pseudowire Headend aggregate shaper	Describes aggregate shaping policies that coexist with subinterface policies and the supported action combinations.
Pseudowire Ethernet subinterface policy	Provides information on applying QoS policies at the subinterface level and setting bandwidth limits.
Scale information for QoS on Pseudowire Headend interfaces	Lists the supported number of PWHE interfaces per line card and scale considerations.
Pseudowire Headend without QoS policy	Explains default traffic behavior when no QoS policies are applied to a PWHE interface.

General features and support information for QoS on PWHE

Read this topic to understand the foundational support details for QoS on PWHE, including address-family compatibility, policy directions, and subinterface inheritance behavior. Knowing these details helps you apply policies correctly on main and subinterfaces. This ensures that configurations remain supported and behave as expected across IPv4 and IPv6 deployments.

The feature supports:

IPv4 address families
IPv6 address families

QoS policies supported:

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.

This table summarizes the policies you can configure on PWHE main and subinterfaces for egress.

Table 5. Egress Policy Matrix (Main versus Subinterface)
On the egress PWHE main interface	On the egress PWHE subinterface
when you configure one of the following: two-level H-QoS queuing policy or flat QoS queuing policy, marking policy, or both	you cannot configure any policies.
if you do not configure any policies	you can configure one of the following: two-level H-QoS queuing policy or flat QoS queuing policy, marking policy, or both
if you configure aggregate shaper, you cannot configure a second policy	you can configure a marking policy, but you cannot set the traffic class. You can set the bandwidth allocation in the queuing policy.

Simultaneous policies on port and PWHE interfaces:

You can apply policies at the port for transit traffic while also applying policies for PWHE interfaces.
This application enables concurrent control of core and pseudowire traffic on the same device.

Traffic mapping for Pseudowire Headend interfaces to pin-down members

By pinning down a member, you keep specific network resources in use. This method gives you stability, predictability, and control over operations. Use it for complex network environments, where dynamic changes can cause issues.

A Pseudowire Headend (PWHE) interface sends its traffic to a specific physical (or pin-down) member. The mapping determines how flows are assigned and maintained for predictable forwarding and shaping.

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 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.
- If 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.
Each PWHE interface directs its traffic through a single physical interface from the generic interface list, so all data flows for that PWHE interface use the same physical path.

Port shaping effect on pin-down members

Port shaping determines how much bandwidth a pin-down member can provide to pseudowire headend (PWHE) traffic.

Understanding this behavior helps you predict effective throughput when PWHE interfaces share the same physical interface.

Port shaping defines how bandwidth limits configured on a physical member influence the total rate available to PWHE traffic pinned to that member.

Rate limitation: A shaping policy on a member interface restricts the maximum amount of traffic that can pass through that port. This constraint affects all PWHE interfaces that are hashed to the same physical member.
Example scenario: If a pin-down member has a shaping policy set to 10 G on its default traffic class (TC-0), the maximum bandwidth allowed on that interface is 10 G. When a PWHE interface (for example, PWHE-1) is configured to use 50% of available bandwidth and is pinned to that member, the effective maximum bandwidth for PWHE-1 is 5 Gbps.
Operational summary: The shaping configuration on the physical port directly determines the throughput available to PWHE traffic. Even if a PWHE interface has its own shaping policy, its actual transmission rate is constrained by the shaping policy of the pin-down member it uses.

Bandwidth distribution for QoS on Pseudowire Headend

Bandwidth distribution controls how excess capacity is shared across classes once high-priority traffic has received its guaranteed bandwidth. Understanding this mechanism helps maintain fairness and efficient utilization of shared physical resources.

Bandwidth distribution determines how remaining capacity is shared between Pseudowire Headend (PWHE) and non-PWHE traffic after guaranteed service levels are met.

Shared resource control: PWHE and non-PWHE traffic on the same pin-down member share scheduling resources dynamically based on configured bandwidth ratios.
Policy tuning: Configure bandwidth remaining ratio values in the parent class-default of PWHE policies to control excess-bandwidth allocation.
- between PWHE and non-PWHE traffic and
- between various PWHE interfaces and physical interfaces.
Operational guidance: Adjust these ratios to maintain fairness and prevent oversubscription between pseudowire traffic and core traffic.

QoS accounting for Pseudowire Headend traffic

QoS accounting measures how pseudowire traffic consumes bandwidth and applies QoS functions, including policing, shaping, and collecting statistics. Accurate accounting enables you to verify performance, troubleshoot issues, and optimize configurations.

QoS accounting describes how the router measures and reports traffic that is handled by PWHE interfaces. This helps validate policy effectiveness and ensures accurate performance analysis.

Measurement basis: Packet length calculations when performing QoS functions (such as policing, shaping, and gathering statistics) include the customer IP packet, the customer Layer 2 header, and any configured overhead.
Exclusion scope: Outer MPLS headers (such as VC and transport labels) and outer Layer 2 headers (Layer 2 encap of the underlying physical interface) of the physical interface are not counted.
Operational use: These statistics provide insight into actual customer traffic and enable validation of QoS policy outcomes.

Marking for QoS on Pseudowire Headend

Marking identifies packet classes and preserves differentiated treatment as traffic enters and exits the pseudowire. Understanding supported marking options ensures consistent end-to-end QoS behavior.

Marking defines which header fields the router can set on Pseudowire Headend (PWHE) interfaces and how those markings apply in the ingress and egress directions.

Supported fields: Marking of the customer IP header (DSCP or precedence), qos-group, and discard-class is supported.
Transport CoS limitation: Marking of CoS bits in the transport Layer 2 header is not supported.
Unconditional marking (ingress and egress): You can set DSCP or precedence, discard-class , and qos-group .
Conditional policer marking (ingress): You can set at most two of these— DSCP or precedence, qos-group , discard-class .
Unconditional policer marking (egress): You can set DSCP or precedence and discard-class .

Table 6. Marking Options and Supported Traffic Direction
Type of marking	Traffic direction	Supported markings
Unconditional	Ingress and egress	DSCP or precedence, discard-class , qos-group
Conditional policer	Ingress	Any two of: DSCP or precedence, qos-group , discard-class
Unconditional policer	Egress	DSCP or precedence, discard-class
Transport L2 CoS	Ingress or egress	Not supported

Policing and queuing for QoS on Pseudowire Headend

Policing regulates ingress rates while queuing and shaping control egress scheduling. Understanding these behaviors ensures predictable bandwidth enforcement and priority handling for Pseudowire Headend (PWHE) traffic.

Policing and queuing govern how PWHE traffic complies with configured rates and how packets are scheduled on egress:

Ingress policing: All policing features supported on normal Layer 3 interfaces are supported on the PWHE main interface and subinterfaces.
Bundles: If a PWHE member is a bundle, policy maps are replicated on bundle members.
Statistics: Show commands provide egress statistics per pin-down member and per bundle member. Aggregate shaper statistics summarize subinterface queues per pin-down member.

If you attach a policy map to the PWHE interface, queuing behavior changes for ingress and egress traffic.

Table 7. PWHE Queuing and Policing Behavior
Policy map on PWHE	Egress queues	Ingress policers
None	Each PWHE member has default queues for each port. Egress traffic uses the member's port default queue. Queuing is supported in the egress direction only when a service policy is attached in the output direction.	Not applicable
Present	Egress queues in the policy maps are replicated on each PWHE member.	Policer bandwidth is calculated based on active members per slice. These are the members attached to the generic interface list on the PWHE interface.

Pseudowire Headend aggregate shaper

The aggregate shaper limits the total egress rate for Pseudowire Headend (PWHE) traffic while allowing subinterfaces to enforce class-level policies.

The PWHE aggregate shaper operates on class-default and can coexist with subinterface policies using supported action combinations.

Action scope: The aggregate shaper policy contains class-default with shape and bandwidth remaining actions.
Supported combinations for the aggregate shaper policy:
- Only shape action
- Only bandwidth remaining action, or
- both shape and bandwidth remaining actions (recommended)
Coexistence rule: Coexistence rule: The aggregate shaper can coexist with subinterface policies. If a shaper is configured on the main interface, you cannot configure another shaping policy.

Table 8. Aggregate Shaper Action Variants
Policy variant	Actions in class-default
Only shape	shape average <rate>
Only bandwidth remaining	bandwidth remaining ratio <value>
Both shape and bandwidth remaining actions (recommended)	shape average <rate> and bandwidth remaining ratio <value>

Pseudowire Ethernet subinterface policy

Subinterface policies enable fine-grained QoS management at lower levels of the interface hierarchy. You can specify how bandwidth and marking are applied to specific classes of traffic on each pseudowire subinterface.

Apply PW-Ethernet subinterface policies for granular QoS management when no policy exists on the parent PW-Ether interface. Key features include:

Applicability: You can apply QoS policies on PW-Ether subinterfaces only when no policy exists on the main PW-Ether interface.
Granular bandwidth control: You can configure bandwidth limits as percentage values for each class within the subinterface policy hierarchy. 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 percent of the available bandwidth.
Differentiated treatment: These subinterface-level configurations let you assign distinct service levels for different customers or applications.
Hierarchy consistency: Subinterface policies align with parent aggregate and shaping policies to maintain overall QoS consistency.

Scale information for QoS on Pseudowire Headend interfaces

Scale information helps you plan configurations that remain within hardware resource limits and maintain consistent performance.

Router-specific scale values define how many Pseudowire Headend (PWHE) interfaces can simultaneously support ingress or egress QoS policies without depleting queueing resources.

Line Card Capacity:
- Each line card supports up to 256 PWHE interfaces with ingress or egress QoS policies.
- This scale is valid only if queuing resources are not exhausted.
- The actual scale also depends on available queuing and shaping resources and the complexity of the policies applied.
- Exceeding these limits may cause policy application failures or degraded performance.
Resource Dependency: The actual scale depends on available queuing and shaping resources. Higher policy complexity can reduce effective scale.

Pseudowire Headend without QoS policy

When a PWHE interface does not have an explicit QoS policy, the router still applies basic classification by copying IP header markings into MPLS labels. Knowing this default behavior helps you predict traffic handling before applying explicit policies.

Default QoS on PWHE interfaces exhibits these behaviors:

PWHE ingress to core-facing egress (access to core): DSCP or precedence values from the customer IP packet are copied to the EXP bits of all imposed labels (VPN and transport).
PWHE egress (core to access): DSCP or precedence values from the customer IP packet are copied to the EXP field in the access facing direction.
Operational impact: These inherited markings preserve basic service differentiation. Bandwidth and queueing controls are not enforced until explicit policies are applied.

Limitations for QoS on Pseudowire Headend

These constraints apply to QoS on pseudowire headend interfaces:

Interface support: Configure QoS only on PW-Ether main or subinterfaces operating in Layer 3 mode.
QoS accounting scope: QoS accounting does not include pseudowire (PW) headers when measuring and recording packet length.

Configuration rules
- When defining QoS policies, include at least one match criterion per class.
- Use supported classification methods for matching access groups in class maps in IPv4 or IPv6. Packet-length or Time to Live (TTL)-based classification is not supported.
Classification and marking inheritance
- Do not use Layer 2 header-based classification and marking on Layer 3 PWHE interfaces.
- Subinterfaces inherit classification and marking behavior from the PW-Ether main interface if no explicit policy is configured.
Egress QoS-group classification: Use classification methods other than QoS group for BUM traffic in access-to-pseudowire flows.

Configuration options for QoS on Pseudowire Headend

Use this reference to identify which QoS configuration best suits your Pseudowire Headend deployment.

The table helps you compare scenarios and select the configuration that matches your traffic type and shaping requirements.

Table 9. Selecting the Appropriate QoS Configuration on PWHE Interfaces
Configuration option	When to use	Network scale	Recommended for
Configure Flat QoS on Pseudowire Headend	Simple traffic management and basic prioritization; no hierarchy needed	Small to medium	Uniform traffic in which marking and queuing apply directly at the interface
Configure Hierarchical QoS on Pseudowire Headend	Multilevel control with parent and child policies	Large	Differentiated voice, video, and data with layered shaping and bandwidth
Configure QoS with aggregate shaper on Pseudowire Headend	Control total bandwidth and smooth bursts while preserving class QoS	Large	Multiple PW-Ether subinterfaces share physical bandwidth and require port level limits

Configure Flat QoS on Pseudowire Headend

Configure a single-level policy on a PWHE interface to prioritize traffic classes.

Flat QoS provides a single policy level on the PW-Ether interface. You manage ingress marking and policing, as well as egress queuing and shaping directly.

Before you begin

Identify classes and priority. Ensure there is no conflicting aggregate shaper on the main interface.

Follow these steps to configure flat QoS on a PWHE interface.

Procedure

Step 1	Apply an input service policy to the physical interface Example: `Router(config)#interface HundredGigE0/0/0/59 Router(config-if)#service-policy input MAIN_IN_PMAP5 Router(config-if)#commit` This example applies an input service policy named MAIN_IN_PMAP5 to the HundredGigE0/0/0/59 physical interface.
Step 2	Apply output service policies to the PWHE interface. Example: `Router(config)#interface PW-Ether1 Router(config-if)#service-policy output shape_flat_bwrr Router(config-if)#service-policy output MAIN_OUT_PMAP5_Q_TC_MARK Router(config-if)#commit` This example applies two service policies named shape_flat_bwrr and MAIN_OUT_PMAP5_Q_TC_MARK to the PWHE interface named PW-Ether .
Step 3	Define class maps and policy maps for traffic classes. Example: Router(config)#policy-map type qos shape_flat_bwrr Router(config-pmap)#class type qos MAIN_OUT_CMAP_1 Router(config-pmap-c)#bandwidth remaining ratio 20 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_2 Router(config-pmap-c)#bandwidth remaining ratio 30 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_3 Router(config-pmap-c)#bandwidth remaining ratio 40 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_4 Router(config-pmap-c)#bandwidth remaining ratio 50 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_5 Router(config-pmap-c)#bandwidth remaining ratio 60 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_6 Router(config-pmap-c)#shape average percent 30 Router(config-pmap-c)#priority level 2 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_7 Router(config-pmap-c)#shape average percent 40 Router(config-pmap-c)#priority level 1 Router(config-pmap)#end-policy-map This step configures bandwidth remaining ratio in the shape_flat_bwrr service policy on the PW-Ether1 interface for different traffic classes. It defines how bandwidth is distributed and prioritized among classes on the PWHE interface.
Step 4	Set traffic classes on the PWHE interface. Example: Router(config)#policy-map type qos MAIN_OUT_PMAP5_Q_TC_MARK Router(config-pmap)#class type qos MAIN_OUT_MARK_CMAP_1 Router(config-pmap-c)#set traffic-class 1 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_CMAP_2 Router(config-pmap-c)#set traffic-class 2 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_CMAP_3 Router(config-pmap-c)#set traffic-class 3 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_CMAP_4 Router(config-pmap-c)#set traffic-class 4 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_CMAP_5 Router(config-pmap-c)#set traffic-class 5 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_CMAP_6 Router(config-pmap-c)#set traffic-class 6 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_CMAP_7 Router(config-pmap-c)#set traffic-class 7 Router(config-pmap-c)#exit Router(config-pmap)#end-policy-map This example sets traffic classes in the MAIN_OUT_PMAP5_Q_TC_MARK policy on the PW-Ether1 interface. This enables consistent QoS treatment across the network.
Step 5	Set traffic classes and QoS groups on the physical interface. Example: Router(config)#policy-map type qos MAIN_IN_PMAP5 Router(config-pmap)#class type qos MAIN_IN_CMAP8_1 Router(config-pmap-c)#set traffic-class 1 Router(config-pmap-c)#set qos-group 1 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_IN_CMAP8_2 Router(config-pmap-c)#set traffic-class 2 Router(config-pmap-c)#set qos-group 2 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_IN_CMAP8_3 Router(config-pmap-c)#set traffic-class 3 Router(config-pmap-c)#set qos-group 3 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_IN_CMAP8_4 Router(config-pmap-c)#set traffic-class 4 Router(config-pmap-c)#set qos-group 4 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_IN_CMAP8_5 Router(config-pmap-c)#set traffic-class 5 Router(config-pmap-c)#set qos-group 5 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_IN_CMAP8_6 Router(config-pmap-c)#set traffic-class 6 Router(config-pmap-c)#set qos-group 6 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_IN_CMAP8_7 Router(config-pmap-c)#set traffic-class 7 Router(config-pmap-c)#set qos-group 7 Router(config-pmap-c)#exit Router(config-pmap)#end-policy-map Router(config-pmap)#commit This example sets traffic classes and QoS groups in the MAIN_IN_PMAP5 policy on the HundredGigE0/0/0/59 physical interface. It ensures ingress traffic is properly classified and marked for QoS enforcement.
Step 6	Verify the flat QoS configuration for the PWHE interface. Example: Router#show policy-map interface PW-Ether1 output PW-Ether1 output: shape_flat_bwrr Class MAIN_OUT_CMAP_1 Classification statistics (packets/bytes) (rate - kbps) Matched : 3713933519/885747042770 20297753 Transmitted : 819154447/194810747182 4464282 Total Dropped : 2894779072/690936295588 15833471 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 2894779072/690936295588 Class MAIN_OUT_CMAP_2 Classification statistics (packets/bytes) (rate - kbps) Matched : 3713933859/885747126352 20297723 Transmitted : 1226431948/292261487200 6697427 Total Dropped : 2487501911/593485639152 13600296 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 2487501911/593485639152 Class MAIN_OUT_CMAP_3 Classification statistics (packets/bytes) (rate - kbps) Matched : 3713934320/885747236808 20297726 Transmitted : 1635701991/389672415000 8929683 Total Dropped : 2078232329/496074821808 11368043 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 2078232329/496074821808 Class MAIN_OUT_CMAP_4 Classification statistics (packets/bytes) (rate - kbps) Matched : 3713934620/885747307472 20297725 Transmitted : 1962135193/467620808304 10715952 Total Dropped : 1751799427/418126499168 9581773 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 1751799427/418126499168 Class MAIN_OUT_CMAP_5 Classification statistics (packets/bytes) (rate - kbps) Matched : 3713934983/885747394920 20297724 Transmitted : 2453607357/584506995776 13394493 Total Dropped : 1260327626/301240399144 6903231 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 1260327626/301240399144 Class MAIN_OUT_CMAP_6 Classification statistics (packets/bytes) (rate - kbps) Matched : 3713935277/885747464816 20297721 Transmitted : 3713522895/885652168176 20295533 Total Dropped : 412382/95296640 2188 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 412382/95296640 Class MAIN_OUT_CMAP_7 Classification statistics (packets/bytes) (rate - kbps) Matched : 3713935660/885747555696 20297721 Transmitted : 3713935660/885747555696 20297721 Total Dropped : 0/0 0 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 0/0 Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 3713933237/885746977848 20297727 Transmitted : 40921134/9742495832 223233 Total Dropped : 3673012103/876004482016 20074494 Policy Bag Stats time: 1722242150998 [Local Time: 07/29/24 08:35:50.998] PW-Ether1 output: MAIN_OUT_PMAP5_Q_TC_MARK Class MAIN_OUT_MARK_CMAP_1 Classification statistics (packets/bytes) (rate - kbps) Matched : 3714522947/885887620056 20317550 Transmitted : 3714522947/885887620056 20317550 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_2 Classification statistics (packets/bytes) (rate - kbps) Matched : 3714523360/885887719136 20317549 Transmitted : 3714523360/885887719136 20317549 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_3 Classification statistics (packets/bytes) (rate - kbps) Matched : 3714523737/885887808376 20317548 Transmitted : 3714523737/885887808376 20317548 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_4 Classification statistics (packets/bytes) (rate - kbps) Matched : 3714524115/885887898616 20317547 Transmitted : 3714524115/885887898616 20317547 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_5 Classification statistics (packets/bytes) (rate - kbps) Matched : 3714524499/885887990496 20317545 Transmitted : 3714524499/885887990496 20317545 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_6 Classification statistics (packets/bytes) (rate - kbps) Matched : 3714524873/885888079352 20317545 Transmitted : 3714524873/885888079352 20317545 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_7 Classification statistics (packets/bytes) (rate - kbps) Matched : 3714525265/885888173128 20317546 Transmitted : 3714525265/885888173128 20317546 Total Dropped : 0/0 0 Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 3714525658/885888266160 20317545 Transmitted : 3714525658/885888266160 20317545 Total Dropped : 0/0 0 Policy Bag Stats time: 1722242151064 [Local Time: 07/29/24 08:35:51.064] This example shows: large numbers of matched and transmitted packets per class indicating active classification and forwarding. significant drops in some classes (for example, MAIN_OUT_CMAP_1 to MAIN_OUT_CMAP_5 ), indicating traffic shaping or congestion control is active and working. zero drops in marking policy classes (MAIN_OUT_MARK_CMAP_1 to MAIN_OUT_MARK_CMAP_7 ), confirming marking is applied without loss.

Flat QoS enforces simple per-class bandwidth allocation and marking on PWHE interfaces without hierarchical nesting.

Configure Hierarchical QoS on Pseudowire Headend

Configure hierarchical parent and child policies on a Pseudowire Headend (PWHE) interface to achieve granular control over traffic scheduling and shaping.

In a hierarchical QoS (H-QoS) setup, the parent policy defines the overall shaping rate for the interface, while the child policy determines how that bandwidth is distributed among individual traffic classes. This configuration enables precise control of traffic priorities and ensures that critical services continue to receive resources even when congestion occurs.

Before you begin

Before configuring H-QoS:

Determine which traffic types in your network are critical and need prioritization with finer control.
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.
See Pseudowire Headend aggregate shaper for details about aggregate shaper policies.

Follow these steps to configure H-QoS on a PWHE interface:

Procedure

Step 1	Apply the parent output policy to the PW-Ether interface. Example: `Router(config)#interface PW-Ether1 Router(config-if)#service-policy output port_shaper_combination_hqos_bwrr Router(config-if)#commit` This example attaches the parent QoS policy map parent_shape_hqos_bwrr to the egress (output) of the PW-Ether1 interface. This ensures that all outbound traffic on this interface is controlled by the shaping and bandwidth rules defined in the referenced policy map.
Step 2	Create the parent QoS policy map with shaping rules. Example: `Router(config)#policy-map type qos parent_shape_hqos_bwrr Router(config-pmap)#class type qos class-default Router(config-pmap-c)#shape average percent 70 Router(config-pmap-c)#end-policy-map` This example creates a parent QoS policy named parent_shape_hqos_bwrr . Within this policy, the class-default traffic class is shaped to use up to 70 percent of the interface's bandwidth.
Step 3	Reference a child policy map within the parent policy map. Example: `Router(config)#policy-map type qos parent_shape_hqos_bwrr Router(config-pmap)#class type qos class-default Router(config-pmap-c)#service-policy type qos shape_hqos_bwrr` This step links the child policy map shape_hqos_bwrr to the class-default class of the parent policy. This allows for further breakdown and detailed QoS handling of the shaped traffic, enabling more granular bandwidth management and queuing within the already shaped group.
Step 4	Define the child policy map. Example: Router(config)#policy-map type qos shape_hqos_bwrr Router(config-pmap)#class type qos MAIN_OUT_CMAP_1 Router(config-pmap-c)#bandwidth remaining ratio 20 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_2 Router(config-pmap-c)#bandwidth remaining ratio 30 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_3 Router(config-pmap-c)#bandwidth remaining ratio 40 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_4 Router(config-pmap-c)#bandwidth remaining ratio 50 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_5 Router(config-pmap-c)#bandwidth remaining ratio 60 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_6 Router(config-pmap-c)#shape average percent 10 Router(config-pmap-c)#priority level 2 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_7 Router(config-pmap-c)#shape average percent 20 Router(config-pmap-c)#priority level 1 Router(config-pmap-c)#exit Router(config-pmap)#class type qos class-default Router(config-pmap-c)#bandwidth remaining ratio 10 Router(config-pmap-c)#end-policy-map Router(config)#commit This example defines the child policy map shape_hqos_bwrr . Each MAIN_OUT_CMAP_X class is assigned a specific bandwidth share (bandwidth remaining ratio) or shaping parameter (shape average percent and priority level). This allows for further breakdown and detailed QoS handling of the shaped traffic, enabling more granular bandwidth management and queuing within the already shaped group. Specifically: Classes 1 to 5 are allocated bandwidth in increasing ratios. Classes 6 and 7 are shaped and prioritized, ensuring critical traffic gets faster service. The class-default ensures any unclassified traffic gets a minimal share. Traffic is separated into classes, each with explicit bandwidth allocation or priority, providing precise traffic management.
Step 5	Verify the H-QoS operation. Example: Router#show policy-map interface PW-Ether1 output PW-Ether1 output: MAIN_OUT_PMAP5_Q_TC_MARK Class MAIN_OUT_MARK_CMAP_1 Classification statistics (packets/bytes) (rate - kbps) Matched : 567459747/135334786816 12797449 Transmitted : 567459747/135334786816 12797449 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_2 Classification statistics (packets/bytes) (rate - kbps) Matched : 567460159/135334884896 12797447 Transmitted : 567460159/135334884896 12797447 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_3 Classification statistics (packets/bytes) (rate - kbps) Matched : 567460559/135334979696 12797443 Transmitted : 567460559/135334979696 12797443 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_4 Classification statistics (packets/bytes) (rate - kbps) Matched : 567460923/135335066400 12797441 Transmitted : 567460923/135335066400 12797441 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_5 Classification statistics (packets/bytes) (rate - kbps) Matched : 567461313/135335159920 12797441 Transmitted : 567461313/135335159920 12797441 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_6 Classification statistics (packets/bytes) (rate - kbps) Matched : 567461672/135335245112 12797434 Transmitted : 567461672/135335245112 12797434 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_7 Classification statistics (packets/bytes) (rate - kbps) Matched : 567462071/135335339784 12797433 Transmitted : 567462071/135335339784 12797433 Total Dropped : 0/0 0 Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 567462460/135335433176 12797433 Transmitted : 567462460/135335433176 12797433 Total Dropped : 0/0 0 Policy Bag Stats time: 1722242661147 PW-Ether1 output: parent_shape_hqos_bwrr Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 4534918248/1081543126494 103380648 Transmitted : 1754661178/418305616732 40446522 Total Dropped : 2780257070/663237509762 62934126 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_1 Classification statistics (packets/bytes) (rate - kbps) Matched : 566863835/135192664022 13582722 Transmitted : 116771460/27808308708 3393098 Total Dropped : 450092375/107384355314 10189624 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 450092375/107384355314 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_2 Classification statistics (packets/bytes) (rate - kbps) Matched : 566864236/135192760288 12828274 Transmitted : 175109685/41713170712 3958057 Total Dropped : 391754551/93479589576 8870217 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 391754551/93479589576 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_3 Classification statistics (packets/bytes) (rate - kbps) Matched : 566864574/135192841920 12828272 Transmitted : 233516796/55616629856 5277334 Total Dropped : 333347778/79576212064 7550938 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 333347778/79576212064 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_4 Classification statistics (packets/bytes) (rate - kbps) Matched : 566864964/135192934568 12828276 Transmitted : 280180776/66740681128 6332876 Total Dropped : 286684188/68452253440 6495400 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 286684188/68452253440 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_5 Classification statistics (packets/bytes) (rate - kbps) Matched : 566865352/135193027832 12828278 Transmitted : 350225162/83425674520 7916096 Total Dropped : 216640190/51767353312 4912182 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 216640190/51767353312 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_6 Classification statistics (packets/bytes) (rate - kbps) Matched : 566865746/135193120992 12828275 Transmitted : 180140646/43035061400 4083496 Total Dropped : 386725100/92158059592 8744779 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 386725100/92158059592 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_7 Classification statistics (packets/bytes) (rate - kbps) Matched : 566866035/135193189376 12828277 Transmitted : 360261283/86063059512 8166361 Total Dropped : 206604752/49130129864 4661916 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 206604752/49130129864 Policy shape_hqos_bwrr Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 566863506/135192587496 12828274 Transmitted : 58455370/13903030896 1319204 Total Dropped : 508408136/121289556600 11509070 Queueing statistics Queue ID : None (Pseudo-Wire) Taildropped(packets/bytes) : 508408136/121289556600 Policy Bag Stats time: 1722242661011 Use this example to confirm that: all expected classes appear with growing counters. critical classes have minimal or zero drops. traffic rates match your policy allocations.

After configuration, the H-QoS policy maintains fairness across all classes by providing fine-grained control of pseudowire queues. During congestion, high-priority traffic retains required bandwidth and performance, while overall bandwidth is shaped efficiently.

Configure QoS with aggregate shaper on Pseudowire Headend

Configure an aggregate shaper on the Pseudowire Ethernet (PW-Ether) main interface to control the total egress bandwidth for all pseudowire subinterfaces. This setup ensures that overall traffic leaving the interface stays within a defined limit, while each subinterface continues to manage its own class-based marking and queuing.

An aggregate shaper defines the maximum rate for all PWHE subinterfaces combined. It operates on the class-default of the policy map and enforces a collective bandwidth cap across all associated traffic.

You can configure an aggregate shaper to coexist with subinterface policies if these configurations meet the rules for shaping and bandwidth-remaining actions. This approach allows you to balance total throughput with per-subinterface service differentiation.

Before you begin

Before you configure the aggregate shaper:

Determine which types of traffic are critical and need prioritization with finer control.
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.
See PWHE Aggregate Shaper for details about aggregate shaper policies.

Follow these steps to configure an aggregate shaper on a PWHE interface:

Procedure

Step 1	Define the aggregate shaper parent policy map. Example: `Router(config)#policy-map parent_shape_hqos_bwrr Router(config-pmap)#class class-default Router(config-pmap-c)#shape average 100000000 Router(config-pmap-c)#service-policy type qos shape_hqos_bwrr Router(config-pmap-c)#exit Router(config-pmap)#end-policy-map Router(config)#commit` The policy map (parent_shape_hqos_bwrr ) defines how all output traffic on the PW-Ether1 main interface is managed: The class-default command matches all traffic on the interface that isn’t explicitly matched by another class (and since only class-default is present, this means all egress traffic). The shape average command enforces an aggregate shaping limit of 100 Mbps. The total egress bandwidth for all traffic combined cannot exceed this value. The service-policy type qos shape_hqos_bwrr command attaches a child policy. After applying the aggregate shaping limit, the traffic is further divided and managed into classes as defined in the child policy.
Step 2	Define the child policy map for class-based shaping and bandwidth allocation. Example: Router(config)#policy-map type qos shape_hqos_bwrr Router(config-pmap)#class type qos MAIN_OUT_CMAP_1 Router(config-pmap-c)#bandwidth remaining ratio 20 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_2 Router(config-pmap-c)#bandwidth remaining ratio 30 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_3 Router(config-pmap-c)#bandwidth remaining ratio 40 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_4 Router(config-pmap-c)#bandwidth remaining ratio 50 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_5 Router(config-pmap-c)#bandwidth remaining ratio 60 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_6 Router(config-pmap-c)#shape average percent 10 Router(config-pmap-c)#priority level 2 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_CMAP_7 Router(config-pmap-c)#shape average percent 20 Router(config-pmap-c)#priority level 1 Router(config-pmap-c)#exit Router(config-pmap)#class type qos class-default Router(config-pmap-c)#bandwidth remaining ratio 10 Router(config-pmap-c)#end-policy-map Router(config)#commit The child policy (shape_hqos_bwrr ) breaks down the aggregate bandwidth among several classes: the bandwidth remaining ratio assigns relative bandwidth shares to each class. the shape average percent and the priority level give special handling to specific classes.
Step 3	Apply the aggregate shaper parent policy to the main PWHE interface. Example: `Router(config)#interface PW-Ether1 Router(config-if)#service-policy output parent_shape_hqos_bwrr Router(config-if)#commit` This command applies the aggregate shaper and all class-based bandwidth and priority controls to all egress traffic on the main interface (PW-Ether1 ).
Step 4	Apply a DSCP marking policy to the PWHE subinterface. Example: `Router(config)#interface PW-Ether1.1 Router(config-if)#service-policy output MAIN_OUT_DSCP_MARK Router(config-if)#commit` This example ensures traffic leaving the subinterface PW-Ether1.1 is marked with the correct DSCP values for downstream QoS treatment.
Step 5	Define the DSCP marking policy map for the subinterface. Example: Router(config)#policy-map type qos MAIN_OUT_DSCP_MARK Router(config-pmap)#class type qos MAIN_OUT_MARK_DSCP_CMAP_1 Router(config-pmap-c)#set dscp af11 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_DSCP_CMAP_2 Router(config-pmap-c)#set dscp af12 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_DSCP_CMAP_3 Router(config-pmap-c)#set dscp af13 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_DSCP_CMAP_4 Router(config-pmap-c)#set dscp af41 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_DSCP_CMAP_5 Router(config-pmap-c)#set dscp af42 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_DSCP_CMAP_6 Router(config-pmap-c)#set dscp af43 Router(config-pmap-c)#exit Router(config-pmap)#class type qos MAIN_OUT_MARK_DSCP_CMAP_7 Router(config-pmap-c)#set dscp ef Router(config-pmap-c)#end-policy-map Router(config)#commit The policy map marks each class of traffic with a specific DSCP value as it leaves the subinterface: Assured Forwarding (af ) values (for example, af11 and af41 ) indicate differentiated levels of forwarding assurance and drop precedence for business-critical or prioritized services. Expedited Forwarding (ef ) is typically used for low-latency, high-priority traffic such as voice or real-time applications.
Step 6	Confirm shaping and class statistics on main interface. Example: Router#show qos-ea default-queue PW-Ether 1 member interface HundredGigE0/7/0/2 output Interface Name = PE1 Interface Handle = 1c000180 Location = 0/7/CPU0 Asic Instance = 0 VOQ Base = 53312 Port Speed(kbps) = 100000000 Local Port = etm_local VOQ Mode = 8 ReceivedPkts ReceivedBytes DroppedPkts DroppedBytes ------------------------------------------------------------------- TC_0 = 150295879 150596322940 762151909 763676346056 TC_1 = 0 0 0 0 TC_2 = 0 0 0 0 TC_3 = 0 0 0 0 TC_4 = 0 0 0 0 TC_5 = 0 0 0 0 TC_6 = 0 0 0 0 TC_7 = 0 0 0 0 This example shows queue statistics for each traffic class (TC_0 to TC_7 ) on the main interface PW-Ether1 . TC_0 (class-default) reflects packet shaping and drops.
Step 7	View detailed QoS statistics and configuration information for output traffic from the main interface. Example: Router#show qos interface PW-Ether1 output member HundredGigE0/7/0/2 NOTE:- Configured values are displayed within parentheses Node 0/7/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 0 Total number of classes: 9 Interface Bandwidth: 100000000 kbps Policy Name: parent_shape_hqos_bwrr Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = class-default Level2 Class = MAIN_OUT_CMAP_1 Level2 Class = MAIN_OUT_CMAP_2 Level2 Class = MAIN_OUT_CMAP_3 Level2 Class = MAIN_OUT_CMAP_4 Level2 Class = MAIN_OUT_CMAP_5 Level2 Class = MAIN_OUT_CMAP_6 Level2 Class = MAIN_OUT_CMAP_7 Level2 Class = class-default Node 0/7/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 0 Total number of classes: 8 Interface Bandwidth: 100000000 kbps Policy Name: MAIN_OUT_PMAP5_Q_TC_MARK Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = MAIN_OUT_MARK_CMAP_1 New traffic class = 1 Level1 Class = MAIN_OUT_MARK_CMAP_2 New traffic class = 2 Level1 Class = MAIN_OUT_MARK_CMAP_3 New traffic class = 3 Level1 Class = MAIN_OUT_MARK_CMAP_4 New traffic class = 4 Level1 Class = MAIN_OUT_MARK_CMAP_5 New traffic class = 5 Level1 Class = MAIN_OUT_MARK_CMAP_6 New traffic class = 6 Level1 Class = MAIN_OUT_MARK_CMAP_7 New traffic class = 7 Level1 Class = class-default Node 0/7/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 3 Total number of classes: 9 Interface Bandwidth: 100000000 kbps Policy Name: parent_shape_hqos_bwrr Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = class-default Level2 Class = MAIN_OUT_CMAP_1 Level2 Class = MAIN_OUT_CMAP_2 Level2 Class = MAIN_OUT_CMAP_3 Level2 Class = MAIN_OUT_CMAP_4 Level2 Class = MAIN_OUT_CMAP_5 Level2 Class = MAIN_OUT_CMAP_6 Level2 Class = MAIN_OUT_CMAP_7 Level2 Class = class-default Node 0/7/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 3 Total number of classes: 8 Interface Bandwidth: 100000000 kbps Policy Name: MAIN_OUT_PMAP5_Q_TC_MARK Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = MAIN_OUT_MARK_CMAP_1 New traffic class = 1 Level1 Class = MAIN_OUT_MARK_CMAP_2 New traffic class = 2 Level1 Class = MAIN_OUT_MARK_CMAP_3 New traffic class = 3 Level1 Class = MAIN_OUT_MARK_CMAP_4 New traffic class = 4 Level1 Class = MAIN_OUT_MARK_CMAP_5 New traffic class = 5 Level1 Class = MAIN_OUT_MARK_CMAP_6 New traffic class = 6 Level1 Class = MAIN_OUT_MARK_CMAP_7 New traffic class = 7 Level1 Class = class-default Interface HundredGigE0/7/0/2 Ifh 0x1c000180 (PinDown Member) -- output policy NPU Id: 0 Total number of classes: 9 Interface Bandwidth: 100000000 kbps Policy Name: parent_shape_hqos_bwrr VOQ Base: 53312 Accounting Type: Layer1 (Include Layer 1 encapsulation and above) VOQ Mode: 8 Shared Counter Mode: 1 ------------------------------------------------------------------------------ Level1 Class = class-default Queue Max. BW. = 70000000 kbps (70 %) Inverse Weight / Weight = 255 / (BWR not configured) Level2 Class = MAIN_OUT_CMAP_1 Egressq Queue ID = 53313 (LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 12 / (20) Guaranteed service rate = 4711538 kbps TailDrop Threshold = 614400 bytes / 1 ms (614400 bytes) WRED not configured for this class Level2 Class = MAIN_OUT_CMAP_2 Egressq Queue ID = 53314 (LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 8 / (30) Guaranteed service rate = 7067307 kbps TailDrop Threshold = 614400 bytes / 702 us (614400 bytes) WRED not configured for this class Level2 Class = MAIN_OUT_CMAP_3 Egressq Queue ID = 53315 (LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 6 / (40) Guaranteed service rate = 9423076 kbps TailDrop Threshold = 614400 bytes / 527 us (614400 bytes) WRED not configured for this class Level2 Class = MAIN_OUT_CMAP_4 Egressq Queue ID = 53316 (LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 5 / (50) Guaranteed service rate = 11307692 kbps TailDrop Threshold = 614400 bytes / 421 us (614400 bytes) WRED not configured for this class Level2 Class = MAIN_OUT_CMAP_5 Egressq Queue ID = 53317 (LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 4 / (60) Guaranteed service rate = 14134615 kbps TailDrop Threshold = 614400 bytes / 351 us (614400 bytes) WRED not configured for this class Level2 Class (HP2) = MAIN_OUT_CMAP_6 Egressq Queue ID = 53318 (HP2 queue) Queue Max. BW. = 7000000 kbps (10 %) Guaranteed service rate = 7000000 kbps TailDrop Threshold = 614400 bytes / 702 us (614400 bytes) WRED not configured for this class Level2 Class (HP1) = MAIN_OUT_CMAP_7 Egressq Queue ID = 53319 (HP1 queue) Queue Max. BW. = 14000000 kbps (20 %) Guaranteed service rate = 14000000 kbps TailDrop Threshold = 614400 bytes / 351 us (614400 bytes) WRED not configured for this class Level2 Class = class-default Egressq Queue ID = 53312 (Default LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 24 / (10) Guaranteed service rate = 2355769 kbps TailDrop Threshold = 614400 bytes / 2 ms (614400 bytes) WRED not configured for this class Interface HundredGigE0/7/0/2 Ifh 0x1c000180 (PinDown Member) -- output policy NPU Id: 0 Total number of classes: 8 Interface Bandwidth: 100000000 kbps Policy Name: MAIN_OUT_PMAP5_Q_TC_MARK VOQ Base: 0 Accounting Type: Layer1 (Include Layer 1 encapsulation and above) VOQ Mode: 8 Shared Counter Mode: 1 ------------------------------------------------------------------------------ Level1 Class = MAIN_OUT_MARK_CMAP_1 New traffic class = 1 Level1 Class = MAIN_OUT_MARK_CMAP_2 New traffic class = 2 Level1 Class = MAIN_OUT_MARK_CMAP_3 New traffic class = 3 Level1 Class = MAIN_OUT_MARK_CMAP_4 New traffic class = 4 Level1 Class = MAIN_OUT_MARK_CMAP_5 New traffic class = 5 Level1 Class = MAIN_OUT_MARK_CMAP_6 New traffic class = 6 Level1 Class = MAIN_OUT_MARK_CMAP_7 New traffic class = 7 Level1 Class = class-default Node 0/0/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 0 Total number of classes: 9 Interface Bandwidth: 25000000 kbps Policy Name: parent_shape_hqos_bwrr Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = class-default Level2 Class = MAIN_OUT_CMAP_1 Level2 Class = MAIN_OUT_CMAP_2 Level2 Class = MAIN_OUT_CMAP_3 Level2 Class = MAIN_OUT_CMAP_4 Level2 Class = MAIN_OUT_CMAP_5 Level2 Class = MAIN_OUT_CMAP_6 Level2 Class = MAIN_OUT_CMAP_7 Level2 Class = class-default Node 0/0/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 0 Total number of classes: 8 Interface Bandwidth: 25000000 kbps Policy Name: MAIN_OUT_PMAP5_Q_TC_MARK Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = MAIN_OUT_MARK_CMAP_1 New traffic class = 1 Level1 Class = MAIN_OUT_MARK_CMAP_2 New traffic class = 2 Level1 Class = MAIN_OUT_MARK_CMAP_3 New traffic class = 3 Level1 Class = MAIN_OUT_MARK_CMAP_4 New traffic class = 4 Level1 Class = MAIN_OUT_MARK_CMAP_5 New traffic class = 5 Level1 Class = MAIN_OUT_MARK_CMAP_6 New traffic class = 6 Level1 Class = MAIN_OUT_MARK_CMAP_7 New traffic class = 7 Level1 Class = class-default This example displays applied policy name (parent_shape_hqos_bwrr ), class structure, bandwidth, queue, and drop thresholds. Ensure that the class and queue structure match the configuration.
Step 8	View detailed QoS statistics and configuration information for output traffic from the main interface. Example: Router#show qos interface PW-Ether1 output member HundredGigE0/7/0/2 NOTE:- Configured values are displayed within parentheses Node 0/7/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 0 Total number of classes: 9 Interface Bandwidth: 100000000 kbps Policy Name: parent_shape_hqos_bwrr Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = class-default Level2 Class = MAIN_OUT_CMAP_1 Level2 Class = MAIN_OUT_CMAP_2 Level2 Class = MAIN_OUT_CMAP_3 Level2 Class = MAIN_OUT_CMAP_4 Level2 Class = MAIN_OUT_CMAP_5 Level2 Class = MAIN_OUT_CMAP_6 Level2 Class = MAIN_OUT_CMAP_7 Level2 Class = class-default Node 0/7/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 0 Total number of classes: 8 Interface Bandwidth: 100000000 kbps Policy Name: MAIN_OUT_PMAP5_Q_TC_MARK Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = MAIN_OUT_MARK_CMAP_1 New traffic class = 1 Level1 Class = MAIN_OUT_MARK_CMAP_2 New traffic class = 2 Level1 Class = MAIN_OUT_MARK_CMAP_3 New traffic class = 3 Level1 Class = MAIN_OUT_MARK_CMAP_4 New traffic class = 4 Level1 Class = MAIN_OUT_MARK_CMAP_5 New traffic class = 5 Level1 Class = MAIN_OUT_MARK_CMAP_6 New traffic class = 6 Level1 Class = MAIN_OUT_MARK_CMAP_7 New traffic class = 7 Level1 Class = class-default Node 0/7/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 3 Total number of classes: 9 Interface Bandwidth: 100000000 kbps Policy Name: parent_shape_hqos_bwrr Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = class-default Level2 Class = MAIN_OUT_CMAP_1 Level2 Class = MAIN_OUT_CMAP_2 Level2 Class = MAIN_OUT_CMAP_3 Level2 Class = MAIN_OUT_CMAP_4 Level2 Class = MAIN_OUT_CMAP_5 Level2 Class = MAIN_OUT_CMAP_6 Level2 Class = MAIN_OUT_CMAP_7 Level2 Class = class-default Node 0/7/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 3 Total number of classes: 8 Interface Bandwidth: 100000000 kbps Policy Name: MAIN_OUT_PMAP5_Q_TC_MARK Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = MAIN_OUT_MARK_CMAP_1 New traffic class = 1 Level1 Class = MAIN_OUT_MARK_CMAP_2 New traffic class = 2 Level1 Class = MAIN_OUT_MARK_CMAP_3 New traffic class = 3 Level1 Class = MAIN_OUT_MARK_CMAP_4 New traffic class = 4 Level1 Class = MAIN_OUT_MARK_CMAP_5 New traffic class = 5 Level1 Class = MAIN_OUT_MARK_CMAP_6 New traffic class = 6 Level1 Class = MAIN_OUT_MARK_CMAP_7 New traffic class = 7 Level1 Class = class-default Interface HundredGigE0/7/0/2 Ifh 0x1c000180 (PinDown Member) -- output policy NPU Id: 0 Total number of classes: 9 Interface Bandwidth: 100000000 kbps Policy Name: parent_shape_hqos_bwrr VOQ Base: 53312 Accounting Type: Layer1 (Include Layer 1 encapsulation and above) VOQ Mode: 8 Shared Counter Mode: 1 ------------------------------------------------------------------------------ Level1 Class = class-default Queue Max. BW. = 70000000 kbps (70 %) Inverse Weight / Weight = 255 / (BWR not configured) Level2 Class = MAIN_OUT_CMAP_1 Egressq Queue ID = 53313 (LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 12 / (20) Guaranteed service rate = 4711538 kbps TailDrop Threshold = 614400 bytes / 1 ms (614400 bytes) WRED not configured for this class Level2 Class = MAIN_OUT_CMAP_2 Egressq Queue ID = 53314 (LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 8 / (30) Guaranteed service rate = 7067307 kbps TailDrop Threshold = 614400 bytes / 702 us (614400 bytes) WRED not configured for this class Level2 Class = MAIN_OUT_CMAP_3 Egressq Queue ID = 53315 (LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 6 / (40) Guaranteed service rate = 9423076 kbps TailDrop Threshold = 614400 bytes / 527 us (614400 bytes) WRED not configured for this class Level2 Class = MAIN_OUT_CMAP_4 Egressq Queue ID = 53316 (LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 5 / (50) Guaranteed service rate = 11307692 kbps TailDrop Threshold = 614400 bytes / 421 us (614400 bytes) WRED not configured for this class Level2 Class = MAIN_OUT_CMAP_5 Egressq Queue ID = 53317 (LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 4 / (60) Guaranteed service rate = 14134615 kbps TailDrop Threshold = 614400 bytes / 351 us (614400 bytes) WRED not configured for this class Level2 Class (HP2) = MAIN_OUT_CMAP_6 Egressq Queue ID = 53318 (HP2 queue) Queue Max. BW. = 7000000 kbps (10 %) Guaranteed service rate = 7000000 kbps TailDrop Threshold = 614400 bytes / 702 us (614400 bytes) WRED not configured for this class Level2 Class (HP1) = MAIN_OUT_CMAP_7 Egressq Queue ID = 53319 (HP1 queue) Queue Max. BW. = 14000000 kbps (20 %) Guaranteed service rate = 14000000 kbps TailDrop Threshold = 614400 bytes / 351 us (614400 bytes) WRED not configured for this class Level2 Class = class-default Egressq Queue ID = 53312 (Default LP queue) Queue Max. BW. = no max (default) Inverse Weight / Weight = 24 / (10) Guaranteed service rate = 2355769 kbps TailDrop Threshold = 614400 bytes / 2 ms (614400 bytes) WRED not configured for this class Interface HundredGigE0/7/0/2 Ifh 0x1c000180 (PinDown Member) -- output policy NPU Id: 0 Total number of classes: 8 Interface Bandwidth: 100000000 kbps Policy Name: MAIN_OUT_PMAP5_Q_TC_MARK VOQ Base: 0 Accounting Type: Layer1 (Include Layer 1 encapsulation and above) VOQ Mode: 8 Shared Counter Mode: 1 ------------------------------------------------------------------------------ Level1 Class = MAIN_OUT_MARK_CMAP_1 New traffic class = 1 Level1 Class = MAIN_OUT_MARK_CMAP_2 New traffic class = 2 Level1 Class = MAIN_OUT_MARK_CMAP_3 New traffic class = 3 Level1 Class = MAIN_OUT_MARK_CMAP_4 New traffic class = 4 Level1 Class = MAIN_OUT_MARK_CMAP_5 New traffic class = 5 Level1 Class = MAIN_OUT_MARK_CMAP_6 New traffic class = 6 Level1 Class = MAIN_OUT_MARK_CMAP_7 New traffic class = 7 Level1 Class = class-default Node 0/0/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 0 Total number of classes: 9 Interface Bandwidth: 25000000 kbps Policy Name: parent_shape_hqos_bwrr Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = class-default Level2 Class = MAIN_OUT_CMAP_1 Level2 Class = MAIN_OUT_CMAP_2 Level2 Class = MAIN_OUT_CMAP_3 Level2 Class = MAIN_OUT_CMAP_4 Level2 Class = MAIN_OUT_CMAP_5 Level2 Class = MAIN_OUT_CMAP_6 Level2 Class = MAIN_OUT_CMAP_7 Level2 Class = class-default Node 0/0/CPU0, Interface PW-Ether1 Ifh 0x7800104c (PW-Ether) -- output policy NPU Id: 0 Total number of classes: 8 Interface Bandwidth: 25000000 kbps Policy Name: MAIN_OUT_PMAP5_Q_TC_MARK Accounting Type: Layer1 (Include Layer 1 encapsulation and above) ------------------------------------------------------------------------------ Level1 Class = MAIN_OUT_MARK_CMAP_1 New traffic class = 1 Level1 Class = MAIN_OUT_MARK_CMAP_2 New traffic class = 2 Level1 Class = MAIN_OUT_MARK_CMAP_3 New traffic class = 3 Level1 Class = MAIN_OUT_MARK_CMAP_4 New traffic class = 4 Level1 Class = MAIN_OUT_MARK_CMAP_5 New traffic class = 5 Level1 Class = MAIN_OUT_MARK_CMAP_6 New traffic class = 6 Level1 Class = MAIN_OUT_MARK_CMAP_7 New traffic class = 7 Level1 Class = class-default This example displays applied policy name (parent_shape_hqos_bwrr ), class structure, bandwidth, queue, and drop thresholds. Look for class and queue structure matching configuration.
Step 9	View per-class statistics and queuing details for a specific member interface on the main interface. Example: Router#show policy-map interface PW-Ether1 output member HundredGigE0/7/0/2 Interface:PW-Ether1 Member:HundredGigE0/7/0/2 output: parent_shape_hqos_bwrr Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 1048830183/250133071040 0 Transmitted : 405970112/96745121320 0 Total Dropped : 642860071/153387949720 0 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_1 Classification statistics (packets/bytes) (rate - kbps) Matched : 131102864/31266417264 0 Transmitted : 27020068/6431611720 0 Total Dropped : 104082796/24834805544 0 Queueing statistics Queue ID : 53313 Taildropped(packets/bytes) : 104082796/24834805544 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_2 Classification statistics (packets/bytes) (rate - kbps) Matched : 131103199/31266497640 0 Transmitted : 40521792/9647311792 0 Total Dropped : 90581407/21619185848 0 Queueing statistics Queue ID : 53314 Taildropped(packets/bytes) : 90581407/21619185848 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_3 Classification statistics (packets/bytes) (rate - kbps) Matched : 131103636/31266600664 0 Transmitted : 54004138/12863485816 0 Total Dropped : 77099498/18403114848 0 Queueing statistics Queue ID : 53315 Taildropped(packets/bytes) : 77099498/18403114848 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_4 Classification statistics (packets/bytes) (rate - kbps) Matched : 131103920/31266669280 0 Transmitted : 64802769/15436026336 0 Total Dropped : 66301151/15830642944 0 Queueing statistics Queue ID : 53316 Taildropped(packets/bytes) : 66301151/15830642944 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_5 Classification statistics (packets/bytes) (rate - kbps) Matched : 131104311/31266762056 0 Transmitted : 80969302/19295430376 0 Total Dropped : 50135009/11971331680 0 Queueing statistics Queue ID : 53317 Taildropped(packets/bytes) : 50135009/11971331680 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_6 Classification statistics (packets/bytes) (rate - kbps) Matched : 131104735/31266863416 0 Transmitted : 41698712/9952700928 0 Total Dropped : 89406023/21314162488 0 Queueing statistics Queue ID : 53318 Taildropped(packets/bytes) : 89406023/21314162488 Policy shape_hqos_bwrr Class MAIN_OUT_CMAP_7 Classification statistics (packets/bytes) (rate - kbps) Matched : 131105067/31266942536 0 Transmitted : 83425746/19902839360 0 Total Dropped : 47679321/11364103176 0 Queueing statistics Queue ID : 53319 Taildropped(packets/bytes) : 47679321/11364103176 Policy shape_hqos_bwrr Class class-default Classification statistics (packets/bytes) (rate - kbps) Matched : 131102451/31266318184 0 Transmitted : 13527585/3215714992 0 Total Dropped : 117574866/28050603192 0 Queueing statistics Queue ID : 53312 Taildropped(packets/bytes) : 117574866/28050603192 Policy Bag Stats time: 1722238640916 [Local Time: 07/29/24 07:37:20.916] Interface:PW-Ether1 Member:HundredGigE0/7/0/2 output: MAIN_OUT_PMAP5_Q_TC_MARK Class MAIN_OUT_MARK_CMAP_1 Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_2 Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_3 Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_4 Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_5 Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_6 Classification statistics (packets/bytes) (rate - kbps) Matched : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0 Class MAIN_OUT_MARK_CMAP_7 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 : 0/0 0 Transmitted : 0/0 0 Total Dropped : 0/0 0 Policy Bag Stats time: 1722238674599 [Local Time: 07/29/24 07:37:54.599] This example shows matched, transmitted, and dropped counts per class, queueing info, and policy name on the member interface HundredGigE0/7/0/2 .

This end-to-end configuration directly implements your design. It enforces a bandwidth cap of 100 Mbps across all subinterfaces on class-default. You can also apply distinct QoS policies, such as marking, at the subinterface level for service differentiation.

Modular QoS Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

Bias-Free Language

Results

Chapter: QoS Deployment across Network Scenarios

QoS Deployment across Network Scenarios

Information flow

QoS Policy Propagation via BGP

QPPB integration of BGP and QoS groups

QPPB for Prioritizing Business-Critical Traffic

Benefits of QoS Policy Propagation via BGP

How QoS Policy Propagation via BGP works

Summary

Workflow

Result

Best practices for configuring QoS Policy Propagation via BGP

Configuration best practices

Interface and hardware recommendations

Interactions with other features

Compatibility with SPAN and remarking features

Configure QoS Policy Propagation via BGP

Before you begin

Procedure

Example:

Example:

Example:

Example:

QoS on Pseudowire Headend

QoS on PWHE and the importance of headend

QoS on PWHE in practice

How QoS on Pseudowire Headend works

Summary

Workflow

Result

Functional details and behaviors of QoS on PWHE

General features and support information for QoS on PWHE

Traffic mapping for Pseudowire Headend interfaces to pin-down members

Port shaping effect on pin-down members

Bandwidth distribution for QoS on Pseudowire Headend

QoS accounting for Pseudowire Headend traffic

Marking for QoS on Pseudowire Headend

Policing and queuing for QoS on Pseudowire Headend

Pseudowire Headend aggregate shaper

Pseudowire Ethernet subinterface policy

Scale information for QoS on Pseudowire Headend interfaces

Pseudowire Headend without QoS policy

Limitations for QoS on Pseudowire Headend

Configuration options for QoS on Pseudowire Headend

Configure Flat QoS on Pseudowire Headend

Before you begin

Procedure

Example:

Example:

Example:

Example:

Example:

Example:

Configure Hierarchical QoS on Pseudowire Headend

Before you begin

Procedure

Example:

Example:

Example:

Example:

Example:

Configure QoS with aggregate shaper on Pseudowire Headend

Before you begin

Procedure

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Example:

Was this Document Helpful?

Contact Cisco