Foundation Discovery Fails on a Segmented BMC Network
A partner engineer is deploying a four-node Nutanix cluster at a manufacturing site. The nodes are racked and cabled: 25 GbE front-end ports to two top-of-rack switches in an MLAG, and 1 GbE BMC ports to a separate management switch. The host and CVM network is 10.20.8.0/24; the BMC network is 192.168.60.0/24, reachable only through a firewall. The engineer runs the Foundation VM on a laptop connected to 10.20.8.0/24. Foundation discovery returns zero nodes. The engineer can ping the host IP addresses but cannot ping any BMC address. The firewall team says no rules exist between the laptop VLAN and the BMC VLAN. The project window is six hours, and the customer will not move BMC ports to the host VLAN because of security policy. Foundation is the only supported deployment tool for this model.
1. What is the most likely connectivity gap, and what would you verify before changing the deployment method?
Read the worked answer
Reasoning: Foundation is not a single-protocol tool. It needs L3 reachability from the Foundation VM to the BMC network for IPMI discovery and boot control, and to the host provisioning network for imaging and CVM configuration. IPMI uses UDP 623; BMC web/KVM commonly uses TCP 443 and 5900/5901; host provisioning uses TCP 22/443 and PXE if configured.
The evidence points to the missing firewall path: host pings succeed, BMC pings fail, and no rules exist between the two VLANs. Before blaming Foundation, verify the Foundation VM IP, default gateway, VLAN tag, and that the BMC addresses are correct and unique. Confirm the customer's security policy allows a temporary, host-specific rule rather than a broad VLAN-to-VLAN permit. Do not jump to manual ISO installs, which bypass the supported deployment workflow and can leave the cluster incorrectly configured.
2. The firewall team offers to allow only TCP 443 from the laptop VLAN to the BMC VLAN. Is that sufficient? What temporary design would you propose?
Read the worked answer
Reasoning: TCP 443 alone is not sufficient because Foundation relies on IPMI, which uses UDP 623, for power control and boot-device selection. If UDP 623 is blocked, discovery or imaging can still time out even though the BMC web UI is reachable.
A safer temporary design is a Foundation VM with two virtual NICs: one on the host/CVM VLAN and one on the management/BMC VLAN. That gives Foundation local L2 access to both networks without opening a broad firewall path. If dual-homing is not allowed, request firewall rules scoped to the Foundation VM's source address: UDP 623 to the BMC subnet and TCP 22/443 to both the BMC and host subnets. Avoid permitting the entire laptop VLAN. Validate with a short discovery run and a packet capture or firewall hit count before starting the six-hour window.
3. After connectivity is fixed, what deployment checks reduce the risk of a failed cluster creation?
Read the worked answer
Reasoning: Discovery is only the first gate. Before imaging, confirm the BMC and host IP plans, VLAN IDs, default gateways, DNS and NTP, and that no addresses collide with existing devices. Check that all four nodes have the expected AOS/Foundation-compatible firmware and that the backplane or front-end cabling matches the intended bond design.
During the run, watch for nodes dropping out of PXE or CVM configuration, not just the final success banner. After cluster creation, verify NCC health, CVM and AHV connectivity, storage pool creation, and the cluster VIP. Record the exact firmware and AOS versions for the handover. If a node fails mid-run, use Foundation logs before re-imaging, because the cause may be a single bad cable, VLAN, or BMC setting rather than the tool.