ちらりんブログ ロゴ ちらりんブログ
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リンクローカル制御用 (Local Network Control Block)。ルータを越えて転送されない同一リンク内の制御通信に予約。ルーティング系の 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-hosts 224.0.0.1、all-routers 224.0.0.2、IGMPv3 224.0.0.22 なども含まれる
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 のマルチキャストアドレスは ff00::/8 の範囲で、FF の後ろに flags と scope が続きます (well-known なグループは ff0x:: の形、たとえば ff05::1:1。SSM 用は ff3x::/32)。参加通知も 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 の判定基準が背後の経路情報 (MRIB) に依存する点です。マルチキャストは独自の経路選択表を持たず、RPF の参照元となる MRIB を使って入口を決めます。MRIB は多くの構成でユニキャストの経路表から導かれますが、MBGP のようにマルチキャスト専用のトポロジを使う構成では、ユニキャストとは別の経路を参照することもあります (RFC 4601)。本ラボは MBGP を使わない単純構成なので、MRIB はユニキャスト OSPF 経路に一致し、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 つの入力が分岐点で複数の出力に複製される — これが配信ツリーの分岐の実体です。

「各 IF に複製した」を出力 IF ごとに数える

ただし show ip mroute count の Packets forwarded は (S,G) 単位の集約カウンタ 1 個で、OIL に Gi3 / Gi4 の 2 IF が並んでいても「各 IF にそれぞれ何パケット複製したか」は読み取れません。「全体で 29 パケット転送した」のか「各 IF に 29 ずつ (= 物理的には 58 フレーム) 出した」のかが、この集約数字だけでは区別できないのです。複製が IF 単位で起きていることを直接見るには、出力 IF ごとのカウンタが要ります。

forwarding plane を表示する show ip mfib は (S,G) の各 OIF を Pkts: 付きで並べますが、本ラボの csr1000v IOS-XE はマルチキャストをハードウェア転送するため、OIF 別の Pkts: 行は process-switch (ソフトウェア転送) 専用で、実トラフィックでは 0/0/0 のまま動きません (複製数は HW Forwarding 側に集約計上されます)。

snippet 
R-RP# show ip mfib 239.1.1.1
 (10.0.12.1,239.1.1.1) Flags: HW
   SW Forwarding: 0/0/0/0, Other: 0/0/0
   HW Forwarding:   25/0/114/0, Other: 0/0/0
   GigabitEthernet2 Flags: A
   GigabitEthernet3 Flags: F NS
     Pkts: 0/0/0    Rate: 0 pps
   GigabitEthernet4 Flags: F NS
     Pkts: 0/0/0    Rate: 0 pps

そこで、各出力 IF に out 方向の計数 ACL (permit ip any host 239.1.1.1) を当てて、複製されて IF から出ていくパケットを IF ごとに数えます。clear ip access-list counters 後に R-SRC から ping 239.1.1.1 repeat 10 を撃ち、両 IF の match 数を見ます。

snippet 
R-RP# show ip access-lists COUNT-MCAST-GI3
Extended IP access list COUNT-MCAST-GI3
    10 permit ip any host 239.1.1.1 (4 matches)
R-RP# show ip access-lists COUNT-MCAST-GI4
Extended IP access list COUNT-MCAST-GI4
    10 permit ip any host 239.1.1.1 (4 matches)
R-RP# show ip mroute 239.1.1.1 count
Group: 239.1.1.1, Source count: 1, Packets forwarded: 29, Packets received: 29
  Source: 10.0.12.1/32, Forwarding: 29/0/114/0, Other: 29/0/0

show ip mroute count の集約 Packets forwarded が 1 個の数字なのに対し、計数 ACL は Gi3 = 4 match / Gi4 = 4 match と、両出力 IF に同数が複製されたことを IF 単位で直接示します。1 入力が分岐点で 2 出力へ「同じだけ」複製されている — 集約カウンタの内訳が、出力 IF ごとに分解できました。(絶対値が ping の repeat 数とずれるのは、メンバ join 状態や process-switch の影響で取りこぼしが出るためで、ここで重要なのは Gi3 と Gi4 の match 数が一致する = 同数複製である点です。)

マルチキャスト ping はグループのメンバ全員へ配送されますが、メンバが応答を返すかどうかは実装次第です (RFC 1122 はマルチキャスト宛 ICMP Echo を破棄してもよいとしています)。本ラボの受信者はルータで ip igmp join-group によりグループのメンバになっているため、ping 239.1.1.1 には R-RECV1 / R-RECV2 の両受信者から応答が返ります。

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 は MRIB に依存する (本ラボではユニキャスト OSPF 経路) / 引数は送信元アドレス — show ip rpf の結果は RPF type: unicast (ospf 1) のように、本ラボでは show ip route のユニキャスト経路から導かれることを実機が明示します。MBGP などマルチキャスト専用トポロジを使う構成では参照元がユニキャスト経路と分かれることもありますが、本ラボはその構成ではありません。また 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 で扱います。
  7. show ip mroute count は集約・per-interface 複製は別の手段で取る — show ip mroute count の Packets forwarded は (S,G) 単位の集約値で、出力 IF ごとの内訳は出ません。forwarding plane の show ip mfib は OIF を Pkts: 付きで並べますが、ハードウェア転送する機種 (本ラボの csr1000v IOS-XE) では OIF 別 Pkts: がソフトウェア転送専用カウンタのため実トラフィックで 0 のまま動かず、複製数は HW Forwarding に集約計上されます。出力 IF ごとの複製を確実に数えたい場合は、本節のように出力 IF へ計数 ACL を当てるか、show interface <IF> | include packets output のような IF カウンタ (マルチキャスト以外も混在する点に注意) で代替します。

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 節目です。

次節