All Traffic Hitting class-default — Classification Not Working
Presenting Symptom
All traffic is being matched by the class-default class in a QoS policy, and no traffic is being classified into the user-defined classes.
Network Context
A small branch office with a Cisco 4321 ISR router running IOS XE 16.9. The router has a single WAN link (GigabitEthernet0/0/0) and a LAN interface (GigabitEthernet0/0/1). A QoS service-policy is applied outbound on the WAN interface to prioritize voice and business-critical traffic, but monitoring shows all traffic falling into class-default.
Diagnostic Steps
Check the QoS policy applied to the interface
show policy-map interface GigabitEthernet0/0/0 GigabitEthernet0/0/0
Service-policy output: QOS-POLICY
Class-map: VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
Class-map: BUSINESS-CRITICAL (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp af31 (26)
Class-map: class-default (match-any)
1000 packets, 120000 bytes
5 minute offered rate 10000 bps, drop rate 0 bps
Match: anyAll traffic is hitting class-default, and the user-defined classes (VOICE, BUSINESS-CRITICAL) show zero packets. This indicates that the classification criteria (DSCP values) are not being matched. Possible reasons: traffic is not being marked with the expected DSCP values, or the match statements are incorrect.
Verify the class-map configuration
show class-mapClass Map match-any VOICE (id 1) Match ip dscp ef (46) Class Map match-any BUSINESS-CRITICAL (id 2) Match ip dscp af31 (26) Class Map match-any class-default (id 0) Match any
The class-maps are configured correctly. The issue is not with the class-map definitions themselves.
Check if traffic is actually being marked with the expected DSCP values
show access-listsExtended IP access list MARK-VOICE
10 permit ip any any dscp ef
Extended IP access list MARK-BUSINESS
10 permit ip any any dscp af31If the traffic is not being marked, the ACLs used for marking may not be matching the traffic. Alternatively, the marking policy may not be applied. This step helps confirm if marking is in place.
Verify the marking policy application
show policy-map interface GigabitEthernet0/0/1 GigabitEthernet0/0/1
Service-policy input: MARKING-POLICY
Class-map: MARK-VOICE (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: access-group 100
Class-map: MARK-BUSINESS (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps
Match: access-group 110
Class-map: class-default (match-any)
1000 packets, 120000 bytes
5 minute offered rate 10000 bps
Match: anyIf the marking policy shows zero packets in the marking classes, it means the ACLs are not matching the traffic. This could be due to incorrect ACL entries or the marking policy not being applied to the correct interface/direction.
Root Cause
The marking policy is applied inbound on the LAN interface (GigabitEthernet0/0/1) but the ACLs used for marking reference the wrong protocol or source/destination. Specifically, the ACLs are matching DSCP values instead of setting them. The correct configuration should use 'set ip dscp' in the policy-map, but the ACLs should match traffic based on other criteria (e.g., source IP, protocol). In this case, the ACLs are configured to permit traffic with a specific DSCP value, but the traffic arrives without any DSCP marking, so no packets match the ACLs, and no marking occurs. Consequently, the outbound QoS policy sees no DSCP markings and all traffic falls into class-default.
Resolution
Verification
1. Check marking policy counters: show policy-map interface GigabitEthernet0/0/1 Expected: Packets are now matching the MARK-VOICE and MARK-BUSINESS classes. 2. Check outbound QoS policy counters: show policy-map interface GigabitEthernet0/0/0 Expected: Packets are now matching VOICE and BUSINESS-CRITICAL classes, not just class-default.
Prevention
1. Always test QoS marking with traffic generators or by checking packet captures to ensure ACLs match the intended traffic. 2. Use 'match ip dscp' in the outbound policy only after confirming that marking is correctly applied upstream. 3. Document the QoS design clearly, including which interfaces have marking policies and the direction of application.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario tests understanding of QoS classification and marking. Questions may present a troubleshooting scenario where all traffic falls into class-default, and the candidate must identify that marking is missing or misconfigured. The exam expects knowledge of the 'show policy-map interface' command and the relationship between marking and classification.
Exam Tips
Remember that classification in a QoS policy relies on the packet's existing markings; if traffic is not marked, it will fall into class-default.
The 'show policy-map interface' command shows per-class packet counts; zero counts in user-defined classes indicate classification failure.
Be able to distinguish between marking (set ip dscp) and classification (match ip dscp); marking must occur before classification.
Commands Used in This Scenario
show access-lists
Displays all configured access control lists (ACLs) on the device, including their entries and match counters, used to verify ACL configuration and traffic filtering.
show class-map
Displays the configuration and match criteria of all class maps or a specific class map, used to verify QoS classification rules.
show policy-map interface
Displays the current QoS policy applied to an interface, including per-class statistics such as packets matched, bytes, and actions taken, used to verify and troubleshoot QoS configurations.
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions