I recently came across a few issues configuring Network Load Balancing (NLB) on two Windows 2008 R2 Hyper-V VMs running IIS and MySql as a hosting solution for 100+ medium traffic WordPress sites to be migrated over after testing.
Installation and configuration of NLB went fine, and the cluster was initially configured as multicast. This worked fine, until I went to go test connectivity from the outside world - no respone. Turns out, the gateway on this network was (correctly) set to not relay multicast packets. Unfortunately, creating static routes on this gateway was not an option, so it was going to have to be unicast. Not a problem - I shut the machines down, added another virtual ethernet adapter, and reconfigured NLB to use the dedicated second adapter. Windows 2008 R2 and 2012 Hyper-V hosts are now set to block VM MAC address spoofing by default, so that needed to be enabled for that second adapter.
All's well and good - WordPress sets up, everything works... until I log into WordPress and find that it can't retrieve any external info (themes, plugins, WordPress news, etc.) Because of the way NLB works in unicast mode, each site was trying to use the adapter it was bound to (the dedicated NLB adapter), which because of the spoofed identical MAC addresses, couldn't guarantee that the response would come back to the machine that generated it.
The following commands, courtsey of The Cable Guy, cleared this issue up:
netsh interface ipv4 set interface {NLB adapter}
weakhostsend=enabled
netsh interface ipv4 set interface {NLB adapter}
weakhostreceive=enabled
netsh interface ipv4 set interface {NLB
adapter}ignoredefaultroutes=enabled
...in addition to going into Advanced Settings from the Network Connections list and setting the Management adapter as a higher priority than the NLB adapter.
The first two commands reenable weak binding, while the third command allows outgoing traffic to go out over the non-load balanced adapter, based upon the order of the connections (and guaranteeing it would come back to that specific machine).
Upon further testing, this solution did not work for the given scenario. NLB is an outdated solution with flaws, but for a while it was the only game in town (on the cheap end). As stated in the setup docs, NLB creates a massive amount of multicast data in this mode. The network configuration is unfortunately large and flat, and this configuration generated multicast storms of each and every request. On an isolated VLAN, this could work, but at that point, you might as well have gone in another direction. Also, upload speeds are hobbled because of how much traffic is created with incoming packets.
Dedicated load balancers and proxy servers are much better for keeping large amounts of web data highly available. Physical devices are expensive but well-designed. Even a lightweight software solution like Squid on quality hardware would fit the bill, plus you get the added benefit of offloading caching and compression to the proxy server, but you lose the ease of a single-point SSL configuration that the better featured physical devices include and instead have to pass encrypted traffic straight-through. Luckily, IIS >= 8 has that covered.