【マルチキャスト】IGMPv2の動作をわかりやすく解説

ある受信機が 239.1.1.1 のマルチキャストを受信したいとき、受信機は自分に一番近いルータ（ラストホップルータ：LHR）に「239.1.1.1 を配信してください」と依頼します。このときに使うプロトコルが IGMP（Internet Group Management Protocol）です。この記事では、よく使われる IGMPv2 の動作を、Cisco ルータの検証とパケットキャプチャで確認します。

マルチキャストルーティングの全体像は、先に次の記事を読んでおくと理解しやすくなります。

>> 参考：【初心者わかりやすく】マルチキャストルーティングの第1歩

IGMP とは

IGMP は、同じセグメントにいる受信機（ホスト）とルータの間で、「どのマルチキャストグループを受信したいか」をやりとりするプロトコルです。ルータは IGMP で、自分のインターフェースの先にどのグループの受信機がいるかを把握し、そのグループのマルチキャストだけをセグメントに流します。

IGMP には、バージョン1〜3があります。

この記事では、よく使われる IGMPv2 を扱います。IGMPv2 のメッセージは次の3種類です。

検証構成

LHR の FastEthernet0/0.123（192.168.123.1）と、2台の受信機 Receiver-1（192.168.123.2）、Receiver-2（192.168.123.3）が、同じセグメント 192.168.123.0/24 につながっています。受信機には Cisco ルータを使います。

IGMPv2 の動作を確認する

LHR で IGMP を有効にする

LHR で IGMP を受け付けるには、マルチキャストルーティングを有効にし、受信機がつながるインターフェースで PIM を有効にします。Cisco ルータでは、インターフェースで PIM を有効にすると、そのインターフェースで IGMP（既定はバージョン2）も有効になります。

LHR

LHR(config)# ip multicast-routing
LHR(config)# interface FastEthernet0/0.123
LHR(config-subif)# ip pim sparse-mode

IGMP が有効になっているかを確認します。

LHR

LHR# show ip igmp interface  
FastEthernet0/0.123 is up, line protocol is up
  Internet address is 192.168.123.1/24
  IGMP is enabled on interface
  Current IGMP host version is 2
  Current IGMP router version is 2
  IGMP query interval is 60 seconds
  IGMP configured query interval is 60 seconds
  IGMP querier timeout is 120 seconds
  IGMP configured querier timeout is 120 seconds
  IGMP max query response time is 10 seconds
  Last member query count is 2
  Last member query response interval is 1000 ms
  Inbound IGMP access group is not set
  IGMP activity: 3 joins, 2 leaves
  Multicast routing is enabled on interface
  Multicast TTL threshold is 0
  Multicast designated router (DR) is 192.168.123.1 (this system)
  IGMP querying router is 192.168.123.1 (this system)
  Multicast groups joined by this system (number of users):
      224.0.1.40(1)

ここで、LHR のパケットをキャプチャしてみます。LHR から IGMPv2 の Membership Query が、60 秒ごとに送られていることがわかります。

▸ Ethernet II, Src: 00:00:00_00:11:11 (00:00:00:00:11:11), Dst: IPv4mcast_01 (01:00:5e:00:00:01)▸ 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1231▸ Internet Protocol Version 4, Src: 192.168.123.1, Dst: 224.0.0.1▾ Internet Group Management Protocol    [IGMP Version: 2]2    Type: Membership Query (0x11)3    Max Resp Time: 10.0 sec (0x64)    Checksum: 0xee9b [correct]    [Checksum Status: Good]4    Multicast Address: 0.0.0.0

General Query で、LHR は「マルチキャストを受信したい機器はいますか？」と定期的に問い合わせます。受信したい機器がいなければ、受信機からは何も返ってきません。

受信機から参加を要求する

IGMP は、Windows、macOS、Linux など一般的な OS でサポートされています。Cisco ルータもサポートしているので、ここでは受信機を Cisco ルータにして、239.1.1.1 の受信を要求します。

Receiver-1

Receiver-1(config)# interface fastEthernet 0/0.123
Receiver-1(config-subif)# ip igmp join-group 239.1.1.1

ip igmp join-group を設定すると、ルータ自身がそのグループのメンバー（受信機）として動き、IGMP の Report を送ります。受信機側のパケットをキャプチャすると、設定した直後に、受信機から 239.1.1.1 宛てに IGMPv2 の Membership Report が送られています。

▸ Ethernet II, Src: 00:00:00_00:22:22 (00:00:00:00:22:22), Dst: IPv4mcast_01:01:01 (01:00:5e:01:01:01)▸ 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1231▸ Internet Protocol Version 4, Src: 192.168.123.2, Dst: 239.1.1.1▾ Internet Group Management Protocol    [IGMP Version: 2]2    Type: Membership Report (0x16)    Max Resp Time: 0.0 sec (0x00)    Checksum: 0xf9fc [correct]    [Checksum Status: Good]3    Multicast Address: 239.1.1.1

Membership Report で、受信機は「239.1.1.1 を配信してください」と要求します。LHR が Report を受け取ったかを確認します。

LHR

LHR# show ip igmp groups
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   
239.1.1.1        FastEthernet0/0.123      00:16:09  00:02:25  192.168.123.2   

192.168.123.2（Receiver-1）から、グループ 239.1.1.1 の Report を受け取っていることがわかります。

このあとも、LHR は 60 秒ごとに General Query を送り、受信機はそのたびに Report を返します。

▸ Internet Protocol Version 4, Src: 192.168.123.1, Dst: 224.0.0.1▾ Internet Group Management Protocol    [IGMP Version: 2]    Type: Membership Query (0x11)1    Max Resp Time: 10.0 sec (0x64)    Checksum: 0xee9b [correct]    [Checksum Status: Good]    Multicast Address: 0.0.0.0

一覧の Time を見ると、Query を受け取ってから Report を返すまでの時間が、1回目は約 6.7 秒、2回目は約 3.3 秒と、毎回ちがいます。受信機が不安定なわけではなく、これは仕様どおりの動きです。

General Query の中身を見ると、最大応答時間（Max Resp Time）が 10 秒になっています。受信機はこの値を受け取り、0〜10 秒の範囲でランダムに決めた時間だけ待ってから Report を返します。

2台目の受信機を追加する

2台目の受信機 Receiver-2 でも、239.1.1.1 の受信を要求します。

Receiver-2

Receiver-2(config)# interface FastEthernet0/0.123
Receiver-2(config-subif)# ip igmp join-group 239.1.1.1

LHR の General Query に対して、2台とも Report を返しているかを、パケットキャプチャで確認します。

2台とも Report を返すのではなく、1回の Query に対して、Receiver-1（192.168.123.2）か Receiver-2（192.168.123.3）のどちらか1台だけが Report を返しています。どちらが返すかは、そのときどきで変わります。

受信機は、それぞれランダムな時間だけ待ってから Report を送ろうとします。Report は受信したいグループのアドレス宛てに送るので、同じグループのほかの受信機にも届きます。待っている間にほかの受信機の Report を受け取った受信機は、自分の Report の送信をやめます。こうして、いちばん早く待ち時間が切れた1台だけが Report を返します。

LHR は、そのセグメントにグループ 239.1.1.1 の受信機が1台以上いることさえわかれば、マルチキャストを流せます。この仕組みがなければ、例えば受信機が 10 台あると、Query のたびに Report も 10 パケット送られ、ネットワークの効率が悪くなります。

受信機の1台が離脱する

2台のうち Receiver-2 で、239.1.1.1 の受信が不要になったので離脱させます。Receiver-2 の設定から ip igmp join-group 239.1.1.1 を削除したときの、LHR のパケットキャプチャを確認します。

▸ Ethernet II, Src: 00:00:00_00:33:33 (00:00:00:00:33:33), Dst: IPv4mcast_02 (01:00:5e:00:00:02)▸ 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1231▸ Internet Protocol Version 4, Src: 192.168.123.3, Dst: 224.0.0.2▾ Internet Group Management Protocol    [IGMP Version: 2]2    Type: Leave Group (0x17)    Max Resp Time: 0.0 sec (0x00)    Checksum: 0xf8fc [correct]    [Checksum Status: Good]3    Multicast Address: 239.1.1.1

Receiver-2 から、239.1.1.1 の Leave Group が送られています。これを受け取った LHR は、すぐに Membership Query を送ります。ただし、これまでの General Query はグループを指定していませんでしたが、今回は 239.1.1.1 を指定して「ほかに 239.1.1.1 の受信機はいませんか？」と問い合わせています。これを Group-Specific Query といいます。

▸ Ethernet II, Src: 00:00:00_00:11:11 (00:00:00:00:11:11), Dst: IPv4mcast_01:01:01 (01:00:5e:01:01:01)▸ 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1231▸ Internet Protocol Version 4, Src: 192.168.123.1, Dst: 239.1.1.1▾ Internet Group Management Protocol    [IGMP Version: 2]    Type: Membership Query (0x11)2    Max Resp Time: 1.0 sec (0x0a)    Checksum: 0xfef2 [correct]    [Checksum Status: Good]3    Multicast Address: 239.1.1.1

ここで面白いのは、最大応答時間（Max Resp Time）が、これまでの 10 秒から 1 秒に変わっていることです。この 1 秒は、STEP 1 で確認した Last member query response interval is 1000 ms の値です。受信機がいなくなったかどうかを早く判断するために、短い時間で返事を求めています。

まだ 239.1.1.1 を受信したい Receiver-1 は、この Query を受け取ると、最大 1 秒のランダムな時間だけ待って Report を返します（一覧では、Query から約 1 秒後）。

▸ Ethernet II, Src: 00:00:00_00:22:22 (00:00:00:00:22:22), Dst: IPv4mcast_01:01:01 (01:00:5e:01:01:01)▸ 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1231▸ Internet Protocol Version 4, Src: 192.168.123.2, Dst: 239.1.1.1▾ Internet Group Management Protocol    [IGMP Version: 2]2    Type: Membership Report (0x16)    Max Resp Time: 0.0 sec (0x00)    Checksum: 0xf9fc [correct]    [Checksum Status: Good]    Multicast Address: 239.1.1.1

まだ受信機がいることがわかったので、LHR は 239.1.1.1 のマルチキャストを流し続けます。

最後の受信機が離脱する

最後に残った 239.1.1.1 の受信機が離脱する場合を確認します。まず、離脱する前の LHR のグループの学習状態を確認しておきます。

LHR

LHR# show ip igmp groups
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   
239.1.1.1        FastEthernet0/0.123      00:41:15  00:02:50  192.168.123.2 

グループ 239.1.1.1 を学習しています。Expires は、あと 2 分 50 秒です。

では、最後の受信機 Receiver-1 で、239.1.1.1 から離脱します。

Receiver-1

Receiver-1(config)# interface fastEthernet 0/0.123
Receiver-1(config-subif)# no ip igmp join-group 239.1.1.1

すると、受信機から Leave Group が送られます。

▸ Ethernet II, Src: 00:00:00_00:22:22 (00:00:00:00:22:22), Dst: IPv4mcast_02 (01:00:5e:00:00:02)▸ 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 1231▸ Internet Protocol Version 4, Src: 192.168.123.2, Dst: 224.0.0.2▾ Internet Group Management Protocol    [IGMP Version: 2]2    Type: Leave Group (0x17)    Max Resp Time: 0.0 sec (0x00)    Checksum: 0xf8fc [correct]    [Checksum Status: Good]    Multicast Address: 239.1.1.1

LHR は、すぐに 239.1.1.1 を指定した Group-Specific Query で、ほかに受信機がいないかを問い合わせます。一覧を見ると、Group-Specific Query は約 1 秒の間隔で 2 回送られています。これは、STEP 1 で確認した Last member query count is 2（2 回）と Last member query response interval is 1000 ms（1 秒）のとおりです。2 回の Query の中身は、STEP 4 の Group-Specific Query と同じで、Max Resp Time は 1 秒です。

もちろん、受信機はもういないので、どの機器も Report を返しません。LHR のグループの学習状態を続けて確認すると、239.1.1.1 の Expires がすぐに 0 になり、一覧から消えます。

LHR

LHR# show ip igmp groups 
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   
239.1.1.1        FastEthernet0/0.123      00:00:13  00:02:46  192.168.123.2   

LHR# show ip igmp groups 
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   
239.1.1.1        FastEthernet0/0.123      00:00:25  00:00:00  192.168.123.2   

LHR# show ip igmp groups 
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   

これが、IGMPv2 の離脱（Leave）の仕組みです。IGMPv1 には Leave Group がないので、ルータは Report が来なくなって Expires が切れるまで、受信機のいなくなったセグメントにマルチキャストを流し続けます。IGMPv2 では、Leave Group と Group-Specific Query で、受信機がいなくなったことを数秒で判断できます。

まとめ

これで、IGMPv2 の動作をひととおり確認できました。

IGMP で受信機の要求を受けた LHR が、配信サーバまでの経路を作る PIM-SM の動作は 【マルチキャスト】PIM-SMをわかりやすく解説(スタティックRP) で確認しています。マルチキャストルーティングの全体像は 【初心者わかりやすく】マルチキャストルーティングの第1歩 を参照してください。