![为什么我的 Linux 主机会突然停止接收多播?专用网络上的所有其他网卡正在接收](https://linux22.com/image/23707/%E4%B8%BA%E4%BB%80%E4%B9%88%E6%88%91%E7%9A%84%20Linux%20%E4%B8%BB%E6%9C%BA%E4%BC%9A%E7%AA%81%E7%84%B6%E5%81%9C%E6%AD%A2%E6%8E%A5%E6%94%B6%E5%A4%9A%E6%92%AD%EF%BC%9F%E4%B8%93%E7%94%A8%E7%BD%91%E7%BB%9C%E4%B8%8A%E7%9A%84%E6%89%80%E6%9C%89%E5%85%B6%E4%BB%96%E7%BD%91%E5%8D%A1%E6%AD%A3%E5%9C%A8%E6%8E%A5%E6%94%B6.png)
这是我的困境。突然之间,从昨天开始,一个节点不再从 eth1(专用千兆位网络)接收多播数据包。所有节点之间路由良好,无冲突、丢包等情况。
ifconfig
info、inet addr、Bcast、Mask 都很好 - 它们都共享相同的 bcast 和网络掩码。此外,它们都共享: UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 on eth1 。
这些节点均由 Xen VM 提供商托管。所有客人都可以看到彼此的私人 IP 地址。没有iptables
涉及任何规则。除了一个节点之外,所有节点(20+)之间都可以看到多播数据包 - 使用tcpdump
.系统重新启动等。
只是补充一下,根据 netstat -g,受影响的节点没有像所有其他节点一样被分配多播组“eth1 1 224.2.2.4”。
什么会导致这样的事情呢?似乎一个节点不再是多播组的一部分 - 我打开了一张票,但我有一种感觉,他们被难住了。
答案1
我不知道 Linux 堆栈中 IGMP 组成员身份有任何过期策略。它可能会发生,但我对此表示怀疑,因为至少有两种方法可以告诉内核(一种是显式的,另一种是隐式的)何时应该删除程序的 IGMP 成员身份。
因此,我认为您侦听多播数据包的软件存在错误。 (愿意说出它的名字吗?)接收多播的程序不知何故要么放弃了自己的成员资格,要么忽略了在启动时添加其成员资格。重新启动多播侦听器程序时,tcpdump
应该会看到网络上发出 IGMPv2+ 组添加成员资格请求。
在小型 LAN 上进行测试时,您可能从未注意到此错误,因为廉价的网络交换机不支持 IGMP。该功能称为 IGMP 监听,仅在交换机中发现,每个端口的成本约为最便宜设备的 5 倍或更多。没有 IGMP 侦听功能的交换机(或关闭该功能的交换机)会将多播转换为广播,因此不需要 IGMP 组添加消息。
您的托管提供商显然在其网络结构上启用了 IGMP 监听,因为在故障计算机的网络堆栈上的 IGMP 组成员身份消失后,多播消息停止传入。
也可能是托管提供商的 IGMP 监听选项在交换机中配置错误,因此它们会删除组成员身份,但这并不能解释结果netstat -g
。