我（代表一个客户，无论如何）在Linux上访问在Hyper-V上托pipe的多播NLB集群时遇到一些麻烦（等待更多关于哪个版本的信息，但是我不认为这个版本太相关，因为这似乎客户端问题）。
NLB集群中有两个成员。 每个模块都有自己的MAC地址（01：xx：xx：xx：xx：xx），正如组播模式中常见的那样。 它们同时也响应集群（03：xx：xx：xx：xx：xx）的共享组播MAC地址，这是多播NLB似乎如何工作的。
从Windows机器Ping群集IP工作正常，控制台显示您期望看到的输出（发送4，收到4等）。 如果你ping Wireshark，你可以看到stream程如下所示：
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) 所以原始的stream程有点奇怪，但似乎几乎是在devise上; 重要的是，在这种情况下，ping工作。
但是，networking上也有一个基于Linux的设备。 这不能成功地ping通NLB群集，并且在tcpdump类似的ping会话时，基本上在发送回显请求之后结束。 ARP表正确，并显示集群IP（03：xx：xx：xx：xx：xx）的组播MAC，出站帧具有正确的MAC地址。 但是，在tcpdump中没有显示回复。
是否有可能Linux内核看到ICMP响应帧回来，指出MAC地址是一个不同的MAC地址，在传出帧上使用，然后在tcpdump（或ping，运行在用户空间）有机会看到它？
在这种情况下，答案似乎是在Linux机器上进行组播（IGMP）监听。 这在br0网桥接口上启用（这是通过tap设备进行VPN访问所必需的）; 只要我使用sysfs来禁用它，ping就开始回来了。 他们被复制，与Windows客户端相同，但他们正在工作…
echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping