Step 1 — Network / DNS / NTP / AD Plan (one page)

Lock this before filling any other workbook page. If you only have time for one meeting with the network + AD/PKI teams, run it on this page. Everything in the workbook flows from these decisions.

Prefer a spreadsheet? Download the blank fillable planning templates (IP/DNS, VLAN/subnet, NTP/AD/CA, BGP) — capture the plan in CSV, then transfer to the workbook or Coscia’s planner. For the firewall flows these networks depend on, see Firewall & Ports.

Convention used in the templates below: site code sfo, instance m01, rack r01. Replace consistently when copying for a real deployment. VLAN IDs and CIDRs are placeholders.

A. VLAN / Subnet plan

Fill one row per traffic type. The same table covers Mgmt Domain and the first WLD — duplicate it for additional WLDs / clusters.

Overlay MTU: host and edge TEP networks carry GENEVE and need MTU ≥ 1600; set 9000 on the distributed switch. The host-overlay VMK inherits its MTU from the vDS rather than a per-network field.

VCF Installer = SDDC Manager identity. When you deploy the VCF Installer on one of the management-domain ESX hosts (the usual greenfield case), you give it the IP and FQDN you plan for SDDC Manager — the appliance switches into SDDC Manager mode after bring-up, so there is no throwaway / temporary IP. Reserve that single IP + FQDN as SDDC Manager (intake E7); the Installer just needs routed reachability to the ESX Management network to commission the hosts. (Only an Installer deployed outside the management infrastructure uses a separate temporary address.) Per Broadcom TechDocs.

Port group VLAN gotcha: on the host you deploy it on, place the Installer on a port group carrying the VM Management VLAN. A fresh ESXi host’s default VM Network port group is untagged (VLAN 0), so if VM Management is a tagged VLAN, set the VLAN ID on it (or use a tagged port group) first — otherwise the appliance comes up with no management connectivity.

IP range carve-out (per subnet)

Inside each /24 reserve contiguous ranges so static pools / DHCP scopes don’t collide with appliance IPs.

Host-facing subnets — one IP per host VMK, sized here for up to 16 mgmt hosts:

TEP addressing: prefer a static IP pool, entered in the VCF Installer — no external DHCP dependency, and no per-AZ scopes in stretched designs. Per Broadcom TechDocs either a static IP pool or a DHCP server on the Host Overlay VLAN satisfies the prerequisite; pools can also be created per cluster later (Create an IP Pool for Tunnel Endpoint IP Addresses).

VM Management subnet — the crowded one. A VCF 9.1 management domain packs a lot onto this network: ~30–48 IPs. Size it generously (a /24 is normal — do not try to squeeze it into a /27). On top of discrete appliance IPs it needs two dedicated contiguous blocks: a /29 for VCF Automation and a /28–/27 for the VCF management-services runtime. Each additional VI Workload Domain also lands its vCenter (1) + NSX Manager cluster (4) on this subnet — +5 IPs per WLD — so leave headroom. The full per-component FQDN/IP list is on TechDocs: VCF Components FQDNs and IP addresses.

Separate internal networks — keep off the VM Mgmt subnet. The VCF services runtime uses an internal container CIDR, 198.18.0.0/15 by default (change to 240.0.0.0/15 or 250.0.0.0/15 if it clashes) — and VCF Automation uses the same kind of internal cluster CIDR, with the same default and alternatives (the cluster CIDR captured in intake B21; see 05-day2-deployments.md section D). These are internal to the platform, not routed appliance IPs — just make sure the blocks do not overlap anything you actually route.

B. BGP plan

Multi-AZ: whether the Edge uplinks and this peering are stretched across AZs or per-AZ depends on the NSX connectivity model — stretched under Centralized, per-AZ under Distributed (intake A10). See 03-multi-az-prep.md section D.

TechDocs: the Edge cluster / Tier-0 / BGP peering this plan feeds is set up per Set up Centralized Connectivity with Edge Clusters — neighbor IP + remote AS are the only required BGP settings (MD5 and BFD are optional).

C. DNS

Two DNS servers (resolver IPs to put into appliances)

Required A + PTR records (Mgmt Domain — minimum)

Every FQDN below needs both an A and a PTR. Add WLD/cluster hosts in the same shape.

Lowercase only. The TechDocs FQDN/IP list marks the fleet-services family with “Do not use capital letters in the FQDN”: VCF Automation, VCF services runtime, fleet components, instance components, Identity Broker, Log Management, real-time metrics. DNS itself is case-insensitive but the appliances are not always — the practical rule: create every VCF FQDN lowercase.

DNS settings checklist

• Forward + reverse zones for the parent domain
• Forward + reverse zones for any child / site domains (e.g. sfo.example.io)
• Dynamic updates: Nonsecure and secure
• Zone replication scope: All DNS servers in this forest
• Every FQDN unique; every PTR present
• No CNAME for any VCF appliance hostname (must be A)
• All FQDNs lowercase (required for the fleet-services family; recommended everywhere)

D. NTP

• Sources must sync to different upstream NTP (avoid common-mode failure).
• AD DCs configured to sync to the same external sources.
• Two NTP entries on every appliance (use the CNAME and a backup A-record).

E. Active Directory

TechDocs: AD is bound fleet-wide via the VCF Identity Broker — Configure an Identity Provider; prep details + gotchas in prerequisites.md.

F. Certificates

TechDocs: Configure a Certificate Authority for VMware Cloud Foundation — CA prerequisites (Microsoft CA Web Enrollment / OpenSSL) in prerequisites.md.

G. SMTP / SFTP / Proxy

Sign-off

Once A–G are filled and signed by the network/AD/PKI owners, move on to 02-intake.md to capture platform-side answers (hosts, sizing, passwords). The intake doc references this page rather than asking the same questions twice.