Welcome to the final lesson in our module on implementing Quality of Service. In the past few sessions, we've systematically built our QoS policy using the Modular QoS CLI (MQC). You've learned how to classify traffic with class-map, and then define actions like marking or queuing within a policy-map. Now, we'll focus on the crucial final step: activating this policy and confirming it works as intended.
This lesson directly addresses the learning outcome of applying a QoS service policy to an interface and verifying its operation. We will bring together all the components of the MQC framework, applying the policies you've designed and using powerful show commands to see the results in real-time. This is where the theoretical concepts of QoS become tangible network behavior.
Activating the Policy: The service-policy Command
A policy-map, no matter how well-crafted, is inert until it's attached to a network interface. This is done using the service-policy command from the interface configuration mode. This command is the switch that turns your QoS engine on for a specific flow of traffic.
A critical aspect of this command is specifying the direction of traffic:
input: The policy is applied to traffic entering the interface. This is typically used for classification and marking, where you want to label packets as soon as they enter your network domain.output: The policy is applied to traffic leaving the interface. This is where actions like queuing (LLQ, CBWFQ) and shaping are implemented, as they manage congestion that occurs when packets are being transmitted out of an interface, especially from a fast link to a slower one.
The following resource provides a concise overview of the three MQC steps and introduces the service-policy command syntax.
This article from NetworkAcademy.IO summarizes the MQC framework and details the service-policy command used to activate a policy.
First, quickly review the three MQC steps as a refresher. Then, focus on the section titled The service-policy command. This shows the exact syntax for applying a policy map to an interface for both input and output traffic.
To see this in a more dynamic context, the following video explains the process of applying a policy map and the significance of choosing the correct direction.
How To Configure QoS On A Cisco Router? Modular QoS CLI Explained
This segment from the Network Direction channel demonstrates the application of a service-policy and explains the in vs. out keywords.
Watch the portion from applying the policy. Pay close attention to the explanation of why you would choose one direction over the other. For instance, marking traffic upon ingress (in) and then applying queuing policies upon egress (out) is a very common network design pattern.
Verification: Is It Working?
Applying the policy is only half the battle. As a network engineer, you must verify that the policy is having the intended effect. The primary command for this is show policy-map interface <interface-name>. This command provides a wealth of information, confirming not only that the policy is active but also showing statistics about the traffic being processed.
When you run this command, you can expect to see:
- The name of the service policy applied and its direction.
- A breakdown for each
class-mapwithin the policy. - Packet and byte counters for traffic that has matched each class. This is the most crucial piece of feedback—if these counters aren't increasing for the traffic you expect, your classification is likely incorrect.
- Statistics on the QoS action, such as packets marked, queue depths, or dropped packets.
The following article provides a clear list of verification commands and an example of what to look for in the output.
How to Configure QoS Policies for IPv4 on a Cisco Router
This blog post from OneUptime gives practical examples of verification commands and their output.
First, review the list under the heading Verification Commands. This provides a quick reference for the essential tools. Next, study the sample output. Notice how it breaks down the statistics for the VOIP and WEB classes, showing matched packets, offered rate, and queuing details. This is the kind of output you will analyze to troubleshoot your QoS configurations.
The video you watched earlier also includes a segment on verification that nicely complements this reading.
How To Configure QoS On A Cisco Router? Modular QoS CLI Explained
This part of the Network Direction video demonstrates how to use show policy-map interface and interpret its output.
Please watch from the verification part. The instructor points out the key elements in the command's output, such as the service policy name, direction, and the traffic counters for each class.
A Complete Lab Example
Let's tie everything together by observing a full configuration and verification cycle. The next video demonstrates applying a policy and then generating different types of traffic (ICMP, HTTP, HTTPS) to confirm that each is being correctly classified and marked.
Free CCNA | QoS | Day 47 Lab | CCNA 200-301 Complete Course
This lab demonstration from Jeremy's IT Lab walks through the final application and verification steps, showing the direct impact of the QoS policy on live packets.
First, watch the brief segment where the instructor applies the policy to the router's egress interface. Then, watch the detailed verification process. While he uses Packet Tracer's simulation mode to inspect individual packets, the core principle is universal: generate specific traffic and then check if your policy handled it correctly. Notice how he sends a ping, then HTTP traffic, then HTTPS traffic, and confirms that R1 applies a different DSCP marking to each, just as the policy dictated. This is precisely the kind of testing you would perform on a real network.
Interpreting Output for Different QoS Tools
The show policy-map interface command is versatile; its output adapts to show details for whatever QoS tool you've configured. In the previous lesson, you focused on queuing. Let's look at an example for traffic shaping, another common QoS tool used to smooth out traffic bursts to a specified rate.
This command output shows the verification for a QoS policy that includes traffic shaping. Note the specific fields related to the shaping parameters.
In the output for the IPERF class in the image above, you can see fields specific to shaping:
- Target/Average Rate: The rate the shaper is configured to enforce (64000 bps).
- Byte Limit / Sustain bits / Excess bits: These parameters control how the shaper handles bursts of traffic.
- Shaping Active: This field is particularly insightful. It currently says "no," which means that while the shaper is configured, the offered traffic rate is below the target rate, so there is no need for shaping to occur. If traffic were to exceed 64 kbps, this would switch to "yes," and you would see packets being placed in a buffer and delayed to meet the target rate. This demonstrates how verification commands give you a dynamic view of network conditions.
Conclusion
In this lesson, you've completed the MQC configuration journey by learning how to apply and verify QoS policies. You now understand that the service-policy command is what activates your configuration on an interface and that the direction (input or output) is critical. More importantly, you are now equipped with the primary verification command, show policy-map interface, and can interpret its output to confirm that your policies for marking, queuing, or shaping are functioning correctly.
Key Takeaways:
- A
policy-mapis activated on an interface using theservice-policy {input | output} <policy-map-name>command. - The
outputdirection is used for egress congestion management tools like queuing and shaping. Theinputdirection is often used for ingress marking. - The
show policy-map interface <interface-name>command is the essential tool for verifying a QoS policy. - The key to verification is checking the packet counters for each class to ensure traffic is being classified correctly.
- The output of the verification command adapts to show relevant statistics for the specific QoS tool being used (e.g., queuing, shaping, policing).
This lesson concludes our deep dive into Quality of Service. You have developed a comprehensive skill set, from classifying and marking traffic to implementing advanced queuing and verifying the entire configuration.
In our next module, we will shift our focus from packet-level controls to a higher-level view of network design. We'll begin exploring "Modern Network Architectures," starting with the concepts of server virtualization and virtual switching.