CCNP Practice Question: Is deploying QoS on a Cisco Catalyst 4500 switch…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Modify the CoS-to-queue mapping using the 'mls qos srr-queue output cos-map' command

  Why this is correct

  This command is correct because on Catalyst switches the default queue assignment for output traffic is based on the CoS value in the 802.1Q header. By modifying the CoS-to-queue map, you can explicitly assign voice (typically CoS 5) to a strict-priority queue and video (e.g., CoS 4) to a separate standard queue, thereby preventing inter-class contention. The command takes precedence over any default mapping and gives the engineer deterministic control over which hardware queue each marked packet uses.

• ✗

  Change the video traffic marking to DSCP AF41 and rely on DSCP-to-queue mapping

  Why it's wrong here

  This is incorrect because, by default, Catalyst switches perform queue selection based on the CoS field, not the DSCP value, unless you explicitly configure 'mls qos trust dscp' and a DSCP-to-queue map (e.g., 'mls qos srr-queue output dscp-map'). Simply re-marking video to AF41 does not change the CoS-to-queue assignment, so video would still be placed in the same queue as voice if both have the same CoS or if the DSCP mapping is not defined. Furthermore, even with DSCP trust enabled, the default DSCP map might still not separate AF41 from voice, so an additional mapping change would still be required.

• ✗

  Apply a service policy that uses a priority queue for voice only

  Why it's wrong here

  Applying a service policy that designates a strict priority queue for voice only does not address the underlying queue mapping problem. The priority command only dictates the scheduling behavior of the queue that voice is placed in; it does not alter which hardware queue video is mapped to. Since video remains in its default queue (which may be the same as voice if the CoS-to-queue mapping is unchanged), the two traffic classes will continue to share the same buffer and scheduling treatment. The correct approach is to remap the CoS values so that voice and video are assigned to different queues, then optionally apply priority scheduling to the voice queue.

• ✗

  Increase the number of queues to eight

  Why it's wrong here

  Increasing the number of output queues to eight is impossible on most Catalyst switching platforms because the number of egress queues per port is fixed by the hardware and typically ranges from two to four, with some ASICs supporting more but not via a software command. Even on platforms that support eight queues, the real issue is that voice and video are currently colliding in the same queue due to the existing CoS-to-queue mapping. Merely adding queues provides no benefit unless the mapping is changed to direct the traffic into the new queues. There is no CLI command to alter the hardware queue count, so this option is not a valid solution.