Fix Cluster Node Unreachable 0X000013BB

You're looking at the cluster management console, and one node shows as Unreachable with error 0X000013BB. This usually happens after a reboot, a network switch change, or when you add a node to a cluster. The node you're on can see itself fine, but the other node just won't connect. It's not a hardware failure yet—it's almost always a network or firewall problem.

The root cause is simple: the cluster heartbeat can't get through. Windows Failover Cluster uses a private network for node-to-node communication. If that network is down, misconfigured, or blocked, the cluster service on the other node appears dead. The error code 0X000013BB just means "I can't reach you."

Fix: Check Network Connectivity

Open PowerShell as Administrator on the node showing the error. Right-click Start, select Windows PowerShell (Admin).
Test basic connectivity. Run:
```
ping <IP of the other node>
```
Replace <IP of the other node> with the actual IP address of the unreachable node. If you don't see replies, the network is broken. Check cables, switches, and VLAN assignments.
If ping works, test the cluster port. The cluster heartbeat uses port 3343 (for older clusters) and port 445 (for newer ones). Run:
```
Test-NetConnection -ComputerName <IP of other node> -Port 3343
```
Then also:
```
Test-NetConnection -ComputerName <IP of other node> -Port 445
```
After each command, you should see TcpTestSucceeded : True. If it says False, the firewall is blocking the port.
Check Windows Firewall. On both nodes, open Windows Defender Firewall with Advanced Security. Look for inbound rules that allow:
- Failover Cluster (TCP-In) – port 3343
- File and Printer Sharing (SMB-In) – port 445
If these rules are missing, create them. Or temporarily disable the firewall on both nodes to test:
```
netsh advfirewall set allprofiles state off
```
Do this on both nodes. After testing, turn it back on:
```
netsh advfirewall set allprofiles state on
```
Important: Never leave the firewall off in production. This is just a test.
Verify cluster network priority. In Failover Cluster Manager, go to Networks. Right-click the network used for cluster communication and select Properties. Make sure "Allow cluster network communication on this network" is checked. Also ensure it's set to a higher metric than other networks (lower number = higher priority).
Restart the Cluster service on both nodes. In PowerShell (Admin) on each node:
```
Stop-Service ClusSvc
Start-Service ClusSvc
```
Wait 30 seconds after starting on the first node, then start on the second. After restarting both, check the cluster manager—the node should come back online.

After these steps, the Unreachable status usually clears. If it doesn't, you've got a more stubborn issue.

If It Still Fails

Look at the event logs. On both nodes, open Event Viewer, go to Windows Logs > System, and filter by source ClusSvc. You'll see errors with more detail. Common deeper problems:

Different cluster versions. One node runs Windows Server 2019, the other runs 2022. Mixing versions can break the heartbeat. Upgrade or downgrade to match.
DNS issues. The cluster uses DNS to resolve node names. Run nslookup <nodename> on each node. If they don't resolve the other node's IP, fix DNS.
Multipath or NIC teaming. If you have two NICs on the same subnet without proper teaming, the cluster gets confused. Disable one NIC and try again.
Time sync. Different system times on nodes cause authentication failures. Check w32tm /query /status on both—they should be within 5 minutes of each other.

One last thing: if you're using a third-party firewall like McAfee or Symantec, it may block cluster traffic even when Windows Firewall is off. Check those logs too. I've seen cases where the antivirus firewall was the culprit for weeks.