VMware ESXi and vSphere Cluster Management

VMware ESXi Standard vSwitch Load Balancing Policies

Learn how VMware ESXi standard vSwitch NIC teaming policies select uplinks, when to use each policy, how port-group overrides work, and how to validate failover and IP hash designs.

A VMware ESXi standard virtual switch (vSS) is a host-local virtual switch that connects virtual machines and VMkernel adapters to physical networks. Its uplinks are physical NICs assigned to the switch. A NIC teaming and load-balancing policy determines which uplink carries outbound traffic from those virtual connections.

Load balancing and redundancy are related but different. Load balancing distributes traffic among eligible uplinks. Redundancy allows traffic to continue through another uplink after a failure. Some policies provide both; Use explicit failover order primarily provides deterministic active/standby redundancy.

A policy is configured on a standard vSwitch and can be inherited by its port groups. A port group is a logical connection point for virtual machine NICs or VMkernel adapters, with its own network and teaming settings. These policies select an uplink for outbound traffic; they do not normally allow one source-to-destination network flow to exceed the bandwidth of a single physical uplink.

How policy scope and inheritance work

When you configure Teaming and failover at the vSwitch level, that configuration becomes the default for the vSwitch's port groups. A port group can either inherit the parent policy or use a customized policy.

Separate traffic classes may need different policies. For example, a management port group might require a preferred active uplink and a standby uplink, while a general VM network may use both uplinks actively. A storage or vMotion network may also need a deliberately selected physical path for isolation, switch design, or operational reasons.

Comparison of standard vSwitch policies

Route based on originating virtual port ID

Route based on originating virtual port ID is the default load-balancing policy for a standard vSwitch. A virtual port is an internal vSwitch connection point used by a VM NIC or VMkernel adapter. ESXi assigns that virtual port to an eligible uplink, and traffic from the port normally continues to use that uplink.

Distribution is based on virtual-port assignments, not on individual packets. This produces predictable behavior and avoids the need for EtherChannel or another aggregation configuration on the physical switch. It is suitable when two or more ESXi uplinks connect to ordinary, independently operating switchports that provide redundancy.

With two uplinks configured as Active, different virtual ports can be assigned across the adapters. However, the result is not guaranteed to be perfectly even. A small number of VMs, a single high-throughput VM, or a busy virtual port can leave one adapter substantially busier than the other.

Example: default redundant VM network

A standard vSwitch has two uplinks connected to independent physical switchports. Set both uplinks to Active and retain originating virtual port ID. The switch does not need an EtherChannel. ESXi can distribute virtual ports across the uplinks and fail traffic over if an eligible uplink fails.

Route based on source MAC hash

Route based on source MAC hash calculates an uplink selection from the source MAC address of the transmitting virtual NIC. A given source MAC generally uses the same uplink until the relevant assignment changes or failover occurs.

This policy does not require EtherChannel on the physical switch when used with a standard vSwitch. An administrator might select it for compatibility with an existing design or for a particular MAC-based distribution preference. It is still a hash-based assignment, not per-packet balancing.

Its main limitation appears when one or a few source MAC addresses generate most of the traffic. Those MAC addresses can hash to one uplink, leaving the other lightly used. Review actual traffic patterns rather than expecting equal utilization.

Route based on IP hash

Route based on IP hash uses a hash of the source and destination IP address pair to select an uplink. A VM communicating with several distinct destination IP addresses may therefore use multiple uplinks. This can improve distribution for a busy VM with many concurrent endpoint pairs.

For a standard vSwitch, IP hash requires the ESXi-connected physical switchports to be configured as one static EtherChannel or static port channel. Do not configure LACP as the required aggregation method for this standard-vSwitch policy. LACP is a dynamic link-aggregation protocol and must not be substituted for the static aggregation expected by vSS IP hash.

Every participating physical switchport must belong to the same aggregation group and must have compatible VLAN, trunk or access, MTU, speed, and operational settings. Confirm the physical topology first: the ports may connect to one switch, a logical switch stack, or a multi-chassis aggregation pair. The switch platform must support that topology as a single valid aggregation domain.

IP hash physical-switch readiness checklist

Enabling IP hash without matching physical aggregation can cause connectivity loss, MAC address movement between ports, intermittent traffic, or confusing one-way communication. If symptoms begin immediately after selecting IP hash, compare the effective vSwitch policy with the switch's port-channel mode and member configuration.

IP hash still does not normally split one source-to-destination IP flow across multiple adapters. Multiple distinct IP pairs are needed for the hash to produce multiple uplink selections.

Use explicit failover order

Use explicit failover order prioritizes uplinks instead of balancing normal traffic across them. ESXi uses the highest-priority active adapter that passes its configured failure-detection checks. Failure detection is the mechanism ESXi uses to decide whether an uplink remains usable.

• Active: The adapter is eligible to carry traffic normally.
• Standby: The adapter is reserved for use after an active uplink fails.
• Unused: The adapter is intentionally excluded from the port group's policy.

This policy is useful when a network requires a deterministic egress path, an active/standby design, or a preferred physical switch connection. If one uplink is Active and another is Standby, normal traffic uses the active adapter until ESXi detects a qualifying failure.

Example: deterministic management path

For a management port group, place the preferred adapter in Active and the second adapter in Standby. Select explicit failover order. Management traffic normally exits through the preferred path and moves to the standby path only when the active path fails according to the configured detection behavior.

Physical-switch design compatibility

Originating virtual port ID, source MAC hash, and explicit failover order usually use separate, independently switched uplinks. The physical switchports should provide the same required VLAN reachability without being bundled into an EtherChannel. Only standard-vSwitch IP hash requires physical-switch port aggregation.

Across teamed adapters, verify matching VLAN membership, access or trunk mode, MTU, speed, duplex expectations, and other switchport settings. A policy can be correct while the physical design is inconsistent, so inspect both sides before changing production networking.

Do not create an EtherChannel merely because a vSwitch has multiple uplinks. Aggregation is specifically required for vSS IP hash. For other policies, an unnecessary bundle can conflict with ESXi's independent-uplink behavior.

Configure a policy in the vSphere Client

1. Open the vSphere Client and go to the ESXi host's networking inventory. Depending on the client version, use Host > Configure or Host > Manage > Networking.
2. Select the target standard vSwitch.
3. Choose Edit settings.
4. Open Teaming and failover.
5. Select the intended load-balancing policy.
6. Arrange the assigned uplinks into the Active, Standby, and Unused lists as required.
7. Save the settings.
8. Inspect the effective policy and uplink roles after saving. Confirm that attached port groups are inheriting the change unless they have overrides.

Override the vSwitch policy for a port group

1. Select the target port group under the standard vSwitch.
2. Open Edit settings and locate Teaming and failover.
3. Choose the option to customize or override the inherited vSwitch policy.
4. Select the load-balancing policy and assign uplinks as Active, Standby, or Unused.
5. Save the change and verify the port group's effective configuration.

For example, leave a parent vSwitch on originating virtual port ID for ordinary VM networks while overriding one port group to use explicit active/standby uplinks for a preferred physical path.

Validation and monitoring

1. Verify the selected policy at both the vSwitch and port-group scopes.
2. Check whether the port group inherits the vSwitch settings or has a custom override.
3. Confirm each uplink's link state and its Active, Standby, or Unused role.
4. For IP hash, validate the static port-channel state and member-port consistency on the physical switch before and after the change.
5. Review ESXi uplink traffic counters and physical-switch member-port counters.
6. Where operationally safe, fail one active uplink and observe whether traffic moves to the expected adapter.

Do not assume that equal uplink utilization is the success criterion. Virtual-port assignments and hash results depend on the number of VMs, MAC addresses, IP endpoint pairs, and traffic volumes. Uneven use can be normal, particularly when one VM or flow dominates the workload.

Troubleshooting common symptoms

Intermittent connectivity after selecting IP hash

Likely causes include physical ports not being in the same static aggregation group, use of LACP instead of the expected static configuration, or mismatched VLAN, trunk, MTU, or port settings. Compare the effective vSS policy with the physical port-channel configuration. Restore a compatible policy or correct the aggregation design before further testing.

One uplink is much busier than the other

First identify the policy. Hashing may map a high-volume VM or a dominant flow to one uplink. The environment may also have too few distinct MAC addresses or IP endpoint pairs. With explicit failover order, one busy uplink may be intentional because only the preferred adapter is active during normal operation.

A port group ignores the vSwitch policy

Inspect the port group's Teaming and failover settings. It may have a custom override, or the expected uplinks may be marked Standby or Unused for that port group.

Traffic does not move to a standby uplink

The active adapter may still pass the configured failure-detection method, the uplink roles may not match the intended order, or the test may not simulate a failure that ESXi can detect. Review link state, failure detection, physical path behavior, and the effective port-group policy.

Exam-relevant points

• Originating virtual port ID is the default standard-vSwitch policy.
• Originating virtual port ID, source MAC hash, and explicit failover order do not require physical-switch EtherChannel configuration.
• Standard-vSwitch IP hash requires a matching static EtherChannel or static port channel.
• Do not use LACP as the required aggregation method for standard-vSwitch IP hash.
• IP hash can distribute different IP destination pairs from one VM, but does not normally split one IP flow across multiple uplinks.
• A port-group override takes precedence over the parent vSwitch's inherited teaming policy.
• Load balancing selects outbound uplinks; it does not make a single flow faster than one physical adapter.
• Active, Standby, and Unused describe uplink roles for the relevant vSwitch or port group.

For broader host networking administration, continue with the VMware ESXi online course and review speed and duplex configuration when checking physical-link compatibility.