Cisco Prime Collaboration 9.0 ネットワーク モニタリング、レポーティング、および診断ガイド
ビデオ エンドポイントの診断
ビデオ エンドポイントの診断
発行日;2013/03/27 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 2MB) | フィードバック

目次

ビデオ エンドポイントの診断

トラブルシューティング ワークフローの開始

MSI 対応デバイスのトラブルシューティング

トラブルシューティング データの分析

トラブルシューティング

ログ

Medianet Path View

パス アセスメント

トラブルシューティング データのエクスポート

ビデオ エンドポイントの診断

この項を確認する前に、Prime Collaboration ディスカバリ ワークフローについて理解しておく必要があります。デバイス ディスカバリ プロセスの詳細については、『 Cisco Prime Collaboration 9.0 Device Management Guide 』を参照してください。

トラブルシューティング ワークフロー中、[Device Monitoring Configuration] ページの [System Status Polling Interval]、[Interface Statistics Polling Interval]、および [Flow Statistics Polling Interval] に指定された値に基づいてデバイスのポーリングが行われます。

トラブルシューティング ワークフロー中、エンドポイントおよび会議デバイスのステータスをチェックするため、それらのポーリングが 1 分間隔で行われます。

Cisco 500、1000、および 3000 シリーズ TelePresence Systems、Cisco Unified IP Phone 8900 および 9900 シリーズ、Cisco Cius の場合、Prime Collaboration の検出はエンドポイントのレイヤ 2 デバイスの検出後に終了します。つまり、Prime Collaboration はエンドポイントが接続されているスイッチおよびファースト ホップ ルータを検出します。

エンドポイント間のレイヤ 3 デバイスは、トラブルシューティング ワークフロー中に検出されます。新たに検出されたデバイスは、Prime Collaboration インベントリに追加されます。ネットワーク トポロジは CDP を使用して検出され、デバイス間のリンクは Prime Collaboration データベースに保持されます。

Cisco C および Ex シリーズ TelePresence Systems、Cisco MXP シリーズ TelePresence System、Polycom、および Cisco Jabber の場合、トラブルシューティング ワークフローでエンドポイント間のレイヤ 3 デバイスが検出されます。Prime Collaboration による検出の際、エンドポイントが接続されているレイヤ 2 デバイスは検出されません。

ネットワーク デバイスに関する詳細(CPU 使用率、メモリ使用率、インターフェイスなど)を表示できます。システムの詳細に加えて、デバイスの障害情報も表示されます。


) トラブルシューティング ワークフローは、Prime Collaboration システムのパフォーマンスに影響を与えます。監視リストにセッションまたはエンドポイントを追加するのは、必要な場合だけにしてください。


図 12-1 に、セッションのトラブルシューティング ワークフローのフロー図を示します。

図 12-1 セッションの Prime Collaboration トラブルシューティング ワークフロー

 

トラブルシューティング ワークフローの機能

次に、トラブルシューティング ワークフローの主な特徴を示します。

トラブルシューティング ワークフローは、自動的に開始することも手動で開始することもできます。

自動トラブルシューティングは、セッションを監視リストに追加すると起動されます。

自動トラブルシューティングは、エンドポイントの 1 つが監視リストに含まれている場合に起動されます。トラブルシューティング ワークフローは、エンドポイントが監視対象状態になっている場合に限り開始できます。

自動トラブルシューティングは、パケット損失、ジッター、または遅延アラームの値が定義済みのしきい値を超えると起動されます。これは、ポイントツーポイント セッションだけに適用できます。

自動トラブルシューティングは、パケット損失、ジッター、または遅延アラームがマルチポイント セッションで発生する場合は起動されません。

手動トラブルシューティングは、[Session Monitoring] ページから開始できます。

セッションおよびエンドポイントのトラブルシューティング ワークフローを開始する方法の詳細については、「トラブルシューティング ワークフローの開始」を参照してください。

ポイントツーポイント セッションの場合は、2 つのエンドポイント間でトラブルシューティングが実行されます。トラブルシューティング ワークフローを手動で開始する場合は、エンドポイント間のトラブルシューティングの方向を選択できます。

マルチポイント セッションの場合は、マルチポイント スイッチとエンドポイント間でトラブルシューティングが実行されます。トラブルシューティング方向は、エンドポイントからマルチポイント スイッチとなり、反対方向では行われません。

2 つのエンドポイント間でパケット損失、ジッター、または遅延アラームが存在するとき、自動トラブルシューティングに対して設定されている場合はトラブルシューティング ワークフローが開始されます。このアラームがクリアされると、トラブルシューティング ワークフローは停止します。

Cisco C シリーズ/Ex シリーズおよび MCU(ポイントツーポイント、マルチポイント、およびマルチサイト)の場合、

2 つのエンドポイント間ではトラブルシューティングがサポートされています。

エンドポイントと MCU との間ではトラブルシューティングはサポートされません。つまり、エンドポイントから MCU への方向、および MCU からエンドポイントへの方向でトラブルシューティングを行うことはできません。

エンドポイントと Cisco TelePresence Server との間ではトラブルシューティングがサポートされています。トラブルシューティングは、エンドポイントから Cisco TelePresence Server への方向で行われ、その逆方向では行われません。

エンドポイントと Cisco MSE との間ではトラブルシューティングがサポートされています。トラブルシューティングは、エンドポイントから Cisco MSE への方向で行われ、その逆方向では行われません。

エンドポイントと Cisco VCS との間ではトラブルシューティングがサポートされています。トラブルシューティングは、エンドポイントから Cisco VCS への方向で行われ、その逆方向では行われません。

セッションのトラブルシューティングのページで、トポロジの一部としてサードパーティ製デバイスを表示できます(セッションの診断から)。ただし、サードパーティ製デバイスのパフォーマンスとその他のトラブルシューティングの統計情報については、詳細を表示できません。

Polycom エンドポイントの場合は、最初のホップ ルータがシスコ デバイスで、[Managed] 状態のときだけトラブルシューティング データが収集されます。ルータでは、読み取りおよび書き込み CLI アクセスを付けて設定されている必要があります。

状態が [Unknown] であるエンドポイントについては、いずれの方向にもトラブルシューティングは実行できません。

トラブルシューティング ワークフローは、開始時から最長 4 時間実行されます。トラブルシューティング ワークフローがこの時間内に終了しない場合は、Prime Collaboration はワークフローを自動的に終了します。

最大 50 個の同時トラブルシューティング ワークフローが一度に存在できます。つまり、10 個の VSAA トラブルシューティング セッション、30 個のリアクティブ トラブルシューティング セッション、および 10 個の事前トラブルシューティング セッションを同時に使用できます。

この制限を超えると、トラブルシューティング ログ ファイルにエラー メッセージが表示されます。

セッションのトラブルシューティング ワークフローの機能

次に、スケジューリングされたセッションが監視リストに追加された場合のトラブルシューティング ワークフローの主な動作を示します。

自動トラブルシューティング ワークフローは、監視リストに追加されるすべてのセッションで開始されます。

マルチポイント セッションでは、トラブルシューティングは、エンドポイントがセッションに参加するとすぐに開始されます。

マルチポイント セッションでは、エンドポイントのトラブルシューティングが停止されると、トラブルシューティング ワークフローは、セッション内の他のエンドポイントについて続行されます。このエンドポイントのトラブルシューティングは手動で開始する必要があります。

マルチポイント セッションでは、問題が原因でエンドポイントが再開されると、セッションへの参加後に、このエンドポイントの新しいトラブルシューティング ワークフローが起動されます。セッション内の他のエンドポイントに影響はありません。

監視リストからセッションが削除されると、次の条件では、関連付けられたトラブルシューティング ワークフローは停止します。

そのセッションについてトリガーされたパケット損失アラーム、ジッター アラーム、および遅延アラームがない。

手動で起動されたトラブルシューティング ワークフローがない。

パケット損失、ジッター、または遅延アラームが原因でトラブルシューティング ワークフローが起動された場合は、次の条件では、パケット損失、ジッター、または遅延アラームがクリアされると、トラブルシューティング ワークフローは停止します。

セッションが監視リストに追加されていない。

手動で起動されたトラブルシューティング ワークフローがない。

トラブルシューティング ワークフローを手動で停止した、またはセッションが終了した。

手動で起動したトラブルシューティング ワークフローは、手動で停止する必要があります。他には、セッションが終了すると停止します。

セッションを再度監視リストに追加すると、新しいトラブルシューティング ワークフローが開始されます。

エンドポイントのトラブルシューティング ワークフローの機能

トラブルシューティング ワークフローは、エンドポイントが監視対象状態になっている場合に限り開始できます。次に、エンドポイントが監視リストに追加された場合のトラブルシューティング ワークフローの主な動作を示します。

エンドポイントの自動トラブルシューティングは、そのエンドポイントがセッションに参加するとすぐに開始されます。(監視リストに追加された)エンドポイントに関連付けられたセッションのトラブルシューティング ワークフローを停止できます。このセッションのトラブルシューティングは手動で開始する必要があります。

セッション中に、エンドポイントが監視リストから削除されると、そのエンドポイントのトラブルシューティングは停止します。

セッションおよび関連付けられたエンドポイントが管理リストに属している場合に、エンドポイントが監視リストから削除されると、そのセッションのトラブルシューティング ワークフローは、セッションが終了するまで続行されます。

セッションおよび関連付けられたエンドポイントが監視リストに属している場合は、セッションが監視リストから削除されると、そのエンドポイントのトラブルシューティング ワークフローは、エンドポイントがセッションから切断されるまで続行されます。つまり、セッションとエンドポイントが監視リストに属している場合は、エンドポイントにより高い優先順位が付けられます。

トラブルシューティング パス トレースが必要な場合は、すべてのネットワーク デバイスで CDP をイネーブルにする必要があります。

CDP がデバイスのいずれでもイネーブルにできない場合、メディア パスの隣接レイヤ 3 ノードが直接接続されているかどうかや、使用されている入力および出力インターフェイスを確認するために Cisco Mediatrace を使用できます。

Medianet ベースのトラブルシューティングが必要な場合は、ルータおよびスイッチに CLI ログイン クレデンシャルが必要です。また、特権 EXEC レベル(レベル 15)アクセスが必要です。

MSI 対応のエンドポイントからトラブルシューティングを開始する場合、Mediatrace は、MSI 対応エンドポイント自体から起動します(最も近い Medianet 対応ルータからではない)。

発信元と宛先のエンドポイントをトラブルシューティングするためのサポート マトリクス

次の表には、発信元エンドポイントと宛先エンドポイントの間のトラブルシューティング サポートの詳細を示してあります。

 

発信元
宛先

CTS

CTS、CTMS、C_CODEC、TPS、CIUS、MXP、Phone、Cisco Jabber

C_CODEC

CTS、CTMS、VCS、C_CODEC、TPS、CIUS、MXP、MSE Blade、Phone、Cisco Jabber

Cius

CTS、CTMS、C_CODEC、TPS、CIUS、MXP、Phone、Cisco Jabber

MXP

CTS、CTMS、VCS、C_CODEC、TPS、CIUS、MXP、Phone、Cisco Jabber

Phone

CTS、CTMS、VCS、C_CODEC、TPS、CIUS、MXP、Phone、Cisco Jabber

Cisco Jabber

CTS、CTMS、VCS、C_CODEC、TPS、CIUS、MXP、Phone、Cisco Jabber

スイッチ

スイッチ、ルータ

ルータ

スイッチ、ルータ

traceroute コマンド

traceroute または traceroute と同等のコマンドが有効になっているエンドポイントでは、トラブルシューティングのパスまたは方向が表示されます。大部分のエンドポイントでこのコマンドは有効になっていますが、Cisco Jabber や Polycom などの一部のエンドポイントではサポートされていません。

traceroute または traceroute と同等のコマンドをサポートしていないエンドポイントの場合、ファースト ホップ ルータ(FHR)が最初に判別されます。ファースト ホップ ルータから宛先エンドポイントにパストレースが実行されます。それが完了すると、ファースト ホップ ルータへの発信元エンドポイントがステッチされ、発信元エンドポイントから宛先エンドポイントまでの完全なパスがパス トポロジで示されます。ファースト ホップ ルータの情報は、デバイスの HTTP インターフェイスを使用して、Cisco Cius や IP Phone などに対して使用できます。

Cisco Jabber や Polycom など、特定のエンドポイントについては、Prime Collaboration はエンドポイント自体からファースト ホップ ルータの情報を取得できません。これらのエンドポイントの場合、Prime Collaboration は Linux 仮想マシン アプライアンスから発信元エンドポイントに traceroute コマンドを開始します。traceroute コマンドの結果が処理され、Prime Collaboration の traceroute の前のラスト ホップ ルータがそのエンドポイントのファースト ホップ ルータと見なされます。

Cisco Performance Monitor

Cisco Performance Monitor では、ネットワーク内のパケット フローをモニタすることで、アプリケーションのパフォーマンスに重大な影響が現れる前に、そのフローに影響をおよぼす可能性がある問題点を認識できます。高品質で対話型のビデオ トラフィックはネットワークの問題点の影響を非常に受けやすいため、ビデオ トラフィックに対しては特にパフォーマンス モニタリングの重要性は高くなります。他のアプリケーションに影響を与えることがほとんどない軽度の問題であっても、ビデオの品質には大きな影響をおよぼす可能性があります。

Prime Collaboration インベントリを使用すると、デバイス上で Cisco IOS Performance Monitor が設定されているかどうかを確認できます。

パフォーマンス モニタリングには SNMP アクセスが必要です(CLI アクセスは必要ではありません)。

詳細については、次を参照してください。

Cisco Medianet 機能: Cisco Enterprise Medianet のホーム ページ。

Collaboration Manager で使用する特定の Cisco Medianet 機能: Cisco IOS 機能に関する各ページ。

Performance Monitor: Cisco Enterprise Medianet のホワイト ペーパー。

トラブルシューティング ワークフローの開始

[Session Monitoring] ページの 360 ° Session ビューからセッションのトラブルシューティング ワークフローを開始できます。

エンドポイントのトラブルシューティング ワークフローは、[Endpoint Monitoring] ページのクイック ビュー ウィンドウ( 表 12-1 を参照)から開始できます。

図 12-2 [Endpoint Monitoring] ページからのトラブルシューティングの開始

 

 

1

[Endpoint Name] 列

2

トラブルシューティングを開始するエンドポイントの上にマウス ポインタを置いて、クイック ビュー アイコンをクリックします。

3

[Add to Watch List] リンク。

 

表 12-1 トラブルシューティング ワークフローの起動ポイント

トラブルシューティング タイプ
起動ポイント

自動

1. [Administration] > [Alarm and Event Configuration] > [Threshold Settings > [TelePresence Endpoint] を選択します。

2. 要件に基づいて、[Rx Packet Loss]、[Average Period Jitter]、および [Average Period Latency] のしきい値を設定します。

3. [Save] をクリックします。

自動

1. [Operate] > [Diagnose] > [Session Diagnostics] を選択します。

2. スケジューリングしたセッションを選択します。

3. [Video Collaboration Sessions] テーブルの [Session Subject] 列の上にマウス ポインタを置いて、表示される [360° Session View] アイコンをクリックします。

4. [Add to Watch List] をクリックします。

自動

1. [Operate] > [Diagnose] > [Endpoint Diagnostics] を選択します。

2. [Not In Use] 使用ステータスになっているエンドポイントを選択します。

3. [List of Endpoints] テーブルの [Endpoint Name] 列の上にマウス ポインタを置いて、表示されるクイック ビュー アイコンをクリックします。

4. [Add to Watch List] をクリックします。

エンドポイントがセッションに参加するとすぐに、トラブルシューティング ワークフローが開始されます。

手動

1. [Operate] > [Diagnose] > [Session Diagnostics] を選択します。

2. 進行中のセッションを選択します。アラームが設定された進行中のセッションを選択することを推奨します。

3. [Video Collaboration Sessions] テーブルの [Session Subject] 列の上にマウス ポインタを置いて、表示される [360° Session View] アイコンをクリックします。

4. アイコンをクリックして [Troubleshooting] ページを起動し、トラブルシューティングを開始する方向を選択します。

手動

1. [Operate] > [Diagnose] > [Session Diagnostics] を選択します。

2. 進行中のセッションを選択します。アラームが設定された進行中のセッションを選択することを推奨します。

3. [session topology] ペインでネットワーク リンク(ネットワーク リンクにアラームがある場合)の上にマウス ポインタを置いて、[360° Session View] アイコンをクリックします。

4. [Troubleshoot Network Link] をクリックします。

手動

1. [Operate] > [Diagnose] > [Endpoint Diagnostics] を選択します。

2. [In Use] 使用ステータスになっているエンドポイントを選択します。

3. [List of Endpoints] テーブルの [Endpoint Name] 列の上にマウス ポインタを置いて、クイック ビュー アイコンをクリックします。

4. [Add to Watch List] をクリックします。

トラブルシューティング ワークフローが即時に開始されます。

MSI 対応デバイスのトラブルシューティング

Cisco Mediatrace を使用すると、データ ストリームに関するネットワーク パフォーマンス低下の問題の切り分けを行ってトラブルシューティングできます。Mediatrace 対応デバイスがネットワークに導入されている場合、Prime Collaboration は、ネットワーク パスを可視化し、ビデオ フロー統計情報の詳細を示します。

エンドポイントが Mediatrace 用にメディア サービス インターフェイス(MSI)をサポートしている場合、Prime Collaboration では、このインターフェイスを使用して、Mediatrace 情報の取得、メディア パスの検出、およびさまざまなミッドポイントの統計情報の収集を行います。

MSI がエンドポイントでイネーブルになっていない場合、Prime Collaboration では、エンドポイントにログインして 5 タプル情報を取得し、この情報を使用して近くのルータまたはスイッチから Mediatrace を開始します。

MSI 対応のエンドポイントからトラブルシューティングを開始する場合、Mediatrace は、MSI 対応エンドポイント自体から起動します(最も近い Medianet 対応ルータからではない)。

MSI 対応エンドポイントは、Medianet バッジ付きで(を参照図 12-3)トラブルシューティング パス トポロジに表示されます。


) MSI 対応エンドポイントは MSI クレデンシャルを使用して検出する必要があります。MSI のクレデンシャルの詳細については、『Cisco Prime Collaboration 9.0 Device Management Guide』を参照してください。


 

図 12-3 MSI 対応エンドポイントのトラブルシューティング

 

トラブルシューティング データの分析

トラブルシューティング ジョブでは、エンドポイント間のパスが検出されます。パスが検出されると、ネットワーク デバイスの詳細情報が収集されます。検出されたネットワーク デバイスの詳細情報に基づいて、インベントリが更新されます。

トラブルシューティング ジョブが完了すると、次のデータが表示されます。

トラブルシューティング

ログ

Medianet Path View

パス アセスメント

トラブルシューティング

エンドポイント間で選択した方向のトポロジ(レイヤ 2 とレイヤ 3)を [Troubleshooting] タブで表示できます。

デバイス間の直線は、それらのデバイスが直接相互に接続されていて、Prime Collaboration がデバイスを検出できることを示します。

デバイス間の点線は、それらのデバイスが接続されていない可能性があり、Prime Collaboration が CDP リンク詳細情報をもとにデバイスを検出できないことを示します。

デバイスがアクセス可能な場合は、マウス ポインタをそのデバイス上に置き、クイック ビュー アイコンをクリックすることで、システム、インターフェイス、および Mediatrace フローの詳細を表示できます。

表 12-2 は、クイック ビューにリスト表示されるシステム、インターフェイス、およびフローの詳細をまとめたものです。

 

表 12-2 システム、インターフェイス、およびフローの詳細

フィールド
説明
Hostname

デバイスに設定されたホスト名。

IP Address

デバイスを管理するために使用される IP アドレス。このリンクを使用して、ページ内のエンドポイントまたはインフラストラクチャ デバイス ログを起動できます。

Mediatrace Capable

この情報は、デバイスで Mediatrace がイネーブルになっている場合にだけ表示されます。

Mediatrace Role

デバイスに Cisco Mediatrace ロールを設定します。

IP SLA Role

デバイスに IP SLA ロールを設定します。

Performance Monitor

設定された Performance Monitor。

System Status

Physical Memory Utilization (in%)

物理メモリ使用率(パーセンテージ)。

Swap Memory Utilization (in%)

スワップ メモリ使用率(パーセンテージ)。

CPU Utilization (in%)

CPU 使用率(パーセンテージ)。

System Status Multipoint Switch

Number of Active Meetings

マルチポイント スイッチに定義されたアクティブ セッションの数。

Number of Segments Used

使用されているセグメント(個々のビデオ ディスプレイ)の数。

Interface Details

Speed

インターフェイスのスピード。単位は Mbps、 snmpifSpeed オブジェクトで指定。

Administrative Status

インターフェイスの動作ステータス。 ifAdminStatus オブジェクトで指定。

Operation Status

インターフェイスの管理ステータス。 ifOperStatus オブジェクトで指定。

Input Metrics

表示されるデータは RFC1213 MIB 属性に基づく。

Output Metrics

表示されるデータは RFC1213 MIB 属性に基づく。

Network Diagnosis
これが表示されるのは、Cisco Prime NAM または Cisco Prime LMS でこれらのデバイスを管理している場合のみです。
Mediatrace Flow Information

次の情報はデバイスのすべての管理対象コーデックの統合レポートです。この情報は、デバイスで Mediatrace がイネーブルになっている場合にだけ表示されます。

DSCP

デバイス上に設定された DSCP 値。

IP Packet Drop Count

ドロップされた IP パケットの数。

RTP Packet Loss

リアルタイム転送プロトコル(RTP)が示すパケット損失。

RTP Packet Jitter (RFC 3550)

リアルタイム転送プロトコル(RTP)が示すジッター。

Ingress Interface

入力インターフェイスの詳細。

Egress Interface

出力インターフェイスの詳細。

View All Flows

このフロー情報は、デバイス上で Cisco IOS Performance Monitor が設定されている場合にのみ表示されます。

Prime Collaboration のインベントリでは、すべてのデバイスに DNS 名または IP アドレス(DNS 名が使用できない場合)を使用します。ただし Sysname はトラブルシューティング パス トポロジのすべてのミッドポイントとして表示されます。ミッドポイントの DNS 名または IP アドレスは、クイック ビューに表示されます。

トラブルシューティングの間にデバイスにアクセスできない場合、トラブルシューティング ワークフローはそのデバイスをスキップします。クレデンシャルを更新し、デバイスを再検出して、トラブルシューティングを続行する必要があります。

ログ

[Log] タブを使用して、トラブルシューティング ワークフロー ステータスの詳細を表示できます。ログ ファイルには、次の情報が含まれます。

トラブルシューティング ワークフローの開始時間と終了時間。

トラブルシューティングの開始方法、および自動と手動のどちらによるものか。

エンドポイント システムの詳細情報の取得時間。

パス検出の開始時間と終了時間。

パス トポロジの詳細の取得で問題が発生したかどうか。

ポーリングの開始時間。

パス トポロジ内のデバイスのいずれかで発生した障害。

Medianet Path View

Medianet Path View には、Mediatrace がイネーブルになっている各デバイスからの出力が含まれます。Prime Collaboration は分析を行い、Mediatrace セッション(ビデオ フロー)のホップと統計情報を表示します。

Medianet Path View では、次のグラフが表示されます。

CPU and Memory

このグラフではすべてのデバイスが表示され、次の情報を含んでいます(図 12-4 を参照)。

縦軸(Y 軸)は、1 分間の CPU 使用率をパーセンテージで表します。

横軸(X 軸)にはパス トレースで検出されたネットワーク デバイスすべてがリストされます。グレーで表示されたデバイスには、Cisco Mediatrace が設定されていません。

グラフ内の球体は、プロセッサ メモリ使用率の詳細をパーセンテージで表します。球体のツールチップには、メモリ使用率の正確な値が表示されます。

球体の大きさは、プロセッサ メモリ使用率によって変化します。球体のサイズが小さい場合、プロセッサ メモリ使用率が低いことを示します。

図 12-4 CPU and Memory グラフ

 

球体(赤いアイコン)をクリックすると、システム、インターフェイス、Mediatrace フローの詳細が表示されます。

CPU and Packet Loss

このグラフは、 Cisco Mediatrace が設定された デバイスについてのみ表示されます。次の情報が表示されます(図 12-5 を参照)。

縦軸(Y 軸)は、1 分間の CPU 使用率をパーセンテージで表します。

横軸(X 軸)にはパス トレースで検出されたネットワーク デバイスすべてがリストされます。グレーで表示されたデバイスには、Cisco Mediatrace が設定されていません。

グラフ内の球体は、ビデオ パケット損失の詳細をパーセンテージで表します。

グリーンの球体は、ビデオ パケット損失がゼロであることを示します。

オレンジの球体は、ビデオ パケット損失が 1 % を超えることを示します。球体の大きさは、ビデオ パケット損失によって変化します。球体のサイズが小さい場合、ビデオ パケット損失が少ないことを示します。

球体をクリックすると、インターフェイス レベルでのパケット損失をより詳細に分析できます。

ブルーの四角は、そのデバイスに Mediatrace が設定されておらず、利用できるビデオ パケット損失データがないことを示します。

図 12-5 CPU and Packet Loss グラフ

 

球体または四角(赤いアイコン)をクリックすると、システム、インターフェイス、Mediatrace フローの詳細が表示されます。

Video IP Bit Rate and Packet Loss

このグラフは、 Cisco Mediatrace が設定された デバイスについてのみ表示されます。次の情報が表示されます(図 12-6 を参照)。

縦軸(Y 軸)には、ビデオ IP ビット レートがキロビット毎秒(kbps)で表示されます。

横軸(X 軸)にはパス トレースで検出されたネットワーク デバイスすべてがリストされます。グレーで表示されたデバイスには、Cisco Mediatrace が設定されていません。

グラフ内の球体は、ビデオ パケット損失の詳細をパーセンテージで表します。

グリーンの球体は、ビデオ パケット損失がゼロであることを示します。

オレンジの球体は、ビデオ パケット損失が 1 % を超えることを示します。球体の大きさは、ビデオ パケット損失によって変化します。球体のサイズが小さい場合、ビデオ パケット損失が少ないことを示します。

球体をクリックすると、インターフェイス レベルでのパケット損失をより詳細に分析できます。

球体がない場合、そのデバイスに Cisco Mediatrace が設定されておらず、利用できるビデオ パケット損失データがないことを示します。

図 12-6 Video IP Bit Rate and Packet Loss グラフ

 

球体(赤いアイコン)をクリックすると、システム、インターフェイス、Mediatrace フローの詳細が表示されます。

Video Interarrival Jitter and Packet Loss

このグラフは、 Cisco Mediatrace が設定された デバイスについてのみ表示されます。次の情報が表示されます(図 12-7 を参照)。

縦軸(Y 軸)は平均ビデオ到着時間間隔ジッター値を示します(ミリ秒単位)。

横軸(X 軸)にはパス トレースで検出されたネットワーク デバイスすべてがリストされます。グレーで表示されたデバイスには、Cisco Mediatrace が設定されていません。

グラフ内の球体は、ビデオ パケット損失の詳細をパーセンテージで表します。

グリーンの球体は、ビデオ パケット損失がゼロであることを示します。

オレンジの球体は、ビデオ パケット損失が 1 % を超えることを示します。球体の大きさは、ビデオ パケット損失によって変化します。球体のサイズが小さい場合、ビデオ パケット損失が少ないことを示します。

球体がない場合、そのデバイスに Cisco Mediatrace が設定されておらず、利用できるビデオ パケット損失データがないことを示します。

図 12-7 Video Interarrival Jitter and Packet Loss グラフ

 

球体(赤いアイコン)をクリックすると、システム、インターフェイス、Mediatrace フローの詳細が表示されます。

IP DSCP and Packet Loss

このグラフは、 Cisco Mediatrace が設定された デバイスについてのみ表示されます。次の情報を表示します。

縦軸(Y 軸)は、平均 IP Differentiated Service Code Point(DSCP; DiffServ コード ポイント)を示します。この値は、デバイスで事前に設定されています。

横軸(X 軸)にはパス トレースで検出されたネットワーク デバイスすべてがリストされます。グレーで表示されたデバイスには、Cisco Mediatrace が設定されていません。

グラフ内の球体は、ビデオ パケット損失の詳細をパーセンテージで表します。

グリーンの球体は、ビデオ パケット損失がゼロであることを示します。

オレンジの球体は、ビデオ パケット損失が 1 % を超えることを示します。球体の大きさは、ビデオ パケット損失によって変化します。球体のサイズが小さい場合、ビデオ パケット損失が少ないことを示します。

球体がない場合、そのデバイスに Mediatrace が設定されておらず、利用できるビデオ パケット損失データがないことを示します。

図 12-8 IP DSCP and Packet Loss グラフ

 

球体(赤いアイコン)をクリックすると、システム、インターフェイス、Mediatrace フローの詳細が表示されます。

メディアネットが有効なネットワーク

メディアネットはネットワークの可視性を拡大して、トラブルシューティングを簡略化し、よりすばやく行えるようにします。Prime Collaboration におけるメディアネットが有効なネットワークと、メディアネットが無効なネットワークの間の主な相違は以下のとおりです。

 

詳細情報
メディアネットが有効なネットワーク
メディアネットが無効なネットワーク

Path Topology

Yes

Yes

System Statistics

Yes

Yes

Interface Statistics

Yes

Yes

Medianet Flow Information(DSCP、IP Packet Drop Count、RTP Packet Loss、RTP Packet Jitter(RFC 3550)、Ingress Interface、Egress Interface)

Yes

No

View All Flows

Yes

No

Mediatrace 診断

この情報は、デバイスで Mediatrace がイネーブルになっている場合にだけ表示されます。詳細については、「Cisco Mediatrace」を参照してください。Mediatrace 統計が無効になっている場合、つまり、Mediatrace フロー情報がクイック ビューに表示されない場合、Prime Collaboration はアプリケーション診断をサポートし、表示されない理由を認識します。

クイック ビューから [Run Diagnostics] をクリックして、根本原因と推奨事項を確認する必要があります。

Prime Collaboration は、次を確認します。

Prime Collaboration で、CLI を使用してデバイスにアクセスできる。

Mediatrace Initiator ロールがデバイスに設定されている。

Mediatrace Responder ロールがデバイスに設定されている。

WSMA が設定されている。

HTTP サーバが設定されている。

エンドポイントのバージョンが 5 タプルをサポートしている。

セッション用に Mediatrace が設定されている。

Mediatrace のライセンスがデバイスにインストールされている。

コールが保留状態である(CTS のみ該当)。

Cisco Mediatrace 2.0 はこのリリースではサポートされていません。Mediatrace 2.0 をサポートする IOS イメージを格納したデバイスを使用する場合、Cisco Mediatrace を使用してトラブルシューティングを実行するときに、次の点に注意してください。

Mediatrace 2.0 を装備したデバイスに Mediatrace Initiator ロールが設定されている場合、Prime Collaboration はデバイスから Mediatrace セッションを開始しません。ただし、そのデバイスの Mediatrace Role は [Device Work Center] ページ([Operate] > [Device Work Center] > [Current Inventory] テーブル)で、[Initiator] または [Initiator/Responder] として表示される場合があります。デバイスの IOS イメージのバージョンが 15.2(3)T(Cisco Mediatrace 2.0 を装備)の場合は、[Troubleshooting Logs] タブにエラー メッセージが表示されます。

Mediatrace 2.0 を装備したデバイスが Mediatrace Responder ロールで設定されている場合、トラブルシューティング中に使用される発信側デバイスに Mediatrace 1.0 が装備されている場合に限り、これらのデバイスの Mediatrace の統計情報を表示できます。

View All Flows

この情報は、デバイス上で Cisco IOS Performance Monitor が設定されている場合にのみ表示されます。

ネットワーク内のパケット フローを表示する手順は次のとおりです。


ステップ 1 トラブルシューティング トポロジ内のデバイスを選択します。

[Performance Monitor] フィールドに [Configured] が表示されていることを確認します(図 12-9 を参照)。

図 12-9 [Configured] と表示された Performance Monitor の状態

 

ステップ 2 [View All Flows] をクリックします。

ステップ 3 パケット フローをモニタするインターフェイスを選択します。

ステップ 4 トラフィックのタイプを選択します。

ステップ 5 [Start] をクリックします

次の詳細情報が表示されます。

図 12-10 Performance Monitor

 

 

表 12-3 インターフェイスに関するフローの詳細情報

フィールド
説明

Current Selection

選択したデバイスの詳細情報。

Interface

デバイス上で選択したインターフェイス。

Type of Traffic Selected

選択したトラフィックのタイプが [All] か [RTP] かを示します。

Maximum Bandwidth

インターフェイスに対して使用できる最大帯域幅(単位は Mbps)。

Interface Usage / Interface Utilization Bar Chart

選択したインターフェイスの使用量(単位は Kbps)。

Flow Usage / Flow Usage Pie Chart

この値は、選択したインターフェイスにおいて個々のフローに使用される帯域幅の合計を表しています( 表 12-4 を参照)。

選択したインターフェイスは、入力または出力のいずれかとして表示されます。Prime Collaboration では、選択したインターフェイスに関するフローの詳細情報がすべて表示されます。

 

表 12-4 インターフェイスに関する個々のフローの詳細情報

フィールド
説明

Ingress

入力インターフェイスの詳細。

Source

パケット フローの起点となる発信元デバイスの名前。

Egress

出力インターフェイスの詳細。

Destination

宛先デバイスの名前。

Protocol

パケット フローに使用されるプロトコル。

Source and Destination Port

フローに使用されるポート。

Application

アプリケーションのタイプ。

Application Category

音声、ビデオ、またはその他のカテゴリのいずれであるか。

Bandwidth (bps)

アプリケーションで使用される帯域幅。

Packet Loss (%)

オーディオおよびビデオ用のパケット損失。

Jitter (ms)

オーディオおよびビデオ用のジッター。


 

パス アセスメント

テスト可能なデバイス、テスト不可能なデバイス、Mediatrace が有効になっているデバイス、パケット ロスしきい値違反のデバイス、ジッターしきい値違反のデバイス、および DSCP 違反のデバイスに関するトラブルシューティングの概要を表示できます。

トラブルシューティングで判別されたデバイスに対して、一連のテストが実行されます。パス アセスメント テストを開始するには、セッションのトラブルシューティングの完了後に、[Path Assessment Tests] をクリックします。


) パス アセスメント テストは、[Managed] 状態であり、CLI アクセス レベル(RW/RO)を持つミッドポイントでのみ実行できます。パス アセスメント テストは、エンドポイントでは実行できません。


次の表に、パス アセスメント テストのタイプをリストします。

 

カテゴリ
テスト

インターフェイス

コントローラ スリップ

出力キューでのコリジョン

コントローラ パス コード違反

入力キューのドロップ

出力キューのドロップ

コントローラ ライン コード違反

コントローラ回線エラー

インターフェイスのフラッピング

Duplex mismatch(デュプレックス モードが不一致)

コントローラのエラー秒数

出力キューでのバブル

出力キューでのエラー

コントローラのフレーム損失

分類/マーキング

DSCP-CoS マッピング

CoS-DSCP マッピング

信頼

信頼の設定

キューイング

出力プライオリティ キュー

LLQ バースト値

CBWFQ キュー制限

CBWFQ/LLQ チェック

ポリシング/シェーピング

ビデオ ストリームの CBWFQ/LLQ

ビデオ トラフィックの出力ポリシー マップのスキャン

テスト結果

テストの結果は、次のように表示されます。

 

アイコン
説明

 

合格を示します。デバイス/カテゴリに対するすべてのテストが合格した場合のみ、テスト結果は合格になります。

 

不合格を示します。デバイス/カテゴリに対して少なくとも 1 つのテストが不合格になると、テスト結果は不合格になります。

 

何らかの理由で、テストを実行できず、結果が不明であることを示します。たとえば、CDP が有効ではない場合、入力および出力インターフェイスは判別されません。このため、信頼 DSCP などのテストは実行できず、結果は不明になります。

テストが不合格になった場合( アイコンで表示)、[Result Field] のクリック ビュー アイコンをクリックして、テストについての根本原因と推奨事項を表示します。

対象のデバイスを選択して、そのデバイスの IP アドレスの横にある矢印をクリックし、そのデバイスで実行されたテストの詳細を表示できます。

単一デバイスの詳細トラブルシューティングを行うには、不合格/不明テスト結果の結果列の上にマウス ポインタを置いて、クイック ビューをクリックし、根本原因と推奨事項を表示します。合格したテストに対しては、クイック ビューは使用できません。


) 14 日以上経過したすべてのセッション情報とトラブルシューティング情報は、1 時間に 1 回パージされます。


トラブルシューティング データのエクスポート

データをエクスポートできるのは、セッションの終了後だけです。トラブルシューティング ジョブの完了後に、[Session Monitoring] ページにトラブルシューティング ジョブ ステータスが表示されます。

トラブルシューティング データをエクスポートするには、次の手順を実行します。


ステップ 1 [Operate] > [Diagnose] > [Session Diagnostics] を選択します。

ステップ 2 トラブルシューティング ステータス アイコンに [Troubleshooting Report Available] が表示される過去のセッションを選択します。

ステップ 3 [Video Collaboration Sessions] テーブルの [Session Subject] 列の上にマウス ポインタを置いて、表示される [360° Session View] アイコンをクリックします。

ステップ 4 [360° Session View] ウィンドウの をクリックします。


 

トラブルシューティング レポートのエクスポートについて

トラブルシューティング レポートをエクスポートすると、次の詳細情報が含まれます。

 

レポート フィールド
説明

Session Identifier

セッションの固有 ID。

Session Subject

セッションがアドホックか、スケジュール済みか、スタティックかを表示します。

Session Date

セッションが発生した日付。

Session Start Time

セッションの開始時刻。

Session Duration in Minutes

セッションの期間。

Session Type

セッションがポイントツーポイントか、またはマルチポイントかを表示します。

Endpoints

セッションの一部であったエンドポイントの詳細。

Call Segment

トラブルシューティング中に使用された方向を表示します。

Troubleshooting Session

トラブルシューティング ワークフローの開始時刻と終了時刻。

Troubleshooting Session ID

トラブルシューティング ワークフローの固有 ID。

Troubleshooting Start Time

トラブルシューティング ワークフローの開始時刻。

Troubleshooting Initiation

トラブルシューティングが手動で開始されたか、自動的に開始したかを表示します。

Path Topology and Metrics

トラブルシューティング パス トポロジとメトリクスについての情報を表示します。

以下にフィールドとそれらの説明を示します。

[Host Name/IP Address]:ホスト名または IP アドレス。

[CPU Utilization (Max, Avg)]:CPU 使用率の最大と平均を表示します。

[Memory Utilization (Max, Avg)]:メモリ使用率の最大と平均を表示します。

[Packet Loss (Video, Audio)]:ビデオおよびオーディオの最大パケット損失を表示します。

[Max Jitter (Video, Audio)]:ビデオとオーディオの最大ジッターを表示します。

[DSCP (Video, Audio)]:ビデオおよびオーディオの DSCP 値を表示します。

Troubleshooting End Time

トラブルシューティング ワークフローの開始時刻。

Troubleshooting Termination

トラブルシューティング ワークフローが手動で終了されたか、自動的に停止したかを表示します。