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 Most people skip this — try not to..

Sound familiar?

Module 07, Lab 7.So 2 — configure and test VM networking — is one of those exercises that looks straightforward on paper. Add a vSwitch. Because of that, create a port group. Assign a VMkernel adapter. Now, ping the gateway. Done. Except the ping fails. Or the VMs can't see each other. Or the management network drops halfway through But it adds up..

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 And it works..

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

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

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 No workaround needed..

In a physical rack, if a cable's unplugged, the link light goes off. Think about it: the link light always shows green. The VM thinks it's connected. In a nested lab, the "cable" is a virtual NIC setting in VMware Workstation or VirtualBox. The ESXi host 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

Counterintuitive, but true Simple, but easy to overlook..

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

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.Practically speaking, ) 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 Surprisingly effective..

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

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.

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.

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

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). Consider this: - IPv4: Separate storage subnet

• **Services: Uncheck Management. Also, check nothing else. On the flip side, ** Storage traffic does not need the Management service enabled. - **MTU: 9000 (Jumbo Frames).Day to day, ** Set this here and on the physical switch ports, the VMkernel adapter, and the array target. One mismatch fragments packets and kills throughput silently.

This changes depending on context. Keep that in mind.

5. Bind iSCSI — The Step Everyone Forgets

Creating the VMkernel adapters isn't enough. You must bind them to the iSCSI Software Adapter.

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 Turns out it matters..

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) That's the part that actually makes a difference..

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.

• Ensure vMotion is only on vmk1. Because of that, - 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.

8. Validate Before You Build VMs

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

Real talk — this step gets skipped all the time Easy to understand, harder to ignore..

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 Worth keeping that in mind. Which is the point..

Treat every vNIC in the nested VM as a physical cable. That's why label them. Still, map them. Enforce Jumbo Frames end-to-end. Bind storage adapters explicitly. Force Round Robin multipathing Most people skip this — try not to. Simple as that..

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 Easy to understand, harder to ignore. But it adds up..

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