I85PREP
⌘ K
Aruba Switching Expert (Written) study materials
Aruba Switching Expert (Written) study resources

QoS Starvation of Voice Under Bulk Data

Aruba Switching Expert (Written) · Put your knowledge to work in context.

All case studies

QoS Starvation of Voice Under Bulk Data

An access switch connects IP phones (VLAN 50, DSCP EF 46) and PCs (VLAN 10, untrusted, DSCP 0) to a 1 Gb/s uplink. During large file transfers from PCs, users report choppy voice. The switch is configured with a single output queue for all traffic and no trust or marking policy; DSCP values pass through unchanged. Uplink egress shows the queue dropping packets during transfers, and voice RTP loss correlates with those drops. The company wants voice protected without over-engineering.

1. Explain why voice suffers despite DSCP EF markings, and what the switch must do to help.

Read the worked answer

DSCP markings alone do nothing unless the switch classifies, queues, and schedules based on them. With a single output queue, EF voice and bulk PC data share one FIFO; during a transfer the queue fills and tail-drops voice RTP along with data. The DSCP is preserved but never acted upon.

The switch must:

  • Classify/trust voice (trust DSCP EF on phone ports; do not trust PC ports, or police/re-mark them to 0).
  • Place voice in a strict-priority (or low-latency) queue and data in a weighted/best-effort queue.
  • Schedule with priority for voice and weighted sharing for the rest so bulk data cannot starve voice.

Without a scheduler and multiple queues, markings are cosmetic.

2. Propose a minimal QoS configuration intent and the verification steps.

Read the worked answer

Minimal intent:

  • On phone ports: trust DSCP (or trust CoS from the phone) so EF is honored; optionally police to a voice rate.
  • On PC ports: do not trust; re-mark to DSCP 0 (or a scavenger class) so users cannot self-mark priority.
  • Egress uplink: at least two queues - strict priority for EF, weighted (e.g., WRR/DRR) for the rest - with a scheduler guaranteeing voice latency.

Verification:

  • show policy-map/show class-map to confirm classification and trust boundaries.
  • show queue/interface queue counters to confirm voice lands in the priority queue and data in the weighted queue.
  • Re-run the file transfer and confirm voice queue drops are ~0 while data queue absorbs drops.
  • Confirm PC-marked EF is re-marked at ingress (trust boundary works).

Keep it to two queues and one trust boundary per port role - sufficient to protect voice without a full QoS architecture.