☰

Linux 커널이 링크에서 "IGMP rejoin"을 수행해야 합니까?

tag-icon • tag-icon networking linux-kernel
Linux 커널이 링크에서 "IGMP rejoin"을 수행해야 합니까?

이 질문은 이전에 발견된 답변되지 않은 질문과 거의 동일합니다.여기커널의 메일링 리스트에 있습니다(Simon Paillard에게 감사드립니다). (의역된) 요약은 다음과 같습니다.

Linux 커널을 실행하는 호스트가 IGMP 스누핑이 활성화된 스위치에 연결되면 다음 시나리오가 발생합니다.

  • 인터페이스가 멀티캐스트 그룹의 구성원입니다. 보고서를 실행(조인)합니다.
  • 링크 오류가 발생했습니다(예: 케이블 연결 끊김).
  • 스위치는 포트의 멀티캐스트 멤버십을 새로 고칩니다.
  • 링크 복구(예: 케이블 재연결)
  • 이 시점에서 커널은 새 IGMP 멤버십 요청을 보내기 전에 스위치의 쿼리를 기다립니다.
  • 이는 링크가 다시 시작되는 시간과 중첩된 계획된 일반 쿼리(RFC의 기본값: 125초) 사이에 애플리케이션이 패킷을 손실한다는 것을 의미합니다.

이는 Linux 커널이 다시 연결한 후 연결을 다시 보내는 일을 담당하지 않음을 나타내는 것 같습니다. IGMP 사양을 더 깊이 이해하고 있는 사람이라면 누구나 재연결 시 재조인을 다시 보내야 하는지 확인할 수 있습니까?

링크 실패를 확인하고 재연결 시 스위치에 대한 조인 요청을 재발행하는 것이 사용자 수준 애플리케이션의 작업입니까?

흥미롭게도 Windows 커널은 링크가 중단된 후 다시 연결될 때 조인 요청을 다시 보내는 역할을 담당하는 것으로 보입니다.

답변1

논리적으로는 그렇다고 생각합니다. Linux IPv6 코드에서 볼 수 있기 때문입니다. 게다가RFCIPv6 MLD 스누핑은 IPv4 IGMP 스누핑과 매우 유사해야 한다고 합니다.

실제로 이 addrconf 코드는 커널이 DAD 및 RS/RA를 지원하는 ipv6에 추가되었습니다. 현재 커널 버전에 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

관련 정보