Vmware Esxi

VMware ESXi Standard Switch (vSwitch) Explained

Learn how an ESXi vSphere Standard Switch forwards Layer 2 traffic, connects VMs and VMkernel services, uses VLANs and uplinks, and differs from distributed switching.

A vSphere Standard Switch, commonly called a vSwitch, is a virtual Ethernet switch that runs inside an ESXi host. It provides Layer 2 connectivity for virtual machines and ESXi VMkernel adapters.

During installation, ESXi normally creates a default standard switch. The default commonly includes a management VMkernel connection and may include an uplink, although the exact configuration depends on the installer choices and ESXi release.

A standard switch is administered at the individual-host level. By contrast, a vSphere Distributed Switch provides a centrally managed switching model across multiple hosts. A standard switch is straightforward and available directly on each host, but equivalent settings must be maintained separately on every host that needs the same network design.

How a Standard Switch Works at Layer 2

Ethernet Layer 2 is the switching layer. Forwarding decisions use destination MAC addresses, which are hardware-style Ethernet addresses assigned to network interfaces.

A standard switch receives an Ethernet frame on one virtual or physical-facing port, learns the source MAC address and its port, and uses its MAC address table to select an appropriate destination port. If the destination is unknown, the frame may be sent to multiple eligible ports. Broadcast and certain multicast traffic can also be delivered to multiple ports according to switch behavior and policy.

The switch does not inherently route traffic between IP subnets. Routing requires a router, Layer 3 switch, firewall, or another routing function. A VM using a default gateway may send traffic to that gateway, but the vSwitch itself is still forwarding the Ethernet frame at Layer 2.

Local switching inside one host

When two VMs on the same ESXi host use compatible port groups and VLANs, their frames can be switched internally. That flow does not need to leave through a physical uplink. This reduces physical-network traffic and means that a failure of an uplink does not necessarily interrupt communication between those locally connected VMs.

Core Standard-Switch Components

The vSwitch is the switching container. It contains virtual ports, connects to optional physical uplinks, and supplies policies to the port groups associated with it.

A vmnic is ESXi's name for a physical network adapter. When a vmnic is attached to a vSwitch, it becomes an uplink: a path from the host's virtual network to a physical Ethernet network.

A port group is a logical group of virtual switch ports that share configuration. A VM port group is intended for virtual machine adapters. A VMkernel port group is intended for an ESXi VMkernel adapter and its host-level services.

VM Port Groups and VMkernel Port Groups

Keeping VM and VMkernel traffic in separate port groups allows different VLAN IDs, IP networks, uplink assignments, security policies, and traffic-shaping policies to be applied to each purpose.

Common Traffic Paths

Examples

Two VMs connected to the same port group and VLAN on one host can exchange frames entirely within that host. A VM on Host A communicating with a VM on Host B sends traffic through Host A's vmnic, across the physical network, and into Host B through its vmnic.

For management, vMotion, storage, and Fault Tolerance logging, create or assign VMkernel adapters to suitable VMkernel port groups. Each service may use a separate logical network, VLAN, IP subnet, or physical path according to the design.

Host-Level Administration and Configuration Drift

A standard switch belongs to exactly one ESXi host. Its switches, port groups, uplinks, teaming settings, failover rules, VLAN IDs, security policies, and traffic-shaping policies are local configuration objects.

If several hosts must support the same workloads or services, administrators must create and maintain equivalent configurations on each host. Matching port-group names are operationally important for VM placement and migration, while matching VLAN IDs and physical-network availability are necessary for consistent connectivity.

Hosts supporting vMotion should have corresponding VMkernel port groups, compatible IP addressing, enabled vMotion services, and equivalent physical-network paths. Differences between hosts create configuration drift: a gradual divergence that can cause failures during migration, failover, or troubleshooting.

Use standard-switch configuration procedures deliberately and document the intended design for every host.

VLAN Support

A VLAN is a logical Layer 2 network segment identified by a VLAN ID. A port group can assign a VLAN ID so that VM or VMkernel traffic is associated with the intended logical network.

VLAN configuration is end to end. The port group must use the correct VLAN ID, the ESXi uplink must reach the appropriate physical switch port, and the physical switch must carry that VLAN. A vSwitch does not configure the physical switch for you.

Access and trunk concepts

An access-style physical switch port normally carries one untagged VLAN for the connected network. A trunk-style port carries multiple VLANs, usually using 802.1Q tags. The correct physical configuration depends on the port-group design and the tagging behavior expected by the environment.

For ordinary VM and VMkernel port groups, ESXi commonly handles the relationship between the virtual port group and the VLAN while the physical switch carries the required VLANs. When designing trunks, verify the tagging model and do not assume that the vSwitch changes the physical switch's access or trunk mode.

VLAN ID 0 generally represents untagged traffic. VLAN ID 4095 is associated with Virtual Guest Tagging, in which VLAN tagging can be passed to or handled by the guest. VLAN 4095 should be used only when the installed ESXi version, guest operating system, virtual hardware, physical network, and application design explicitly support that model. Validate behavior for the target release before deployment.

For practical VLAN procedures, see Configure VLANs.

Uplinks and NIC Teaming

One or more physical adapters can attach to a standard switch as uplinks. They provide the path to other ESXi hosts, physical servers, routers, firewalls, storage systems, and other external endpoints.

NIC teaming uses multiple physical uplinks for redundancy, traffic distribution, or both. Uplink roles commonly include:

• Active: normally used to forward traffic.
• Standby: held in reserve and used after an active-uplink failure.
• Unused: not used by that port group or switch policy.

Load-balancing policies determine how traffic is distributed among eligible uplinks. Failover policies determine how the switch responds to link or connectivity failures. The correct choice depends on traffic patterns, physical topology, switch capabilities, and whether link aggregation is required.

A physical port channel is a link-aggregation construct configured on the physical switch. It must match the selected ESXi teaming method. Do not configure a physical port channel merely because two vmnics are attached; incompatible aggregation and failover designs can cause loops, dropped traffic, or asymmetric behavior.

For host-level resilience, one simple design is two vmnics on one standard switch, with one uplink active and the other standby. Test the design by performing a controlled link-failure test.

Traffic and Security Policies

Policies can be defined at the standard-switch level and inherited by port groups. A port group can usually override an inherited setting. Always check the effective port-group policy rather than assuming the switch-level value is the final value.

A packet-capture appliance, network monitor, or nested virtualization workload may need one or more security exceptions. Place those exceptions on a dedicated port group where possible; do not enable broad exceptions across every production network.

Discovery and Operational Visibility

CDP, or Cisco Discovery Protocol, can expose neighboring Cisco switch information where supported and enabled. This may include details useful for identifying the connected switch and physical port.

LLDP, or Link Layer Discovery Protocol, is a related vendor-neutral discovery mechanism supported by relevant ESXi versions and network devices. Check the target release and switch capabilities before relying on it.

Discovery information helps validate cabling, confirm uplink placement, identify an unexpected physical connection, and compare the intended network diagram with the actual topology.

Capacity Planning and Limits

These are historically cited standard-switch values, not universal guarantees for every ESXi release. Always consult the VMware Configuration Maximums documentation applicable to the installed version.

Port consumption matters because each virtual adapter and service connection can consume switch ports. Port-group counts matter because a design with many workload, tenant, service, and security-specific groups can approach the per-switch limit even when the number of VMs is modest.

Conceptual Topology

A common design places separate VM and VMkernel port groups on the same standard switch. For example, a Production VM port group might use VLAN 20, while a Management VMkernel port group uses VLAN 10 and a Storage VMkernel port group uses VLAN 30. The switch connects these logical groups to one or more vmnic uplinks, which connect to a physical Ethernet switch carrying the required VLANs.

Logical separation through port groups and VLANs does not mean that the traffic uses separate physical adapters. If stronger isolation or predictable performance is required, assign different uplinks or physical networks as part of the design.

Creating and Reviewing a Standard Switch

1. Open the target ESXi host's networking settings in the vSphere Client.
2. Create or select a standard switch.
3. Assign one or more physical adapters as uplinks when external connectivity is required.
4. Create VM port groups and VMkernel port groups for the required networks.
5. Set the correct VLAN ID on each port group.
6. Configure teaming, failover, security, and outbound traffic-shaping policies.
7. Create or assign VMkernel adapters for management, vMotion, storage, or Fault Tolerance logging.
8. Repeat the required design on each ESXi host that must provide equivalent connectivity.

Selected command-line examples are:

esxcli network vswitch standard list
esxcli network vswitch standard portgroup list
esxcli network vswitch standard add --vswitch-name=vSwitch1
esxcli network vswitch standard uplink add --uplink-name=vmnic1 --vswitch-name=vSwitch1
esxcli network vswitch standard portgroup add --portgroup-name=Production --vswitch-name=vSwitch1
esxcli network vswitch standard portgroup set --portgroup-name=Production --vlan-id=20

Command availability and exact options can vary by ESXi release. Verify syntax on the target host and test changes during an approved maintenance window.

Troubleshooting Standard-Switch Connectivity

VMs on the same VLAN cannot communicate across hosts

• Check that both port groups use the same VLAN ID.
• Verify that each host has a connected, usable vmnic uplink.
• Confirm physical cabling and the physical switch's access or trunk configuration.
• Compare teaming, failover, and uplink assignments on both hosts.

Local VMs communicate, but external systems are unreachable

• Confirm that an active uplink is attached to the vSwitch.
• Check the uplink link state and physical switch port assignment.
• Verify that the VM port group's VLAN is available on the physical network.

Management, vMotion, or storage VMkernel traffic fails

• Verify that the required VMkernel adapter exists and is attached to the correct port group.
• Confirm that the intended VMkernel service is enabled.
• Validate IP addressing, VLAN IDs, MTU, and routing where applicable from end to end.
• Check that the peer ESXi host has equivalent service-network connectivity.

Monitoring or an appliance cannot see expected frames

• Review promiscuous mode, MAC address changes, and forged-transmits settings.
• Check whether the workload is connected to the intended port group.
• Apply only the required exception to an isolated port group and avoid exposing unrelated production traffic.

Uplink redundancy does not work after a failure

• Confirm that the second uplink is active or standby rather than unused.
• Review failover detection and load-balancing settings.
• Test a controlled link failure.
• Verify that any physical-switch aggregation design matches the ESXi teaming method.

Key Exam and Design Notes

• A vSphere Standard Switch is a host-local virtual Ethernet switch.
• Its primary function is Layer 2 forwarding based on MAC addresses; it is not an IP router.
• VM port groups serve virtual machine adapters, while VMkernel port groups serve ESXi host services.
• Uplinks connect the virtual switch to the external physical network.
• Traffic between compatible local VMs can remain inside the ESXi host.
• Traffic between hosts normally crosses both hosts' uplinks and the physical network.
• VLAN configuration must match the physical switch's VLAN-carrying behavior.
• Active, standby, and unused uplink roles support teaming and failover designs.
• Promiscuous mode, MAC address changes, and forged transmits are security controls, not general-purpose performance settings.
• Standard-switch settings are maintained per host, so configuration drift is a major multi-host operational risk.
• Validate capacity limits against the Configuration Maximums for the installed ESXi release.

For related study, review the VMware ESXi online course, distributed switches, iSCSI configuration, NFS datastore configuration, and vSphere Fault Tolerance.