Transcript Troubleshooting Network Communications

Troubleshooting Network
Communications

Depending on
the symptom,
you may have
to troubleshoot
node-to-node
or client-tonode
communication
s.

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 networkrelated problems requires different
approaches.
Troubleshooting Node-toNode 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 www.microsoft.com. This tool verifies that
Windows 2000 Server services are responding to the
call requests of remote procedures between nodes.
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.
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.
Troubleshooting Client-toNode 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.
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.
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.
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.

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