DMCP study materials
DMCP study resources

One-Way Audio on a VLT Leaf Pair

DMCP · Put your knowledge to work in context.

All case studies

One-Way Audio on a VLT Leaf Pair

At a university campus, each building is dual-homed to a pair of Dell PowerSwitch S5248F-ON leaf switches running VLT. The VLT pair connects northbound with two 40 GbE uplinks to a spine and uses a two-member 100 GbE VLTi. VLAN 120 carries IP phones and uses DSCP EF marking; VLAN 130 carries IPTV multicast. Since a new 1 GbE access switch was added in Building C, users report one-way audio and jitter between 10:00 and 11:00, but only for calls that traverse the leaf pair. The new switch is single-homed to leaf-1. Monitoring shows no uplink saturation, but broadcast and unknown-unicast counters increase on leaf-2. The phone system vendor says the network is dropping RTP. The campus has no packet broker; captures can be taken at the leaf.

1. Form a working hypothesis and list the commands or data you would use to confirm it.

Read the worked answer

Hypothesis: the new single-homed access switch is creating an orphan-port and unknown-unicast path, and RTP is taking asymmetric paths across the VLT pair. A device single-homed to leaf-1 is not inherently broken, but if its MAC is not learned symmetrically, leaf-2 floods unknown unicast, which matches the rising counters. One-way audio occurs when RTP ingress and egress use different leaf peers and one direction is dropped or delayed by VLT or spanning-tree behavior.

Collect show vlt detail, show vlt mismatch, show vlt backup-link, show interfaces, show mac address-table, show spanning-tree, show qos interface, and logs on both leaves. Check VLT domain ID, peer-link status, backup link, MTU, VLAN membership, and whether the new switch's port is an orphan. Verify DSCP trust on the access switch and leaf; if the phone marks EF but the switch rewrites it, QoS queuing fails.

A packet capture on VLAN 120 at leaf-1 and leaf-2 during a bad call will show whether RTP is one-way at ingress or lost across the VLTi. That distinguishes a forwarding bug from a QoS bug before any configuration change.

2. Propose the configuration fix and how you would validate it without interrupting the whole campus.

Read the worked answer

Best fix: dual-home the new access switch with a VLT port-channel to leaf-1 and leaf-2, with matching LACP and VLAN configuration. If the switch cannot be dual-homed, explicitly configure the orphan port according to the platform's VLT orphan-port guidance and verify that flooding is controlled. Ensure the VLTi has sufficient capacity and a backup link; a single 100 GbE VLTi is a risk if all orphan traffic crosses it.

For QoS, trust DSCP on the access-to-leaf link, classify EF into the priority queue, and verify egress scheduling on the uplink. For IPTV, enable IGMP snooping and a querier on VLAN 130 so multicast is not flooded. Make changes during a low-call period and validate with a before/after packet capture, interface counters, and a test call during the 10:00–11:00 peak.

Do not simply add bandwidth; the counters point to a forwarding-path issue, not saturation. Validate one building first, then apply the same standard to other single-homed access switches.

3. How would you separate a QoS problem from a topology problem if jitter persists after the first fix?

Read the worked answer

One-way audio is a forwarding symptom, not proof of insufficient bandwidth. If jitter persists, compare voice and IPTV behavior. If both degrade, suspect a shared forwarding path or VLTi issue; if only voice degrades, suspect QoS marking or queue drops. Check DSCP trust end to end, queue drop counters, and whether the phone VLAN is using the priority queue. Check whether RTP takes an asymmetric path by capturing at both leaves and comparing timestamps and sequence numbers.

For multicast IPTV, verify IGMP snooping and querier configuration; flooding can consume capacity and affect voice. For voice, verify that EF marking survives every hop and that the uplink scheduler honors it. If captures show packets entering leaf-1 and never leaving leaf-2, the problem is topology or VLT forwarding, not QoS. Fix forwarding first, then re-test QoS. This sequence avoids tuning queues to compensate for a broken path.