|
 フラッディングするレイヤ2スイッチの問題
今回は、マルチキャストトラフィックの転送における、レイヤ2スイッチの問題について解説していきます。
先ずは、デフォルト設定のレイヤ 2 スイッチがマルチキャストフレームを、ブロードキャストフレーム同様に
スイッチの全ポートにフラッディングすることを思い出して下さい。そして、この動作こそが問題なのです。
では、全ポートにフラッディングすることが一体どのような問題であるのか下図をみて考えていきましょう。
例えば、192.168.0.4 が 224.10.200.1 のマルチキャストパケットが欲しいとIGMPでルータに通知するとします。
ルータは、192.168.0.0/24 のセグメントに
224.10.200.1 のマルチキャストパケットを欲しがっているメンバーが
いるこを認識し、宛先 224.10.200.1 のパケットを
192.168.0.0/24 のセグメントへ転送するようになります。
ここまでは問題ないのですが、ルータからスイッチにそのパケットが転送された時、スイッチはどうするでしょうか。
スイッチは、宛先MACアドレスが 01-00-5E から始まるMACアドレスのエントリがないか各ポートを調べます。
そんなMACアドレスがエントリされているポートなんてない・・・よしっ全ポートにフラッディングしよう！となります。
その結果、上図の構成でいえは、スイッチに接続している４台のうち１台だけが受信できればいいのに、３台へは
無駄なトラフィックが流れてしまいます。さらに、全てのポートにマルチキャストフレームを、毎回フラッディングする
スイッチには、とても無駄な負荷がかかります。例えば、クライアントに指定していないグループのマルチキャストを
受信しないインテリなNICが搭載されていたとしても、スイッチへの無駄な負荷は軽減されることはありません・・・
この問題を回避するために ① IGMPスヌーピング ② CGMP ③ IEEE802.1GMRP などの手法があります。
IGMPスヌーピング
では、どうすればいいのでしょうか。ホストがルータに
IGMP Joinメッセージ ( メンバーシップレポート
) を送る時に
スイッチがその中身をのぞき見(Snooping) すればいいのです。IGMPスヌーピングとは、IGMPメッセージの中身を
のぞき見することです。
スイッチは、ルータとホストとの間でやりとりする IGMP joinメッセージをスヌーピングすることで、ホストが接続して
いるポートを、そのグループに対応するマルチキャストテーブルエントリに追加します。これにより、どこのポートに
どのマルチキャストグループのホストがいるのかを認識できるので、適切にトラフィックを転送できるようになります。
また、スイッチでマルチキャストテーブルエントリを消す場合は、IGMP
leaveメッセージをスヌーピングすることで
可能になります。スイッチは IGMP leaveメッセージを受信した応答として、MACベースのグループスペシフィック
クエリを送信します。次に、同一 VLAN に接続している他のホストが、そのグループのマルチキャストトラフィックを
受信したいかどうか確認します。その結果、IGMP
join メッセージを受け取ることができなかった場合、そのホストの
テーブルエントリを削除します。さらに、どのホストからも
IGMP join メッセージを受け取れなかった場合は、その
グループエントリごと削除することになります。
IGMPスヌーピングは、Fast-leave proceccing( 高速離脱処理 ）をサポートしています。この機能が有効な場合
スイッチがホストから IGMP Leaveメッセージを受信すると、そのポートにMACベースのグループスペシフィッククエリ
を送信することなく、そのポートを CAM テーブルエントリのポートリストから削除します。つまり、スイッチのポートに
ホスト1台だけが接続している場合に有効にすると効果的ですが、ハブを介して複数存在する時はNGの手法です。
注意事項として、スイッチは IGMPパケットと通常のマルチキャストパケットの違いを認識することができないので、
全てのマルチキャストパケットをのぞき見していくことになります。ハードウェアスイッチングと連携して動作可能な
IGMPスヌーピング専用のASICがない場合、低速CPUのローエンドスイッチでは
CGMP の実装が推奨されます。
※ Resource ： マルチキャストネットワーク開発ガイド IGMPsnooping & CGMP BCMSN認定テキスト マスタリングTCP/IP マルチキャスト編
|