The quick summary of this post is, “Don’t use NLB on teamed NICs.”
Microsoft clearly says that NIC teaming “may” cause problems with NLB in KB 278431.
This is where things get confusing, because the issue is just that; it may be a problem. The reasoning is really fairly simple. Teaming software, in many cases, overwrites the MAC address of the individual NICs in the team. Well, NLB, in Unicast, also overwrites the MAC address. So, the problem is:
- Will the teaming software allow the overwrite behavior of Unicast?
- Will the teaming software handle the failure of a NIC in the team and the overwrite process of NLB in the event of a NIC failure?
The answers are, it might not allow the overwrite in Unicast, and it might not behave properly in the event of a NIC failure and passing of the MAC to the other NIC in the team. Thus, the “may” statement earlier.
The way it needs to work is that teaming software for NICs nees to support the overwrite of MAC addresses. Many vendors do now provide this support. A workaround exists allowing the team MAC address to be set directly through the management tool. Compaq/HP, for example, defaults to the MAC address of the primary adapter. After NLB sets the MAC on the virtual adapter (the NIC team), the Compaq/HP software does not propagate the MAC address to the physical adapters. To make it work, you have to copy the NLB MAC and paste it into the team MAC in the management software. Workarounds and High Availability environments can not be used in the same sentence, thus, this is not a best practice.
My contention is simple: Since we can’t guarantee transparncy of failure of the team and how it allows NLB overwrites of the MAC (this is a hardware driver issue that Microsoft can not guarantee will behave properly), it should be considered a best practice to not use teaming for NLB NICs.
By the way, this behavior does not change in Longhorn.