How to Configure an NLB in Hyper-V (Part 2)

OK, so you’ve got all the prerequisites out of the way now right? If not, go back and peruse the first part of this series and come back (I’ll wait here for you): How to Configure an NLB in Hyper-V (Part 1).

Welcome back, now let’s jump right in and get busy with configuring this NLB stuff.

Get the VMs talking the same language, TCP/IP-wise anyway.

Remember those TCP/IP settings that you planned for earlier according to the first part of this post? Time to call their numbers and get them in the game. In Hyper-V manager, crank up the virtual machines that will be a part of the NLB cluster and configure the necessary TCP/IP settings.

  1. Go to the Network and Sharing Center, Manage network connections. To make things easier, you can rename that connection that has appeared when you added the 2nd NIC we talked about in the first part of this series to NLB NIC or something you’ll remember.
  2. Right-click and select Properties on the connection. On the General Tab, enter the appropriate NLB TCP/IP settings for each VM in the Internet Protocol Version 4 (TCP/IPv4) properties that you came up with earlier.
  3. Next, click Advanced on the General Tab and then go to the DNS Tab for the advanced TCP/IP settings. Ensure that the Register this connection’s addresses in DNS checkbox is not selected! If you do that with NLB connections, things will get weird with DNS and no one wants that.
    NLB TCP/IP Settings 

Time to make the NLB.

Remember how I said to install the NLB components on one extra server? Go to that server VM now and open up Network Load Balancing Manager from Administrative Tools.

  1. On the File Menu of NLB Manager, click Cluster and then click New.
  2. Enter the name of the first VM that will take part in the joys of NLB and select the interface you configured NLB TCP/IP settings for and click Next. Accept the defaults for the Host Parameters and then click Next again:
    New NLB Cluster 
  3. This step is where the virtual part of the NLB comes in. Enter the NLB’s virtual IP address and the DNS host name that you created in the first part of this series and click Next:
    NLB Cluster Properties
  4. Wash, rinse, and repeat for the additional VM(s) that you have configured to be part of the NLB cluster.

Now technically, as you refresh the view in NLB Manager, the NLB nodes should happily converge at this point and you’ll be in business with that being all there is to it, but I always get a message something like: “the bind operation was successful but NLB is not responding to queries. Check the system even log NLB was configured, but the host isn’t responding to queries. Check the system event log on the specified computer for error entries [double click for details…]” and this very uncomforting sight:

NLB Manager (misconfigured)

Note: I think this is one of the reasons that you’re supposed to enable MAC spoofing on the NIC in Hyper-V Manager, but even though I do that, it doesn’t seem to do anything for me for some reason. Am I doing something wrong to cause this error? Could be. Do I know how to get it working anyway? Yep. This is the point when I decided to write a bog post about how to do this.

Some manual fine tuning.

Now for some reason I always get the cluster IP address is not added to TCP/IP properties and there’s some MAC weirdness going on that stands between me and NLB happiness. Just need to manually make a few tweaks and we’re in business though.

  1. The error I get is that the NLB IP isn’t added to the TCP/IP Properties so, just go use the powers of the Add button to put in the cluster IP on the Advanced Tab of the TCP/IP properties for all the NLB cluster node VMs:
    Two IPs
  2. At this point, if you restart the VMs and then refresh NLB manager, you’ll think everything is cool. Finally, a happily converged NLB, I can move on to something else right? Wrong (at least for me in my lab):
    Converged NLB Cluster 
  3. You should always test to ensure that the NLB address is responding to requests via your favorite web browser before calling it a day—and whatever you do, don’t test it on one of the NLB host VMs as they will lie to you and tell you everyting is hunky dory when in reality it might not be! If you’re like me and my lab setup, then don’t be surprised if you get something like “the address is not valid”.  Bummer.
    Address not valid 

Again, if you’re like me and my lab setup, you’ll now go into a short period of primal scream therapy before realizing that this must be something to do with the MAC addresses not being properly configured (or spoofed as the case may be).

  1. Go to NLB Manager, Cluster Properties, the Clusters Parameters Tab and scribble down the network address for the NLB cluster. For me, that was 02-BF-C0-A8-00-09.
  2. Shut down the NLB cluster VMs, and then in Hyper-V Manager, manually configure the network adapters that you added to the VMs for the NLB cluster to use a static MAC address that matches the NLB network address:
    NLB network address 
  3. Cross your fingers and restart the NLB VMs in Hyper-V Manager.

Testing the NLB.

Great, I think I have this working now, but need to be sure before I move on to actually using the NLB to do something. First, we need to check that the NLB is responding, and then we need to verify that if fails over as expected.

  1. With NLB manager still open (on a different VM than the NLB cluster machines), check out the website via NLB name (in my case the very witty “NLB”):
    NLB Node 1 
  2. Viola! The NLB is responding! Notice there in the top left corner it says “I am Server 3”? That because we modified the default iisstart.htm files during the first part of this series. That’s also the trick to verifying that the NLB will actually fail over. Let’s try that now.
  3. In NLB manager, stop the host (right-click the host name, click Control Host, and then Stop). Hit refresh the view and when that previously responding NLB node as stopped, move on:
    NLB Node Stopped 
  4. Go back to that favorite web browser and hit refresh on the NLB address. If all goes to plan, it should be some other node responding now as evidenced by the text you put into the iisstart.htm file for that server. This shows the NLB is properly failing over. Hurray!
    NLB Node 2 

I hope that at some point this post has helped or will help you to get a network load balancing cluster setup in your Hyper-V lab and again, you might not need to do all the workarounds that I did to get it working, but in case you do, that’s how I did it.

While it does sadden me that our NLB journey has come to an end, you can now continue your IT adventures using the mystic powers of network load balancing!

Bonus: If you stick around, in my next post I’ll show you how to configure MBAM Clients to use an MBAM Administration and Monitoring Server configured in an NLB.




Written by , Posted .
  • Maurits Van de Lande

    Hi, thanks for your blog about NLB.

    I use NLB on virtualized Windows servers with KVM (not hyperV). I was having trouble with NLB until I configured the mac addres on the virtual NLB interface with the cluster mac address as you pointed out in this post.

    There are two things I would like to add.

    1) I also configured the Network adapter order like
    - First interface “Production Interface”
    - Second interface “NLB Interface”

    2) then I enabled forwarding from the “NLB” to the “Production” interface
    netsh interface ipv4 set interface “NLB Interface” forwarding=enabled

  • Anthony

    Bravo on the MAC address spoofing!!!

  • Jernej Suhadolc

    thanx for the post, I was just wandering, why would you want to have both
    interfaces in the same IP subnet? Wouldn’t it be more correct to have them in
    different subnets? Than it would probably also work without fixed MAC address?

    both interfaces are in the same address space, how does ARP table know to which
    it should send the packets?