带有Linux客户端的Windows多播北草坪会议大楼

Question

我(无论如何代表一个客户)在Linux访问Hyper上托管的多播北草坪会议大楼集群(等待更多关于哪个版本的信息，但我不认为这个版本太相关，因为这似乎是一个客户端问题)方面遇到了一些问题。

北草坪会议大楼专题组有两名成员。每个人都有自己的MAC地址(01:xx:xx)，就像在多播模式下一样。它们都响应集群的共享多播MAC地址(03:xx:xx)，这就是多播北草坪会议大楼的工作方式。

从Windows机器上单击集群IP可以正常工作，控制台将显示您希望看到的输出(发送4、接收4等)。如果你在敲击时发出声音，你就会看到水流是这样的：

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)

因此，原始流有点奇怪，但这似乎几乎是通过设计实现的；重要的是，在这个场景中，ping是有效的。

然而，网络上也有一个基于Linux的设备。这无法成功地平平北草坪会议大楼集群，当tcpdumping类似的ping会话时，它基本上在发送回显请求后结束。ARP表是正确的，并显示集群IP (03:xx:xx)的多播MAC，传出帧上有正确的MAC地址。但是，在tcpdump中没有显示答复。

Linux内核是否可能看到ICMP响应帧返回，注意到MAC地址与在传出帧上使用的MAC地址不同，然后在tcpdump (或ping，在用户空间中运行)有机会看到它之前将其删除？

Answer 1

在这种情况下，答案似乎是多播(IGMP)在Linux机器上窥探。这是在br0桥接口上启用的(这是通过抽头设备进行VPN访问所必需的)；一旦我使用sysfs禁用它，pings就开始返回。他们被复制了，和Windows客户端一样，但是他们在工作.

echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping