Simulation Lab 7.2: Module 07 Configure And Test Vm Networking

You've stared at the lab instructions for twenty minutes. The PDF is open on one monitor, your hypervisor on the other, and nothing is pinging. Again.

Sound familiar?

Module 07, Lab 7.On top of that, 2 — configure and test VM networking — is one of those exercises that looks straightforward on paper. Add a vSwitch. Here's the thing — create a port group. Assign a VMkernel adapter. Ping the gateway. In practice, done. Except the ping fails. On top of that, or the VMs can't see each other. Or the management network drops halfway through.

I've watched students (and honestly, done it myself) burn hours on this lab because they skipped the "why" and jumped straight to the "click here, type that." This guide walks through the whole thing — what's actually happening, where it goes wrong, and how to verify each step before you move to the next.

What Is Simulation Lab 7.2

This lab sits in the virtualization networking module of most infrastructure curricula — think VMware vSphere ICM, Cisco DCACI, or similar vendor-agnostic programs. The goal: build a functional virtual network from scratch inside a nested ESXi environment, then prove it works.

Most guides skip this. Don't.

You're typically given:

• A nested ESXi host (running inside Workstation, Fusion, or a cloud lab platform)
• One or two VMs deployed on that host
• A set of requirements: management network, VM network, maybe a vMotion or iSCSI network
• A validation checklist: ping, SSH, vCenter connectivity, VM-to-VM traffic

The "simulation" part means you're not on bare metal. Which means that adds a layer — your physical host's network, the virtualization software's virtual switches, then the ESXi vSwitch. You're running ESXi inside a VM. Three layers where things can break The details matter here..

The Core Components You'll Build

That's the map. Now let's talk about why the territory eats people alive And that's really what it comes down to..

Why This Lab Matters (And Why It Frustrates Everyone)

Virtual networking isn't "just like physical networking but virtual." It looks like it — same terms, same VLANs, same IP schemes — but the failure modes are different.

In a physical rack, if a cable's unplugged, the link light goes off. In a nested lab, the "cable" is a virtual NIC setting in VMware Workstation or VirtualBox. The link light always shows green. In real terms, the ESXi host thinks it's connected. The VM thinks it's connected. But traffic never leaves the host application Easy to understand, harder to ignore..

That's the trap.

This lab forces you to understand:

• How vSwitches actually forward frames (hint: it's not magic, it's MAC learning)
• Why VLAN tagging at the port group level ≠ tagging at the physical switch level
• How VMkernel interfaces differ from VM network interfaces
• What "promiscuous mode" and "forged transmits" actually do — and why the lab often requires them

Skip the concepts, and you'll pass the lab by luck. Change one setting later, and the whole thing collapses.

How It Works: Step-by-Step Walkthrough

1. Verify the Physical Layer First

Before you touch ESXi, check the outer layer. Your nested ESXi VM has virtual NICs. In Workstation/Fusion, each vNIC maps to a network adapter setting: Bridged, NAT, Host-Only, or Custom (vmnetX) Not complicated — just consistent..

Most lab failures start here.

If the lab says "Management Network on VLAN 10, VM Network on VLAN 20," your physical host's virtual switch (vmnet0, vmnet1, etc.On the flip side, workstation's default vmnet0 is bridged to your physical NIC — but does your physical switch port allow VLANs 10 and 20? ) must pass those VLANs. If not, tagged frames get dropped before they reach ESXi.

Fix: Use a custom vmnet (say, vmnet2) in "Host-Only" mode for the lab. Then configure VLAN tagging inside ESXi only. The outer layer just passes Ethernet frames. Let ESXi do the VLAN work.

2. Build the vSwitch — Don't Rush the Uplink

Log into the ESXi DCUI or Host Client. Go to Networking → Virtual Switches → Add Standard Virtual Switch.

Name it vSwitch0 (or whatever the lab specifies). Here's where people click "Add Uplink" and pick vmnic0 without thinking.

Pause.

In a nested ESXi, vmnic0 maps to the first virtual NIC you added to the ESXi VM in Workstation. Worth adding: vmnic1 maps to the second. If you added them in the wrong order — or added a third NIC later — the mapping shifts The details matter here..

Not the most exciting part, but easily the most useful.

Verify: Run esxcli network nic list via SSH. Match the MAC addresses to the vNICs in your hypervisor. Label them in your notes. "vmnic0 = vmnet2 (Management), vmnic1 = vmnet3 (VM Traffic)."

Now add the uplink. Think about it: enable Promiscuous Mode: Accept and Forged Transmits: Accept on the vSwitch or the port groups (lab will specify). These allow the nested ESXi to see traffic not destined for its own MAC — critical when VMs inside ESXi talk to each other or to the outside world Still holds up..

The official docs gloss over this. That's a mistake And that's really what it comes down to..

3. Create Port Groups with Intent

Each port group is a broadcast domain. Treat it like a physical VLAN interface The details matter here..

Management Network port group:

• Name: Management Network (or per lab spec)
• VLAN ID: 0 (untagged) or specific VLAN per lab
• vSwitch: vSwitch0
• Security: Promiscuous Mode / Forged Transmits / MAC Changes — usually "Accept" for nested labs

VM Network port group:

• Name: VM Network
• VLAN ID: 20 (example)
• Same vSwitch
• Same security overrides

vMotion port group (if required):

• Name: vMotion
• VLAN ID: 30
• Critical: Check "vMotion traffic" checkbox in the port group settings. This enables the VMkernel adapter for vMotion later.

iSCSI / NFS port groups:

• Separate port groups, separate VLANs
• Enable "Management traffic" only if explicitly told — otherwise keep them isolated

4. Add VMkernel Adapters — One Per Service

Go to Networking → VMkernel NICs → Add VMkernel NIC.

Each service gets its own adapter. That said, don't pile Management + vMotion + iSCSI on one vmk0. It works until it doesn't — troubleshooting becomes a nightmare.

Management VMkernel (vmk0 usually):

• Port group: Management Network
• IPv4: Static IP per lab spec
• Gateway: Lab gateway
• DNS: Lab DNS
• Services: Check "Management" only

vMotion VMkernel (vmk1):

• Port group: vMotion
• IPv4: Different subnet usually
• Services: Check "vMotion" only

iSCSI VMkernel (vmk2):

• Port group: iSCSI-A (and iSCSI-B on second vSwitch

second vSwitch for multipathing). Think about it: ** Set this here and on the physical switch ports, the VMkernel adapter, and the array target. ** Storage traffic does not need the Management service enabled. Worth adding: - IPv4: Separate storage subnet

• **Services: Uncheck Management. In practice, - **MTU: 9000 (Jumbo Frames). Consider this: check nothing else. One mismatch fragments packets and kills throughput silently.

5. Bind iSCSI — The Step Everyone Forgets

Creating the VMkernel adapters isn't enough. You must bind them to the iSCSI Software Adapter Simple, but easy to overlook..

1. Storage → Adapters → iSCSI Software Adapter → Configure → Network Port Binding.
2. Add vmk2 (and vmk3 if you built the second path).
3. Dynamic Discovery tab → Add the array Target IP.
4. Static Discovery (optional but preferred for control) → Add Target IQN + IP.

Verify: Run esxcli iscsi session list. You should see two sessions (one per vmk) for the same target if multipathing is working. If you see one, check your binding order and switch uplinks.

6. Set Multipathing Policy — Round Robin or Bust

Default is Fixed (VMware). It picks one path and stays there until failure. That wastes your second 10GbE link.

Change it:

• Storage → Adapters → iSCSI Software Adapter → Devices (tab at bottom).
• Select the datastore LUN → Edit Multipathing.
• Policy: Round Robin (VMware).
• Path Selection: "Rotate every 1 MB" (default) is fine for most labs. For heavy sequential workloads, drop to 128 KB.

Confirm esxcli storage nmp device list -d <naa.id> shows Path Selection Policy: VMW_PSP_RR and both paths show Active (I/O).

7. Tag Traffic — Don't Let vMotion Steal Management Bandwidth

If you skipped separate port groups and dumped everything on vmk0, skip this. You’ve already lost.

If you followed Section 4: Networking → VMkernel NICs → Edit each → Traffic Filtering / System Traffic. Also, - Ensure Management is only on vmk0. - Ensure vMotion is only on vmk1.

• Ensure Provisioning (NFC/clone traffic) is tagged explicitly if you created a separate vmk for it — otherwise it rides vMotion or Management.

This prevents a 50 GB VM migration from starving the hostd heartbeat that keeps vCenter happy.

8. Validate Before You Build VMs

Run the gauntlet now, not when a VM won't deploy.

Fix red flags before you click "New Virtual Machine."

Conclusion

Nested ESXi networking isn't magic — it's just Layer 2 and Layer 3 with extra abstraction layers that punish assumptions. The hypervisor (Workstation/Fusion) hands you virtual wires; ESXi expects you to terminate them correctly into vSwitches, port groups, and VMkernel interfaces with deliberate intent And it works..

This is the bit that actually matters in practice Worth keeping that in mind..

Treat every vNIC in the nested VM as a physical cable. Now, label them. Map them. Enforce Jumbo Frames end-to-end. Bind storage adapters explicitly. Force Round Robin multipathing No workaround needed..

traffic religiously. Validate with vmkping and esxcli until the output is boringly perfect And that's really what it comes down to..

Do the work once at the infrastructure layer, and every nested cluster, vSAN datastore, and NSX segment you stack on top inherits a foundation that doesn't flinch under load. Skip it, and you'll be debugging "slow VMs" that are actually congested uplinks, asymmetric paths, or MTU black holes — problems that masquerade as application bugs but live in the plumbing.

Your nested lab is only as reliable as the virtual wires holding it together. Wire it like you mean it.