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

List every appliance and give each a static IP address and an FQDN. This guide uses IPv4 throughout, which VCF 9.1 fully supports. VCF 9.1 also supports dual stack and can run vSAN and vMotion on IPv6, but the NSX host overlay always needs a dedicated IPv4 range, so keep an IPv4 pool for overlay traffic.

1. List every appliance the installer will deploy: the VCF Installer appliance, vCenter, the NSX Manager cluster, SDDC Manager, VCF Operations, and the VCF Management Services range.
2. Assign each appliance a static IPv4 address and an FQDN.
3. Set aside a fresh /27 block for the VCF Management Services container cluster that does not overlap any network pool.
4. Reserve 12 or more contiguous IPs for the Management Services range.
5. Reserve 5 or more IPs for VCF Automation, 3 for the nodes and 2 as a buffer for redeployment and rolling updates.
6. Record hostname, role, IP, subnet mask and gateway in one spreadsheet so every later step and the installer wizard share a single source of truth.

Step 2 create forward and reverse DNS records

Create matching forward and reverse records for every name, on two DNS servers outside the VCF instance.

1. Create an A record for every FQDN on your list.
2. Create a matching PTR record for every FQDN, since VCF resolves names both ways and a missing PTR is the most common failed DNS precheck.
3. Host the records on two DNS servers outside the VCF instance, reachable from the ESXi management and VM management networks.
4. Open UDP and TCP port 53 to both DNS servers.
5. Pick one domain suffix, for example vcf.local or your routed corporate domain, and use it consistently.
6. Allow replication time if you run more than one DNS server, then validate in Step 6.

Step 3 configure NTP and reduce time skew

Point every component at reliable time so authentication holds during bringup.

1. Choose two NTP servers reachable from both management networks and hosted outside the VCF instance.
2. Open UDP port 123 between the management networks and the NTP servers.
3. Confirm any appliance based time source is synced upstream before you rely on it.
4. Keep the clock offset within a few seconds, because a larger skew breaks single sign on, certificates and login tokens.
5. Enter the same two NTP servers into the installer later, where they auto populate.

Step 4 define the VLANs and set MTU

Create a VLAN per traffic type and set jumbo frames where it matters.

1. Create the management, vMotion, vSAN or NFS, and NSX host overlay VLANs.
2. Tag every VLAN to all host uplinks.
3. Set MTU 9000 on the vMotion, storage and overlay VLANs where the fabric allows, end to end through every switch.
4. Set the NSX host overlay to 1600 at minimum, since Geneve needs header room, and 9000 where supported.
5. Set the physical switch MTU slightly above the host value so encapsulation overhead never clips a frame.
6. Size the TEP pool at two IPs per host, double the count you use for vMotion or vSAN.

Step 5 reserve the management services and automation ranges

Hand the installer contiguous ranges and non overlapping pools.

1. Confirm the /27 Management Services block is free and does not overlap a network pool.
2. Provide the Management Services range of 12 or more addresses as a range, not as per node FQDNs.
3. Provide the VCF Automation range of 5 or more addresses as a range.
4. Build a network pool for vMotion and vSAN or NFS so those vmkernel ports receive static IPs automatically.
5. Keep each pool subnet from overlapping another pool.

Step 6 validate resolution and reachability

Prove every record resolves and every path is open before you deploy the installer.

1. Run nslookup on each FQDN for the A record from a host on the management network, querying both DNS servers.
2. Run nslookup on each IP for the PTR record and confirm it returns the matching FQDN.
3. Confirm NTP replies on UDP 123 and the offset is small.
4. Test overlay and storage MTU with vmkping using the do not fragment flag and a payload that matches your MTU.
5. 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