Microsoft Network Load Balancing (NLB) on VMware ESX

The other day I went into a Microsoft Network Load Balancing issue. The customer had configured a Microsoft NLB cluster in Unicast mode with 4 nodes (VMs) in a ESX farm. One could say it works out of the box, just go for the default configuration and voila.  Well not true in that particular ESX and physical network environments.

So let me explain the 2 main cast modes when deploying a NLB cluster:

  1. UNICAST mode

In Unicast mode, NLB reassigns the station MAC (media access control) address of the network adapter for which it is enabled and all cluster hosts are assigned the same MAC address. Unicast mode induces switch flooding, where all switch ports are flooded with NLB traffic, even ports to which non-NLB servers are attached. Since all hosts in the cluster have the same IP Address and the same MAC Address, there is no inter-host communication possible between the hosts configured in Unicast mode therefore a second NIC needed for other host communication. UNICAST requires you to modify the vSwitches in an ugly way. For more info check this VMware KB: Sample Configuration – Network Load Balancing (NLB) UNICAST Mode Configuration

  1. MULTICAST mode (prefered)

In multicast mode, NLB assigns a layer-2 multicast address to the cluster adapter instead of changing the adapter’s station address. Multicast allows inter-host communication because it adds a layer two multicast address to the cluster instead of changing it. This makes inter-host communication possible as the hosts retain their original unique MAC addresses and already have unique dedicated IP addresses. However, in multicast mode, the ARP reply sent out by a host in the cluster, in response to an ARP request, maps the clusters Unicast IP Address to its multicast MAC Address. Such a mapping in an ARP reply is rejected by some routers so administrators must add a static ARP entry in the router mapping the Cluster IP Address to its MAC Address. MULTICAST mode is by far the best one in my customer’s case, and in most scenarios as well IMO.

Here are the following steps to configure NLB in MULTICAST mode:

  1. Install Microsoft NLB and set MULTICAST mode (more at VMware KB 1006558)
  2. Disable DDNS/WINS. Network Load Balancing does not support dynamic Domain Name System (DNS) resolution, where the name of the cluster is automatically registered by the host when the host starts. This functionality must be disabled on the Network Load Balancing interface for both DNS and Windows Internet Name Service (WINS); otherwise, each host’s computer name will be registered with the cluster IP address. When using Network Load Balancing with DNS, you will need to directly configure the DNS server to register the name.
  3. Add a static ARP entry in your default router (more at VMware KB 1006525)
  4. Turn on MULTICAST support on your physical switches. If your switches do not support MULTICAST, you will have to setup Microsoft NLB in UNICAST mode.

About PiroNet

Didier Pironet is an independent blogger and freelancer with +15 years of IT industry experience. Didier is also a former VMware inc. employee where he specialised in Datacenter and Cloud Infrastructure products as well as Infrastructure, Operations and IT Business Management products. Didier is passionate about technologies and he is found to be a creative and a visionary thinker, expressing with passion and excitement, hopefully inspiring and enrolling people to innovation and change.
This entry was posted in Uncategorized. Bookmark the permalink.

13 Responses to Microsoft Network Load Balancing (NLB) on VMware ESX

  1. Pingback: Microsoft Network Load Balancing (NLB) on VMware ESX « DeinosCloud | IP

  2. Pingback: A Year Blogging In Summary And Season’s Greetings « DeinosCloud

  3. deinoscloud says:

    VMware just published an excellent KB regarding Microsoft NLB not working properly in Unicast Mode
    Worth a read!

  4. Darren says:

    Good Information. I am curious though, If you are adding the static arp on the cisco switch that binds that multicast address to a physical port on the switch, how do you accommodate for ESX redundancy if the ESX that is hosting the NLB cluster fails over to another ESX cluster member.. if that makes any sense.

    • Roy Kliewer says:

      adding a static arp only associates the MAC address to the IP address, it has nothing to do with switch ports. It is needed when the switch won’t learn the multicast MAC address from outbound packets.

  5. Farouk says:

    But which interfaces the mac-address-table static command should specify? we have a cluster with 6 ESX servers, 4 NIC each (wihin HP C3000 Blade enclosure) with DRS and HA enabled, so the NLB nodes can exists on any host.

    Should we in this case specify all the 6 x 4 ports on the interconnect switches? and if this is the case, doesnt this affect network performance as the NLB traffic will be broadcast to all the ports?

    Any comments?

  6. deinoscloud says:

    A great post from Ammesiah on this hot NLB topic (following my site stats). Worth a read at

  7. Pingback: A Year Of Blogging In Summary And Season’s Greetings | DeinosCloud

  8. PiroNet says:

    Ivan Pepelnjak just published a very good article explaining Microsoft NLB behind the scene. And if you don’t yet follow Ivan, I urge you to do so!

    You can read the article at

    Enjoy 😉

  9. Pingback: Exchange 2010 DAG & NLB « Exchange 2013, Lync 2013 & Office 365 | Ondrej Stefka's blog

  10. albertwt says:

    Thanks for sharing it here man !

  11. Mellon Straig says:

    “MULTICATS” instead of MULTICAST caught my eye. Shucks! But I found this information very useful. Thank you.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s