You're staring at ERROR_CLUSTER_INVALID_IPV6_NETWORK (0x00001726) after a failover cluster node reboot or a network adapter change. I've seen this on Server 2016 and 2019 clusters more times than I can count. The message is misleading – it says 'invalid network' but it's almost always a subnet mismatch or a stale IPv6 configuration on a cluster NIC.
The good news? It's fixable without rebuilding the cluster. The bad news? If you ignore it, cluster health reports will keep nagging you and failover may behave erratically.
Cause 1: IPv6 Subnet Mask Mismatch Between Nodes
This is the big one. Each cluster network is tied to a subnet. If one node's NIC has a different IPv6 subnet prefix length (like /64 vs /128) than the other nodes, the cluster service gets confused and throws 0x1726.
I've seen this happen after someone manually sets a static IPv6 address on one node but forgets to match the prefix length on the others. It also happens when you add a new node to an existing cluster and that node's IPv6 configuration is slightly off.
How to fix it
Open an elevated PowerShell on each cluster node and check the IPv6 addresses and their prefix lengths:
Get-NetIPAddress -AddressFamily IPv6 | Where-Object {$_.InterfaceAlias -like '*Cluster*' -or $_.IPAddress -like 'fe80*'} | Format-Table InterfaceAlias, IPAddress, PrefixLength
Look at the PrefixLength column. All nodes on the same physical network should have the same prefix length. For example, if node 1 shows fe80::/64 and node 2 shows fe80::/128, that's your problem.
To fix a mismatch, set the prefix length explicitly on the offending adapter:
Set-NetIPAddress -InterfaceAlias 'Ethernet2' -IPAddress 'fe80::1234:5678:9abc:def0' -PrefixLength 64
Adjust the interface name and IP to match your environment. After that, restart the Cluster service on that node:
Restart-Service ClusSvc
Also verify the cluster network's subnet in Failover Cluster Manager. Go to Networks and check the IPv6 subnet listed. It should match the prefix length you just set.
If you're not sure which subnet the cluster expects, run:
Get-ClusterNetwork | Format-List Name, Address, IPv4Addresses, IPv6Addresses
Compare that to the node's actual IPv6 addresses. They must line up.
Cause 2: IPv6 Disabled or Misconfigured on a Cluster NIC
Some admins disable IPv6 thinking it speeds things up. That's a mistake on a cluster node – the cluster service still wants to bind to IPv6 link-local addresses, even if you don't use IPv6 for actual traffic. When IPv6 is disabled completely or the adapter is set to 'Disable IPv6' in the registry, the cluster can't assign a valid network and you get 0x1726.
This often shows up after someone follows a 'performance tuning' guide that tells them to disable IPv6. Don't bother – the gain is negligible and it breaks clusters.
How to fix it
Re-enable IPv6 on the cluster network adapter. Open ncpa.cpl, right-click the adapter, go to Properties, and make sure the checkbox next to 'Internet Protocol Version 6 (TCP/IPv6)' is checked. Then reboot the node or restart the Cluster service.
If you've previously disabled IPv6 via the registry, you'll need to remove that override. Check this key:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\DisabledComponents
If the value is not 0, that's the culprit. Set it to 0 and reboot:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters' -Name DisabledComponents -Value 0
After the reboot, run Get-ClusterNetwork to confirm the error clears.
Cause 3: Stale Cluster Network Configuration
Sometimes the cluster network object in the cluster database is just out of sync. This happens after you remove a NIC, change a subnet, or move a node to a different VLAN. The cluster still thinks the old IPv6 subnet exists, and when the node comes up with the new one, you get 0x1726.
This is less common, but I've seen it on clusters that have been upgraded from Server 2012 R2 to 2016/2019 without cleaning up the network definitions.
How to fix it
First, validate the cluster network. In Failover Cluster Manager, right-click the network with the error and select 'Properties'. Check the IPv6 subnet address – if it looks wrong, you can edit it, but sometimes it won't let you.
If editing doesn't work, remove and re-add the network. But do this carefully – it will drop all dependencies on that network. Better to use PowerShell to force the cluster to re-discover the network:
Remove-ClusterNetwork -Name 'Cluster Network 1' -Force
Get-ClusterNetwork
Then let the cluster recreate it automatically. If it doesn't come back, restart the Cluster service on all nodes:
Restart-Service ClusSvc
If you're still stuck, check the cluster log for more details:
Get-ClusterLog -Destination C:\clusterlogs
Look for lines mentioning 0x1726 or INVALID_IPV6_NETWORK in the output. That'll point you to the exact NIC and subnet causing the grief.
Quick Reference Summary
| Cause | Symptom | Fix |
|---|---|---|
| IPv6 subnet mismatch | Different prefix lengths across nodes | Set matching PrefixLength on all nodes |
| IPv6 disabled on NIC | Adapter has IPv6 unchecked or DisabledComponents set | Re-enable IPv6, set DisabledComponents to 0 |
| Stale cluster network | Cluster shows old subnet after NIC changes | Remove cluster network, restart Cluster service |
Most of the time it's the first one – a simple prefix length mismatch. Check that before you go ripping out adapters. And remember, if you're in a pinch, you can always disable IPv6 cluster networks entirely (if your applications don't need them) by setting the network's role to 0 in cluster properties. But that's a band-aid, not a fix. Get the subnets aligned and you'll be done.