Microsoft's Network Load Balancing has been the low-cost option of choice for network administrators looking to gain either more performance or high availability. Although it doesn't have a lot of the bells and whistles that the dedicated appliance-based load-balancers have, the price is sure right (assuming you have a license for Windows Server). However, there are some things every server administrator should know about how network switches work before you go and configure NLB.
When a switch receives a frame, it makes the decision about which port to forward it out on based on the destination MAC address in that frame. Most regular SearchNetworking readers are already well aware of this. In order to make intelligent decisions, the switch maintains what most of the world calls a "forwarding database" (FDB), which is a list of all its ports, and what MAC addresses reside beyond each port. Again, I know this isn't breaking news, but bear with me. Now, realize that the FDB entries aren't configured by network engineers, like, say, IP subnets are configured on router interfaces. The switch populates the FDB dynamically by snooping on frames as they come from each port and keeping track of the Source MAC addresses. So, when a switch has seen a particular MAC address come from a particular port, it will "forward" all frames destined to that MAC address to that port. But, and this is crucial to understand, if the switch has never seen a specific MAC address before, then it will "flood" that frame to ALL ports on the switch, except of course, the port the frame came in on. (This is normal operation for instance, when the switch first boots up.)
What does this have to do with NLB? Glad you asked...
The way Microsoft's NLB operates (always for Windows 2000, and by default for Windows 2003) is to send outbound traffic using a MAC address that is not the same as the MAC address it sends in its ARP Response. The result is, that the inbound traffic is coming to a MAC address that does not exist in the switch's FDB, so the switch floods this traffic to ALL ports, which allows all the servers in the cluster to receive and then decide who gets to process the packets. Now, you may be thinking "My, that's pretty clever!" but before you get too excited, you should consider the implications for your network design.
First, what about all the other servers on your switch? How much traffic will they see and will this be a problem?
Second, what about security? Do you want systems connected to other ports receiving all the packets being sent to the cluster? Or... what if some evil hacker periodically forges a packet with the source address of your cluster and fools the switch into redirecting all the traffic away from the cluster? That would not be fun to troubleshoot.
Third, what about the rest of the network? Heaven forbid you're one of those admins who stick servers on the core of the network... will all this spam be sent to every switch and every user in the network too?
If you're currently using this technology, I highly recommend upgrading to Windows 2003, which supports NLB based on multicast. If 2003 isn't in your immediate future, you can address some of these concerns by reading the "best practices" documents on Microsoft.com.
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex.
