Skyline Health reports "Basic (unicast) connectivity check" and "MTU check" failures due to faulty vmnic in VMware vSAN

Products

VMware vSAN

Issue/Introduction

Symptoms:

The vSAN Skyline Health Check reports failures for the following alerts:
- vSAN: Basic (unicast) connectivity check
- vSAN: MTU check (ping with large packets)
- vSAN Cluster Partition
- Hosts with LACP issues
- vSAN: Object health
- Stats DB object
Identify the faulty host via Skyline Health
1. In the vSphere Client, navigate to the vSAN Skyline Health checks.
2. Select the primary failing issue: vSAN: Basic (unicast) connectivity check.
3. Click the Troubleshoot option.
4. Review the resulting report. This runs an automated ping test between all vSAN VMkernel adapters in the cluster and will explicitly list any unreachable hosts, the specific VMkernel being used for vSAN, and the packet size (MTU) tested.
Validate MTU Configurations
To check the VMkernel MTU:
1. Select the host from the vSphere inventory.
2. Navigate to Configure > Networking > VMkernel adapters.
3. Select the VMkernel adapter that has the vSAN service enabled.
4. Locate the MTU value under Properties > NIC settings.
To check the Virtual Switch MTU:
1. Navigate to Configure > Networking > Virtual switches.
2. Expand the virtual switch utilized by the vSAN VMkernel.
3. Click the three dots (ellipses) on the far right and select View Settings.
4. Locate the MTU value.
To confirm the host is isolated, review the "esxcli vsan cluster get" output and verify that the Sub-Cluster Member Count is reported as 1, indicating the host has formed its own single-node vSAN sub-cluster.

[root@esxihost:~] esxcli vsan cluster get

Cluster Information
Enabled: true
Current Local Time: 2026-06-30T09:32:49Z
Local Node UUID: 695fc829-9fdc-f585-08cc-########
Local Node Type: NORMAL
Local Node State: MASTER
Local Node Health State: HEALTHY
Sub-Cluster Master UUID: 695fc829-9fdc-f585-08cc-########
Sub-Cluster Backup UUID:
Sub-Cluster UUID: 52fed224-c15c-6142-1ee1-#########
Sub-Cluster Membership Entry Revision: 0
Sub-Cluster Member Count: 1
Sub-Cluster Member UUIDs: 695fc829-9fdc-f585-08cc-########
Sub-Cluster Member HostNames: esxihost
Sub-Cluster Membership UUID: a83b3d6a-b687-673e-2203-########
Unicast Mode Enabled: true
Maintenance Mode State: OFF
Config Generation: e0027394-05cd-4a3e-ac9d-######## 10 2026-06-30T08:56:06.857
Mode: REGULAR
vSAN ESA Enabled: true

To confirm if the network adapter is failing to pass traffic, test the VMkernel network connectivity from the problematic ESXi host to a working ESXi host in the cluster.

Test the connectivity using both standard (1500) and Jumbo Frame (9000) MTU sizes.

Example of a failed 1500 MTU test:

PING ##.##.###.## (##.##.###.##): 1472 data bytes

--- ##.##.###.## ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Example of a failed 9000 MTU (Jumbo Frame) test:

PING ##.##.###.## (##.##.###.##): 8972 data bytes

--- ##.##.###.## ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Run the command "esxcfg-nics -l" on the affected host. The output may report NIC link Down state for one or both the vmnics:

esxcfg-nics -l
Name PCI Driver Link Speed Duplex MAC Address MTU Description
vmnic2 ####:##:##.# bnxtnet Down 0Mbps Half ##:##:##:##:##:## 1500 ############
vmnic3 ####:##:##.# bnxtnet Down 0Mbps Half ##:##:##:##:##:## 1500 ############
The LACP configuration status may also report a Down state on one or both the uplinks:.
esxcli network vswitch dvs vmware lacp status get
########
DVSwitch: ########
Flags: S - Device is sending Slow LACPDUs, F - Device is sending fast LACPDUs, A - Device is in active mode, P - Device is in passive mode
LAGID: ###########
Mode: Active
Nic List:
Local Information:
Admin Key: ##
Flags: ##
Oper Key: ##
Port Number: 2
Port Priority: 255
Port State: ACT,AGG,DEF,
Nic: vmnic3
Partner Information:
Age: 00:00:00
Device ID:
Flags:
Oper Key: 0
Port Number: 0
Port Priority: 0
Port State:
State: Down
Local Information:
Admin Key: ##
Flags: ##
Oper Key: ##
Port Number: 1
Port Priority: 255
Port State: ACT,AGG,DEF,
Nic: vmnic2
Partner Information:
Age: 00:00:00
Device ID:
Flags:
Oper Key: 0
Port Number: 0
Port Priority: 0
Port State:
State: Down
The /var/run/log/vobd.log file on the affected host may report link down state for one or both the vmnics.
YYYY-MM-DDTHH:MM:SS.SSS-SS:SSZ In(14) vobd[2097763]: [netCorrelator] 9582556514372us: [esx.problem.net.vmnic.linkstate.down] Physical NIC vmnic3 linkstate is down
YYYY-MM-DDTHH:MM:SS.SSS-SS:SSZ In(14) vobd[2097763]: [netCorrelator] 11569289297493us: [esx.problem.net.vmnic.linkstate.down] Physical NIC vmnic2 linkstate is down

Environment

VMware vSAN 7.x
VMware vSAN 8.x
VMware vSAN 9.x

Cause

vSAN network traffic is being forwarded through a problematic physical network adapter (vmnic#) that is unable to pass traffic. Because this degraded uplink is silently dropping or blocking traffic, the host loses communication with the rest of the cluster, resulting in the isolation event and the associated health check failures.

Resolution

In case of both the vmnics are down: Engage networking team to bring back the vmnics to healthy state.
In case the vmnics are not physically down but only drops the packets: Follow the below procedure to move the traffic to standby vmnic.

Phase 1: Identify the active vmnic serving vSAN traffic

SSH into the ESXi host that is reported as unreachable by the vSAN Skyline Health Check.
Run the following command to open the network statistics view: esxtop
Press the n key to switch to the network view.
Locate the VMkernel port (vmk#) associated with the vSAN service. Look at the TEAM-PNIC column in that row to identify the active physical adapter (e.g., vmnic#) currently handling the vSAN traffic.

Phase 2: Force a network failover (Isolate the issue)

Note: Only perform these steps if there is more than one vmnic in active or standby in the vSAN VMkernel port group's teaming settings. (Reference KB: "How to configure NIC teaming in ESXi and ESX").

Place the ESXi host into Maintenance Mode to ensure all active VMs are safely migrated to other hosts in the cluster.
Administratively bring down the active vmnic identified in Phase 1 by running:

esxcli network nic down -n vmnic# (Replace vmnic# with the actual vmnic ID).
Return to esxtop (network view) and confirm that a different vmnic now appears under the TEAM-PNIC column, verifying that the failover was successful.

Phase 3: Re-test connectivity After the vmnic failover completes, perform the vmkping tests again between the affected hosts to see if traffic passes over the newly active adapter.

Test standard MTU:

vmkping -I vmkX -d -s 1472 <ip address>
Test Jumbo Frames (if configured):

vmkping -I vmkX -d -s 8972 <ip address>

Phase 4: Next Steps & Remediation

If the ping tests succeed on the newly active NIC but failed on the original NIC, the issue is isolated to that specific adapter. Engage your internal networking team to investigate the problematic vmnic.
If only one host is unreachable over the vSAN network, it is highly likely an issue with the upstream physical switch port configuration.