Microsoft NLB with 6509's

[rolandshum]

I'm running into an issue where my 6509's (sup720's and IOS v12.2(18)) aren't holding a Microsoft Network Load Balanceing virtual MAC address in it's ARP cache. I know the servers in the cluster are responding to an ARP request however the switch/router's arp table doesn't reflect it. The virtual MAC is a multicast MAC address and I'm not sure if I have to configure multicast on the layer 2 ports as well as the layer3 interface. Any help or experience would be appreciated.

[michael_davis · Accepted solution]

You will need to create a static entry on the sup720s.

arp a.b.c.d h.h.h arpa

where a.b.c.d is the NLB virtual IP address, and h.h.h is the multicast mac address.

Let me know if this helps by rating the post.

Michael

[rolandshum]

While that should work, I'll test later this morning, it's not dynamic. I'm always leery of static entries and I'm not sure if the servers in the cluster will always have the same virtual MAC address if a reboot happens. Again something I'll have to test. Thanks for the information though.

[rolandshum]

Well the static ARP does work, I've found the virtual MAC doesn't change unless the cluster's virtual IP changes.

It seems like the problem is the cluster responds to ARP requests for the virtual IP with the hard coded MAC address of the NIC (that is active) in the MAC source address field of the frame and the virtual MAC in the payload portion of the frame. The 720 doesn't seem to like it and reads the MAC in the source address field only.

[jbrunner007]

the real question is why are you using MS Software Load balancing at all ?

At a bare minimum (without a CSM blade in the cat6k) you could IOS SLB, and with a simple pool would be better than the MS multicast interface.

Joe

[rolandshum]

Office politics and all being what they are...I'm doing it from a CYA stand point LOL.

[michael_davis]

Well said, Joe!

But I also understand how it goes when management asks "Why should I care about broken RFCs - when I can get a similar result from software I've already purchased?"

Just make sure that management understands the scalability and deployment constraints as well as the potential things that can be broken.

For example:

1) You're limited to deploying cluster members on a single vlan, in a single location. There can be no geo-diversity.

2) The multicast and/or broadcast behavior in switches that NLB exploits should be constrained to dedicated switch hardware. Multicast, broadcast, and ICMP processing are done in software, and can severely impact host, firewall and router cpu utilization if traffic is at all significan.

3) Given the vagueness inherent in L2 to L3 multicast address mapping, NLB traffic _may_ step on non-NLB multicast traffic.

4) At a minimum, if you are using PIM or other multicast routing in your network for other applications, like music on hold or video, you need to ensure that PIM is not enabled on the NLB subnet. Failure to do so would likely result in a great deal of CPU impact to multicast routers from repeated join/prune processing.

5) As you said, you have to maintain static arp entries (whether in multicast or unicast mode) on all connected hosts that speak to the VIP.

6) I haven't tried this, but I can imagine problems with proxy-arp on routers and especially PIX.

Good luck and glad I could help you get through the issue,

Michael