Create a new Network Load Balancing Port Rule
Applies To: Windows Server 2008 R2
Port rules control how a Network Load Balancing (NLB) cluster functions. To maximize control of various types of TCP/IP traffic, you can set up port rules to control how each port's cluster-network traffic is handled. The method by which a port's network traffic is handled is called its filtering mode. There are three possible filtering modes: Multiple hosts, Single host, and Disabled.
You can also specify that a filtering mode apply to a numerical range of ports. You do this by defining a port rule with a set of configuration parameters that define the filtering mode. Each rule consists of the following configuration parameters:
The virtual IP address that the rule should apply to
The TCP or UDP port range that this rule should apply to
The protocols that this rule should apply to, including TCP, UDP, or both
The filtering mode that specifies how the cluster handles traffic, which is described by the port range and the protocols
In addition, you can select one of three options for client affinity: None, Single, or Network. Single and Network are used to ensure that all network traffic from a particular client is directed to the same cluster host. To allow NLB to properly handle IP fragments, you should avoid using None when you select UDP or Both for your protocol setting. As an extension to the Single and Network options, you can configure a time-out setting to preserve client affinity when the configuration of an NLB cluster is changed. This extension also allows clients to keep affinity to a cluster host even if there are no active, existing connections from the client to the host.
By default, all cluster network traffic that is not governed by port rules is handled by the host with the highest host priority among the current members of the cluster. This single host handles all of the cluster network traffic, with another host taking over the traffic if the highest priority host fails or goes offline. This default behavior ensures that NLB does not affect cluster network traffic for ports that you do not specifically manage with the NLB load-balancing mechanisms. It also provides high availability in handling your cluster network traffic.
You can also perform the task described in this procedure by using Windows PowerShell. For more information about using Windows PowerShell for NLB clusters, see http://go.microsoft.com/fwlink/?LinkId=140180.
When you are using Network Load Balancing (NLB) Manager, you must be a member of the Administrators group on the host that you are configuring, or you must have been delegated the appropriate authority. If you are configuring a cluster or host by running NLB Manager from a computer that is not part of the cluster, you do not have to be a member of the Administrators group on that computer.
To ensure that Network Load Balancing Manager is displaying the most recent host information, right-click the cluster and click Refresh. This step is necessary because the host properties that Network Load Balancing Manager displays are a copy of the host properties that were configured the last time Network Load Balancing Manager connected to that host. When you click Refresh, Network Load Balancing Manager reconnects to the cluster and displays updated information.
To create a new Network Load Balancing port rule
To open NLB Manager, click Start, click Administrative Tools, and then click Network Load Balancing Manager. You can also open NLB Manager by typing Nlbmgr at a command prompt.
If NLB Manager does not list the cluster, connect to the cluster.
Right-click the cluster, and then click Cluster Properties.
Click the Port Rules tab, and then click Add. Using information from the checklist for configuring NLB, specify values for the following:
Cluster IP address, which is the virtual IP address that you want this rule to apply to. Enter a specific virtual IP address to create a virtual cluster, or check All to apply the rule to all virtual IP addresses.
Affinity and Load weight (as appropriate)
In Timeout, set the value you want to extend the Single or Network affinity option. This preserves client affinity when the configuration of an NLB cluster is changed. Time-out settings are available only for Single and Network options.
Click OK. This applies changes to the NLB parameters, stops NLB (if it is running), reloads the parameters, and then restarts cluster operations.
The number and type of rules must be exactly the same for each host in the cluster. NLB Manager handles pushing the port rules across the hosts in the cluster.
If a host attempts to join the cluster with a different number of rules than the other hosts, it is not accepted as part of the cluster, and the rest of the cluster continues to handle the traffic as before. At the same time, a message is entered into the Windows event log. When this happens, consult the event log to determine which host has a conflicting number of rules, resolve the conflict, and restart NLB on this host.
The rules that are entered on each host in the cluster must have matching cluster IP addresses, port ranges, protocol types, and filtering modes.
If NLB detects an inconsistent rule among the hosts in the cluster, it records a message in the Windows event log. Consult the event log to determine the host in question and which rule is responsible for the issue. Fix the rule and restart NLB on that host. For more information about error logging and cluster operations, see Additional references.
When using NLB to load balance virtual private network (VPN) traffic (such as PPTP/GRE and IPSEC/L2TP), you must configure the port rules that govern the ports handling the VPN traffic (TCP port 1723 for PPTP and UDP port 500 for IPSEC) to use either Single or Network affinity.
To allow NLB to properly handle IP fragments, you should avoid using the None affinity value when you select UDP or Both for your protocol setting. You should instead set affinity to Single.
The list of all currently installed port rules is sorted by port range.
The parameters that are set in the Properties dialog box are recorded in the registry on each host.