Configuring LACP on a VMware vSphere Distributed Switch
Link aggregation combines multiple physical switch links into a logical connection. In a VMware vSphere environment, Link Aggregation Control Protocol (LACP) can improve uplink resilience and distribute traffic across several physical adapters connected to a vSphere Distributed Switch (vDS).
A correctly designed LACP configuration requires coordination between vCenter, ESXi hosts, and the physical network switches. The distributed switch must use a compatible version, the switch ports must belong to the same aggregation group, and each host must present its vmnics consistently.
This guide covers the main design decisions, switch configuration, vSphere setup, migration precautions, and troubleshooting methods. The examples apply to common enterprise environments in Australia, including centralised data centres in Sydney and Melbourne and smaller infrastructure footprints in Brisbane, Perth, or regional offices.
Confirm the design and compatibility
Before making changes, document the current vDS version, ESXi release, physical NIC assignments, switch model, and cabling. Every host in the cluster should have equivalent uplinks wherever possible. For example, vmnic2 and vmnic3 might connect to separate members of a redundant switch stack, while vmnic0 and vmnic1 remain available for management or vMotion.
LACP support and configuration options vary between vSphere releases and switch vendors. Check the VMware Compatibility Guide and the network vendor documentation before selecting a mode. In most deployments, configure the physical switch ports and the vSphere LAG for active LACP negotiation. Do not assume that a port-channel configured for a traditional static EtherChannel will behave identically to an LACP bundle.
Consider the failure domains as well. Connecting both links to the same physical switch provides link redundancy but not switch redundancy. If the design uses two switches, they must support a suitable multi-chassis link aggregation technology, such as MLAG, VLT, or a vendor-specific equivalent.
Prepare the physical switch ports
Create an LACP port-channel on the physical switch for each ESXi host, unless the switch platform supports a shared multi-chassis design. Add only the ports connected to that host to its aggregation group. Configure the member interfaces consistently with the same VLAN trunk, native VLAN, MTU, speed, and spanning-tree settings.
A typical trunk carries management, vMotion, vSAN, virtual machine, and backup VLANs. Permit only the VLANs required by that host and document the VLAN IDs carefully. Australian organisations often inherit VLAN records from multiple projects, so validate the live switch configuration rather than relying solely on an old Visio diagram or spreadsheet.
Do not configure one port-channel containing links from unrelated ESXi hosts. Each host requires its own logical bundle. Also check that the physical switch does not suspend a member because of mismatched speed, duplex, VLAN, MTU, or trunk settings.
Create the LAG on the distributed switch
In the vSphere Client, open Networking, select the distributed switch, and choose the option to add a Link Aggregation Group. Give the LAG a clear name, define the number of ports, and select the supported LACP negotiation mode. The port count must match the number of physical uplinks that will participate from each host.
After creating the LAG, add or migrate the host uplinks into it. The vSphere Client presents a migration workflow that can move vmnics and associated networking configuration. Review the proposed mapping carefully, particularly when the host is remote or carries production management traffic.
For a site in Perth connecting back to a central operations team in Sydney, a mistake during uplink migration can leave engineers dependent on an out-of-band console or a costly remote-hands visit. Schedule the change within an approved maintenance window and confirm access through the iDRAC, iLO, console server, or another independent path.
Apply the correct port group policies
LACP is configured at the distributed switch and LAG level, but port group policies still determine how traffic uses the available uplinks. Review the teaming and failover settings for every affected distributed port group. When using link aggregation, select the load-balancing policy recommended for the vSphere release and switch design, commonly a policy based on IP hashing.
Do not combine a LAG with an incompatible teaming policy or place the same uplinks in conflicting active and standby roles. Keep VLAN tagging consistent: virtual machine port groups generally use VLAN or VLAN trunking at the vDS, while the physical switch ports remain configured as trunks.
LACP distributes flows, not individual packets. A single TCP session between two endpoints may remain on one physical link, so a 10 GbE LAG does not automatically provide 20 GbE to one file transfer. Multiple VM conversations, backup streams, and vMotion operations are more likely to use the bundle effectively.
Migrate hosts without losing connectivity
For a new cluster, build the vDS and LAG before placing production workloads on it. For an existing cluster, migrate one host at a time and verify its management, vMotion, storage, and virtual machine networks after each change. Keep at least one known-good recovery path until the host has been validated.
Use a staged migration for critical environments. First add the host to the vDS, then move one uplink, confirm that the LACP bundle forms, and migrate the remaining uplink only after the first path is stable. Avoid making simultaneous changes across every host during an Australian business-hours change window, particularly when sites span AEST, ACST, and AWST.
After migration, test more than ping. Check vMotion, access to vCenter, VM gateway reachability, DNS, monitoring, backup traffic, and any vSAN or NFS paths. If the environment uses jumbo frames, verify the configured MTU end to end rather than testing only the ESXi-to-switch link.
Validate and troubleshoot the bundle
On the physical switch, confirm that all expected member ports are attached to the same LACP group and show a collecting or forwarding state. Look for suspended interfaces, partner mismatches, VLAN inconsistencies, and links negotiating at an unexpected speed. A switch may report the port-channel as operational even when one member is silently excluded.
In vSphere, inspect the distributed switch, LAG status, host uplink assignment, and port group teaming policy. ESXi logs can reveal link flaps, LACP negotiation errors, VLAN failures, and physical NIC resets. A useful test is to disconnect one cable at a time during an approved window and confirm that traffic continues through the remaining member.
Common causes of failure include configuring LACP on only one side, using a static port-channel on the switch, assigning the wrong vmnic order, mismatching the LAG port count, or connecting a host uplink to the wrong switch. In a home lab built with nested ESXi, LACP testing can also be misleading because virtual NICs and nested switches may not reproduce production behaviour.
Once the bundle is stable, record the vDS version, LAG name, switch port-channel IDs, VLANs, MTU, vmnic-to-switch mappings, and rollback steps. This operational record is particularly valuable when an Australian managed service provider or data-centre technician needs to diagnose a fault outside the normal local support window.