■ IGMPv2への拡張

前回はIGMPv1だったわけだが。

いんたーねっとぐるーぷまねじめんとぷろとこる、ネットワーク間グループ管理プロトコルですね。

うむ。複数サブネットにわかれたマルチキャストグループを各サブネット単位で管理するためのプロトコル、そのバージョン1だったわけだ。

今回は、バージョン2？

そうだ。IGMPv1で見つかったいくつかのポイントを修正するために作られたのが、IGMPv2なわけだな。
変更点はいくつかあるが、特にIGMPv1の2つの問題点を修正している。

2つ？ なんか問題点ありましたっけ？

前回、最後で参加遅延の話をしたな。

参加遅延？ クエリとクエリの間に参加しちゃうと、次のクエリまで参加をクエリアに教える方法がないって奴ですか？ なのでクエリがなくてもレポートを送るって事ですよね。

そう、それだ。確かにIGMPv1でも参加遅延を解消する手段はとられている。
だが、離脱遅延への対処がない。

ありゃ〜、参加遅延のちょうど反対が起きるんですね。

そういう事だ。
何故こんなことが起きる？

え〜、え〜っと。IGMPv1では離脱を能動的に行わないから、じゃないでしょうか。

…。

あれ？ 違いました？

…あってる。奇跡ってのは起きるもんだな。

博士、奇跡ってのは起きるものじゃくて、起こすものですよ。
いや〜、僕かっこいいっ!!

…。
そして、もう1つはIGMPv1ではこういう事が起こりえる。

あ、あぅ〜。僕のカッコイイ科白スルーですか？

ありゃりゃ。こりゃまた随分…。

無駄じゃないか？、だろ？

です。
って、もともとそれは博士の科白ですよ。

まぁ、実際は、マルチキャストルーティングプロトコルの方で最適パスの選択が行われるから、これが起き得ない場合もある。
だが、仕様上起きてもおかしくはない。原因は何かね？ ネット君。

え、え〜〜〜〜。
……なんだろう？

うむ。奇跡は起こすものではないと証明されたわけだが。
クエリア同士が互いを知ろうとしないことが原因なわけだ。

そう、ですね。確かに他にクエリアがいることを知ってるならば、どちらかが役目を果たせばいいわけですから。

そういうことだ。

じゃ、これらのことがIGMPv2では対処されているんですね？

■ IGMPv2

もちろんだ。そうでなければわざわざ説明しない。
まず、パケットフォーマットからしてIGMPv1とv2は異なる。

あれ？ IGMPv1って、バージョンがなかったでしたっけ？ IGMPv2にはバージョンがない？
なんか変じゃないですか？

IGMPv1は確かに先頭4ビットはバージョン、次の4ビットがタイプだった。
だが、IGMPv2はIGMPv1とフォーマットは異なるが、下位互換だ。

じゃ、ますますおかしくないですか？ こういうのって、先頭にあるバージョンを見て判断するってのがパターンでしょ？

問題ない。IGMPv2のタイプは以下の4種類だ。

このように、タイプの値は必ず0x1から始まる。なのでIGMPv1しか理解できないホストがいても問題ない。
ともかく、下位互換用v1メンバーシップリポートを含めて4種類だ。

…メンバーシップクエリが2つにわかれるんですか？ 一般と、すぺしふぃっく？

うむ、スペシフィック[specific]、意味は「特定の」「限定の」だな。役割的には一般クエリに対して、「限定」クエリとでも訳すのがいいだろう。

は〜、限定くえり。なにが限定なんですか？

ま、それは後述するとして、IGMPv1と同様IGMPv2でも「参加」「問い合わせ」「維持」「離脱」の4つがある。
まず、「参加」と「維持」は基本的にIGMPv1と変わらない。

なんだ、そうなんですか？

うむ。違いがあるとすれば、クエリに使うMaxResp.Timeだな。
MaxResp.Time時間以内にレポートを返さなければならない、という制限がついている。

へ〜。
動作の点でIGMPv1とv2の明確な違いってないんですか？

■ IGMPv2による拡張

もちろんある。さっきのIGMPv1での問題点の解決の話だな。
まず、離脱遅延。これはリーブレポートにより、解消される。

離脱レポート？ つまり、離脱することを通知するんですね？

そうだ。参加遅延のように、離脱したいホストはすぐにリーブレポートを出して離脱を通知する。

確かに、そうすれば離脱遅延は解消されますね。

ただし、リーブレポートを受け取ったクエリアは、参加しているホストが残っているか確認しないといけない。ホストが残っているのにグループがないと判断してしまうと困るからな。

覚えておくのは、スペシフィックリポートと一般レポートの違いだ。
スペシフィックは特定のグループのみ、一般は全グループを対象とする。

んん？ なんで一般じゃいけないんです？

この離脱の確認の場合は、リーブメッセージが来たグループだけを確認したいわけだろう？
わざわざ全グループに聞く必要はないじゃないか？

一般クエリで全グループに聞くと、全グループからレポートが返ってくる…。

帯域と処理の無駄って奴だな、それは。

なるほど。

さてもう１つ、複数のクエリアが存在する場合の解決法だが。
他のクエリアからのクエリを受け取ったクエリアは、その他のクエリアのIPアドレスを確認し。

確認し？

もし、自分のIPアドレスよりも低いIPアドレスだった場合、クエリアとして動作しない。

へ〜、なんかOSPFのDRやSTPのルートブリッジの選出みたいなことするんですね。

■ CGMP

さて、マルチキャストトラフィックをやりとりするのはホストとルータだが、その間には普通はスイッチ（L2)が入るな。

それはそうでしょうね。ルータとホスト直結なんて普通やらないですし。

さて、スイッチはマルチキャストをどう処理するんだね？

え、え〜っと。マルチとブロードはフラッディングですよね？

そうだ。だが、ブロードキャストはともかく、マルチキャストは宛先が特定できないこともないんだから、制御したいとは思わないかね？

まぁ、そう言われればしたいかな。

うむ、どうするかといえば、CAMにマルチキャストのMACアドレスを載せてしまえばいいわけだ。

CAMって、MACアドレステーブルですよね。
これにマルチキャストMACアドレスが載ると、そのポートにマルチキャストが転送されるようになる…。

そういうことだな。さて、その方法だが、まずCGMPというものがある。
これはCiscoの独自規格だな。

きましたね、独自規格。
しすこぐるーぷまねじめんとぷろとこる、ですか。

これは、ルータがIGMPで得た情報をスイッチへ送るためのプロトコルだ。ルータがCGMPサーバ、スイッチがCGMPクライアントとして動作する。まず、参加はこう。

へ〜、つまりCAMに追加するよう要求を送る、って感じですね。

ま、そうだな。
なお、CAMテーブルのマルチキャストエントリはリフレッシュされない。

なんでです？

消えると困るだろう？ IGMPレポートは参加する時は全ホストが必ず出すが、それ以外はクエリに対して1台しか応答しないんだぞ？ 参加後、マルチキャストのやりとりがしばらくなかったら消えて戻らなくなってしまう。

ん〜〜〜、あ、そうか。
CAMにエントリされるにはIGMPレポートが必要だけど、参加後は出さないホストもいるかもしれないからですね。

そういうことだ。
次は、離脱時だな。ちょっとややこしい。

IGMPv2に対応して、CGMPv2なんてのがあるんですね。

そうだな、離脱動作が大きく違うからな。

で、スイッチがIGMPを使う形になるんですね。IGMPリーブを受け取ったり、IGMPスペシフィッククエリを送信したり。

そうなる。ちなみにIGMPv2に対応したこの機能をCGMP Fast-Leaveと呼ぶ。

ふぁすとりーぶ。
早く離脱できるからですね。

■ IGMPスヌーピング

もう1つ、スイッチにマルチキャストトラフィックを制御させる方法として、IGMPスヌーピングがある。

すぬーぴんぐ？

「snoop」+「ing」だな。「かぎまわる」とか「盗み見する」とかいう意味だ。

IGMPをかぎまわる？

スイッチが「IGMPを盗み見する」だ。

IGMPを盗み見てどうしようというんです？

先ほどのCGMP Fast-Leaveに近い。IGMPのレポートやリーブを見て、CAMを変更するのだ。

へ〜、随分CGMPよりスマートですね。

確かに。CGMPはいったんルータにIGMPレポートが送られて、そこからCGMPジョインによって追加、だからな。こっちは直接IGMPレポートを読み取りするから手早く感じるだろう。

ですよね。
で、参加はわかりましたけど、離脱は？

あぁ。離脱はCGMP Fast-Leaveと同じだ。

ということは、リーブメッセージを受け取ったらCAMから削除。
最後のホストの時にだけ、ルータへ通知？

そうなる。ただし、IGMPスヌーピングはIGMPを直接見る処理をスイッチで行うためスイッチの負荷が高い。
スヌーピングの処理がちゃんとできるスイッチでないとあまりするべきではない、ということになる。

結構IGMPって頻繁にやりとりしそうですしねぇ。

さて、今回でIGMPの話は終わりだ。
次回もマルチキャストの話だな。

まだあるんですか？

前回でただろう？ マルチキャストを転送するには？

「マルチキャストグループがあるかどうか」と「マルチキャストグループがあるルータへのパス」が必要…。

その「マルチキャストグループがあるルータへのパス」を説明する。

まるちきゃすとるーてぃんぐぷろとこる？

そういうことだ。ではまた次回。

了解です。
30分間ネットワーキングでした〜♪