☰

Linux 内核是否应该在链路上执行“IGMP 重新加入”？

tag-icon • tag-icon networking linux-kernel
Linux 内核是否应该在链路上执行“IGMP 重新加入”？

这个问题与发现的一个较旧的未回答问题几乎相同这里在内核的邮件列表中（感谢 Simon Paillard）。以下是（释义）摘要：

当运行Linux内核的主机连接到启用了IGMP Snooping的交换机时，我们会遇到以下场景：

  • 接口是多播组的成员。执行（加入）报告。
  • 发生链路故障（例如电缆断开）。
  • 交换机刷新该端口的多播成员资格。
  • 链路恢复（例如，电缆重新连接）。
  • 此时，内核在发送新的 IGMP 加入成员资格请求之前等待来自交换机的查询。
  • 这意味着应用程序会在链路恢复正常和嵌套计划的通用查询之间丢失数据包（RFC 中的默认值：125 秒）。

这似乎表明 Linux 内核不负责重新连接后重新发送连接。任何对 IGMP 规范有更深入了解的人都可以确认重新连接时是否应该重新发送重新加入吗？

检查链路故障并在重新连接时向交换机重新发出加入请求是用户级应用程序的工作吗？

有趣的是，当链接断开后恢复正常时，Windows 内核似乎会负责重新发送加入请求。

答案1

从逻辑上来说，我认为是这样。因为我可以在Linux IPv6代码中看到它。还有RFC说 IPv6 MLD 监听应该与 IPv4 IGMP 监听非常相似。

实际上，此 addrconf 代码是为 ipv6 添加的 - 其中内核支持 DAD 和 RS/RA。如果当前内核版本中没有 ipv4 的等效项，我不会感到惊讶。

    } else if (event == NETDEV_CHANGE) {
        if (!addrconf_link_ready(dev)) {
            /* device is still not ready. */
            rt6_sync_down_dev(dev, event);
            break;
        }

        if (!IS_ERR_OR_NULL(idev)) {
            if (idev->if_flags & IF_READY) {
                /* device is already configured -
                 * but resend MLD reports, we might
                 * have roamed and need to update
                 * multicast snooping switches
                 */
                ipv6_mc_up(idev);
                change_info = ptr;
                if (change_info->flags_changed & IFF_NOARP)
                    addrconf_dad_run(idev, true);
                rt6_sync_up(dev, RTNH_F_LINKDOWN);
                break;
            }
            idev->if_flags |= IF_READY;
        }

        pr_info("ADDRCONF(NETDEV_CHANGE): %s: link becomes ready\n",
            dev->name);

https://elixir.bootlin.com/linux/v5.1/source/net/ipv6/addrconf.c#L3546

相关内容