この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、一般的な問題をトラブルシューティングする方法について説明します。内容は次のとおりです。
• 「一般的な問題」
• 「AppNav サービス ノード自動検出デバッグ コマンド(Cisco CSR 1000V シリーズのみ)」
• 「Cisco IOS XE コントロール プレーンのデバッグ」
AppNav-XE のすべての統計情報、または特定の統計情報をクリアするには、次のコマンドを使用します。
コントロール プレーンのアクティビティをトレースするには、次のデバッグ コマンドを使用します。
• debug appnav-controller cmm events
予定外のパケット ドロップを表示するには、次のコマンドを使用します。
• AppNavInvSNpkt:サービス ノードからの変形したまたはサポートされていないパケット。
• AppNavInternalErr:AppNav-XE コンポーネント内の論理エラー。まれに発生します。
• AppNavBadRoute:AppNav-XE の仮想またはトンネル インターフェイスに表示される非 AppNav-XE パケット。ルーティング プロトコルがイネーブルの場合、頻繁に発生します。
• AppNavNoTunnel:サービス ノード宛てのパケットに使用可能なトンネル機能がありません。
• AppNavNoSvcCtx:サービス ノードからのフローに一致するサービス コンテキストがありません。
• AppNavInvFOState:フロー状態が有効ではありません。これは通常、設定の変更により発生します。
• AppNavUnexpctdpkt:AppNav-XE コンポーネントがシャットダウンされたため、より多くのパケットの処理が予測されませんでした。
データ パス CPU の使用率を表示するには、次のコマンドを使用します。
データ パス メモリの使用状況に関する統計情報を表示するには、次のコマンドを使用します。
(注) 使用中の DRAM メモリの値は DRAM メモリの総容量の値の 90 パーセント未満である必要があります。そうでない場合、AppNav-XE コンポーネントによって新しいフローの最適化が停止されます。
次のデバッグ コマンドの出力は、アクティブな FP モジュールに応じて Fx が F0 または F1 のいずれかである FP シェルの下で、/tmp/fp/trace/cpp_cp_ Fx -0.log という名前のログ ファイルとして表示されます。FP シェルにアクセスするにはシェル ライセンスが必要です。
シェルへのアクセス権がない場合、 test platform software trace slot fp act cpp-control-process rotate コマンドを使用して、ログを強制的に bootflash:tracelogs にフラッシュできます。
上記の各カテゴリ(レベルのない ドロップ を除く)には、次の 4 つのレベルがあります。
• Error:エラー レベル デバッグを表示し、潜在的な問題を検出します。
• All:デバッグの最低レベル。すべてのデバッグを表示します。
デバッグ メッセージの数を制限するには、最初にエラー デバッグ レベルだけをイネーブルにし、その後徐々にデバッグ レベルを下げることを推奨します。
また、ルータがドロップしたパケットを確認するには、次のコマンドを使用できます。このコマンドは、理由があってドロップされたすべてのパケットを一覧表示します。AppNav のドロップの理由を表示するには、debug drop コマンドをイネーブルにして、トレース ログ内の実際のパケットのドロップを確認できます。
Cisco CSR 1000V シリーズの AppNav サービス ノード自動検出機能をトレースするには、次のデバッグ コマンドを使用します。
(注) 自動検出デバッグ コマンドは、Cisco CSR 1000V シリーズにのみ適用されます。
• 「トラフィックがリダイレクトされる代わりにパススルーされる」
• 「負荷なしにもかかわらずアプリケーション アクセラレータのステータスが赤色を示している」
• 「AppNav-XE コンポーネントの初期化が失敗する」
トラフィックが正しくリダイレクトされない場合、トラフィックが代行受信されると想定されるインターフェイス上に「service-insertion waas」が存在することを確認します。これを確認するには、 show service-insertion status コマンドを発行します。
show service-insertion statistics connection コマンドは、トラフィックがパススルーされたのかリダイレクトされたのかを示します。トラフィックがリダイレクトされる代わりにパススルーされた場合は、show policy-map target service-context context_name passthru-reason コマンドを使用して理由を特定します。詳細については、「パススルーの理由の統計情報の表示」を参照してください。
また、サービス ノード カウンタをモニタできます。「サービス ノードごと、サービス ノード グループごとの統計情報の表示」を参照してください。
「Initial Redirect」は、フローがサービス ノードにリダイレクトされていることを示します。フローがサービス ノードにリダイレクトされていない場合は、ポリシーがトラフィック タイプに対応していない可能性があります。
「Initial Redirect -> Passthrough」カウンタは、サービス ノードがフローをパススルーすることを決定したことを示します。これは、サービス ノードのポリシーが原因の可能性があります。
「Redirect -> Passthrough」カウンタは、サービス ノードがフローをパススルーすることを後で決定したことを示します。これは、ピア WAAS デバイスの欠落が原因の可能性があります。フローを最適化するには、パスに 2 台の WAAS デバイスが必要です。
接続がパススルーされたときに、複数の AppNav コントローラがある AppNav コントローラ グループを使用している場合は、クラスタのパフォーマンスが低下する可能性があります。これは AppNav コントローラのビューが AppNav の各コントローラで同じでないことを意味します。
クラスタの状態および各 AppNav コントローラの安定した AppNav コントローラ ビューを確認するには、次のコマンドを使用します。
各 AppNav コントローラで AppNav コントローラ ビューが異なる理由は、AppNav コントローラの AppNav コントローラ グループ設定の不一致、または AppNav コントローラ間の接続の問題が原因である可能性があります。
次のコマンドにより AppNav の各コントローラでアラームを確認することも役立ちます。このコマンドでは修正措置も示されます。
Cluster membership manager has detected a discrepancy in the AC view of peer ACs.Optimization will be turned off on this device for cluster consistency.
AppNav controller is unreachable.
Cluster protocol detected failure of the peer AC.This could happen due to several reasons - configuration mismatch or network issues preventing communication between the ACs or the AC actually being down.
トラフィックが特定のサービス ノードにリダイレクトされず、複数の AppNav コントローラを持つ AppNav コントローラ グループを使用する場合、サービス ノードが除外されることがあります。これは、各 AppNav コントローラでサービス ノード ビューが異なる場合に発生します。
AppNav の各コントローラで安定したサービス ノード ビューを調べるには、show service-insertion service-context コマンドを使用します。
サービス ノード ビューが異なる理由は、AppNav コントローラのサービス ノード グループ設定の不一致、または 1 つ以上の AppNav コントローラと除外されたサービス ノード間の接続の問題が原因である可能性があります。
どのサービス ノードが除外されたか、または到達不能かを確認するには、各 AppNav コントローラで show service-insertion alarms detail support コマンドを使用して、SN_excluded および SN_unreachable アラームを検索します。
これは、ACG の AppNav コントローラによって認識されたトラフィックの VRF 名の不一致が原因である可能性があります。
show service-insertion statistics connection summary コマンドで出力される Flow sync failures due to vrf-mismatch カウンタを確認します。
接続がハングする場合、さまざまな理由が考えられます。多くの場合、Telnet を使用してサーバへの接続をシミュレートすることが役立ちます。たとえば、 telnet HTTP_server 80 と入力します。
TCP スリーウェイ ハンドシェイク中に接続がハングした場合は、サービス ノードへの接続およびルートの両方が正しく設定されていることを確認します。
接続の確立後に接続がハングした場合は、パスに沿って接続を確認します。パスの MTU が正しいことを確認します。
AppNav コントローラとサービス ノード間の接続をクロスチェックするには、AppNav コントローラ上で show service-insertion statistics connection コマンド、サービス ノード上で show statistics connection コマンドを使用します。
パケット ドロップを確認するには、 show platform hardware qfp active statistics drop コマンドを使用します。
通常は、サービス ノード上で show statistics connection closed コマンドおよび show statistics connection closed conn-id connection_ID コマンドを発行して、接続のリセットの理由を調べることができます。パケットのキャプチャも、接続のリセットの原因分析に役立ちます。
ドロップされたパケットを確認するには、 show platform hardware qfp active statistics drop コマンドを使用します。
インターフェイスで service-insertion waas コマンドがイネーブルのときにシステムが「ERROR_NOTIFY」syslog メッセージを表示する場合は、メモリ容量の不足が原因で AppNav-XE コンポーネントの初期化が失敗した可能性があります。次のコマンドを使用して、メモリ容量を確認してください。
使用可能なメモリ容量が総メモリ容量の 10 パーセントに満たない場合、AppNav-XE コンポーネントが初期化されず、フローがリダイレクトされなくなる可能性があります。
show policy-map target service-context waas/1 コマンドの出力が、使用される AppNav ポリシーの一覧表示ではなく空白であった場合、初期化に失敗した可能性があります。
AppNav コントローラとサービス ノードの両方とも、サポート可能なフロー数には制限があります。AppNav コントローラでは、上限は 200 万フローです。上限を超えると、すべてのフローがパススルーされます。制限を超えると、システムは次のエラー メッセージを表示します。
使用可能なメモリ容量により、フローの上限にすぐに到達してしまう場合があります。この場合、システムは次の syslog メッセージを表示します。
AppNav コントローラが WAAS TCP トレースに応答しない場合、システムは TCP トレースをサービス ノードに転送し、サービス ノードはパスに沿ったサービス ノードのリストとともに応答を生成します。