1. Troubleshooting Network Communications
Depending on the symptom, you may have to troubleshoot node-to-node or client-to-node communications.

2. There are two types of cluster network communications that can fail: the client may be unable to access the cluster or the nodes may be unable to communicate with each other. When client communications are interrupted, there is a problem with the public network. When the nodes are unable to communicate, there is a problem with either the public or the private network. Troubleshooting these two types of network-related problems requires different approaches.

3. Troubleshooting Node-to-Node Communications
You can use Windows 2000 Network Monitor before installing Cluster service to capture the trace of the ping between the nodes on the public and private network. After Cluster service is installed, you use Network Monitor to verify remote procedure call (RPC) communication and cluster heartbeats.
Note: You can also use RPC Ping, which is an RPC connectivity verification tool that is a free download from This tool verifies that Windows 2000 Server services are responding to the call requests of remote procedures between nodes.

4. Verifying RPC Communication
To verify that RPC communication is occurring between the nodes of a cluster, use a network capture utility, such as Microsoft Network Monitor. Windows 2000 Server includes a simple version of Network Monitor that you can install by using the Network program in Control Panel.
To verify RPC communication, configure the Capture utility to capture all of the traffic between the nodes of a cluster. After you have started a capture, using Cluster Administrator to create a group or resource will result in RPC traffic between the nodes.

5. Verifying Cluster Heartbeats
As with RPC communication, to verify that cluster heartbeats are occurring between the nodes of a cluster, you must use a network capture utility.
Cluster service uses User Datagram Protocol (UDP) port 3343 to send heartbeats on the network. Use Network Monitor to capture port 3343 to verify both nodes of the cluster are sending and receiving cluster heartbeats.

6. Troubleshooting Client-to-Node Communications
After a failover occurs, clients must still be able to gain access to a cluster, even though they will be accessing a different node. The client must be able to resolve any cluster network names so that they will always connect to the node on which the resources are online. If clients cannot connect to virtual servers, verify that:
The client is accessing the cluster by using the correct network name or IP address.
The client has the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol correctly installed and configured.

7. Check NetBT Cache with Nbtstat
Depending on the resource that is being accessed, the client can address the cluster by specifying either the resource network name or the IP address. In the case of the network name, you can verify proper name resolution by checking the NetBT cache (using the Nbtstat.exe utility) to determine whether the name had been previously resolved. Also, confirm proper Windows Internet Name Service (WINS) configuration, at the client and at the cluster nodes.

8. Ping IP Address Using Ping Utility
If the client is accessing the resource through a specific IP address, ping the IP address of the cluster resource and cluster nodes from a command prompt.

9. WINS Static Mappings
You should not create static network name to IP address mappings for any cluster names in a WINS database. WINS is the only name resolution method that will cause problems when using static mappings, because WINS static mappings use the media access control (MAC) address of the network card as part of the static mapping.

10. If clients are having a problem connecting to a virtual server, an administrator might have created a WINS static mapping for a virtual server. The node for which the mapping is created will be able to bring the network name resource online and clients will be able to connect. However, if failover occurs, the second node in the cluster will be able to bring the IP address online but not the network name. When the second node attempts to bring the network name online, WINS will return an error preventing it from registering the network name. WINS prevents the network name from going online because the second node does not have the same physical address as the one recorded in the static mapping for the network name.