Tag Archives: NLB

MS Network Load Balancing and Cisco

I originally wrote this in Sept. 2006 and have decided to resurrect it from an old blog for my benefit only.

Begin Repost:

Just recently worked on a last minute project to utilize MS Network Load Balancing on a few servers. I was pulled in to handle the network side of it and wanted to comment on it to possibly help others out in the future.

By default MS Network Load Balancing (NLB) works out of the box if you will even with Cisco switches / routers by using Unicast. However it is not the best or recommended way of doing things, it is the simpliest though. The main reason for the concern with using Unicast is switch flooding, all ports will get the data regardless if they want it. Kinda defeats the primary point of switches right?

So your other option is to leverage Multicast. This is an option with MS NLB, but it poses a problem with many devices not handling it correctly. See the MS multicast is not true multicast. You don’t use Class D (multicast) address space for your IP addressing for one. MS simply adds a virtual (fake) multicast MAC address to the data packets. These things hit the Cisco router on the network and well the router is smart enough to know that you cant’ or not suppose to anyway have a Class A, B or C address with a multicast MAC. So it never adds or creates an ARP entry.

So that is the best and easiest for me to describe the root of the problem in laymens terms. Now how do you make it all work?

Ok, so you want to leverage NLB using multicast with Cisco routers and/or switches. First you can just go ahead and select the multicast option with MS NLB. Now you will want to get on your core router and add an arp entry. You need two things, the virtual MAC created in NLB and the IP address of the cluster.

Create your ARP entry as follows:

arp 10.10.10.10 5555.5555.5555 ARPA – obviously use your cluster IP and MAC

Thats it really, as long as you got the right router in the network and barring no other unrelated problems you should be good to go. You can test by pinging the group IP. You can also keep a ping running and try shutting down one of the servers in the cluster, your ping should continue with no problems.

Now, before you think thats everything I should warn you that you are still in the same boat using multicast as you were with unicast in regards to switch flooding. Since the switch you have your cluster servers plugged into does not have the group multicast mac in its mac-address-table it is simply flooding all ports with the data. Not good.

If you have a Cisco switch here is one way, to me the easiest, to fix this. From within MS NLB where you choose Unicast or Mulitcast you can also select IGMP support. Go ahead and select this. Now at this point you probably just broke your network connectivity again. Why? Because it appears (at least it happend to us) that when you select the IGMP support it changes the group MAC. So you again have no ARP entry for the cluster.

Also, possibly unrelated to the lost of connectivity but you will need and want to now configure the switch for IGMP snooping. When you select the IGMP support what happens is the hosts in the cluster will now start sending out IGMP join messages. The switch takes that info “if IGMP is enabled” and uses it to put those ports into a multicast group. So now your multicast traffic for the group multicast MAC will only be sent to members of the group.

On a CATOS switch that supports IGMP it’s pretty simple commands:

set igmp enable

set igmp querier enable 200 – substitute your vlan# for 200

Couple of things to note. First this is not going to work for everyone. You may have to upgrade your IOS or CATOS to support IGMP, you may be using IOS instead of CATOS which is what the above commands are for. You do not have to enable the igmp querier, I personally found it useful as I did not configure a multicast router.

Ok, so you have multicast enabled with IGMP support. You added the ARP entry on the core router for the multicast MAC. You can ping the cluster. You enabled IGMP on the switch. Now lets see if the switch ports the servers are connected to now show up in a multicast group on the switch.

sh multicast group

Results (should look something like this):

Console> (enable) sho multicast group

VLAN Dest MAC/Route Des Destination Ports or VCs / [Protocol Type]

—- —————— ————————————————

200 01-00-5e-05-06-07 2/1,2/3-4

Well good luck, hope you find it some what helpful. Its pretty easy and the whole network load balancing stuff is pretty cool. If you need any help feel free to contact me.

Useful and related links:

Multicast Does Not Work in the Same VLAN in Catalyst Switches:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008059a9df.shtml#solu2

Configuring IGMP Snooping:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a00804356ac.html

Multicast in a Campus Network: CGMP and IGMP Snooping:
http://www.cisco.com/warp/public/473/22.html

:
http://cio.cisco.com/univercd/cc/td/doc/product/lan/cat5000/rel_4_3/config/multi.htm#xtocid237780