When you configure NLB in unicast mode on virtual machines (guest machines) running on Windows Server 2008 R2 Hyper-V, you may not be able to ping the virtual IP address or the dedicated IP address of the virtual machines.
With this problem, if you take a network capture on the machine you are pinging from, you will see an ARP request leaves the client with the machine requesting the physical (MAC) address of the NLB node, but no response is received. A capture taken on the NLB node, however, will show the node responds to the ARP request but the response does not reach the client machine (source).
This is because the Hyper-V Virtual Switch drops the ARP response packet as the source MAC address on the ARP response packet does not match the MAC address of the virtual NIC on the Virtual machine’s settings.
When unicast NLB nodes respond to an ARP request with an ARP response, they don’t use their actual MAC address in the Ethernet Source Address field. This is because in unicast NLB the Virtual MAC address 02-BF-XX-XX-XX-XX will override the actual MAC address of the NIC so the nodes will use the spoofed MAC address (02-HostID-XX-XX-XX-X) for all outbound packets to keep the network switch from learning the virtual MAC address of the NLB nodes.
The virtual switch in Windows Server 2008 R2 has MAC Spoofing disabled by default on all ports which will drop the packet when it finds the spoofed MAC address in the Ethernet Source Address Field which is different than actual MAC address as shown below.
To resolve this issue, enable MAC address spoofing on the network adapter of the virtual machine (guest machine) using the following steps:
Note: The virtual machine must be turned off to make this change.
Note: Make sure to do this on all NLB nodes.
For more information about MAC spoofing, please follow the link given below to JHoward’s blog on the subject:
- Saravanan N
I've been having an issue with an NLB cluster and I'm wondering if this could be the cause. My cluster includes two virtual machines and one non-virtual.
I'm occasionally getting this exception: System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.0.100:80.
The virtual machines are set up to get 90% of the load-balanced traffic and this exception is only occurring a small percentage of the time. Could this possibly be the cause of my issue? Or would this issue cause the virtual nodes to not work at all?
@John R. Change it and see what happens.