Single Subnet, Access Ports, and MTU Mismatch at a Branch
A 3-node VxRail cluster is being deployed at a branch. Each node has two 25GbE ports. The network team configured both switch ports for each node as access ports in VLAN 100 and set MTU 1500, because 'VxRail only needs one network.' The VxRail deployment wizard has separate fields for management, vSAN, vMotion, and VM networks. The installer enters 10.20.30.0/24 for all four networks, using different IP ranges. Deployment fails during network validation with 'vSAN VMkernel adapter is not reachable' and 'MTU mismatch detected.' The branch has a single /24 and no additional VLANs. The customer wants to know whether they can keep one subnet and what the minimum change is.
1. What are the likely causes of the validation failure?
Read the worked answer
Two independent causes are visible. First, the switch ports are access ports in VLAN 100, but VxRail expects trunk ports with the required VLANs allowed. If VxRail sends tagged frames for management, vSAN, or vMotion, an access port will drop or misclassify them, so the vSAN VMkernel is unreachable. Second, the switch MTU is 1500 while the wizard is validating vSAN/vMotion at 9000; the MTU mismatch is explicit. The single /24 is a design concern because it collapses traffic separation and makes per-service MTU design difficult, but the immediate validation errors are trunking and MTU.
Check the physical switch configuration, the VxRail VLAN IDs, and the VMkernel MTU settings. Also confirm that the installer did not assign duplicate IPs or use the gateway incorrectly across the four networks.
2. Can the customer keep a single /24 for all VxRail traffic?
Read the worked answer
Technically the wizard may allow multiple VMkernel services on one subnet if VLAN and MTU are consistent, but it is not a good production design. vSAN, vMotion, management, and VM traffic share broadcast and ARP behavior, and you lose the ability to apply different MTU, traffic shaping, and troubleshooting boundaries. More importantly for this case, vSAN and vMotion are usually set to MTU 9000 while management is 1500; a single subnet with mixed MTU on the same L2 is fragile and can fail validation.
If the customer insists on one subnet, set a consistent MTU end-to-end and accept that jumbo frames are either all-on or all-off. Do not mix 9000 and 1500 on the same subnet. Best practice: keep management/VM on one VLAN and put vSAN/vMotion on a separate jumbo VLAN, even if the branch must add one more VLAN. The minimum safe change is to split at least the storage traffic.
3. What minimum change plan would you give the network team?
Read the worked answer
Change the VxRail-facing switch ports to trunk mode, allow the VLANs used by management, vSAN, vMotion, and VM traffic, and set the native VLAN correctly if one is used. Set MTU 9000 on the vSAN and vMotion VLANs end-to-end, including the switch uplinks, and leave management at 1500 unless the design standardizes jumbo everywhere. If the customer keeps one VLAN, make the MTU consistent and do not mix 9000 and 1500.
On the VxRail side, set vSAN and vMotion VMkernel MTU to 9000 only after the switch path supports it, then validate with vmkping -s 8972 -d between all vSAN VMkernels. Confirm DNS, NTP, and gateways. Re-run the deployment validation only after the physical trunk and MTU changes are complete; changing only the wizard values will not fix an access port.