☰

带有 Linux 客户端的 Windows 多播 NLB

tag-icon • tag-icon linux linux-networking linux-kernel nlb
带有 Linux 客户端的 Windows 多播 NLB

我（无论如何代表客户）在使用 Linux 访问托管在 Hyper-V 上的多播 NLB 群集时遇到了一些问题（正在等待有关哪个版本的更多信息，但我认为版本不太相关，因为这似乎是客户端问题）。

NLB 群集中有两个成员。每个成员都有自己的 MAC 地址 (01:xx:xx:xx:xx:xx)，这在多播模式下很常见。它们都对群集的共享多播 MAC 地址 (03:xx:xx:xx:xx:xx) 做出响应，多播 NLB 似乎就是这样工作的。

从 Windows 计算机 ping 集群 IP 成功，控制台显示您期望看到的输出（发送 4、接收 4 等）。如果您在 ping 时使用 Wireshark，则可以看到流程如下：

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 的设备。这无法成功 ping NLB 群集，当使用 tcpdump 进行类似的 ping 会话时，它基本上在发送回显请求后结束。ARP 表是正确的，并显示群集 IP 的多播 MAC（03:xx:xx:xx:xx:xx），传出的帧上有正确的 MAC 地址。但是，在 tcpdump 中没有显示回复。

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

答案1

在这种情况下，答案似乎是 Linux 机器上的多播 (IGMP) 监听。此功能在 br0 桥接接口上启用（这是通过 Tap 设备进行 VPN 访问所必需的）；当我使用 sysfs 禁用它时，ping 开始恢复。它们是重复的，与 Windows 客户端相同，但它们正在工作……

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

相关内容