Balancing Act – What you really ought to know about Windows Server NLB


Managing the multiple data streams comprising today’s enterprise networks can turn into a digital balancing act.  This blog series hopes to assist you in achieving that “Zen-like” symbiosis that we all want.  Like most tools, NLB can be very effective if understood and used properly.  Let’s look at 5 of the top support call generators related to NLB…

1. What’s the deal with NLB and Layer 3 Switches? – First of all, know that NLB can run into issues when servers in an NLB cluster are plugged directly into a layer 3 switch (a switch that makes routing decisions based on source/destination IP addresses rather than MAC addresses).  This potential incompatibility stems from some “smart” switches ability to break NLB’s Mask Source MAC functionality.  When this happens, all traffic destined for the NLB cluster gets forwarded to a single port and a single cluster host.  What you really ought to know is that although this is a known issue, there are ways to utilize layer 3 switches effectively with NLB.  Some layer 3 switches can be “dumbed down” to operate at layer 2.  A second approach would be to plug the NLB cluster directly into a layer 2 switch which then uplinks to your layer 3 switch.  An old fashioned hub could also be substituted for your layer 3 switch if you have one around.  This eliminates the issue as the hub will simply forward all the traffic out all of its ports.  If you’re going to use a hub, keep everyone else off this subnet as the broadcast traffic will negatively impact bandwidth available to any other non-NLB nodes on the subnet.

2. Multicast vs Unicast – Multicast represents one of two possible configurations for your NLB cluster.  When you choose a Multicast configuration, the NLB host actually has two MAC addresses — its own specific host MAC address (i.e. the actual hardware MAC for the NIC) as well as a NLB cluster virtual MAC address.  NOTE: All nodes in a single NLB cluster must use the same option!  Because of this method of MAC addressing, individual hosts in a single NLB cluster can communicate with each other, even if there is a single network card in the server.  When Unicast mode is enabled, each host uses the same NLB cluster MAC address.  When a host goes to send traffic to another NLB host it recognizes the destination MAC address as its source MAC address.  The data never leaves the network card and thus never arrives at the intended destination.  What you really ought to know is that Microsoft Knowledge Base article KB898867 changed things for the better.  Using a key called “UnicastInterHostCommSupport” Unicast NLB nodes configured with this registry value send data to other NLB nodes using a multicast MAC address. This gets us around the issue of having a single, shared MAC address.  As the traffic never hits the router, this doesn’t cause any issues there.  As a result, unicast mode works fine for the vast majority of NLB cluster configurations, single NIC or not.

3. Why isn’t this thing balancing? – NLB doesn’t operate on the “One for me, one for you!” principle.  What you really ought to know is that the more hosts that connect to your NLB cluster, the better “balanced” or evenly distributed your client connections will be.  The skinny here is that NLB uses a proprietary Microsoft algorithm to balance host connections (unfortunately, no, it isn’t published for public consumption).  Factors such as the Weight setting you configure for each NLB cluster host and your Affinity setting affect the number of connections that each NLB cluster host handles at any given time.  NLB does NOT dynamically adjust the number of connections each cluster hosts handles based on the current client load.  For many deployments, NLB’s load balancing metrics are more than adequate.  Just understand what you should expect up front and choose the right solution based on your need.

4. NIC teaming and NLB (Not a match made in heaven) – Network card teaming allows you to improve your data throughput and performance in some server configurations.  Microsoft Knowledge Base Article KB278431 refers to something you really ought to know, however.  The bottom line is that the teaming driver and the NLB driver reside at approximately the same level in the TCPIP stack.  As a result, NLB and Windows clusters in general have known issues with network card teams.  This is a classic example of the necessity to keep network card drivers updated.  Known issues may sometimes be resolved via a simple driver update for current network cards so try that first.  In the event that you are troubleshooting an issue with Microsoft support, understand we might have to break the network card team in order to rule out teaming.  Another option is to configure the cluster for Multicast mode.  By using the actual hardware MAC address, these issues can be resolved.

5. Simple yet effective – NLB was designed back when NetBIOS still ruled the day.  NLB makes filtering decisions based on the port rules configured on the cluster.  NLB runs regardless of any applications it may be supporting.  If IIS restarts or is otherwise unavailable, NLB continues to forward client requests blissfully unaware of the service failure (See SCOM 2007 below):

Network Load Balancing automatically detects and recovers when the entire server fails or is manually disconnected from the network.  However, Network Load Balancing is unaware of the applications and services running on the cluster, and it does not detect failed applications or services.  To provide awareness of application or service failures, you need to add management software, such as Systems Center Operations Manager.

NLB in and of itself does NOT provide application monitoring or awareness.  However, Microsoft does now offer a solution when integrated with SCOM 2007 via the NLB Management Pack.  For more information, please see or  In some situations, you may need a hardware load balancer.  This is where doing your homework will pay off.  Doing your due diligence up front when designing a load balanced solution is the right answer.  As always, test your solution in a lab environment and engage Microsoft Consulting Services (MCS) if you want some outside assistance; but know the limits of the solution before going live.

– Pete Sullivan