☰

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

相關內容