トラブルシューティング

この章では、システムの動作中に発生する可能性のある問題をトラブルシューティングするために、システムのコマンドラインインターフェイス(CLI)を使用する方法について説明します。

これらのトラブルシューティング手順で対処するハードウェアコンポーネントの包括的な説明については、『 ASR 5500 Installation Guide 』を参照してください。

ハードウェアの不具合の検出

シャーシに電源が投入されている場合、管理 I/O(MIO/UMIO)カード、データ処理カード(DPC/UDPC/DPC2/UDPC2)、ファブリックおよびストレージカード(FCS)、システムステータスカード(SSC)に電源が順次投入されます。

システムに取り付けられている各 PFU とカードには、動作ステータスを示す発光ダイオード(LED)が組み込まれています。この項では、これらのステータス LED を使用して、取り付けられているすべてのコンポーネントが正しく動作していることを確認する方法について説明します。


重要


システムの起動プロセスが進行していても、一部のカードは LED のアクティビティをすぐには表示しません。起動プロセスが開始されてから、さまざまなカード上の LED をチェックして起動プロセスが正常に完了したことを確認できるようになるには、数分かかります。


ライセンスの問題

システム起動プロセスは、StarOS ライセンスによって管理されます。起動プロセス中に、各カードは一連の電源投入時自己診断テスト (POST) を実行して、ハードウェアが動作可能であることを確認します。これらのテストでは、カードがこのシャーシで動作するために、すべてのライセンス要件を満たしていることも確認します。

起動プロセスで有効なライセンスとカードタイプの詳細については、『ASR 5500 Installation Guide』の「Chassis Universal License Requirements」を参照してください。

CLI を使用したステータス LED の表示

すべてのカードのステータス LED は、Exec モードの show led all コマンドを入力することによって、CLI を使用して表示できます。

[local]host_name# show leds all 

次に、このコマンドの出力例を示します。

Slot 01: Run/Fail: Green | Active: Off    | Redundant: Green 
Slot 02: Run/Fail: Green         | Active: Off    | Redundant: Green 
Slot 03: Run/Fail: Green         | Active: Off    | Redundant: Green 
Slot 05: Run/Fail: Green         | Active: Green  | Redundant: Green    Master: Green 
Slot 06: Run/Fail: Green         | Active: Off    | Redundant: Green    Master:Off 
Slot 08: Run/Fail: Green         | Active: Off    | Redundant: Green 
Slot 11: Run/Fail: Green         | Active: Green  | Redundant: Green    Status: Green  | Service: Off  
Slot 12: Run/Fail: Green         | Active: Green  | Redundant: Green    Status: Green  | Service: Off  
Slot 13: Run/Fail: Green         | Active: Green  | Redundant: Green 
Slot 14: Run/Fail: Green         | Active: Green  | Redundant: Green 
Slot 15: Run/Fail: Green         | Active: Green  | Redundant: Green 
Slot 16: Run/Fail: Green         | Active: Green  | Redundant: Green 
Slot 17: Run/Fail: Green         | Active: Green  | Redundant: Green 

Exec モードの show power chassis コマンドを入力することによって、2 つの電源フィルタユニット(PFU)のステータスを表示できます。

PFU 上の LED の確認

各 PFU には、前面パネルの上端に沿って 4 つの LED があります。これらの LED を表示するには、シャーシから上部の前面カバーのスナップを外す必要があります。各 LED は、PFU に接続されている 4 つの -48 VDC のいずれかの給電に関連付けられています。

通常の動作状態では、PFU の各 LED が青に点灯しています。

図 1. PFU LED


次の表で、これらの LED が取り得る状態について説明します。LED が青に点灯していない場合は、次のトラブルシューティング情報を使用して問題を診断してください。
表 1. PFU LED の状態
説明 トラブルシューティング
青色 給電については、この電源プレーンに -48VDC を供給しています。 対処の必要はありません。
なし PFU は、1 つ以上の電源プレーンに電力を供給していません。 各遮断器がオンの位置にあることを確認します。
RTN および -48VDC のラグがシャーシの背面上部の支柱に適切に接続されていることを確認します。
アースラグが適切に接続されていることを確認します。
電圧計を使用して、配電盤が適切な電圧を提供していること、および PFU の背面にある端子に十分な配電があることを確認します。
電源からラックまでのケーブルが導通しているか確認します。
配電フレーム(PDF)とシャーシの間に配電盤(PDP)が取り付けられている場合は、遮断器がオンに設定されていることを確認します。
PDF とシャーシの間に PDP が取り付けられている場合は、PDP からシャーシへのケーブルの導通を確認します。
上記のすべての推奨事項を確認している場合は、PFU が機能していない可能性があります。サービス担当者にお問い合わせください。

MIO カード上の LED の確認

各 MIO/UMIO には、次の LED が装備されています。

  • 実行/障害

  • アクティブ

  • 冗長性

  • マスター

  • ビジー

図 2. MIO カードステータス LED


すべての MIO/UMIO LED で考えられる状態については、次の項で説明します。

MIO 実行/障害 LED の状態

MIO/UMIO の 実行/障害 LED は、カードの全体的なステータスを示します。正常に動作している場合、この LED は安定して緑に点灯しています。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 2. MIO 実行/障害 LED の状態
説明 トラブルシューティング
エラーが検出されていないカードの電源が入っている

対処の必要はありません。

緑に点滅 カードが初期化中またはソフトウェアをロードしている

これは、起動時の正常な動作です。

エラーが検出されたカードに電源が入っている

電源投入時自己診断テスト(POST)時にエラーが検出されました。起動時に、システムのコマンド ライン インターフェイスにエラーが記録されている可能性があります。

なし カードに電源が供給されていない PFU の LED が青に点灯していることを確認します。青に点灯していない場合は、PFU 上の LED の確認 を参照してトラブルシューティング情報を確認してください。
電源がシャーシに十分な電圧と電流を供給していることを確認します。
ASR 5500 Installation Guide』の手順に従って、カードが適切に取り付けられていることを確認します。
上記の推奨事項をすべて確認している場合は、MIO が機能していない可能性があります。サービス担当者にお問い合わせください。

MIO アクティブ LED の状態

MIO/UMIO の アクティブ LED は、ソフトウェアがカードにロードされており、動作可能な状態であることを示しています。シャーシのスロット 5 に取り付けられている MIO の場合、通常の動作ではこの LED が緑に点灯します。スロット 6 に取り付けられている MIO の場合、通常の動作では、この LED は消灯している必要があります。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 3. アクティブ LED の状態
説明 トラブルシューティング
カードはアクティブです スロット 5 の MIO/UMIO には必要ありません。スロット 6 の MIO/UMIO が緑に点灯している場合は、『ASR 5500 Installation Guide』の手順に従って、スロット 5 の MIO/UMIO が正しく取り付けられ、ライセンスが供与されていることを確認します。
緑に点滅 タスクまたはプロセスがアクティブな MIO からスタンバイ MIO に移行中です。 MIO/UMIO およびシステム ソフトウェア プロセスのステータスの確認については、「システムのモニタリング」を参照してください。
なし

カードに電力が供給されていません。

または

カードに障害が発生しています。

実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給され、POST の結果がプラスになります。消灯している場合は、MIO 実行/障害 LED の状態 を参照してトラブルシューティング情報を確認してください。

MIO 冗長性 LED の状態

MIO/UMIO/MIO2 の LED は、ソフトウェアがカードにロードされているが、冗長コンポーネントとして機能していることを示しています。スロット 6 に取り付けられている MIO/UMIO の場合、通常の動作ではこの LED が緑に点灯します。スロット 8 に取り付けられている MIO/UMIO の場合、通常の動作ではこの LED は消灯している必要があります。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 4. MIO 冗長性 LED の状態
説明 トラブルシューティング
カードが冗長モードになっています。 対処の必要はありません。スロット 5 とスロット 6 の MIO/UMIO が緑になっている場合、カードとポートは完全にバックアップされます。
オレンジ カードまたはこのカードのポートは、他の MIO によってバックアップされていません。 他の MIO/UMIO のステータスを確認します。障害が発生した場合、または 1 つ以上のポートがアクティブでなくなった場合、システムは機能を継続できますが、冗長性が損なわれます。
MIO/UMIO およびシステム ソフトウェア プロセスのステータスの確認については、「システムのモニタリング」を参照してください。
オレンジに点滅 タスクまたはプロセスがアクティブな MIO からスタンバイ MIO に移行中です。 MIO/UMIO およびシステム ソフトウェア プロセスのステータスの確認については、「システムのモニタリング」を参照してください。
なし

カードに電力が供給されていません。

または

カードに障害が発生しています。

実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給され、POST の結果がプラスになります。消灯している場合は、MIO 実行/障害 LED の状態を参照してトラブルシューティング情報を確認してください。

MIO マスター LED の状態

MIO/UMIO/MIO2 の LED は、カードがアクティブモードとスタンバイモードのどちらであるかを示します。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、問題を診断するために提供されているトラブルシューティング情報も使用してください。
表 5. MIO マスター LED の状態
説明 トラブルシューティング
このカードはアクティブな MIO です。

対処の必要はありません。

緑に点滅 タスクまたはプロセスがアクティブな MIO からスタンバイ MIO に移行中です。

MIO/UMIO およびシステム ソフトウェア プロセスのステータスの確認については、「システムのモニタリング」を参照してください。

なし

このカードはスタンバイ MIO です。

または

カードに障害が発生しています。

実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給され、POST の結果がプラスになります。消灯している場合は、MIO 実行/障害 LED の状態 を参照してトラブルシューティング情報を確認してください。
MIO/UMIO/mio2 およびシステムソフトウェアプロセスのステータスを確認する方法については」を参照してください。

MIO ビジー LED の状態

MIO/UMIO/MIO2 の LED は、カードが FSC 上の RAID ソリッドステートドライブにアクセスしていることを示します。

ファイルストレージのアクティビティが発生していない場合、この LED は消灯します。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 6. MIO ビジー LED の状態
説明 トラブルシューティング
ファイルは、FSC の RAID 設定との間で転送またはアクセスされています。 対処は不要です。
なし

RAID のアクティビティはありません。

または

RAID 設定は使用できません。

FSC 上の LED の確認

MIO:インターフェイスリンク LED の状態

MIO/UMIO ドーターカード(サブスクライバトラフィック)の 1000Base-T(管理)または10 ギガビット イーサネット ポートに関連付けられているLink LED は、ネットワークリンクのステータスを示します。正常に動作している場合、この LED は緑に点灯しています。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 7. MIO:インターフェイスリンク LED の状態
説明 トラブルシューティング
リンクが確立

対処の必要はありません。

注:この LED は、ソフトウェア設定プロセス中にインターフェイスパラメータが設定されるまで、ネットワークリンクの存在を示すものではありません。

なし

カードに電力が供給されていません。

または

リンクがダウンしています。

実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給されています。消灯している場合は、MIO 実行/障害 LED の状態 を参照してトラブルシューティング情報を確認してください。
インターフェイスが正しく配線されていることを確認します。
インターフェイスが設置されているデバイスがケーブル接続され、適切に電源が供給されていることを確認します。

MIO:インターフェイス アクティビティ LED の状態

MIO/UMIO ドーターカード(サブスクライバトラフィック)の 1000Base-T(管理)または 10 ギガビット イーサネット ポートに関連付けられている Activity LED は、ネットワークリンクにトラフィックが存在することを示します。この LED は、データがインターフェイスを介して送信または受信されるときに緑色になります。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 8. MIO:インターフェイス アクティビティ LED の状態
説明 トラブルシューティング
グリーンで点滅 リンク上にトラフィックが存在します

対処の必要はありません。

なし リンク上にトラフィックが存在しません

リンクにアクティビティがない場合は、何も必要ありません。インターフェイス設定前は、これが通常の動作です。

DPC 上の LED の確認

各 DPC/UDPC または /DPC2/UDPC2 みは、次に示すステータス LED が装備されています。

  • 実行/障害

  • アクティブ

  • 冗長性

図 3. DPC のステータス LED


次の項では、すべての DPC/UDPC または /DPC2/UDPC2 の LED 考えられる状態について説明します。

DPC 実行/障害 LED の状態

DPC/UDPC または /DPC2/UDPC2実行/障害 LED は、カードの全体的なステータスを示します。正常に動作している場合、この LED は緑に点灯しています。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 9. DPC 実行/障害 LED の状態
説明 トラブルシューティング
エラーが検出されていないカードに電源が入っています。 対処の必要はありません。
緑に点滅 カードの初期化中および/またはソフトウェアのロード中です。 これは、起動時の正常な動作です。
エラーが検出されたカードに電源が入っています。 電源投入時自己診断テスト(POST)時にエラーが検出されました。起動時に、システムのコマンド ライン インターフェイスにエラーが記録されている可能性があります。
なし カードに電力が供給されていません。 PFU の LED が青に点灯していることを確認します。青に点灯していない場合は、PFU 上の LED の確認 を参照してトラブルシューティング情報を確認してください。
電源がシャーシに十分な電圧と電流を供給していることを確認します。
『ASR 5500 Installation Guide』の手順に従って、カードが適切に取り付けられ、ライセンスされていることを確認します。
上記のすべての推奨事項が確認されている場合は、DPC/UDPC または /DPC2/UDPC2 が機能していない可能性があります。サービス担当者にお問い合わせください。

DPC アクティブ LED の状態

DDPC/UDPCPC または/DPC2/UDPC2アクティブな LED には、ソフトウェアがカードにロードされており、そのカードが動作可能であることが示されます。システムが最初に起動すると、インストールされているすべての DPC/UDPC または/DPC2/UDPC2 がスタンバイモードで起動します。次に、DPC/UDPC または /DPC2/UDPC2s が冗長コンポーネントとして機能するか(スタンバイモードを維持)や、アクティブなコンポーネントとして機能するかについて設定する必要があります。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 10. DPC アクティブ LED の状態
説明 トラブルシューティング
カードはアクティブです。 システムに初めて電源を投入するときは、すべての DPC/UDPC または /DPC2/UDPC2 をスタンバイモードで起動する必要があります。したがって、この LED は消灯しています。
緑に点滅 タスクまたはプロセスは、アクティブ DPC からスタンバイ DPC への移行中です。 スタンバイ DPC/UDPC または/DPC2/UDPC2冗長性 LED も緑に点滅していることを確認します。緑に点滅している場合は、アクティブ DPC/UDPC または /DPC2/UDPC2 に問題があり、そのプロセスを転送しています。
DPC/UDPCまたは /DPC2/UDPC2 とシステムソフトウェアのプロセスおよび機能のステータスを確認する方法については、「システムのモニタリング」を参照してください。
なし

カードに電力が供給されていません。

または

カードはスタンバイモードになっています。

実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給され、POST の結果がプラスになります。消灯している場合は、DPC 実行/障害 LED の状態 を参照してトラブルシューティング情報を確認してください。
冗長性 LED の状態を確認します。緑に点灯している場合、カードはスタンバイモードになっています。これは、初期電源投入時の正常な動作です。必要に応じて、カードをアクティブにする方法の詳細については、「システム設定」の「DPC の可用性の設定」の項を参照してください。

DPC 冗長性 LED の状態

DPC/UDPC または /DPC2/UDPC2冗長性 LED は、ソフトウェアがカードにロードされているが、スタンバイコンポーネントとして機能していることを示します。DPC/UDPC または/DPC2/UDPC2 は n:1 の冗長性をサポートしています。冗長性 LED は、正常にシステムが動作している場合に、DPC/UDPC または/DPC2/UDPC2 の 1 つのみが緑で点灯しています。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 11. DPC 冗長性 LED の状態
説明 トラブルシューティング
カードはスタンバイモードになっています。 対処の必要はありません。少なくとも 1 つの DPC/UDPC または/DPC2/UDPC2 がスタンバイモードになっています。
オレンジ カードはスタンバイ DPC によってバックアップされていません。 他の DPC/UDPC または/DPC2/UDPC2 のステータスを確認します。1 つの DPC/UDPC または/DPC2/UDPC2 に障害が発生したか、またはシャーシから取り外された場合、システムは機能し続けることはできますが、冗長性は損なわれます。
DPC/UDPC または/DPC2/UDPC2 とシステム ソフトウェア プロセスのステータスの確認については、「システムのモニタリング」を参照してください。
オレンジに点滅 アクティブな DPC からスタンバイ DPC に移行されるタスクまたはプロセス。 DPC/UDPC または/DPC2/UDPC2 とシステム ソフトウェア プロセスのステータスの確認については、「システムのモニタリング」を参照してください。
なし

カードに電力が供給されていません。

または

カードに障害が発生しています。

実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給され、POST の結果がプラスになります。消灯している場合は、DPC 実行/障害 LED の状態 を参照してトラブルシューティング情報を確認してください。

FSC 上の LED の確認

各 FSC には、添付図に示すように、次の LED が装備されています。

  • 実行/障害

  • アクティブ

  • 冗長性

  • ドライブ 1 アクティビティ

  • ドライブ 2 アクティビティ

図 4. FSC のステータス LED


すべての FSC LED で考えられる状態については、次の項で説明します。

FSC 実行/障害 LED の状態

FSC の実行/障害 LED は、カードの全体的なステータスを示します。正常に動作している場合、この LED は緑に点灯しています。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 12. FSC 実行/障害 LED の状態
説明 トラブルシューティング
エラーが検出されていないカードの電源が入っている 対処の必要はありません。
緑に点滅 カードが初期化中またはソフトウェアをロードしている これは、起動時の正常な動作です。
エラーが検出されたカードに電源が入っている 電源投入時自己診断テスト(POST)時にエラーが検出されました。起動時に、システムのコマンド ライン インターフェイスにエラーが記録されている可能性があります。
なし カードに電源が供給されていない PFU の LED が青に点灯していることを確認します。青に点灯していない場合は、PFU 上の LED の確認 を参照してトラブルシューティング情報を確認してください。
電源がシャーシに十分な電圧と電流を供給していることを確認します。
ASR 5500 Installation Guide』の手順に従って、カードが適切に取り付けられていることを確認します。
上記の推奨事項をすべて確認している場合は、FSC が機能していない可能性があります。サービス担当者にお問い合わせください。

FSC アクティブ LED の状態

FSC のアクティブ LED は、カードにソフトウェアがロードされていること、およびカードが動作可能な状態になっていることを示しています。システムが最初に起動すると、インストールされているすべての FSC が準備モードで起動します。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 13. FSC アクティブ LED の状態
説明 トラブルシューティング
カードはアクティブです。

システムに初めて電源が投入されたときに、すべての FSC を準備モードで起動する必要があります。したがって、この LED は点灯しています。

緑に点滅 アクティブ FSC からスタンバイ FSC に移行されるタスクまたはプロセス。 スタンバイ FSC の冗長性 LED も緑に点滅していることを確認します。緑に点滅している場合は、アクティブ FSC に問題があり、そのプロセスを転送しています。
FSC およびシステムソフトウェアのプロセスと機能のステータスを確認する方法については、「システムのモニタリング」を参照してください。
なし

カードに電力が供給されていません。

または

カードはスタンバイモードになっています。

実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給され、POST の結果がプラスになります。消灯している場合は、FSC 実行/障害 LED の状態 を参照してトラブルシューティング情報を確認してください。
冗長性 LED の状態を確認します。緑に点灯している場合、カードはスタンバイモードになっています。

FSC 冗長性 LED の状態

FSC の冗長性 LED は、ソフトウェアがカードにロードされているが、冗長コンポーネントとして機能していることを示しています。FSC は n+1 冗長性をサポートします。通常のシステム動作では、冗長 LED は 1 つの FSC でのみ緑である必要があります。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 14. FSC 冗長性 LED の状態
説明 トラブルシューティング
カードが冗長モードになっています。

対処の必要はありません。スタンバイモードには少なくとも 1 つの FSC があります。

オレンジ カードはスタンバイ FSC によってバックアップされていません。 もう一方の FSC のステータスを確認します。1 つの FSC に障害が発生した場合、またはシャーシから取り外された場合、システムは機能を継続できますが、冗長性が損なわれます。
FSC およびシステム ソフトウェア プロセスのステータスの確認については、「システムのモニタリング」を参照してください。
オレンジに点滅 アクティブ FSC からスタンバイ FSC に移行されるタスクまたはプロセス。

FSC およびシステム ソフトウェア プロセスのステータスの確認については、「システムのモニタリング」を参照してください。

なし

カードに電力が供給されていません。

または

カードに障害が発生しています。

実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給され、POST の結果がプラスになります。消灯している場合は、FSC 実行/障害 LED の状態 を参照してトラブルシューティング情報を確認してください。

FSC ドライブ n アクティビティ LED の状態

FSC のドライブ 1 のアクティビティ LED とドライブ 2 のアクティビティ LED は、RAID ソリッド ステート ドライブ(SSD)が MIO によってアクセスされていることを示しています。各 FSC のドライブ 1 とドライブ 2 は、RAID 0 の設定を形成します。


重要


FSC-400GB には、単一の 400 GB のドライブが搭載されています。ドライブ 1 のアクティビティ LED のみがアクティブになります。ドライブ 2 のアクティビティ LED は常にオフ(なし)になります。


次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、問題を診断するために提供されているトラブルシューティング情報も使用してください。
表 15. FSC ドライブ n アクティビティ LED の状態
説明 トラブルシューティング
ファイルは、MIO によって RAID 設定との間で転送またはアクセスされます。 対処は不要です。
なし

RAID アクティビティはありません。

または

RAID 設定は使用できません。

MIO カード上の LED の確認

FSC-400GB には、2 番目の SDD が搭載されていません。ドライブ 1 のアクティビティ LED のみがアクティブになります。

なし カードに電源が供給されていない 実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給され、POST の結果がプラスになります。消灯している場合は、FSC 実行/障害 LED の状態 を参照してトラブルシューティング情報を確認してください。

SSC 上の LED の確認

各 SSC には、添付図に示すように、次の LED が装備されています。

  • 実行/障害

  • アクティブ

  • 冗長性

  • システムステータス

  • システム サービス

図 5. SSC のステータス LED


すべての SSC LED で考えられる状態については、次の項で説明します。

SSC 実行/障害 LED の状態

SSC の 実行/障害 LED は、カードの全体的なステータスを示します。正常に動作している場合、この LED は緑に点灯しています。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 16. SSC 実行/障害 LED の状態
説明 トラブルシューティング
エラーが検出されていないカードの電源が入っている 対処の必要はありません。
緑に点滅 カードが初期化中またはソフトウェアをロードしている これは、起動時の正常な動作です。
エラーが検出されたカードに電源が入っている 電源投入時自己診断テスト(POST)時にエラーが検出されました。起動時に、システムのコマンド ライン インターフェイスにエラーが記録されている可能性があります。
なし カードに電源が供給されていない PFU の LED が青に点灯していることを確認します。青に点灯していない場合は、PFU 上の LED の確認 を参照してトラブルシューティング情報を確認してください。
電源がシャーシに十分な電圧と電流を供給していることを確認します。
ASR 5500 Installation Guide』の手順に従って、カードが適切に取り付けられていることを確認します。
上記の推奨事項をすべて確認している場合は、SSC が機能していない可能性があります。サービス担当者にお問い合わせください。

SSC アクティブ LED の状態

SSC のアクティブ LED は、カードにソフトウェアがロードされていること、およびカードが動作可能な状態になっていることを示しています。システムが最初に起動すると、両方の SSC が準備モードで起動します。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。

表 17. SSC アクティブ LED の状態
説明 トラブルシューティング
カードはアクティブです。

システムに初めて電源が投入されたときに、両方の SSC を準備モードで起動する必要があります。したがって、この LED は点灯しています。

緑に点滅 アクティブ FSC からスタンバイ FSC に移行されるタスクまたはプロセス。 スタンバイ SSC の冗長性 LED も緑に点滅していることを確認します。その場合は、アクティブ SSC に問題があり、そのプロセスを転送しています。
SSC およびシステムソフトウェアのプロセスと機能のステータスを確認する方法については、「システムのモニタリング」を参照してください。
なし

カードに電力が供給されていません。

または

カードはスタンバイモードになっています。

実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給され、POST の結果がプラスになります。オフになっている場合は、「SSC の実行/障害 LED の状態」の項を参照して、トラブルシューティング情報を確認してください。
冗長性 LED の状態を確認します。緑に点灯している場合、カードはスタンバイモードになっています。

SSC 冗長性 LED の状態

SSC の冗長性 LED は、ソフトウェアがカードにロードされていても、スタンバイコンポーネントとして機能していることを示します。SSC は 1:1 の冗長性をサポートしています。システムの動作が正常の場合は、別の SSC の冗長性 LED は緑に点灯しているはずです。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 18. SSC 冗長性 LED の状態
説明 トラブルシューティング
カードはスタンバイモードになっています。

対処の必要はありません。もう一方の SSC がスタンバイモードになっている必要があります。

オレンジ カードはスタンバイ SSC によってバックアップされません。 もう一方の SSC のステータスを確認します。一方に障害が発生した場合、または一方がシャーシから取り外された場合も、システムは機能し続けますが、冗長性は損なわれます。
SSC およびシステム ソフトウェア プロセスのステータスの確認については、「システムのモニタリング」を参照してください。
オレンジに点滅 タスクまたはプロセスがアクティブな SSC からスタンバイ SSC に移行中です。 SSC およびシステム ソフトウェア プロセスのステータスの確認については、「システムのモニタリング」を参照してください。
なし

カードに電力が供給されていません。

または

カードに障害が発生しています。

実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給され、POST の結果がプラスになります。オフになっている場合は、「SSC の実行/障害 LED の状態」の項を参照して、トラブルシューティング情報を確認してください。

SSC システムステータス LED の状態

SSC のシステムステータス LED は、システムのどこかでサービスが失われていることを示しています。この LED が赤に点灯している場合、システムはメンテナンスまたはサービスを必要とします(たとえば、システムが起動時に有効なソフトウェアイメージを見つけられなかったか、高温状態になっている可能性があります)。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、問題を診断するために提供されているトラブルシューティング情報も使用してください。
表 19. SSC システムステータス LED 状態 11
説明 トラブルシューティング
システムは正常に動作しています 対処は不要です。
システムでサービスの損失が発生しました。 システムハードウェアとソフトウェアプロセスのステータスの確認については、「システムのモニタリング」を参照してください。
なし カードに電源が供給されていない 実行/障害 LED が緑に点灯していることを確認します。緑に点灯している場合は、カードに電力が供給され、POST の結果がプラスになります。オフになっている場合は、「SSC の実行/障害 LED の状態」の項を参照して、トラブルシューティング情報を確認してください。

SSC システムサービス LED の状態

SSC のシステムサービス LED がオレンジに点灯し、システムでハードウェアコンポーネントの障害が発生していることを示します。

この LED は、通常の運用では消灯しています。

次の表で、この LED が取り得る状態について説明します。LED が緑に点灯していない場合は、表のトラブルシューティング情報を参照して問題を診断してください。
表 20. SSC システムサービス LED の状態 12
説明 トラブルシューティング
オレンジ システムには、メンテナンス(ファンフィルタ、温度警告、PFU 停止など)が必要です。 Show コマンドのシステムをモニタリングします。その出力は、問題をさらに特定するために役立ちます。
ログを表示する方法については、「システムログ」を参照してください。
なし

コンポーネントの障害は検出されませんでした。

または

カードに電力が供給されていません。

メンテナンスは必要ありません。

テストシステムのアラーム出力

システムには、次の 2 つの物理アラームメカニズムが用意されています。
  • システムの可聴アラーム:SSC に設置されているスピーカーは、マイナー、メジャー、またはクリティカルのアラームが発生したことを示す可聴インジケータを提供するために使用されます。

  • CO アラームインターフェイス:SSC に配置されているこのインターフェイスには、外部音声および/またはビジュアルインジケータのトリガーとして 3 つのドライコンタクトリレー(Form C)を有効にする DB-15 コネクタが用意されています。これらのインジケータは、マイナー、メジャー、またはクリティカルなアラームのいずれかの発生を警告するために使用できます。

これらのアラームの動作は、次のコマンドを発行することでテストできます。
[local]host_name# test alarm { audible | central-office [ critical | major | minor ] } 

このコマンドを実行すると、指定したアラームが 10 秒間アクティブになります。この時間が経過すると、アラームは前の状態に戻ります。

修正処置の実施

インストールされているアプリケーションまたはラインカードで問題が検出された場合は、シビラティ(重大度)に応じて修正措置を実行する必要があります。

システムのダウンタイムとデータ損失を最小限に抑えるために、アプリケーションおよびラインカードの問題に対処するための冗長性とフェールオーバーのメカニズムが提供されます。これらのメカニズムについては、以降のセクションで説明します。

MIO のスイッチング

システムが起動すると、シャーシスロット 5 に取り付けられている MIO/UMIO がアクティブモードで起動し、他のシステムコンポーネントの起動が開始されます。シャーシスロット 6 に取り付けられている MIO/UMIO は、冗長コンポーネントとして機能することを示すスタンバイモードで自動的に起動します。アクティブな MIO/UMIO は、現在実行中のタスクまたはプロセスをスタンバイ MIO/UMIOと自動的に同期します。

スロット 5の MIO/UMIO クリティカルな障害が発生した場合、システム制御によってスロット 6 のスタンバイ MIO/UMIO に自動的に切り替えられます。この 2 つは同期されているため、比較的シームレスに移行されます。以前にアクティブだった MIO がスタンバイモードに入り、安全に置換または復元できます。

システムが自動的にスイッチオーバーを実行するほど重大ではない問題が発生した場合は、Exec モードのプロンプトから次のコマンドを実行することで、手動スイッチオーバーを呼び出すことができます。

手順


ステップ 1

次のコマンドを入力して、手動の MIO/UMIO スイッチオーバーを開始します。

[local]host_name# card switch from <5 or 6> to <6 or 5>  

次のプロンプトが表示されます。

Are You Sure? [Yes|No]: 

ステップ 2

Y を押してスイッチオーバーを開始します。

ステップ 3

Exec モードプロンプトで show card table コマンドを入力し、スイッチオーバーが正常に行われたことを確認します。

切り替えた MIO/UMIO の横にある [Oper State] 列のエントリを確認します。状態は [Standby] である必要があります。


DPC のビジーアウト

この busy-out コマンドは、送信元 DPC/UDPC または DPC2/UDPC2 から接続先 DPC/UDPC または DPC2/UDPC2 へプロセスを移動するか、または DPC/UDPC またはDPC2/UDPC2 が新しいコールを受け入れられないようにします。ビジーアウトが有効になっている場合、DPC/UDPC または DPC2/UDPC2 は、新しいコールの受信を停止しますが、完了するまでコールの処理を続行します。コマンドが開始されると、コマンドプロンプトが返されます。ビジーアウトの手順はバックグラウンドで完了します。

手順


ステップ 1

次のコマンドを入力して、ビジーアウトを開始します。

[local]host_name# card busy-out slot_number 

次のプロンプトが表示されます。

Are You Sure? [Yes|No]: 

ステップ 2

Y を押してスイッチオーバーを開始します。

ステップ 3

Exec モードプロンプトで show card table コマンドを入力し、ビジーアウトが正常に行われたことを確認します。

ビジーアウトした DPC/UDPC または DPC2/UDPC2 の横にある [Oper State] 列のエントリを確認します。状態は [Standby] である必要があります。


DPC の移行

システムが起動すると、すべての DPC/UDPC または DPC2/UDPC2 は「スタンバイ」モードに入ります。スタンバイモードは、カードが使用可能であるが、動作用に設定されていないことを示します。インストールされたコンポーネントは、ソフトウェアの設定プロセスを通じてアクティブにすることができます。「アクティブ」モードを開始するように設定されていないカードは、冗長コンポーネントとして使用するためにスタンバイモードのままになります。

DPC/UDPC または DPC2/UDPC2 に重大な障害が発生した場合は、タスクはアクティブカードからスタンバイモードの冗長カードに自動的に移行されます。

システムが自動移行を実行するほど深刻ではない問題が発生した場合は、手動移行を開始できます。DPC/UDPC または DPC2/UDPC2 の移行を手動で開始するには、次の手順に従います。これらの手順は、Exec モードのルートプロンプトに表示されることを前提としています。

手順


ステップ 1

次のコマンドを入力して、DPC/UDPC または DPC2/UDPC2 の移行を開始します。

[local]host_name# card migration from original_slot# to final_slot# 

次のプロンプトが表示されます。

Are You Sure? [Yes|No]: 

ステップ 2

移行を開始するには、Y を押します。

ステップ 3

Exec モードのプロンプトで show card table コマンドを入力して、移行が成功したことを確認します。

移行したばかりのパケット処理カードの横にある [Oper State] 列のエントリを確認します。状態は [Standby] である必要があります。移行先のパケット処理カードの状態は[Active] である必要があります。

計画されたリカバリ(移行)統計情報を確認するには、show rct stats verbose コマンドを使用します。


FSC スイッチオーバーの手動による起動

FSC は n + 1 の冗長性を得るように設定されています。アクティブ FSC に障害が発生すると、スタンバイ FSC への自動スイッチオーバーが行われます。スイッチオーバーを開始する前に、少なくとも 1 つの FSC をスタンバイモードにする必要があります。

システムが自動スイッチオーバーを実行するほど重大ではない問題が発生した場合は、手動によるスイッチオーバーを実行できます。FSC のスイッチオーバーを手動で開始するには、次の手順を実行します。これらの手順は、Exec モードのルートプロンプトに表示されることを前提としています。

手順


ステップ 1

次のコマンドを入力して手動による FSC スイッチオーバーを開始します。

[local]host_name# card switch from slot# to slot#  
次のプロンプトが表示されます。
Are You Sure&quest; [Yes|No]: 

ステップ 2

Y を押し、スイッチオーバーを開始します。

ステップ 3

Exec モードプロンプトで show card table コマンドを入力して、移行が成功したことを確認します。

切り替えた FSC の横にある [Oper State] 列のエントリを確認します。状態は [Standby] である必要があります。FSC が切り替わった後の状態は [Active] である必要があります。

カードの停止

アクティブまたはスタンバイのいずれかのモードの MIO/UMIO 以外のカードは停止できます。これらのカードを停止すると、それらは「オフライン」モードになります。このモードでは、カードはアクティブまたは冗長コンポーネントとしてセッション処理に使用できません。

アクティブモードのカードが停止している場合は、オフラインモードになる前に、タスク、プロセス、またはネットワーク接続が移行されるか、または冗長コンポーネントに切り替えられます。

この項では、カードの停止を開始し、停止したコンポーネントを復元する方法について説明します。

カード停止の開始


重要


システム内のアクティブな FSC が 2 つ未満の場合は、アクティブな FSC に対してカードの停止を開始しないでください。アクティブな FSC が 2 つ未満の場合、システムはエラーメッセージを返します。アクティブな FSC でカードのリブートまたはカードのアップグレードコマンドを実行する場合は、同様の制限があります。詳細については、『Command Line Interface Reference』を参照してください。


カードの停止を手動で開始するには、次の手順を実行します。これらの手順は、Exec モードのルートプロンプトに表示されることを前提としています。

手順

ステップ 1

次のコマンドを入力して手動によるカードの移行を開始します。

[local]host_name# card halt slot# 

スロット番号は、停止するカードが装着されるシャーシスロットの番号を意味します。1 ~ 4、7 ~ 18 の任意の整数を指定できます。次のプロンプトが表示されます。

Are You Sure? [Yes|No]: 

ステップ 2

Y を押して、停止操作を開始します。

ステップ 3

Exec モードプロンプトで show card table コマンドを入力して、移行が成功したことを確認します。

停止したカードの横にある [Oper State] 列のエントリを確認します。状態はオフラインである必要があります。このコマンドを実行する前にカードがアクティブモードになっていた場合、そのカードに関連付けられている冗長コンポーネントの状態はアクティブになります。


停止していたカードの復元

以前に停止したカードを復元するには、次の手順に従います。これらの手順は、Exec モードのルートプロンプトに表示されることを前提としています。

手順

ステップ 1

次のコマンドを入力して、復元するカードを再起動します。

[local]host_name# card reboot slot# -force 

次のプロンプトが表示されます。

Are You Sure? [Yes|No]: 

ステップ 2

[Y] を押してカードの再起動を開始します。

ステップ 3

プロンプトでshow card table コマンドを入力して、移行が成功したことを確認します。

復元したばかりのカードの横にある [Oper State] 列のエントリを確認します。その状態は、停止される前の状態である必要があります。


ネットワーク接続の確認

システムでサポートされているコマンドは複数あり、ネットワーク接続の確認やトラブルシュートを行うことができます。ネットワーク接続は、システムインターフェイスとポートが設定され、バインドされている場合にのみテストできることに注意してください。

このセクションで指定するコマンドは、コンテキストごとに発行する必要があります。コンテキストは、他のコンテキストとは独立して動作するバーチャル プライベート ネットワーク(VPN)のように機能します。あるコンテキストで設定されたポート、インターフェイス、およびルートは、追加の設定なしで別のコンテキストからテストすることはできません。

コンテキストを切り替えるには、Exec モードのルートプロンプトで次のコマンドを入力します。
[local]host_name# context context_name 
context_name は、切り替え先のコンテキストの名前です。次のプロンプトが表示されます。
[context_name]host_name# 

ping コマンド または ping6 コマンドの使用

ping または ping6 コマンドは、応答間でデータパケットを受け渡し、測定することによって、ネットワーク内のリモートノードとシステムが通信できることを確認します。このコマンドは、ネットワークルーティングを確認したり、リモートノードが IP レイヤで応答できるかどうかを確認するのに役立ちます。

構文

ping のコマンドシンタックスは、次のとおりです。

ping host_ipv4_address [ count num_packets ] [ flood ] [ pattern packet_pattern ] [ size octet_count ] [ src { src_host_name | src_host_ipv4_address } ] [ vrf vrf_nam ] 
ping6 host_ipv6_address [ count num_packets ] [ flood ][ pattern packet_pattern ] [ size octet_count ] [ src { src_host_name | src_host_ipv6_address } ] [ vrf vrf_nam ] 

上記のコマンドの詳細については、『Command Line Interface Reference』の「Exec Mode Commands」の章を参照してください。

次に、成功した ping(IPV4)の応答の例を示します。

PING 209.165.200.227 (209.165.200.227): 56 data bytes 
64 bytes from 209.165.200.227: icmp_seq=0 ttl=255 time=0.4 ms 
64 bytes from 209.165.200.227: icmp_seq=1 ttl=255 time=0.2 ms 
64 bytes from 209.165.200.227: icmp_seq=2 ttl=255 time=0.2 ms 
64 bytes from 209.165.200.227: icmp_seq=3 ttl=255 time=0.2 ms 
64 bytes from 209.165.200.227: icmp_seq=4 ttl=255 time=0.2 ms 
--- 209.165.200.227 ping statistics --- 
5 packets transmitted, 5 packets received, 0% packet loss 
round-trip min/avg/max = 0.2/0.2/0.4 ms 

トラブルシューティング

ターゲットから応答を受信しない場合は、次のトラブルシューティング手順に従ってください。

  • 正しい IP アドレスが入力されていることを確認します。

  • 同じネットワーク上の別のデバイスに ping を試行します。ping が成功した場合は、システム設定が正しいと思われます。ping を実行しようとしているデバイスの電源が入っており、正常に機能していることを確認します。

  • ポートが動作していることを確認します。

  • コンテキスト内のポートとインターフェイスの設定が正しいことを確認します。

  • 設定が正しく、ping を試行しているデバイスにアクセスできる場合は、そのデバイスからシステムに ping を実行します。

  • まだ応答がない場合は、パケットがネットワークデバイスによって破棄されている可能性があります。この章で説明されている traceroute コマンドまたは traceroute6 コマンドおよび show ip static-route コマンドを使用して、この問題のトラブルシュートを行います。

traceroute または traceroute6 コマンドの使用

traceroute コマンドまたは traceroute6 コマンドは、指定されたホストに送信されるルートデータに関する情報を収集します。これは、ネットワーク上の重大なパケット遅延またはパケット損失の原因を特定するために使用できる、便利なトラブルシューティング コマンドです。また、このコマンドは、ネットワークを介したデータのルーティングのボトルボトルネックを識別するためにも使用できます。

traceroute:IPv4

次に、traceroute コマンドシンタックスを示します。

traceroute { host_name | host_ipv4_address } [ count packets ] [ df ]  [ maxttl max_ttl ] [ minttl min_ttl ] [ port port_number ] [ size octet_count ] [ src { src_host_name | src_host_ipv4_address }  ]  [ timeout seconds ] [ vrf vrf_nam ] 

上記のコマンドの詳細については、『Command Line Interface Reference』の「Exec Mode Commands」の章を参照してください。

次に、出力例を示します。

traceroute to 209.165.200.227 (209.165.200.227), 30 hops max, 40 byte packets 
 1  209.165.200.227 (209.165.200.227)  0.446 ms  0.235 ms  0.178 ms 

traceroute6:IPv6

次に、traceroute6 コマンドのシンタックスを示します。

traceroute6 { host_name | host_ipv6_address } [ count packets ]  [ maxttl max_ttl ] [ port port_number ] [ size octet_count ] [ src { src_host_name | src_host_ipv6_address }  ]  [ timeout seconds ] [ vrf vrf_nam ] 

上記のコマンドの詳細については、『Command Line Interface Reference』の「Exec Mode Commands」の章を参照してください。

次に、出力例を示します。

traceroute6 to 2001:4A2B::1f3F (2001:4A2B::1f3F), 30 hops max, 40 byte packets 
 1  2001:4A2B::1f3F (2001:4A2B::1f3F)  0.446 ms  0.235 ms 0.178 ms 

IP ルートの表示

このシステムには、特定のノードへのルート情報またはコンテキスト全体を表示するメカニズムが備わっています。この情報を使用して、ネットワーク接続を確認し、ネットワーク接続の効率を高めることができます。コマンドの構文は、次のとおりです。

show ip route [ route_ip_address ] 
show ipv6 route [ route_ipv6_address ] ] 

上記のコマンドの詳細については、『Command Line Interface Reference』の「Exec Mode show Commands」の章を参照してください。

キーワードを指定しなかった場合は、コンテキストのルーティングテーブル内のすべての IP ルートが表示されます。

次に、コンテキスト IPv4 ルーティングテーブルが示されているこのコマンドの出力例を示します。

"*" indicates the Best or Used route. 
  Destination     Nexthop     Protocol    Prec    Cost    Interface 
*0.0.0.0/0        10.0.4.1    static      0       0       SPIO1 
*10.0.4.0/24      0.0.0.0     kernel      0       0       SPIO1 
*10.0.4.0/32      0.0.0.0     kernel      0       0       SPIO1 
*10.0.4.3/32      0.0.0.0     kernel      0       0       SPIO1 
*10.0.4.255/32    0.0.0.0     kernel      0       0       SPIO1 

アドレス解決プロトコルテーブルの表示

システムは、特定のノードまたはコンテキスト全体に対して、Address Resolution Protocol(ARP)のテーブル情報を表示するメカニズムを提供します。この情報は、システムが ARP パケットを送信したときに、他のネットワークノードから有効な応答を受信したことを確認するために使用できます。

[local]host_name# show ip arp [ arp_ip_address ] 

arp_ip_address は、ARP 情報を表示する特定のネットワークノードを指定します。このアドレスは、IPv4 ドット付き 10 進表記または IPv6 コロン区切り 16 進表記で入力できます。このキーワードが指定されていない場合は、コンテキストの ARP テーブル内のすべてのエントリが表示されます。


重要


VPN マネージャを再起動すると、カーネルからすべてのインターフェイスが削除されます。これにより、すべての ARP エントリが削除されます。ただし、NPU では、トラフィックが中断されないように、すべての ARP エントリが引き続き保持されます。ユーザーの観点から、このコマンドは NPU ではなくカーネルから情報を収集するため、show ip arp が破損しています。


次に、コンテキストの ARP テーブルを表示するこのコマンドの出力例を示します。

Flags codes: 
C - Completed, M - Permanent, P - Published, ! - Not answered 
T - has requested trailers 
Address         Link Type    Link Address          Flags    Mask Interface 
10.0.4.240      ether        00:05:47:02:20:20     C        MIO1 
10.0.4.7        ether        00:05:47:02:03:36     C        MIO1 
10.0.4.1        ether        00:01:30:F2:7F:00     C        MIO1 

システム診断ユーティリティの使用

システムには、設定のトラブルシューティングや確認の際に役立つプロトコルモニターとテストユーティリティが備わっています。これらのユーティリティによって生成される情報は、ソフトウェやネットワーク設定の問題の根本原因を特定するのに便利です。

この項では、これらのユーティリティの使用方法について説明します。


重要


この章で説明する診断ユーティリティは、オペレータ以上の権限を持つ管理者のみが実行できます。


モニターユーティリティの使用

システムにはトラブルシューティングを目的としたプロトコル モニタリング ユーティリティが用意されています。このツールは、特定のサブスクライバセッションか、または処理中のすべてのセッションのプロトコル情報を表示します。


注意    


モニターツールによって、セッションの処理遅延やデータ損失が発生する場合があります。したがって、トラブルシューティングを行う場合にのみ使用してください。


プロトコルモニターの使用

プロトコルモニターには、現在処理中のすべてのセッションの情報が表示されます。モニター対象のプロトコルの数と進行中のセッション数に応じて、大量のデータが生成されます。生成されたすべての情報をキャプチャするには、端末クライアントでロギングを有効にすることを強くお勧めします。

monitor protocol コマンドおよび monitor subscriber コマンドの PCAP 機能を有効にするには、パケットキャプチャ(PCAP)トレース も参照してください。

プロトコル モニタリング ツールを起動して設定するには、次の手順に従います。

手順


ステップ 1

monitor protocol コマンドを入力して、Exec モードでプロトコルモニターを起動します。

[local]host_name# monitor protocol 
現在使用可能なすべてのプロトコル(それぞれに割り当てられた番号を持つ)が一覧表示された出力が表示されます。

ステップ 2

Select: プロンプトで関連付けられた番号を入力して、モニターするプロトコルを選択します。選択したプロトコルの横に右矢印(>)が表示されます。

ステップ 3

必要に応じてステップ 2 を繰り返して、複数のプロトコルを選択します。

ステップ 4

B を押して、プロトコルモニターを開始します。

WARNING!!! You have selected options that can DISRUPT USER SERVICE 
Existing CALLS MAY BE DROPPED and/or new CALLS MAY FAIL!!! 
(Under heavy call load, some debugging output may not be displayed) 
Proceed? - Select (Y)es or (N)o 

ステップ 5

Y を入力してモニターを続行するか、N を入力して前のメニューに戻ります。

C - Control Events    (ON ) 
D - Data Events               (ON ) 
E - EventID Info              (ON ) 
H - Display ethernet          (ON ) 
I - Inbound Events            (ON ) 
O - Outbound Events           (ON ) 
S - Sender Info               (OFF) 
T - Timestamps                (ON ) 
X - PDU Hexdump               (OFF) 
A - PDU Hex/Ascii             (OFF) 
+/- Verbosity Level           (    1) 
L - Limit Context             (OFF) 
M - Match Newcalls            (ON ) 
R - RADIUS Dict               (no-override) 
G - GTPP Dict                 (no-override) 
Y - Multi-Call Trace          ((OFF)) 
      (Q)uit,      <ESC> Prev Menu,      <SPACE> Pause,      <ENTER> Re-Display Options 

ステップ 6

モニターによって表示される情報の量を設定します。オプションを有効化または無効化するには、そのオプションに関連付けられている文字(C、D、E など)を入力します。冗長性を向上または低下させるには、プラス(+)またはマイナス(-)キーを使用します。

各オプションの右側には、[ON (enabled)] または [OFF (disabled)] の現在の状態が表示されます。

ステップ 7

[Enter] キーを押して画面を更新し、モニタリングを開始します。


モニターは、無効になるまでアクティブのままになります。プロトコルモニターを終了してプロンプトに戻るには、q を押します。

特定サブスクライバのプロトコルモニターの使用

プロトコルモニターは、現在処理中の特定のサブスクライバセッションの情報を表示するために使用できます。モニター対象のプロトコルの数と進行中のセッション数に応じて、大量のデータが生成されます。生成されたすべての情報をキャプチャするには、端末クライアントでロギングを有効にすることを強くお勧めします。

特定のサブスクライバセッションのプロトコル モニタリング ツールを起動して設定するには、この項の手順に従います。

手順

ステップ 1

Exec モードからセッション固有のプロトコルモニターを起動するには、monitor subscriber コマンドを入力します。

[local]host_name# monitor subscriber { callid | imei | imsi | ipaddr | ipv6addr | msid | msisdn | next-call | pcf | peer-fa | peer-lac | sgsn-address | type | username } 

ステップ 2

適切なキーワードを入力して、モニターが使用するメソッドを指定します。

ステップ 3

その他のオプションを選択したり、選択したキーワードに適切な情報を入力したりします。

モニターの起動時に、指定された基準に一致するセッションが処理されなかった場合は、使用可能なモニタリングオプションの画面が表示されます。

ステップ 4

モニターによって表示される情報の量を設定します。オプションを有効または無効にするには、そのオプションに関連付けられている文字または 2 桁の数字(C、D、E、11、12 など)を入力します。冗長性を向上または低下させるには、プラス(+)またはマイナス(-)キーを使用します。

各オプションの右側には、[ON (enabled)] または [OFF (disabled)] の現在の状態が表示されます。

マルチコールトレースを実行するためのオプション Y は、GGSN での使用に対してのみサポートされています。

ステップ 5

必要に応じてステップ 6 を繰り返して、複数のプロトコルを有効または無効にします。

ステップ 6

Enter を押して画面を更新し、モニタリングを開始します

次に、user2@aaa という名前のサブスクライバに対するモニターの出力例の一部を示します。デフォルトのプロトコルがモニターされました。

--------------------------------------------------------------------------- 
Incoming Call: 
--------------------------------------------------------------------------- 
    MSID: 0000012345 Callid: 002dc6c2 
    Username: user2@aaa SessionType: unknown 
    Status: Active Service Name: xxx1 
    Src Context: source Dest Context: 
--------------------------------------------------------------------------- 
 
<<<<OUTBOUND 10:02:35:415 Eventid:25001(0) 
PPP Tx PDU (9) 
PAP 9: Auth-Ack(1), Msg= 
 
<<<<OUTBOUND 10:02:35:416 Eventid:25001(0) 
PPP Tx PDU (14) 
IPCP 14: Conf-Req(1), IP-Addr=192.168.250.70 
 
<<<<OUTBOUND 10:02:35:416 Eventid:25001(0) 
PPP Tx PDU (27) 
CCP 27: Conf-Req(1), MPPC, Stac-LZS, Deflate, MVRCA 
 
INBOUND>>>>> 10:02:35:517 Eventid:25000(0) 
PPP Rx PDU (30) 
IPCP 30: Conf-Req(1), IP-Comp VJ-Comp, IP-Addr=0.0.0.0, Pri-DNS=0.0.0.0, 
Sec-DNS=0.0.0.0 
 
<<<<OUTBOUND 10:02:35:517 Eventid:25001(0) 
PPP Tx PDU (26) 
IPCP 26: Conf-Rej(1), IP-Comp VJ-Comp, Pri-DNS=0.0.0.0, Sec-DNS=0.0.0.0 
 
INBOUND>>>>> 10:02:35:517 Eventid:25000(0) 
PPP Rx PDU (12) 
IPCP 12: Conf-Ack(1), IP-Addr=192.168.250.70 
 
INBOUND>>>>> 10:02:35:518 Eventid:25000(0) 
PPP Rx PDU (31) 
LCP 31: Prot-Rej(1), Rejected-Protocol=CCP (0x80fd) 
 
INBOUND>>>>> 10:02:35:518 Eventid:25000(0) 
PPP Rx PDU (12) 
IPCP 12: Conf-Req(2), IP-Addr=0.0.0.0 
 
<<<<OUTBOUND 10:02:35:518 Eventid:25001(0) 
PPP Tx PDU (14) 
IPCP 14: Conf-Nak(2), IP-Addr=192.168.250.87 
 
INBOUND>>>>> 10:02:35:519 Eventid:25000(0) 
PPP Rx PDU (12) 
IPCP 12: Conf-Req(3), IP-Addr=192.168.250.87 
 

モニターは、無効になるまでアクティブのままになります。プロトコルモニターを終了してプロンプトに戻るには、q を押します。


DHCP テストツールの使用

CLI には、DHCP サーバーとのネットワーク接続と、それらのサーバーの設定をテストするためのメカニズムが用意されています。この機能は、システムの DHCP 設定の精度とサーバーの応答時間を判断するのに役立ちます。

このツールには、システムが通信する 1 つまたは複数の DHCP サーバーの IP アドレスを取得するためのメカニズムが用意されています。また、このツールにはアドレスを DHCP サーバーに戻すためのメカニズムも備わっています。


重要


このツールは、DHCP サーバーが設定されているコンテキストから実行する必要があります。


DHCP テストツールを実行するには、適切なコンテキスト内で次のコマンドを入力します。
dhcp test dhcp-service { service_name } [ all | server ip_addr ] 

上記のコマンドの詳細については、『Command Line Interface Reference』の「Exec Mode Commands」の章を参照してください。

SSD の生成

SSD は、Exec モードの show support details コマンドが実行されたときの出力のインスタンスです。トラブルシューティングのために役立つシステム情報の包括的なリストが表示されます。ほとんどの場合、このコマンドの出力はテクニカル アシスタンス センター(TAC)によって要求されます。

SSD 出力の .tar ファイルは、ローカルまたはリモートの場所(URL)にリダイレクトできます。

.tar ファイルには次のものが含まれます。
  • support_summary:サポートの詳細情報を含む ASCII テキストファイル。

  • information.minicores.tar:システム上ので検出された minicore ファイルを含む .tar ファイル。Minicore ファイルには、一部のイベント中にキャプチャされるメモリコアダンプが含まれています。これらのコアダンプは、イベントに関する特定のメモリの場所とその他の情報を提供します。この情報はテクニカルサポートチームにとって、推定原因とともにイベントが発生した場所とタイミングを特定するために役立ちます。

show support details コマンドには、他の方法ではユーザーがアクセスできない情報が含まれていますが、TAC による問題の迅速な解決に役立ちます。


重要


大規模な構成ファイルを持つプラットフォームでは、SSD を完了するまでに最大で30分かかる場合があります。show support details コマンドを実行すると、システムリソースが消費され、トラフィックのスループットが低下する可能性があります。


オペレータが show support details コマンドを入力したときに SSD が進行中である場合、StarOS は SSD がすでに進行中であることを示す警告メッセージで応答します。ユーザーは後で再試行する必要があります。オペレータは、一度に 1 つの SSD インスタンスだけを実行するように制限されています。

show support details コマンドには、特定のタイプの情報だけを報告するように SSD をターゲットにできるオプションのキーワードがあります。これらのキーワードにより、SSD の生成に必要な時間を短縮できます。

show support details コマンドの詳細については、『Command Line Interface Reference』の「 Exec Mode Show Commands (Q-S)」の章を参照してください。

サポートデータコレクターの設定と使用

サポートデータを収集するタスクは、record collector と呼ばれるバックグラウンド CLI タスクによって実行されます。管理者は、CLI を介して Support Data Collector(SDC)を設定し、コマンドを定期的に実行します。レコードコレクタは常にバックグラウンドで実行され、収集レコードがあるかどうかを確認します。

サポートデータを収集する時間になると、スケジューラは設定された CLI コマンドのシーケンスを実行し、その結果をハードディスク上の gunzipped(gz)ファイルに保存します。このファイルは SDR(サポートデータレコード)と呼ばれ、その時点でのシステム全体の状態のスナップショットを表します。

テクニカル アシスタンス センター(TAC)担当者およびローカル管理者は、SDR をオンラインで、またはシステムから転送して確認することができます。また、コレクタの状態の情報を調査する場合もあります。

SDC 機能の詳細については、「サポートデータコレクター」の章を参照してください。

ハイパーバイザによる強制再起動の開始

ハイパーバイザは、仮想ウォッチドッグデバイスをサポートしています。VPC がこのウォッチドッグの機能を停止すると、ハイパーバイザによって VM が強制的に再起動されます。次の表を参照してください。

表 21. ハイパーバイザによる強制再起動の条件
条件 再起動方法 リカバリ 注意
クリティカルタスクの失敗 ハイパーバイザ ウォッチドッグ ハイパーバイザによる VM の再起動 StarOS がウォッチドッグの機能を停止します。
カーネルのハング/クラッシュ カーネルまたはハイパーバイザ ウォッチドッグ ハイパーバイザによる VM の再起動
ホストの障害 ハイパーバイザ HA(高可用性) ハイパーバイザ管理システムが HA を呼び出し、VM を別のホストに割り当てて再起動します。 例:VMware の HA クラスタ

KVM では、 --watchdog i6300esb コマンドライン引数を使用して仮想ウォッチドッグデバイスを指定できます。VMware には、独自のウォッチドッグメカニズムが備わっています。