QoS Architecture practice questions

The policy-map is not applied to the correct interface direction.

Why wrong: Incorrect because the policy-map could be applied in the input direction, but without trust, the marking may still not be honored.

The switch does not support DSCP-to-CoS mapping.

Why wrong: Incorrect because Catalyst 9300 switches support DSCP-to-CoS mapping.

The IP phone is not sending packets with DSCP EF.

Why wrong: Incorrect because the scenario states the engineer is trying to mark the packets, meaning the phone may or may not be marking them; the issue is on the switch side.

RTP traffic uses UDP ports, and the class-map must match on the UDP port range instead.

Why wrong: Incorrect because 'match protocol rtp' should match RTP traffic regardless of port, but it requires NBAR.

The class-map must be configured with 'match any' to capture all traffic.

Why wrong: Incorrect because 'match any' would match all traffic, not specifically RTP.

RTP traffic is always marked with DSCP EF, so the class-map should match on DSCP instead.

Why wrong: Incorrect because RTP traffic may not always be marked, and the engineer wants to match based on protocol, not marking.

Configure a policy-map that sets the DSCP to EF, and the router will automatically set IP precedence to 5.

Why wrong: Incorrect because setting DSCP does not automatically set IP precedence; they are separate fields.

Use the 'qos map dscp-ip-precedence' command to create a mapping table.

Why wrong: Incorrect because that command is used on some platforms to map DSCP to IP precedence, but it is not the standard method on most routers.

The router will automatically map DSCP EF to IP precedence 5 without any configuration.

Why wrong: Incorrect because there is no automatic mapping; the engineer must configure the marking.

The router does not trust the CoS marking and re-marks it to 0.

Why wrong: Incorrect because the router may trust the marking, but CoS is not preserved across Layer 3 interfaces.

The switch must be configured to set DSCP instead of CoS.

Why wrong: Incorrect because setting DSCP on the switch would also be lost if not mapped, but the issue is specifically about CoS.

The router must have 'mls qos trust cos' configured on the interface.

Why wrong: Incorrect because the trust command is for accepting markings, but CoS is still a Layer 2 field.

The priority queue is not configured with a bandwidth statement.

Why wrong: Incorrect because LLQ requires a bandwidth statement, but the issue is about drops due to policing.

The class-map is not matching voice traffic correctly.

Why wrong: Incorrect because the scenario states the drops are occurring, which indicates matching is happening.

The router is using FIFO queuing instead of LLQ.

Why wrong: Incorrect because LLQ is configured, but the drops are due to policing, not wrong queuing.

CoS

Why wrong: Incorrect because CoS is a Layer 2 marking and is stripped at Layer 3 boundaries.

IP Precedence

Why wrong: Incorrect because IP Precedence is also a Layer 3 field, but it has only 3 bits, providing fewer classes than DSCP.

MPLS EXP

Why wrong: Incorrect because MPLS EXP is used in MPLS networks and may not be supported by all non-Cisco devices.

The access-list used for matching is not applied to the correct interface.

Why wrong: Incorrect because the access-list is used within the class-map, not applied directly to the interface.

The router does not support matching on both IP and port in the same class-map.

Why wrong: Incorrect because routers support matching on multiple fields.

The class-map must be applied to the interface before it can match traffic.

Why wrong: Incorrect because the class-map itself does not need to be applied; the policy-map containing the class-map must be applied.

The queue-limit is set too low, causing tail drops.

Why wrong: Incorrect because the engineer set the queue-limit, but the issue may be that the queue is not being used.

The video traffic is not being marked with DSCP AF41.

Why wrong: Incorrect because the scenario assumes the marking is correct.

The policy-map must be applied to the output direction.

Why wrong: Incorrect because the policy-map is likely applied correctly, but the queue configuration is missing.

The router does not support setting MPLS EXP bits.

Why wrong: Incorrect because most Cisco routers support setting MPLS EXP bits.

The MPLS EXP bits are set automatically based on the IP precedence.

Why wrong: Incorrect because automatic mapping may not occur unless configured; the engineer explicitly set the EXP bits.

The policy-map must use 'set mpls experimental imposition 5' instead of 'set mpls experimental 5'.

Why wrong: Incorrect because the command 'set mpls experimental' sets the EXP bits on the imposed label; the issue is the interface direction.

Implement a single FIFO queue on all interfaces and rely on the default CoS-to-queue mapping to prioritize voice.

Why wrong: FIFO does not provide differentiated treatment; voice and video would compete with data, causing jitter and loss.

Configure strict priority queuing for all traffic marked with DSCP values greater than 0.

Why wrong: This would prioritize all marked traffic, including bulk data, starving other traffic and not guaranteeing bandwidth for video.

Use the IntServ model with RSVP to reserve bandwidth for each voice and video flow.

Why wrong: IntServ is not scalable for large campus networks and is not the DiffServ model required by the scenario.

Define a localized QoS policy on each branch router using MQC, matching the same DSCP values.

Why wrong: Localized policies must be configured per device, which is less scalable and prone to inconsistency; centralized policy is the architectural choice for SD-WAN.

Use the vSmart controller to apply QoS policy only on the MPLS transport, leaving Internet and LTE unmanaged.

Why wrong: This would not provide consistent treatment across all transports, violating the requirement.

Implement QoS using RSVP across the overlay tunnels.

Why wrong: RSVP is not used in SD-WAN; the fabric uses centralized policy-based QoS.

Apply all QoS policies only on the spine switches, since they handle inter-leaf traffic.

Why wrong: Spine switches do not see traffic from servers directly; classification must occur at the leaf where traffic enters.

Configure QoS only on the default gateway router, which is upstream of the leaf-spine fabric.

Why wrong: This would not affect traffic within the fabric, failing to prioritize iSCSI over backup inside the data center.

Use a single QoS policy on all interfaces with default settings, relying on hardware buffers.

Why wrong: Default settings do not differentiate traffic; iSCSI and backup would compete, causing potential performance issues.

Use a Type 2 hypervisor to allow the VNF to share resources with other VMs more efficiently.

Why wrong: Type 2 hypervisors add overhead; Type 1 (bare-metal) is preferred for performance-sensitive VNFs.

Enable overcommitment of CPU resources to maximize the number of VNFs per host.

Why wrong: Overcommitment can cause CPU contention, increasing latency and reducing throughput for the CSR1000v.

Place the CSR1000v on a VMware ESXi host instead of KVM for better performance.

Why wrong: Both hypervisors can perform well with proper tuning; the key is CPU pinning and NUMA awareness, not the hypervisor brand.

Configure QoS policies on the wireless LAN controller (WLC) only, marking voice traffic with DSCP EF, and rely on the fabric to preserve the marking.

Why wrong: While marking is important, the fabric edge must still apply queuing; this approach does not leverage fabric-specific features like SGT.

Implement a centralized QoS policy on the fabric border node that matches the source IP addresses of voice devices.

Why wrong: Border nodes handle traffic leaving the fabric; classification should occur at the edge where traffic enters.

Use VXLAN network identifiers (VNIs) to classify voice traffic and apply QoS on the control plane node.

Why wrong: VNIs segregate traffic but are not used for QoS classification; control plane nodes do not forward data traffic.

Use a single level of CBWFQ on all interfaces, classifying traffic by tenant using VLANs.

Why wrong: Single-level CBWFQ cannot enforce per-tenant bandwidth limits; tenants could starve each other.

Apply strict priority queuing for all mission-critical traffic across all tenants.

Why wrong: This would allow one tenant's critical traffic to monopolize bandwidth, violating fairness.

Configure separate physical interfaces for each tenant and apply independent QoS policies.

Why wrong: This is not scalable and wastes ports; HQoS is designed for multi-tenant environments on shared interfaces.

Use a policer on the ingress interface to drop traffic exceeding the CIR.

Why wrong: Policing drops excess traffic, which is not the goal; shaping buffers excess traffic to avoid drops.

Configure a shaper on the provider's device instead of the customer router.

Why wrong: The customer cannot control the provider's device; shaping must be done on the customer edge.

Set the interface bandwidth to the CIR and rely on FIFO queuing.

Why wrong: This does not shape traffic; it only sets the bandwidth parameter, which does not prevent bursts from exceeding the CIR.

Use a centralized data policy to steer video traffic to the MPLS link only.

Why wrong: This does not address congestion on the Internet link; video may still be delayed if it uses that link.

Implement a centralized application-aware routing policy to prefer the MPLS link for video.

Why wrong: This influences path selection but does not provide QoS queuing on the Internet link.

Configure a VPN membership policy to isolate video traffic in a separate VPN.

Why wrong: VPN isolation does not provide QoS queuing; traffic still competes within the VPN.

Remark all traffic to a single DSCP value at the access layer and apply priority queuing at the core.

Why wrong: Remarking all traffic to the same value eliminates differentiation; voice would not receive priority.

Apply QoS policies only at the core layer, ignoring markings from the access layer.

Why wrong: Without classification at the access, the core cannot distinguish voice from other traffic.

Use the distribution layer to reclassify traffic based on source MAC addresses of IP phones.

Why wrong: MAC-based classification is less scalable and not standard; DSCP trust is the recommended approach.

The VOICE class traffic is always sent before other classes, and excess traffic beyond 30% is queued in the default class.

Why wrong: Priority traffic is not re-queued; excess is dropped unless police is configured differently.

The VIDEO class traffic is treated with strict priority after the VOICE class.

Why wrong: Only the class with the priority command gets strict priority; VIDEO uses bandwidth guarantee.

The class-default uses Weighted Fair Queuing with a maximum queue size of 100 packets, and all classes share the remaining bandwidth equally.

Why wrong: The class-default uses fair-queue, but the bandwidth allocation for VIDEO is fixed at 20%, not equally shared.

The policy-map is applied to traffic entering the interface, performing classification and marking.

Why wrong: Input direction is used for classification and marking; output is for queuing.

The policy-map can only be applied if the interface is in a shutdown state.

Why wrong: Service-policy can be applied on active interfaces without shutdown.

The policy-map must contain a class-default with a shape command to be valid.

Why wrong: Shape is not mandatory; the policy-map can use bandwidth, priority, or fair-queue in class-default.