I'm (on behalf of a client, anyway) having some troubles with Linux accessing a multicast NLB cluster hosted on Hyper-V (waiting for more information on what version, but I don't think the version is too relevant because this seems a client side issue).
There are two members in the NLB cluster. Each has their own MAC address (01:xx:xx:xx:xx:xx), as is usual in multicast mode. They both also answer to a shared multicast MAC address for the cluster (03:xx:xx:xx:xx:xx), which is how multicast NLB seems to work.
Pinging the cluster IP from a Windows machine works OK, the console displays the output you'd expect to see (sent 4, received 4, etc). If you Wireshark while pinging, you can see that the flow goes something like this:
ClientIP-ClientMAC -> ClusterIP-ClusterMAC : ICMP echo request ClusterIP-Node1MAC -> ClientIP-ClientMAC : ICMP echo response ClusterIP-Node2MAC -> ClientIP-ClientMAC : ICMP echo response (duplicate response from the second node) ClientIP-ClientMAC -> ClusterIP-ClusterMAC : ICMP destination unreachable (seems to be the client discarding the second ping response, and using the ClusterMAC because that's what's in its ARP table, even though that's not the MAC that the frame was received from)
So the raw flow is a bit odd, but that seems to be almost by design; the important thing is that a ping in this scenario does work.
However, there's a Linux-based appliance on the network as well. This is not able to successfully ping the NLB cluster, and when tcpdumping a similar ping session, it basically ends after the echo request is sent. The ARP table is correct and shows the multicast MAC of the cluster IP (03:xx:xx:xx:xx:xx), the outgoing frame has the correct MAC address on it. However, in tcpdump no reply is shown.
Is it possible that the Linux kernel is seeing the ICMP response frame come back, noted that the MAC address is a different MAC address to the one that was used on the outgoing frame, and then dropping it before tcpdump (or ping, running in userspace) has a chance to see it?