This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(294.40000000000003, 70%, 38%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ELJ%3C/text%3E%3C/svg%3E)
We have deployed an Azure Local cluster (three nodes, HPE DL380 Gen11)
All of a suddent the storage network in Failover Cluster Manager is reporting as "Partitioned" and we're seeing errors in the Windows Admin Centre console related to a loss of quorum.
If I disallow the cluster to use the storage network the error disappears but we also lose a good amount of performance, when I enable it, we get some performance back (not all) and it very quickly transitions to partitioned.
The storage network is two different physical Mellanox NIC's connected to an Aruba switch via 25Gb DAC cables. All communication would appear to be fine, pings are fine between the IP's on the storage network, the interfaces are trunk ports allowing both Storage VLAN's to communicate accordingly.
On Windows Admin Centre we get these errors:
The cluster detected network connectivity issues that prevent Storage Spaces Direct from working properly.
If a maintenance operation is ongoing, please suspend it and restore access to all storage until the storage stabilizes.
The switch configuration is matched across all storage NIC ports and the settings across the nodes look to be identical for internal PFC/RDMA etc.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(262.40000000000003, 96%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAY%3C/text%3E%3C/svg%3E)
Hi Luke Jackson,
Get-NetAdapterRdma
# PFC priorities
Get-NetQosFlowControl
# SMB QoS policy
Get-NetQosPolicy -PolicyStore ActiveStore
Hi Luke Jackson,
Just checking in if you are still facing the issue with your Storage network. If yes, please help us by answering the queries asked so that we can assist you further.
Thanks!
I've managed to resolve this.
I checked the IP Addresses assigned to the two storage networks on each node and it looks like Node 2 and 3 had picked up an IP from the other VLAN (10.71.1.X) instead of the VLAN the NIC was attached to (10.71.2.X) so this was causing the loss in communication when it was trying to establish connections.
Hello Luke Jackson,
Glad to know that issue was addressed and fixed.
Thanks for letting us know about it.
It turned out that the IP addresses assigned to the two storage networks on node 2 and node 3 were misconfigured (ie NIC was attached to VLAN with IP (10.71.2.X) but the IP address was assigned from VLAN with IP (10.71.1.X)). This caused the loss in communication when using storage network.
To fix the issue, the customer had to fix the IP address misconfiguration.