Uplink Congestion After VLAN Consolidation
A two-building campus runs ArubaOS-CX 6300M switches at each IDF, uplinked to a 6400 core via two 10G DACs in an LACP port-channel. Users were spread across VLANs 10, 20, and 30, each with its own subnet and its own uplink trunk carrying all three VLANs tagged. After a facilities consolidation, all three VLANs now terminate on the same IDF pair. Monitoring shows the LACP bundle is running at 92% average utilization during business hours and broadcast traffic has tripled. The network team proposes adding a fourth VLAN and a third 10G member to the bundle. There is no routing between VLANs today; all inter-VLAN traffic hairpins through a firewall on a stick connected to the core.
1. Is adding a third bundle member the right first move? What should be investigated before adding capacity?
Read the worked answer
Adding a member treats a symptom. The 92% utilization is aggregate across all three VLANs, and broadcast tripled after consolidation - that is the signal to investigate.
- Broadcast amplification: Consolidating three broadcast domains' worth of hosts onto one IDF pair should not triple broadcast unless the VLANs were merged or a loop/duplicate-address condition exists. Check
show interfaceerror counters,show mac-address-tablefor flapping, and ARP/ND rates per VLAN. - Hairpin traffic: Inter-VLAN traffic still traverses the firewall-on-a-stick. That traffic crosses the uplink twice (IDF→core→firewall→core→IDF). A large share of the 92% may be hairpinned flows, not intra-VLAN load. Confirm with flow sampling or interface counters on the firewall subinterfaces.
- LACP hashing: A 2-member bundle with default hashing can put a small number of elephant flows on one member. Check per-member utilization; if one member is saturated and the other idle, the fix is hashing tuning, not more members.
Only after ruling out hairpin and hashing skew does adding a member make sense - and if hairpin is the cause, moving inter-VLAN routing to the CX switches (SVIs) removes the round trip entirely and is cheaper than another DAC.
2. The team wants to enable inter-VLAN routing on the 6300M stack to eliminate the hairpin. What must change on the uplink and on the firewall for this to work correctly?
Read the worked answer
Enabling SVIs on the IDF stack changes the traffic path, so the uplink and firewall roles must be re-planned:
- Uplink: The LACP trunk currently carries VLANs 10/20/30 tagged to the core. If the IDF now owns the gateways, the core no longer needs those VLANs on the uplink except for the transit network between IDF and firewall/core. Prune the trunk to the routed transit VLAN plus any VLANs the core still terminates. Leaving all three VLANs tagged creates a Layer 2 loop risk if the core also has SVIs in those subnets.
- Firewall: It currently sees all inter-VLAN traffic. After the change it sees only traffic destined off-subnet or to filtered resources. If policy requires inspection between VLANs, you cannot simply remove the firewall from the path - you would instead route IDF→firewall→core with the firewall as the next hop, or use ACLs on the CX SVIs for the permitted flows and keep the firewall for north-south.
- Gateway move: Change the default gateway (DHCP option 3) on the three subnets to the new SVIs, and ensure the firewall's connected routes to those subnets are replaced with static or dynamic routes pointing at the IDF SVIs.
Document the new path and confirm with traceroute from each VLAN before decommissioning the old hairpin.