mediumMultiple Choice
350-401 Practice Question: An enterprise is deploying a leaf-spine…
An enterprise is deploying a leaf-spine architecture in its data center to support high-bandwidth east-west traffic. The design must include QoS to prioritize storage replication traffic (iSCSI) over backup traffic, while ensuring low latency for real-time applications. Where should the architect apply QoS classification and queuing policies in this topology?
⚠ Common exam trap
Cisco often tests the misconception that QoS policies should be applied only at the core or spine layer, but the correct approach requires classification at the edge (leaf ingress) and queuing on all egress interfaces to ensure end-to-end treatment across the fabric.
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
✓
Apply classification and marking on the leaf switches at ingress, and queuing policies on egress interfaces of both leaf and spine switches.
In a leaf-spine architecture, QoS classification and marking must occur at the ingress of leaf switches (where traffic enters the fabric) to identify iSCSI, backup, and real-time flows. Queuing policies must be applied on egress interfaces of both leaf and spine switches to manage congestion and prioritize latency-sensitive traffic across the entire path, ensuring end-to-end QoS for east-west traffic.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Apply classification and marking on the leaf switches at ingress, and queuing policies on egress interfaces of both leaf and spine switches.
Why this is correct
This is the correct QoS architecture. In a leaf-spine fabric, the leaf switch is the first device to see server-originated traffic, so it must be the trust boundary: classify and mark traffic (e.g., iSCSI as EF or AF4x, backup as AF11) at ingress, using ACLs, class-maps, and policy-maps. Then apply egress queuing policies on both leaf and spine egress interfaces: spines handle inter-leaf traffic and need the same scheduling (strict priority, bandwidth allocation, WRED) based on the already-marked DSCP values, while leaf egress interfaces handle traffic toward servers (including storage targets). Marking at ingress and consistent queuing at every egress hop preserves the PHB (Per-Hop Behavior) across the fabric, so iSCSI latency and loss stay controlled even when backup traffic congests the network.
- ✗
Apply all QoS policies only on the spine switches, since they handle inter-leaf traffic.
Why it's wrong here
This approach is fundamentally flawed because spine switches only see traffic that has already entered the fabric and do not directly connect to servers or storage end devices. Classification and marking must happen at the ingress leaf switch, which is the trust boundary where packets are first received; if no marking is done there, the spine would have to rely on default/untrusted DSCP values or infer application type from deeper packet inspection, which is both CPU-intensive and fragile. Additionally, spine egress policies alone cannot manage traffic destined to servers from the leaf's egress interface—the leaf egress is the final queue before the server and is critical for protecting latency-sensitive iSCSI from backup traffic. Therefore, placing all QoS on spines misses the necessary marking step and leaves leaf egress uncontrolled.
- ✗
Configure QoS only on the default gateway router, which is upstream of the leaf-spine fabric.
Why it's wrong here
Configuring QoS only on the upstream default gateway router fails because the overwhelming majority of data-center micro-segmentation traffic—such as iSCSI between application servers and storage arrays, or backup between servers and media agents—never crosses the gateway; it stays inside the leaf-spine fabric. The router sees only traffic destined to external networks or potentially inter-VLAN traffic if it is on a stick, but in modern leaf-spine designs with anycast gateway on the leaves, even most North-South traffic is handled at the leaf without touching a separate router. As a result, gateway-only QoS cannot prioritize iSCSI over backup within the fabric, where congestion actually occurs, so the solution is ineffective for intra-fabric flows and does not address the stated problem.
- ✗
Use a single QoS policy on all interfaces with default settings, relying on hardware buffers.
Why it's wrong here
A single QoS policy with default settings on all interfaces is a no-op for differentiation because default hardware queues typically treat all packets as best-effort with a single FIFO or share bandwidth equally, offering no preference for iSCSI over backup. Hardware buffers are finite and are not a substitute for explicit scheduling—under burst or congestion, both delay-sensitive iSCSI and bulk backup traffic will compete equally, causing iSCSI latency spikes, possibly timeouts, and inconsistent performance. Furthermore, relying on hardware buffers without classification/marking means that even if the hardware supports multiple queues, packets are not mapped to the appropriate queue; you must explicitly classify and mark traffic at ingress and assign queuing behavior at egress to ensure the PHB guarantees, rather than hoping the ASIC buffers will absorb the burst.
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.