Uplink Congestion After Access-Layer Consolidation
A 48-port access switch serves 40 endpoints: 30 VoIP phones with PCs daisy-chained, 6 wireless APs, and 4 servers. The switch has two 1 GbE SFP uplinks in a static LAG to a distribution switch. Users report choppy voice during file transfers and slow wireless roaming. Port counters show the LAG members at 85-92% utilization during peak, with output drops on the AP-facing ports. The VoIP traffic is untagged on VLAN 10; AP management is on VLAN 20 and SSIDs are tunneled to a controller. There is no QoS configured anywhere, and the distribution switch has a single 10 GbE link to the core. The customer wants a fix this week and cannot replace hardware.
1. Identify the most likely root cause of voice quality degradation and justify it with the evidence given.
Read the worked answer
The evidence points to congestion and head-of-line blocking on the 2 GbE LAG, not a voice-specific fault.
- LAG members at 85-92% peak utilization means the bundle is near saturation; a static LAG hashes flows across members, so a few large transfers plus tunneled AP traffic can fill one member while the other is underused (asymmetric hashing).
- Output drops on AP-facing ports indicate egress queuing on the access switch, so voice frames compete in a single FIFO-ish queue with bulk data - jitter and loss follow.
- No QoS anywhere means voice is not prioritized and cannot be protected when the uplink is the bottleneck.
- Tunneled SSIDs mean all wireless client traffic, including roaming-related control, is carried over the same saturated LAG to the controller.
So the judgement call: the uplink bundle, not the phones or the APs, is the constrained resource.
2. Propose a remediation plan that does not require new hardware, ordered by effort and impact.
Read the worked answer
Order by effort/impact:
- Enable QoS trust and prioritization end-to-end on the path: trust DSCP/CoS on phone-facing ports (phones typically mark EF), classify voice into a strict-priority or low-latency queue, and cap bulk-data queues. This is configuration-only and directly addresses jitter.
- Reduce uplink load: move the 4 servers off this access switch or onto a separate path; the servers are the likely bulk-transfer source and should not share an access uplink with voice.
- Re-balance the LAG: verify hashing (L3+L4 if supported) so flows spread across both members; confirm both members are actually forwarding and not one-sided.
- Local switching for AP traffic if the controller/AP model supports it, so wireless client data does not traverse the saturated LAG to the controller.
- Monitor queue drops and per-member utilization after each step; only then consider link aggregation changes (e.g., LACP with more members if spare ports exist).
Avoid: blaming the phones, replacing hardware, or adding bandwidth at the core - the core link is not the reported constraint.