We have a problem with WLBS. We have 2 windows 2000 servers connected to an Access layer 2950 switch. In the distribution layer we have 2 6509 with redundant MSFCs. The WLBS is configured in Multicast Mode
The problem in that when we put a static ARP entry on both MSFCs for virtual WLBS IP and WLBS MAC address, the processor utilization reaches to 80-95% of MSFC. Once we try to ping the mapped Unicast IP address, it partially times out and the switches responds poorly.
(arp ?Load Balance virtual-ip-address? ?Load Balance MAC address? arpa)
Despite the problems you have been experiencing with the processor utilization, I agree with your choice going for the multicast mode.
The principle of the WLBS is that both (all?) the physical servers must see all the packets that are destined for the cluster. The individual servers then decide between themselves which frames to process and which to leave for the other guy. It can do this in multicast mode or in unicast mode.
In unicast mode, the servers respond to an ARP from the client (or router) with a virtual unicast MAC address. The client uses that address to send frames to the cluster. So why do they not get filtered by the switches in the normal way? The anwser is that the servers do not use that MAC address as source for their frames, but use their own addresses. The switches therefore never see frames sourced from the virtual MAC address, and so flood them throughout the VLAN. If you have a big VLAN, then that can cause scalability issues.
Now for multicast mode: when the client (or router) ARPs for the service address, the servers reply with a multicast MAC address. The clients (or router) then send their frames with that address as destination. The propagation though the VLAN is therefore controlled by IGMP snooping. Incidentally, some routers - including I presume the MSFC - will not believe an ARP response that gives a multicast MAC address. In my case, I had to configure the static ARP entry - IP to multicast MAC - in the router to make it work at all.
There is one other thing to say about the mutlicast scheme: the heartbeat between the servers is sent on the same multicast MAC address,but is not an IP etype, and is therefore not limited by IGMP snooping. It will be flooded to the entire VLAN. Look out for frames with etype 0x886F.
So, why are you having problems with the multicast scheme? My guess is that you have IGMP snooping, but AFAIK the 2950 supports IGMP snooping only in software rather than on the ASIC. You could switch off the IGMP snooping - that would relieve your processor, but would flood all you WLBS traffic.
I can suggest some possible aproaches to this problem:
1. Put up with the increased processor load.
2. Change your switches to something that supports IGMP snooping in hardware, or connect the WLBS servers only to switches that support this.
3. Use the unicast scheme, put your WLBS on a dedicated VLAN, and allow it to flood.
4. Use the unicast scheme and put CAM entries in all your switches for the virtual unicast address, with egress ports towards the WLBS servers.
Let me know how you solve this one, because I have the problem too, except that my servers are connected to switches that either support IGMP snooping in hardware, or do CGMP.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...