In the CCNA 200-301 exam, QoS is a core topic that tests your ability to manage network congestion and prioritize critical traffic. This lab walks you through configuring QoS marking and queuing on Cisco IOS devices, a skill essential for ensuring voice, video, and other real-time applications perform reliably. Mastering this lab will help you pass the exam and build production networks that deliver consistent user experiences.
Jump to a section
Imagine a busy airport terminal with hundreds of passengers trying to board flights. The airline uses a priority boarding system: first-class passengers board first, then business class, then economy. This is exactly how QoS marking and queuing work on a network. In the airport, passengers are 'marked' with a boarding pass that indicates their class (first, business, economy). At the gate, the boarding agent (the switch or router) checks each passenger's marking and directs them to the appropriate queue. First-class passengers go into a fast, dedicated lane (high-priority queue) that moves quickly, while economy passengers wait in a longer, slower lane (best-effort queue). If the gate becomes congested (e.g., a delayed flight causes a crowd), the agent may even decide to hold back some economy passengers to let first-class passengers through first. This is analogous to congestion management: the device uses queues (like the boarding lanes) and a scheduler (the agent) to decide which queue to serve next. In networking, the markings are the IP Precedence or DSCP values in the IP header, and the queues are implemented using hardware or software buffers. The scheduler might use a strict priority queue (like the first-class lane) that always gets served before others, or a weighted fair queue (like giving business class more frequent service than economy). Without proper marking and queuing, all traffic is treated equally, causing voice calls to stutter and video to freeze during congestion—just as if all passengers had to fight for a single boarding lane.
What is QoS Marking and Queuing?
Quality of Service (QoS) is a set of techniques to manage network resources by classifying, marking, and queuing traffic. Marking involves setting bits in the IP header (ToS byte) to indicate the priority of a packet. The two common marking schemes are IP Precedence (3 bits, values 0-7) and DSCP (6 bits, values 0-63). Queuing is the process of storing packets in different queues based on their markings and then servicing those queues according to a scheduling algorithm. On Cisco switches and routers, this is implemented using MQC (Modular QoS CLI).
Why It Exists
Without QoS, all packets are treated equally in a FIFO (First In, First Out) queue. During congestion, all traffic suffers equally—voice packets get dropped just like bulk file transfers. QoS marking allows you to differentiate traffic, and queuing ensures high-priority traffic gets preferential treatment (lower latency, less jitter, lower drop probability). This is critical for real-time applications like VoIP and video conferencing.
How It Works Step by Step
Classification: The switch/router inspects packets (based on ACLs, NBAR, or trust settings) and assigns them to a class. For example, voice traffic from a known UDP port range.
Marking: Within each class, the device sets the DSCP or CoS value. On a switch, you can trust the existing marking (e.g., from an IP phone) or override it.
Policing/Shaping (optional): You can limit the rate of certain traffic classes. Policing drops or remarks packets that exceed a rate; shaping buffers them.
Queuing: The device places packets into output queues based on their marking. On Catalyst switches, this is done using egress queues (e.g., 1p3q8t = 1 strict priority queue, 3 standard queues, 8 thresholds per queue).
Scheduling: The switch services queues according to a configured algorithm. Common algorithms include Strict Priority (SP), Weighted Round Robin (WRR), and Shaped Round Robin (SRR).
Key States, Timers, and Defaults
Default CoS-to-queue mapping on Catalyst 2960/3650/3850: CoS 5 maps to queue 4 (priority queue), CoS 0-1 to queue 1, CoS 2-3 to queue 2, CoS 4-6 to queue 3. But this varies by platform.
Default DSCP-to-queue mapping: Often based on the CoS mapping via the DSCP-to-CoS map.
SRR shares: Default weights are usually equal (25/25/25/25) for four queues. Priority queue gets strict priority before SRR.
Tail drop thresholds: Default is 100% (no early drop). For voice, you might set a lower threshold to drop less important packets first.
Trust state: By default, switch ports are in "untrusted" mode for QoS—they rewrite the CoS to 0 unless you configure mls qos trust cos or mls qos trust dscp.
IOS CLI Verification Commands
To verify QoS configuration on a Cisco Catalyst switch:
Switch# show mls qos interface gigabitEthernet 0/1Example output:
GigabitEthernet0/1
trust state: trust cos
trust mode: trust cos
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP mutation map: defaultTo see queuing statistics:
Switch# show mls qos interface gigabitEthernet 0/1 statisticsExample output:
GigabitEthernet0/1 (All Queues)
dscp: incoming
no_policer: 0
policed: 0
aggregate_policed: 0
inprofile: 0
outprofile: 0
qos: count
qid: 0
...To see the current queue configuration:
Switch# show mls qos interface gigabitEthernet 0/1 queueingHow It Interacts with Related Protocols
QoS marking interacts with 802.1p (CoS) in VLAN tags. When a packet egresses a trunk port, the CoS value is written into the 802.1q tag. DSCP is carried in the IP header and is preserved across layer-3 boundaries. On a router, you can map DSCP to IP Precedence or vice versa. QoS also interacts with ACLs for classification and NBAR for deep packet inspection. In a typical campus network, an IP phone marks voice traffic with CoS 5 and DSCP EF (46). The switch trusts this marking and places it in the priority queue. Access switches then pass the marked packets to distribution switches, which may perform additional policing.
Configure Classification and Marking
First, define a class map to match traffic of interest. For example, match voice traffic using an ACL or NBAR. Then create a policy map to mark the matched traffic with a DSCP value. Apply the policy map to the input direction of an interface. Example configuration: ``` Switch(config)# class-map match-all VOICE Switch(config-cmap)# match ip dscp ef Switch(config-cmap)# exit Switch(config)# policy-map MARK_VOICE Switch(config-pmap)# class VOICE Switch(config-pmap-c)# set dscp ef Switch(config-pmap-c)# exit Switch(config-pmap)# exit Switch(config)# interface gigabitEthernet 0/1 Switch(config-if)# service-policy input MARK_VOICE ``` This marks any incoming packet with DSCP EF (already marked) with DSCP EF again (can be used to ensure marking). In practice, you might trust the marking from an IP phone instead.
Configure Queuing on Egress Interface
Queuing is configured on the egress interface. On Catalyst switches, you modify the queue settings using the `mls qos` commands. For example, to assign CoS 5 to the priority queue (queue 4 on many platforms) and set the bandwidth weights: ``` Switch(config)# interface gigabitEthernet 0/1 Switch(config-if)# mls qos trust cos Switch(config-if)# mls qos queue-set-output 1 Switch(config-if)# priority-queue out ``` The `priority-queue out` command enables the strict priority queue for egress. For more granular control, you can map CoS values to queues and set thresholds: ``` Switch(config)# mls qos srr-queue output cos-map queue 4 5 Switch(config)# mls qos srr-queue output bandwidth 10 20 20 50 ``` This maps CoS 5 to queue 4 and sets SRR weights (queue 4 gets 50% of bandwidth).
Verify Trust and Marking
Use `show mls qos interface <interface>` to verify that the interface trusts the correct marking. For example: ``` Switch# show mls qos interface gigabitEthernet 0/1 ``` Look for "trust state: trust cos" or "trust dscp". If it says "untrusted", the switch will overwrite any incoming CoS/DSCP to 0. Also verify that the policy map is applied correctly with `show policy-map interface <interface>`. Example output: ``` Switch# show policy-map interface gigabitEthernet 0/1 GigabitEthernet0/1 Service-policy input: MARK_VOICE Class-map: VOICE (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip dscp ef (46) QoS Set dscp ef Packets marked 0 ```
Verify Queuing Configuration
Use `show mls qos interface <interface> queueing` to see the queue configuration. Example output: ``` Switch# show mls qos interface gigabitEthernet 0/1 queueing GigabitEthernet0/1 Egress Priority Queue : enabled Shaped queue weights (absolute) : 25 0 0 0 Shared queue weights : 25 25 25 25 The port is mapped to qset : 1 ``` Check that the priority queue is enabled and that the weights are set as expected. Also use `show mls qos srr-queue output` to see the CoS-to-queue mapping: ``` Switch# show mls qos srr-queue output cos-map Queue 1 : 0 1 2 3 4 6 7 Queue 2 : Queue 3 : Queue 4 : 5 ```
Test and Monitor Traffic
Generate test traffic (e.g., using an IP phone or a traffic generator) and monitor the queue statistics. Use `show mls qos interface <interface> statistics` to see the number of packets queued and dropped per queue. Example: ``` Switch# show mls qos interface gigabitEthernet 0/1 statistics GigabitEthernet0/1 (All Queues) dscp: incoming no_policer: 0 policed: 0 aggregate_policed: 0 inprofile: 0 outprofile: 0 qos: count qid: 0 ... ``` Also use `show interfaces gigabitEthernet 0/1` to check for output drops. If you see many drops on the priority queue, you may need to police voice traffic to prevent it from starving other queues.
Troubleshoot Common Issues
Common issues: (1) QoS not working because the interface is in untrusted mode. Verify trust state. (2) Priority queue not enabled. Ensure `priority-queue out` is configured. (3) Incorrect CoS-to-queue mapping. Verify with `show mls qos srr-queue output cos-map`. (4) Policy map not applied correctly. Use `show policy-map interface` to confirm. (5) DSCP values not preserved across layer-3 boundaries. On a router, you may need to configure `ip dscp` marking in a policy map. Use `debug ip packet` carefully to see packet markings.
In a typical enterprise campus network, QoS marking and queuing are deployed to protect voice and video traffic. For example, consider a company with 500 IP phones and 50 video conferencing units. The access switches (e.g., Catalyst 2960-X) are configured to trust the CoS marking from the IP phones (CoS 5 for voice, CoS 4 for video). The switch's egress interface toward the distribution switch has a strict priority queue for voice (queue 4) and a separate queue for video with guaranteed bandwidth. This ensures that even during peak usage (e.g., end-of-month file transfers), voice calls remain clear.
Another scenario is a data center with storage traffic (iSCSI) and application traffic. Storage traffic requires low latency and no drops. The network engineer marks iSCSI traffic with DSCP CS3 (class selector 3) and places it in a high-priority queue with policed bandwidth to prevent starvation of other traffic. The remaining traffic is placed in best-effort queues. Misconfiguration here can cause storage timeouts and application slowdowns.
A common misconfiguration is forgetting to enable QoS globally with mls qos on the switch. Without this command, all QoS commands are ignored. Another is not trusting the marking from the source—if the switch is untrusted, it will overwrite CoS to 0, and voice traffic will end up in the best-effort queue, causing poor call quality. In production, always test QoS with a traffic generator and monitor queue drops. Also, consider that QoS can add latency due to processing; modern switches handle it in hardware, so impact is minimal.
The CCNA 200-301 exam tests QoS under objective 4.8: "Configure and verify QoS." You must know the difference between marking (CoS, DSCP, IP Precedence) and queuing (FIFO, priority queue, WRR, SRR). Expect scenario questions where you need to choose the correct configuration for a given traffic type.
Common wrong answers:
1. "Apply the service policy in the output direction for marking." This is wrong—marking is typically done on input. Queuing is output.
2. "Use the bandwidth command for queuing." On a switch, you use srr-queue commands, not the bandwidth command (which is for routers).
3. "DSCP EF is decimal 46, but CoS 5 is the same as DSCP 5." No, CoS is a 3-bit field in the 802.1q tag, while DSCP is 6 bits. They are different.
4. "All switches support the same queuing commands." False—platforms vary. The exam likely uses Catalyst 3650/3850 or 2960-X.
Exam-specific values:
- DSCP EF = 46 (voice)
- DSCP AF41 = 34 (video)
- CoS 5 = voice, CoS 4 = video, CoS 3 = call signaling
- Default trust state: untrusted (unless mls qos is enabled and trust configured)
- Default queue weights: equal (25 each for 4 queues)
Decision rule: If the question says "voice traffic must have low latency" → use a priority queue. If it says "guarantee bandwidth for video" → use a queue with a minimum bandwidth guarantee (WRR). If it says "mark traffic from a specific subnet" → use an ACL in a class map.
Calculation traps: None for this topic, but be careful with DSCP-to-CoS mapping. DSCP EF (46) maps to CoS 5, but not all DSCP values map to a CoS value (only the first 3 bits are used).
QoS marking uses DSCP (6 bits, 0-63) or CoS (3 bits, 0-7) to indicate traffic priority.
Queuing on Catalyst switches uses SRR with a strict priority queue (enabled via `priority-queue out`).
Always enable QoS globally with `mls qos` before applying any QoS commands.
Trust state must be configured on the interface: `mls qos trust cos` or `mls qos trust dscp`.
Use `show mls qos interface <int> queueing` to verify queue configuration.
Voice traffic should be marked as DSCP EF (46) and mapped to the priority queue.
On the exam, remember that marking is applied on input, queuing on output.
These come up on the exam all the time. Here's how to tell them apart.
DSCP
6 bits in IP header
64 possible values (0-63)
Used at Layer 3 (routed networks)
Preserved across layer-3 boundaries
Common values: EF (46), AF41 (34)
CoS (802.1p)
3 bits in 802.1q tag
8 possible values (0-7)
Used at Layer 2 (switched networks)
Lost when VLAN tag is removed
Common values: 5 (voice), 4 (video)
Mistake
DSCP and CoS are the same thing and can be used interchangeably.
Correct
DSCP is a 6-bit field in the IP header (values 0-63), while CoS is a 3-bit field in the 802.1q tag (values 0-7). They are different and used in different contexts.
Both are used for QoS marking, so candidates often confuse them.
Mistake
The `service-policy output` command is used to apply marking.
Correct
Marking is typically applied on input (`service-policy input`). Queuing is applied on output.
It seems intuitive to mark packets as they leave, but marking on input allows downstream devices to trust the marking.
Mistake
Enabling `mls qos` on the switch automatically trusts all incoming CoS markings.
Correct
Enabling `mls qos` globally enables QoS processing, but interfaces default to untrusted. You must explicitly configure `mls qos trust cos` on each interface.
Candidates assume the global command implies trust, but it does not.
Mistake
The priority queue has unlimited bandwidth and can handle any amount of traffic.
Correct
The priority queue is serviced first, but if it is oversubscribed, it can starve other queues. Best practice is to police priority traffic to a percentage of the link bandwidth.
The name 'priority' suggests it is special, but it can cause issues if not policed.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
IP Precedence uses the first 3 bits of the ToS byte (values 0-7), while DSCP uses the first 6 bits (values 0-63). DSCP is backward compatible with IP Precedence: the first 3 bits of DSCP are the same as IP Precedence. For example, DSCP EF (46) has a binary of 101110, so the first 3 bits are 101 (5), which maps to IP Precedence 5. Cisco recommends using DSCP for finer granularity. On the exam, know that DSCP is the modern standard.
First, enable QoS globally with `mls qos` in global configuration mode. Then, on each interface where you want to trust markings, configure `mls qos trust cos` or `mls qos trust dscp`. For queuing, configure the egress queues with `srr-queue` commands. Without `mls qos` globally, no QoS commands take effect. Also, note that on some platforms like the 2960-X, QoS is disabled by default.
By default, switch interfaces are in untrusted mode. This means the switch will overwrite any incoming CoS or DSCP marking to 0. To preserve markings, you must explicitly configure `mls qos trust cos` or `mls qos trust dscp`. This is a common exam trap: candidates assume that enabling `mls qos` globally makes all interfaces trust, but it does not.
Use `show mls qos interface <interface> queueing` to see if the priority queue is enabled and which CoS maps to it. Then use `show mls qos interface <interface> statistics` to see the packet counts per queue. You can also use `show policy-map interface <interface>` to see if the marking policy is matching traffic. Finally, use `show interfaces <interface>` to check for output drops; if the priority queue has many drops, you may need to police voice traffic.
Yes, a policy map can contain multiple classes, and each class can have multiple actions, such as `set dscp` and `police`. For example, you can mark voice traffic with DSCP EF and police it to 1 Mbps. The order of actions matters: marking typically happens before policing. However, on some platforms, you may need separate policy maps for input and output actions.
This command maps a CoS value (0-7) to an output queue number. By default, CoS 5 maps to queue 4 (priority queue), but you can change it. For example, if you want CoS 5 to go to queue 3 instead, you would use `mls qos srr-queue output cos-map queue 3 5`. This is useful when you have multiple traffic types and want to customize queue assignments.
SRR (Shaped Round Robin) and WRR (Weighted Round Robin) are both scheduling algorithms that service queues in a round-robin fashion with weights. The key difference is that SRR can shape the output rate (by using absolute weights), while WRR shares bandwidth proportionally. On Catalyst switches, SRR is used for both sharing and shaping. In sharing mode, weights are relative (e.g., 25/25/25/25). In shaping mode, weights are absolute (e.g., 10 Mbps). The exam may refer to both, but know that SRR is the Cisco implementation.
You've just covered Lab: Configure QoS Marking and Queuing — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?