7.1 Standard Switches (vSS) vs Distributed Switches (vDS)

7.1 Standard Switches (vSS) vs Distributed Switches (vDS)

Virtual networking forms the foundational communication fabric in a VMware vSphere software-defined datacenter. It interconnects virtual machines with one another, connects ESXi hypervisor kernels to external shared storage arrays and clustered replication targets, and carries mission-critical hypervisor management and migration traffic. VMware vSphere Foundation 9.0 delivers two primary virtual switch architectures: the host-centric vSphere Standard Switch (vSS) and the cluster-wide vSphere Distributed Switch (vDS).

---

Virtual Networking Architecture: Decoupling Management and Data Planes

To understand virtual switching in vSphere, you must understand the architectural separation between the control and management plane and the data plane (forwarding plane).

1. The Data Plane (ESXi VMkernel)

The data plane is responsible for inspecting, forwarding, tagging, and switching Ethernet frames between virtual machine virtual network interface cards (vNICs), VMkernel network adapters (vmk), and physical network adapters (vmnics).

• In vSphere, the data plane never runs inside vCenter Server; it is implemented directly inside the ESXi VMkernel core.
• On every ESXi host connected to a vSphere Distributed Switch, the VMkernel instantiates a hidden, local host proxy switch. This proxy switch maintains a cached copy of the switch's forwarding tables, port assignments, and security policies.
• Because the data plane runs locally within the VMkernel, forwarding stays local to the host; actual performance depends on traffic and configuration.

2. The Management Plane (vCenter Server)

The management plane provides the administrative interface used to create, configure, modify, and monitor virtual switching constructs. For a vSphere Distributed Switch, vCenter Server acts as the centralized management authority. Network configurations created in vCenter are automatically serialized and pushed down to the host proxy switches across all participating ESXi hosts.

3. Survivability During vCenter Server Outages

A vital architectural principle frequently tested on the 2V0-16.25 exam is data plane survivability:

• If the vCenter Server Appliance (VCSA) crashes, powers down, or experiences network isolation, virtual machine and VMkernel packet forwarding is completely unaffected.
• The local host proxy switches continue forwarding packets, performing Layer 2 forwarding, enforcing VLAN tagging, executing teaming failover, and honoring traffic shaping policies using their cached local configuration state.
• The only operational impact during a vCenter outage is to the management plane: administrators cannot create new distributed port groups, edit existing port policies, or migrate new virtual machines to different distributed ports until vCenter Server is restored.

---

vSphere Standard Switch (vSS) Architecture & Limitations

A vSphere Standard Switch (vSS) is a software-based Layer 2 virtual switch that exists exclusively within the memory space of a single, individual ESXi host.

Core Characteristics of vSS

• Host-Local Configuration: A standard switch is configured and managed on a per-host basis. If a cluster contains 32 ESXi hosts, an administrator using standard switches must manually configure 32 separate virtual switches and create identical port groups on every single host.

• Configuration Drift Risk: Because each vSS is an independent entity, any typo in a port group name (for example, naming a port group Production_VLAN10 on Host 1 and Production-VLAN10 on Host 2) will cause vSphere vMotion migrations to fail, because automatic network matching can fail; verify the destination mapping and VLAN connectivity rather than relying on display names alone.

• Scalability: Check current configuration maximums for host and switch capacity. The limits of different virtual-switch objects are not interchangeable.

• Modern Role: While enterprise clusters standardize on vSphere Distributed Switches, the vSphere Standard Switch remains essential during initial ESXi bootstrap deployment, Disaster Recovery scenarios, and standalone host operations where vCenter Server is not available.

---

vSphere Distributed Switch (vDS) Architecture & Centralized Management

A vSphere Distributed Switch (vDS) extends virtual switching across an entire vCenter datacenter or cluster, acting as a single, unified logical switch spanning dozens or hundreds of ESXi hosts.

1. Distributed Port Groups (dvPortGroups)

Instead of creating local port groups on individual hosts, administrators configure Distributed Port Groups on the vDS. A distributed port group defines uniform network properties—such as VLAN IDs, teaming and failover rules, security policies, and traffic shaping parameters—that are automatically propagated and enforced across every ESXi host connected to that switch.

2. Port Binding Modes on vDS

When a virtual machine network adapter (vNIC) connects to a distributed port group, the vDS assigns it a specific virtual port based on the configured port binding mode:

• Static Binding (Default & Recommended): A virtual switch port is assigned to the VM's vNIC at the moment the VM is connected to the port group or powered on. Once assigned, the port reservation persists across VM power cycles and host reboots. Static binding ensures predictable port allocation and enables full vSphere resource management.
• Ephemeral Binding ("No Binding"): Virtual ports are allocated on demand when the virtual machine powers on and are immediately released when the VM powers off. In ephemeral mode, the local ESXi host daemon (hostd) can allocate ports directly from the local host proxy switch without requiring an active connection to vCenter Server. For this reason, creating an ephemeral distributed port group is a VMware architectural best practice for hosting the vCenter Server Appliance (VCSA) itself, providing an option to recover connectivity directly through the ESXi Host Client if vCenter is offline.

---

Comprehensive Comparison: vSS vs. vDS

---

Advanced Switching Capabilities Exclusive to vDS

Deploying a vSphere Distributed Switch unlocks enterprise-grade traffic governance, observability, and security features that are entirely absent in standard switches.

1. Link Aggregation Control Protocol (LACP)

While a vSS supports only unnegotiated static multi-NIC EtherChannel, a vDS supports industry-standard Dynamic LACP (IEEE 802.3ad). LACP dynamically negotiates link bundling between ESXi host physical adapters and upstream physical switches via Link Aggregation Groups (LAGs). Validate the supported LAG count, host member count and hash choices for the actual switch version. Dynamic LACP requires compatible configuration at both ends.

2. Network I/O Control (NIOC v3)

NIOC v3 allows administrators to segment physical uplink bandwidth and guarantee quality of service (QoS) across competing traffic streams (vSAN, vMotion, Management, and virtual machines). It enforces strict bandwidth reservations, limits, and proportional shares.

3. Enterprise Port Mirroring & Flow Observability

For network troubleshooting, intrusion detection, and performance telemetry, the vDS supports advanced traffic diagnostics:

• Local Port Mirroring (SPAN): Copies packets from source virtual ports or uplinks to a destination virtual port on the same host.
• Remote Port Mirroring (RSPAN): Encapsulates mirrored traffic into a dedicated RSPAN VLAN and floods it across the physical network to a remote analyzer.
• Encapsulated Remote Port Mirroring (ERSPAN): Encapsulates mirrored packets into Generic Routing Encapsulation (GRE) Layer 3 packets (IP protocol 47). This allows network administrators to route mirrored traffic across routable enterprise subnets to a centralized packet analyzer located anywhere in the enterprise.
• NetFlow / IPFIX (RFC 5101): Monitors IP traffic flows traversing the vDS and exports flow records to external NetFlow collector appliances for capacity planning and security surveillance.

4. Private VLANs (PVLANs)

Traditional VLANs partition a physical switch into distinct broadcast domains (VLAN IDs 1–4094), requiring a Layer 3 router to move packets between them. In high-density environments (such as DMZs, multi-tenant hosting, and cloud infrastructure), assigning a unique subnet and VLAN to every tenant rapidly exhausts VLAN IDs and IP address space. Private VLANs (PVLANs) solve this by sub-dividing a single Primary VLAN into secondary broadcast domains while preserving a single IP subnet.

A Private VLAN configuration consists of a Primary VLAN and three distinct port types:

• Promiscuous Port (Primary VLAN): Connects to upstream default gateways, firewalls, and monitoring tools. A promiscuous port can communicate with all ports in the primary VLAN and all associated secondary VLANs.
• Community Port (Secondary VLAN): Connects to servers that must communicate with one another and with the default gateway, but must be isolated from the rest of the network. For example, database cluster nodes within the same application tier can talk to each other and the gateway, but cannot communicate with other communities.
• Isolated Port (Secondary VLAN): Enforces complete Layer 2 isolation. Ports in an isolated VLAN can communicate only with promiscuous ports. They are completely blocked from communicating with sibling ports inside the exact same isolated VLAN. This design is standard for multi-tenant DMZs where untrusted web servers share an IP subnet but must not see or attack each other.

PVLAN Communication Matrix

---

Migration from vSS to vDS: Non-Disruptive Workflows & Safeguards

Transitioning production ESXi hosts from host-local standard switches to a centralized distributed switch is a common administrative task on the 2V0-16.25 exam. When planned correctly, this migration is executed with a planned migration with validation of connectivity and application behavior.

The Non-Disruptive Migration Workflow

1. Pre-requisite Verification: Create the vSphere Distributed Switch in vCenter Server. Configure distributed port groups with identical VLAN IDs, MTU values, and security policies matching the existing standard switch port groups.
2. Initiate Migration Wizard: In the vSphere Client, navigate to the vDS, right-click, and select Add and Manage Hosts > Manage host networking.
3. Select Participating Hosts: Choose the target ESXi hosts in the cluster.
4. Migrate Physical Adapters (vmnics): In hosts with dual redundant uplinks (e.g., vmnic0 and vmnic1), unassign one physical NIC (e.g., vmnic1) from the vSS and assign it to an uplink port on the vDS. The host remains reachable through vmnic0 on the vSS.
5. Migrate VMkernel Adapters: Map the host VMkernel network adapters (such as vmk0 Management, vmk1 vMotion) from the vSS port groups to the corresponding distributed port groups.
6. Migrate Virtual Machine Networking: Reassign virtual machine vNICs from the legacy vSS port groups to the new dvPortGroups. vSphere transfers network state instantaneously with a brief transition that should be validated.
7. Migrate Remaining Physical Adapter: Once all VMkernel and VM traffic is verified traversing the vDS over vmnic1, migrate the remaining physical NIC (vmnic0) from the standard switch to the vDS. Both physical uplinks now form a redundant team on the vDS.
8. Clean Up Legacy vSS: Delete the empty, unbacked vSphere Standard Switch instances from the hosts.

Automated Network Rollback & Recovery Mechanics

A primary administrative fear during network migration is severing management connectivity (vmk0), leaving the ESXi host orphaned and disconnected from vCenter Server. vSphere incorporates an automated Network Rollback safety mechanism:

• When a network configuration change is initiated on an ESXi host, the VMkernel starts a rollback validation.
• If the host loses management connectivity to vCenter Server as a result of the change (for example, due to an invalid VLAN tag or mismatched uplink assignment), the VMkernel automatically aborts the operation, rolls back the network state to the previous working configuration, and restores connectivity.
• If an administrator ever experiences a complete, unrecoverable disconnect, management networking can be manually restored to a standard switch using the ESXi Direct Console User Interface (DCUI) under Network Restore Options > Restore Standard Switch.

Official Reading

Use the official 2V0-16.25 objective guide for scope and Broadcom technical documentation for the installed 9.0 component. This independent lesson was reviewed October 18, 2026; actual deployment support depends on the applicable version and configuration.

Review Takeaways

• A standard switch is configured per host; a distributed switch centralizes configuration across participating hosts.
• Existing forwarding on healthy hosts continues from local state when vCenter is unavailable.
• vDS features include LACP, NIOC, port mirroring, flow export and private VLANs.
• Migrate uplinks and VMkernel networking in stages and keep a tested recovery option.