TelePresence MCU ハードウェア トラブルシューティング ガイド
内容
はじめに
このドキュメントでは、Cisco TelePresence Multipoint Control Unit（MCU）製品をトラブルシュートする手順について説明します。このドキュメントは、ビデオ システム管理者と、お客様がビデオ システム管理者であるシスコ パートナーを対象とします。
MCU 製品群は、業界最先端のマルチメディア会議製品です。これらは、最適なパフォーマンスを提供するためにシスコで設計されたハードウェアを使用する複合的な組み込みシステムです。このドキュメントは、Cisco MCU 製品のハードウェア障害に起因する状況の解決を促進することを目的としています。シスコ テクニカル サポート エンジニアは、疑わしいコンポーネントに応じた一連のテストを通して、実際に製品で障害が発生するかどうかを確認し、その上で Return to Manufacturing Authorization（RMA）を付与する必要があります。このガイドの目的は、これらのテストから得られた知見を利用して、このプロセスを促進することです。
前提条件
要件
次の項目に関する知識があることが推奨されます。
- Cisco TelePresence MCU MSE シリーズ
- Cisco TelePresence MCU 5300 シリーズ
- Cisco TelePresence MCU 4500 シリーズ
- Cisco TelePresence MCU 4200 シリーズ
- Cisco TelePresence ISDN Gateway（GW）シリーズ
使用するコンポーネント
このドキュメントの情報は、Cisco TelePresence MCU Media Services Engine（MSE）シリーズに基づいています。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
関連製品
このドキュメントは、次のバージョンのハードウェアとソフトウェアにも使用できます。
- Cisco Telepresence Server 7010
- Cisco Telepresence MCU 5300 シリーズ
- Cisco Telepresence MCU 4500 シリーズ
- Cisco Telepresence MCU 4200 シリーズ
- Cisco Telepresence ISDN Gateway シリーズ
Cisco TelePresence MCU MSE シリーズ RMA チェックリスト
このセクションでは、MCU MSE シリーズ ブレードが動作可能で、ハードウェア障害の影響を受けないことを確認するために使用される、より基本的なチェックについて説明します。MCU の動作はこれらのチェックが完了した時点で文書化される必要があります。
MCU のクイック チェックの実行
このセクションでは、Web インターフェイス経由の MCU の基本設定のトラブルシューティングに使用できるチェックリストを示します。これは、H.323 設定、自動応答、ポート ライセンスの使用、およびループバック コールの確認で構成されます。
ブレードからビデオ コールを発信できることを確認します。MCU Web インターフェイスにアクセスできて、コールを発信できれば、基本的に機能します。次のステップを実行します。
- Web ブラウザを開いて、MCU IP アドレスに移動します。ホームページには、次のように表示されるはずです。
- MCU 上で現在動作しているソフトウェア リリースをチェックするには、[Status] リンクをクリックします。
- Web インターフェイスにアクセス可能な場合は、次の手順を実行します。
- [Settings] > [H.323] に移動して、[H.323 gatekeeper usage] を [Disabled] に設定します。一部のゲートキーパーが MCU から IP アドレスへの直接コールを阻止するため、このステップは不可欠です。
- [Settings] > [Conferences] > [Advanced Settings] に移動し、[Incoming calls to unknown conferences or auto attendants] が [Default Auto Attendant] に設定されていることを確認します。
- 新しい会議を作成して、127.0.0.1 の IP アドレスで H.323 参加者を追加します。これにより、MCU は独自の自動応答（AA）をコールバックできます。AA 画面にプレビュー サムネールが表示され、オーディオ コーデックとビデオ コーデックの両方が双方向でネゴシエートされます。
ここで、MCU がそれ自体を正常に呼び出すことができた場合の MCU MSE 8510 画面の例を示します。
これが動作し、接続された参加者が（前の画像と同様に）表示されている場合は、ゲートキーパー、ネットワーク、またはエンドポイントの相互運用問題が発生している可能性があります。実際のエンドポイントにダイヤルして、そこでイベント ログと H323/Session Initiation Protocol（SIP）ログを使用してトラブルシューティングします。接続はただちに失敗するが、Web インターフェイスがまだ機能している場合は、次の手順に進みます。 - ポート ライセンスが MCU に割り当てられていることを確認するために、Supervisor ブレードのポート ライセンス管理セクションに移動します。ここで、Supervisor MSE 8050 ブレードからのポート ライセンスの割り当てを示す画像を示します。
画像で、スロット 4 の下の空のブロックは、ポート ライセンスが割り当てられていないブレードがこのスロットに実装されていることを示します。このブレードはコールを発信できないため、ステップ3で説明されているループバックテストがこのブレードで失敗します。スロット 2、3、5、および7 の下の青色のブロックは、これらのスロットにポート ライセンスが完全に割り当てられていることを示します。スロットに警告シンボルが表示されている場合は、そのスロットにブレードが実装されていません。半分青色のブロックは、ブレードに一部のポート ライセンスが割り当てられていることを示しますが、フル機能を備えていることを示しているわけではありません。このようなブレードは、さらにライセンスが割り当てられるまで、アドバタイズされたすべてのポートに接続することができません。 - ブレードにライセンスが割り当てられていない場合は、ポート ライセンスを割り当てます（このプロセスについては、オンライン ヘルプを参照してください）。ポート ライセンス用のキーが提供されていない場合は、アカウント マネージャにお問い合わせください。
- [Settings] > [H.323] に移動して、[H.323 gatekeeper usage] を [Disabled] に設定します。一部のゲートキーパーが MCU から IP アドレスへの直接コールを阻止するため、このステップは不可欠です。
MCU ネットワーク接続の確認
このセクションは、ネットワーク接続とネットワーク設定の検証に基づいて、ブラウザから MCU Web インターフェイスへの接続中に発生した問題をトラブルシューティングする場合に使用します。
ブラウザから MCU Web インターフェイスに接続しようとすると、次の問題のいずれかが発生する可能性があります。
- PC と MCU 間のネットワークに伴う問題
- MCU 自体に伴う問題（ネットワーク インターフェイス カード（NIC）、ハードウェア、または設定）
この問題をトラブルシューティングするには、次の手順を実行します。
- MCU の IP アドレスを ping します。
MCU が ping に応答しても、Web インターフェイスがダウンしている場合は、MCU が完全にブートできない、またはリブート サイクルにロックされる可能性があります。その場合は、このドキュメントの「ブレードでの物理チェック」のセクションを参照してください。MCU が ping に応答しない場合は、次の手順に進みます。 - MCU MSE 8510 ブレードを含むシャーシの Supervisor MSE 8050 ブレードの Web インターフェイスに移動します。Supervisor ブレード ユーザ インターフェイスに到達できない場合は、ローカル ネットワーク管理者に問い合わせて、可能性のあるネットワークの問題を調査してください。Supervisor ブレード ユーザ インターフェイスに到達可能で、Supervisor と MCU が同じネットワーク上に存在する場合は、問題がブレードまたはその IP 設定にある可能性があります。
- Supervisor ブレード ユーザ インターフェイスから、[Hardware] に移動して、MCU MSE 8510 ブレードのスロット番号リンクをクリックします。次に、[Port A] タブをクリックします。
- MCU の [Port A IP configuration] を調べて、ネットワーク上の他のホストに同じ IP アドレスが割り当てられていないことを確認します。IP アドレスの重複はよく発生する問題です。必要に応じて、ネットワーク管理者に相談して次の設定を確認してください。
- [Port A Ethernet status] セクションを調べます。リンク ステータスが [up] になっていない場合は、ネットワーク ケーブルがスイッチに接続されていることを確認します。ケーブルまたはスイッチ ポートに問題がある可能性があります。
- ネットワーク上で MCU が到達可能な場合は、この手順の最初のステップを繰り返します。IP アドレスの設定が正しく、イーサネット リンクのステータスが [up] になっているが、ブレードがまだネットワーク上でアクセス不可能な場合は、このドキュメントの「Supervisor 経由の MCU MSE 8510 シリーズ ブレードの確認」のセクションを参照してください。
Supervisor 経由の MCU MSE 8510 シリーズ ブレードの確認
MCU ブレードと会議のステータス、ヘルスと稼働時間に関するレポート、ソフトウェア バージョン、温度、および電圧を確認するには、次の手順を実行します。
- [Hardware] をクリックして、問題のあるブレードのスロット番号をクリックします。サマリー ページに、以下に関する情報が表示されます。
- IP アドレス、稼働時間、シリアル番号、およびソフトウェア バージョンを含む [Blade status]
- 温度、電圧、およびリアルタイム クロック（RTC）バッテリを含む [Blade health]
- アクティブな会議、参加者の人数、使用中のオーディオ/ビデオ ポートの数、およびストリーミング視聴者の人数に関する [Reported status]
次の画像に、[Blade health] セクションを示します。
- [Voltage] ステータス（current または worse）に [OK] と表示されていない場合は、シャーシに電力を供給する電源シェルフに十分な整流器が設置されていることを確認します。また、シスコの記事「MSE 8000 の電力と電流の要件を計算する」に記載されているように、電源がシャーシの電流要件を満たしていることを確認します。
- 電源プロビジョンに [OK] と表示されない場合は、シスコ テクニカル サポートにお問い合わせください。
- [Blade health] セクション内の他の電流ステータスのいずれかに [OK] と表示されていない場合は、シスコ テクニカル サポートにお問い合わせください。
- すべての電流ステータスが [OK] と表示されているが、1 つ以上の [Worst status seen] に [OK] と表示されていない場合は、Supervisor からイベント ログとアラーム ログを取得して、シスコ テクニカル サポートにお問い合わせください。
- 稼働時間を確認します。稼働時間が予想外に短く（30 分未満）、理由が不明な場合（電源が再投入されていない場合やブレードが再装着されていない場合など）は、ブレードが最近リブートした可能性があります。リブートの原因として、ソフトウェアの不具合やハードウェアの問題が考えられます。これは、ワンタイム リブートなのか、循環リブートなのかによって異なります。
これを判断するには、次の手順を実行します。
- 30 分間待機します。
- ページを更新します。
- 再度、稼働時間を確認します。
更新された稼働時間からブレードが続けてリブートしたことが判明した場合は、このドキュメントの「クラッシュ」のセクションを参照してください。 - 30 分間待機します。
- ステータス ページを確認した後でブレードがリブートしておらず、他のすべての点が正常に見える（ネットワーク設定とポート ライセンスの検証を通して）場合は、ブレードが使用可能なデジタル シグナル プロセッサ（DSP）リソースを使用せずに起動した可能性があります。
これを確認するには、次の手順を実行します。
- Supervisor ユーザ インターフェイスから、ブレード サマリー ページの [Reported status] セクションを確認します。
- ブレードが正常にブートして、ライセンスを付与されたビデオ リソースの総数が表示されます。これは、ブレードに割り当てられたポート ライセンスの数と一致する必要があります。ブレードが高解像度（HD）/HD+ モードの場合は最大 20 で、ブレードが標準画質（SD）モードの場合は最大 80 です。これらが一致しない場合は、動作、バージョン、および診断ログを文書化してシスコ テクニカル サポートにお問い合わせください。
- Supervisor ユーザ インターフェイスから、ブレード サマリー ページの [Reported status] セクションを確認します。
ブレードでの物理チェック
このセクションでは、LED ライトの理解と別のスロットへのブレードの移動に基づいて、ブレード上で物理チェックを実行するために使用される手順について説明します。
前のセクションで説明された手順を実行した後にブレードのハードウェアで問題が起きたかどうかがわからない場合は、MSE 8000 シリーズ シャーシを物理的に確認します。物理チェックを実行するには、次の手順を実行します。
- 最初にシャーシの電源をオンにしてからブレードがブートするまでに十分な時間が確保されていることを確認します（またはすでに電源がオンになっているシャーシにブレードを設置します）。これには約 20 分かかります。
- ブレードの前面で点灯している LED ライトの色を確認してメモします。重要な LED ライトは次のとおりです。
- 電源（青色）：このライトは、下部プラスチック タブのすぐ上にあり、ブレードに電力が供給されるとすぐに点灯します。
- ステータス（緑色）：このライトは、ブレードが正常にブートしたときに点灯します。
- アラーム（赤色）：このライトは、ブレードがブート中またはブートできない状態にある場合に点灯します。
- イーサネット ポート A リンク（3 つの緑色）：このライトは、アクティビティ、デュプレックス、および速度を示します。リリース4.4の時点で、8510はポートAの接続のみをサポートします。ポートB、C、およびDはサポートされません。
- 電源（青色）：このライトは、下部プラスチック タブのすぐ上にあり、ブレードに電力が供給されるとすぐに点灯します。
- LED ライトを確認したときに問題が発生した場合は、次の手順を実行します。
- いずれのライトも点灯していない場合は、シャーシの他の部分に電力が供給されていることと、ブレードが正しくスロットに装着されていることを確認します。
- ライトがまだ点灯しない場合は、ブレードをシャーシ内の別のスロットに移動します。できれば、動作していることがわかっているブレードが装着されていたスロットに移動します。
- それでもブレードが起動しない場合は、シスコ テクニカル サポートにお問い合わせください。
- 青色の電源ライトは点灯しているが、他のライトが消灯している場合は、シスコ テクニカル サポートにお問い合わせください。赤色のアラーム ライトが 30 分以上点灯している場合は、このドキュメントのクラッシュのセクションを参照してください。
- 青色の電源ライトと緑色のステータス ライトが点灯しているが、緑色のポート A ライトが消灯している場合は、RMA が必要ありません。これは、スイッチ ポートへの接続に問題があることを示しています。新しいケーブル/スイッチ ポート/スイッチを使用して、Supervisor の [Hardware] タブで、ブレードの [Ethernet Port A] 設定を確認します。リンクの両側を自動ネゴシエーション用に設定することを強くお勧めします。
- いずれのライトも点灯していない場合は、シャーシの他の部分に電力が供給されていることと、ブレードが正しくスロットに装着されていることを確認します。
Web インターフェイス上での MCU への到達
Cisco TelePresence MCU は、ユニットに付属のコンソール ケーブルを通してコンソール セッション経由でアクセスできます。システムが Web インターフェイス経由でアクセスできず、ping 要求に応答しない場合は、ユニットへのコンソール セッションを開いて、有効にされたサービス、ポート設定、およびステータスを確認することによりトラブルシューティングできます。
システムに ping できない場合や IP アドレスを割り当てた後にシステムの Web インターフェイスに移動できない場合に MCU に到達するには、次の手順を実行します。
- ユニットの前面にある赤色のアラーム ライトが点灯していないことを確認します。ユニットの電源をオンにしてから 20 分以上経過しているのに、まだ赤色のアラーム ライトが点灯している場合は、このドキュメントの「クラッシュ」のセクションを参照してください。
- デバイス上で緑色のステータス ライトが点灯している場合は、ユニットに付属のコンソール ケーブルを通して PC をコンソール ポートに接続します。
- 接続したターミナル セッションが実際に接続されていることを確認するには、Enter キーを数回押します。そうすると、プロンプトが表示されます。表示されるプロンプトには、デバイス(IPGW:>、ISDNGW:>、またはMCU:>など)が示されています。
- HTTP または HTTPS サービスが有効になっていることを確認するには、service show コマンドを入力します。
- デバイスのリンク ステータスを確認するには、status コマンドを入力します。
- [Port A] に [no link] と表示された場合は、イーサネット ケーブルをポート B に接続して、リンク ステータスが変化するかどうかを確認します。
- ポート B ではリンクを検出できるが、ポート A では検出できない場合は、次の手順を実行して、ポート A の IP 設定を再確認します。
- ポート A A に問題がない場合は、reset_config 手順を実行して、工場出荷時のデフォルト設定に戻します。
- 工場出荷時のリセット プロセスが完了したら、ポートの静的 IP アドレスを再設定します。
- それでも問題が解消されない場合は、コンソールからシステムをリブートして、使用されているターミナル クライアントを介してブートからの出力をテキスト ファイルに収集します。
MCU MSE 8510 シリーズ ブレードと MCU MSE 8710 シリーズ ブレードには、2 つのイーサネット インターフェイスが vfx0 と vfx1 として表示されます。ラックマウント可能なシステム（MCU 4500 シリーズと 4200 シリーズ、IPGW 3500 シリーズ、および ISDN GW 3241 シリーズ）には、イーサネット インターフェイスが bge0 と bge1 として表示されます。
- ポート A A に問題がない場合は、reset_config 手順を実行して、工場出荷時のデフォルト設定に戻します。
- MCU MSE 8510 および 8710 シリーズ ブレードで、MAC アドレスが割り当てられていることと、vfx0 または vfx1 に問題がないことを確認します。
- ラックマウント可能なユニットで、次の画像に示すような、デバイス上のネットワーク インターフェイス カード（NIC）の障害を示す bge0 を伴う出力が表示される場合があります。これは物理層が検出されなかったことを示します。この現象が確認された場合は、シスコ テクニカル サポートにお問い合わせください。
- ポートを入れ替えても [no link] が表示される場合は、ネットワーク接続を確認します。理想的には、出力が、次の画像に示すように、すべての IP 情報を伴って表示される必要があります。これはユニットの IP 設定が正しく設定されていることを示しています。
- ネットワーク上の IP アドレスのセットに伴う問題を発見するには、ユニットの IP アドレスを変更します。
- スイッチ ポートの問題を解決するには、イーサネット ケーブルを別のスイッチ ポートに移動します。
- スイッチ ポートの問題が解決された場合は、クロス ケーブルを介してラップトップを直接ユニットに接続して、そのサブネット内に含まれる同じサブネット マスク、デフォルト ゲートウェイ、および IP アドレスでラップトップを設定します。
- ラップトップに IP アドレスを設定したら、ラップトップからユニットに ping を送信します。ラップトップからユニットの Web インターフェイスに到達できるかどうかを確認します。また、ping コマンド経由でユニット コンソール セッションからラップトップの IP アドレスに ping を送信します。接続と Web アクセスがある場合は、ネットワーク接続の問題を示しています。そうでない場合は、イーサネット ポート ピンが破損している可能性があるため、シスコ テクニカル サポートに問い合わせる必要があります。
クラッシュ
Cisco TelePresence MCU 製品のクラッシュは、ブートの失敗、連続リブート サイクル、または連続会議で発生したインシデントに起因している可能性があります。
ユニットの赤色のアラーム ライトが 20 分以上点灯したままになっている、ユニットの Web インターフェイスに移動できない、またはビデオ コールを発信できない場合は、ユニットがブートに失敗したか、リブート サイクルで止まっている可能性があります。その場合は、次の手順を実行して、問題をトラブルシューティングします。
- ユニットの電源リード線を外します。これがブレードの場合は、それをシャーシから取り外します。
- 5 分待ってから、ユニットの電源をオンにします。
- ユニットが正常にブートしない場合は、ブートを試みたユニットが表示されたコンソール ログを収集します。これはこの状況に最適な診断ツールです。コンソール ログの収集方法については、シスコの記事「シスコが所有する Codian ユニット上でコンソール ポートに接続する」を参照してください。
- ユニットの電源をオフにしてから、ユニットの電源をオンにします。
- 出力が完全に停止するか、ユニットが 3 回または 4 回リブートするまで待機します。シスコ テクニカル サポートに問い合わせて、コンソール ログを提供します。
MSE 8000 シリーズのファン トレイ、電力整流器、および電源シェルフのトラブルシューティング
ファン トレイ、電力整流器、および電源シェルフはすべて Supervisor MSE 8050 シリーズ ブレード経由でモニタされます。Supervisor Web インターフェイスを介してこれらに関係する障害や問題をトラブルシューティングすることができます。このセクションでは、ログとステータスの検証を通して、ファン、電源シェルフ、または電力整流器の障害をトラブルシューティングするために使用する手順について説明します。
完全な MSE 8000 シリーズ シャーシを示す画像は次のとおりです。
上の画像の注目点：
- 上側と下側のファン トレイ
- 挿入されたブレード
- 個々のブレードの拡大図
- ラック マウント
MSE 8000 シリーズ ファン障害のトラブルシューティング
このセクションは、Supervisor MSE 8050 シリーズ ブレード上のアラーム ステータスとイベント ログの検証を通して、MSE 8000 シリーズ シャーシのファン障害をトラブルシューティングするために使用します。
ここで、上側のファン トレイに伴う問題を示すイベント ログからの抜粋を示します。
37804 2012/07/03 18:43:28.567 HEALTH Warning
upper fan tray, fan 3 too slow - 1569 rpm
37805 2012/07/03 18:43:28.567 ALARMS Info
set alarm : 2 / Fan failure SET
37806 2012/07/03 18:43:44.568 ALARMS Info
clear alarm : 2 / Fan failure CLEAR
37807 2012/07/03 18:44:00.569 HEALTH Warning
upper fan tray, fan 3 too slow
次のようなエラーが表示された場合は、次の手順を実行して必要なログを収集します。
- アラーム ログ テキスト ファイルをダウンロードするには、[Alarms] > [Alarms Log] > [Download as Text] に移動します。これが記録された最新の日付を確認します。
- イベント ログ テキスト ファイルをダウンロードするには、[Logs] > [Event Log] > [Download as Text] に移動します。
- [Alarms] > [Alarms Status] に移動して、[Alarm Status] ページのスクリーン ショットを撮ります。
- 上部のファン トレイを外して、すべてのファンが正しく動作していることを確認します。
- 下部のファン トレイを外して、すべてのファンが正しく動作していることを確認します。
- Supervisor のアラーム履歴を消去するには、[Alarms] > [Alarms Status] > [Clear Historic Alarms] に移動します。
- アラーム ログを消去するには、[Alarms] > [Alarms Log] > [Clear Log] に移動します。
- アラームが再発するかどうかをモニタして確認します。
- 問題が再発した場合は、上部トレイと下部トレイを交換して、問題がファン トレイに起因するかどうかを確認します。問題が再発してファン トレイに起因する場合は、収集したログと一緒にシスコ テクニカル サポートにお問い合わせください。
電源シェルフ問題
MSE 8000 シリーズ シャーシ内部には、2 つの DC 電源または AC を DC に変換する 2 つのバレール シェルフのどちらかに直接接続できる 2 つの独立した DC 電源入力があります。MSE 8000 シリーズ シャーシは、1 つまたは 2 つの電源シェルフ（A と B）で動作できます。これらがすべてのファン トレイとブレードに個別に電力を供給します。ユニットは、電源Aまたは電源Bから完全に給電できます。一方の電源モジュールで障害が発生しても、もう一方の電源モジュールから電力が供給されるため、ユニットは動作し続けます。
完全な冗長性と最大限の信頼性を確保するために、電力供給を独立した電源に接続することをお勧めします。それぞれが、ユニットと、同じ数の整流器を含む各シェルフの全電気負荷に対応できるだけの容量を備えている必要があります。
次の画像に、MSE 8000 シリーズの DC 電源シェルフを示します。
ここで、発生する可能性がある 2 つの一般的な電源シェルフの問題を示します。
- [Lost Contact with Power Shelf] - [Hardware] > [Power Supplies] と移動したときに、[Supply A] に [Lost Contact with Power Shelf] と表示されます。これは、Supervisor MSE 8050 シリーズが電源シェルフと通信できないことを意味します。
- [10/External supply out of range SET] - これは、シャーシへの入力電圧が仕様の範囲外であることを意味します。「MSE 8000 の電力と電流の要件を計算する」のオンライン ツールを使用して、正しい電力と電流がシャーシに提供されていることを確認します。
前述の電力と電流の検証を実行したときに矛盾が発見されなければ、その情報を取得して、シスコ テクニカル サポートにお問い合わせください。
- MSE 8050 シリーズの Supervisor 設定
- 監査ログ
- アラーム ログ
- イベント ログ
- [Alarm Status] ページのスクリーンショット
- シャーシ内のブレードの数とモデル
- 電源のステータス
電源ステータス モニタリングの設定
ログに書き込まれたすべてのエラー、警告、またはその他の重要な情報に関する信頼できるフィードバックをビデオ管理者に提供するために、電源ステータス モニタリングを設定することをお勧めします。
電源電圧と AC/DC 電源シェルフ（必要に応じて）のモニタリングを有効にするには、『Cisco TelePresence Supervisor 2.3 オンライン ヘルプ（印刷可能な形式）』の 61 ページの手順を実行します。電源ステータス設定の完了後にログを消去します。
電源シェルフの背面からシャーシに配線された電源シェルフ モニタリング ケーブルを確認します。これは電源シェルフ モニタリングに使用される特殊なケーブルです。ケーブルをチェックするときは、標準の DB9-RJ45 コンソール ケーブルと混同しやすいため、注意が必要です。電源シェルフ モニタリング ケーブルには、「Power Shelf Rear」というラベルが付けられています。
MSE 8000シリーズシャーシの背面には2組のコネクタがあり、左側のペアにはSlot 10、右側のペアにはSlot 1というラベルが付いています。モニタリング ケーブルが Slot 1 に接続されていることを確認します。これが MSE 8050 シリーズの Supervisor スロットを表すコネクタです。
電源シェルフ モニタリング設定で問題が発生した場合は、次の手順を実行します。
- 問題がケーブルで発生しているかどうかを確認するために、電源シェルフ モニタリング ケーブルをシェルフ A からシェルフ B に切り替えます。ケーブルの問題が解消されない場合は、シスコ テクニカル サポートにお問い合わせください。
- NIC カードが問題の原因かどうかを確認するために、電源シェルフ A と電源シェルフ B の NIC カードを交換します。アラームが再発して、問題が NIC カードで発生している場合は、シスコ テクニカル サポートにお問い合わせください。
次の画像に、電源シェルフの NIC カードを示します。
電力整流器のトラブルシューティング
電力整流器のいずれかで問題が発生する場合もあります。このセクションでは、こうした問題のトラブルシューティング方法について説明します。
整流器が実装されている電源シェルフの前面図を示します。
電源シェルフの背面図を示します。
電力整流器に伴う問題を解決するには、次の手順を実行します。
- 整流器でエラーが発生した場合は、それを実装しなおして、エラーがまだ発生するかどうかを確認します（整流器はホットプラグ可能です）。
- エラーが数分以上続いている場合は、問題が整流器にあるのか電源シェルフのスロットにあるのかを判断するために、整流器を電源シェルフ A または B の別のスロットに実装します。
- それでも問題が解決しない場合は、シスコ テクニカル サポートに連絡して、次の情報を提供してください。
- アラーム状態の整流器の写真
- 整流器のシリアル番号（整流器の右側か左側に記載されている）
- [Power Supplies] ページ（[Hardware] > [Power Supplies]）のスクリーンショット
- [Health] ページ（[Status] > [Health]）のスクリーンショット
- 監査ログ
- アラーム ログ
- イベント ログ
Cisco TelePresence ISDN GW 問題のトラブルシューティング
Cisco Telepresence ISDN GW は、ISDN 経由で完全な機能透明性を示す、IP ネットワークと ISDN ネットワーク間のシームレスな統合を実現します。このセクションでは、DSP 上の ISDN PRI インターフェイスとバッファをトラブルシューティングする方法について説明します。
PRI レイヤ 1 とレイヤ 2 のダウン
このセクションは、ISDN GW 上の PRI インターフェイスの問題をトラブルシューティングする場合に使用します。PRI ポートは、ループバック プラグで確認して、故障しているどうかを判断できます。
- レイヤ 1（L1）は、物理層つまり PRI 接続を示します。
- レイヤ 2（L2）は、シグナリングに使用されます。
ループバック ケーブルを使用して、ISDN GW の PRI ポートの L1 ステータスを特定できます。ピン 1 とピン 4、ピン 2 とピン 5 を接続して、ループバック ケーブルを作成します。
ループバック ケーブルをポート 1 に接続して、L1 ステータスを確認します。ポート 1 の L1 ステータスがループバック ケーブルによって [Up] と表示された場合は、使用されているケーブルで問題が発生している可能性があります。問題を切り分けるために、さらにループバック ケーブルを使用できます。
ポート 1 の L1 ステータスがループバック ケーブルによって [Down] と表示された場合は、ISDN GW 上の PRI 用のポート 2 を有効にします。ループバック ケーブルを使用してポート 2 もテストします。特定のポートで問題が解決されない場合は、PRI ポート障害が発生している可能性があります。シスコ テクニカルサポートへ連絡してください。
Ping Pong エラーと DSP タイムアウト
DSP 上には、Ping と Pong と呼ばれる 2 つのバッファがあります。それぞれのバッファは、一度に 10 ミリ秒のデータ（1 ISDN フレーム）を処理します。この目的は 1 つのバッファを処理しながら、次のバッファを読み込むことです。この 2 つのバッファが同期しなくなった場合は、入れ替わって再度同期しようとします。
ここで、バッファが同期しなくなり、修復を試みている Cisco Telepresence ISDN GW イベント ログの例を示します。
14031 2012/02/29 13:03:05.143 dspapi Warning DSP(05):
"Ping Pong buffer returned to sync 0, 11111111"
14032 2012/02/29 13:03:05.399 dspapi Error DSP(05):
"Ping Pong buffer out of sync 1, 11111111"
14033 2012/02/29 13:03:05.399 dspapi Info DSP(05):
"Attempt to correct Ping Pong buffer sync"
14034 2012/02/29 13:03:05.400 dspapi Warning DSP(05):
"Ping Pong buffer returned to sync 0, 11111111"
14035 2012/02/29 13:03:05.856 dspapi Error DSP(05):
"Ping Pong buffer out of sync 1, 11111111"
14036 2012/02/29 13:03:05.856 dspapi Info DSP(05):
"Attempt to correct Ping Pong buffer sync"
14037 2012/02/29 13:03:05.862 dspapi Warning DSP(05):
"Ping Pong buffer returned to sync 0, 11111111"
14064 2012/02/29 13:03:21.626 dspapi Info DSP(04):
"receive from local primary dsp timeout"
14065 2012/02/29 13:03:21.626 dspapi Info DSP(03):
"receive from local primary dsp timeout"
14066 2012/02/29 13:03:21.638 dspapi Info DSP(15):
"receive from peer primary dsp timeout (rx)"
次に、検討すべき質問を示します。
- バッファが同期しなくなったのはなぜですか。
- 無効なフレーム、故障した ISDN クロック、または信頼できない PRI が問題を引き起こした可能性があります。
次に、収集する情報の一覧を示します。
- この GW に接続されている PRI の数はいくつですか。
- すべての PRI が同じスイッチにつながっていますか、それとも別々のスイッチにつながっていますか。
- すべての PRI を外してシステムをリブートしても、エラーは解消されませんか。これらのエラーを示すコンソール ログを収集します。
- PRI 1 だけが接続されている場合に、エラーが再発しますか。
- PRI 2 だけが接続されている場合に、エラーが再発しますか。一度に 1 つずつ、すべての PRI で繰り返します。
別々のスイッチからの PRI が使用されている場合は、PRI クロックが同期している必要があります（通常は、同じ通信事業者からの PRI です）。1 つのスイッチからの PRI のクロックが他のスイッチ上の PRI のクロックと同期していない可能性があります。1 つの PRI だけが接続されており、正常だと思われる場合は、1 つのスイッチからの 1 つの PRI と別のスイッチからの 1 つの PRI を接続して、システムをリブートし、エラーが再発するかどうかを確認します。必要に応じて、テストと動作を記録し、シスコ テクニカル サポートに提供します。
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
19-Nov-2013 |
初版 |
フィードバック