이것이 나의 딜레마입니다. 갑자기 어제부터 한 노드가 더 이상 eth1(개인 기가비트 네트워크)로부터 멀티캐스트 패킷을 수신하지 않습니다. 모든 노드 간의 라우팅은 충돌, 패킷 손실 등 없이 양호합니다.
ifconfiginfo, inet addr, Bcast, Mask는 모두 괜찮습니다. 모두 동일한 bcast와 넷마스크를 공유합니다. 또한 둘 다 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 on eth1 을 공유합니다.
이러한 노드는 Xen VM 공급자에 의해 호스팅됩니다. 모든 게스트는 서로의 개인 IP 주소를 볼 수 있습니다. 관련된 규칙 은 없습니다 iptables. 멀티캐스트 패킷은 tcpdump.system 재시작 등을 사용하여 하나를 제외한 모든 노드(20+) 간에 표시됩니다.
덧붙이자면 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.