Windows Network Load Balancing (NLB) is a pretty popular (free!) solution for quickly setting up load balancers.

You must chose either Unicast or Multicast operational mode.

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
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 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.

So which one should you chose? And why?

In general, you should enable and use multicast NLB whenever possible. Use unicast mode only if your network equipment—switches and routers—don’t support multicast or if they experience significant performance issues when multicast is enabled.

Other considerations

If you don’t have administrative access to modify the configuration of the switches and routers in your environment then you may be forced to use Unicast. You might also be forced to use Unicast if your routers do not support mapping a unicast IP to a multicast MAC address.
A second network adapter is required to provide peer-to-peer communication between cluster hosts in Unicast mode. A side effect of Unicast mode is “switch flooding;” network traffic is simultaneously delivered to all cluster hosts.

If you only have a single NIC, then it is recommended to use Multicast, but you will need to plan on adding a static ARP entry into the switches and routers on your LAN because most do not support multicast by default. This is easy to do in a small environment, but in a large routed environment, with multiple “side-car” routers then you would need to add an entry to each “side-car” router.
For example, on each Cisco router that has a “leg” into the LAN where the NLB cluster resides, enter configuration mode and enter these commands:

arp [ip] [cluster multicast mac*] ARPA
arp 192.168.1.100 03bf.c0a8.0164 ARPA
*the cluster’s multicast MAC address can be obtained from the Network Load Balancing Properties dialog box

By using the multicast method with Internet Group Membership Protocol (IGMP), you can limit switch flooding, if the switch supports IGMP snooping. IGMP snooping allows the switch to examine the contents of multicast packets and associate a port with a multicast address. Without IGMP snooping, switches might require additional configuration to tell the switch which ports to use for the multicast traffic. Otherwise, switch flooding occurs, as with the unicast method. Here are the commands to tell the switch which ports to use for multicast traffic:

mac-address-table static [cluster multicast mac] [vlan id] [interface]
mac-address-table static 03bf.c0a8.0164 vlan 1 interface GigabitEthernet1/1 GigabitEthernet1/2

[Update 2/16/2013]

Note: the highlighted section above is fantastic when your environment is fairly static, however, if your NLB hosts are virtual machines, and if those virtual machines reside in an NLB cluster, then the above hardcoded configuration will prevent the NLB nodes from converging when the virtual machines are migrated to other hypervisors in the cluster. This is because the other hypervisor nodes are connected to the switch via separate ports than those hardcoded above. And you can’t hardcode all the hypervisor nodes in advance because the VM’s don’t reside on all nodes at the same time. Therefore, I recommend avoiding using the mac-address-table command and relying only on the arp command.