Monday, 10 January 2011

Microsoft NLB and HP Procurve switches?


Last week I encountered and environment where I had to setup Microsoft NLB for Exchange 2010 CAS and Hub server. The environment was a mixture of VMware 3.5 virtualization deployed in two separate system rooms and a mixture of Cisco switches in IBM blade chassis and an HP Procurve 5300 which was used as a central routing switch.

The main question was will the NLB work since the Internet search I did told that it was not possible to setup a static ARP record on HP Procurve switches which is required on Cisco switches if I we want for multicast NLB virtual IP to be available across different subnets. I could not find the answer if multicast NLB works across subnets on HP Procurve and we were additionally concerned because we used virtual machines across two separate rooms for NLB and thus switches that are physically separate but the machines were still in the same VLAN. The unicast NLB was not an option because VMware support this only if virtual machines are running on the same physical host.

So we decided just to setup the NLB on Windows hosts and see if it works. And, it worked! :)
The reason this works is probably in the fact that HP obviously accepts ARP replies for unicast IP addresses that contains multicast MAC addresses. Cisco devices in turn do not allow this (see this link).

Please leave a comment if you have more info on this subject.



  1. Procurves can learn the arp, but never learn the multicast mac. Put another host on the same vlan and I guarantee you'll see packets intended for members of the MS NLB group. The reason this works for your environment is because when the switch does not know what port a mac address is on, it floods all ports on that vlan. We were primarily an HP shop prior to this discovery and are still in the process of moving our MS NLB interfaces over to Catalyst switches and converting to NLB Multicast in the process. It also requires that the cisco switch handle the routing otherwise the HP procurve will still attempt to route and switch if the NLB interface lives on a subnet connected to the HP.

  2. HP has fixed this and now allows you to add the static arp:

  3. Anonymous...

    I never said that HP did not support static arp entries. When I said that they never learn the multicast mac perhaps I was not clear. They will never learn the ports that a multicast mac is connected to and they do not support static mac address table entries.

    Reread the contents of the link you posted. Note Antonio Milanese's comment on Dec 27, 2010 14:39:44 GMT. Note he says "...we are *still* talking about per RFC1112 (01:00:xx..)mcast addresses and not Microsoft "creative" ones (03:BF:xx..)..."

  4. I probably should have checked before I replied, but it appears that our mcast macs are RFC1112 compliant - I will see if I can configure a 5406 for another upcoming MS NLB project. Thank you for the link. Maybe we'll get lucky!

  5. This comment has been removed by a blog administrator.

  6. Hi,
    Can you please specify more what the solutions was, did you made any static arp entry in the switch?

  7. I have several NLB escenario in my infrastructure, here I give you the configuration for a HP 5830af Series Switch


    [HP]interface GigabitEthernet1/0/1
    [HP]port link-mode bridge
    [HP]port access vlan 2000
    [HP]broadcast-suppression pps 3000
    [HP]stp edged-port enable
    [HP]mac-address multicast 03bf-0a46-02c9 vlan 2000

    Do not forget to :

    [HP] undo arp check enable

    Why this: Comware based switches do not learn multicast MAC addresses. for this reason the switch does not add them to the ARP table, you cannot add static multicast MAC address entries. You have to disable the ARP entry check.

    Hope that this help you.

  8. Unless signal differences are taken into account, they can degrade signal integrity and affect total test system performance
    Bussmann Fuses