In this part you prepare the external network services that a VCF 9.1 management domain depends on. You will set up DNS forward and reverse records, point the environment at reliable NTP, define the VLANs and subnets for each traffic type, and reserve the IP ranges the VCF Installer asks for. None of this deploys a VMware appliance yet. It builds the foundation that the installer checks in its prechecks, and a clean pass here removes most of the failures that stop a bringup halfway through.

Do this work before you deploy the VCF Installer appliance in Part 4. Read the prerequisites, then follow the numbered steps in order. Every field name and value below matches what the installer and your switching gear expect, so enter them exactly as written and substitute your own addresses where noted.

Prerequisites

Confirm each item below is in place and reachable from the subnet where the VCF Installer appliance will live. Missing DNS or NTP is the single most common reason a bringup stalls.

Step 1 plan the IP addressing and FQDN list

Start by listing every appliance the management domain will deploy and assign each one a static IPv4 address and an FQDN. All infrastructure networks in VCF 9.1 must be IPv4 based, so do not plan IPv6 for management, vMotion or storage. Record the VCF Installer appliance, vCenter, the NSX Manager cluster, SDDC Manager, VCF Operations and the VCF Management Services range. For the management services container cluster, set aside a fresh /27 block that does not overlap any network pool. Reserve a range of 12 or more contiguous IPs for the services, and a separate range of 5 or more IPs for VCF Automation, where 3 addresses go to the automation nodes and 2 stay as a buffer for redeployment and rolling updates. Keep a spreadsheet with hostname, role, IP, subnet mask and gateway so the following steps and the installer wizard share one source of truth.

Step 2 create forward and reverse DNS records

Create both an A record and a matching PTR record for every FQDN on your list. VCF resolves names in both directions during bringup, and a missing PTR is the most frequent cause of a failed DNS precheck. Use two DNS servers that sit outside the VCF instance and are reachable from both the ESXi management network and the VM management network. Open UDP and TCP port 53 to both servers. Enter the same two DNS servers into the VCF Installer later, where the wizard populates DNS fields from the values you gave the appliance. Pick a domain suffix such as vcf.local or your routed corporate domain and use it consistently. After you add the records, allow time for replication if you run more than one DNS server, then validate them in Step 6.

Step 3 configure NTP and reduce time skew

Point the environment at two NTP servers that are reachable from both management networks and hosted outside the VCF instance. Accurate time keeps single sign on, certificates and login tokens valid across every VCF component, and a clock offset of more than a few seconds can break authentication during bringup. Open UDP port 123 between the management networks and the NTP servers. If you use appliance based time sources, confirm they are synced upstream before you rely on them. Enter the same two NTP servers into the installer, where they auto populate the same way DNS does.

Step 4 define the VLANs and set MTU

Create the VLANs for each traffic type and tag them to every host uplink. A management domain needs at minimum a management VLAN, a vMotion VLAN, a vSAN or NFS VLAN, and an NSX host overlay VLAN. Set MTU 9000 on the vMotion, storage and overlay VLANs where your fabric allows it, and enable that MTU end to end through every switch in the path. For the NSX host overlay, 1600 is the hard floor because Geneve needs header room, and 9000 is the recommended value. Physical switches should carry an MTU slightly above the host value so encapsulation overhead never clips a frame. In VCF 9.1 you can configure the overlay Tunnel End Point directly from vCenter like any other vmkernel NIC, and each host takes two IPs from the TEP pool, so size that pool at double the count you use for vMotion or vSAN.

Step 5 reserve the management services and automation ranges

Confirm the /27 management block for VCF Management Services is free and does not overlap a network pool. Management Services is a mandatory container cluster in VCF 9.1 that runs fleet lifecycle, SDDC lifecycle, the software depot, the license server and the identity broker, and it needs its own block on the VCF management network. Provide the services IP range of 12 or more addresses and the VCF Automation range of 5 or more addresses as ranges, not as per node FQDNs, because the installer assigns them for you. Build a network pool for vMotion and vSAN or NFS so those vmkernel ports receive static IPs automatically, and keep each pool subnet from overlapping another pool.

Step 6 validate resolution and reachability

Before you deploy the installer appliance, prove that every record resolves and every path is open. Run nslookup on each FQDN for the A record and on each IP for the PTR record from a host on the management network, and query both DNS servers. Confirm NTP replies on UDP 123 and that the offset is small. Test the overlay and storage MTU with vmkping once hosts are reachable, using a do not fragment flag and a payload that matches your MTU. Fix any failure now, because the VCF Installer runs the same checks and refuses to proceed if one fails.

flowchart TD
    A[Plan IP addressing and FQDN list] --> B[Create forward and reverse DNS records]
    B --> C[Configure NTP and check time skew]
    C --> D[Define VLANs and set MTU]
    D --> E[Reserve management services and automation ranges]
    E --> F[Validate resolution and reachability]
    F --> G[Ready for VCF Installer prechecks]

Map each traffic type to a distributed switch

VCF 9.1 places management, vMotion, storage and overlay traffic on a vSphere Distributed Switch that the installer creates during bringup, so plan the uplinks now. Assign at least two physical NICs per host to the distributed switch for redundancy, and confirm both uplinks carry every VLAN you defined in Step 4. Set the switch MTU to 9000 so jumbo frames pass on vMotion, storage and overlay, and leave the management port group at the fabric default if your management VLAN does not run jumbo frames. Record which vmnic maps to which uplink on every host, because mixed cabling causes a NIC speed or link mismatch that the installer flags during prechecks. Keep the uplink speed consistent across hosts, since the VCF Installer checks NIC speed and rejects a host whose adapters do not meet the floor for the profile you selected. When you later run the installer, the values you set here feed the network profile, so a clean and consistent layout now means fewer corrections during the management domain build.

Plan routing between the management network and your external services before bringup. Set a gateway on the management VLAN and confirm the installer appliance can reach both DNS servers, both NTP servers and the software depot through it. If management, VM management and the services block sit on separate subnets, add the routes that let them reach each other, because the Management Services container cluster and VCF Automation must talk to vCenter and NSX during and after deployment. Verify that return traffic is not blocked by a firewall rule, since a one way path passes a simple ping but still breaks bringup.

Verify DNS, NTP and MTU

Run each check below from a workstation or ESXi host on the management network and confirm it returns a clean result. A correct outcome is a returned name or address for every query and a successful ping with the do not fragment flag set.

When the VCF Installer later shows a green precheck for DNS forward, DNS reverse, NTP and NIC speed, your network layer is ready for the management domain build.

Common errors and fixes

Failed DNS precheck from a missing PTR. Because the installer resolves names both ways, an A record without a matching PTR fails the reverse check. Add a PTR for every FQDN on both DNS servers, then rerun the precheck.

NTP unreachable or clock skew too high. If UDP 123 is blocked or a server is down, time drifts and authentication fails during bringup. Open UDP 123 to both NTP servers and confirm the offset is within a few seconds before you continue.

Overlay MTU below the Geneve floor. An NSX host overlay set under 1600 drops encapsulated frames and TEP tunnels fail to form. Set the overlay VLAN to 1600 at minimum and 9000 where supported, end to end through every switch.

Management Services block overlaps a network pool. A /27 that shares addresses with a vMotion or vSAN pool causes IP conflicts and a failed availability check. Move Management Services to a fresh /27 that no pool uses, then revalidate.

Questions that come up

Whether a dedicated management VLAN is required. A dedicated VCF management network is the recommended model, and all IP ranges should sit on it. If you have no dedicated network, you can place components on the VM management network instead.

How many DNS and NTP servers to provide. Provide two of each so a single server outage does not stall bringup or break time sync.

What MTU the NSX overlay needs. 1600 is the minimum for Geneve and 9000 is the recommended value. Set it end to end across every switch in the path.

Why the management services block must be a fresh /27. Management Services is a mandatory container cluster and needs its own block that does not overlap any network pool or storage subnet.

References

• VCF Components FQDNs and IP Addresses, Broadcom TechDocs
• Network Fabric Detailed Design, Broadcom TechDocs
• Create a Network Pool, Broadcom TechDocs
• Simplify Workload Connectivity in VCF 9.1, VCF Blog

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts