CCNP Practice Question: An engineer is configuring QoS on a Cisco ASR…

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 interface bandwidth command is not set to 50000 kbps

  Why this is correct

  The root cause is that CBWFQ's percent-based bandwidth commands (bandwidth percent, priority percent) are calculated against the interface `bandwidth` setting, not the physical line rate. If an Ethernet interface retains its default bandwidth of 1000000 kbps (1 Gbps) while the actual WAN circuit is 50 Mbps, a voice class configured with `bandwidth percent 10` would reserve 100000 kbps instead of 5000 kbps. Without `bandwidth 50000` under the interface, the percentages do not map to the real link speed, so the voice class appears under-allocated even though the configuration is logically correct.

• ✗

  The voice class should use priority instead of bandwidth

  Why it's wrong here

  Replacing `bandwidth` with `priority` for the voice class will not fix the underlying allocation problem. `priority` provides strict priority queueing for delay-sensitive traffic, but it still uses the interface `bandwidth` value to compute the policed rate when the `priority percent` keyword is used. Moreover, strict priority can starve other classes if traffic exceeds the priority policer, whereas the issue described is about incorrect absolute bandwidth reservation due to a wrong interface reference—not about latency or priority handling.

• ✗

  The video class should use bandwidth remaining percent

  Why it's wrong here

  Moving the video class to `bandwidth remaining percent` would only change how the unused bandwidth is distributed after all classes receive their guaranteed minimums. It does not alter the absolute amount of bandwidth reserved for the voice class, which is incorrectly based on the default interface bandwidth. The voice class's `bandwidth percent` is still computed against the wrong reference value, so video's allocation method has no bearing on the voice under-allocation. The proper fix is to correct the interface bandwidth, not to reallocate leftover bandwidth.

• ✗

  The policy map is applied in the input direction

  Why it's wrong here

  Applying the policy map in the input direction is unsupported for CBWFQ bandwidth guarantees; on Cisco IOS, the `bandwidth` and `priority` commands are only honored in the output direction. For ingress traffic, only policing (e.g., `police`) is available—bandwidth reservation and queuing are egress-only features. Even if the policy were applied outbound, the voice under-allocation would persist because the interface bandwidth reference is still incorrect. Additionally, the question describes a misallocation, not a directional limitation, so the answer must address the root cause: the missing `bandwidth 50000` statement.