Configuring vSphere Distributed Switch Traffic and Load Balancing

A vSphere Distributed Switch (vDS) centralizes network configuration across ESXi hosts while providing controls that are unavailable or limited on a standard virtual switch. Traffic shaping and load balancing are especially useful when virtual machines share uplinks, converge on busy VLANs, or require predictable network performance.

Traffic shaping controls the rate at which virtual machine traffic leaves or enters a distributed port group. Load-balancing policies determine how virtual machine network adapters use physical uplinks. These settings are related, but they solve different problems: shaping limits bandwidth, while teaming distributes traffic and provides failover.

The safest implementation starts with a clear mapping of port groups, VLANs, uplinks, and physical switch configuration. Test changes with a non-critical port group before applying policies to management, vMotion, storage, or production workloads.

Prepare The Distributed Switch

Confirm that every participating ESXi host has the expected number of physical network adapters connected to the vDS. Verify the uplink names, active and standby assignments, negotiated speed, and physical switch port-channel configuration before changing load-balancing settings.

Keep management and storage traffic in mind. A policy that works well for a general server VLAN may be unsuitable for vMotion or iSCSI. Where possible, use separate distributed port groups and dedicated uplinks for latency-sensitive or storage networks.

Record the existing configuration with vCenter documentation or PowerCLI. Useful details include VLAN IDs, MTU, teaming policy, failover order, traffic-shaping values, and Network I/O Control settings. This provides a reliable rollback reference when troubleshooting.

Configure Port Group Traffic Shaping

Open the distributed port group settings in vCenter, select Edit Settings, and locate the traffic-shaping policy. Depending on the vSphere version and port-group type, separate policies may be available for ingress, egress, or both directions. Enable only the direction required by the design.

The main parameters are average bandwidth, peak bandwidth, and burst size. Average bandwidth establishes the sustained rate. Peak bandwidth permits short-term bursts above that rate, while burst size determines how much traffic can use the allowance before the average limit applies. Values are generally entered in kilobits per second.

For example, a backup network could use a sustained rate of 500 Mbps with a higher peak rate for short bursts. A small burst allowance prevents every brief transfer from being unnecessarily throttled, but an excessive value can allow traffic to overwhelm the physical uplink. Traffic shaping is usually applied per distributed port or port group, so account for the number of active virtual machines sharing the policy.

Select A Load Balancing Policy

The teaming and failover policy controls how the vDS selects an uplink. Route based on originating virtual port assigns a virtual port to an uplink and keeps that association until a failure or configuration change. It requires no special physical switch configuration and is a practical default for many environments.

Route based on source MAC hash selects an uplink according to the source MAC address. It can distribute workloads across uplinks, but a single virtual machine may still use only one uplink at a time. Route based on IP hash can distribute flows from a virtual machine across multiple uplinks, but it requires EtherChannel or a correctly configured static port channel on the physical switches.

Route based on physical NIC load dynamically moves traffic when an uplink remains highly utilized. This policy is available with appropriate vDS capabilities and generally requires the physical switches to operate as independent access ports rather than as a port channel. LACP provides negotiated link aggregation when both the vDS and physical switch configuration support the required mode.

Policy	Physical Switch Requirement	Traffic Distribution	Common Use
Originating virtual port	Independent switch ports	Per virtual port	General-purpose networks
Source MAC hash	Independent switch ports	Per source MAC	Simple host-level distribution
IP hash	EtherChannel or port channel	Per IP flow	Environments needing flow-based spreading
Physical NIC load	Independent switch ports	Dynamic uplink selection	Variable workloads
LACP	Matching LAG configuration	Negotiated flow distribution	Standardized link aggregation

A common mistake is selecting IP hash or LACP on the vDS while leaving the physical switch ports as ordinary access interfaces. This can cause intermittent connectivity, blocked ports, or MAC-flapping alerts. The vSphere policy and upstream switch design must be treated as one configuration.

Combine Shaping With Network I/O Control

Traffic shaping operates at the port-group level, while Network I/O Control (NIOC) manages contention among broader traffic classes. NIOC can reserve bandwidth, define shares, and set limits for categories such as management, vMotion, virtual machine, vSAN, and replication traffic.

Use NIOC when several traffic types compete for the same physical uplinks. A reservation protects critical operations, while shares establish relative priority during congestion. A hard limit should be used carefully because it can cap performance even when spare uplink capacity exists.

Avoid using port-group shaping and NIOC limits without calculating their combined effect. The effective throughput may be constrained by the lowest applicable limit. Document which control is responsible for each requirement so future administrators do not raise one setting while another remains restrictive.

Validate Failover And Performance

Test the configuration with representative traffic rather than relying only on a successful vCenter task. Generate transfers between suitable test virtual machines, monitor uplink utilization, and confirm that the expected port group receives the configured bandwidth behavior.

Place an ESXi host uplink into maintenance or disconnect a test cable during a controlled window. Confirm that virtual machines retain connectivity and that traffic moves to the configured standby or alternate uplink. For LACP and IP-hash designs, inspect the physical switch port-channel status at the same time.

Review vCenter performance charts, ESXi networking counters, and physical switch interface statistics. Look for dropped packets, unexpected errors, uneven uplink use, queue congestion, and failover events. Uneven utilization is not automatically a fault; a single large flow may remain on one uplink by design.

Apply Practical Design Guidelines

Use these practices when deploying traffic policies and uplink teaming:

• Start with originating virtual port for ordinary port groups unless the physical network design requires another policy.
• Match IP-hash or LACP settings precisely between vCenter and the physical switches.
• Apply shaping to the smallest logical scope that meets the requirement, usually a dedicated distributed port group.
• Use NIOC for competition between traffic classes and port-group shaping for workload-specific limits.
• Test failover, burst behavior, and sustained throughput before changing production port groups.

Keep a change record containing the vDS version, host membership, uplink mappings, port-group policies, and switch-side configuration. Include measured throughput and failover results so later troubleshooting can distinguish a policy issue from a physical network problem.

A controlled lab with two ESXi hosts, a vCenter instance, and a managed switch is enough to reproduce most scenarios. Build the design there first, then promote the validated settings through maintenance windows and monitor the result after deployment.

Use these procedures as a baseline for your vSphere network design, validate every policy against the upstream switching environment, and document the final configuration for the next operational change.