Aerohive AP's and Microsoft Network Load Balancers (NLB)

  • 2
  • Question
  • Updated 3 years ago
  • Answered
When integrating a server cluster using a Microsoft NLB (Network Load Balancer), considerations must be taken as to how the load balancing is performed, and what is required of the network in between the client and the server cluster containing the resources.

Using MS NLB you will have 2 options for the operation of balancing- Unicast mode or Multicast mode.
Unicast- When operating in Unicast mode, NLB will assign a "bogus" spoofed MAC to each node in a server cluster. Balancing is performed by responding to a client's ARP request for the IP of the resource with the spoofed MAC of the server that the NLB chooses to push the client to.
Multicast- When operating in Multicast mode, the NLB will generate a "bogus" spoofed multicast address that is assigned to all server nodes within the cluster. When the client receives an ARP response from the NLB for the cluster, it will receive this multicast address. The communication from the client is then sent to each node in the cluster instead of one particular server. The selected server will then respond to the client request.

In order for this balancing using ARP to operate properly, one must be sure that the switching infrastructure is prepared for this operation. If all the servers in the cluster and the NLB are connected to the same switch, static ARP entries are required for both Unicast and Multicast modes.
The reason extra configuration is requires is because clients learn the MAC from the ARP header, where switches will learn the MAC from the ethernet header. This means that the MAC the upstream switches will contain is the true physical MAC of each node in the cluster, instead of the spoofed MAC provided in the ARP response packet.
In order for the upstream network to properly forward traffic, static ARP entries are needed on the switch that the cluster nodes are connected to.
-In Unicast mode, you will want to ensure there is a static entry for each port that has the spoofed Unicast MAC assigned to the port of the applicable cluster node.
-In Multicast mode, the spoofed multicast address must be statically assigned to each port in the cluster, allowing the client requests to flood this select port group.

If these steps are not taken, the requests will reach this switch where the cluster lives, and the packets will be flooded out of all ports when the MAC is not found in the CAM table of the switch.
This would cause what is known as switch flooding. As client load on the server increases, so will the amount of flooding. It is advised that the configuration steps above are performed before deploying an NLB.

Assuming the back end network has been properly configured for the operation, there is only a small change on an Aerohive AP that is required to complete this setup.
As stated above- L2 devices will learn MAC's via the ethernet header of a frame and not the data contained in the ARP response, any device that is performing ARP Proxy will end up storing ARP entries for the MAC of the NLB for each of the IP's in the server cluster.
This means that each time a client attempts to ARP for the MAC of a particular server it is trying to reach it will instead continue to see the entry for the NLB's physical MAC. The client will continue to retry communication and a symptom of a "timeout" would be experienced.

In order for a client connected to an Aerohive AP to receive the spoofed MAC contained in the ARP response from an NLB server, we will need to disable Proxy-ARP and allow the ARP responses to be forwarded down to the client, rather than cached in the AP.
When the client receives the packet, it is able to look into the data of the ARP response and locally cache the spoofed MAC- functioning as the load balancing is intended to work.

To make the change on an Aerohive AP, one must enter the network policy the AP's are assigned to and simply check a box to disable this feature.

With these changes made to your upstream network and to the Aerohive device configuration, the Microsoft NLB will be able to successfully trick the clients into contacting the different servers in the cluster.
Photo of Tim Ruda

Tim Ruda, Official Rep

  • 40 Posts
  • 56 Reply Likes
  • confident

Posted 5 years ago

  • 2
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Excellent write-up, Tim!! I am certain this will very useful to our community, thanks for posting this here!
Photo of Ruwan Indika

Ruwan Indika

  • 66 Posts
  • 22 Reply Likes
Interesting !