i made the same mistake in my interpretation. When i did my first NLB in production I learned some things. Its worth considering the following points:

First – and most importantly – there is not really an idea of a heartbeat NIC in NLB the way you are thinking of it. What you have in your head is something that exists in ‘Windows Failover Clustering’ not NLB, and its in a Failover Clustering setup where we would typically create a seperate hearbeat network.

I think that its an easy mistake to make. when we see NLB hosts configured with multiple NICs we naturally assume that one of them is like a heartbeat NIC. But actually thats not the case. The reason we have multiple NICs is not for any ‘heartbeat’ reason

Here’s the rub:

In an NLB host with 2 NIC’s we usually have the NLB Service bound to only 1 NIC. Its only this NIC that the NLB driver is bound. Its only this NIC that participates in NLB. All of the NLB related function happens on this NIC. No NLB related communication happens on the other NIC to which the NLB driver is NOT bound

The NLB NIC is also the NIC where the ‘cluster’ Virtual IP is bound. So this is the NIC that receives our application traffic. This is the NIC we chose when we first create an NLB cluster in the NLB Manager.

Any other NIC’s in the machine are not participating in NLB at all. They are there just like normal NIC’s
A NIC that doesnt have the NLB service bound to it is not aware of NLB,
A NIC that doesnt have the NLB service bound to it doesnt ‘converge’ with any other NIC, and does not send any ‘heartbeat’ traffic

This is confirmed in MS documentation

So – you ask why do we have a second NIC?

The reason why we have 2 NIC’s is usually to seperate ‘application’ traffic (traffic we want to load balance) from ‘host’ or ‘administration’ traffic or other traffice that we know we dont want to load balance. This includes traffic where the 2 hosts need to talk to each other,or talk to anything else on the LAN – like regular individual windows hosts.

You see, there is a big processing overhead associated with receiving data on an NLB NIC Any packet received on an NLB enabled NIC has to be processed by the NLB driver. So if we receive anything on an NLB NIC the driver will have to process it and figure out if its something that NLB interested in or not.

Typically we dont want anything other than the application we are trying to load balance to come in on an NLB NIC. We certainly dont want ‘AD Domain’ traffic or maybe ‘SQL’ traffic or ‘RDP’ or anything like that going on to an NLB address. We dont want any of the regular windows chit chat coming in through this NIC either. This bad for 2 reasons

1) becuase – depending on if we are running unicast of multicast mode – the hosts might not be distinguishable from each other at Layer 2 (MAC address) on the NLB NIC – so we may not be able to know which host we are reaching. and….
2) because every single one of those packets will have to be processed by the NLB driver on either or both of the hosts.

In my environment we only use NLB for INTRANET applications. Both NICs are connected to the the same switch, but NLB and non NLB NICS are on different VLANs. There are so many difrerent ways you can set this up. There is not 1 correct way. It depends what you are trying to do.

I do this:

-> NLB NICS are connected to switchports that are set on a dedicated VLAN (example. 10.0.20.0 /28)
-> non NLB NICS are connected to switchports that are set on a seperate VLAN (example 10.0.50.0 /25)
-> Cluster IP address setup on the NLB NICs in the NLB IP subnet and NOT the regular ‘subnet’
(ivorb’s great guide above is very misleading in this step (see my comment above)
-> NLB NIC’s are NOT configured with any default gateway or DNS servers
-> non NLB NIC’s have the Default Gateway and DNS (example – core router on 10.0.50.1)
-> The DNS name of the application i want load balanced is manually registered in DNS with the NLB cluster IP address only.
-> DNS dynamic registration is turned off on the NLB NICS
-> enable IP forwarding from the NLB NIC’s to the non NLB NIC with ‘netsh interface ipv4 set int “” forwarding=enabled’ so that replies to NLB traffic can be sent out on a different NIC to that which it was received on.

With the above setup, my NLB NICS are effectively ‘receive only’ NIC’s and they only receive application traffic that i want to load balance. Any and all traffic thats sent from any NLB host is sent via the other non NLB NIC. Likewise the hostnames are registered on the non NLB NICs, so anything thats intended for the host name (rather than the application) comes in to a refular NIC.

This works pretty well for me.

I quote from this blog post which explains it quite well:

http://blogs.technet.com/b/clint_huffman/archive/2007/10/08/an-optimal-network-load-balancing-nlb-configuration.aspx

“[Windows Failover Clustering].. uses a backend “heartbeat” network used to determine if their partner server is alive or down. NLB also has a “heartbeat”, but it’s heartbeat is really just broadcast TCP/IP packets on the NLB enabled network… let me repeat… on the NLB enabled network…..”

Does anyone disagree with this? If so, help us understand. Also, can someone comment on how the physical hosts should be wired to the switch? For example Can you place a crossover cable between the physical heartbear NICs and then connect the physical Client NICs to the switch?

Guest Machine 1
LAN NIC: 192.168.1.100
NLB NIC: 10.0.0.1

Guest Machine 2
LAN NIC: 192.168.1.101
NLB NIC: 10.0.0.2

NLB VIP 10.0.0.3

I have done this and it is the only way I can get the vip to be pingable. If I make the VIP 192.168.1.113, I cannot ping it.

There are no VLANS in this lab configuration and I’ve been super lucky that almost all the clients I’ve worked with so far with Exchange 2010 either had hardware load balancers in place or purchased them for the Exchange project.

your diagram shows your NLB cluster with public and private NICs. They are on different IP subnets.

It looks like you want your private nics (10.0.0.x) to be heartbeat only, with the public NICs (192.168.0.x) to be used for application IO.

But in your NLB cluster you are binding the cluster IP (192.168.0.113) to the private NIC’s (10.0.0.x)

If this is a real world configuration then i can only assume that you are not using VLANs. For this to work as you have it, both your clients and all the NLBS NICs would have to be on the same broadcase domain.

Otherwise, traffic to the FQDN of your cluster (192.168.0.113) is never going to be reach the NIC where the Cluster IP is bound (10.0.0.x).

Put simply – if theres a router in there, traffic to 192.168.0.x will not get routed to the 10.0.0.x subnet.

Are you sure this works anywhere except in the Lab?

Also – apologies if i misunderstood your setup. but it really looks that way to me.