Using NLB to build TMG (or UAG) clusters is heavily dependent on switches used. HP Procurve has shown to not being “up to the job” in many cases.
After spending the last days helping a customer Migrate from ISA to TMG and trying to figure out how to get NLB to work in their environment I thought i should share some findings.
Unicast or Multicast
It is important to remember that TMG does not care if you use Uni- or Multicast. This is entirely a switch problem. Problem is that many network guys do not know how to pick the right one for the specific switch model at hand.
NLB in Procurve
When using typical Procurve switches (like 2800-series) you will find yourself stuck on using Unicast NLB and also having to add some static MAC-address entries in the environment.
When trying to use Multicast NLB we discovered that HP switches will not let you add Multicast MAC-addresses as static entry’s in many models.
One thing that i noted in this project is total lack of information from HP on how to integrate NLB with there different models.
Why NLB?
Many of you might say… Stop using NLB and get a HW LB instead…
In my opinion NLB should always be the first load balancing you should consider when building TMG and UAG clusters.
Why?… Simply because this is the one integrated into the product. If using any other LB you will not benefit from TMG’s integrated management. Configuring a stand-alone LB to detect service failures in TMG to cause a node-drop is not an easy task. I have also found that when using external LB you will in many cases not be able to use routed relations and will have some serious problems to get bi-directional affinity to work, especially in protocols like RPC.