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.Ping the gateway. On top of that, except the ping fails. Add a vSwitch. Still, assign a VMkernel adapter. Create a port group. Day to day, or the VMs can't see each other. 2 — configure and test VM networking — is one of those exercises that looks straightforward on paper. Now, done. 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.

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. You're running ESXi inside a VM. On the flip side, that adds a layer — your physical host's network, the virtualization software's virtual switches, then the ESXi vSwitch. Three layers where things can break Not complicated — just consistent..

The Core Components You'll Build

That's the map. Now let's talk about why the territory eats people alive.

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. On top of that, the link light always shows green. That's why the ESXi host thinks it's connected. The VM thinks it's connected. But traffic never leaves the host application.

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 That alone is useful..

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) The details matter here..

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.In practice, ) must pass those VLANs. Workstation's default vmnet0 is bridged to your physical NIC — but does your physical switch port allow VLANs 10 and 20? If not, tagged frames get dropped before they reach ESXi.

The official docs gloss over this. That's a mistake.

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. vmnic1 maps to the second. If you added them in the wrong order — or added a third NIC later — the mapping shifts.

Short version: it depends. Long version — keep reading.

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. 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.

3. Create Port Groups with Intent

Each port group is a broadcast domain. Treat it like a physical VLAN interface.

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 Still holds up..

Each service gets its own adapter. Because of that, 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).

• IPv4: Separate storage subnet
• **Services: Uncheck Management. Here's the thing — check nothing else. Worth adding: ** Storage traffic does not need the Management service enabled. Think about it: - **MTU: 9000 (Jumbo Frames). ** Set this here and on the physical switch ports, the VMkernel adapter, and the array target. One mismatch fragments packets and kills throughput silently.

Not obvious, but once you see it — you'll see it everywhere.

5. Bind iSCSI — The Step Everyone Forgets

Creating the VMkernel adapters isn't enough. You must bind them to the iSCSI Software Adapter Less friction, more output..

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). Here's the thing — it picks one path and stays there until failure. That wastes your second 10GbE link Worth knowing..

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 Easy to understand, harder to ignore..

If you followed Section 4: Networking → VMkernel NICs → Edit each → Traffic Filtering / System Traffic And that's really what it comes down to. Less friction, more output..

• Ensure vMotion is only on vmk1. On the flip side, - Ensure Management is only on vmk0. - 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 Most people skip this — try not to..

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 Small thing, real impact..

Treat every vNIC in the nested VM as a physical cable. Map them. Label them. Enforce Jumbo Frames end-to-end. Still, bind storage adapters explicitly. Force Round Robin multipathing Still holds up..

traffic religiously. Validate with vmkping and esxcli until the output is boringly perfect.

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.