Complex VLAN Setup for VMware VCF Lab — Sorted in 5 Hours

When you're building a home lab that mirrors enterprise infrastructure closely enough to run VMware Cloud Foundation and Private AI workloads, "close enough" doesn't cut it. That's the position a customer found himself in after assembling some genuinely serious hardware: four Dell PowerEdge R740XD servers packing Intel Xeon Gold 6148 processors, each with four 10Gb NICs, all feeding into a pair of Netgear XS724EM switches and a Netgear PR60X router handling Layer 3 routing.

The goal was ambitious but clear. This wasn't a toy setup or a virtualized nested lab. It was a real, physical management cluster designed to support VCF and, eventually, VMware Private AI, complete with a future GPU server addition. To get there, the customer needed four distinct VLANs working in harmony: VLAN 1611 for Management, 1612 for vMotion, 1613 for vSAN, and 1614 for NSX Host Overlay, on top of the default VLAN 1 coming from the router.

The servers were installed, wired, and configured. VMware vSphere 8.0 U3 was up and running, with VLANs already established on standard vSwitches at the host level. That part of the puzzle was solid. But VLANs don't live in isolation. They have to be carried consistently across every hop in the network, and that's where things fell apart. Getting the physical switches and router to properly tag, trunk, and assign PVIDs to match what ESXi expected was proving to be a serious sticking point. Two switches, one router, and four VLANs meant a lot of moving parts that all needed to agree with each other, and networking configuration at this level isn't something you want to guess your way through.

Enter Alexander, the Rogue Support technician who picked up the ticket. This was a classic case of the customer having done the heavy lifting on the compute and virtualization side, but needing an experienced hand for the physical networking layer to make it all click.

Alex approached the session the way you'd want any technician to approach a project this involved: methodically. Rather than jumping straight into switch configs, he walked through the full topology with the customer first, confirming exactly how the four VLANs needed to flow from the ESXi hosts, across both Netgear XS724EM switches, and up through the PR60X router for inter-VLAN routing. With a setup spanning two switches specifically to leave room for two more servers down the line, getting the trunk ports and tagging right the first time mattered. Nobody wants to revisit this configuration every time they add a node.

From there, the real troubleshooting began. Alex worked through the switch configurations to make sure trunk ports were properly tagging all four VLANs while access ports, where needed, were assigned the correct PVIDs. This is the kind of detail that sounds simple on paper but trips up even experienced IT folks when Netgear's interface doesn't always map cleanly to how VMware presents VLAN tagging on the vSwitch side. Small mismatches here, a port left as untagged when it should be tagged, or a PVID that doesn't align with what the ESXi host expects, can cause VLANs to silently fail or bleed traffic where it shouldn't go.

On the router side, Alex configured the PR60X to handle Layer 3 routing between the VLANs, making sure Management, vMotion, vSAN, and NSX Host Overlay traffic could all route appropriately without stepping on each other. For a lab environment that's meant to eventually support NSX overlays and VCF's networking requirements, this inter-VLAN routing had to be rock solid. VCF is unforgiving when the underlying network doesn't behave exactly as expected.

Throughout the five-hour session, the customer noted that Alex didn't just make changes silently. He explained his reasoning as he went, walking through why each setting mattered and how it connected to the broader goal. For someone deep in a complex home lab build, that kind of communication turns a repair session into a learning experience, which is exactly what happened here.

By the end of the engagement, the VLANs were properly tagged and trunked across both switches, PVIDs were correctly assigned, and the PR60X was routing inter-VLAN traffic as intended. The physical network now matched what had already been configured on the ESXi standard vSwitches, meaning Management, vMotion, vSAN, and NSX Host Overlay traffic could all move correctly across the environment.

That might sound like a small technical win, but it unlocked the customer's entire roadmap. With the VLAN foundation solid, he's now free to move forward with the larger project: finishing the VCF deployment and eventually standing up VMware Private AI on dedicated GPU hardware. None of that is possible if the underlying network isn't rock solid, and now it is.

The customer's review speaks for itself. Alex was described as an excellent technician with strong troubleshooting instincts and a communication style that made a genuinely complex networking problem feel manageable. That combination, deep technical skill paired with the patience to explain the "why" behind each decision, is exactly what separates a good remote session from a frustrating one.

This is precisely the kind of challenge Rogue Support was built for. Whether it's enterprise-grade VLAN configuration for a home lab, wireless troubleshooting, VPN setup, or any other networking headache, customers submit a ticket, vetted technicians bid on the job, and the customer picks who they want to work with. No dispatch fees, no waiting around for a truck that may or may not show up on time. Just experienced professionals like Alexander, ready to solve real problems remotely, at $120 an hour, with the flexibility to jump on a call and get things done right the first time.