目次

- 概要

- 前提条件

- 要件

- 使用するコンポーネント

- 表記法

- IP マルチキャスト動作の概要

- トラブルシューティングのポイント

- 障害事例とそのトラブルシューティング方法

- 障害内容

- トラブルシューティングステップ

- 考えられる原因と解決方法

- 障害時に必要な切り分け内容とログ取得項目

- 関連資料

概要

このドキュメントでは IP マルチキャストに関する一般的な問題とその解決策について解説します。

前提条件

要件

このドキュメントは、次の項目に関する知識があることが推奨されます。

- IP マルチキャストに関する基礎知識

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメント内で使用されているデバイスは、すべてクリアな（デフォルト）設定で作業が開始されています。対象のネットワークが実稼働中である場合には、すべてのコマンドによる潜在的な影響について確実に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

IP マルチキャスト動作の概要

ユニキャストルーティングでは、送信元は特定の宛先ホストに対してトラフィックを送信するため、各ルータは宛先へのパスに沿って転送されます。一方、マルチキャストルーティングでは、送信元は任意のマルチキャストグループアドレス宛にトラフィックを送信します。マルチキャストトラフィックをマルチキャストグループに所属する全ホストに配信するために、ルータはディストリビューションツリーに従ってマルチキャストルーティングを行います。

ディストリビューションツリーは、マルチキャストソースとレシーバとをつなぐパスを示しており、マルチキャストグループ毎に作成されます。ルータはディストリビューションツリーからレシーバが存在するインタフェースを把握し、受信したマルチキャストトラフィックの転送を行います。レシーバが存在するインタフェースが複数あれば、ルータはマルチキャストパケットを複製し、転送を行います。

このディストリビューションツリーを作成するためのプロトコルが、マルチキャストルーティングプロトコルです。代表的なマルチキャストルーティングプロトコルとして、PIM（Protocol Independent Multicast）が挙げられます。PIM はユニキャストルーティングプロトコルの種類を問わず、ユニキャストルーティングテーブルの情報を参照し、ディストリビューションツリーを示すマルチキャストルーティングテーブル（mroute）を作成します。そのため、ユニキャストルーティングプロトコルはディストリビューションツリーを作成するための1つの要素であるといえます。また、セグメント内ホストのマルチキャストグループへの参加と離脱を管理するためのプロトコルである IGMP（Internet Group Management Protocol）も、ディストリビューションツリーを作成するための1つの要素となります。

PIM で使用されるディストリビューションツリーは次の2種類です。

Source Specific Tree（送信元ツリー）

マルチキャストソース毎に作成される個々のディストリビューションツリーのことで、マルチキャストソースがルート（根）となりレシーバまで達するパスを形成します。マルチキャストトラフィックが最短パスでレシーバに配信されることから SPT（Shortest Path Tree）とも呼ばれます。

※ 画像をクリックすると、大きく表示されます。

（S,G）という表記は、S がマルチキャストソースの IP アドレス、G がマルチキャストグループアドレスを示し、SPT を列挙します。

Shared Tree（共有ツリー）

共有ツリーでは、ネットワーク上の選択されたシェアードポイントをルートとしたレシーバまでのパスを形成します。PIM-SM ではシェアードポイントとして RP（Rendezvous Point; ランデブーポイント）を使用することから、RPT（Rendezvous Point Tree）とも呼ばれます。

共有ツリーは複数のマルチキャストソースで単一の共通ルートを用います。RP を経由するので、必ずしも最短パスでマルチキャストトラフィックが配信されるわけではありません。

※ 画像をクリックすると、大きく表示されます。

共有ツリーではマルチキャストトラフィックのすべての送信元が共通した共有ツリーを用いるため、（*,G）というワイルドカード表記でツリーを表記します。* は全送信元を意味し、G はマルチキャストグループを意味します。

2つのディストリビューションツリーは PIM の動作モードによって使い分けられます。

PIM-DM（PIM　Dense モード: 稠密モード）では送信元ツリーを作成し、PIM-SM（PIM Sparse モード: 希薄モード）では送信元ツリーと共有ツリーを組み合わせたツリーを作成します。

PIM-DM ではレシーバがネットワークに集中している環境を想定しています。マルチキャストソースからのパケット配信が開始されると、マルチキャストソースを根源とした送信元ツリーが作成され、マルチキャストトラフィックはいったんネットワーク全体に配信（Flooding）されます。その後、レシーバが存在しないルータについてはツリーから離脱（Prune）する流れになります。

一方、PIM-SM ではレシーバがネットワークにまばらにある環境を想定しており、マルチキャストトラフィックはそれを明示的に要求した特定のネットワークにのみ送信されます。レシーバが存在するルータが RP に結合（Join）することで RP を根源とした共有ツリーが作成され、マルチキャストトラフィックがレシーバに配信されます。また、共有ツリーとは別に SPT がある場合には、SPT に Join することで SPT 経由でのマルチキャストトラフィックの配信が可能となります。

送信元ツリーと共有ツリーは、各ルータでの以下のようなマルチキャストルーティング情報から成ります。これらの情報は、実際のマルチキャストトラフィックがどのように配信されているかを把握する上で、重要な基本情報です。

- IIF（Incoming Interface）

マルチキャストトラフィックの受信インタフェース。

- OIF（Outgoing Interface）

マルチキャストパケットの出力インタフェースのリスト。

各マルチキャストルータは、マルチキャスト転送の際に RPF（Reverse Path Forwarding）チェックを行います。これは、マルチキャストパケットの重複やループの発生を防ぐことが目的です。

RPF は、マルチキャストトラフィックを受信するインタフェースをユニキャストルーティングテーブルの情報を使って決定します。ルータはマルチキャストパケットを受信すると、届いたパケットの送信元アドレスについてユニキャストルーティングテーブルを参照し、パケットが送信元への Reverse Path 上にあるインタフェースから受信しているかチェックします。パケットを Reverse Path 上のインタフェース（RPF インタフェース）から受信している場合には、RPF チェックは正常に終了し、パケットの転送がされます。RPF チェックに失敗した場合には、ルータはパケットを廃棄します。

トラブルシューティングのポイント

このセクションでは、PIM-SM 使用時におけるトラブルシューティングのポイントについて解説します。

前述の通り、マルチキャストトラフィックを配信するためのディストリビューションツリーは、マルチキャストのソースやレシーバの状態や、各プロトコルの動作状況に基づいて、マルチキャストグループごとに動的に作成されます。そのため、マルチキャストトラフィックが正常に配信されない等の障害をトラブルシューティングするためには、まず、以下のような基本情報を確認する必要があります。

- ネットワークトポロジ

- 障害が発生しているマルチキャストグループアドレス

- マルチキャストソースの位置

- マルチキャストレシーバの位置

- マルチキャストトラフィック配信不可の詳細状況

（まったく配信不可 / 数時間毎に不可 / 数パケットだけランダムにロス等）

上記の情報が確認できたら、次に、ディストリビューションツリーの正常性を確認します。show ip mroute コマンドが有効です。このコマンドの出力から、障害の要因を、以下のようなコンポーネントレベルで、切り分けていきます。

- IGMP

- マルチキャストルーティングプロトコル（PIM）

- ユニキャストルーティングプロトコル

PIM-SM 使用時に、マルチキャストトラフィックがレシーバに正常に配信されない場合の具体的なトラブルシューティングステップの一例を、以下に解説します。

トラブルシューティングステップの例

ステップ 1 -

ネットワークトポロジにおけるマルチキャストソースとレシーバの位置、障害が発生しているマルチキャストグループアドレス等の情報を整理します。

ステップ 2 -

ディストリビューションツリー上の各ルータで、ツリーの正常性を確認します。ツリーの状態は、show ip mroute コマンドで確認します。

PIM-SM では、レシーバがマルチキャストグループに Join することでディストリビューションツリーが作成され、マルチキャストトラフィックの配信が行われます。そのため、mroute の確認は、マルチキャストのダウンストリーム（下流）からアップストリーム（上流）方向に行なっていくことが重要です。

以下は、mroute の出力例です。

※ 画像をクリックすると、大きく表示されます。

mroute を確認する際には、次の点に注目します。

- IIF

（*, G）エントリ: RP への最短経路のインタフェース

（S,G）エントリ: マルチキャストソースへの最短経路のインタフェース

- OIF

IGMP Membership Report または PIM Join を受信したインタフェース

- RPF nbr

アップストリーム（IIF の先）の PIM Neighbor Router

- 各エントリのタイマー（Uptime/Expire time）

- Flag の状態

Flag は、mroute の動作状況を示しており、トラブルシューティングを行なう上で、重要な箇所になります。各 Flag の意味は、以下の通りです。

※ 画像をクリックすると、大きく表示されます。

Note;

- Last-hop-router: マルチキャストグループに参加するホストと接続しているルータ

- First-hop-router: マルチキャストソースに接続しているルータ

mroute が正常か否か確認できたら、その結果に基づいて、次のステップに進みます。

- mroute が正常に作成されていない場合 → ステップ3

- mroute が正常に作成されている場合 → ステップ4

トラブルシューティングステップの例（続き）

ステップ 3 -

mroute が正常に作成されていない場合には、次の点を確認します。

- IGMP エントリ

Last-hop-route 上の show ip igmp gruop コマンドの出力からレシーバがマルチキャストグループに Join していることを確認します。

- 各ルータの PIM のステータス

PIM Neighbor ステータスや、RP エントリが正常に作成されていることを確認します。show ip pim interface, show ip pim neighbor, show ip pim rp mapping コマンド等が有効です。

- ユニキャストルーティングテーブル

show ip route コマンドの出力から、ユニキャストルーティングテーブルが正常に作成され、ルータがマルチキャストソースおよびRPへの経路を学習していることを確認します。また、show ip rpf コマンドから、RPF に関する問題が無いか確認します。

- マルチキャストパケットの TTL（Time To Live）

マルチキャストパケットがレシーバに到達する前に TTL の値がゼロとなり、ルータで廃棄されていないか確認します。この問題が発生した場合、show ip traffic コマンドの ｢bad hop count」 がカウントされます。

さらに、詳細な動作を確認するためには、デバッグコマンドが有効です。

ステップ 4 -

mroute が正常に作成されている場合には、次の点を確認します。

- IIF/OIF のカウンタ

IIF/OIF のインタフェースカウンタや mroute カウンタを確認することで、パケットの転送が停止している障害箇所を特定します。この確認には、主に show interface, show ip mroute count, show ip mroute active コマンドを使用します。

- ハードウェア mroute エントリ

マルチキャストパケットのハードウエア処理をサポートしている機種では、ルータが受信した新たなマルチキャストグループ宛への最初のパケットはソフトウェアで処理されます。ソフトウエア処理で、mroute が作成されてパケット転送が行なわれます。その際、mroute のエントリーはハードウエアにもインストールされます。後続の同一マルチキャストグループ宛へのパケットは、そのハードウエア mroute エントリに基づき転送されます。そのため、障害発生ルータ上で show ip mroute の出力が正常である場合には、ハードウェア mroute エントリを確認する必要があります。

障害事例とそのトラブルシューティング方法

このセクションでは、PIM-SM 使用時にマルチキャストトラフィックがレシーバに配信されない場合の具体的なトラブルシューティング方法について解説します。

障害内容：マルチキャストソースから配信されるマルチキャストトラフィックが、レシーバ側で受信できない

※ 画像をクリックすると、大きく表示されます。

上記トポロジでは、アドレス 192.1.1.100 を持つサーバから、マルチキャストグループ 239.2.2.1 宛てのマルチキャストトラフィックが配信されています。該当グループに対応する RP は RT3に設定されており、RP アドレスとして、10.1.1.1が設定されています。

マルチキャストレシーバが 239.2.2.1 に Join すると、マルチキャストトラフィックは、まず、RP を経由してレシーバに配信されます。その後、RP を経由しない SPT に切り替わって、マルチキャストトラフィックが配信されています。

本障害では、レシーバは該当グループに Join した後、いったんマルチキャストトラフィックを受信しますが、その数分後に受信できなくなります。

トラブルシューティングステップ

Last-hop-router から順に mroute を確認します。RT5の show ip mroute の出力を確認すると、適切な (*,G) エントリは作成されていますが、(S,G) エントリが作成されていません。

※ 画像をクリックすると、大きく表示されます。

次に、RP である RT3の mroute を確認すると、(*,G) エントリと (S,G) エントリが作成されています。(*,G) エントリの OIF には RT5との接続インタフェースが設定されています。一方、(S,G) エントリには P フラグがセットされ、OIF は Null となっています。これは、SPT へ切り替わるため、RT5 が RP である RT3 に対して、Prune を送信したことを示します。そのため、RT3の mroute には問題がありません。

※ 画像をクリックすると、大きく表示されます。

さらに、RT5の SPT のアップストリームである RT4の mroute を確認します。(S,G) エントリの OIF には RT5との接続インタフェースが正しく設定されています。これは、RT4は RT5からの (S,G) Join を正常に受信していたことを示すため、RT5は(S,G)エントリがある間は SPT への Join ができていたものと考えることができます。

また、事象発生前の RT5の mroute を確認したところ、(S,G) エントリの Expire Timer が正しく更新されておらず、11秒後に(S,G) エントリーが Expire されることを示しています。

※ 画像をクリックすると、大きく表示されます。

ルータはマルチキャストトラフィックの受信を10秒毎に定期的にチェックしており、チェック時にトラフィックを受信していた場合は (S,G) エントリの Expire Timer を更新します。そのため、マルチキャストトラフィックを継続的に受信している場合には、Expire Timer は2:50-3:30の範囲内にとどまります。

Note；

(S,G) エントリの Expire Timer は、PIM に関するイベントによりエントリが作成された場合には3:30にセットされますが、マルチキャストトラフィックの受信や IGMP によりエントリが作成された場合には3:00にセットされます。

しかしながら、上記の通り、RT5の (S,G) エントリの Expire Timer はアップデートされていません。そのため、11秒後に (S,G) エントリは削除されます。この要因として、次の2つの原因が推測できます。

- 推測1: RT4がマルチキャストトラフィックを RT5に転送していない

- 推測2: RT5がマルチキャストトラフィックを受信/転送できていない

上記を切り分けるため、まず RT4上で show ip mroute count の出力を確認します。Forwarding カウンタは、左から number of packets/packets per second, average packet size/bytes per second を示します。出力結果は、RT4は問題なくマルチキャストトラフィックを転送できていることを示します。

※ 画像をクリックすると、大きく表示されます。

合わせて、RT4が OIF からマルチキャストトラフィックを送信していることを確認します。show interface コマンドを数回実行し、「packets output」がインクリメントされることが確認できるため、RT4は問題なくマルチキャストトラフィックを転送しています。

※ 画像をクリックすると、大きく表示されます。

このことから、障害は推測1に起因していないと判断できます。

推測2の確認のため、RT5上で各カウンタの確認をします。これを行うためには、障害発生前後のカウンタを確認する必要があります。

RT5上で show ip mroute count を数回実行し Forwarding カウンタを確認すると、「number of packets」はインクリメントされておらず、「packets per second」はゼロであることから、マルチキャストトラフィックを転送できていないことが示されます。

※ 画像をクリックすると、大きく表示されます。

また、RT5が IIF からマルチキャストトラフィックを受信していることを確認します。show ip interface コマンドを数回実行し、「packets input」がインクリメントされることが確認できるため、RT5はマルチキャストトラフィックを受信していることが分かります。

※ 画像をクリックすると、大きく表示されます。

以上のトラブルシューティング結果から、本障害は、RT5において、マルチキャストトラフィックを受信しているものの、正しく転送できていないことに起因していると考えることができます。

考えられる原因と解決方法

このような障害が発生した場合には、以下の原因が考えられます。

- ハードウェア mroute エントリに関連する問題

- インタフェースモジュールに依存した問題

- ソフトウェアの不具合

これらを切り分けるコマンドは使用する機器やモジュールにより異なるため、本ドキュメントでの解説はいたしません。

障害時に必要な切り分け内容とログ取得項目

このセクションで説明するコマンドを使用すると、マルチキャストの問題のトラブルシューティングに役立つ情報を収集できます。 これらの show コマンドの詳細については、『IP マルチキャスト コマンド リファレンス ガイド』を参照してください。

show コマンド

- show ip route

- show ip rpf <source>

- show ip igmp groups

- show ip igmp interface

- show ip pim interface

- show ip pim interface detail

- show ip pim interface count

- show ip pim neighbor

- show ip pim rp mapping

- show ip mroute

- show ip mroute count

- show ip mroute active

Note;

show tech-support ipmulticast コマンドを実行することで、太字のログを纏めて採取することができます。

debug コマンド

- debug ip routing

- debug ip mrouting <group>

- debug ip mrouting rpf-events <group>

- debug ip mrouting timer

- debug ip pim <group>

- debug ip pim hello

- debug ip pim auto-rp

- debug ip pim bsr

- debug ip igmp <group>

- debug ip mpacket

注意；

ルータで大量のマルチキャストパケットが処理されている場合は、パケットレベルのデバッグの有効化には注意が必要です。

関連資料

- IP Multicast Glossary of Terms

- Multicast Quick-Start Configuration Guide

- IP Multicast Troubleshooting Guide

Updated：Jan 29, 2008

Document ID：501012008