Sou (em nome de um cliente, de qualquer forma) tendo alguns problemas com o Linux acessando um cluster NLB de multicast hospedado no Hyper-V (esperando por mais informações sobre qual versão, mas não acho que a versão seja muito relevante porque isso parece uma questão do lado do cliente).
Existem dois membros no cluster NLB. Cada um tem seu próprio endereço MAC (01: xx: xx: xx: xx: xx), como é usual no modo multicast. Ambos também respondem a um endereço MAC de multicast compartilhado para o cluster (03: xx: xx: xx: xx: xx), que é como o NLB de multicast parece funcionar.
Ping do IP do cluster de uma máquina Windows funciona OK, o console exibe a saída que você esperaria ver (enviado 4, recebido 4, etc). Se você Wireshark enquanto faz ping, você pode ver que o fluxo é algo assim:
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)
Assim, o fluxo bruto é um pouco estranho, mas isso parece ser quase por design; o importante é que um ping nesse cenário funcione.
No entanto, também há um appliance baseado em Linux na rede. Isso não é capaz de executar com êxito o ping do cluster NLB e, quando tcpdumping uma sessão de ping semelhante, basicamente termina depois que a solicitação de eco é enviada. A tabela ARP está correta e mostra o MAC de multicast do IP do cluster (03: xx: xx: xx: xx: xx), o quadro de saída tem o endereço MAC correto. No entanto, no tcpdump, nenhuma resposta é mostrada.
É possível que o kernel do Linux esteja vendo o quadro de resposta do ICMP voltar, notou que o endereço MAC é um endereço MAC diferente daquele que foi usado no quadro de saída e depois o descarta antes do tcpdump (ou ping, rodando no userspace) tem a chance de ver isso?
A resposta, neste caso, parecia ser a espionagem de multicast (IGMP) na caixa do Linux. Isso foi ativado na interface da ponte br0 (que é necessária para o acesso VPN por meio de um dispositivo de toque); assim que eu usei o sysfs para desativá-lo, pings começaram a voltar. Eles foram duplicados, mesmo que o cliente Windows, mas eles estão trabalhando ...
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping