by Jack Chen, Taos Senior Technical Consultant
As we have learned from Microsoft, WNLB (Windows Network Load Balancer) interfaces are connected to a Layer 2 device by default, it uses the Mask_Source_MAC to ensure that the L2 switch is unable to learn the original source MAC addresses of the NLB hosts. In other words, on an Unicast NLB, the switch is not able to associate a MAC with a particular port because it is masked, it just sends the data to all switch ports to ensure all NLB hosts process the traffic. Thus, it always create “flood” to L2 switch network, even though most of network engineers do not like such traffic -switch flood, but it is part of the WNLB strategy that it has to get the best throughput for the load of client requests by relaying packets which are sent to the VIP/WNLB to all cluster hosts. Since the WNLB (such as Exchange Cas Array) cluster shares the same switch with other computers and servers which it is very common practice, then this kind of “flooding” could always be annoy and consequently it might be a negative impact to network and server performance.
You might ask if there is a way to bypass or solve it? As I remember that I learned from Allen during the Exchange 2010HA cross-sites migration that we fixed the flood by isolating the NLB hosts in their vLAN from the other functional servers. Besides, we found that to use the Multicast with IGMP on a network device supports IGMP snooping could be the best and thoughtful solution, because it can restrain multicast traffic in a switched network without the use of dedicated VLANs, however it is more costly and complicated than unicast in terms of hardware and configuration.
Just share with you that to identify NLB host in an unicast cluster, the masked MAC address is similar to the original MAC address, but with the first two fields replaced as follows: 02 which is, an NLB host with a host ID of 1 and a MAC address of 01-36-DD-4B-37-78 has a substituted source MAC address of 02-01-DD-4B-37-78. In a multicast cluster, the ARP response from an NLB host includes a substitute source MAC address in the Ethernet frame, but contains the correct NLB-Cluster MAC address in the ARP header. Although some Layer 3 routers are confused by this response and cannot perform the ARP mapping automatically, but we can create a static ARP mapping on those routers (or L3 switches) that maps the NLB VIP to the NLB-Cluster MAC.
We probably do not mind if using an unicast NLB or multicast NLB on an Exchange CAS Array or TMG Cluster, but the different behavior it provides and the different efforts we need to invest would take us a serious consideration, since either one would lead to a different consequence.