ちらりんブログ ロゴ ちらりんブログ
STUDY · NETWORK GUIDE

3-16 マルチキャスト基礎 — IGMP・RPF・配信ツリー

1 対多で帯域を節約するマルチキャストの基礎を扱う。グループアドレスと MAC マッピング、IGMP、RPF チェック、共有ツリー (*,G) と送信元ツリー (S,G) を、CML2.9 IOS-XE 17.x の show ip mroute で実機確認する。

1. 前節までの振り返りと本節の内容

3-1 から 3-15 まで、ルーティングの基礎、RIP / OSPF / EIGRP / BGP の各プロトコル、再配送・ルーティングポリシー・FHRP による冗長化、そして IPv6 ルーティングまでを扱ってきました。これらに共通していたのは、ユニキャスト (Unicast) — 1 つの宛先へ 1 本のパケットを届ける通信です。ルータは宛先 IP アドレスを見て、1 対 1 で最適な経路を選んでいました。

本節から扱う マルチキャスト (Multicast) は、これとは根本的に異なります。マルチキャストは 1 対多 (one-to-many) の配信で、1 つの送信元が送ったパケットを、ネットワーク側がツリー状に複製して複数の受信者へ届けます。動画配信・株価配信・ルーティングプロトコルの更新通知 (OSPF の 224.0.0.5 や RIP の 224.0.0.9 も実はマルチキャスト) など、「同じデータを多数の相手へ同時に送る」場面で使われます。

マルチキャストは扱う範囲が広いため、本指南書では 3 節に分けて段階的に進めます。

  • 3-16 マルチキャスト基礎 (本節) — グループアドレス・IGMP・RPF・配信ツリーの土台
  • 3-17 PIM-SM — RP (Rendezvous Point) と共有ツリーから SPT への切替
  • 3-18 SSM / PIM-DM — RP を使わない配信方式と flood & prune

本節 3-16 では、マルチキャストを理解するうえで欠かせない 4 つの土台を扱います。マルチキャストグループアドレスとその MAC マッピング、ホストがグループ参加を伝える IGMP (Internet Group Management Protocol)、ループ防止の根幹となる RPF (Reverse Path Forwarding) チェック、そして共有ツリー (*,G) と送信元ツリー (S,G) という配信ツリーの考え方です。RP の詳しい仕組みと SPT 切替は次節 3-17 へ送ります。

2. マルチキャストとは — 1 対多で帯域を節約する

IPv4 の通信は、宛先の指定の仕方で 3 種類に分かれます。ユニキャストは 1 つの宛先を指定する 1 対 1、ブロードキャスト (Broadcast) はセグメント上の全ホストへ届ける 1 対全、そしてマルチキャストは「特定のグループに参加した受信者だけ」へ届ける 1 対多です。

マルチキャストの価値は帯域の節約にあります。たとえば 3 人の受信者へ同じ動画を配るとき、ユニキャストでは送信元が 1 本の IF から、宛先を変えた同じデータを受信者の数だけ連続して送ります。送信元のリンクには同じデータが受信者の数だけ繰り返し流れ、受信者が増えるほど負荷が比例して増えます。一方マルチキャストでは、送信元は宛先をグループアドレスにした 1 つのストリームだけを送り、経路の途中の分岐点で必要な方向にだけ複製します。受信者が 1000 人いても、送信元が出すのは 1 つのストリームです。

ユニキャスト (上) は送信元が 1 本の IF から受信者の数だけ同じデータを連続送信するため、送信元リンクに同じデータが繰り返し流れる。マルチキャスト (下) は送信元が 1 つのストリームだけ送り、分岐点でだけ複製するため送信元リンクは 1 つ分で済む。受信者数によらず送信元の負荷が一定になるのが 1 対多の帯域節約

この「送信元は 1 本」「複製は分岐点でだけ」という 2 つの性質が、マルチキャストの本質です。問題は「どこで複製するか」をネットワークがどう決めるかで、それを担うのが配信ツリーと PIM (Protocol Independent Multicast) です。本節ではまず、その土台となる IGMP・グループアドレス・RPF・配信ツリーを押さえます。

3. 本ラボのトポロジ — 送信元 1・分岐ルータ・受信者 2

検証ラボは、1 対多の配信ツリーを最小構成で観察するため、送信元 1 台・RP 兼分岐ルータ 1 台・受信者 2 台で組みます。分岐点で 1 つのパケットが 2 方向へ複製される様子を show ip mroute の OIL (Outgoing Interface List) で確認します。

R-SRC が 239.1.1.1 へ送ったパケットを、RP 兼分岐ルータ R-RP が 2 つの受信者 R-RECV1 / R-RECV2 へ複製して配る。受信者はルータ IF に ip igmp join-group 239.1.1.1 を設定して IGMP メンバになる。全リンクで OSPF area 0 (ユニキャスト到達性 = RPF の土台) と PIM sparse-mode を有効化し、静的 RP に R-RP の Lo0 (10.0.0.2) を指定する

各ルータの役割は以下のとおりです。

  • R-SRC — 送信元。ping 239.1.1.1 でマルチキャストトラフィックを生成します。
  • R-RP — RP (Lo0 = 10.0.0.2) 兼分岐ルータ。3 方向と接続し、配信ツリーの分岐点になります。show ip mroute の OIL に 2 つの受信側 IF が並ぶところが見どころです。
  • R-RECV1 / R-RECV2 — 受信者。ルータ IF に ip igmp join-group 239.1.1.1 を設定し、IGMP join を発生させます。

受信者を実機ホストで再現する場合、非特権シェルの制約によって IGMP join の観察が難しくなります (3-12 FHRP / 3-14 NDP の検証でも同じ制約が現れました)。本節は観察を確実にするため、受信者をルータの ip igmp join-group で作る方式を採ります。この選択の意味は §9 の落とし穴 1 で補足します。

マルチキャストルーティングの前提として、全ルータで ip multicast-routing をグローバルに有効化し、配信ツリーが通る全 IF で ip pim sparse-mode を有効化します。RPF が参照するユニキャスト到達性は OSPF area 0 で作ります。

4. マルチキャストグループアドレス — 224.0.0.0/4 と MAC マッピング

マルチキャストの宛先は クラス D アドレス (224.0.0.0/4、224.0.0.0 ～ 239.255.255.255) です。この範囲はいくつかの用途に区分されています。

範囲用途
224.0.0.0/24リンクローカル制御用。ルータ間でルーティング情報をやり取りするための予約。OSPF 224.0.0.5 / 224.0.0.6、RIP 224.0.0.9、EIGRP 224.0.0.10、PIM 224.0.0.13、all-routers 224.0.0.2、all-hosts 224.0.0.1
232.0.0.0/8SSM (Source-Specific Multicast) 用。送信元を指定する配信 (3-18 で扱う)
239.0.0.0/8管理スコープ (Administratively Scoped)。組織内に閉じた配信に使う。本ラボの 239.1.1.1 はここ

マルチキャスト IPv4 アドレスをイーサネットで運ぶには、マルチキャスト MAC アドレスへのマッピングが必要です。IANA が予約した OUI 01:00:5e の後ろ 23 ビットに、IPv4 アドレスの下位 23 ビットを載せます。

239.1.1.1 の場合、第 1 オクテット 239 の上位ビットは捨て、下位 23 ビット (1.1.1 相当) を 01:00:5e に続けて 01:00:5e:01:01:01 になります。

ここに罠があります。IPv4 マルチキャストアドレスは 28 ビット (224.0.0.0/4 の可変部) ありますが、MAC に載るのは下位 23 ビットだけです。上位 5 ビットが MAC へ反映されないため、32 個の異なるマルチキャストアドレスが同じ MAC に重なります (32:1 マッピング)。たとえば 224.1.1.1 と 239.1.1.1 は、上位 5 ビットが違うだけで下位 23 ビットが同じため、どちらも 01:00:5e:01:01:01 になります。

snippet 
239.1.1.1 = 11101111.0000001.00000001.00000001
                    ↑ 上位 9 ビット(うち先頭4は固定)は MAC に載らない
            01:00:5e + 0000001.00000001.00000001 = 01:00:5e:01:01:01

224.1.1.1 = 11100000.0000001.00000001.00000001
            01:00:5e + 0000001.00000001.00000001 = 01:00:5e:01:01:01  ← 同じ MAC

この重なりは、スイッチの IGMP snooping が「MAC 単位」で配信先ポートを絞る際に、意図しないグループのトラフィックが漏れる原因になりえます。設計上はグループアドレスを選ぶ際に下位 23 ビットの衝突を避ける配慮が要ります。

5. IGMP — ホストがグループ参加を伝える

マルチキャストの配信が始まるには、まず「誰がそのグループを受信したいか」をルータが知る必要があります。これを担うのが IGMP (Internet Group Management Protocol) で、ホストとルータの間でグループ参加を通知するプロトコルです。

IGMPv2 の主なメッセージは 3 種類です。Membership Report はホストが「このグループを受信したい」と申告するメッセージ、Query はルータが「まだ受信したいホストはいるか」を定期的に問い合わせるメッセージ、Leave はホストが受信をやめるときに送るメッセージです。ルータ側はセグメントごとに 1 台が IGMP querier となり、Query を出してメンバの生存を確認します。

① R-RP は IGMP querier として動くがまだメンバなし。② R-RECV1 が IGMP Membership Report (グループ 239.1.1.1) を Gi3 経由で R-RP へ送る。③ R-RP の IGMP groups テーブルに 239.1.1.1 / Gi3 が登録される。④⑤ R-RECV2 も join し、Gi4 が追加される。⑥ OIL が {Gi3, Gi4} の 2 つになり、ここが分岐点になる。送信元はまだ送っていないので (*,G) 共有ツリーだけが張られる

本ラボでは、受信者ルータの IF に ip igmp join-group 239.1.1.1 を設定することで Membership Report を発生させます。R-RP は各受信側 IF で Report を受け取り、IGMP groups テーブルにグループとインタフェースを登録します。

分岐ルータ R-RP の show ip igmp groups は次のようになります。

snippet 
R-RP# show ip igmp groups
IGMP Connected Group Membership
Group Address    Interface          Uptime    Expires   Last Reporter
239.1.1.1        GigabitEthernet4   00:06:50  00:02:58  10.0.24.4
239.1.1.1        GigabitEthernet3   00:33:00  00:02:59  10.0.23.3
224.0.1.40       Loopback0          00:33:19  00:02:48  10.0.0.2

239.1.1.1 が Gi3 と Gi4 の 2 つの IFに登録され、Last Reporter がそれぞれ R-RECV1 (10.0.23.3) と R-RECV2 (10.0.24.4) になっています。2 つの受信者がそれぞれの IF の先で join したことを R-RP が把握した状態です。なお 224.0.1.40 は Cisco ルータが自動で参加する Auto-RP discovery 用のグループで、本ラボの設定とは無関係に現れます。

detail を付けると Group mode が確認できます。

snippet 
R-RP# show ip igmp groups 239.1.1.1 detail
Interface:      GigabitEthernet4
Group:          239.1.1.1
Group mode:     EXCLUDE (Expires: 00:02:53)
Last reporter:  10.0.24.4
Source list is empty

Group mode: EXCLUDE は、IGMPv3 の「指定した送信元を除外して受信する」モードを表し、Source list が空なので「すべての送信元を受信する (= 旧来の any-source)」状態です。送信元を限定する SSM は 3-18 で扱います。

MLD (Multicast Listener Discovery) は IGMP の IPv6 版です。IPv6 ではグループアドレスが ff0x:: で表され (たとえば ff05::1:1)、参加通知も IGMP ではなく MLD が担います。MLD は ICMPv6 のメッセージとして実装され、MLDv1 が IGMPv2、MLDv2 が IGMPv3 に対応します。役割と仕組みは IGMP とほぼ同じで、本節の実機検証は IPv4 (IGMP) に絞ります。

6. RPF チェック — マルチキャストのループ防止

ユニキャストは宛先アドレスを見て転送先を決めますが、マルチキャストは「送信元から受信者へ向かう逆向き」で経路を考えます。ここで欠かせないのが RPF (Reverse Path Forwarding) チェックで、マルチキャストにおけるループ防止の根幹です。

RPF チェックの考え方はシンプルです。ルータはマルチキャストパケットを受け取ると、「このパケットが届いた IF は、パケットの送信元へ向かうユニキャスト最短経路の出口 IF と一致するか」を確認します。一致すれば正しい経路から来たとみなして転送し、一致しなければ (ループして巡ってきた可能性があるため) 破棄します。

R-RP は show ip rpf 10.0.0.1 で「送信元 10.0.0.1 への RPF interface は Gi2」と知っている。① 正しい IF (Gi2) から届いたパケットは RPF 成功で受理し、配信ツリーの出力 (Gi3/Gi4) へ転送する。② 誤った IF (Gi3) から同じ送信元のパケットが届いたら RPF 失敗で破棄する (ループ防止)。RPF interface は show ip route のユニキャスト最短経路を流用して決まる

重要なのは、RPF の判定基準が背後のユニキャスト経路に完全依存する点です。マルチキャストは独自の経路表を持たず、show ip route が示すユニキャスト経路 (または専用の MRIB) を流用して入口を決めます。show ip rpf <source> の結果は、show ip route <source> のユニキャスト最短経路から導かれます。

R-RP で show ip rpf を送信元 R-SRC の Lo0 (10.0.0.1) に対して実行すると、RPF interface とその根拠が表示されます。

snippet 
R-RP# show ip rpf 10.0.0.1
RPF information for ? (10.0.0.1)
  RPF interface: GigabitEthernet2
  RPF neighbor: ? (10.0.12.1)
  RPF route/mask: 10.0.0.1/32
  RPF type: unicast (ospf 1)
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

注目すべきは RPF type: unicast (ospf 1) と RPF topology: ... originated from ipv4 unicast base の 2 行です。RPF interface が OSPF のユニキャスト経路から導かれていることを実機が明示しています。これを show ip route 10.0.0.1 と並べると、同じ出口 IF (Gi2) を参照していることが確認できます。

snippet 
R-RP# show ip route 10.0.0.1
Routing entry for 10.0.0.1/32
  Known via "ospf 1", distance 110, metric 2, type intra area
  * 10.0.12.1, from 10.0.0.1, via GigabitEthernet2

ユニキャスト経路の出口 (Gi2) と RPF interface (Gi2) が一致しています。ユニキャスト経路が変われば RPF interface も変わる — これがマルチキャストとユニキャストのつながりです。

RPF は送信元アドレス (ユニキャスト) を引数に取ります。グループアドレスを渡すと show ip rpf 239.1.1.1 → Invalid address, must be a unicast address で弾かれます。RPF が「送信元へ向かう逆経路」を見る仕組みであることが、この挙動からも分かります。

ここでは RPF の例として R-SRC の Lo0 (10.0.0.1) を使いました。一方、次節以降の show ip mroute の (S,G) エントリでは送信元が 10.0.12.1 で現れます。これは R-SRC が ping 239.1.1.1 source GigabitEthernet2 のように Gi2 を送信元 IF にして送るためで、(S,G) の「S」には実際にパケットを送出した IF のアドレス (Gi2 = 10.0.12.1) が入ります。どちらも RPF interface は同じ Gi2 です。

7. 配信ツリー — 共有ツリー (*,G) と送信元ツリー (S,G)

マルチキャストの配信経路は配信ツリー (Distribution Tree) と呼ばれ、ルータの マルチキャストルーティングテーブル (show ip mroute) に表現されます。配信ツリーには 2 種類あり、mroute のエントリ形式で区別されます。

  • 共有ツリー (*,G) / RPT (Rendezvous Point Tree) — (*, 239.1.1.1) のように送信元を * (ワイルドカード) で表すエントリ。「このグループを受信したい人がいる」という受信希望を表し、RP を根とする共有のツリーです。受信者が join すると現れます。
  • 送信元ツリー (S,G) / SPT (Shortest Path Tree) — (10.0.12.1, 239.1.1.1) のように送信元 IP を明示するエントリ。「この送信元からの実際の配信」を表し、送信元を根とする最短経路のツリーです。送信元が実際にパケットを送ると現れます。

mroute エントリにはフラグが付き、S は Sparse モード、T は SPT (送信元ツリー) で配信中であることを示します。各エントリには Incoming interface (RPF に合格した入口) と Outgoing interface list (OIL) (複製して送り出す出口の一覧) が記録されます。

ここに本節で押さえるべき重要な性質があります。受信者が join しただけでは (*,G) 共有ツリーしか現れず、送信元が実際にパケットを送って初めて (S,G) 送信元ツリーが現れます。 mroute エントリの出現タイミングの差を実機で確認します。

§5 の IGMP join の後、ソースが送信する前の R-RP では (*, 239.1.1.1) だけが存在します。

snippet 
R-RP# show ip mroute 239.1.1.1
(*, 239.1.1.1), 00:35:21/00:03:08, RP 10.0.0.2, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet4, Forward/Sparse, 00:09:02/00:03:08
    GigabitEthernet3, Forward/Sparse, 00:34:39/00:02:33

(*, 239.1.1.1) の flags: SJC は S=Sparse、J=Join SPT、C=Connected を表します。RP は 10.0.0.2、OIL に Gi4 / Gi3 の 2 つが並び、ここが分岐点であることが分かります。Incoming interface が Null なのは、R-RP 自身が RP を兼ねているため上流方向が存在しないからです (本来は RP へ向かう IF が入ります)。送信元はまだ送っていないので、(S,G) はまだありません。

R-SRC が ping 239.1.1.1 を送ると、R-RP に (S,G) エントリが新しく現れます。

snippet 
R-RP# show ip mroute 239.1.1.1
(*, 239.1.1.1), 00:37:21/00:03:28, RP 10.0.0.2, flags: SJCF
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    GigabitEthernet4, Forward/Sparse, ...
    GigabitEthernet3, Forward/Sparse, ...

(10.0.12.1, 239.1.1.1), 00:01:36/00:01:23, flags: FT
  Incoming interface: GigabitEthernet2, RPF nbr 10.0.12.1
  Outgoing interface list:
    GigabitEthernet3, Forward/Sparse, ...
    GigabitEthernet4, Forward/Sparse, ...

送信元アドレスは ping を出した IF (R-SRC の Gi2 = 10.0.12.1) になります。新しく現れた (10.0.12.1, 239.1.1.1) の flags: FT は F=Register flag、T=SPT-bit set (送信元ツリーで配信中) を表します。Incoming interface = Gi2 で、これは §6 の RPF interface と一致します (送信元方向から正しく届いている)。(*,G) 側にも F フラグが付き、ソースの登録が始まったことが分かります。

このように、join しただけでは (*,G) のみ、ソースが送って初めて (S,G) が現れるという出現タイミングの差が、mroute エントリで実機確認できます。

8. 1 入力 → 2 出力の複製 — 配信ツリーの分岐

配信ツリーの核心は、分岐点で 1 つの入力パケットが複数の出力に複製されることです。R-RP は (S,G) の OIL に従い、R-SRC から受け取った 1 パケットを Gi3 と Gi4 の両方へ複製し、R-RECV1 / R-RECV2 の両方へ届けます。

① join 済みなので (*,G) 共有ツリーが OIL={Gi3,Gi4} で存在する。② R-SRC が Gi2 (10.0.12.1) を送信元に 239.1.1.1 へ 1 パケット送信。③ ソース送信で (10.0.12.1, 239.1.1.1) の (S,G) 送信元ツリーが Incoming=Gi2 で現れる。④ R-RP が分岐点で 1 入力を Gi3/Gi4 の 2 出力へ複製。⑤ 両受信者に同じグループが届く。⑥ (*,G)=受信希望の共有ツリー / (S,G)=実配信の送信元ツリーという役割分担

上で見た (S,G) (10.0.12.1, 239.1.1.1) の OIL には Gi3 / Gi4 の 2 つが並んでいます。show ip mroute count でパケットカウンタを見ると、複製が数字で確認できます。

snippet 
R-RP# show ip mroute 239.1.1.1 count
Group: 239.1.1.1, Source count: 1, Packets forwarded: 8, Packets received: 9
  Source: 10.0.12.1/32, Forwarding: 8/0/114/0, Other: 8/0/0

送信元 10.0.12.1 からのパケットを R-RP が受け取り、OIL の 2 IF へ複製して転送している様子が Packets forwarded として記録されます。1 つの入力が分岐点で複数の出力に複製される — これが配信ツリーの分岐の実体です。

マルチキャスト ping は「グループのメンバ全員に届き、各メンバが応答する」という挙動を持ちます。R-RECV1 / R-RECV2 が join しているため、ping 239.1.1.1 には両受信者からの応答が返ります。

snippet 
R-SRC# ping 239.1.1.1 source GigabitEthernet2 repeat 20
Sending 20, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.12.1

Reply to request 0 from 10.0.24.4, 73 ms
Reply to request 0 from 10.0.23.3, 78 ms
Reply to request 1 from 10.0.23.3, 5 ms
Reply to request 1 from 10.0.24.4, 6 ms
...

request 0 に対し 10.0.24.4 (R-RECV2) と 10.0.23.3 (R-RECV1) の両方から応答が返っています。1 回の ping が分岐点で複製され、2 つの受信者に届いて、それぞれが応答した — 1 対多の配信が成立していることの実証です。受信者がいないグループへ送れば応答は返りません (........) ので、「join しているから届く」という因果が応答の有無で確認できます。

9. 落とし穴・補足

実機検証で確認できた、教科書の記述と実機挙動のギャップや注意点を記録します。

  1. ip igmp join-group と ip igmp static-group の違い — join-group はルータ自身がグループのメンバになり、CPU がマルチキャストパケットを受信処理します。本ラボは観察を目的に join-group で受信者を作りました。一方 static-group は CPU で受信処理せず転送だけを行うため、本番でルータを純粋な転送装置として使う場合は static-group が推奨されます。観察目的と本番運用で使い分ける点に注意します。
  2. マルチキャスト ping の応答は join したメンバから返る — 受信者が join していないグループへ ping を送っても応答は返りません。「join しているから返る」という因果を、応答の有無で確認できます。
  3. (*,G) は join で、(S,G) はソーストラフィックで現れる — 受信者が join しただけでは共有ツリー (*,G) のみが作られ、送信元が実際に送って初めて送信元ツリー (S,G) が現れます。mroute エントリの出現タイミングの差を理解しておくと、トラブルシュートで「(S,G) が無い = ソースが送っていない」と切り分けられます。
  4. RPF はユニキャスト経路に完全依存する / 引数は送信元アドレス — show ip rpf の結果は RPF type: unicast (ospf 1) のように、show ip route のユニキャスト経路から導かれることを実機が明示します。また show ip rpf の引数は送信元のユニキャストアドレスで、グループアドレスを渡すと Invalid address, must be a unicast address で弾かれます。マルチキャストの到達性が崩れたら、まずユニキャスト経路と RPF interface を確認するのが定石です。
  5. MAC マッピングの 32:1 重なり — 224.1.1.1 と 239.1.1.1 のように下位 23 ビットが同じ多数のグループが同じマルチキャスト MAC 01:00:5e:01:01:01 になります。IGMP snooping を使うスイッチ環境では、この重なりが意図しないグループの漏れを生むことがあります。
  6. RP 自身が分岐点だと (*,G) の Incoming が Null になる — 本ラボは RP と分岐ルータを同一の R-RP にしたため、(*,G) の Incoming interface が Null、RPF nbr が 0.0.0.0 と表示されます。これは異常ではなく「RP 自身には上流方向が存在しない」ことを表します。RP を別ルータに分けると、ここに RP へ向かう IF が入ります。RP の配置と register の仕組みは次節 3-17 で扱います。

10. 次節

本節では、マルチキャストの土台となるグループアドレスと MAC マッピング、IGMP によるグループ参加、RPF によるループ防止、そして共有ツリー (*,G) と送信元ツリー (S,G) の配信ツリーを実機で確認しました。「送信元は 1 本、複製は分岐点でだけ」という 1 対多の帯域節約の仕組みと、それを支える mroute の読み方を押さえました。

次節 3-17 PIM-SM では、配信ツリーをどう張るかを担う PIM-SM (Protocol Independent Multicast - Sparse Mode) の中身に踏み込みます。本節で静的に指定した RP (Rendezvous Point) が果たす役割、送信元が RP へ自分を登録する register プロセス、そして共有ツリー (RPT) から送信元ツリー (SPT) へ切り替わる SPT 切替を、CML2.9 の実機検証とともに見ていきます。マルチキャスト 3 節の 2 節目です。

次節