mediumMultiple Choice
350-401 Practice Question: Is configuring QoS on a Cisco router to…
A network engineer is configuring QoS on a Cisco router to prioritize business-critical applications. The engineer creates a class-map that matches traffic based on the destination IP address and port. However, the class-map does not match the expected traffic. What is the most likely reason?
⚠ Common exam trap
Cisco often tests the subtle difference between 'match-all' (default) and 'match-any' in class-maps, trapping candidates who assume that multiple match conditions automatically use OR logic.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The class-map uses 'match-all' but the engineer intended to use 'match-any'.
When a class-map uses 'match-all', all match conditions must be true for a packet to be classified. If the engineer intended to match traffic based on either the destination IP address OR the port, using 'match-any' would allow the class-map to match if any single condition is met. The mismatch occurs because the class-map is too restrictive, requiring both conditions to be satisfied simultaneously.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
The class-map uses 'match-all' but the engineer intended to use 'match-any'.
Why this is correct
Because the class-map is configured with 'match-all', every match statement must evaluate true for a packet to be classified into that class. QoS class-maps default to 'match-all' unless 'match-any' is explicitly specified; if the engineer configured multiple match conditions such as 'match access-group' and 'match protocol' and only one of those conditions is satisfied, the packet will not be placed in this user-defined class. As a result, the intended QoS policy (such as marking, policing, or queuing) will not apply to that traffic, and the packet falls through to the default class. Changing the class-map to 'match-any' allows the traffic to match when any one of the conditions is true.
- ✗
The access-list used for matching is not applied to the correct interface.
Why it's wrong here
Access-lists used inside a class-map are not interface service-policies; they simply define a traffic pattern that the classification engine evaluates against a packet. In Modular QoS CLI (MQC), the class-map references the access-list, then the policy-map references the class-map, and only the policy-map is attached to the interface with the 'service-policy' command. Applying an access-list directly to an interface would cause it to act as a traffic filter (dropping or permitting packets), which is a completely different function from QoS classification. Therefore, the access-list not being applied to the interface is irrelevant to why the classification is not matching; the correct action is to ensure the policy-map using this class-map is attached.
- ✗
The router does not support matching on both IP and port in the same class-map.
Why it's wrong here
Cisco routers fully support matching on multiple fields such as IP source/destination addresses and TCP/UDP port numbers within a single class-map, either by configuring separate 'match' statements or by referencing an access-list that includes multiple protocol and port entries. The MQC architecture is designed to combine classification criteria flexibly, and no standard IOS/IOS-XE platform prohibits matching on both IP and port simultaneously. If the classification appears to fail, the real cause is not a platform limitation but likely the class-map's 'match-all' logic, which requires every separate 'match' statement to be true. When an access-list is referenced, its entries are OR'd internally, but this does not change the relationship between multiple independent match statements in a match-all class-map.
- ✗
The class-map must be applied to the interface before it can match traffic.
Why it's wrong here
A class-map itself is a standalone classification container that is not directly attached to an interface; it gains operational effect only when a policy-map includes that class and when the policy-map is applied to an interface using the 'service-policy' command in the input or output direction. The router evaluates the class-map's match criteria during packet processing only after the parent policy-map is attached, so applying only the class-map (or doing nothing) would never enable classification. The missing step in this scenario is not 'applying the class-map' but ensuring the policy-map that references this class-map is correctly configured and attached to the desired interface. Additionally, you should verify the direction (ingress/egress) matches where you expect the classification to occur.
Quick reference
IPv4 Address Class Summary
| Class | First Octet Range | Default Mask | Networks | Hosts per Network |
|---|---|---|---|---|
| A | 1–126 | /8 (255.0.0.0) | 126 | 16,777,214 |
| B | 128–191 | /16 (255.255.0.0) | 16,384 | 65,534 |
| C | 192–223 | /24 (255.255.255.0) | 2,097,152 | 254 |
| D | 224–239 | N/A | Multicast groups | — |
| E | 240–255 | N/A | Reserved / experimental | — |
127.x.x.x is reserved for loopback. Modern networks use CIDR (classless) rather than classful addressing.
Go deeper
Related to this question
About these practice questions
One of 1,923 original 350-401 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 350-401 practice question is part of Courseiva's free Cisco certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 350-401 exam.