Quality of Service (QoS) is the mechanism that lets you tell your network, "Hey, these packets are more important than those packets," and have it actually listen.
Let’s watch it in action. Imagine a busy office network. You’ve got VoIP phones, video conferencing, file transfers, and regular web browsing all competing for bandwidth. Without QoS, a massive file download could easily choke the network, making your important video call stutter or even drop.
Here’s a simplified configuration on a Cisco router:
policy-map PBR-QOS
class VOICE
priority percent 30
class VIDEO
bandwidth percent 20
class BULK
bandwidth percent 10
class class-default
fair-queue
interface GigabitEthernet0/1
description Uplink to Internet
service-policy input PBR-QOS
In this example:
policy-map PBR-QOS: This defines our QoS policy.class VOICE: This class matches voice traffic.priority percent 30: This is the key. It guarantees that 30% of the link’s bandwidth is reserved for voice traffic, and it gets sent before anything else if the link is congested. This is called "strict priority."class VIDEO: This class matches video conferencing traffic.bandwidth percent 20: This guarantees that video traffic gets at least 20% of the bandwidth. It’s not strict priority, but it’s a firm floor.class BULK: This class matches less critical traffic, like large file transfers.bandwidth percent 10: This ensures bulk traffic gets at least 10% of the bandwidth.class class-default: This is a catch-all for any traffic not matched by the previous classes.fair-queue: This tells the router to try and distribute the remaining bandwidth as fairly as possible among the packets in this class.interface GigabitEthernet0/1: We’re applying this policy to the uplink interface.service-policy input PBR-QOS: This activates the QoS policy for traffic entering this interface.
The problem this solves is congestion. When the total demand for bandwidth exceeds the available capacity, packets start getting dropped. QoS doesn’t create more bandwidth, but it intelligently manages the existing bandwidth to ensure that critical applications get what they need, even when the network is struggling. It uses mechanisms like classification (identifying traffic types), marking (tagging packets), queuing (holding packets in buffers), and scheduling (deciding which packets to send next) to achieve this.
The actual "marking" of packets often happens earlier, using DSCP (Differentiated Services Code Point) values in the IP header. For instance, voice traffic might be marked with a DSCP value of EF (Expedited Forwarding, typically 46), and video with AF41 (Assured Forwarding, typically 34). The QoS policy then reads these markings to apply the appropriate treatment.
What most people don’t realize is that the priority command, while seemingly simple, often uses a Weighted Fair Queuing (WFQ) variant that includes a strict priority queue. This means that if the priority queue is not empty, it will always be serviced before any other queue, regardless of how much bandwidth those other queues are configured to use. This is why it’s so effective for latency-sensitive traffic like voice, but also why overusing it can starve other traffic.
The next logical step after implementing basic QoS is understanding how to shape traffic, which controls the rate at which traffic is sent, rather than just prioritizing it.