Fix cluster network interface already exists (0xC0130008)

You're building a Windows Failover Cluster, you run the Add-Node wizard or use the PowerShell Add-ClusterNode cmdlet, and boom — error 0xC0130008 with the message "The cluster network interface already exists." This usually happens when you've previously removed a node from the cluster but didn't clean up its network interface entries. Or if you're adding a node back that had a network adapter with the same name as one still registered in the cluster database.

What's actually happening here is that when a node joins a cluster, Windows registers each physical network adapter's name (like "Ethernet" or "Ethernet 2") as a cluster network interface object inside the cluster database. Even after you evict the node, these interface objects can linger if the eviction wasn't clean — say, if the node crashed or the cluster service was forced down. So when you try to re-add that node with the same adapter name, the cluster sees a duplicate and refuses.

The Root Cause

The cluster database holds a list of all network interfaces for all nodes that have ever joined, indexed by their adapter name. No two interfaces in the same cluster can share the same name. This is by design — it prevents confusion when routing cluster heartbeat traffic. But it also means you can't just re-add a node with the same adapter name unless you delete the stale entry first.

Fix: Remove the Stale Network Interface Entry

You have two options. Option 1 is the clean way using PowerShell. Option 2 is the nuclear option — force-remove the node from the cluster database entirely. I prefer Option 1 because it's surgical.

Option 1: Remove Just the Network Interface (Recommended)

1. Log into any existing node in the cluster with an account that has cluster admin rights.
2. Open PowerShell as Administrator.
3. Run Get-ClusterNetworkInterface | Format-Table -AutoSize to list all interfaces. Look for the interface name that matches the problematic adapter on the node you're adding. It'll show something like Node1 - Ethernet.
4. Once you've identified the stale interface, remove it with:
   

   Remove-ClusterResource -Name "NodeName - InterfaceName" -Force

   Replace NodeName - InterfaceName with the exact name from step 3. For example:
   

   Remove-ClusterResource -Name "OldNode - Ethernet" -Force

5. Now retry adding the node. The error should be gone.

Why this works: The -Force flag deletes the resource even if it's not in an offline state. The cluster will recreate the interface fresh when the node joins again.

Option 2: Force-Evict the Node and Re-Add

If you don't know which interface is stale — maybe the node was removed months ago and you don't have logs — you can blow away the entire node from the cluster database.

1. On a current cluster node, open PowerShell as Admin.
2. Run:
   

   Remove-ClusterNode -Name "OldNodeName" -Force

   This removes the node and all its associated resources, including network interfaces.
3. Add the node back normally with Add-ClusterNode -Name "OldNodeName".

Warning: This is aggressive. If the node had any cluster roles (like a file share witness or disk witness), those get wiped too. Only do this if you're sure the node isn't running anything critical.

What to Check If It Still Fails

If you've removed the interface but the error comes back, check these:

• Did you remove the right interface? Run Get-ClusterNetworkInterface again and double-check the name. It's case-insensitive but must match exactly.
• Is the node already in the cluster database? Run Get-ClusterNode to list all nodes. If the problematic node shows up there (even if it's down), you need to evict it first. The interface error can mask a deeper "node exists" problem.
• Did you rename the network adapter? If you changed the adapter's name (like from "Ethernet" to "Cluster-Heartbeat") on the node before re-adding it, the cluster might still see the old name in its database. In that case, remove the old interface name from the cluster as described in Option 1.
• Check cluster logs. Run Get-ClusterLog -Destination C:\Temp -TimeSpan 30 on an existing node, then look through the generated log files for lines containing "0xC0130008" or "network interface." That'll tell you exactly which interface is causing the conflict.

One more thing: if you're in a hurry and the node you're adding is freshly installed (no old cluster remnants), you can also try renaming the network adapter on that node to something unique (like "Ethernet-New") and then adding it. The cluster won't see a duplicate because the name is new. Once the node joins, you can rename the adapter back — the cluster won't complain after the fact.

I've seen this error most commonly after a node was evicted via the Failover Cluster Manager GUI but the interface wasn't cleaned up. The GUI is fine, but it doesn't always purge orphaned resources. PowerShell is more reliable here.