You're running a Windows Server Failover Cluster, and suddenly the cluster starts acting up. You check the cluster events and see error 0XC0130010 with the message "The cluster network is not valid." This usually shows up when you're adding a new node, changing IP addresses, or after a network adapter gets renamed. For example, you just replaced a NIC on one node and gave it a different name, but the cluster still thinks the old name exists. That mismatch is a classic trigger.
What's actually going on?
The cluster keeps a list of networks it knows about. Each network is tied to a subnet and a set of adapters. When the cluster can't match a physical adapter to a configured network, it marks that network as invalid. The most common reasons are:
- An adapter was disabled or removed without properly removing it from cluster use.
- You changed the IP address or subnet mask on a node, and the cluster network no longer matches any physical subnet.
- You have multiple NICs on the same subnet, and the cluster gets confused about which one is which.
The real fix is to identify which network is invalid, check its settings against the actual hardware, and either correct the settings or remove the stale network object.
Step-by-step fix
Step 1: Open Failover Cluster Manager
Log on to a node that has the Failover Cluster Management tool installed. Open Server Manager, then click Tools and select Failover Cluster Manager. You should see your cluster listed. If not, right-click and choose Connect to Cluster, then type the cluster name.
After the manager loads, you'll see the cluster home page. Click on Networks in the left tree. This shows all the networks the cluster is tracking.
Expected: You'll see a list of networks. Look for one with a status of "Invalid" or "Not Available". That's your problem child.
Step 2: Identify the invalid network
In the Networks list, each entry shows the name, status, and subnet. Find the one that says Invalid. Right-click it and select Properties.
In the Properties window, go to the General tab. Note the name and the subnet. Also check the Network Interfaces tab. It lists which adapters on which nodes are supposed to be part of this network. If you see no adapters listed, that's a big clue—the cluster thinks the network exists, but no physical adapter is attached to it.
Step 3: Compare with actual adapters
On each node, open a Command Prompt (run as administrator) and type:
ipconfig /allLook for the subnet that matches the invalid network. Make sure at least one NIC on a node has an IP address in that subnet. If not, you need to either assign an IP in that subnet or remove the network from the cluster.
Also, check the adapter names. Open Network Connections (ncpa.cpl) on each node and see the adapter names. The cluster network interface names should match the adapter names. If you renamed an adapter after the cluster was created, the cluster might still reference the old name.
Step 4: Fix the network settings
If the subnet is still in use but the network name is wrong, rename it in the properties. Right-click the network, go to Properties, and change the name to something meaningful like "Cluster_1". Also, make sure the Allow cluster network communication on this network checkbox is checked, and the Client access checkboxes are set appropriately (usually only for the network that hosts client IPs).
If the subnet isn't used anymore, you should remove the network. Right-click the network and choose Remove. The cluster won't let you remove a network that has client access points on it. If that's the case, you'll need to move those resources to another network first. That's a more involved process, but it's rare.
Step 5: Validate the cluster
After making changes, run a validation. In Failover Cluster Manager, right-click the cluster name and select Validate Cluster. This runs a series of tests, including network checks. It takes a few minutes. The report will tell you if the network issue is resolved.
Step 6: Restart the Cluster Service (if needed)
Sometimes a fresh start clears up the confusion. On each node, you can restart the Cluster Service. Open an elevated PowerShell and run:
Restart-Service ClusSvcDo this on one node at a time, waiting for the cluster to be healthy between nodes. This kicks the cluster to re-enumerate networks.
Still failing? Check these things
- Check cluster events. Open Event Viewer, go to Windows Logs > System, and look for source "Microsoft-Windows-FailoverClustering". The event details will often point to the specific network.
- Check for duplicate subnets. If you have two different VLANs using the same subnet but different gateway IPs, the cluster gets confused. Make sure no two cluster networks share the same IP subnet.
- Check the cluster database. In rare cases, the cluster database gets corrupted. You can export the configuration and compare with a healthy node. That's a deeper dive, but if nothing else works, it's worth a look.
The key takeaway: this error is almost always a mismatch between what the cluster thinks its networks look like and what the physical adapters actually look like. Identify that mismatch, correct it, and you're back in business.