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）とも呼ばれます。 
※ 画像をクリックすると、大きく表示されます。 共有ツリーではマルチキャストトラフィックのすべての送信元が共通した共有ツリーを用いるため、（*,G）というワイルドカード表記でツリーを表記します。* は全送信元を意味し、G はマルチキャストグループを意味します。 2つのディストリビューションツリーは PIM の動作モードによって使い分けられます。 PIM-DM ではレシーバがネットワークに集中している環境を想定しています。マルチキャストソースからのパケット配信が開始されると、マルチキャストソースを根源とした送信元ツリーが作成され、マルチキャストトラフィックはいったんネットワーク全体に配信（Flooding）されます。その後、レシーバが存在しないルータについてはツリーから離脱（Prune）する流れになります。 一方、PIM-SM ではレシーバがネットワークにまばらにある環境を想定しており、マルチキャストトラフィックはそれを明示的に要求した特定のネットワークにのみ送信されます。レシーバが存在するルータが RP に結合（Join）することで RP を根源とした共有ツリーが作成され、マルチキャストトラフィックがレシーバに配信されます。また、共有ツリーとは別に SPT がある場合には、SPT に Join することで SPT 経由でのマルチキャストトラフィックの配信が可能となります。 送信元ツリーと共有ツリーは、各ルータでの以下のようなマルチキャストルーティング情報から成ります。これらの情報は、実際のマルチキャストトラフィックがどのように配信されているかを把握する上で、重要な基本情報です。
各マルチキャストルータは、マルチキャスト転送の際に RPF（Reverse Path Forwarding）チェックを行います。これは、マルチキャストパケットの重複やループの発生を防ぐことが目的です。 RPF は、マルチキャストトラフィックを受信するインタフェースをユニキャストルーティングテーブルの情報を使って決定します。ルータはマルチキャストパケットを受信すると、届いたパケットの送信元アドレスについてユニキャストルーティングテーブルを参照し、パケットが送信元への Reverse Path 上にあるインタフェースから受信しているかチェックします。パケットを Reverse Path 上のインタフェース（RPF インタフェース）から受信している場合には、RPF チェックは正常に終了し、パケットの転送がされます。RPF チェックに失敗した場合には、ルータはパケットを廃棄します。 トラブルシューティングのポイントこのセクションでは、PIM-SM 使用時におけるトラブルシューティングのポイントについて解説します。 前述の通り、マルチキャストトラフィックを配信するためのディストリビューションツリーは、マルチキャストのソースやレシーバの状態や、各プロトコルの動作状況に基づいて、マルチキャストグループごとに動的に作成されます。そのため、マルチキャストトラフィックが正常に配信されない等の障害をトラブルシューティングするためには、まず、以下のような基本情報を確認する必要があります。
上記の情報が確認できたら、次に、ディストリビューションツリーの正常性を確認します。show ip mroute コマンドが有効です。このコマンドの出力から、障害の要因を、以下のようなコンポーネントレベルで、切り分けていきます。
PIM-SM 使用時に、マルチキャストトラフィックがレシーバに正常に配信されない場合の具体的なトラブルシューティングステップの一例を、以下に解説します。
以下は、mroute の出力例です。 
※ 画像をクリックすると、大きく表示されます。 mroute を確認する際には、次の点に注目します。
Flag は、mroute の動作状況を示しており、トラブルシューティングを行なう上で、重要な箇所になります。各 Flag の意味は、以下の通りです。 
※ 画像をクリックすると、大きく表示されます。 Note;
mroute が正常か否か確認できたら、その結果に基づいて、次のステップに進みます。
障害事例とそのトラブルシューティング方法このセクションでは、PIM-SM 使用時にマルチキャストトラフィックがレシーバに配信されない場合の具体的なトラブルシューティング方法について解説します。 障害内容：マルチキャストソースから配信されるマルチキャストトラフィックが、レシーバ側で受信できない
※ 画像をクリックすると、大きく表示されます。 上記トポロジでは、アドレス 192.1.1.100 を持つサーバから、マルチキャストグループ 239.2.2.1 宛てのマルチキャストトラフィックが配信されています。該当グループに対応する RP は RT3に設定されており、RP アドレスとして、10.1.1.1が設定されています。 トラブルシューティングステップ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つの原因が推測できます。
上記を切り分けるため、まず 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が IIF からマルチキャストトラフィックを受信していることを確認します。show ip interface コマンドを数回実行し、「packets input」がインクリメントされることが確認できるため、RT5はマルチキャストトラフィックを受信していることが分かります。 
※ 画像をクリックすると、大きく表示されます。 以上のトラブルシューティング結果から、本障害は、RT5において、マルチキャストトラフィックを受信しているものの、正しく転送できていないことに起因していると考えることができます。 考えられる原因と解決方法このような障害が発生した場合には、以下の原因が考えられます。
これらを切り分けるコマンドは使用する機器やモジュールにより異なるため、本ドキュメントでの解説はいたしません。 障害時に必要な切り分け内容とログ取得項目このセクションで説明するコマンドを使用すると、マルチキャストの問題のトラブルシューティングに役立つ情報を収集できます。 これらの show コマンドの詳細については、『IP マルチキャスト コマンド リファレンス ガイド』を参照してください。
Note;show tech-support ipmulticast コマンドを実行することで、太字のログを纏めて採取することができます。
注意；ルータで大量のマルチキャストパケットが処理されている場合は、パケットレベルのデバッグの有効化には注意が必要です。
|
||||||||||||||||||
 |
||||||||||||||||||
フィードバック