Deep Dive of the Day Building NSX Edge clusters from vCenter in VCF 9.1, and the choices you can't easily undo
In VCF 9.1 the natural place to build an Edge cluster is vCenter. The centralised connectivity workflow lives in the vSphere Client under Networks, and in one pass it creates the Edge cluster, the Edge nodes, their credentials, a Tier-0 gateway and, if you use VPCs, the external and private transit gateway IP blocks. You need Edges whenever you want dynamic or static routing with the physical fabric and centralised stateful services; if you don't, the distributed connection with Virtual Network Appliances is the lighter option we covered on 21 October.
The prerequisites are where most failed deployments start. The hosts need VDS uplinks, the compute manager must be registered with NSX, a transport node profile must be attached to the cluster, "Activate NSX on DVPG" must be on for the host cluster, and every host in the target cluster or host group needs identical access to the management, uplink, host TEP and Edge TEP networks. Edge DNS records must exist beforehand, management addresses must be routable to NSX Manager, and any host group or resource pool you plan to pin the Edges to has to exist before you open the wizard.
Sizing is simpler than it looks. TechDocs lists Small (2 vCPU, 4 GB) for lab and proof of concept, and Medium (4 vCPU, 8 GB), Large (8 vCPU, 32 GB) and XLarge (16 vCPU, 64 GB) for production with load balancing. Every Edge reserves 100% of its CPU and memory, so the cluster needs room for at least two at full reservation. For production, the host fault tolerant design recommends Large or XLarge, High CPU shares and a dedicated cluster for Edges.
The TEP VLAN decision deserves some thought. The wizard offers "Use the host overlay network configuration", which puts Edge TEPs on the same VLAN as host TEPs; that only works when the cluster is prepared with NSX activated on the DVPG. The design guide advises against it and recommends separate, routed TEP VLANs for hosts and Edges, with addresses from IP pools and TEP groups enabled. Shared VLANs are possible, but separate ones are easier to troubleshoot and match the validated design.
MTU is the classic trap. The Edge TEP MTU has to match the host overlay MTU in the same transport zone, and the wizard takes it from the global fabric settings. KB 422523 explains why that matters: the workflow always applies the default nsx-edge-multiple-vteps-uplink-profile, so changing the TEP MTU in NSX after deployment doesn't update the fp-eth interfaces on Edges you've already deployed. Set System > Fabric > Settings > Global Fabric Settings first, and make sure the physical path carries it end to end. Gateway uplinks are separate and accept 1,500 to 9,000.
Routing comes next. With BGP you give each uplink a peer IP, MTU and password and reserve a local ASN for the Tier-0; with static routing you can use an HA VIP on an active-standby Tier-0 as the top-of-rack next hop. In active-standby, only two Edges can carry gateway uplinks. You can also skip the gateway step entirely, deploy just the Edges, and add the Tier-0 later from Network Connectivity, which is handy when the network team hasn't confirmed ASNs yet.
Placement is what keeps a host failure from taking out north-south traffic. The design guide asks for at least two Edges in the cluster, spread across hosts, with one host group per host, one VM group per Edge, a "must" VM/host rule between them and a Best Effort Restart compute policy. Under that policy vMotion doesn't evacuate Edges during host maintenance, so plan maintenance one Edge at a time. NSX failure domains are only worth configuring once you have more than two Edges.
A few wizard limits are worth knowing before you start. An Edge cluster needs between two and ten Edges, all on the same type of vSphere cluster (standard or stretched). Cloning a node in the wizard is only safe when the clone stays in the same cluster with identical networks, and you must change its FQDN. VM management port groups aren't created automatically for VI workloads, so create them first, and let VCF manage Edge passwords unless you have a reason not to, since manual ones must meet the 12-character complexity rules.
In a nested lab, Small Edges are fine, but the outer environment matters more than the Edge size. Lubomir Tobek's nested VCF 9.1 build [Community] needed Promiscuous Mode and Forged Transmits set to Accept on the nested trunk port groups, an MTU of 9000 across the Edge TEP and uplink paths, and Geneve (UDP 6081) allowed between the host and Edge TEP VLANs. He also found that the BGP sessions stay idle until real ASNs are in place while the Edges, Tier-0 and transit gateway still come up, and that each Edge took 20 to 25 minutes to deploy on nested hardware.
The practical order, then: settle the global fabric MTU and the TEP VLAN design first, pre-create DNS records, host groups and port groups, size for full reservation, and add anti-affinity before you rely on failover. Then test what matters rather than just pinging the Tier-0: fail an uplink, put a host into maintenance and watch BGP converge. The Edge cluster is one of the few things in VCF 9.1 that's awkward to change once workloads depend on it, so it repays an hour of planning.
Based on Configure Centralized Network Connectivity with Edge Clusters (VCF 9.1) Official Host Fault Tolerant NSX Edge Cluster Model (VCF 9.1 design library) Official KB 422523: Unable to change MTU on Edge fp-eth interfaces in VCF 9 Official Nested VCF 9.1 Lab, Part 5: NSX Manager cluster and NSX Edge deployment (Lubomir Tobek)
