2012-03-26 18 views
0

新しい Redhat Enterprise Linux 6サーバーにマルチキャストデータを受信するアプリケーションを作成しています。サポートチームは、サーバーがマルチキャストデータフローを取得できるかどうかをテストするために使用されるアプリケーションを私に提供します。Redhat Enterprise Linux 6マルチキャストフィード

私は、テストアプリケーションを起動し、そしてまた、私は、マルチキャストデータがで来るのを見ることができます例えば、

12:58:21.645968 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 729 
12:58:21.648369 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 969 
12:58:21.649406 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 893 
12:58:21.651823 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 604 
12:58:21.654079 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 913 
12:58:21.656724 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 1320 
12:58:21.658194 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 124 
12:58:21.658226 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 217 
12:58:21.658348 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 182 
12:58:21.658625 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 1014 
12:58:21.659592 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 135 
12:58:21.659842 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 242 
12:58:21.660674 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 242 
12:58:21.660743 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 84 
12:58:21.662327 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 84 
12:58:21.669154 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 161 
12:58:21.669365 IP 10.26.12.22.50002 > 238.6.6.36.50002: UDP, length 166 
12:58:21.670792 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49 
12:58:21.670796 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49 
12:58:21.670798 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49 
12:58:21.670799 IP 10.26.12.22.60002 > 238.230.230.100.60002: UDP, length 49 

しかし、アプリケーションが任意のデータフローを拾うことができない、すなわちtcpdumpを実行中、 を持ったらあたかもマルチキャスト・データ・サブスクリプションが失敗したかのようにアプリケーションが実行されます。

サポートチームは、他のサーバーで正常に動作しているため、テストアプリケーションに問題はないことを保証します。 新しいサーバーがあるので、サーバーの一部の設定が正しくない可能性があります。

マルチキャストデータを受信するアプリケーションを停止させる可能性のあるLinux設定を調べる必要があります。たとえtcpdumpがそのデータを見ることができたとしてもです。ライブラリやパッケージがありませんか?

ありがとうございました。

答えて

3

まず、RHEL 6がカーネルレベルでマルチキャストサポートを有効にしていることを確認することをお勧めします。 (可能性はありますが、RHEL 6をチェックすることはできません) /proc/net/igmpファイルが存在することを確認してください。

また、マルチキャストアドレスの範囲が期待しているインターフェイスにルーティングされていることを確認してください。これが間違っていると、tcpdumpがパケットをスニッフィングしている間にマルチキャストだけを受信するという興味深い症状が生じることがあります。これは、NICがマルチキャストを適切にサポートしていない場合にも当てはまります。古いNICの中には、ifconfigに示されているマルチキャスト設定に関係なく、マルチキャストを受信するためにプロミスキャスモードに設定する必要があるものもあります。

もう1つのことは、テストアプリケーションの実行中に/ proc/net/igmpファイルの内容を確認することです。 /proc/net/igmpファイルには、サーバがアクティブに受信しているすべてのマルチキャストグループアドレスのリストが含まれます。テストアプリケーションが受信しようとしているマルチキャストグループアドレス(あなたのケースでは238.6.6.36と238.230.230.100)に対応するエントリが "Group"カラムにある場合、IP_ADD_MEMBERSHIP(またはIP_ADD_SOURCE_MEMBERSHIP)ソケットオプションはおそらく正しいNICで正しく呼び出されました。グループの列には、マルチキャストグループのアドレスが16進数で表示されているので、238.6.6.36は240606EEと表示されます。

テストアプリケーションを実行しているマシン上でマルチキャストルータ(Xorp、igmpproxyなど)を実行していると状況がより複雑になることがあります。 この場合、/ proc/net/ip_mr_vifおよび/ proc/net/ip_mr_cacheファイルも調べて、適切なエントリがあることを確認する必要があります。

+0

お返事ありがとうございました。私はネットワークの専門家ではないので、私はこれをサポートチームに転送します。 – 2607

+0

有用な情報ですが、同じ問題があります。/proc/net/igmpについて知りませんでしたが、netstat -gを使っていました。それでも問題は見つからなかった – easytiger

1

私はRHEL 6マシンで同様の問題がありました。私はファイアウォールを介して許可されたポートに必要なUDPポートを追加することで解決しました。 udpポート50002を追加してみてください。

+0

あなたの返信ありがとうございます。サーバー上でselinuxとiptableの両方が無効になっています。アプリケーションがマルチキャストデータを処理する前に、別のユニキャストデータソースからのスナップショットが必要であり、そのユニキャスト送信元ポートが開いていないとどうなりますか。 – 2607

2

plsでスイッチレベルをチェックしてください。私のケースでは、私はクラスタリングに悩まされていました。私のクラスターはマルチキャストでのみ動作します。しかし、私はマルチキャストでいくつかのパケットを失うことに直面していた。それは私にはあまりにも奇妙だった。しかし結局私は私の親友(Google)から解決策を得ました。私はちょうど私のスイッチレベルでIGMPを無効にして、それは正常に働いています。

関連する問題