M6220 224.0.0.x multicast drops and delays

Possible duplicate: M6220: Bug on the new firmware 3.1.5.2 (mutlicast)

I'm posting this here in case others run into similar issues. We've applied a workaround that seems to solve the issue in practice, see below.

After upgrading to v5 firmware, we saw lots of multicast drops and delays (60+ seconds for the packets to arrive at the destination) that broke our VRRP setups.

We use the keepalived daemon for VRRP to establish failover between two servers on the switch. The switch does not do any VRRP on its own, nor any routing. VRRP standard dictates to use 224.0.0.18 as the destination IP address.

Now, the VRRP backup node saw frequent VRRP outages and triggered its master state, flapping back and forth a lot. The reason turned out to be the switch itself that dropped or delayed VRRP packets.

We use the Linux Virtual Server (ipvs) connection synchronization protocol. This is also multicast, using destination address 224.0.0.81, and with a fairly high volume of packets.

Disabling IGMP snooping with "no ip igmp snooping" solved the issue.

The root cause seems to be a combination of a new v4 or v5 feature relating to handling of known/unknown multicast destinations.

The v5.1.0.1 firmware release notes contain:
Unknown unicast and multicast packets are copied to the CPU on the lowest priority QoS queue. Unknown packets are those that do not have hardware forwarding entries. Known unicast/multicast packets are hardware forwarded and are not queued to the CPU. Control plane packets (e.g. spanning tree BPDUs) are copied or forwarded to the CPU on higher priority queues. The rate limiting for unknown packets occurs on the internal CPU port and does not affect hardware based traffic routing/forwarding in any way. Typically, the switch will examine the received packets in software to check if there is a forwarding entry, create a forwarding entry (e.g., add a L2 MAC address or ARP response), and then either discard the packet or software forward the packet (only occurs during the brief transitional period when the system is actively adding a hardware forwarding entry but the hardware is not yet updated). Processing delays for higher priority packets may occur when the internal CPU queue is continually kept busy handling low priority packets.

And then from the 4.1.0.6 "Added Functionality" section, under MVR:
Network planners are reminded that multicast groups in the 224.0.0.x range are reserved for multicast control plane traffic.

So the theory is that the switch assumes all 224.0.0.x packets are control plane packets that it sends to its CPU for software processing. With the high volume of ipvs sync packets, this starves the CPU and makes it drop or delay VRRP packets. This can be fatal for VRRP setups like the ones we use, so it is a fairly odd default behaviour. Beware.