Table of Contents Link to heading

• Static LAG or LACP – The Wrong Question from the Start
• NIC Teaming Architecture in VMware ESXi
  • vSphere Standard Switch and Its Protocol Limitations
  • vSphere Distributed Switch – When LACP Is Actually Valid
  • Mapping ESXi Teaming Policy to Switch Configuration
• How EtherChannel Distributes Traffic
  • Flow-Based Forwarding – Not Round-Robin
  • Hash Algorithms and Why Both Ends Must Agree
  • Real-World Bandwidth and Setting the Right Expectations
• The Silent Failure Scenario – Ports Up, System Unstable
• Verification on Cisco IOS Switches
  • Confirm All Member Ports Are Bundled
  • Verify the Active Load-Balance Algorithm
  • Detect Uneven Traffic Distribution
• Summary

Static LAG or LACP – The Wrong Question from the Start Link to heading

In working with virtualisation network infrastructure, I’ve noticed a consistent pattern: when a network engineer looks at the uplink configuration between a switch and an ESXi host, the first question is almost always “why aren’t you using LACP?” — and that’s the wrong question to start with.

The right question is: “What type of vSwitch is ESXi running, and what NIC teaming policy is active?” Because it’s the ESXi side that determines what the switch must do — not the other way around.

This post analyses the mechanism from the ESXi layer down, explains why Static EtherChannel is not just a valid option but sometimes the only correct one, and — more importantly — why a port-channel that looks perfectly healthy can still be the source of the most difficult-to-diagnose failures in a server environment.

NIC Teaming Architecture in VMware ESXi Link to heading

ESXi does not handle NIC teaming the way a conventional operating system does. Rather than allowing the kernel to manage a bonding interface directly, VMware designed two distinct vSwitch layers with fundamentally different capabilities.

vSphere Standard Switch and Its Protocol Limitations Link to heading

The critical point: vSS does not participate in any link aggregation negotiation protocol. When NIC teaming is enabled with the IP-based load balancing policy, vSS independently calculates which physical NIC to use for each frame by XOR-ing the source and destination IP addresses — it sends no LACP PDUs and there is no control plane involved in the process.

The direct consequence: the upstream switch cannot use LACP because it will never receive an LACP response. Ports waiting for LACP negotiation will either remain in an indefinite waiting state or fall back to Individual mode, and the port-channel will never form.

The correct switch configuration when facing a vSS host using IP-based load balancing is Static LAG:

port-channel load-balance src-dst-ip

interface range GigabitEthernet0/1 - 4
 description -> ESXi-HOST-01 vmnic0-3
 switchport mode access
 switchport access vlan 100
 spanning-tree portfast
 channel-group 1 mode on

vSphere Distributed Switch – When LACP Is Actually Valid Link to heading

vDS is a fundamentally different product from vSS. Most importantly: it supports LACP. vDS can send and process LACP PDUs, negotiating link aggregation properly with the upstream switch.

When infrastructure has been migrated to vDS with LAG and LACP enabled, the switch configuration changes accordingly:

interface range GigabitEthernet0/1 - 4
 description -> ESXi-HOST-01 vmnic0-3 (vDS + LACP)
 switchport mode access
 switchport access vlan 100
 channel-group 1 mode active

Both sides negotiate, confirm each other, and form the bundle correctly — this is how LACP was designed to work.

Mapping ESXi Teaming Policy to Switch Configuration Link to heading

Looking at this table, the question “static or LACP?” is really just a consequence of the underlying question: “what policy is ESXi actually running?”

How EtherChannel Distributes Traffic Link to heading

This section is the source of many serious misunderstandings — both about expected bandwidth behaviour and about how to troubleshoot when something goes wrong.

Flow-Based Forwarding – Not Round-Robin Link to heading

EtherChannel does not distribute traffic round-robin per packet. If it did, packets belonging to the same TCP session would arrive via different physical paths with different latencies, causing out-of-order delivery — TCP would retransmit continuously and effective throughput would collapse.

Instead, EtherChannel distributes by flow. Each flow — identified by header fields determined by the active load-balance method — is hashed to an index, and that index maps to a fixed physical port. All packets belonging to that flow traverse the same single port for the lifetime of the session.

An example with a 4-member port-channel:

TCP session: 10.10.1.5:49200  → 192.168.50.100:443   | Hash mod 4 = 2 → Gi0/3
TCP session: 10.10.1.8:51000  → 192.168.50.200:3306  | Hash mod 4 = 0 → Gi0/1
TCP session: 10.10.2.3:44100  → 10.20.5.10:8080      | Hash mod 4 = 3 → Gi0/4

Each session is pinned to a single physical port — no session is ever split across multiple links.

Hash Algorithms and Why Both Ends Must Agree Link to heading

Cisco IOS supports multiple load-balance methods, configured globally with port-channel load-balance:

On the ESXi side with IP-based load balancing, vSS also XORs source and destination IPs to select a pNIC. If the switch is configured with src-mac while ESXi hashes by IP, traffic distribution between the two sides will be misaligned — some links will be overloaded while others sit nearly idle, with no warning or alert generated.

Real-World Bandwidth and Setting the Right Expectations Link to heading

Aggregate throughput only approaches the sum of all links when there are many VMs generating hundreds of concurrent sessions with diverse source and destination IPs — where the hash distributes evenly across all 4 links and aggregate throughput approaches 4 Gbps.

EtherChannel in a virtualised server context is a solution for aggregate bandwidth and link redundancy, not per-connection speed. If the requirement is to accelerate a single connection, this is not the right technology.

The Silent Failure Scenario – Ports Up, System Unstable Link to heading

The situation: The switch is configured with Static EtherChannel (mode on). The ESXi administrator — typically a different team — configures a NIC teaming policy that is not IP-based: either leaving the default “Route based on originating virtual port ID” or explicitly setting Active/Standby.

After configuration, the system appears entirely healthy:

• All port-channel members show as Up
• ESXi reports no NIC warnings
• Basic ping tests and traffic flows normally

Problems then begin appearing intermittently: packet loss that comes and goes, some VMs experiencing flapping connectivity while others are unaffected, storage I/O latency spikes that resolve on their own, logs with nothing conclusive.

Root cause: The switch is treating the 4 ports as a bundle and distributing traffic according to its own hash logic. ESXi may be sending frames out a fixed pNIC without following compatible logic. The result is that some frames arrive at the switch from a pNIC that doesn’t align with the port-channel’s forwarding expectations — causing abnormal forwarding decisions: duplicate frames, localised loops within the bundle, or silently dropped frames.

The only way to detect this is through active verification on both sides: checking the switch’s load-balance policy against the NIC teaming policy running on the vSS, and confirming that the hash logic is compatible between them.

Verification on Cisco IOS Switches Link to heading

Confirm All Member Ports Are Bundled Link to heading

show etherchannel summary

The output should show all member ports with flag P (bundled in port-channel):

Flags:  D - down        P - bundled in port-channel
        I - stand-alone s - suspended
        H - Hot-standby (LACP only)
        R - Layer3      S - Layer2
        U - in use      f - failed to allocate aggregator

Number of channel-groups in use: 1
Number of aggregators:           1

Group  Port-channel  Protocol    Ports
------+-------------+-----------+------------------------------------------
1      Po1(SU)          -        Gi0/1(P)  Gi0/2(P)  Gi0/3(P)  Gi0/4(P)

Verify the Active Load-Balance Algorithm Link to heading

show etherchannel load-balance

Cross-reference the output with the NIC teaming policy on the ESXi side. If ESXi is using IP-based load balancing, the switch should be running src-dst-ip:

port-channel load-balance src-dst-ip

Detect Uneven Traffic Distribution Link to heading

Check counters on each member port individually:

show interfaces GigabitEthernet0/1 counters
show interfaces GigabitEthernet0/2 counters
show interfaces GigabitEthernet0/3 counters
show interfaces GigabitEthernet0/4 counters

Compare input and output packet counts across all ports. Perfect distribution is not expected — hash algorithms are never perfectly uniform — but if one port is carrying 80–90% of all traffic while another is nearly idle, that indicates either a hash skew or a workload that is too concentrated on a narrow range of IP addresses to benefit from the hash spread.

Summary Link to heading

Static EtherChannel with ESXi is not a shortcut or a workaround — it is a technical requirement that follows directly from the protocol limitations of vSphere Standard Switch. Understanding this distinction prevents an entire class of failures that aren’t caused by hardware or cabling, but by two halves of a system operating under incompatible assumptions.

When troubleshooting a port-channel connected to an ESXi host, the correct sequence is:

1. Determine whether ESXi is running vSS or vDS
2. Identify the NIC teaming policy currently active on the vSwitch
3. Cross-reference it against the mode and load-balance method on the switch
4. Verify actual traffic distribution across member ports
5. Only then look at individual port up/down state

The majority of issues in this category are resolved at steps 2 and 3 — before any packet capture tooling is needed.