これが私のジレンマです。突然、昨日から、1 つのノードの eth1 (プライベート ギガビット ネットワーク) からマルチキャスト パケットが受信されなくなりました。すべてのノード間のルーティングは正常で、衝突やパケット損失などはありません。
ifconfiginfo、inet addr、Bcast、Mask はすべて正常です。すべて同じ bcast とネットマスクを共有しています。また、すべて次の情報を共有しています: UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 on eth1 。
これらのノードはすべて、Xen VM プロバイダーによってホストされています。すべてのゲストは、互いのプライベート IP アドレスを認識しています。iptablesルールは適用されません。1 つのノードを除くすべてのノード (20 以上) 間で、マルチキャスト パケットを確認できます ( を使用) tcpdump。システムが再起動されたなどです。
追加すると、netstat -g によると、影響を受けるノードには、他のすべてのノードと同様にマルチキャスト グループ「eth1 1 224.2.2.4」が割り当てられていません。
このようなことが起こる原因は何でしょうか? 1 つのノードがマルチキャスト グループの一部ではなくなったようです。チケットは開いていますが、困惑しているような気がします。
答え1
Linux スタック内の IGMP グループ メンバーシップの有効期限ポリシーについては、私は知りません。プログラムの IGMP メンバーシップを削除するタイミングをカーネルに通知する方法が少なくとも 2 つ (1 つは明示的、もう 1 つは暗黙的) あるため、有効期限ポリシーが存在する可能性はありますが、私はそうは思いません。
したがって、マルチキャスト パケットをリッスンするソフトウェアにバグがあると思います。(名前を付けていただけますか?) マルチキャストを受信するプログラムは、何らかの理由で自身のメンバーシップを削除したか、起動時にメンバーシップの追加を怠っています。マルチキャスト リスナー プログラムを再起動すると、tcpdumpIGMPv2+ グループ追加メンバーシップ要求がネットワーク上に送信されるはずです。
安価なネットワーク スイッチは IGMP を認識しないため、小規模な LAN でテストしているときにこのバグに気付いたことはおそらくないでしょう。この機能は IGMP スヌーピングと呼ばれ、最も安価なユニットのポートあたりのコストの約 5 倍以上のスイッチにのみ搭載されています。IGMP スヌーピング機能のないスイッチ、またはこの機能がオフになっているスイッチは、マルチキャストをブロードキャストに変換するため、IGMP グループ追加メッセージは必要ありません。
問題のあるマシンのネットワーク スタックで IGMP グループ メンバーシップがなくなった後、マルチキャスト メッセージの受信が停止したことから、ホスティング プロバイダーはネットワーク ファブリック上で IGMP スヌーピングを有効にしているようです。
ホスティング プロバイダーの IGMP スヌーピング オプションがスイッチで誤って設定されているためにグループ メンバーシップが削除されている可能性もありますが、それでは結果が説明できませんnetstat -g。