vSAN Partition After a ToR Switch Upgrade
After a scheduled ToR switch firmware upgrade, a 6-node VxRail cluster reports vSAN health 'Cluster partition' and three hosts are disconnected in vCenter. iDRAC on all hosts is reachable, and VxRail Manager is online. The switch upgrade changed the uplink LACP hash from src-dst-ip to src-dst-mac and removed VLAN 40 from the allowed list on one uplink. The vSAN VLAN is 40; vMotion VLAN 50. The customer sees some VMs still running on the connected hosts, but new VM migrations fail. The network team wants to reboot the switches again. The application owner demands immediate restoration. You have console access to one disconnected host.
1. What are your first triage steps on the disconnected host?
Read the worked answer
Use the console to confirm the host is alive and check its network state before rebooting anything. Run esxcli network ip interface list and esxcli network ip interface ipv4 get to confirm the management and vSAN VMkernel interfaces are up with the expected IPs. Run esxcli vsan network list to confirm the vSAN VMkernel is configured on VLAN 40 with the expected MTU. Check esxcli network vswitch standard uplink list and the physical NIC link state.
Then test reachability: vmkping the vSAN VMkernel of a connected host and vmkping -s 8972 -d to test jumbo. Check the physical switch port configuration for trunking, allowed VLAN 40, and LACP settings. Do not reboot the switches yet; the symptom points to a configuration change, and another reboot may extend the outage without restoring the removed VLAN.
2. What is the most likely root cause?
Read the worked answer
The most likely cause is the switch configuration change, not a VxRail failure. VLAN 40 was removed from the allowed list on one uplink, so any vSAN traffic hashed to that uplink is dropped. The LACP hash change from src-dst-ip to src-dst-mac changes which flows use which uplink; vSAN traffic that previously used a working uplink may now be pinned to the uplink missing VLAN 40. That explains a partial partition: some hosts remain connected, three are disconnected, and existing VMs on connected hosts still run while new migrations fail.
The vSAN VMkernel is likely up locally but cannot reach all peers, so vSAN declares a partition. The iDRAC path is separate and remains reachable, which confirms the hosts are powered and managed. This is a Layer 2/VLAN issue, not a vSAN disk failure.
3. What remediation restores service with the least risk?
Read the worked answer
Restore VLAN 40 on every uplink that carries the VxRail vSAN traffic, and return the LACP hash to the previously validated setting or make both sides consistent. Do not reboot the switches as the first action; correcting the allowed VLAN and hash is less disruptive. After the switch change, verify on each host that the vSAN VMkernel is up, then run vmkping -s 8972 -d from each vSAN VMkernel to every other vSAN VMkernel. Check vSAN health until the partition clears and resync completes.
Then test vMotion on VLAN 50 and confirm the disconnected hosts reconnect in vCenter. If a host remains isolated, compare its physical switch port configuration with a working host. Document the change-control failure: VLAN pruning and LACP hash changes must be validated against VxRail network requirements before a ToR upgrade.