Sizing Uplinks for a Mixed Wired/Wireless Closet
A two-building campus uses Aruba CX 6300M switches as access stacks. Building A has 9 stacks of 4 members each; each member provides 48 GbE access ports with 802.3at PoE. Peak measured access-port utilization is 22% bidirectional, average frame size 600 bytes. Each stack currently uplinks with a single 10G DAC to a CX 8360 core pair running VSX. The customer wants to add 240 Wi-Fi 6E APs (each AP: 1x 5G base-T uplink, typical busy-hour load 350 Mbps, peak 1.2 Gbps) and reports intermittent congestion on two stacks during class changes. The design must survive one core switch failure and one stack-member failure without oversubscription worse than 4:1 on access-to-uplink.
1. Determine the minimum uplink capacity per stack and whether the current single 10G uplink is adequate. Show your arithmetic and state assumptions.
Read the worked answer
Access-side demand. Per stack: 4 members x 48 ports = 192 ports. At 22% of 1 Gbps per port, aggregate = 192 x 0.22 = ~42.2 Gbps. That is the offered load, not the uplink need - but it is the number the 4:1 rule is applied to for capacity planning.
AP demand. 240 APs across 9 stacks ≈ 27 APs/stack. Busy-hour 350 Mbps each = ~9.3 Gbps/stack; peak 1.2 Gbps each = ~32 Gbps/stack. Wi-Fi 6E APs with 5G uplinks can exceed 1 Gbps, so 1G AP ports are a bottleneck; assume 5G or 2.5G AP ports and that AP traffic lands on the stack.
Combined worst case (busy hour). 42.2 + 9.3 ≈ 51.5 Gbps offered. A single 10G uplink gives ~5:1, violating the 4:1 target. Minimum uplink = 51.5 / 4 ≈ 12.9 Gbps, so 2 x 10G (20G) LAG is the floor; 2 x 25G is the safer choice given peak AP bursts.
Resilience check. With VSX on the core, a 2-member LAG split across both core switches survives one core failure at half bandwidth (10G), which then fails the 4:1 rule at peak. Recommend 2 x 25G LAG (50G), one member per core switch: single core failure leaves 25G, still ≥4:1. For stack-member failure, ensure the LAG has members on at least two stack members so losing one member does not drop the whole uplink.
2. The two congested stacks show drops only during class changes. What is the most likely cause and what would you change first?
Read the worked answer
Class changes are a short, synchronized burst - hundreds of clients re-authenticating and re-ARPing at once. Symptoms point to microbursts filling shallow egress queues, not sustained average oversubscription (average utilization looked fine).
First changes, in order:
- Verify with sub-second counters. Check interface output drops and queue statistics (e.g.,
show interface ... queues), not 5-minute averages. Confirm drops are on the uplink egress. - Widen the uplink. Convert the single 10G to a 2 x 25G LAG across stack members and core peers. This raises the burst ceiling more than any tuning.
- Tune QoS/queue scheduling on the uplink: ensure bursty best-effort traffic is not starved and that CoS mapping is consistent end-to-end; avoid policing that clips legitimate bursts.
- Reduce the burst source. Enable broadcast/multicast storm control sensibly, ensure DHCP snooping/ARP protection limit broadcast storms, and stagger client reconnection where the WLAN controller allows it.
Do not start by adding more access ports - the bottleneck is the uplink egress queue depth and headroom, not port count.