This article was previously published under Q317239
If you are using a deployment that uses both Network Load Balancing and an F5 Networks BIG-IP load balancer, the Network Load Balancing hosts may be unable to communicate with other servers that are load-balanced by the BIG-IP load balancer. This compatibility problem may occur if the Network Load Balancing cluster runs in Network Load Balancing's unicast mode and connects to BIG-IP over the same subnet on which Network Load Balancing receives client traffic.
This problem may occur because the recent BIG-IP software release includes a new security check that discards Address Resolution Protocol (ARP) packets in which the packet's hardware media access control (MAC) address does not match the source MAC address in the data fields of the ARP packet. If you run Network Load Balancing in unicast mode, Network Load Balancing's default behavior modifies the hardware MAC address of all outgoing packets, including ARP packets. This behavior causes these packets to be discarded by BIG-IP.
Network Load Balancing's behavior is intended to make sure that incoming packets for a Network Load Balancing cluster are simultaneously received by all Network Load Balancing hosts on the same subnet. To do so, Network Load Balancing sets the MAC address of its network adapter on each cluster host to the same value that is associated with the virtual Internet Protocol (IP) addresses. Network Load Balancing also modifies all outgoing packets to mask this address and thereby prevents the address's discovery by the switch to which Network Load Balancing hosts are connected. As a result, the switch broadcasts the incoming packets that are intended for the Network Load Balancing cluster's MAC address on all ports, and all Network Load Balancing hosts simultaneously receive these packets.
To work around this compatibility problem, use any of the following methods:
Switch to Network Load Balancing multicast mode.
You can configure Network Load Balancing to use multicast mode. If you do so, Network Load Balancing uses ISO layer 2 multicast to simultaneously distribute incoming packets to all cluster hosts. In this mode, Network Load Balancing does not modify the hardware MAC address of outgoing packets, and the compatibility problem with BIG-IP does not occur. You may not be able to use multicast mode in all installations because it is not compatible with some Cisco routers. (See Network Load Balancing 's Online help for more details.)
Use a hub instead of a switch.
If you connect Network Load Balancing hosts to a hub instead of to a switch, all incoming packets are automatically broadcast to all cluster hosts. In this situation, you can turn off Network Load Balancing's default behavior that masks hardware MAC addresses in unicast mode by setting the Network Load Balancing MaskSourceMAC registry value to 0 (the default setting for this value is 1). See the Windows 2000 Advanced Server Resource Kit for more details.
Use a different subnet.
You can avoid the compatibility problem between Network Load Balancing and BIG-IP by using a separate subnet to communicate between Network Load Balancing hosts and BIG-IP. To do so, you must install an additional network adapter in each Network Load Balancing host and in BIG-IP. Do not turn on Network Load Balancing on these additional network adapters in the Network Load Balancing hosts.
To modify BIG-IP's default behavior of discarding ARP packets that violate the security condition (which is described in this article), run the following BIG-IP command:
bigpipe global auto_lasthop disable
If you turn on BIG-IP auto_lasthop mode, BIG-IP uses an incoming hardware MAC address as the destination MAC address for outgoing packets, and it ignores its ARP table. You can set a global variable in BIG-IP that turns off auto_lasthop. If you set this variable, BIG-IP tracks connections using its ARP table instead. You can run the preceding command to set this variable. When you do so, communications between Network Load Balancing and BIG-IP are restored.
The third-party products that are discussed in this article are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.