1

We just ran into the same problem outlined in this post:

KEMP load balancers using UCARP (VRRP) - multicast MAC address not being picked up

The only work-around that I was able to do was to disable the "User Virtual MAC Addresses" option on the Kemp. That option has the following text: "By default, the HA subsystem only switches IP addresses and uses gratuitous ARPs. Enabling this option [turning virtual mac address on] will force the MAC address to also be switched. This option is only needed if gratuitous ARPs are not allowed."

With the "virtual mac" option enabled, the VIP of one of the Kemp load balancers gets the multicast mac (like you have): 00-00-5e-00-05-01 Disabling this option, the VIP gets a unicast MAC: 00-10-f3-3e-12-32

But now HA failover takes a few mins while the ARP table expires.

I'd love to know what anyone else had done to get around this with PowerConnect 5.1.1.7 firmware and make it work like it did in 4.x firmware.

Thanks

Community
  • 1
Ed Smith
  • 86
  • 1
  • 3
  • 1
    sigh This again? 00-00-5e-00-05-01 is a unicast address. A vMAC can instantly be anywhere in the network -- i.e. the in-charge gateway can change very quickly. At layer-2, the traffic for that MAC will go to which ever port last sourced a frame with that MAC. KEMP's UCARP gets every. single. thing. wrong. – Ricky Apr 14 '16 at 20:30
  • Thanks Ricky, yes, sorry about that I should have said unicast macs on both options. The difference is that in with "virtual mac" enabled the mac address floats between the HA units. With it disabled, the MAC of the VIP is the interface of the Kemp unit itself. So I don't think this actually has to do with UCARP. Nevertheless, I'm just trying to figure out how to fix it. Any help is appreciated. – Ed Smith Apr 15 '16 at 00:12
  • Read the question that brought you here. Their implementation is broken. The multicast frames are sourced with the unicast vMAC, which causes a MAC FLAP. It's supposed to be sent with the nic/hardware/built-in-address, i.e. one unique to the device. (FWIW, the company I work for -- who shall remain nameless -- does the same stupid. Every "vrrp" group uses the same hardcoded VRID: 1. The break VRRP by putting a group id elsewhere in the protocol.) – Ricky Apr 15 '16 at 04:24
  • I'm a little confused here. I don't think these frames are multicast. The MAC address is "00-00-5e-00-05-01" and the IP is 10.8.10.78 -- neither are in the multicast MAC or IP range. – Ed Smith Apr 15 '16 at 14:23
  • Also, I did a little more digging. This issue only happens when I have a load balancer VIP setup in L4 Direct Server Return (DSR) mode. If I run at L7 NAT mode then traffic is passed. – Ed Smith Apr 15 '16 at 14:25
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Aug 09 '17 at 01:30

1 Answers1

1

I posted this on the other thread but I resolved the problem:

I was able to resolve the issue. On the Kemp (with HA pair) you have the option of using a "Virtual MAC Address". If this box isn't checked, then the MAC of a load balancer VIP is that of the physical interface of the active Kemp unit. If this box is checked, then the MAC address of the VIP is a VRRP MAC. The VRRP RFC states that the MAC will be being "00:00"{blah} with the last octet being the Router ID eg ":01". The default Kemp HA [router] ID is 01. On my PowerConnects using Firmware 5.1.x.x I'm not using VRRP but I ran some traces and determined that the PowerConnect will drop a VRRP frame if the router ID is the same as itself. They do this EVEN if VRRP isn't configured and in that mode they default to 01. So changing the Kemp HA router ID to something like 22 (0x16) resulted in everything working.

Ed Smith
  • 86
  • 1
  • 3