I85PREP
⌘ K
Aruba ACSP study materials
Aruba ACSP study resources

Backup Slower After Dual-Homing

Aruba ACSP · Put your knowledge to work in context.

All case studies

Backup Slower After Dual-Homing

Four research nodes each dual-home 25 GbE into an Aruba 8325 VSX pair as a multi-chassis LAG with LACP; the ISL is a 2x100G LAG. Node A's nightly backup moved 8 TB in 62 minutes over its old single 25G link. After the dual-homing redesign the same job takes 105 minutes. During the job, show interface reports each 25G member at about 6 Gbps and the ISL at 5.8 Gbps. Hashing is the default L3/L4 profile. The backup agent opens four TCP streams to one destination IP and port. Node B still uses active/standby teaming per an old vendor document; Node C uses 802.3ad with a layer 3+4 transmit hash; Node D uses adaptive load balancing. Core uplinks are a separate 2x100G LAG running at 40% average.

1. Explain why Node A gets roughly 12 Gbps aggregate instead of 50, and why the ISL is carrying 5.8 Gbps during a server-to-server job.

Read the worked answer

The links are healthy; the traffic lacks entropy.

  • LACP hashes per flow (or per frame, depending on the hash), not per byte. Four TCP streams distributed across two 25G members means at most two streams per member, at roughly 3 Gbps each, so each member shows about 6 Gbps and the total is about 12 Gbps. A single member can never exceed 25 Gbps, and the aggregate is capped by the number and size of flows, not by link capacity.
  • The hash is deterministic: identical four-tuples always land on the same member. With one destination IP and one destination port, the only entropy source is the source port, which is why the spread is uneven and stable rather than fluctuating.
  • The ISL traffic is expected MLAG behavior. A frame can arrive on the peer that does not own the egress member link for that flow, and must then cross the ISL to leave through the correct port. In VSX both peers forward, so hairpinning over the ISL is normal, not a fault.

The original 62-minute job ran on one 25G link, so 12 Gbps is a throughput regression from expectation, not a broken LAG. Record that baseline before changing anything.

2. Which changes would you make, and which tempting changes would you refuse?

Read the worked answer

Adopt

  • Increase the number of parallel streams (for example iperf3 -P 16, or a backup agent with multiple concurrent jobs and separate source ports). This is the cheapest and most reliable fix, because it adds the entropy the hash needs.
  • Verify the hash actually includes L4 ports, and check for hash polarization against the core LAG. If both the server MLAG and the core LAG use the same inputs, test an alternative profile.
  • Bring Node B onto LACP with a modern hash. Active/standby throws away half the bandwidth and gains nothing on Aruba hardware.
  • Size the ISL for hairpinned traffic. At 5.8 Gbps today there is headroom, but if all four nodes back up simultaneously the ISL becomes the shared bottleneck.

Refuse

  • Adding member links. Four flows will still land on two ports, and you add failure surface for no gain.
  • Per-packet member selection. It reorders packets and collapses TCP throughput.
  • Node D's adaptive load balancing in a VSX MLAG. It can reorder and it hides failures from LACP.
  • Raising LACP timers or changing to static LAGs to 'fix' throughput. Speed is a hashing problem, not a protocol problem.

3. What would you verify before and after the change, and what would make you conclude the design itself is wrong?

Read the worked answer

Before

  • show lag and show lacp interfaces to confirm both members are collecting and distributing, and that the partner is in sync.
  • show vsx status on both peers: ISL up, keepalive up, config sync in-sync, roles correct.
  • show interface rates per member and ISL during a controlled test, plus show interface error counters to rule out a bad optic masquerading as a slow link.

After

  • Re-run the backup and compare elapsed time and per-member rates. Success is roughly proportional load across members, not 'both lights on'.
  • Re-check ISL utilization, since more streams means more hairpinning.
  • Confirm no output drops or discards appeared on the LAG.

Signs the design is wrong

  • Even with many streams, one member is consistently saturated and the other idle. That points to polarization between the server hash and the core hash, and is fixed by profile or topology change, not by adding links.
  • ISL utilization approaches ISL capacity during normal multi-node backups. Then the MLAG has become a shared choke point and the nodes should be split across both peers by design, not all dual-homed.