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

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

Virtual networking forms the foundational communication fabric of a VMware vSphere software-defined data center. Understanding how virtual switches emulate Layer-2 physical switches while enforcing distinct virtualization-specific forwarding and loop-prevention rules is critical for administering production environments and passing the VCP-DCV exam.

---

Virtual Switch Networking Fundamentals

A vSphere virtual switch operates as a software-based Layer-2 Ethernet switch residing within the ESXi VMkernel. While it shares many functional attributes with physical access switches—such as frame forwarding, MAC address learning, and VLAN encapsulation—its architectural implementation eliminates several classical networking complexities.

Layer-2 Forwarding & MAC Address Tables

In a traditional physical Ethernet network, switches continuously inspect the source MAC address of incoming frames on physical ports, populate a dynamic Content Addressable Memory (CAM) table, and broadcast unknown unicast frames out all ports on the same VLAN (flooding).

An ESXi virtual switch behaves differently:

• Deterministic MAC Mapping: The virtual switch knows the MAC address of every connected virtual network adapter (vNIC) and VMkernel port (vmk) the instant the interface connects or powers on. Because the VMkernel assigns or registers these MAC addresses directly into the switch port table, the virtual switch never floods unknown unicast frames out across virtual ports.
• Outbound Frame Inspection: For outbound frames originating from a virtual machine, the virtual switch forwards the frame directly to the designated physical network interface card (uplink/vmnic) assigned to that port group.
• Inbound Frame Forwarding: For inbound frames arriving from the external physical network via a physical uplink, the virtual switch inspects the destination MAC address. If the destination MAC matches an active virtual network adapter registered on that local virtual switch, the frame is delivered directly to that virtual port. If the destination MAC is not registered on the virtual switch, the frame is immediately dropped.

Absence of Spanning Tree Protocol (STP) & Loop Prevention

One of the most heavily tested architectural concepts on the VCP-DCV exam is the handling of Spanning Tree Protocol (STP) on ESXi virtual switches:

Core Rule: ESXi virtual switches (both vSS and vDS) do not run Spanning Tree Protocol (IEEE 802.1D / 802.1w / 802.1s). They do not generate, process, or participate in Spanning Tree Bridge Protocol Data Units (BPDUs).

In a physical network, redundant links between switches create Layer-2 bridging loops that can trigger devastating broadcast storms. Physical switches rely on STP to block redundant links. Virtual switches prevent loops through architectural design rather than STP:

1. No Inter-Switch Links (ISLs): Virtual switches cannot be connected to other virtual switches within the same or different ESXi hosts. A virtual switch cannot bridge traffic to another virtual switch.
2. Split-Horizon Forwarding (Uplink Isolation): An ESXi virtual switch will never forward a packet received on one physical uplink (vmnic) back out of another physical uplink. Uplinks function purely as edge ports connecting the virtual domain to the physical domain. Because a frame can never transit through an ESXi virtual switch from physical switch port A to physical switch port B, the virtual switch can never form a Layer-2 loop in the physical network.
3. BPDU Handling: Virtual switches never compute spanning-tree path costs. If a guest (for example a VM bridging two vNICs) sends BPDUs, a physical switch port with BPDU Guard may shut down the uplink. Enabling the host advanced setting Net.BlockGuestBPDU (the BPDU filter) drops BPDUs sent by guests.

Uplinks, VMkernel Ports, and VM Port Groups

A virtual switch connects three distinct network entities:

• Physical Uplinks (vmnic): Physical network adapters installed in the ESXi host (e.g., vmnic0, vmnic1). Uplinks bridge the software switch to top-of-rack (ToR) physical switches.
• VMkernel Adapters (vmk): Specialized virtual network interfaces that terminate IP endpoints for ESXi host-level services. Each VMkernel adapter requires an IP address, subnet mask, MTU, and association with a specific TCP/IP stack. Core services running over VMkernel adapters include:
  • Management Network (vmk0 by default): Facilitates host communication with vCenter Server, ESXi Host Client, SSH, and remote APIs.
  • vSphere vMotion: Carries live virtual machine memory, state, and checkpoint data between hosts.
  • vSAN: Carries distributed storage clustering, synchronization, and I/O traffic.
  • iSCSI / NFS: Transports block-level or file-level IP storage traffic to external storage arrays.
  • Fault Tolerance (FT) Logging: Synchronizes execution state between primary and secondary FT virtual machines.
  • vSphere Replication: Carries replicated block changes to a secondary site.
• Virtual Machine Port Groups: Logical aggregation points that define Layer-2 network policies (VLAN tagging, NIC teaming, traffic shaping, and security policies) for virtual machine vNICs (such as VMXNET3 or E1000E adapters).

---

vSphere Standard Switch (vSS) Architecture

A vSphere Standard Switch (vSS) is a host-local Layer-2 virtual switch. Its configuration, lifecycle, and operational state reside exclusively within the configuration files and memory of an individual ESXi host.

Key Operational Characteristics

• Host-Bound Management: A vSS is managed on a per-host basis. If an administrator creates a standard switch named vSwitch0 with a port group named Production-VLAN10 on Host A, that configuration exists only on Host A. To maintain a consistent cluster, the administrator must manually recreate identical configurations on Host B, Host C, and every other host.
• Risk of Configuration Drift: Because there is no centralized synchronization, discrepancies inevitably emerge. A typographical error in a port group name (e.g., Production-VLAN10 vs production-vlan10 or Production_VLAN10) will cause vSphere vMotion to fail, as vCenter verifies that the target host possesses a port group with the exact, case-sensitive name of the source network.
• Port Scalability: A standard switch can have up to 4,088 ports, and a host supports 4,096 virtual switch ports in total across all its switches. None of that configuration is shared with other hosts.

---

vSphere Distributed Switch (vDS) Architecture

A vSphere Distributed Switch (vDS) acts as a single, centralized virtual switch spanning across multiple ESXi hosts in a vCenter Server datacenter or cluster (up to 2,000 ESXi hosts per vDS). It abstracts host-level virtual networking into a unified datacenter-wide construct.

Separation of Management and Data Planes

The fundamental architectural breakthrough of the vDS is the strict decoupling of the control/management plane from the data plane:

+-------------------------------------------------------------------------+
|                        vCenter Server (vDS Management Plane)            |
| - Distributed Switch configuration, Port Groups, Policies, NIOC v3      |
| - Centralized provisioning, backup/restore, monitoring, IPFIX           |
+-------------------------------------------------------------------------+
                                     | Synchronizes state
         +---------------------------+---------------------------+
         |                                                       |
         v                                                       v
+-----------------------------------+   +-----------------------------------+
|       ESXi Host 1 (Data Plane)    |   |       ESXi Host 2 (Data Plane)    |
| +-------------------------------+ |   | +-------------------------------+ | 
| | Host Proxy Switch (HPS)       | |   | | Host Proxy Switch (HPS)       | | 
| | - Local packet forwarding     | |   | | - Local packet forwarding     | | 
| | - Active port table cache     | |   | | - Active port table cache     | | 
| | - Line-rate packet processing | |   | | - Line-rate packet processing | | 
| +-------------------------------+ |   | +-------------------------------+ | 
|   vmk0  vmk1  [VMs]   vmnic0/1    |   |   vmk0  vmk1  [VMs]   vmnic0/1    |
+-----------------------------------+   +-----------------------------------+

1. Management Plane (vCenter Server): The creation, configuration, policy definition, and lifecycle of the vDS occur entirely within vCenter Server. All distributed port group settings, VLAN IDs, teaming rules, and traffic shaping policies are stored in the vCenter database and pushed to ESXi hosts.
2. Data Plane (Host Proxy Switch - HPS): When an ESXi host is joined to a vDS, the VMkernel instantiates a local Host Proxy Switch (HPS). The HPS reads the switch specification from vCenter and maintains a local runtime cache of all ports, MAC tables, and security policies.

Critical vCenter Outage Behavior

A critical exam scenario tests what happens when vCenter Server experiences an outage:

• Traffic Continuity: If vCenter Server crashes, is shut down, or loses network connectivity, all data-plane network traffic continues without interruption. VMs continue communicating, storage traffic flows, and existing port forwarding remains fully functional because the local Host Proxy Switch processes packets independently.
• Management Limitations During Outage: While vCenter is offline, administrators cannot create new distributed port groups, modify switch policies, or assign VMs to distributed port groups with static binding.

Features Exclusive to Distributed Switches

The following advanced networking features require a vSphere Distributed Switch (and vSphere Enterprise Plus licensing):

• Network I/O Control (NIOC v3): Cluster-wide bandwidth reservation and share allocation for system traffic types and VM resource pools.
• Link Aggregation Control Protocol (LACP): Dynamic negotiation of multi-port physical link aggregation (IEEE 802.3ad).
• Route Based on Physical NIC Load (Load-Based Teaming - LBT): Automatic rebalancing of VM uplinks when link utilization exceeds 75%.
• Port Mirroring: SPAN, Remote SPAN (RSPAN), and Encapsulated Remote SPAN (ERSPAN) for packet inspection.
• NetFlow / IPFIX: Flow-level monitoring exported to external network collectors.
• Traffic Filtering and Marking: QoS classification, DSCP/802.1p tagging, and access control lists (ACLs).
• Centralized Switch Configuration Backup & Restore: Exporting the switch and port group configuration to a .zip file, then restoring it or importing it to create a new switch.
• MAC Learning Policy: Dynamic MAC learning and aging on virtual ports (essential for nested virtualization and container overlay networks).

---

Port Group Binding Types

When creating a port group on a vSphere Distributed Switch, the administrator must configure the Port Binding mode, which dictates how and when virtual switch ports are allocated to virtual machines.

Exam Trap: If the vCenter Server Appliance (vCSA) itself is hosted on a vDS distributed port group configured with Static Binding, and the ESXi host hosting the vCSA crashes, an administrator cannot easily power on or reassign the vCSA on an alternate host using the standalone ESXi Host Client because vCenter is offline and cannot allocate a static port! To avoid this catch-22, VMware best practice dictates placing the vCSA on a distributed port group with Ephemeral Binding or on a dedicated vSS.

---

Migration Workflow: vSS to vDS

Migrating production ESXi hosts from standard switches to a distributed switch must be performed without dropping active management sessions, storage I/O, or VM connectivity. vSphere provides the Add and Manage Hosts wizard in vCenter to execute non-disruptive phased migrations.

Step-by-Step Migration Procedure

Phase 1: Existing vSS Topology
[ vSS: vSwitch0 ] <---> vmnic0 (Active) & vmnic1 (Active)
                  <---> vmk0 (Management Network)
                  <---> Production-VMs

Phase 2: Split Uplinks & Add Host to vDS
[ vSS: vSwitch0 ] <---> vmnic0 (Active) <---> vmk0 & Production-VMs
[ vDS: DSwitch0 ] <---> vmnic1 (Uplink 2) <---> [Ready for migration]

Phase 3: Migrate VMkernel Adapters & Virtual Machines
[ vSS: vSwitch0 ] <---> vmnic0 (Active)
[ vDS: DSwitch0 ] <---> vmnic1 (Uplink 2) <---> vmk0 (Migrated) & Production-VMs (Migrated)

Phase 4: Finalize Uplinks & Decommission vSS
[ vDS: DSwitch0 ] <---> vmnic0 (Uplink 1) & vmnic1 (Uplink 2)
                  <---> vmk0 (Management) & Production-VMs
[ vSS: vSwitch0 ] ---> (No uplinks, No port groups) ---> Deleted

1. Create the Distributed Switch: Define the vDS, specify the target vSphere distributed switch version (e.g., 8.0.0), configure the number of uplinks, and create the required distributed port groups matching existing VLANs.
2. Split Physical Uplinks: In a host with redundant physical adapters (e.g., vmnic0 and vmnic1 active on vSwitch0), remove vmnic1 from vSwitch0 and assign it as an uplink (e.g., Uplink 2) on the vDS. vmnic0 remains active on the vSS to maintain management connectivity.
3. Migrate VMkernel Adapters: Using the "Manage Host Networking" wizard, migrate vmk0 (Management) and any other VMkernel adapters (vMotion, vSAN, iSCSI) from the standard port groups to the corresponding distributed port groups.
4. Migrate Virtual Machine Networking: Migrate virtual machine network adapters from standard port groups to distributed port groups. This can be performed per host, per network, or cluster-wide using the "Migrate VM storage and networking" wizard.
5. Migrate Remaining Uplink: Once all VMkernel adapters and VMs have evacuated the vSS, reassign vmnic0 from vSwitch0 to the vDS as Uplink 1.
6. Delete Empty Standard Switch: With zero active uplinks, VMkernel ports, and VMs remaining, the legacy vSwitch0 can be cleanly removed.

Automated Network Rollback & Recovery

To prevent administrators from inadvertently severing their own management access during network migration, vSphere includes an automated safety mechanism:

• Rollback Heartbeat: Whenever an administrator commits a network configuration change affecting management VMkernel adapter (vmk0) connectivity, the ESXi host initiates a rollback timer.
• Automatic Rollback: If the host loses contact with vCenter Server for more than 30 seconds, the host VMkernel immediately aborts the configuration change and rolls back its local network state to the previous working configuration.
• Direct Console User Interface (DCUI) Recovery: If a catastrophic misconfiguration bypasses rollback (e.g., misconfigured VLAN on an upstream physical switch port), an administrator can access the physical host console, enter the DCUI, navigate to Network Restore Options, and select Restore Standard Switch to recreate a default vSwitch0 with vmk0 connected to an active physical adapter.

Creating, Joining, and Examining a vDS (Objectives 4.2.1-4.2.3)

Create a Distributed Switch (4.2.1)

In the Networking view, right-click the data center and choose Distributed Switch > New Distributed Switch:

1. Name the switch.
2. Choose the version (for example 8.0.0). Hosts must run that ESXi version or later to join, and the version enables features such as network offloads for DPUs.
3. Set the number of uplinks (default 4), Network I/O Control (enabled by default unless you pick a DPU offload option), and optionally create a default port group.

Add ESXi Hosts (4.2.2)

Right-click the switch and choose Add and Manage Hosts > Add hosts. Then:

• select the hosts,
• assign physical adapters (vmnics) to the switch's uplinks, for example vmnic0 to Uplink 1 and vmnic1 to Uplink 2,
• optionally migrate VMkernel adapters and VM networking to distributed port groups, which is the non-disruptive migration described above.

Examine the Configuration (4.2.3)

Use Export Configuration (on the Settings menu) before large changes so you can restore the switch or its port groups.