Network Load Balancing (NLB)

The GUI program is called NLBMGR.EXE, and a shortcut is present in the Administrative Tools menu. Care must be exercised when using both the GUI and the CLI to manage a cluster. NLBMGR.EXE does not refresh its cluster view, so if you perform a change via the CLI while it is active, it will have a stale view and will get confused. Clusters can be managed using both interfaces; however, make sure that you use only one interface at a time and whenever you use the CLI, make sure the GUI is not active.

Virtual Cluster

A very common deployment scenario for NLB cluster involves a large cluster with multiple applications sharing the resources. Until Windows Server 2003, such a cluster had a big inconvenience: it had only one VIP (Virtual IP) and one set of port rules. So it was not possible to separately administer the multiple applications. In Windows Server 2003, Microsoft adds the capability to have multiple VIPs assigned to one cluster, and each VIP in turn can have its own port rules and can be started and stopped independently.

note

When using the GUI to configure an NLB cluster, a distinction is made between the first cluster VIP and the additional cluster VIP. However, for application purposes, there are no differences and this is just a GUI oddity.

Because each VIP is actually a separate IP address and port rule, it's possible to have each IP registered under different names in DNS and therefore allow a service provider more discretion in segregating clients . Furthermore, because the port rules are independent, it's possible to tailor the port rule for the application, or even drain and stop load balancing of an application while other applications are unaffected.

Unicast Warning

NLB clusters have been designed from the beginning to use unicast IP addresses. Unfortunately, having multiple machines answer to the same IP unicast address is a misuse of the IP design ”multicast IP addresses were meant for that, but infrastructure limitations greatly diminish their usefulness . At the MAC (Media Access Control) layer, NLB allows use of either unicast or multicast addresses; however, infrastructure limitations also limit the widespread use of multicast MAC addresses. Because of those limitations, NLB has to accommodate unicast IP addresses and unicast MAC addresses. However, when doing so, it is possible to get into a situation where NLB cluster members cannot talk to one another. Because NLB cannot predict the future configuration changes, NLBMGR displays a worrisome message every time it is started on an NLB machine with all its NICs bound to NLB (see Figure 13.2). The message does not mean that the current setup has the problem, but rather that the current setup could have the problem if unicast MAC addresses are used.

IGMP Support

In an effort to improve the usefulness of multicast MAC addresses, Windows Server 2003 NLB has been modified to support IGMP (Internet Group Management Protocol) and attempt to solve the switch-flooding problem. Switches are L2 (Layer-2) snooping intelligent devices and associate a MAC address for a server with the port on which it is connected. Switches monitor the traffic passing through their ports to determine what MAC addresses are associated with a port, and then only forward traffic destined for that MAC address via that port. However, when a switch notices a multicast MAC address, it forwards the packets destined to that multicast address to all ports. This, in turn, defeats the purpose of a switch and potentially floods the downstream NICs with the traffic destined for the NLB hosts . Because NLB clusters are meant to service high volumes of requests , the amount of traffic that is forwarded to those nonNLB downstream nodes can be quite large and overwhelming. Hence, the name "switch flooding." Note that switch flooding does not occur if the NLB cluster members are the only nodes plugged into a switch or if using a nonintelligent device such as a hub.

IGMP is an IP specification used for communication between a set of computers and an upstream switch for the purpose of forming multicast groups. After the switch knows what ports to associate with a multicast group, it doesn't have to forward the multicast messages to other ports, and that prevents the flooding.

With the addition of IGMP support, NLB now also generates a multicast IP address to associate with the multicast MAC address. The MAC address used by NLB can be obtained using the NLB IP2MAC command:

E:\>nlb ip2mac 157.54.160.55

WLBS Cluster Control Utility V2.4 (c) 1997-2002 Microsoft Corporation.

Cluster:                 157.54.160.55

Unicast MAC:             02-bf-9d-36-a0-37

Multicast MAC:           03-bf-9d-36-a0-37

IGMP Multicast MAC:      01-00-5e-7f-a0-37

The multicast IP address and the multicast MAC addresses are related . The multicast MAC address generated by NLB is of the form 01-00-5e-xx-xx-xx . To determine the last three octets of the IP address, a multicast IP group address has to be chosen so that it will not interfere with the Internet traffic and also will not hinder any multicast applications that are running on hosts that are part of the subnet on which the NLB cluster resides. The address range 239.255.x.x is used because it's defined to be administratively scoped (that is, any IGMP join messages sent to an address in this range would not be forwarded by border gateway routers preventing interference with any traffic on the Internet).

note

IGMP support does not change anything with regard to the incompatibility between NLB clusters and layer-3 switches. Layer-3 switches should not be used to connect NLB cluster members.