VCF Homelab Infrastructure Subnet Design

Overview

This VCF infrastructure subnet design separates the services supporting my physical lab, including host management, storage, vMotion and management virtual machines. I keep the physical environment separate from nested test environments so I can rebuild the latter without disturbing the former.

I decided to build a physical and nested VCF architecture because in the physical side I can test out a true deployment on a single host and use this deployment as my test bed for my own training and hands-on experience with it. I don’t want to muddy up my VCF deployment when assisting customers so I will also deploy nested VCF environments that can be spun up on the fly as needed and rebuilt quickly using Powershell scripts and PowerCLI module.

Infrastructure subnet allocation

The following segments reflect my lab’s separation of management, storage and supporting services. They are not a universal minimum subnet count for VCF. The networks required for a deployment depend on its release, storage and topology; NSX TEPs, uplinks and nested environments are addressed separately.

Illustrative examples only: the VLAN IDs and 10.60.0.0/16 address block below are invented for this article. They do not document my deployed addresses or a tested configuration. Replace them after checking your existing networks, VPN routes and product-reserved address ranges. The prefix sizes retain the original lab plan to make its capacity limits visible.

Address suffixes such as .2–.14 refer to the subnet on that row. In this example, .1 is reserved for a gateway on routed segments and left unused on segments without one. Do not add a gateway to every storage or VMkernel network automatically; routing follows the selected design.

Address allocation and capacity

• Record each VLAN, network/prefix, gateway where required, DNS name, address owner and purpose in IPAM or a spreadsheet. Allocate static service addresses first, then define DHCP scopes that exclude those addresses.
• A /29 has 6 usable IPv4 addresses, a /28 has 14, a /27 has 30 and a /25 has 126. Network and broadcast addresses are not host addresses. Reserving .1 leaves only 5 service addresses in either /29 above, so expand those networks before deployment if your service count or growth needs exceed that limit.
• The example keeps gaps between subnets instead of packing them together. That makes the table easy to read and leaves planning room; it does not authorize expanding a live subnet without checking overlap, routes and all attached systems.
• Count appliance nodes, cluster VIPs, storage interfaces and temporary deployment or upgrade addresses separately. A deployment profile may need more addresses than its visible service endpoint suggests.
• Create forward and reverse DNS records for named infrastructure services and keep their address assignments outside client DHCP pools. Use the linked DNS guide for record creation.
• Separate VLANs provide traffic separation, but access control still requires routing and firewall policy. Limit management access to the intended administration paths. The single iSCSI row is an addressing example, not a complete storage multipathing or redundancy design.

Original DHCP choices versus VCF import

The original version of this plan proposed DHCP pools for vMotion, vSAN, iSCSI and provisioning. Preserve that as historical lab context, not an instruction to leave VMkernel adapters on DHCP when preparing a VCF import. The table above uses static host-interface assignments for the example. DHCP for ordinary wired, wireless and temporary build guests is a separate choice.

A DHCP reservation can make an address predictable, but the interface is still configured as a DHCP client. It is not equivalent to configuring a static address on the VMkernel adapter. Inspect each adapter’s actual configuration before import and resolve the validation findings for your VCF release.

Broadcom KB 433966 documents the static-IP guardrail in a VCF 9.0.0.0 inventory-sync/upgrade precheck, including failure when an IPv6-configured adapter retains DHCP for IPv4. Its IPv6-specific remedy is not a reason to disable IPv4 on an IPv4 lab. For this IPv4 example, plan appropriate static settings and a controlled change with console access before altering host networking.

Before using the example

• Check that every CIDR and VLAN is unused and appropriate for your topology. Confirm switch trunks, port groups, routing and intended firewall paths.
• Confirm address capacity, non-overlapping static and DHCP allocations, DNS resolution and the MTU required by your chosen design.
• Review the requirements for your exact VCF version and deployment/import path, then run its prechecks. Do not bypass a failed networking guardrail.

This is an illustrative addressing plan. It has not been deployed or used to validate routing, storage or VCF import in a live lab.

Design rationale and next steps

Yes this a good amount of subnets to create but these are what I determined are needed based on my experience with other labs and wanting to ensure I have logical separation for all the various pieces I am going to be deploying.

Check out my next posts where I will go into details on the networking and nested subnets.