vSAN basic (unicast) connectivity health check reports failure between witness host and data nodes despite healthy network connectivity

Products

• VMware vSAN

Issue/Introduction

In a vSAN stretched cluster, the vSAN basic (unicast) connectivity health check incorrectly reports a failure or alarm between the witness host and data nodes, even though network connectivity and ping tests between them succeed without issue.

It is important to distinguish that this health check will trigger constantly in this situation, despite no network drops. If the message is intermittent, or comes and goes, this KB is not relevant and further analysis should be conducted. 

Environment

vSAN

Cause

This issue occurs in specific vSAN stretched cluster configurations where the vSAN vmknic on the data nodes has dual routing table entries:

    Entry 1: Internal vSAN traffic routed through a default gateway shared with the management network.
    Entry 2: Witness traffic routed through a dedicated witness gateway.

Because of this dual-routing setup, ICMP-based ping response packets generated by the health check may fail to route correctly back to the appropriate application layer. This causes the unicast connectivity health check to flag a failure, even though network connectivity is functional and actual vSAN data traffic is completely unaffected. 

Resolution

There is currently no workaround required or available.

Because this is a cosmetic health check defect that does not impact vSAN data traffic, the alarm can be safely ignored.

This issue is scheduled to be resolved in an upcoming patch release.