여기에 내 딜레마가 있습니다. 갑자기 어제부터 한 노드의 eth1(개인 기가비트 네트워크)에서 멀티캐스트 패킷이 더 이상 수신되지 않습니다. 모든 노드 간의 라우팅이 양호하며 충돌, 패킷 손실 등이 없습니다.
ifconfiginfo, 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 멤버십을 삭제해야 할 때 커널이 이를 알릴 수 있는 방법(명시적 방법, 암시적 방법)이 적어도 두 가지 있기 때문에 의심스럽습니다.
따라서 멀티캐스트 패킷을 수신하는 소프트웨어에 버그가 있는 것 같습니다. (이름을 정하시겠습니까?) 멀티캐스트를 수신하는 프로그램이 자체 멤버십을 삭제했거나 시작 시 멤버십 추가를 무시했습니다. 멀티캐스트 수신기 프로그램을 다시 시작하면 tcpdumpIGMPv2+ 그룹 멤버십 추가 요청이 네트워크에서 나가는 것을 볼 수 있습니다.
저렴한 네트워크 스위치는 IGMP를 이해하지 못하기 때문에 소규모 LAN에서 테스트할 때 이 버그를 전혀 발견하지 못했을 것입니다. 이 기능을 IGMP 스누핑이라고 하며 스위치에서만 발견되며 포트당 가장 저렴한 장치 비용의 약 5배 이상입니다. IGMP 스누핑 기능이 없거나 기능이 꺼진 스위치는 멀티캐스트를 브로드캐스트로 전환하므로 IGMP 그룹 추가 메시지가 필요하지 않습니다.
문제가 있는 시스템의 네트워크 스택에서 IGMP 그룹 멤버십이 사라진 후 멀티캐스트 메시지 수신이 중단되었기 때문에 호스팅 제공업체는 네트워크 패브릭에서 IGMP 스누핑을 활성화한 것으로 보입니다.
호스팅 제공업체의 IGMP 스누핑 옵션이 스위치에 잘못 구성되어 그룹 멤버십이 삭제될 수도 있지만 이는 결과를 설명하지 않습니다 netstat -g.