Sharing IP address among cluster nodes leads to network issues

A Network Load Balancing cluster uses two IP addresses. One of these addresses is unique to each node in the cluster; the other is shared among all the nodes.

However, one fundamental rule of the TCP/IP protocol

    Requires Free Membership to View

is that you cannot use the same IP address on more than one computer; if you do, an IP address conflict occurs. So sharing an IP address among the nodes in the cluster can lead to some tricky networking issues.

This article will look at some of these issues are and how they affect your cluster.

A Network Load Balancing cluster employs a fairly simple architecture. Because each server in the cluster contains its own copy of the hosted application, you don't have to worry about creating a SAN that can be used to provide shared storage to the cluster nodes. Although no special hardware is required, the nodes in a Network Load Balancing cluster can usually benefit from having a second network card installed in each cluster node.

To understand why this is so, you need to appreciate the difference between how cluster nodes operate in unicast mode and multicast mode.

Unicast mode is used when each cluster node contains only a single NIC. A NIC has a unique Media Access Control (MAC) address that identifies that NIC on the network. Just as nodes in a Network Load Balancing cluster must share a common IP address, they must also share a common MAC address.

When a cluster is functioning in unicast mode, each NIC's unique MAC address is replaced by the cluster's shared MAC address. When this happens, the server's physical MAC address is not used at all. Instead, both the unique IP address and the shared IP address are both mapped to the shared MAC address on each node.

The effect of running the cluster in unicast mode is that cluster nodes are not able to communicate with each other using their physical MAC address. This means you can't use the Network Load Balancing Manager to manage the nodes in the cluster. However, nodes are able to communicate with other computers outside the cluster so long as the IP datagrams do not use the cluster's MAC address.

If you don't need to run the Network Load Balancing Manager application, running in unicast mode may not pose a problem. After all, if each node in the cluster is running an identical copy of an application, cluster nodes may not need to communicate with each other. But if you do need the cluster nodes to communicate with each other or you need to run the Network Load Balancing Manager, you have two options.

1. Configure the cluster to operate in multicast mode. The difference between unicast mode and multicast mode on cluster nodes with single NICs is that the cluster's MAC address is assigned to the NIC, but the NIC also retains its original MAC address.

With this configuration, the cluster's IP address is bound to the cluster MAC address, and the server's individual IP address is bound to the physical MAC address. The caveat here is that network routers must support multicast MAC addresses.

2. Install a second NIC into each of the cluster nodes. In this configuration, one of the NICs has its physical MAC address replaced by the cluster's MAC address. The cluster's IP addresses bound to the NIC that uses the cluster's MAC address. Reminder: If the server is running in unicast mode, it cannot communicate with other nodes in the cluster.

This is not to say that the server cannot communicate with other cluster nodes. The server's second NIC retains its original physical address, and is bound to a unique IP address. This NIC is used for in all non-cluster related communications.

You can configure the Network Load Balancing cluster nodes to use either unicast or multicast mode. Just be consistent. No matter which mode you choose, you must use the same load on all cluster nodes. It's possible to have some cluster nodes with a single NIC, while other nodes have two NICs. However, if the cluster is running in unicast mode, then cluster nodes with only a single NIC will not be able to communicate with other servers.

About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He writes regularly for SearchWinComputing.com and other TechTarget sites.

More information on this topic:

This was first published in November 2006

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.