Cluster Help : Network Load Balancing

Exchange Server 2007 Hub Transport (HT) and Client Access Service (CAS) on the Same NLB Cluster - Updated Jan 9, 2008

cluster — Fri, 05 Oct 2007 15:47:00 GMT

In order to keep the number of servers down in a high availability environment, administrators have been looking at using Network Load Balancing (NLB) for CAS and then co-locating the HT role on each node of the NLB cluster to also provide high availability...(read more)

Network Load Balancing and MAC Addresses

cluster — Sun, 25 Jun 2006 03:40:00 GMT

I learned something new yesterday. It kind of flipped me out, but now it almost makes sense. You can try this to confirm. From a client, ping the IP address of your NLB cluster. From the same client, run arp -a fom the command prompt. You should see something...(read more)

Network Load Balancing (NLB) and Network Interface Card (NIC) Teaming

cluster — Tue, 06 Jun 2006 03:48:00 GMT

The quick summary of this post is, "Don't use NLB on teamed NICs."

Microsoft clearly says that NIC teaming "may" cause problems with NLB in KB 278431.

This is where things get confusing, because the issue is just that; it may be a problem. The reasoning is really fairly simple. Teaming software, in many cases, overwrites the MAC address of the individual NICs in the team. Well, NLB, in Unicast, also overwrites the MAC address. So, the problem is:

Will the teaming software allow the overwrite behavior of Unicast?
Will the teaming software handle the failure of a NIC in the team and the overwrite process of NLB in the event of a NIC failure?

The answers are, it might not allow the overwrite in Unicast, and it might not behave properly in the event of a NIC failure and passing of the MAC to the other NIC in the team. Thus, the "may" statement earlier.

The way it needs to work is that teaming software for NICs nees to support the overwrite of MAC addresses. Many vendors do now provide this support. A workaround exists allowing the team MAC address to be set directly through the management tool. Compaq/HP, for example, defaults to the MAC address of the primary adapter. After NLB sets the MAC on the virtual adapter (the NIC team), the Compaq/HP software does not propagate the MAC address to the physical adapters. To make it work, you have to copy the NLB MAC and paste it into the team MAC in the management software. Workarounds and High Availability environments can not be used in the same sentence, thus, this is not a best practice.

My contention is simple: Since we can't guarantee transparncy of failure of the team and how it allows NLB overwrites of the MAC (this is a hardware driver issue that Microsoft can not guarantee will behave properly), it should be considered a best practice to not use teaming for NLB NICs.

By the way, this behavior does not change in Longhorn.

Unicast vs. Multicast - Original Posted Feb 21, 2005

cluster — Sun, 07 Aug 2005 16:33:00 GMT

As usual, confusion motivates me to blog some more. In this case, I have blogged this because I was confused, and I am pretty sure that I have it straight now. Comments may prove me wrong.

When designing, planning, testing, and implementing Network Load Balancing (NLB) Clustering, a choice has to be made regarding unicast vs. multicast. There are a few differences, but the main difference is in the way MAC addresses are implemented.

Unicast - Each NLB cluster node replaces its real (hard coded) MAC address with a new one (generated by the NLB software) and each node in the NLB cluster uses the same (virtual) MAC. Because of this virtual MAC being used by multiple computers, a switch is not able to learn the port for the virtual NLB cluster MAC and is forced to send the packets destined for the NLB MAC to all ports of a switch to make sure packets get to the right destination.

So, basically, the way NLB traffic is handled is kind of like this:

1. An inbound packet for IP address w.x.y.z (NLB Virtual IP) arrives
2. The ARP request is generated and is sent across all ports of the switch since there is no mapping at this point
3. All of the NLB cluster nodes respond with the same MAC
4. The switch sends the traffic to all ports because it is not able to tell which is the proper port and this leads to switch flooding

If an NLB cluster node is using unicast, NLB isn't able to tell each node apart as they all have the same MAC. Since each NLB cluster node has the same MAC, communication between NLB cluster nodes is not possible unless each NLB cluster node has an additional NIC with a unique MAC.

Multicast - NLB adds a layer 2 MAC address to the NIC of each node. Each NLB cluster node basically has two MAC addresses, its real one and its NLB generated address. With multicast, you can create static entries in the switch so that it sends the packets only to members of the NLB cluster. Mapping the address to the ports being used by the NLB cluster stops all ports from being flooded. Only the mapped ports will receive the the packets for the NLB cluster instead of all ports in the switch. If you don't create the static entries, it will cause switch flooding just like in unicast.

Flooding Solutions:

Hook all NLB devices to a hub and then connect it to a port on the switch. Since all NLB nodes with the same MAC come through the same port, there is no switch port flooding.
Configure a VLAN for all NLB cluster nodes to contain all NLB cluster traffic to just the VLAN and not run it over the entire switch.
Use multicast and configure static mapping for the NLB cluster nodes in the switch so it only floods the mapped ports instead of the entire switch.
Use port mirroring so that all ports involved in the NLB cluster mirror each other.

NLB Unicast vs. Multicast - Original Posted Feb 21, 2005

cluster — Fri, 05 Aug 2005 18:48:00 GMT

As usual, confusion motivates me to blog some more. In this case, I have blogged this because I was confused, and I am pretty sure that I have it straight now. Comments may prove me wrong.

So, basically, the way NLB traffic is handled is kind of like this:

Flooding Solutions:
1. Hook all NLB devices to a hub and then connect it to a port on the switch. Since all NLB nodes with the same MAC come through the same port, there is no switch port flooding.
2. Configure a VLAN for all NLB cluster nodes to contain all NLB cluster traffic to just the VLAN and not run it over the entire switch.
3. Use multicast and configure static mapping for the NLB cluster nodes in the switch so it only floods the mapped ports instead of the entire switch.