Lab: Deploy vDS & Configure NIC Teaming

VCF 9.0Intermediatevcp-foundation⏱ 90 min

Objectives

Lab: Deploy vDS & Configure NIC Teaming

Prerequisites

VCF lab environment deployed and operational

Lab Environment

Standard VCF lab environment for vSphere Foundation 9.0 Administrator

Tasks

Task 1 Lab: Deploy vDS & Configure NIC Teaming

VDS deployment and NIC teaming are foundational networking skills. Incorrect teaming policy causes network outages; incorrect VLAN trunking causes silent packet drops. Always verify connectivity after configuration changes.

Step 1

Create new vDS (6.7+ recommended): vCenter UI → Networking → New Distributed Switch

Step 2

Add all ESXi hosts to vDS (1-pass migration: create VM port group, migrate management vmk, then data vmks)

Step 3

Create port groups: Management, vMotion (TCP/IP Stack), vSAN (VLAN 100, MTU 9000)

Step 4

Configure NIC Teaming to "IP Hash" with LACP

Step 5

Verify on switch: LACP interface shows active state, etherchannel summary shows all links up

Step 6

Test: vmkping -I vmk_vsan_ip vsan_gateway_ip (should succeed with <2ms RTT)

Validation Gate

Check: After deploying VDS with two uplinks, verify: (a) both uplinks show 'Up' status, (b) VMkernel adapters are on correct port groups, (c) ping test succeeds on management, vMotion, and vSAN networks

Expected: All three network types respond to ping, both uplinks show connected, and teaming policy matches design specification

Common Errors

Selecting wrong NIC teaming policy for the traffic type

Fix: Route based on physical NIC load (default for VDS) distributes traffic dynamically. Route based on originating port pins each VM to a specific uplink — simpler but can create imbalance. Use load-based for vMotion/vSAN (high bandwidth); use originating port for management (predictable failover).

Not configuring failover order correctly for active/standby

Fix: Active uplinks carry traffic; standby activates only when all active uplinks fail. A common mistake: placing all NICs in active without understanding the load distribution implications, or placing the wrong NIC in standby (e.g., the 25GbE NIC as standby while the 10GbE is active).

Forgetting to migrate VMkernel adapters when switching from VSS to VDS

Fix: VMkernel adapters (management, vMotion, vSAN) must be migrated from VSS to VDS. If you delete the VSS first, you lose management connectivity to the host. Always migrate VMkernels to VDS first, verify connectivity, then remove VSS.

VLAN trunk not configured on physical switch port

Fix: VDS port groups with VLAN tags only work if the physical switch port is configured as a trunk carrying those VLANs. A VDS port group tagged VLAN 100 on an access port (VLAN 200) will drop all traffic. Verify physical switch configuration matches VDS VLAN assignments.

Final Validation

Lab completed successfully

✓ All steps completed → No errors observed

Cleanup / Restore

• Revert to snapshot if needed

Design Reflection (VCDX)

Network design is always challenged in VCDX defense. Panelists ask why you chose specific teaming policies, how you handle NIC failure, and what happens if a physical switch fails. Know your uplink mapping and failover behavior.

Requirements

Deploy VDS with appropriate teaming policy per traffic type
Configure VLAN trunking to match physical switch
Migrate VMkernel adapters from VSS to VDS without losing connectivity

Constraints

Physical switch must trunk the required VLANs
VSS to VDS migration must maintain management connectivity throughout

Assumptions

Physical NICs are correctly cabled to appropriate switch ports
MTU 9000 is configured end-to-end for vSAN and overlay traffic

Risks

Management network loss during VSS-to-VDS migration
Silent packet drops from VLAN mismatch between VDS and physical switch

⚠ Known Pitfalls (from Community KB)

Deleting VSS before migrating VMkernel adapters to VDS — this disconnects the host from vCenter.

Assuming VDS VLAN tagging works without verifying physical switch trunk configuration.

Mark complete