Do you find the Support WebCast transcripts helpful?
Let us know!

Note This document is based on the original spoken Support WebCast transcript. It has been edited for clarity.

Troy Reavis: My name is Troy Reavis, and we will be presenting today on Microsoft^® Windows^® 2000 Network Load Balancing. So let's get right into the WebCast.

The first slide (slide 2) is titled "What Does Network Load Balancing Add to My Business?" As you'll notice, we have three major bullets. These three points are the main selling points of Network Load Balancing. They are Availability, Performance, and Scalability. Within each one of these components, we have at least one subcomponent. We will of course be getting into those subcomponents a little bit later.

On the next slide (slide 3), we have one of the questions that I hear most often, something that is absolutely vital for administrators to understand when they're working with Network Load Balancing or Microsoft Clustering Services. This slide is "What is the Difference Between Microsoft Cluster Server and NLB?"

The next slide (slide 4) is titled "Microsoft Cluster Server", also known as MSCS. Basically, with Microsoft Clustering Services and clustering machines, we're consolidating their resources for the good of multiple and distinct applications. So we're looking at this application, which is going to consolidate resources — whether those be hard drive space, memory, or bandwidth —across two nodes. As you'll notice, our second note is that there is a maximum of two systems or nodes for MSCS to function.

Some examples of applications or uses for Microsoft Clustering Services are SQL Server and databases, anything that needs a lot of up-time, or anything that needs high availability and accessibility.

On our next slide (slide 5), we have the description of Network Load Balancing, otherwise known as NLB. We're going to use NLB to just balance IP traffic across a number of nodes. TCP/IP is related — applications only; we absolutely have to use applications that run using TCP/IP, which then would remove from NLB functions or applications that use things such as AppleTalk or IPX.

As you'll notice in the third bullet, we do have a maximum of 32 systems or nodes with Network Load Balancing. Some available uses would be things like HTTP, FTP, Terminal Services, and things of that nature.

On our next slide (slide 6), we have the requirements for NLB. The requirements are very straightforward, with Windows 2000. It does require Windows 2000 Advanced Server or Windows 2000 Datacenter Server, which, as you'll notice, excludes Windows 2000 Server. NLB is a feature that was not included in Windows 2000 Server. It is included in Windows 2000 Advanced Server and Windows 2000 Datacenter Center. It does require 1 MB of disk space and 4 MB of RAM; it's not too resource-intensive on the machine. It does require the TCP/IP Protocol. Like the previous slide said, applications that utilize TCP/IP are the applications that NLB will allow us to use. So the machine running NLB has to have TCP/IP installed.

The topology we're going to use FDDI, Ethernet LAN, or Gigabit Ethernet. Hosts must reside on the same subnet, and this is important, because it is not possible to have a network load-balanced cluster, or load-balanced machines, that are on different subnets or that are on routed subnets. So they must absolutely reside on the same subnet. And only one network card per machine can have NLB enabled on it; so, that's just one other point for Windows 2000.

On our next slide (slide 7), we've titled it "How Does NLB Load Balance?" Basically, NLB sits above the NIC driver. The actual NLB service sits above our network card driver, but below Internet protocol. It enables each one of the nodes in the cluster to look at each and every packet that comes in. So as a packet hits the wire and comes into this cluster of machines, every machine is going to pick up and inspect the packet; but according to the rules that we'll talk about in just a little bit, which are set per cluster, the node will then decide, according to those rules, whether to pass that frame or that packet on up its IP stack to be processed, or whether to just drop the packet altogether.

On our next slide (slide 8), we get into the different modes that NLB can run on, unicast mode being the first and default mode. As you'll notice, one of our bullets does mention that it is on by default. With unicast mode, there is a single, virtual MAC address that's used across all nodes within the cluster. It does always start with 02-bf, which we'll be able to get into a little bit later, when we have some screens of the actual interface. Because of this single, shared MAC address, the nodes are unable to communicate with each other on the network card that NLB is installed and enabled on. That is important to know as well. It is a limitation with unicast mode. There are two ways to get around this, the nodes not being able to talk back and forth. One of the ways would be to install a second network card on the same subnet, or on a separate subnet that would be considered our dedicated card, dedicated for communication to and from the nodes. Or we can get into the second mode. We can enable the second mode on our load-balanced cluster machines, and that is called multicast mode.

So if we can move on to our next slide (slide 9), it is titled "Multicast Mode." Multicast uses both the virtual or shared MAC address and also a dedicated MAC address. The virtual MAC address will always start with 03-bf (which again, we'll be able to see in a little bit), and it does have the ability to communicate with other nodes on the network that has NLB installed, on that NIC. So, that is an important point to make about multicast versus unicast mode.

Move to our next slide, "Layer 2 vs. Layer 3 Switches." Layer 2 switches work at the MAC address level, keeping ARP tables and things like that, the ability to route packets and such at that MAC address level. By doing that, with the virtual IP address or the shared IP address that we use for our cluster, we're not going to have any conflicts, because we are working a layer below the IP address. So Layer 2 switches are the type of switch that you do need to use when using Network Load Balancing. As you'll notice in the third and fourth bullet on this slide, regarding our Layer 3 switches, they do work at the IP address level. And because Network Load Balancing relies on this shared IP address to be able to balance traffic across, Layer 3 switches will not work, because we would have conflicts.

There is one point that I'd like to make here, back with Layer 2 switches, and it is about a registry key that we'll talk about in a little bit, called MaskSourceMAC. What this registry key allows for is a node to mask its MAC address within the ARP payload. In other words, whenever traffic leaves the node and is routed by the switch, in the ARP payload — which is what the switch monitors and how the switch builds its ARP table — there is a masked MAC address, so the switch is not able to learn this same MAC address. If you have three nodes, and all three of them have this same virtual MAC address, obviously the switch is going to realize that all three nodes have the same MAC address. It's going to assign one MAC address for one port on the switch, therefore ruining and breaking Network Load Balancing.

So {in that case}, we have this registry key that allows you to enable the MaskSourceMAC key. It then masks that MAC address in the ARP payload, so the switch doesn't learn it. The switch believes that they are three completely different machines, but actually the Ethernet header of that outbound packet is where this virtual MAC address is. That allows for the client that is using Network Load Balancing, that's sending in data — it knows that it is coming from the same MAC address as the other two or three nodes are sending from. So that is an important point to make, and it's again a feature that we'll look at in just a bit.

On our next slide (slide 11), we have a slide titled "Convergence." This is one of the first of those subcomponents that I referred to back on slide 2. Convergence, as you can see from slide 11, is the mechanism by which cluster status and load distribution are established; it's very simple. During convergence nodes are either brought into the cluster or they leave the cluster. But every time convergence happens, this algorithm runs, which actually is what Network Load Balancing is. It's what causes the balancing to happen.

In short, the algorithm takes the number of nodes, depending on any preset rules or anything that's been defined (which we'll get into), and it literally takes all available IP addresses out on the Web: every possible IP address that could come to this node is taken. That algorithm then splits it up, depending on how many nodes are in the cluster and depending on the rules that you've defined, and it assigns each IP address individually to each node. So if you have three nodes, we're going to break all of the possible IP addresses up. Assuming there's no rule that prevents this, we're going to break them into thirds, and each machine is going to have one-third of all possible IP addresses that it is responsible for.

So again, this is how the balancing happens. It's an algorithm. Each node knows, because of this algorithm, when a packet comes in. Looking at the source IP address, it knows then whether it is destined for it, or whether it should just drop the packet and let another node take the traffic.

One other point I would like to make is that convergence does take approximately three seconds. So if you do have questions along the lines of, "If a node drops out of my cluster, how long am I looking at for the convergence to happen, for everything to be back up and running as normal," convergence is one of the variables that you have to consider. Again, it takes three seconds.

Our second variable is on slide 12, which is titled "Heartbeat." The heartbeat is kind of a checks-and-balances type of system, where nodes can monitor and determine whether a node is online, whether a node has gone offline, whether a new node has come online, and things like that. If you'll notice, the two bullet points break down the heartbeat very well. It's broadcast from interface to interface that Network Load Balancing is bound on, or that NLB is enabled on. It only works on that interface. It does not work on your dedicated NIC. If you do have a second NIC in the machine, it does not heartbeat over that. It only goes over the network load balanced card. It's about 1.5 KB, a little packet, and it pushes itself across the network about every second. This is something that is configurable, if you do feel that you need to either raise or lower that setting, and we'll get into that. That is a registry setting.

Our second note on the "Heartbeat" slide mentions that if one node misses five heartbeats, convergence starts for the remaining nodes. Again, that is configurable in the registry, and we will get into that. That plus the three seconds that convergence takes, by default, means that if a node is dropped offline or if a node is placed into our cluster, it is going to take approximately eight seconds for everything to come back up and continue running as we would hope it would.

The next slide we have is titled "Affinity." Affinity is one of these methods that I had alluded to earlier during convergence, the way the algorithm worked. This is one of the things that you can set that does affect the way machines pick up or toss packets to the side. If you'll notice, we do have a little chart. I hope you can all read it. We have, on the far-left column, the Affinity. We have None, Single, and Class C. Those are our three different types of affinity.

Starting with None, as you can see, the Load Balancing Granularity is simply individual TCP connections. Those inbound packets are hashed on the source IP address and the ports. This is used for most applications: HTTP, things like that.

Single affinity is a little bit more restrictive. Its Load Balancing Granularity is all connections originating from the same source. So as you can see, Single affinity does require and does set up that application so that if a packet is coming in from the same source, it's going to always hit the same destination server, even if you have four nodes with applications that require session state. We need something like this, something like Single affinity. It's hashed on the source IP address only. It is used for session support, like I mentioned, SSL, and multi-connection protocols — for such things like FTP and PPTP, and so on, it's very important that Single affinity is set.

Class C affinity is like Single affinity. It's a little less restrictive. It's not something that's used too often, but it does load balance according to all connections originating from the same Class C address space. So, as the name hints at, depending on the Class C address space that you're coming from, it will send that packet to the same host. It's hashed on the source IP address with a Class C mask applied to it. It's used for things like properly handling sessions for users residing behind scaling proxy arrays. So, if you know the destination or where the source of a group of users is going to be from, you can absolutely use Class C Affinity and require that all those users hit the same server every time. So that will enable session state for them as well.

On our next slide (slide 14), titled "NLB Driver Interface," we do have two of our three interfaces, two of the more configurable tabs within NLB properties. As you'll notice, and we won't get too much into this, because this is a little harder to read, we have three tabs. The Cluster Parameters tab is going to apply to the cluster as a whole and the cluster settings for this machine specifically, this node. The Host Parameters tab has the parameters that just specify for this node. So the host parameters will not be something that will be shared across the three or the four nodes that you have in your NLB scenario. Finally, our Port Rules tab. And Port Rules is basically the tab where everything happens, where you define rules, where you drop packets, where you save packets, where you set affinity, and things like that — the things we've been talking about.

If we move on to our next slide (slide 15), we'll get into as much depth as possible, and we'll get into each one of these three interfaces: the first one being the Cluster Parameters setup. As you'll notice at the top, we have our Primary IP address. This is the primary IP address for the cluster-wide services, otherwise known as your virtual IP address or your VIP. When you have three nodes or four nodes, and you're balancing incoming Web traffic, this is the IP address that machines will connect to. Whether they hit node A or node B, it doesn't matter. They are going to direct their request to this virtual IP. Again, it is set there in Primary IP address.

We have Subnet mask. Of course, that speaks for itself: the full Internet name for reverse queries, and if it's a Web site, if you're balancing things like that, you enter your fully qualified name there as well. Multicast support: we have that check box in the center to enable multicast. By default, it is turned off. And when it is enabled or when it is disabled, you will see, next to the Network address box, an unavailable box that has that 02-bf or 03-bf entry, and that will coincide with multicast versus unicast. If you do clear that box, you will be using unicast. Across all nodes, this has to be exactly the same. In fact, this entire tab has to be exactly the same across all nodes that you have within your cluster. Finally, at the bottom, there's the very self-explanatory Remote password, and then enabling Remote control. It's self-explanatory: enabled is to control these nodes remotely.

On our next slide (slide 16), which is titled "Host Parameters Setup," Host parameters is our second tab. At the top, the first entry box is Priority. Basically, Priority is what's used to determine the default host, or what's referred to as the default host for the cluster. The default host is very important. The default host gets all of the traffic that comes into that virtual IP address, and that IP address is shared across all nodes. If there is traffic that comes into that virtual IP address but does not in fact have a port rule defined for it, that default host will field that request, and that is without any reason. There is no way to change that. If there's no rule for it, the default host takes it. All the priorities have to be different. So, if you have four nodes, you need to make sure that your priorities are 1, 2, 3, and 4. We can't have 1, and then a couple of 2s and a 3. That's very important to know. Also, if you have host priority 1, 2, and 3, and let's say that the first node, the host priority 1, goes down, that means that the one that has a host priority of 2, which is next in line, becomes the default host, until another machine with host priority 1 comes online. It is something that is statically set by the administrator. Whenever you're configuring your nodes, your cluster, you will want to place this, and again make sure that none of them overlap, that they are all 1, 2, 3, 4, for however many nodes you have.

We have three other boxes: Initial has a check box that says active next to it. Basically, if that check box is selected, then each time this node comes online, you reboot the machine. This machine, if that check box is selected, which it is by default, will automatically attempt to join a cluster. So if you clear that selection, you will have to run wlbs start from the command prompt, or some commands that we'll get into in a later slide, to start the WLBS or the NLB service.

We also have Dedicated IP address and Subnet mask. These are required. If you have a second IP address bound to the network card that has NLB running on it, you are to enter the dedicated IP address, that's what that's referred to as — your dedicated IP address. Of course, you enter the coinciding subnet mask there, just for Network Load Balancing to be able to know that, because NLB does reside below IP in our TCP/IP and net stack.

On to our next slide, titled "Port Rules Setup": Port Rules is the final tab and the final configuration for Network Load Balancing. As we'll see, there is quite a bit of information on this, and most of it is straightforward. At the top, we have a Port range between 1 and 65535, the ports that are available for connectivity. You define these ports per rule. So if you want 80 through 80, if you're creating a rule for HTTP, you're more than welcome to do that — if you're using FTP, if you're using services that have a well-known port. You are able to select a broad range. In fact, by default, it is wide open. It is a port range of 1 through 65535, so it's as wide as it can possibly be.

Below that, the Protocols: TCP, UDP, or Both. Again, by default, it's wide open. It is set to Both.

Below that, we have Filtering mode, which gets into what we talked about earlier with Affinity. We have None, Single, and Class C affinities. If you'll look on the left side of this tab, we have Filtering mode with Multiple hosts, Single host, and Disabled. So I'm going to do my best to describe what each one of these do.

Our multiple hosts: if you create a rule that is a multiple host filtering mode rule, this is used to spread the traffic across the cluster. So this does the load balancing. This is how you specify something, a rule that will be load balanced. You can leave the default setting of Equal. Off to the right of multiple hosts, there is a check box that says Equal. You can leave that selected. If you clear that, you are able to specify the load weight, which is a percentage. Again, make sure that you keep your numbers straight. So if you have two nodes, and you have one at 60, of course you want the other one at 40. Make sure that those are all straight; but by default, it is set to Equal. The Equal box button will be selected, and then it will equally balance it across all nodes.

Our second filtering mode, Single host, is a rule that's used to define a port or a rule that is to be inbound, and you want only one host to answer to it. It's not the same as default host, because the default host is that Network Load Balancing node that is going to take all traffic that does not have a rule for it. When you set up a single host rule, you are setting up a rule. So it is different than default host, but it acts similarly. In that, when you create the single host, you'll add the same rule on each node, you'll enable Single host, and you'll set the Handling priority. So we of course want one as 1, and then 2, 3, and 4. If 1 ever goes offline, 2 picks up where 1 left off. So it's very similar to the default host description, except that you do create a rule for this to be handled by one of your hosts.

Finally, our final option in filtering mode is the Disabled option. Disabled is very straightforward. Basically, if you have security issues, or for whatever reason you have a range of ports that you absolutely want to be dropped, that you do not want to come into any three or four of the nodes that you have in your cluster, you create a disabled mode rule, a disabled rule, for those ports. All hosts check these rules first, and they will drop the packets if there is a disabled rule created for that specific port that it's coming in as.

Again, you create these rules one at a time. So, just for example, you could come in Port range, set that to 80 to 80. For Protocols, we could leave it at Both or set it to TCP. Filtering mode, we could set it to None, because the HTTP is not going to require session and leave the Load weight left to Equal. We'll make it to multiple host filtering mode, and then you're just going to click Add. When you're ready to add or remove, you use two of the three buttons down at the bottom, and of course use Modify to modify a rule that's already existent. Again, the default rule, whenever you first set up NLB, it's wide open. Everything is going to be load balanced equally across all nodes with Single affinity. So everything should be ready to go, right out of the box.

On our next slide (slide 18), we're going to get into the command-line driven tools that Wlbs.exe can call. These are all very self-explanatory. You can hang on to this list and use these in the future. help displays our help information. setup will run our NLB setup dialog. If you don't want to do it by the UI, or if you're remotely administering these nodes, you can absolutely use setup and run through the dialog. reload will reload the parameters. start and stop starts and stops that host from using load balancing. enable and disable affect the traffic to port x, x being a variable. You're going to enable/disable port to x, on the host that you're running the command to. query is going to report cluster status. This is one that is used commonly for scripts. If you want to run a script and be able to monitor, and realize what the status is of each one of your nodes, it's something that can be run, backlogged, and kept just for review. Then finally, display; and display displays a lot of extensive information: event logs, parameters, things like that. This is a really good troubleshooting tool that I use and that we should all commonly use. It will give you pretty much every bit of information you could ever want to know about your cluster.

On our next slide, titled "NLB in the Registry," I do have the Knowledge Base article here, Q193601, which can be accessed from our TechNet site. Or, if you would like to go to http://support.microsoft.com/, you can search specifically for this KB article and Q number. The reason why I put it in there is, I did not place all of the registry parameters or the values that you can add within this key, the key being HKEY_LOCAL_MACHINE\System\CCS\Svcs\WLBS\Parameters. Within Parameters, there are about eight or nine different registry values that you can add. The three most important ones, the three that we talked about earlier, are: AliveMessagePeriod: the period between "I am alive" messages broadcast by each host or the heartbeat information that we referred to earlier; AliveMessageTolerance: the number of periods to wait before declaring a host is dead, which again we talked about earlier was set by default to 5; and then finally, MaskSourceMAC: the one that we got into much earlier in our presentation. Again, by default, it is set to 1, which if you'll remember, it does then mask the MAC address, in case you want to plug directly into a switch. It will mask the MAC address into that ARP payload. And by doing that, it's going to keep the switch from learning and placing one of the nodes, one of the MAC addresses, on one of the ports. It's going to be able to mask that.

On to our final slide (slide 20), and I believe we are ready for the question-and-answer session. So what I'm going to do is turn it back over to Jason and let him take over.

Jason Bennet: Thank you for the presentation, Troy. Just a couple of quick notes before we move on to the Q&A portion of the WebCast. To access information on all upcoming Support WebCasts and the archived content from all past WebCasts, an easy-to-remember URL is http://support.microsoft.com/webcasts/.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the Support WebCast topic. One-on-one product support issues are outside the scope of these Support WebCasts. So if you need technical assistance, submit an incident on the Web, or call Microsoft Product Support Services and speak to a support professional.

So, the first question: Would I use NLB or clustering for a shared storage unit and two file servers?

Troy: Actually, Network Load Balancing is probably not going to be the solution, in that sense. It depends on what the front end is. You could definitely use Network Load Balancing on a front end for something like Outlook^® Web Access (OWA), for example. If you have OWA with Exchange servers on the back end, you can use Network Load Balancing for OWA and things like that, which have the ability to have packets come in, packets go out, and it can pass things to the back end. As far as file servers and things like that are concerned, it depends on how it's deployed, of course, but chances are Microsoft Clustering Services is going to be your best bet. If you'll look on slide 4, Clustering Services is the service that is going to consolidate resources. So if you have a large amount of data, whether it be a database or whatever, and you want extreme uptime, extreme accessibility (it's an extremely important type database or type file, in your case, file server information and such), Clustering Services allows you to consolidate resources between nodes. So that's probably going to be the way you'll want to go with that.

Jason: The next question: We have about 50 Terminal Servers in our environment. Can we set up several network load balancers here? And if we do set up Network Load Balancing here and one of the member servers goes down, will that affect all the users who are currently logged in? And will those users lose their process?

Troy: No, the way it is set up is that with Terminal Services, as long as there is no reason for you to use affinity, then each time a packet comes in on port 3389, we're going to hit a different host. So let's say that you have 50 nodes, in your situation. Of course, we would probably have to use at least two different clusters. Again, we are limited to 32, currently. But if we split them up, let's say we have 25 and 25 — if node 25 goes down and we have hundreds and hundreds of users connected to 25, without affinity being set, each packet that comes in is going to be redirected, as needed. If a host is down, Network Load Balancing will pass that information to a different host. The problem comes when you have affinity set, and things like that. But again, with the registry keys, you can tweak it as much as needed to keep the uptime to where you would like.

Jason: Great. Is it recommended to use two network cards in each server?

Troy: It completely depends on the situation. If you have switches that are multicast aware, you want to use multicast, and in a situation where clients are going to be connecting to the server on the same interface that you as an administrator would be connecting to the server, then in multicast mode, because of this MaskSourceMAC and because multicast enables you to be able to have one IP address with a shared MAC address across all nodes, you can function with just one single network card. So, if you have eight nodes, you have the same MAC address across all nodes for that specific IP that's going to be spit out — any other IP address that you add, because of multicast and because of the limitations of unicast being different, being able to be used in multicast, you can absolutely just bind a second IP address to the TCP/IP properties. You'd want to bind that to the IP properties first. And then, if you have eight nodes, you do not want to duplicate that IP address. It would be as if the machine is just sitting there with no Network Load Balancing, as if you'd separated the two. Then, you're more than welcome to connect to that interface.

If you do decide to put a second network card in, you would need to think very carefully about the routing, simply because if you have a packet coming in to one interface and it's getting routed out of a separate interface, then depending on where your gateway is set, and depending on where your routing is set to go, you could have issues with the client receiving the packet from a source address that it did not send it to. There are some advancements in IP with Windows NT^® 4.0 SP5, I believe, and also with Windows 2000, that enable the machines to have another unique identifier with the session, so that they know that, even if the packet comes from a different source address. It is still the same session that it had open with that different virtual IP address. But it is very important to take notice and to understand your routing if you do add a second interface.

Jason: Are there any specific switch or hub requirements to use NLB?

Troy: Absolutely not. Well, I take that back. You do not want to have Layer 3 switches, because of the fact that they work with the IP layer, and because Network Load Balancing relies on that virtual IP address, that shared IP address, across all nodes. You do want to stay away from Layer 3 switches, without a doubt. There are some older Layer 2 switches that have trouble pulling the MAC address from the ARP payload. They pull it from different spots. It's well documented on our TechNet or our support site, if you have some specific issues or questions. But you can manually add ARP entries into switches.

But speaking about switch requirements, not really, other than that they need to be Layer 2. But hubs, absolutely not. After you're connected to a hub—obviously, hubs are not going to have that ARP table. They're not going to have that routing capability. So you don't have to worry about MaskSourceMAC or the registry keys that we talked about earlier, which enable machines to be plugged directly into a switch and not have their port realized and assigned, based on the fact that all nodes have the same MAC. You don't need to worry about that with a hub. So that's just one other point to make. But there are definitely no requirements, other than that.

Jason: Okay, related to that, maybe you just answered this, but: Are any specific router protocols required?

Troy: Absolutely not. Again, it is a requirement of Network Load Balancing, and it's very important that all nodes are connected to the same subnet or are a part of the same subnet. There should be no routing between nodes.

Beyond the nodes, there's one thing you have to watch out for, and this again is something else that's been well documented, and it's something that most vendors that produce network address translation or NAT devices are taking a look at. You have to realize — let's say, for instance, you have two Web servers, and you have them published behind your NAT firewall. You have some firewall sitting out there. You have a public interface on it, and the virtual IP address is on that public interface, but it's being published through that NAT device. You have to be careful, because the way that most NAT devices work is, when something is published, they turn around and create a completely different TCP session, using their internal interface, or that private interface that's going to be on the same subnet or the same internal scheme as your load-balanced cluster members, your nodes. It is a very well-documented problem that when companies do that, or when administrators do that, they'll see that one node is getting all the traffic. Well of course, that's because it's being sourced from the same IP address.

And back to the algorithm — machines are going to answer specific to the source IP address. So that's one thing that you definitely need to watch out for; but as far as routing protocols are concerned, there are no requirements.

Jason: In clustering, if one node dies, will applications continue to work?

Troy: That's an excellent question, and one thing that is very commonly misunderstood is that when you have Network Load Balancing enabled — and let's say you're just load balancing a Web server — just because IIS stops does not mean that that node will drop out of that cluster. It's very important to realize that. We don't have this yet, but there are tools out there that enable you to, after a cluster drops out, send yourself an e-mail. I'm sure you've all seen some of those types of administrator tools, not just with Load Balancing, but with other services — e-mail, and services like that that need uptime — which can let you know that IIS has stopped, or the service has stopped. But the node is not going to drop out of the cluster, because the node is still able to receive in-bound TCP traffic. That is very important to realize — that if WLBS or that NLB service is started, and that machine is still online and able to receive packets, even if it's not able to receive them, even if IIS dies or Terminal Services die, that node will stay online. You can take other measures to combat that type of an issue, but that is something else that's misunderstood, and it's a good question.

Jason: What's the effect on Network Load Balancing if you have redundant NICs on the server?

Troy: It completely depends on the type of redundancy. Again, assuming that we are talking about redundancy — it depends if it's a software-type redundancy rollout and one node is virtually disabled, or one NIC is virtually disabled until the primary or that first NIC comes offline, then it switches over, and there are no problems there. In fact, because of the heartbeat setting (and this is actually pretty cool, that you can mix redundancy in Network Load Balancing) it's not immediate. Again, something you'd have to realize as an administrator is that every now and then there's going to be congestion. There may be a problem on your network. So you don't want to set the heartbeat requirement to drop someone out of a node. You don't want to set it so that if it misses one, it's out, because that could happen. That happens commonly, with things other than just these heartbeat packets; but with redundancy, if you do have a NIC go down, and you have a way of failing over to that other NIC, it should pick up that heartbeat. Because again, by default, it's set to five seconds, and the heartbeat hits every second. So five seconds, and as long as the redundancy kicks in quickly enough, that is an excellent way of deploying your cluster or your nodes.

Jason: Does NLB provide any kind of failure recovery (failover, et cetera) that would allow real-time users session recovery while using Network Load Balancing?

Troy: Yes. And again, it depends on whether we're working with a session that's connected to a node or to that virtual IP, whether or not that port or that session is something that is using affinity. If there is no affinity, then you would not need to worry about that. If traffic comes inbound, it's not always guaranteed that it's going to go the same node. Because again, it's based on that source IP and the source port.

When you have services that use affinity, the session will be maintained on all nodes during convergence. So, let's just say we eight FTP servers. They're the old-school FTP, so we're using ports 20 and 21. We make our initial connections over 21, then 20 over data. Let's say that we have, again, eight nodes.

Let's say that one of them goes down. Any machines that are connected to that node, that have session state to that node, are going to have trouble. I'd be lying if I said that isn't a problem, but any other nodes that are connected, as convergence happens — so let's say you have your heartbeat set to one second, you have it set by default every five seconds that a machine misses one, it's dropped out of convergence, then convergence takes three seconds, and then everybody's back up and running.

During convergence and during that entire scenario, nodes will absolutely not be affected. In fact, even if during convergence something happens, which is likely — that a source IP address or a machine is no longer under control of that node — it will continue its session until that session is over. Then the algorithm and what was determined during convergence will go into effect. But it is very important to know that without affinity, there are no problems. With affinity, if that node drops offline and it does have the session state established with that node, it's going to have issues until convergence happens again, and until that IP address is then able to be used by one of the other nodes, one of the nodes that is left online after convergence. So, good question.

Jason: What are some of the disadvantages of multicast?

Troy: A big disadvantage is with upstream switch flooding or port flooding. With multicast, if you've worked with the protocol IGMP, it absolutely spreads itself across a network to its extent. There's nothing set. IGMP will spread itself everywhere, and only members of that multicast group will pick up on those packets. That's the first thing to realize.

Now, of course with the newer switches and with most of the older switches, you can set up VLAN. You can set up a virtual LAN on your switch and VLAN out. If you have a 16-port switch and you have eight nodes, you can VLAN out those eight nodes, and basically you then just enable it so that fragmented and broadcast packets and things like that are going to be restricted to those eight ports. So then you know that you're not going to be flooding the switch above this switch, and it will spread itself out. That's one of the problems with multicast. Other than that, there's really not anything else to speak of. A lot of the people that I speak with end up using VLAN support in their switches and use IGMP, so multicast. It's definitely a viable option.

Jason: Is communication between nodes required for heartbeat information, et cetera, similar to MSCS? You mentioned that unicast mode won't be able to, unless accommodations are made by adding a second NIC.

Troy: Right. The heartbeat will function, because the heartbeat is broadcast, and it works differently than a directed packet. When I was referring to unicast and requiring a second NIC to be able to speak from node to node, that has to do with any TCP, any IP, any traffic that's going to be coming to or from it. The actual heartbeat is removed from that equation. The heartbeat will bounce between NICs, between machines, between nodes, whether it's unicast or multicast, or whether you have one NIC or two NICs. If you do have a single NIC, whether you have just the virtual IP address bound or whether you have the virtual address plus a dedicated IP, the heartbeat will function. Again, the checks and balances. It's that function that Network Load Balance has, that inherited function that will keep the uptime and keep everything running as smoothly as possible. It's not restricted to unicast or multicast again. It will function, without a doubt.

Jason: From what I understand, is there currently no way, under Windows 2000, to load balance across NICs on a single server? Is there any way I can utilize two or more network cards to get more throughput?

Troy: Actually, you are correct in the first portion of that question, in that you cannot enable Network Load Balancing on more than one network card, currently, with Windows 2000. I like the way that was put, because it is something that has been worked on, and in my testing and looking at future releases of our server products, it is something that I can say is going to be addressed. So just take that as you'd like. But regardless, there are basically two different ways that you can get better throughput.

To help with bandwidth, the first method would be, if you have the driver bound to your network card —there are a few vendors that will enable you to have two network cards and run the NICs in load balanced mode. So then you have double the bandwidth coming in. That's one way that you can get throughput.

The other way, and a way that's a little bit more inherent with the operating system, I guess you could say, is if you have two network cards in the node — let's say we have two nodes. We have two Web servers, and we have one NIC that is on each one of the nodes that has NLB bound, has it enabled, and is doing the balancing. Then, on the back NIC, or our dedicated network card on the other side, it would have to be on the same subnet. That is important: it needs to be on the same subnet if the traffic is going to be heading back to the client. But what you can do is have the virtual IP address on the NIC that has in-bound traffic. You can assign your default gateway, or however you do your routing. You can basically assign the routing so that the traffic comes in one NIC and only in that NIC. And the traffic goes out the dedicated NIC and only out that dedicated NIC. That is a way that customers have definitely implemented throughput, and it does make a difference. It is definitely something that you should look at.

Again, it is something that has become a reality, because of an update to TCP/IP. In the past, if I sent a request to an IP address and I got a request back that was sourced from a different IP address, I would then assume that something was wrong. I'm just going to drop this packet. And I'm probably going to retransmit a couple of times. Then, the session will end, because I never heard an answer back from that IP that I was sending to. The difference being, with the update with IP, there is a unique ID within each of your sessions. When I establish that session, whether it's coming back from the IP address that I'm sending to, or coming back from this IP address that we just spoke of, that is going to allow you throughput. Because of that identifier and because of that update with IP, it is absolutely going to know and realize that it is of the same session, and it will continue to direct traffic to the virtual IP address. That's another thing that's important; because again, if we're a Web page or whatever, we're going to continue heading to that same virtual IP. We're not going to send it to the address of the throughput packet.

So those are definitely two different ways that can help: with bandwidth control — that is, enable that with the two NICs and the software load balancing between the two NICs — or the throughput with the dedicated network card that you alluded to in your question. So, good question.

Jason: How do you determine whether to use unicast or multicast?

Troy: It completely depends on the environment. The switch has to be IGMP or multicast aware. That's one important thing to be said. Other than that, it completely depends on administration.

A scenario that I could give you that may help draw the picture just a little bit: let's say you have two nodes, two machines, two Web servers. You have a public NIC. You have a NIC sitting out on the Web on each one of them, with the virtual IP address bound, and they're in unicast mode. If you can put a second NIC, basically on a different subnet, in the background, and you're able to administrate using a third party, or what would be considered a client machine (something that's not in this Network Load Balanced picture), you could administrate two node 1s and two node 2s on this back NIC.

If you have IIS or Web page type publishing (I know there are a lot of applications out there, Microsoft Application Center 2000, things like that, that can push information to and from nodes, whether it be Web or whatever, where you can publish data automatically), if there's something that for any reason the nodes need to talk back and forth, it is important that you do realize that they're in unicast mode, because we're going to be sharing the same MAC address. That is absolutely set in stone, there's no way of getting around that. Of course, if a machine gets a packet from another machine, goes to ARP, and sees that it's got the same MAC address, it's going to have a little trouble. It's going to drop that. So that's one of the issues that you could consider when using unicast and multicast.

The other thing is, if you're an entirely switched environment, and you're not comfortable or not able to VLAN out switches, and you don't like the fact that IGMP spits traffic all over your network, that's another reason that you can consider unicast. Because it will keep that upstream flooding, as we like to refer to it, or those packets going everywhere, down to a minimum. So that's one other variable that you may want to consider when choosing between unicast or multicast.

Jason: Okay. What affinity is used for Windows Terminal Services?

Troy: With Terminal Services, you can absolutely require that they use Single affinity to make sure that that session state is established and is kept up. That is what I suggest.

Jason: One of the slides mentioned that all nodes must be on the same subnet. Is this limited to the same Class C subnet, or is it the same physical subnet?

Troy: It's the same physical subnet. Basically, if you go into the machine's IP properties, and for any reason, to get from one machine to the other, they have to pass through a router, whether it's been subnetted out a Class C, or you have just one giant private Class A (of course, you're probably not going to be routing between a giant Class A), just follow the logic of the routing when you're setting up your nodes. Just make sure that with incorporating the IP address in the subnet mask, that you do have your nodes, all of them, without a doubt, on the same subnet. That is another point, is that this is the same subnet on the network card that has your Network Load Balancing on it. So you just have to make sure that those guys are on the same subnet.

Jason: Great. Regarding Layer 2 switches and Network Load Balancing, how would this work? That is, how would a Layer 2 switch know that an incoming packet should be sent to all cluster nodes?

Troy: With a Layer 2 switch, we use MaskSourceMAC. We use this registry value — and again, I always like to use examples, it's absolutely the easiest way to get it across, and we'll make it as simply as possible. We have two nodes, two Web servers, let's say. They are plugged directly into our Layer 2 switch. We only have a single NIC in them, so we don't need to worry about that. These are just sitting out on the Web. We have a couple of clients on the Web that are attempting to connect to our virtual IP address.

The packet in-bound from the switch, as the ARP table is built up, the nodes (node 1 and node 2), as they respond, as long as you have MaskSourceMAC turned on (which is on by default), the value in the registry is set to a 1, and the nodes will send their out-bound packet. They will include a masked MAC address. It will just make one up. It will place that in the ARP payload, which is where switches get that information. It's where switches build their ARP table, from that ARP payload. It's kind of a way of tricking, I guess you could say, those switches, in that in your ARP payload, you're saying, "Hey, I'm node 1," and "I'm node 2. We have completely different MAC addresses." But in your Ethernet header, which is what the client is going to see and respond to, it will see that it is this clustered MAC address. It will know which MAC address it's coming from.

So it is inherent to Network Load Balancing and to the client. Unfortunately, I wasn't involved in development of any kind, so I don't know. It's a very interesting way of getting around the problem with Layer 2 switches. I think it's pretty neat the way that came together. With that registry value set, you're able to tell a switch that you're not who you really are. So it's kind of neat the way you can get around that.

Jason: The next question I have is this: Application Center 2000 uses NLB as a communication, but seems to do the priority backward of the method that you described, and I'm not sure which slide they're referring to. They said 32 is the first one assigned. Does that make sense, and can you comment on that?

If you don't understand the question, we can get clarifying information from this user.

Troy: Absolutely. And the other thing I would just like to point out is that in the team that I'm a part of, and the decisions that I'm made part of, it is strictly for Network Load Balancing for Windows 2000 and .NET. So just keep that in mind with your questions. Application Center 2000 is one of the coolest things that we've put out. With Network Load Balancing, I think it's a great application. But unfortunately, I don't have much experience with it at all. If you want to submit questions, as long as Jason doesn't have a problem with it, I'm sure we could research a few of them and do what we can. Or you're more than welcome to do the research. I'm sure that there are some white papers. I'm sure that there's a white paper either in development, or out already, for Application Center 2000. Hopefully it has some information specific to that; but unfortunately, in my lack of practice with it, I don't exactly know the answer to that question.

Jason: Right, and Troy makes a great point. Again, we're talking specifically about Network Load Balancing. This question does seem to cover Network Load Balancing. So if you have a specific question on it and you can refer back to the slide that you were talking about, we'll definitely take your question during the WebCast.

Troy: Actually, no, I don't have too much practice with it. The Cisco solution, in short, balances in-bound TCP/IP traffic according to the source port and source IP address, or simply the source IP address. In certain cases, the Class C affinity, the source IP address, and the actual subnet mask are figured into the equation. Unfortunately, I don't know for sure if that is what it does. NLB is very simple.

The algorithm is a bit confusing. They are very, very tight-lipped on that algorithm. It's the core of Network Load Balancing. So the algorithm, during convergence, is something that I just know about very vaguely. I know very vaguely how it works, what it does, and any updates to it, and so on. So that is how it load balances.

Without knowing what the Cisco product is exactly, I can describe another question that I get, which hopefully will answer a few questions that might be out there (and it kind of branches off of this one, to explain a little bit better the common problems with Network Load Balancing, which might be right in the same line with the Cisco solution). Another common question I get is someone will ask, "I have two Web servers. I have load balancing enabled on them, and I've tested it, and it's always going to the same node." In following up with that question, the question then being, "How many clients are you testing it from," a lot of times the answer is one, two, or three.

What you have to remember with load balancing and convergence is that in this algorithm, it's similar to a coin flip. If you have two nodes, it's similar to if you flip a coin. If you flip that coin 10 times, you're not guaranteed to hit 5 heads and 5 tails. That's exactly the way the convergence works, exactly the way the algorithm works. It load balances it out mathematically. So if you have thousands and thousands of hits, it will load balance itself out. You will see a split: maybe not 50/50, but mathematically, it's going to split itself up.

The problem in testing, and it may be kind of along those lines again with the Cisco product, is that if you test with one, two, or three clients, there's a good chance that you could have one be one and two the other, but there's also a good chance you could hit all three on one of the nodes, and not the others. So that's just one other thing. Hopefully that will provide a little bit more information into Network Load Balancing and its inner workings, and that will answer your question indirectly, about its comparison to that Cisco solution.

Jason: Okay, great. When a page is being downloaded from the browser's HTTP GET request, are all the images — GIFs, JPEGs, et cetera — being downloaded from the first server that answers the request, or are they downloaded from across all hosts in the cluster?

Troy: They will be downloaded across all hosts in the cluster, unless you have affinity set in your rule, or you have that session state established with the same node. Because each time you go to make a TCP connection or each time you go to connect, it's going to be balanced across the nodes. Which again, if you want that state, if you want to keep it — and the way your question was worded, you'd like to keep it (the scenario where each machine will download from the same host every time, or at least during that same session from that same host) — consider affinity. By default, it's what's enabled. By default, everything is set to use Single affinity. So just know that.

If not, you also have to know that without affinity, with the connections going here, there, and everywhere, with nodes going offline and online, that also enables hosts to continue on as they normally would. Again, you don't have a session open and established with a node that could possibly go down. So that's just two cents worth there, as far as that's concerned, that there are two sides to the affinity. But regarding your question, it will spread it across the nodes.

Jason: When and why would you want to define port rules?

Troy: The port rules are one of the first portions of that NLB engine, that driver, that allows NLB to function. The port rules are what are brought up to basically perform a litmus test against your in-bound packets. If you were to go through and set up two nodes and delete — because, by default, there's going to be a rule in there, there's going to be a rule for all ports. We talked about it earlier, but again, all ports, protocols — Single affinity, equal, a multiple host rule — it's going to be in there. If you want to go in and remove that, all you're doing then is saying, "Okay, whichever one of my hosts is the default host, that's who this traffic is going to go to." In that situation, you're really doing no load balancing at all. You're just using an IP address that is shared between two nodes; but you should know all your traffic is going to go the default host.

You want to use port rules, and you can use any mix of port rules. We didn't get too much into that, but if you have a few different functions — if you have an SSL site, you have a Web site, and you have an FTP site — and you want to set up one rule, and you have two nodes, set up a multiple host rule for port 80, with no affinity between the two nodes. Okay, so you set that rule up. You can go in and create a second rule for your SSL. You can create it again; let's say that SSL is only set up on one of the two nodes, but of course you still want it to service the SSL. You don't want it to hit the other node, because the other node doesn't have the SSL site inside of IIS or inside of its Web site, it's not there. You can create a single host rule (which we talked about earlier) for port 443 and set Single affinity, and add that rule. You would want to set the node that has the SSL on it, set its handling priority to 1. And for the second node, you'd want to set it to something other than 1. So if it ever fails on the first node, it's going to go to the second node, but the SSL site's not going to be there. So that way you can kind of say, "Okay, I want everybody to handle port 80, all my nodes, but because I have SSL just on this server, I only want packets to go to this one host."

It is load balanced in a sense, because again, any time a packet hits the virtual IP address, it's going to go to every single node within your cluster. It's going to be taken up to the NLB driver just before hitting IP. It's going to hit that driver, and the driver's going to apply these rules. With a single host rule, or whatever port rules you define, it's then going to either pass the information up to the IP layer and on to the application, or it's going to drop the packet to whatever node has a rule for it.

Support rules are very important. I strongly urge, if you have an application and you're just not sure what port it uses, and you can't reach the developer, you can always use the default rule, the Single affinity, TCP, UDP, 1 through 65535. It will balance everything, basically. So that's one other consideration with the port rules.

Jason: Is it recommended to use two network cards in each server when in unicast mode? Will it work with only one network card in unicast mode?

Troy: It will work. It will work with either scenario. If you have one network card, however, the two nodes will not be able to talk to each other on that interface. So if you have the second NIC, you're more than welcome to administer the two machines over that network card. You're more than welcome to have the nodes do their transactions between each other, if they need to, for whatever reason. You can do that on that second card, what we like to refer to as the dedicated card. You're more than welcome to set it up that way, but they will work in either scenario.

Another common question I get is: "I have two Web servers. I have them in unicast mode. I can't ping the other node. I want to make sure that it's up and running, and I have my virtual IP address bound, but I've also assigned a dedicated IP address to each one. I have one IP address and another IP address on node A and node B, and I cannot ping the IP address on the other node."

Well, the problem is, no matter how many IP addresses you bind, if you're in unicast mode, for the interface that has NLB enabled on it, it will all use that shared or that virtual MAC address. Then, if a machine gets a packet from another machine, or gets an ARP from another machine, and it responds with the same MAC address, it's going to assume that something is going wrong, and it's just going to drop those packets. So it will work in either scenario, but there are caveats to both scenarios, with or without two NICs. Those are things to consider when deploying your cluster.

Jason: Okay, good. During convergence, is my cluster offline, and are connections dropped?

Troy: Absolutely not, and that's a very good question. I always like to stress that during convergence, and it does depend on the connection type. But for most connection types — no affinity, or if you have Single affinity to one of the nodes that didn't get dropped, (which was not removed from the cluster, any connections during convergence) and then after convergence is done — even if convergence has moved, like we talked about the algorithm assigning IP addresses here, there, and everywhere, that session is going to be maintained. The connection will not get dropped. That is again one of the big selling points. Back on our first slide, one of the big selling points was about scalability and about availability. That's a good point to make, and a good question to ask. So, thank you.

Jason: Okay, terrific. If my Network Load Balancing cluster contains two Exchange 2000 Outlook Web Access servers, will the server with host priority of 1 get all the traffic, unless it's down? If so, that doesn't sound like true load balancing. Can you comment on that?

Troy: If you have two OWA front ends set up, and you have Network Load Balancing enabled on them, as long as you have a port rule for the in-bound port 80 (for where the OWA is going to sync up and make its connection), it's absolutely going to load balance. It's going to be no different than any other Web site that you have published on your server or on your nodes. Then, after the connection is established — you have a back-end Exchange server, or whatever — the one thing you have to realize about Exchange is that if you have one mailbox on one node and another mailbox on another node, that breaks down one of the most basic rules of Network Load Balancing, which is the data needs to be the same. It always has to be the same. When data is accessed on one node, it's not going to affect it, whether it's accessed immediately by the other node, or vice versa

What you have to watch out for is if you load balance in Exchange Server and you have Tom and Bill's mailboxes on node A and Tom and Bill's mailboxes on node B; if Tom connects to node A and connects to his mailbox there, with node B, you're pretty much breaking the function of Exchange. You're going to have a lot of trouble, and it's basically just not going to function.

There is an article, if you want to check it out, on our support site. There's a solid article on setting up that OWA front end, the actual Web page front end, and using Exchange servers. You could use clustered Exchange servers, which would get in to the difference between Network Load Balancing and Clustering Services (because with Exchange, we would obviously want to have that information on one, local store). But if you want to keep all that information and the resources and things like that spread across two nodes, Clustering Services would be the way to go, with the Exchange back end. There is a good article on that. I apologize, I do not have the Q article number in front of me, [Presenter's follow-up: See Q226470; http://support.microsoft.com/support/misc/kblookup.asp?id=Q226470], but go to our Support site and search for "OWA" and "NLB." You should get a couple of articles on it.

So it's definitely an option that is used; it has been deployed and it works very well. So absolutely, as long as the OWA front-ends have port rules for them, then they will let you load balance across them. You will just not hit the default host.

Jason: I did want to take just a moment to solicit some feedback from our audience. If you've come in to our WebCast for the first time today, or you've been in before, we would like your feedback on today's WebCast: what you think of the presentation, the overall quality of the presentation, the sound quality, or whether your questions were answered fully. All of that is good feedback to send to us, because we do take your feedback into account with this WebCast program, as it evolves.

We would particularly like feedback on what you think of the topics that are being covered, and what you'd like to see covered in the future. You can send us feedback through the alias feedback@microsoft.com. If you do that, you'll want to make sure you include "Support WebCast" in the subject line, and that way you can make sure it gets routed to us.

Troy: Yes. In answer to that, when you do have Single affinity set, no matter the number of nodes, no matter where you're coming from, if you are connected to and have a session open with a machine, then after that session has broken down, you're going to be kicked out of your session, like anything else. We'll use SSL Web sites as an example. If you're connected directly to your bank's Web site and you have that session opened, if something happens to that server or the Web site application, if something happens to take that offline, you will be kicked out, and then you will be able to re-establish your connection. There's no difference with Network Load Balancing. After you've created that session and it's broken down, you have to re-establish the session. It can't just be passed from node A to node B or node B to node C. It has to be re-established.

The way you control that is in the registry key parameters that I covered. In case you missed it, it is on slide 19, titled "NLB in the Registry" There's a KB article, and I'll read that off: it's Q193601 (http://support.microsoft.com/support/misc/kblookup.asp?id=Q193601). There is a registry key for WLBS parameters. I apologize for not mentioning this earlier: WLBS is synonymous with NLB. In Windows NT 4.0, it was referred to as the Windows Load Balancing Service (WLBS), and it's kind of evolved into a different product, and so the name was updated as well. I just wanted to point that out. But in WLBS\Parameters, you can use AliveMessagePeriod. In fact, this is in the first two examples that I have in this slide, the period between "I am alive" or the heartbeat messages broadcast by each host, and the number of periods to wait before declaring a host is dead.

Again, by default, you have heartbeat that happens every second. Suppose a node misses five heartbeats in a row. Now, if they hit that fifth heartbeat, and then the tenth heartbeat, and then the fifteenth, there could be some networking problems, but that node is not going to drop out of the cluster. Convergence will not be taken — but if it does miss it, one second heartbeat, every five that it misses, it's going to drop out of the cluster, and then convergence is going to happen, which takes approximately three seconds.

By default, your turnaround is about eight seconds. And if a user gets disconnected from that application, almost 100 percent of the time, by the time they get that application reconnected, convergence has happened and everything is up and ready to go. So unfortunately, because of the session state and SSL, and things where we're actually not just requiring session state, you would not ever want to pass that session on to another machine, without actually having the session re-established. That's a big security breach. So that unfortunately is the deal with Single affinity. But usually, by the time the client realizes they've been disconnected and re-enables their client (whether it's Web-based or whatever), by the time they get reconnected, the chances are very good that convergence has happened again. They will then hit one of the nodes that is still up, one of the nodes that is still running.

Jason: Okay. You stated the None affinity setting is used for HTTP, and Single affinity is for FTP. What do I do if I want to host FTP and HTTP services on the same Network Load Balancing cluster?

Troy: Great question, absolutely great question. If you'll look back to the slide 17, the "Port Rules Setup" slide, you can add as many rules in there as you'd like. In that scenario, specifically, you could just create one rule, set Port range at 80 to 80, protocol TCP, None affinity and Multiple hosts, and add that. You can go right back into the UI and set Port range to 20 to 21, protocol TCP, Single affinity, and Multiple hosts and add that one. You want to add those rules across all nodes, but you can add as many rules as needed. You can definitely add as many as possible. So that's the answer to that one.

Jason: How many network cards are supported in a Single node, noncluster, to balance in-bound and out-bound traffic to a single SQL Server?

Troy: To be honest, the single node, noncluster is what's throwing me off. The limitation for Network Load Balancing is NLB can be bound to and enabled on just one interface per machine that's in the cluster. You can add as many network cards as you'd like. Again, you have to watch the routing and make sure you keep everything in line, but you can add as many NICs as you'd like. I hope that answers your question. I apologize if it does not. If it doesn't, feel free to follow-up, because I don't exactly understand the scenario that's being described.

Jason: How are SSL certificates implemented with a Network Load Balancing cluster? Is one SSL certificate used on all cluster machines for the virtual IP address?

Troy: Right, that's exactly right. It's used the exact same way as if you just had a single node. Obviously, the certificate is going to be installed and used for that IP address. So each node uses it as it should, as you would hope it would use it, and as it should use it, with a single node. You would use it across all of them. So you can just look at it like it's one computer. They're all going to have the same data, and that includes certificates, Web content, and things like that.

Jason: If a Windows 2000 server has multiple NIC cards connected to the same subnet, and Network Load Balancing is not being used, what are the configuration considerations to gain reduced latency between clients and the server, where the server itself is acting as a file and print server? Will configuring Network Load Balancing improve that performance?

Troy: If you only have one server, you're not going to be load balancing, because again, you can only enable NLB on one NIC per machine, currently. Again, I'd like to stress that it is currently the limitation for Windows 2000. So if you only have one file and print server, you're not going to be gaining anything by enabling Network Load Balancing, because you don't have another host to load balance with.

If you did enable a second host, or bring online a second host with the exact same content, then depending on the way it's deployed, depending on the way it's going to be used, you could use Network Load Balancing. But it sounds to me like it would be a scenario that could possibly require something more along the lines of Microsoft Clustering Services, or something that's a true clustering service, like noted earlier, that will consolidate your resources. It's going to keep all the resources as if it's one machine, as opposed to just balancing in-bound connections. So I hope that answers your question.

Jason: Great. Is it possible to load balance self-developed RPC servers in a network load balanced cluster using Single affinity mode?

Troy: Yes, absolutely. There are no issues. Again, because we're talking TCP/IP, absolutely. It's going to depend on the function that the RPC service is doing. As long as we understand the difference between no affinity and Single or Class C affinity, as long as we understand that session is maintained, then if the application is developed, it's all going to depend on the way the application interacts with the client. Let's say, in a VPN connection, if I make my PPTP connection to VPN server A, and I bring in my GRE traffic for logging on and for setting up my PPT session, then if there's no affinity, there's a good chance that could go to a different node, and of course you're going to have problems there. The same thing with FTP. If 21 is in-bound to one node, if we don't have affinity set, 20 could come in and go to a completely different node. So, depending on the way the application works, if there are secondary connections, if there is session state required and things like that, that's where you want to take affinity into consideration, and play with it as you're developing that application.

Jason: Are the Wlbs.exe query results available in a Performance Monitor snap-in?

Troy: That's a good question. I'm going to have to research that. I do not know. [Follow-up answer: There are no counters in Performance Monitor for Wlbs.exe.]

Jason: Okay. When you set up Network Load Balancing with two NIC cards in unicast mode, what NIC card should be bound first: the one with the Network Load Balancing cluster address, or the one for private communication?

Troy: That completely depends on the way that your routing is going to be structured. If you are using that second card simply for administration purposes (so, you're going to connect to that second NIC just so you can talk to that machine, and not have to talk to the network card that is actually doing the load balancing), then I would suggest binding that load balancing NIC first. If you're using that second network card for throughput, basically to allow transmissions to come in one network card and out the other, then rather than binding order, you would consider your gateway information and your routing table on that local machine, to judge where it's going to respond and which network card it's going to respond out of. But the binding order is probably not going to come into play at all, actually. You could probably just disregard that: which to do, one before the other.

Jason: Okay, great. In multicast mode, are there any settings required on the Layer 2 switch or the router connector to the L2 switch?

Troy: As long as the switch is multicast aware, as long as it's able to receive and recognize multicast packets, then there's really nothing else to set up. The one thing I will reiterate is that one of the issues that's brought up commonly with multicast is the upstream switch flooding, and the fact that IGMP does spread itself out very thoroughly across your subnet and across your local subnet. So you can use VLAN. Of course, this is something that I can't really get into. Your switch manufacturer can get into that. But it is something that I would suggest, to use a VLAN that to restrict all of those fragmented or all of your IGMP packets to specific ports in the switch, so that you don't see your IGMP traffic going crazy three or four switches away. It's definitely something to consider. But other than that, as long as they're IGMP aware, as long as they're multicast aware, then they should be ready right out of the box.

Jason: If you were clustering four Web servers using Single affinity, and an application on one of them stopped responding, would Network Load Balancing detect this and be able to redirect the traffic to another node, or would Network Load Balancing continue to direct traffic to this now unavailable Web server?

Troy: As long as the node is unable to respond to the heartbeat — and this again is something that we talked about earlier, that I absolutely want to make a point of. If you have four Web servers and the Web service stops on one node, but it's still able to respond to in-bound TCP traffic (it's able to respond basically to this heartbeat that I've referred to a couple of times), it's not going to pull itself out of that NLB cluster. There are a lot of administration tools where you can run a script as soon as something like that happens. As soon as the service starts, you can run a script that will do a wlbs stop, and it stops the service. Then, after that happens, you have the whole five seconds, by default, for it to miss heartbeats, and then three seconds for reconvergence. Then, the machine comes back up again. But with affinity, it is very important for applications (and it would be a big mistake for Network Load Balancing to be able to move something that has session state with one machine) to be able to dynamically move that from one node to the other. Whether we're just talking about if it's Web-based, using affinity for some other reason, or SSL, it's going to treat the two scenarios the same, and you would want to just move an SSL session from one machine to another. That's very important, that that session gets established and is maintained by that machine. So it would stay down, and the client would continue to go to that node, until that node drops out, and until reconvergence happens.

Jason: There appear to be a number of manual configuration parameters that can be implemented improperly, total weight control not equal to 100 percent. I guess that's an example. Are there any correction mechanisms? Or, what will be the consequences of incorrect parameter values?

Troy: I'm assuming that we're talking about parameter values in the Network Load Balancing driver, in those three tabs in the driver properties that we've been talking about. You'll see some issues, and they're all very well documented. Convergence will not happen. If a parameter is set up improperly within the Network Load Balancing driver, that would hinder or stop the ability for Network Load Balancing to function, it's not going to converge. So you will not see them converge. You can do a wlbs display, one of those .exe commands that we talked about, and you'll see. It will give you the convergence state, and you should see that it is not converged.

It is very, very important, when you initially go in, to make sure that things like the host priority (which will determine the default host), the virtual IP address, the subnet mask and the multicast enable setting are all congruent, not to mention your port rules. Those need to be mirror images of each other on all nodes, or else there could be some other issues. The nodes will start to refer to a duplicate IP address on the network, and things like that; that's just one thing that you might run into.

But for the most part, if a parameter is really misconfigured, it's just not going to converge. You have to check back through and make sure that everything is set up, and that there are no duplicates where you don't want duplicates, and that everything is the same where you'd want everything to be the same. Just make sure that everything is in line.

Jason: I'm going to apologize if I've already asked this question. It sounds familiar: In multicast with one network card, if we use a dedicated address, which address should we bind first to the NIC card: the primary address or the dedicated?

Troy: No, that hasn't been asked, and that's an excellent question, something that I didn't bring up in our slides. In the properties of IP, on that single network card, without a doubt you want the primary IP address, that dedicated IP address, not the virtual IP. You want the dedicated one bound first. Then, you go through and bind your virtual IP or IPs. It's a very important point to make. In fact, this is one of the things where you'll get the duplicate IP address, and some odd problems along the network, and it's absolutely good question. I believe there is a KB article on this. You may want to search on "duplicate IP" and probably "dedicated," I don't remember the exact text in the title. But there is information specific to that. But you do want the dedicated IP first, then use your virtual IP, which will be shared across all of them. That's a good question.

Jason: AliveMessage registry keys — I'm not certain I'm reading that correctly — which systems do the keys apply to: the local system or the foreign system?

Troy: The local system, they reply to the local system. These are registry parameters that you would want to, as the administrator, make sure that they are the same across all of your nodes. If you make an adjustment away from the default from one node, you're going to want to make that change on all the nodes. But regardless, it is for that local system, just like the registry values. You're going to want to make sure that it's set up the way that you want this local system to function. Getting more into the question, the AliveMessagePeriod is the period between "I am alive" messages broadcasted by each host that is specific to this host. So it's asking, "How long am I going to wait until I send another ‘I am alive' or another heartbeat?"

Jason: Which takes precedence, TCP/IP filter or Port rules filter?

Troy: By the question, I'm assuming that we're referring to the advanced TCP/IP filters that are in the TCP/IP properties, in the properties of each one of our network cards that has IP bound. If that is what we're talking about, as far as TCP/IP filters, and if we're talking about port rules filters, then when you create a disabled filter mode, you can create a disabled rule for a specific port or port range. If that's what we're talking about, then the port rule will happen first, because the packet that the NLB driver does sits directly above our NIC driver and below IP. So TCP doesn't even get to it until the NLB driver decides whether or not to pass the packet up its stack or not. So it will absolutely be touched by the port rules filter first.

Jason: If you have one NIC on a hub with Network Load Balancing enabled and then one NIC into a switch, does your public traffic have to be going through the hub, because this is where Network Load Balancing is bound? I would rather have my public traffic going through the switch.

Troy: The load-balanced traffic is only going to go to the network card, and it's only going to be picked up on the network card that has Network Load Balancing enabled. So, if you enable it on the network card that's plugged into the hub, the traffic is going to hit the network card that's on the hub. If you enable it on the one that's on the switch, the traffic is going to hit the one that's on the switch. So, as you're deploying, decide which network card you'd like to enable Network Load Balancing on.

Jason: Can you give us examples of when you'd use a single NIC setup as opposed to dual NICs? What is the advantage of using two NICs?

Troy: First, the advantages of using two NICs: if you have servers that are really tied up with traffic, or if for any reason you do not want any traffic inbound or outbound from the network card that's not a part of the load-balanced traffic, you can put in a second network card that absolutely is completely off of the scope of the load balanced cluster of your cluster. You can administrate, or if you're sitting at the server, you can connect using that network card, assuming that the subnets are different, or that you have your routing configured so that your traffic will go out of that second card, that dedicated card.

As far as examples, first and foremost would be the example I just alluded to. If you have a reason to have one network card that you cannot or you will not attach to and be able to talk to or send information to, then using a second network card is the way to go. If you absolutely have to use unicast mode for whatever reason — if your switches do not allow multicast IGMP, or if you just have a problem with it — you can use unicast mode on those network cards. But if you ever want to have the two machines talk to each other, you'll have to install and enable a second network card that does not have Network Load Balancing on it, so that they can talk back and forth. Those would be two prime examples of why to use two network cards, and the benefits of using two network cards.

Jason: This is leaning toward one-on-one product support, but I wanted to ask it and see if you know about any known issues: In a certain situation, we were trying to log in into a machine with Network Load Balancing. We experienced a long wait before the machine logged in. If we unplugged the Network Load Balancing NIC, the problem went away. Are you aware of any known issues or a quick troubleshooting step to solve this problem?

Troy: It sounds like a scenario where the nodes have more than one network card. If that's the case, there are really no known issues. Chances are, this has something to do with routing or with the device that the two network cards would be plugged into, like the switch, or whatever. You may want to consider the MaskSourceMAC, or things like that, which are going to enable the routing through the switch. Again, it sounds like there's more than one NIC in it, and there are really no known issues. There could be a number of things that could cause that problem, and using a network sniffer or something like that may be your best bet. That would be what I would probably use, right off the bat, to see if I could combat the problem, to see if I could figure out where it's coming from.

Jason: Under what circumstances would using a hardware load balancer be a better choice than using Network Load Balancing?

Troy: Because Microsoft doesn't produce a hardware load balancing solution, it's kind of hard for me to really get into that. Obviously, one scenario would be, if you have a hardware load balancing solution, there's a possibility that you could enable the load balancing on more than one interface. There could also be some other restrictions that we have placed on our NLB solution that again, I would like to point out, might be changed, or that we're looking at for future releases of the server product. But regardless, some scenarios or some situations are not restricted, using a hardware solution. It really depends on the solution and on the device. Because we don't produce one, it's kind of hard for me to speculate. Without specific examples, it's hard for me to speculate.

Jason: How do I know how many nodes are in and out of the cluster?

Troy: If you run wlbs display from any one of the nodes that are inside of the cluster, at the very bottom of it, there is an output that says, Member of… I can't remember the exact text, I don't have it front of me, but it's something to the effect of, "Member 1 of 12" or "Member 1 of 2" or "Member 1 of 4." So you pretty much can tell. It's going to be that final number. It's telling you which member you are in regard to the number of total members. That's the quickest and easiest way to do it.

Jason: Can Network Load Balancing parameters be set during an unattended installation of Windows?

Troy: That's a good question. To be honest, I don't think so. I don't think that there is an option in the unattend to enter that data and to set it up, mainly because of the rules and things like that that are enabled using NLB. It's a possibility. It's something that I could look into and get back to you very quickly on. I'll talk to someone who works more with unattends and setups and things like that. But you can use it remotely. Again, you can use the Wlbs.exe, that list of commands that I mentioned. You can run wlbs setup, one of those command-line tools. So, you're more than welcome to do it that way, but I'll have to check. [Follow-up answer: No, the parameters for the NLB driver cannot be set up during an unattended install.]

Jason: Is there a proper procedure for removing a node from a cluster for maintenance? I have two Web servers configured with WLBS.

Troy: To be honest, if you're sitting at the console, the quickest and cleanest way of doing it (either one of the two nodes) would be to just run wlbs stop to stop that service, and stop the machine from being a part of that cluster. You can do your maintenance, put it right back online, and run wlbs start, and it will join right back up. After convergence, you'll be ready to go. That's the easiest and the cleanest way of doing it.

Jason: In unicast mode, if there are two NICs, one with unicast on Network Load Balancing and one dedicated NIC for communicating with the back-end network in SQL, is there any reason why the non-Network Load Balancing NIC would stop communicating with the back-end network?

Troy: With the back-end network, no. Obviously, it would depend on routing again, whether or not the two NICs are on different subnets. Obviously then, the back-end network would have its subnet route, and it would know exactly how to get to the back end. If there's a problem with routing, and the two of them are on the same subnet, but yet plugged in to different devices and going in different directions, you could have problems with two entries in your routing table to the same subnet, and you'll have packets going out the wrong interface, even though, as far as IP and routing is concerned, there's no wrong interface. So that could be one of the issues.

Other than that, I don't know. There are probably a lot of factors that would go into that. So again, I would consider using the network sniffer or something of that sort, and attempt to make your connection, and then see if it does kick it out of the load-balanced NIC. If it does that, then you know you have a routing problem. You have to work with your routing table and make sure that it's set up properly. Maybe you change the metric numbers, or something.

Jason: I've read that you can use Network Load Balancing on a Windows NT print server. Is this true? And how about for Exchange servers?

Troy: As far as the Windows NT print server is concerned, as long as all the print servers are maintaining the same print back end, as long as there's no problem going to one and not going to the other, which I'll get into with Exchange, then absolutely, you can use Network Load Balancing with printing.

I'll just briefly say that with Exchange, if you have two nodes and you have mailbox from Bob and Bill on node A and Bob and Bill on node B, and Bob accesses his mailbox on node A, node B obviously is not going to be synched up with node A. Although immediately after this you can do whatever you can to try to merge the changes and make sure that everything is updated, still, with the basic function and the logic behind e-mail, the logic behind load balancing and things like that, you're going to break that basic logic. In that, you have two different stores of the same information, and it's going to be updated on one site differently than it will on the other. It's something you really have to watch out for, specifically with Exchange.

Jason: When using single host filter mode, will lower-priority nodes only receive packets when higher-priority hosts leave the cluster?

Troy: That is absolutely correct. In fact, when using single host mode, if you have three nodes, Priority 1, Priority 2, and Priority 3, if 1 goes down, then 2 takes over. Priority 3 is never in the picture, unless 1 and 2 are down. It's very similar to the default host, except that there's an actual rule defined for it. Just know that the other ones, the ones that are not accepting the traffic, they're literally just sitting there as backups, and there's going to be no traffic accepted by those nodes.

Jason: What are the best affinity settings to use for dual-homed Exchange 2000 Outlook Web Access servers?

Troy: With OWA, because the connection is going to be made on the back end to the Exchange server, on the Web site front end, it really doesn't matter. You can use no affinity, because it's just going to be a Web-based connection. Then, after you're connected, you're going to have that connection to the back-end server. Again, depending on the way it's deployed and depending on no affinity versus Single affinity and knowing the differences between the two, if you do see performance problems, you may just consider using Single affinity. It's definitely not going to hurt anything to use Single affinity for port 80 for OWA, just for the front end.

Jason: If the Terminal Services server using Network Load Balancing becomes unavailable, do the Terminal Server licenses for that node become unavailable?

Troy: That's a good question. That would definitely fall within the scope of the Terminal Services, because Network Load Balancing is just going to be balancing that in-bound traffic. But that is something that I could definitely see becoming an issue with Terminal Services and with licensing. So if you'll note that one, Jason, as well, I will do my best to talk to someone in Terminal Services and find out what that scenario might produce.

[Follow-up answer: Unless clients are thin clients, all Terminal Service licenses are stored on the client. And even if they are thin clients, the licenses are only supported if stored on a license server that is not either of your Terminal Services (a domain controller, for example). Licensing for Terminal Services was designed to prevent exactly what your question is, and that goes for a stand-alone Terminal Server or a cluster of 10 of them.]

Jason: Okay, this sounds like a very similar question to what we just asked a couple of questions ago: In a two-host cluster, if there's no port rule, can I assume all the traffic would be routed to the highest-priority host?

Troy: Yes, it's going to be on the Host parameters tab and that Priority box. It's going to always send it the highest, whether that's 1, 2, or 3. It's always going to go the highest only.

Jason: Okay, and: If this host goes down, would all traffic be routed to the other host?

Troy: It would be routed to the very next host in priority line.

Jason: Okay. What effect do the metric settings have on the NIC dedicated to Network Load Balancing?

Troy: The same effect that it has on any other network card. This is something that I alluded to earlier, as far as routing is concerned. If you have two NICs on the same subnet, but they're plugged into two completely different devices going in different directions, obviously then, in your routing table, you're going to have two routes to the same subnet, using two different interfaces, both with a metric of 1, by default. You're going to confuse your routing. That problem is a basic routing problem. You really want to stay away from an issue like that.

You can use your metric numbers on the interfaces, if there's an outbound request going to a subnet, to specify which one you want to try to use first. Again, depending on the way your routing is set up (and I have worked with scenarios where this was the way to get around problems), set the metric of 2 to allow throughput on our back-end network card, so that way traffic is not actually responded to, across or using the load balanced NIC. It responds to the one with the metric of 1 on the back end. Again, it completely depends on routing, but you can use it like you would with any other machine. With load balancing removed, you can use it the same way you would on any other box.

Jason: Can performance be improved if two NICs are used such that one NIC is used exclusively for Network Load Balancing and the other NIC is used exclusively for administrative purposes, such as backup?

Troy: Absolutely. Because with just simple bandwidth, if you're restricted to a 10 MB or a 100 MB maximum (of course, we're not going to hit that, but if we're restricted to that on the network card), if all you have is the load balanced traffic hitting one NIC, and on the other NIC you do all your other administration work, of course the network card that's being load balanced is going to have less work on it. The throughput won't be dramatic, but there will be a difference in performance, absolutely.

Jason: Which port and protocol numbers do heartbeats use for firewall configuration?

Troy: It's just a broadcast packet that doesn't use a port. It doesn't use what you would normally think of with a TCP connection. Again, that is important, and it goes back into subnetting and making sure that all of our machines or nodes are on the same subnet. If we're unable to broadcast that heartbeat, for any reason, from one node to another, we're going to have problems. If we need to enable ports, and if we need to enable protocols and things like that, a lot of times that has to do with a router and something that's being blocked between one machine and another machine. That's something you want to stay away from, because of heartbeat and other variables. The heartbeat is not something that has a normal TCP connection-like setup. So it definitely does not use what you would normally use.

Jason: Would you have Network Load Balancing enabled on both NICs in a redundant NIC situation?

Troy: Actually, you cannot. In a redundant NIC situation (and again, this goes back to either a software or a hardware vendor that's doing this redundancy for you, on a machine), you can only enable Network Load Balancing on a single network card. So it does depend on how the network cards are configured. The way I understand it, though, is that with most of them (and again, in testing, this would fall out of the scope of my expertise, because it's definitely going to be a third-party solution), as long as that network card is completely disabled, and its properties and its components are not included in the machine's IP stack as a whole, then you don't need to worry about it, because NLB is not going to have any conflict with the other interface that's up and running. As soon as the first one goes down and the other one comes up in redundancy, you still only have one interface that has NLB defined on it, or is being used on it. But that completely depends on the vendor and the way that redundancy is handled.

Jason: For an ASP-hosted application that relies on sessions and is accessed by users from all over the Internet, must we use the Class C affinity setting to avoid problems with other companies' proxy server configurations?

Troy: No, you wouldn't have to. But again, if you have a proxy array or a bunch of clients that are sitting behind something that is proxying out or is doing NAT out, you have to realize that those packets are going to come from a specific IP address or a range of IP addresses. Depending on the two, three, or however many sites you're looking at, you may want to use Class C affinity. But, in the question, I'm just assuming that everyone's going to be using the sites, and there just so happen to be quite a few sites out there with different groups of users behind a proxy array, or groups of users behind a NAT box, things like that, in which case you don't need to worry about it. You can use the Single affinity, and the algorithm will work itself out. Like I said, it's pretty much half and half mathematically; or, depending on how many nodes you have, it's pretty much right down the middle.

Jason: How do you do WLBS testing to make sure that it's working?

Troy: That is an excellent question, I'm glad that we got to this one — an example would be if you have two Web servers and they're both running NLB, and you're balancing that out. Like I said earlier, if you have a scenario where you're only testing for one or two clients and you keep hitting the same node, it's not a good test, because it's like every time you flip a coin, you're not always going to hit heads then tails then heads then tails. It's going to work itself out, in the number of tries that you give it, to about 50/50. But if you have two Web servers, the best way to do it is if you hit one node and you know you've hit that node (like you've made a little comment in the bottom of the Web site or something so you know what site you've hit), stop WLBS on that server. Run wlbs stop, and then try to hit the virtual IP address again. You should then hit the second server. If that doesn't happen, then you're not load balancing, and you might want to make sure that convergence happened and everything else is in line.

Jason: Okay, one quick follow-up to that: What if they're using Secure Sockets Layer? Does that change anything in the configuration, in the testing?

Troy: No, it would be the exact same thing. If you're making a session to a machine, or if you're not making a session to a machine, and if you drop one host out of the convergence, and you're connected to your SSL, of course you're going to get dropped out of that session. But as soon as you go back and reconnect, if you don't hit the other host, then you're in trouble. Then, you need to make sure that convergence is going on and that everything else is set up properly. Make sure you don't have any errors in your WLBS display. So no, SSL does not make a difference at all.

Jason: Is it possible to load balance two ISA servers using server publishing, like NAT?

Troy: Yes, that again is a problem or an issue that we're seeing quite a bit. If you're using Network Load Balancing on your internal network cards of your ISA array — so let's say you have three or four ISA boxes, you're using NLB on the internal to load balance the requests from the traffic to and from an internal server — then that's fine. The problem comes when you incorporate NAT and you have load balancing going on on the external side of ISA, and then you have server publishing on the internal side.

The problem is that if a request comes into the virtual IP (VIP) and it hits one of the machines, it's going to pass that connection through to your internal server, to whatever it is, SSL or whatever's being server published. It's going to pass it through. And when the machine responds, there's no guarantee that it's going to go to the same host. Because again, with Web publishing, a second session is created internally on the ISA Server. Therefore, you have a direct connection between point A and point B. When you're using server publishing, that second session is not created, so you have to be careful with the Web server or whatever the server is internally, that's being server published, because it's not necessarily going to know which one of the four ISA servers it came from.

So that is a little hitch, and there's a lot of documentation out there on it as well. I also work with ISA Server a little bit, and if you look at http://isaserver.org, a Web site that is not maintained by anyone at Microsoft but is an excellent resource, they do have quite a bit of information. You can interact with people who are running into this same problem and see what's going on. But it is something that's being looked at by the ISA Server development team, I can guarantee you that.

Jason: We are down to our last question, and here it is: How would you set up port rules so that you assure that all traffic to a particular host on a particular port gets to that host, and is not load balanced?

Troy: I would set up a single host rule. Actually, there are two ways of doing it. You can configure a single host rule, and then configure that port. So, if we're looking for some random port, port 2000, create a port rule for 2000 to 2000, TCP. You set it to Single affinity, but it's not really going to matter, because we're going to go the single host filtering mode. Then, we want to make sure that our handling priority — and I apologize, the affinity is not going to come into play. If we go to single host mode, we're going to be able to set the handling priority and the host that you want to have all that traffic; it needs to be the first priority. Everybody else is going to be 2, 3, 4, and so on. As soon as the 1 goes down, the second handling priority is going to be the one that's going to take all that information. You have to remember that.

The other way you can do it is just to create a rule for it and make whichever node or whichever machine you want take all that traffic. You can make it the default host, which is on the host parameter setup in the Priority option box. You can set that to a 1. And then again, when your priority is set to 1, and you're online, you're the default host, which means you get every bit of the traffic that does not have a port rule defined for it. So there are two different ways that you can guarantee that traffic does not get — it will get load balanced per se, but you know which node it's going to go to. You definitely know which node.

Jason: Okay, great. That does answer all the questions that were submitted today. So that's going to wrap up our session. I want to thank all of you for joining us today. I hope the information was useful to you.

Again, we are very interested in your feedback regarding the WebCast program. You can always send us your feedback through e-mail, to the alias feedback@microsoft.com. If you use that alias, just make sure and include "Support WebCast" in the subject line.

We hope you join us again in the near future. Thank you, and good-bye.