Over the last few days we have been looking at getting a Client Access Array going for our Exchange 2010 setup for basic redundancy and load balancing. I thought I would outline an issue we discovered with using Windows Network Load Balancing in a HP switching environment.
The first is whether to use Unicast or Multicast modes for the NLB Traffic. It is important to remember that Exchange does not care if you use Unicast or Multicast and is entirely dependent on your switching environment. At first we were confused as to which to choose due to the myriad of documentation suggesting either protocol. So we decided to give multicast a go.
After a few minutes our core switch (an 8212zl) started dropping packets for our services VLAN. We shut off the NLB and everything had returned to normal. After a bit of digging we found that ProCurve switches are not compatible with multicast mode NLB due to their inability to have static ARP tables (they can only cache). But this can be remedied somewhat by issuing the following command on some models of switches:
ProCurve(config)# ip arp-mcast-replies
The command is supported on HP ProCurve E8200zl series, E5400zl series, E3500yl series, E6600 series and E6200yl series switches support Microsoft Windows NLB in Multicast mode. Simply ensure that these switches are running K.15.03.0007 or greater firmware.
5 thoughts to “Procurve Switches and Windows Network Load Balancing in Multicast Mode causing high collision and drop rates”
we are experiencing unexplained “High collision or drop rate” events on several Procurve switches 3-4 times/day.
What does NLB traffic look like so I can isolate it with a packet capture?
Hi Fletch. If you’re running Microsoft’s NLB then use something like wireshark or ethereal you will see it as MS-NLB (Multicast or Unicast depending on how you’ve set it up). You are probably best creating a seperate VLAN for your NLB Heartbeat traffic or even go as far as creating a seperate physical network.
I know this is an old post but I’m hoping you can help out here. We are not running NLB, however, we are using KeepAliveD with VRRP which utilizes multicast. I noticed on our ProCurve 3500yl switches that we have a high number of Dropped TX. Is this a problem with all multicast devices? I know some procurves support VRRP between them.
VRRP utilises multicast to check on the status of the master router but I doubt that this would be the cause of the Dropped TX packets. AFAIK the 3500yl doesn’t support Static ARP lists but this generally only affects MS NLB.
Have you checked to see if there are any other devices multicasting on the same subnet?
This article is helpful. It saved me hours of troubleshooting.
Thanks a mil