LACP, Link Aggregation & MLAG Best Practices

A customer has four 10Gbps links bundled to the core switch, but a single backup job still appears limited to around 10Gbps. Where did the other bandwidth go?

This is a common misunderstanding around link aggregation. The bundle can carry more traffic overall, but an individual connection normally uses one physical member. Understanding that distinction helps engineers set realistic expectations and design redundancy that survives the failures that matter.

What is link aggregation?

A Link Aggregation Group (LAG) combines multiple physical Ethernet links into one logical interface. It provides aggregate capacity and can maintain connectivity when a member link fails, provided enough working members remain.

The relevant standard is IEEE 802.1AX; link aggregation was previously associated with IEEE 802.3ad. Product terminology varies:

Cisco: EtherChannel or Port-Channel.
Aruba/HPE: trunk or LAG, depending on the platform. Here, trunk can mean aggregation rather than VLAN tagging.
Linux/Proxmox: bond; the selected bonding mode determines whether LACP is used.
Fortinet: aggregate interface, with LACP options depending on the platform.

Check the actual operating mode rather than relying on the interface name.

LACP is not the link bundle

The Link Aggregation Control Protocol (LACP) negotiates and monitors aggregation membership. It helps confirm compatible partners, detects loss of protocol participation, and excludes members that are no longer eligible to forward. Physical link-down detection also contributes to failure handling.

Static aggregation configures the bundle without LACP negotiation. It can work, but provides fewer checks against incorrect partner connections. LACP helps prevent certain mistakes; it does not validate every VLAN, MTU or application requirement. Neither method turns multiple members into one giant single-flow connection.

The single-flow trap

Four 10Gbps members offer approximately 40Gbps of aggregate capacity in each direction across suitably distributed traffic, before overhead and other limits. One TCP connection does not normally get 40Gbps.

Devices generally select an outgoing member using a hashing algorithm. Depending on the device and configuration, inputs may include source and destination MAC addresses, source and destination IP addresses, and Layer 4 source and destination ports.

A flow normally maps to one member to preserve packet ordering. A single backup stream may therefore remain limited by one 10Gbps link, with useful application throughput below that line rate.

Multiple simultaneous flows can use different members. However, hashes can collide: several flows may select the same link while another stays lightly loaded. Equal utilisation is not guaranteed, and each end independently selects its outgoing member.

Why more links may not speed up one transfer

One large SMB transfer, backup stream, iSCSI session or TCP connection may use a single member. Multiple sessions or parallel streams can distribute more effectively when the hashing policy distinguishes them.

Application features matter. SMB Multichannel or supported storage multipathing can create multiple paths or connections, but require compatible configuration. A backup job may already open several streams; verify its actual behaviour before concluding that it is a single flow.

Storage performance, protocol overhead, CPU, NIC capability, disk throughput and application behaviour can all become bottlenecks. Measure member counters alongside application performance. For storage context, see Hardware vs Software RAID.

A LAG still has a single-switch problem

A conventional LAG usually terminates on one logical switch. Four cables into one standalone switch can protect against certain cable or port failures, but the switch remains a shared dependency.

Switch failure, maintenance or loss of power may take every member down together. Multi-chassis designs address this dependency, although their own control and inter-switch links also need careful design.

What is MLAG?

Multi-Chassis Link Aggregation allows two physical switches to present a coordinated logical LACP partner to a connected device. The device can be dual-homed, with members connected to both switches.

Examples include Cisco vPC, Aruba VSX, Arista MLAG, Juniper MC-LAG and FortiSwitch MCLAG. These implementations are not identical: peer coordination, supported topologies, failover behaviour and configuration requirements differ.

The purpose is to remove a single-switch dependency and maintain connectivity during supported failure scenarios. Peer-link failure, split-brain prevention, keepalive design and devices connected to only one peer deserve explicit review and testing.

Enterprise design examples

Servers and hypervisors

Dual-home supported servers or virtualisation hosts to a redundant switching pair. Match host bonding configuration to the switch design, and check management, migration and storage traffic separately. Two independent switches cannot accept one ordinary cross-switch LAG without suitable coordination.

Access switches

Use redundant uplinks toward distribution or core switches where the topology supports them. Confirm whether the design uses MLAG, stacking, spanning tree or routed links; these have different forwarding and recovery behaviours.

Firewall high availability

Firewall clusters may aggregate links toward redundant switching infrastructure where supported. Check the firewall platform’s HA behaviour, aggregate-interface support and switching requirements. An aggregate interface alone does not make a firewall deployment highly available.

Modern data centres

Leaf-spine fabrics frequently use Layer 3 equal-cost multipath routing (ECMP) between switches. LACP or MLAG may still serve server-facing connections, depending on the architecture. Fabric routing and host attachment solve different parts of the design.

Hashing matters

Layer 3/Layer 4 hashing can distinguish multiple sessions more effectively than simpler Layer 2 hashing in many environments. For example, sessions between the same two MAC addresses may still have different IP addresses or transport ports.

No policy is universally best. Select it for the traffic pattern, devices, applications, topology and vendor implementation. Test representative traffic and inspect individual member utilisation. A policy change may remap existing flows, so check its operational impact before changing a production bundle.

LACP active mode

Active mode initiates LACP negotiation; passive mode responds. Active mode on the relevant interfaces can make establishment more predictable. Two passive endpoints normally do not initiate a bundle. Confirm platform behaviour and supported settings at both ends rather than applying vendor-specific assumptions.

Set a suitable min-links threshold

A four-member LAG may stay operational with one surviving member. That leaves 25% of its nominal aggregate capacity, which may be insufficient for the workload.

Where supported, min-links can mark the logical interface down when the number of eligible members falls below a configured threshold. This can trigger an alternate path instead of leaving a severely degraded bundle active. Threshold semantics vary by vendor; verify that an alternate path exists and test both failure and recovery.

Important design checklist

Use matching interface speeds and supported member types.
Verify VLAN configuration on the logical interface and members as required.
Keep MTU consistent across the intended path.
Confirm LACP mode at both ends.
Review the hashing algorithm against actual traffic.
Spread links across hardware where appropriate and supported.
Monitor individual member utilisation, errors and drops.
Test link failure and recovery.
Test switch failure where resilience depends on MLAG.
Configure suitable min-links where supported.
Document the physical and logical topology.
Verify both ends of the LAG match, including allowed VLANs and member state.

Common mistakes

Assuming 4 × 10G means one 40G connection.
Spanning two independent switches without supported MLAG or stacking.
Leaving mismatched VLANs.
Allowing inconsistent MTU.
Mixing incompatible static and LACP settings.
Choosing hashing without considering the workload.
Testing total bandwidth while ignoring individual member usage.
Calling multiple cables redundancy when they still depend on one switch.

Practical takeaway

Adding cables does not automatically remove a single point of failure. Review dependencies across links, ports, line cards, switches, power and upstream paths. Then test whether traffic recovers within the application’s tolerance, with enough capacity remaining.

Originally discussed on LinkedIn

This practical guidance expands on the topic introduced in the original LinkedIn discussion.

Practical infrastructure support

Need help reviewing network resilience, switching, LACP or infrastructure design? IOT SOLUTIONS provides practical IT infrastructure consulting and system integration and professional technical training for organisations in Malaysia.

Need help with IT infrastructure planning or troubleshooting?

Share the operational requirement and we can discuss a practical infrastructure or support approach.

Explore Solutions