QoS marking mismatches are one of the most common yet subtle causes of poor application performance in enterprise networks. On the CCNA 200-301 exam, objective 4.8 (Troubleshoot) requires you to diagnose why traffic isn't receiving the expected priority, even when QoS policies appear correct. In real networks, a marking mismatch can cause voice jitter, video freezing, or critical data delays — and finding the root cause demands a systematic approach. This chapter gives you the tools to identify, isolate, and fix marking mismatches using the right show commands and packet-level analysis.
Jump to a section
Imagine a busy airport where luggage moves through a conveyor system. Each piece of luggage has a colored tag (priority marking) that tells handlers whether it's first-class (gold), priority (silver), or economy (white). The system is designed so gold tags always go on the fast belt, silver on the medium belt, and white on the slow belt. Now, suppose a first-class passenger's bag accidentally gets a white tag (marking mismatch). The bag will be routed to the slow belt, even though the passenger paid for fast delivery. The conveyor system doesn't know the bag's true priority — it only reads the tag. Similarly, in a network, routers and switches trust the DSCP or CoS markings in the packet header. If an application marks packets as EF (Expedited Forwarding, for voice) but a downstream device re-marks them to DF (Default Forwarding, best effort), the voice packets will be treated like data. The network devices are just following the tag; they don't verify if the tag is correct. The root cause isn't a broken conveyor but a mismatch between the intended priority and the actual marking. To fix it, you must trace where the marking gets changed — often at a trust boundary, a policing policy, or a misconfigured interface. In the airport, you'd check every point where tags can be applied or altered: check-in, security, and transfer belts. In networking, you check ingress interfaces, classification policies, and remarking rules.
What is a QoS Marking Mismatch?
A QoS marking mismatch occurs when a packet carries a Differentiated Services Code Point (DSCP) or Class of Service (CoS) value that does not match what the network policy expects for that traffic type. For example, voice traffic should typically be marked with DSCP EF (46), but if it arrives with DSCP 0 (Best Effort), it will not receive priority queuing. The mismatch can happen at the source (application incorrectly marking) or along the path (a device remarking the packet). The CCNA exam focuses on identifying where the marking changes and why.
How Marking Works at the Packet Level
QoS marking is applied in the IP header (DSCP) or the 802.1Q header (CoS). DSCP uses the first 6 bits of the ToS byte, while CoS uses 3 bits in the 802.1Q tag. A packet can have both markings, and there is a mapping between them (e.g., DSCP EF maps to CoS 5). When a router receives a packet, it checks the marking and applies the appropriate per-hop behavior (PHB): EF for low-loss, low-latency traffic; AF classes for assured forwarding; DF for best effort. If the marking is wrong, the PHB is wrong.
Common Causes of Marking Mismatch
Trust misconfiguration: An interface may be configured to trust CoS but the packet has only DSCP set, or vice versa. Cisco switches default to untrusted on access ports, meaning they overwrite any incoming marking with 0.
Policing/remark: A policer or service policy may be configured to mark down certain traffic (e.g., re-mark AF41 to AF42 when exceeding a rate).
Ingress classification: An MQC policy may classify traffic based on ACL or NBAR and then set a DSCP value, overriding the original marking.
End device misconfiguration: An IP phone or PC may be configured to mark traffic with the wrong DSCP (e.g., using 46 for all traffic).
Tunnel overhead: In GRE or IPsec tunnels, the outer IP header may not carry the same DSCP as the inner packet unless explicitly copied.
Key Defaults and Values
Default DSCP: 0 (Best Effort)
Default CoS: 0
Trust boundary: Usually at the access layer; Cisco switches do not trust markings by default on access ports.
CoS-to-DSCP mapping: CoS 5 → DSCP EF (46), CoS 3 → DSCP CS3 (24), etc.
DSCP-to-CoS mapping: DSCP EF → CoS 5, AF41 → CoS 4, etc.
EF value: 46 (binary 101110)
AF values: AF11 (10), AF12 (12), AF13 (14), AF21 (18), AF22 (20), AF23 (22), AF31 (26), AF32 (28), AF33 (30), AF41 (34), AF42 (36), AF43 (38)
IOS CLI Verification Commands
To diagnose marking mismatches, use the following commands:
show mls qos interface [interface]: Displays trust state and statistics.
Switch# show mls qos interface gigabitethernet0/1
GigabitEthernet0/1
trust state: trust dscp
trust mode: trust dscp
COS override: dis
default COS: 0
pass-through: none
trust device: none
qos mode: port-basedshow policy-map interface [interface]: Displays classification and marking statistics.
Router# show policy-map interface gigabitethernet0/1
GigabitEthernet0/1
Service-policy input: MARKING
class-map: VOICE (match-any)
1411 packets, 112880 bytes
5 minute offered rate 0 bps, drop rate 0 bps
match: ip dscp ef (46)
QoS Set
dscp ef
packets 1411
class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
match: anyshow class-map [name]: Displays match criteria for a class map.
debug ip packet [acl]: Use with caution to see actual packet markings.
Interaction with Related Protocols
802.1Q: CoS is carried in the 802.1Q tag; trunk ports preserve CoS. Access ports may strip the tag and lose CoS.
IP Precedence: Older 3-bit field; DSCP is backward compatible. Some devices still use IP Precedence.
NBAR: Can classify traffic based on application signatures and mark accordingly.
Policing: Can re-mark packets when they exceed a rate (e.g., conform-action transmit, exceed-action set-dscp-transmit).
Step-by-Step Packet Journey
Host sends packet with DSCP EF (46).
Access switch receives on an untrusted port → DSCP is reset to 0 by default.
Packet now has DSCP 0, not EF.
Distribution switch sees DSCP 0 → treats as best effort.
Voice quality degrades.
The fix: Configure the access port to trust DSCP from the IP phone or PC.
interface GigabitEthernet0/1
mls qos trust dscpOr use auto QoS for phones:
interface GigabitEthernet0/1
auto qos voip trustIdentify the Affected Traffic
Start by confirming which traffic is experiencing poor performance. For example, users report choppy voice calls or slow critical application responses. Verify that the issue is QoS-related by checking if the traffic is being dropped, delayed, or not receiving priority. Use 'show policy-map interface' to see if packets are matching the expected class and if any drops are occurring. Also check the interface for congestion: 'show interface' output will show output drops if queues are full. If drops are seen on the priority queue (PQ), it may indicate the queue is oversubscribed, but a marking mismatch could also cause traffic to go to the wrong queue.
Verify the Expected Marking at Source
Determine what marking the application or device should be using. For VoIP, the standard is DSCP EF (46) and CoS 5. For video conferencing, often AF41 (34) or CS4 (32). For transactional data, AF21 (18). Check the endpoint configuration or the application's documentation. If possible, capture a packet at the source using Wireshark or a monitor session to see the actual DSCP value in the IP header. For example, a Cisco IP phone marks its own voice traffic with DSCP EF, but if the phone is misconfigured, it might mark with 0. This step establishes the baseline expectation.
Trace the Marking Path with Show Commands
Use 'show mls qos interface' on each switch along the path to see the trust state. On routers, use 'show policy-map interface' to see if any marking or remarking is happening. Look for interfaces that are 'untrusted' — they will overwrite the marking to 0. Also look for policies that match the traffic and set a DSCP value. For example, if a switchport is configured as 'mls qos trust cos' but the traffic is only marked with DSCP (no 802.1Q tag), the switch will not trust the DSCP and may use the default CoS (0). Run 'show mls qos ip' to see the DSCP-to-CoS mapping. Document the marking at each hop.
Check for Policing or Remarking Policies
Policers can re-mark packets that exceed a rate. Use 'show policy-map interface' to see if the traffic is hitting a policer and what action is taken (e.g., set-dscp-transmit). For example, a policer might be configured to re-mark DSCP EF to AF31 when the rate exceeds 1 Mbps. This is a common source of marking mismatch. Also check for 'service-policy' applied in the input direction. Look at the 'QoS Set' section of the policy-map output to see if DSCP is being set. If a packet is matched by a class that sets DSCP, the original marking is overwritten.
Inspect the Actual Marking at Each Hop
Use a monitor session to capture packets at intermediate points and compare the DSCP values. For example, configure a SPAN session on a switch to capture traffic from the problematic flow and analyze with Wireshark. Look at the IP header's DSCP field. Also check the 802.1Q CoS if the traffic is on a trunk. If the marking changes between hops, you've found the mismatch location. On Cisco switches, you can also use 'show mls qos interface statistics' to see how many packets were marked with each DSCP value on an interface.
Correct the Configuration and Verify
Based on your findings, adjust the configuration. Common fixes: set the trust state to 'trust dscp' on access ports that connect to trusted devices (like IP phones); remove or modify remarking policies that incorrectly change markings; ensure that the classification in MQC matches the actual traffic. After making changes, use 'show policy-map interface' and 'show mls qos interface' to verify the marking is now correct. Also test the application performance. For example, to trust DSCP on a switchport: 'interface GigabitEthernet0/1', 'mls qos trust dscp'. To set DSCP in a policy: 'policy-map SET-DSCP', 'class VOICE', 'set dscp ef'. Then verify with 'show policy-map interface'.
Scenario 1: VoIP Quality Issues on a New Switch Deployment
A company rolled out new Cisco Catalyst 2960-X switches at the access layer. After migration, users reported choppy voice calls. The network team had configured AutoQoS VoIP on all ports connecting IP phones, but the issue persisted. Investigation revealed that the AutoQoS command 'auto qos voip trust' was applied, but the global QoS setting 'mls qos' was not enabled. Without 'mls qos', the trust setting is ignored, and all ports remain untrusted. The fix was to enable 'mls qos' globally. This scenario highlights that 'mls qos' must be enabled at the global level for any per-interface QoS trust to take effect. A common mistake is to configure interface-level trust without the global command.
Scenario 2: Video Conferencing Degradation Across a WAN
A multinational corporation used Cisco ISR 4451 routers for WAN connectivity. Video conferencing traffic (marked DSCP AF41) was experiencing packet loss and jitter. The WAN policy was configured to prioritize EF and AF41, but the traffic was being treated as best effort. Using 'show policy-map interface' on the WAN router, the engineer noticed that the video traffic was matching class-default instead of the VIDEO class. Further inspection revealed that the classification matched on 'ip dscp af41', but the incoming traffic from the LAN had been re-marked by a policer on the distribution switch to AF31 (due to a rate limit). The switch was re-marking video traffic that exceeded 5 Mbps. The solution was to increase the policer rate or remove the remark action for video traffic. This shows that marking mismatches can occur due to policing policies upstream.
Scenario 3: Data Center Traffic Not Receiving Priority
In a data center, storage traffic (iSCSI) was marked with DSCP CS4 (32) by the storage array. The ToR (Top of Rack) switch was configured with 'mls qos trust dscp', but the traffic was still being treated as best effort. The engineer used 'show mls qos interface' and saw that the trust state was 'trust dscp', but the DSCP-to-CoS mapping had CS4 mapped to CoS 0 (default). On the egress interface, the switch used CoS for queue assignment, so CS4 traffic was placed in the best-effort queue. The fix was to modify the DSCP-to-CoS mapping: 'mls qos map dscp-cos 32 to 4'. This scenario underscores that trust is not enough — the mapping must also align with the egress queuing strategy.
On the CCNA 200-301 exam, objective 4.8 (Troubleshoot) expects you to diagnose QoS marking mismatches using show commands. The exam will present a scenario with symptoms (e.g., voice quality poor) and ask you to identify the cause or the corrective action. Key areas tested:
Trust states: Understand the difference between 'trust dscp', 'trust cos', 'trust ip-precedence', and 'untrusted' (default on access ports). Know that untrusted ports set the marking to 0.
Global QoS enablement: 'mls qos' must be enabled globally for trust to work. Many candidates forget this.
AutoQoS: 'auto qos voip trust' configures trust for Cisco IP phones; 'auto qos voip cisco-phone' also enables trust and configures the phone via CDP.
Policing remark: 'police' with 'set-dscp-transmit' or 'set-cos-transmit' is a common source of remarking.
Show commands: Be able to interpret 'show mls qos interface', 'show policy-map interface', and 'show class-map'.
Common Wrong Answers
"The interface is not configured with a service-policy" — While true that no marking policy exists, the symptom is often due to trust, not lack of policy. The default action on untrusted ports is to mark everything as 0, which is the cause.
"The DSCP value is incorrect" — This is too vague. The exam expects you to identify where the marking is being changed, not just state it's wrong.
"The CoS value is not mapped to the correct queue" — This can be a secondary issue, but the primary cause is often the trust boundary.
"The router is not configured for QoS" — QoS may be configured, but the marking mismatch is due to trust or remarking.
Decision Rule for Scenario Questions
When analyzing a QoS troubleshooting scenario: 1. Identify the traffic type and expected marking. 2. Check the trust state on the ingress interface of the first switch/router. 3. Check for any service-policy that matches the traffic and sets a DSCP/CoS. 4. Check for policing that re-marks. 5. Verify the marking at each hop using show commands or packet capture.
If the marking is correct at the source but wrong at the destination, the issue is at an intermediate device. The most common cause on the exam is an untrusted access port.
QoS marking mismatch occurs when a packet's DSCP or CoS value differs from what the network policy expects.
On Cisco switches, 'mls qos' must be enabled globally for per-interface trust to take effect.
Default trust state on access ports is untrusted, which overwrites incoming markings to DSCP 0 and CoS 0.
Use 'show mls qos interface' to verify trust state and 'show policy-map interface' to see marking/remarking actions.
Common remarking sources: policers with 'set-dscp-transmit' and MQC policies with 'set dscp'.
AutoQoS VoIP trust configures trust on the port and enables CDP for phone detection.
DSCP-to-CoS mapping must align with egress queuing; use 'mls qos map dscp-cos' to adjust.
Packet capture (SPAN) is the definitive way to trace marking changes hop by hop.
These come up on the exam all the time. Here's how to tell them apart.
Trust DSCP
Uses the DSCP field in the IP header (Layer 3).
Common for IP phones and routers.
Default mapping: DSCP 0-63 to internal queues.
Requires IP routing or Layer 3 awareness.
Configuration: 'mls qos trust dscp'
Trust CoS
Uses the CoS field in the 802.1Q tag (Layer 2).
Common on trunk ports and for switch-to-switch links.
Default mapping: CoS 0-7 to internal queues.
Works at Layer 2 only.
Configuration: 'mls qos trust cos'
Mistake
Enabling 'mls qos trust dscp' on an interface automatically enables QoS globally.
Correct
No, 'mls qos' must be enabled globally first. Without it, the trust command is ignored.
Candidates assume the interface command implies global enablement, but Cisco requires explicit global configuration.
Mistake
If a switchport is configured as a trunk, it automatically trusts CoS markings.
Correct
Trunk ports do not automatically trust; they preserve the existing 802.1Q tag but the trust state still defaults to untrusted unless explicitly configured.
There is a common belief that trunk ports inherently trust because they carry VLAN tags, but trust is independent.
Mistake
Setting DSCP EF in a policy-map guarantees voice packets will be prioritized end-to-end.
Correct
The marking must be trusted at every hop; if any device re-marks or ignores the DSCP, the priority is lost.
Candidates think setting the marking once is sufficient, but trust boundaries must be configured on each interface.
Mistake
AutoQoS VoIP trust configures both trust DSCP and trust CoS.
Correct
AutoQoS VoIP trust configures trust for the specific device type. For Cisco IP phones, it sets trust to DSCP (since phones mark DSCP). It does not trust CoS from non-phone devices.
The word 'trust' in AutoQoS is often misinterpreted as trusting all markings, but it is device-specific.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
'trust dscp' tells the switch to use the DSCP value in the IP header for QoS classification and queuing. This is used when the device marks at Layer 3 (e.g., IP phones). 'trust cos' tells the switch to use the CoS value in the 802.1Q tag (Layer 2). This is common on trunk ports or when connecting to devices that set CoS. The choice depends on where the marking is applied. On an access port with a phone, you typically trust DSCP because the phone sets DSCP. On a trunk between switches, you often trust CoS because the 802.1Q tag is preserved. On the exam, know that untrusted ports set both to 0.
The global 'mls qos' command enables QoS processing on the switch. Without it, the switch ignores all QoS configuration, including trust settings, policy-maps, and queueing. It is a common oversight — you can configure interface trust commands, but they have no effect until 'mls qos' is enabled. Always verify with 'show mls qos' to see if QoS is active.
Use a SPAN session to capture traffic at the ingress and egress of the device. Compare the DSCP values in the IP header. Alternatively, use 'show policy-map interface' to see if any 'set dscp' or 'set-dscp-transmit' actions are applied. On a switch, 'show mls qos interface statistics' can show how many packets with each DSCP value were received and transmitted.
The default mapping is: DSCP 0-7 → CoS 0, 8-15 → CoS 1, 16-23 → CoS 2, 24-31 → CoS 3, 32-39 → CoS 4, 40-47 → CoS 5, 48-55 → CoS 6, 56-63 → CoS 7. For example, DSCP EF (46) maps to CoS 5. This mapping can be modified with 'mls qos map dscp-cos'.
Indirectly, yes. If traffic is marked with a low priority (e.g., DSCP 0) but the network expects it to be high priority, it may be dropped during congestion because it goes to a shallow queue or is tail-dropped. Also, if a policer re-marks traffic to a lower priority, it may then be subject to dropping by downstream devices. The mismatch itself doesn't drop packets, but the resulting treatment can.
AutoQoS simplifies QoS configuration for specific applications like VoIP. The 'auto qos voip trust' command configures the interface to trust the DSCP marking from a Cisco IP phone (detected via CDP). It also sets the appropriate queueing parameters. It is a quick way to avoid marking mismatches for voice traffic, but you must ensure the phone actually marks traffic correctly.
On a router, use 'show policy-map interface' to see classification and marking. Check if the traffic matches the expected class and if any 'set dscp' or 'set precedence' actions are applied. Also check the input and output policy direction. Use 'debug ip packet' with an ACL to see the actual DSCP values (use with caution). Ensure that the router is not re-marking due to a policer or a service policy applied on another interface.
You've just covered Troubleshoot: QoS Marking Mismatch — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?