ASR 9000シリーズパントファブリックデータパス障害のトラブルシューティング
内容
はじめに
このドキュメントでは、Cisco アグリゲーション サービス ルータ（ASR）9000 シリーズの動作中に表示されるパント ファブリック データ パス障害メッセージについて説明します。
メッセージは次の形式で表示されます。
RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC: pfm_node_rp[358]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 1) (0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5)
(0/7/CPU0, 6) (0/7/CPU0, 7)
このドキュメントは、エラーメッセージを理解し、問題が発生した場合に実行するアクションを理解したい人を対象としています。
前提条件
要件
シスコでは、次の項目について高度な知識があることを推奨しています。
- ASR 9000 のライン カード
- ファブリック カード
- ルート プロセッサ
- シャーシ構造
ただし、このドキュメントを読むにあたり、読者がハードウェアの詳細を知っている必要はありません。エラー メッセージについて説明する前に、必要な背景情報が提供されます。このドキュメントでは、Trident ベースのライン カードと Typhoon ベースのライン カードの両方のエラーについて説明します。これらの用語の説明については、「ASR 9000シリーズラインカードのタイプについて」を参照してください。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。
このマニュアルの使用方法
このドキュメントを使用して重要な詳細を収集する方法、およびトラブルシューティングプロセスのリファレンスガイドとして使用する方法については、次の推奨事項を考慮してください。
- パント ファブリック データ パス障害の原因を急いで特定する必要がない場合は、このドキュメントのすべてのセクションをお読みください。このドキュメントでは、そのようなエラーが発生した場合に、障害のあるコンポーネントを特定するために必要な背景知識が得られます。
- 迅速な回答が必要な、具体的な質問がある場合は、「FAQ」のセクションを使用してください。質問が「FAQ」のセクションに含まれていない場合は、メイン ドキュメントでその質問を扱っているかどうかを確認してください。
- ルータで障害が発生している場合に問題を特定して不良コンポーネントを見つけるためや、それが既知の問題なのかどうかを確認するには、「障害の分析」のすべてのセクションを使用してください。
背景説明
パケットは、ライン カードのタイプに応じて、スイッチ ファブリック中を 2 ホップまたは 3 ホップ通過します。Typhoon 世代のライン カードにはスイッチ ファブリック要素が追加されていますが、Trident ベースのライン カードでは、すべてのトラフィックがルート プロセッサ カードのファブリックのみでスイッチングされます。以下の図は、これら両方のライン カード タイプのファブリック要素と、ルート プロセッサ カードとファブリックの接続を示しています。
パント ファブリック診断パケット パス
ルート プロセッサ カードの CPU 上で実行される診断アプリケーションは、各ネットワーク プロセッサ（NP）宛の診断パケットを定期的に注入します。診断パケットは NP の内部でループバックされ、パケットを送信したルート プロセッサ カードの CPU 宛に再注入されます。ルート プロセッサ カード上の診断アプリケーションによる、NP ごとに固有のパケットを使用した全 NP のこの定期的なヘルス チェックは、ルータの動作中にデータ パス上のすべての機能エラーについてのアラートを提供します。アクティブ ルート プロセッサとスタンバイ ルート プロセッサの両方の診断アプリケーションが、NP ごとに 1 個のパケットを定期的に注入し、NP ごとに成功または失敗数を保持することに注意する必要があります。ドロップした診断パケット数のしきい値に達すると、アプリケーションはエラーを生成します。
診断パスの概念図
Trident および Typhoon ベースのライン カードでの診断パスについて説明する前に、ここでは、ライン カード上のアクティブおよびスタンバイ ルート プロセッサ カードから NP に向かうファブリック診断パスの概要を示します。
アクティブ ルート プロセッサ カードとライン カードの間のパケット パス
アクティブ ルート プロセッサから NP に向かうファブリックに注入される診断パケットは、スイッチ ファブリックによってユニキャスト パケットとして扱われます。ユニキャスト パケットの場合、スイッチ ファブリックは、リンクの現在のトラフィック負荷に基づいて送信リンクを選択します。これにより診断パケットは、ルータのトラフィック負荷に応じて処理されます。NP へ向かう複数の送信リンクが存在する場合、スイッチ ファブリックの ASIC は、現在最も負荷が低いリンクを選択します。
次の図は、アクティブ ルート プロセッサから送信された診断パケットのパスを示しています。
スタンバイ ルート プロセッサ カードとライン カードの間のパケット パス
スタンバイ ルート プロセッサから NP へ向かうファブリックに注入される診断パケットは、スイッチ ファブリックによってマルチキャスト パケットとして扱われます。マルチキャスト パケットではあっても、ファブリック内部での複製は行われません。スタンバイ ルート プロセッサから送信されたすべての診断パケットは、やはり一度に 1 つの NP のみに到達します。NP からルート プロセッサ宛の応答パケットも、ファブリック上のマルチキャスト パケットであり、複製は行われません。したがって、スタンバイ ルート プロセッサ上の診断アプリケーションは、NP からの 1 個の応答パケットを、一度に 1 パケットずつ受信します。診断アプリケーションは、システム内のすべての NP を追跡します。これは、NP ごとに 1 個のパケットを注入し、一度に 1 パケットずつ、すべての NP からの応答を期待するためです。マルチキャスト パケットの場合、スイッチ ファブリックはパケット ヘッダーのフィールド値に基づいて送信リンクを選択します。これは、ルート プロセッサ カードとライン カード間のすべてのファブリック リンク上で診断パケットを注入するのに役立ちます。スタンバイ ルート プロセッサは、ルート プロセッサ カードとライン カード スロットの間を接続するすべてのファブリック リンク上で NP の稼働状態を追跡します。
前述の図は、スタンバイ ルート プロセッサから送信された診断パケットのパスを示しています。アクティブ ルート プロセッサの場合とは異なり、ライン カードをルート プロセッサ上の XBAR に接続するすべてのリンクが調べられることに注意してください。NP からの応答パケットは、ルート プロセッサからライン カードの方向にパケットが使用したのと同じファブリック リンクを使用します。このテストにより、スタンバイ ルート プロセッサをライン カードに接続するすべてのリンクが継続的にモニタされます。
Trident ベースのライン カード上のパント ファブリック診断パケット パス
次の図は、ルート プロセッサが NP 宛に送信した診断パケットが、ルート プロセッサに向けてループバックされる様子を示しています。すべての NP に共通するデータ パス リンクおよび ASIC と、NP のサブセットに固有のリンクおよびコンポーネントに注意することが重要です。たとえば、ブリッジ ASIC 0（B0）は NP0 と NP1 に共通ですが、FIA0 はすべての NP に共通です。ルート プロセッサ側では、すべてのリンク、データ パス ASIC、および Field-Programmable Gate Array（FPGA）がすべてのライン カードに共通であることから、シャーシ内のすべての NP に共通です。
Typhoon ベースのライン カード上のパント ファブリック診断パケット パス
次の図は、ルート プロセッサ カードが NP 宛に送信した診断パケットが、ルート プロセッサに向けてループバックされる様子を示しています。すべての NP に共通するデータ パス リンクおよび ASIC と、NP のサブセットに固有のリンクおよびコンポーネントに注意することが重要です。たとえば、FIA0 は NP0 と NP1 に共通です。ルート プロセッサ カード側では、すべてのリンク、データ パス ASIC、および FGPA がすべてのライン カードに共通であることから、シャーシ内のすべての NP に共通です。
Tomahawk、Lightspeed、およびLightspeedPlusベースのラインカード上のパントファブリック診断パケットパス
Tomahawkラインカードでは、FIAとNPの間に1:1の接続があります。
LightspeedおよびLightspeedPlusラインカードでは、FIAはNPチップに統合されています。
以降の数セクションでは、すべての NP へのパケット パスを示します。これは、パント ファブリック データ パスのエラー メッセージを理解し、障害場所を探すために必要です。
パント ファブリック診断アラームと障害レポート
ASR 9000 ベースのルータの NP からの応答の受信に失敗するとアラームが発生します。ルート プロセッサ上で動作するオンライン診断アプリケーションがアラームを発生するための決定は、3 回連続で障害が発生した場合に行われます。診断アプリケーションは、すべての NP に対して 3 個のパケット障害ウィンドウを保持します。アクティブ ルート プロセッサとスタンバイ ルート プロセッサは、個別に並行して診断を行います。アクティブルートプロセッサ、スタンバイルートプロセッサ、または両方のルートプロセッサカードがエラーを報告する可能性があります。どのルート プロセッサがアラームを報告するかは、障害とパケット損失の場所で決まります。
各 NP 宛の診断パケットのデフォルトの頻度は、60 秒ごとに 1 パケットです。
アラーム メッセージの形式を次に示します。
RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC: pfm_node_rp[358]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 1) (0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5)
(0/7/CPU0, 6) (0/7/CPU0, 7)
このメッセージは、ルートプロセッサ0/rsp0/cpu0からラインカード0/7/cpu0上のNP 1、2、3、4、5、6、および7に到達できない障害を示しています。
オンライン診断テストのリストから、次のコマンドを使用してパント ファブリック ループバック テストの属性を確認できます。
RP/0/RSP0/CPU0:iox(admin)#show diagnostic content location 0/RSP0/CPU0
RP 0/RSP0/CPU0:
Diagnostics test suite attributes:
M/C/* - Minimal bootup level test / Complete bootup level test / NA
B/O/* - Basic ondemand test / not Ondemand test / NA
P/V/* - Per port test / Per device test / NA
D/N/* - Disruptive test / Non-disruptive test / NA
S/* - Only applicable to standby unit / NA
X/* - Not a health monitoring test / NA
F/* - Fixed monitoring interval test / NA
E/* - Always enabled monitoring test / NA
A/I - Monitoring is active / Monitoring is inactive
Test Interval Thre-
ID Test Name Attributes (day hh:mm:ss.ms shold)
==== ================================== ============ ================= =====
1) PuntFPGAScratchRegister ---------- *B*N****A 000 00:01:00.000 1
2) FIAScratchRegister --------------- *B*N****A 000 00:01:00.000 1
3) ClkCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
4) IntCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
5) CPUCtrlScratchRegister ----------- *B*N****A 000 00:01:00.000 1
6) FabSwitchIdRegister -------------- *B*N****A 000 00:01:00.000 1
7) EccSbeTest ----------------------- *B*N****I 000 00:01:00.000 3
8) SrspStandbyEobcHeartbeat --------- *B*NS***A 000 00:00:05.000 3
9) SrspActiveEobcHeartbeat ---------- *B*NS***A 000 00:00:05.000 3
10) FabricLoopback ------------------- MB*N****A 000 00:01:00.000 3
11) PuntFabricDataPath --------------- *B*N****A 000 00:01:00.000 3
12) FPDimageVerify ------------------- *B*N****I 001 00:00:00.000 1
RP/0/RSP0/CPU0:ios(admin)#
この出力は、PuntFabricDataPath テストの頻度が毎分 1 パケットであり、障害しきい値が 3 であることを示しています。これは、連続する 3 個のパケットが損失することは許容されず、アラームが発生することを意味しています。ここに示されているテスト属性はデフォルト値です。デフォルトを変更するには、 diagnostic monitor interval と diagnostic monitor threshold コマンドを使用します。
Trident ベースのライン カードの診断パケット パス
NP0 診断障害
ファブリック診断パス
次の図は、ルート プロセッサの CPU とライン カードの NP0 の間のパケット パスを示しています。B0 と NP0 を接続するリンクは、NP0 専用の唯一のリンクです。他のすべてのリンクは共通のパスになります。
ルート プロセッサから NP0 に向かうパケット パスをメモします。ルート プロセッサから NP0 に向かうパケットに使用するリンクは 4 つありますが、ルート プロセッサとライン カード スロットの間の最初のリンクは、ルート プロセッサからライン カードへ向かうパケットに使用されます。NP0 からの戻りパケットは、ライン カード スロットとアクティブ ルート プロセッサの間の 2 本のファブリック リンク パスのいずれかを介してアクティブ ルート プロセッサに返送される可能性があります。2 本のリンクのどちらを使用するかは、その時点のリンクの負荷によって選択されます。NP0 からスタンバイ ルート プロセッサへ向かう応答パケットは両方のリンクを使用しますが、一度に使用するのは 1 つのリンクです。リンクの選択は、診断アプリケーションが設定するヘッダー フィールドに基づいて行われます。
NP0 診断障害分析
単一障害シナリオ
単一の Platform Fault Manage（PFM）パント ファブリック データ パス障害アラームが検出され、障害メッセージ中に NP0 のみが出力される場合、障害は、ルート プロセッサとライン カードの NP0 を接続するファブリック パスだけにあります。これは単一障害です。障害が複数の NP に対して検出される場合は、「複数障害シナリオ」のセクションを参照してください。
RP/0/RSP0/CPU0:Sep 3 13:49:36.595 UTC: pfm_node_rp[358]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 0)
前出のデータ パスの図に示すように、障害は次の 1 つ以上の場所にあります。
- NP0 と B0 を接続するリンク
- NP0 へ向かう B0 キューの内部
- NP0 の内部
複数障害シナリオ
複数の NP 障害
NP0 上で他の障害が発生している場合や、同じライン カードの他の NP によって障害 PUNT_FABRIC_DATA_PATH_FAILED も報告される場合は、すべての障害を関連付けることで障害の切り分けを行います。たとえば、PUNT_FABRIC_DATA_PATH_FAILED障害とLC_NP_LOOPBACK_FAILED障害の両方がNP0で発生した場合、NPはパケットの処理を停止しています。ループバック障害について理解するには、「NPループバック診断パス」セクションを参照してください。これは、NP0 内部の重大な障害の初期兆候である可能性があります。ただし、2 種類の障害のうち 1 つだけが発生する場合、障害はパント ファブリック データ パスか、ライン カードの CPU から NP へのパスに限定されます。
ライン カードの複数の NP でパント ファブリック データ パス障害が発生する場合は、不良コンポーネントを特定するために、ファブリック リンクのツリー パス全体を調べる必要があります。たとえば、NP0 と NP1 の両方に障害がある場合は、B0 か、B0 と FIA0 を接続するリンクに障害があります。NP0 と NP1 の両方で重大な内部エラーが同時に発生する可能性はほとんどありません。可能性は低いものの、NP0 と NP1 で、特定の種類のパケットや不良パケットの不正な処理によって重大なエラーが発生することは考えられます。
両方のルート プロセッサ カードがエラーを報告
アクティブとスタンバイの両方のルート プロセッサ カードが、ライン カードの 1 つ以上の NP に対する障害を報告する場合は、該当する NP と両方のルート プロセッサ カードの間のデータ パス上にある、すべての共通リンクとコンポーネントを確認します。
NP1 診断障害
次の図は、ルート プロセッサ カードの CPU とライン カードの NP1 の間のパケット パスを示しています。ブリッジ ASIC 0（B0）と NP1 を接続するリンクは、NP1 専用の唯一のリンクです。他のすべてのリンクは共通のパスになります。
ルート プロセッサ カードから NP1 に向かうパケット パスをメモします。ルート プロセッサから NP0 に向かうパケットに使用するリンクは 4 つありますが、ルート プロセッサとライン カード スロットの間の最初のリンクは、ルート プロセッサからライン カードへ向かうパケットに使用されます。NP1 からの戻りパケットは、ライン カード スロットとアクティブ ルート プロセッサの間の 2 本のファブリック リンク パスのいずれかを介してアクティブ ルート プロセッサに返送される可能性があります。2 本のリンクのどちらを使用するかは、その時点のリンクの負荷によって選択されます。NP1 からスタンバイ ルート プロセッサへ向かう応答パケットは両方のリンクを使用しますが、一度に使用するのは 1 つのリンクです。リンクの選択は、診断アプリケーションが設定するヘッダー フィールドに基づいて行われます。
ファブリック診断パス
NP1 診断障害分析
「NP0 診断障害分析」のセクションを参照して、NP0 ではなく NP1 に対して同じ推論を適用します。
NP2 診断障害
次の図は、ルート プロセッサ カードの CPU とライン カードの NP2 の間のパケット パスを示しています。B1 と NP2 を接続するリンクは、NP2 専用の唯一のリンクです。他のすべてのリンクは共通のパスになります。
ルート プロセッサ カードから NP2 に向かうパケット パスをメモします。ルート プロセッサから NP2 に向かうパケットに使用するリンクは 4 つありますが、ルート プロセッサとライン カード スロットの間の最初のリンクは、ルート プロセッサからライン カードへ向かうパケットに使用されます。NP2 からの戻りパケットは、ライン カード スロットとアクティブ ルート プロセッサの間の 2 本のファブリック リンク パスのいずれかを介してアクティブ ルート プロセッサに返送される可能性があります。2 本のリンクのどちらを使用するかは、その時点のリンクの負荷によって選択されます。NP2 からスタンバイ ルート プロセッサへ向かう応答パケットは両方のリンクを使用しますが、一度に使用するのは 1 つのリンクです。リンクの選択は、診断アプリケーションが設定するヘッダー フィールドに基づいて行われます。
ファブリック診断パス
NP2 診断障害分析
「NP0 診断障害分析」のセクションを参照して、NP0 ではなく NP2 に対して同じ推論を適用します。
NP3 診断障害
次の図は、ルート プロセッサ カードの CPU とライン カードの NP3 の間のパケット パスを示しています。ブリッジ ASIC 1（B1）と NP3 を接続するリンクは、NP3 専用の唯一のリンクです。他のすべてのリンクは共通のパスになります。
ルート プロセッサ カードから NP3 に向かうパケット パスをメモします。ルート プロセッサから NP3 に向かうパケットに使用するリンクは 4 つありますが、ルート プロセッサとライン カード スロットの間の最初のリンクは、ルート プロセッサからライン カードへ向かうパケットに使用されます。NP3 からの戻りパケットは、ライン カード スロットとアクティブ ルート プロセッサの間の 2 本のファブリック リンク パスのいずれかを介してアクティブ ルート プロセッサに返送される可能性があります。2 本のリンクのどちらを使用するかは、その時点のリンクの負荷によって選択されます。NP3 からスタンバイ ルート プロセッサへ向かう応答パケットは両方のリンクを使用しますが、一度に使用するのは 1 つのリンクです。リンクの選択は、診断アプリケーションが設定するヘッダー フィールドに基づいて行われます。
ファブリック診断パス
NP3 診断障害分析
「NP0 診断障害分析」のセクションを参照して、NP0 ではなく NP3 に対して同じ推論を適用します。
Typhoon ベースのライン カードの診断パケット パス
ここでは、Typhoon ベースのライン カードで、ファブリック パント パケットの背景知識を得るための 2 つの例を示します。1 つ目の例は NP1 を使用し、2 つ目の例は NP3 を使用します。説明と分析は、任意の Typhoon ベースのライン カードの他の NP に拡張することができます。
Typhoon NP1 診断障害
次の図は、ルート プロセッサ カードの CPU とライン カードの NP1 の間のパケット パスを示しています。FIA0 と NP1 を接続するリンクは、NP1 パス専用の唯一のリンクです。ライン カード スロットとルート プロセッサ カード スロットの間の他のすべてのリンクは共通パスになります。ライン カード上のファブリック XBAR ASIC をライン カード上の FIA に接続するリンクは、NP のサブセットに固有です。たとえば、ライン カードの FIA0 とローカル ファブリックの XBAR ASIC の間の両方のリンクが、NP1 へのトラフィックに使用されます。
ルート プロセッサ カードから NP1 に向かうパケット パスをメモします。ルート プロセッサ カードから NP1 に向かうパケットに使用するリンクは 8 つありますが、ルート プロセッサ カードとライン カード スロットの間の単一のパスが使用されます。NP1 からの戻りパケットは、ライン カード スロットとルート プロセッサの間の 8 つのファブリック リンク パスを介してルート プロセッサ カードに返送される可能性があります。この 8 つのリンクそれぞれが、診断パケットがルート プロセッサ カードの CPU に返送されるときに、一度に 1 つずつ調べられます。
ファブリック診断パス
Typhoon NP3 診断障害
次の図は、ルート プロセッサ カードの CPU とライン カードの NP3 の間のパケット パスを示しています。FIA1 と NP3 を接続するリンクは、NP3 パス専用の唯一のリンクです。ライン カード スロットとルート プロセッサ カード スロットの間の他のすべてのリンクは共通パスになります。ライン カード上のファブリック XBAR ASIC をライン カード上の FIA に接続するリンクは、NP のサブセットに固有です。たとえば、ライン カードの FIA1 とローカル ファブリックの XBAR ASIC の間の両方のリンクが、NP3 へのトラフィックに使用されます。
ルート プロセッサ カードから NP3 に向かうパケット パスをメモします。ルート プロセッサ カードから NP3 に向かうパケットに使用するリンクは 8 つありますが、ルート プロセッサ カードとライン カード スロットの間の単一のパスが使用されます。NP1 からの戻りパケットは、ライン カード スロットとルート プロセッサの間の 8 つのファブリック リンク パスを介してルート プロセッサ カードに返送される可能性があります。この 8 つのリンクそれぞれが、診断パケットがルート プロセッサ カードの CPU に返送されるときに、一度に 1 つずつ調べられます。
ファブリック診断パス
Tomahawkベースのラインカード診断パケットパス
FIAとNPの間は1:1で接続されているため、FIA0を通過するトラフィックはNP0との間のトラフィックだけです。
LightspeedおよびLightspeedPlusベースのラインカードの診断パケットパス
FIAはNPチップに統合されているため、FIA0を通過する唯一のトラフィックはNP0との間のトラフィックです。
障害の分析
ここでは、障害をハード障害と一時的な障害に分類し、障害がハード障害なのか一時的な障害なのかを特定するために使用する手順を示します。障害の種類が判明した後で、障害と必要な修正措置について理解するために、ルータに対して実行可能なコマンドを示します。
一時的な障害
PFM 設定メッセージの後に PFM クリア メッセージが続く場合は、障害が発生し、ルータ自身によって障害が解消されました。一時的な障害は、環境条件やハードウェア コンポーネントの回復可能な障害によって発生する可能性があります。一時的な障害を特定のイベントに関連付けることは困難な場合があります。
明確にするため、一時的なファブリック障害の例を以下に示します。
RP/0/RSP0/CPU0:Feb 5 05:05:44.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0)
RP/0/RSP0/CPU0:Feb 5 05:05:46.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Clear|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0)
一時的な障害の修正措置
一時的なエラーに対する推奨されるアプローチは、そのようなエラーの以降の発生のみをモニタすることです。一時的な障害が何度も発生する場合は、一時的な障害をハード障害として扱い、次のセクションで説明するように、ハード障害を分析するための推奨事項と手順を使用します。
ハード障害
PFM 設定メッセージの後に PFM クリア メッセージが続かない場合は、障害が発生し、ルータ自身が障害処理コードによって障害を解決していないか、ハードウェア障害がその性質上回復不可能です。ハード障害は、環境条件やハードウェア コンポーネントの回復不能な障害によって発生する可能性があります。ハード障害に対する推奨されるアプローチは、「ハード障害の分析」のセクションで説明するガイドラインを使用することです。
明確にするために、ハード ファブリック障害の例を以下に示します。このメッセージ例には、対応する PFM クリア メッセージがありません。
RP/0/RSP0/CPU0:Feb 5 05:05:44.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0)
ハード障害の修正措置
ハード障害シナリオでは、「サービス要求を作成する前に収集すべきデータ」のセクションに示されているすべてのコマンドを収集し、サービス リクエストをオープンします。緊急の場合は、トラブルシューティング コマンドの出力をすべて収集した後、障害の切り分けに基づいて、ルート プロセッサ カードまたはライン カードのリロードを開始します。リロード後、エラーが回復しなかった場合は、Return Material Authorization（RMA）を開始します。
一時的な障害の分析
一時的な障害を分析するには、次の手順を実行します。
- config コマンドを入力します
show logging | inc “PUNT_FABRIC_DATA_PATH"コマンドを発行して、エラーが1回発生したか、複数回発生したかを検出します。 - config コマンドを入力します
show pfm location allコマンドを発行して、現在のステータス（SETまたはCLEAR）を確認します。エラーが残っているか、クリアされたかを判断します。SET と CLEAR の間でエラー ステータスが変化する場合、ファブリック データ パス内で 1 つ以上の障害が繰り返し発生し、ソフトウェアまたはハードウェアで修正されます。 - 簡易ネットワーク管理プロトコル(SNMP)トラップをプロビジョニングするか、または収集するスクリプトを実行します。
show pfm location allコマンドの出力を参照し、エラー文字列を定期的に検索して、今後の障害の発生を監視します（エラーの最後のステータスがCLEARで、新しい障害が発生していない場合）。
使用するコマンド
一時的な障害を分析するには、次のコマンドを入力します。
show logging | inc “PUNT_FABRIC_DATA_PATH”show pfm location all
ハード障害の分析
ライン カード上のファブリック データ パス リンクをツリーとして表示した場合（詳細は「背景説明」のセクションを参照）、1 つ以上の NP がアクセス不能になっているかどうかを、障害場所に基づいて推測する必要があります。複数の障害が複数の NP で発生する場合は、このセクションに示すコマンドを使用して障害を分析します。
使用するコマンド
ハード障害を分析するには、次のコマンドを入力します。
show logging | inc “PUNT_FABRIC_DATA_PATH”
出力には、1つ以上のNP（NP2、NP3など）が含まれる場合があります。show controller fabric fia link-status location
NP2 と NP3（「Typhoon NP3 診断障害」のセクション）はいずれも 1 つの FIA を経由して送受信するため、障害がパス上の関連する FIA にあると推測するのが妥当です。show controller fabric crossbar link-status instance <0 and 1> location
ラインカード上のすべてのNPが診断アプリケーションに到達できない場合、ラインカードスロットをルートプロセッサカードに接続するリンクで、ルートプロセッサカードとラインカードの間でトラフィックを転送するASICのいずれかに障害があると推測するのが妥当です。show controller fabric crossbar link-status instance 0 locationshow controller fabric crossbar link-status instance 0 location 0/rsp0/cpu0show controller fabric crossbar link-status instance 1 location 0/rsp0/cpu0show controller fabric crossbar link-status instance 0 location 0/rsp1/cpu0show controller fabric crossbar link-status instance 1 location 0/rsp1/cpu0show controller fabric fia link-status location 0/rsp*/cpu0show controller fabric fia link-status location 0/rsp0/cpu0show controller fabric fia link-status location 0/rsp1/cpu0show controller fabric fia bridge sync-status location 0/rsp*/cpu0show controller fabric fia bridge sync-status location 0/rsp0/cpu0show controller fabric fia bridge sync-status location 0/rsp1/cpu0show tech fabric terminal
過去の障害
これまでの例を見ると、障害の 99 % が回復可能であり、ほとんどの場合、ソフトウェアによって起動される回復アクションによって障害が解決されます。ただし、非常にまれなケースで、カードの RMA でしか解決できない回復不能なエラーが発生します。
以降のセクションでは、同様のエラーが発生した場合のガイダンスとして、過去に発生した障害のいくつかを示します。
NP のオーバーサブスクリプションによる一時的なエラー
エラーの原因が NP のオーバーサブスクリプションである場合、次のメッセージが表示されます。
RP/0/RP1/CPU0:Jun 26 13:08:28.669 : pfm_node_rp[349]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[200823]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/10/CPU0, 0)
RP/0/RP1/CPU0:Jun 26 13:09:28.692 : pfm_node_rp[349]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Clear|online_diag_rsp[200823]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/10/CPU0,0)
一時的な障害は確認が困難な場合があります。NP が現在オーバーサブスクライブされているか、過去にオーバーサブスクライブされていたかを判断するための 1 つの方法は、NP 内部の特定の種類のドロップと、FIA 内のテール ドロップを確認することです。NP 内の Ingress Front Direct Memory Access（IFDMA）ドロップは、NP がオーバーサブスクライブされており、受信トラフィックを処理しきれない場合に発生します。FIA のテール ドロップは、出力 NP がフロー制御を通知する（入力ライン カードに対し、送信トラフィックを減らすよう求める）ときに発生します。フロー制御シナリオでは、入力 FIA でテール ドロップが発生します。
ランダム データの例は次のとおりです。
RP/0/RSP0/CPU0:RP/0/RSP0/CPU0:ASR9006-C#show controllers np counters all
Wed Feb 19 13:10:11.848 EST
Node: 0/1/CPU0:
----------------------------------------------------------------
Show global stats counters for NP0, revision v3
Read 93 non-zero NP counters:
Offset Counter FrameValue Rate (pps)
-----------------------------------------------------------------------
22 PARSE_ENET_RECEIVE_CNT 46913080435 118335
23 PARSE_FABRIC_RECEIVE_CNT 40175773071 5
24 PARSE_LOOPBACK_RECEIVE_CNT 5198971143966 0
<SNIP>
Show special stats counters for NP0, revision v3
Offset Counter CounterValue
----------------------------------------------------------------------------
524032 IFDMA discard stats counters 0 8008746088 0 <<<<<
ランダム データの例は次のとおりです。
RP/0/RSP0/CPU0:ASR9006-C#show controllers fabric fia drops ingress location 0/1/cPU0
Wed Feb 19 13:37:27.159 EST
********** FIA-0 **********
Category: in_drop-0
DDR Rx FIFO-0 0
DDR Rx FIFO-1 0
Tail Drop-0 0 <<<<<<<
Tail Drop-1 0 <<<<<<<
Tail Drop-2 0 <<<<<<<
Tail Drop-3 0 <<<<<<<
Tail Drop DE-0 0
Tail Drop DE-1 0
Tail Drop DE-2 0
Tail Drop DE-3 0
Hard Drop-0 0
Hard Drop-1 0
Hard Drop-2 0
Hard Drop-3 0
Hard Drop DE-0 0
Hard Drop DE-1 0
Hard Drop DE-2 0
Hard Drop DE-3 0
WRED Drop-0 0
WRED Drop-1 0
WRED Drop-2 0
WRED Drop-3 0
WRED Drop DE-0 0
WRED Drop DE-1 0
WRED Drop DE-2 0
WRED Drop DE-3 0
Mc No Rep 0
NP の高速リセットによるハード障害
PUNT_FABRIC_DATA_PATH_FAILED が発生し、NP の高速リセットが障害の原因である場合に、Typhoon ベースのライン カードでここに示すようなログが表示されます。ヘルス モニタリングのメカニズムは Typhoon ベースのライン カードで使用できますが、Trident ベースのライン カードでは使用できません。
LC/0/2/CPU0:Aug 26 12:09:15.784 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702
LC/0/2/CPU0:Aug 26 12:09:18.798 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702
LC/0/2/CPU0:Aug 26 12:09:21.812 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702
LC/0/2/CPU0:Aug 26 12:09:24.815 CEST:
prm_server_ty[303]: NP-DIAG health monitoring failure on NP0
LC/0/2/CPU0:Aug 26 12:09:24.815 CEST: pfm_node_lc[291]:
%PLATFORM-NP-0-NP_DIAG : Set|prm_server_ty[172112]|
Network Processor Unit(0x1008000)| NP diagnostics warning on NP0.
LC/0/2/CPU0:Aug 26 12:09:40.492 CEST: prm_server_ty[303]:
Starting fast reset for NP 0 LC/0/2/CPU0:Aug 26 12:09:40.524 CEST:
prm_server_ty[303]: Fast Reset NP0 - successful auto-recovery of NP
Trident ベースのライン カードでは、このログは、NP の高速リセットとともに表示されます。
LC/0/1/CPU0:Mar 29 15:27:43.787 test:
pfm_node_lc[279]: Fast Reset initiated on NP3
RSP440 ルート プロセッサと Typhoon ライン カードの間の障害
シスコでは、バックプレーン全体で、ルート スイッチ プロセッサ（RSP）440 と Typhoon ベースのライン カードの間のファブリック リンクがまれに再確立される問題を修正しました。ファブリック リンクが再確立されるのは、信号強度が最適ではないためです。この問題は、ベースとなるCisco IOS® XRソフトウェアリリース4.2.1、4.2.2、4.2.3、4.3.0、4.3.1、および4.3.2に存在します。これらの各リリースのソフトウェア メンテナンス アップデート（SMU）が Cisco Connection Online で公開されており、Cisco Bug ID CSCuj10837 および Cisco Bug ID CSCul39674 で追跡されています。
この問題がルータで発生すると、以下のシナリオのいずれかが発生する可能性があります。
- リンクがダウンしアップします（一時的）。
- リンクがダウンしたままになります。
Cisco Bug ID CSCuj10837:RSPとLC（TX方向）間のファブリックの再確立
確認するには、LCと両方のRSP(show controller fabric crossbar ltrace location <>)を使用して、次の出力がRSPトレースに表示されるかどうかを確認します。
SMU is already available
ランダム データの例は次のとおりです。
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain
Oct 1 08:22:58.999 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (1,1,0),(2,1,0),1.
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain
Oct 1 08:22:58.967 crossbar 0/0/CPU0 t1 init xbar_trigger_link_retrain:
destslot:0 fmlgrp:3 rc:0
Oct 1 08:22:58.967 crossbar 0/0/CPU0 t1 detail xbar_pfm_alarm_callback:
xbar_trigger_link_retrain(): (2,0,7) initiated
Oct 1 08:22:58.969 crossbar 0/0/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (2,1,0),(2,2,0),0.
TX 方向とは、RSP のクロスバー ファブリック インターフェイスから見た、Typhoon ベースのライン カード上のファブリック クロスバー インターフェイスに向かう方向を表します。
Cisco Bug ID CSCuj10837 の特徴は、Typhoon ライン カードにより RSP からの RX リンク上で問題が検出され、リンクの再確立が開始されるという点です。いずれの側（LC または RSP）も再確立イベントを開始する可能性があります。Cisco Bug ID CSCuj10837の場合、LCが再確立を開始し、LCのトレースにあるinit xbar_trigger_link_retrain：メッセージで検出できます。
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain
Oct 1 08:22:58.967 crossbar 0/0/CPU0 t1 init xbar_trigger_link_retrain: destslot:
0 fmlgrp:3 rc:0
LC が再確立を開始すると、RSP はトレース出力で rcvd link_retrain を報告します。
RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain
Oct 1 08:22:58.999 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (1,1,0),(2,1,0),1.
Cisco Bug ID CSCul39674:RSPとLC間のファブリックの再確立（RX方向）
確認するには、ラインカードと両方のRSPからltrace出力を収集します(show controller fabric crossbar ltrace location <>)を使用して、次の出力がRSPトレースに表示されるかどうかを確認します。
ランダム データの例は次のとおりです。
RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain
Jan 8 17:28:39.215 crossbar 0/0/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (0,1,0),(5,1,1),0.
RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain
Jan 8 17:28:39.207 crossbar 0/RSP1/CPU0 t1 init xbar_trigger_link_retrain:
destslot:4 fmlgrp:3 rc:0
Jan 8 17:28:39.207 crossbar 0/RSP1/CPU0 t1 detail xbar_pfm_alarm_callback:
xbar_trigger_link_retrain(): (5,1,11) initiated
Jan 8 17:28:39.256 crossbar 0/RSP1/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (5,1,1),(0,1,0),0.
RX 方向とは、RSP のクロスバー ファブリック インターフェイスから見た、Typhoon ベースのライン カード上のファブリック クロスバー インターフェイスからの方向を表します。
Cisco Bug ID CSCul39674 の特徴は、RSP により Typhoon ライン カードからの RX リンク上で問題が検出され、リンクの再確立が開始されるという点です。いずれの側（LC または RSP）も再確立イベントを開始する可能性があります。Cisco Bug ID CSCul39674の場合、RSPが再確立を開始し、RSPのトレースにあるinit xbar_trigger_link_retrain：メッセージで検出できます。
RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain
Jan 8 17:28:39.207 crossbar 0/RSP1/CPU0 t1 init xbar_trigger_link_retrain: destslot:4 fmlgrp:
3 rc:0
RSP が再確立を開始すると、LC はトレース出力で rcvd link_retrain イベントを報告します。
RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain
Jan 8 17:28:39.215 crossbar 0/0/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (0,1,0),(5,1,1),0.
リリース 4.3.2 以降でのファブリックの再確立の違い
Cisco IOS XRリリース4.3.2以降では、ファブリックリンクの再確立に要する時間を短縮するために、多くの作業が行われています。ファブリックの再確立は1秒未満で実行されるようになり、トラフィックフローからは認識されません。Cisco IOS XRリリース4.3.2では、ファブリックリンクの再確立が発生したときに表示されるのは、次のsyslogメッセージだけです。
%PLATFORM-FABMGR-5-FABRIC_TRANSIENT_FAULT : Fabric backplane crossbar link
underwent link retraining to recover from a transient error: Physical slot 1
ファブリック ASIC FIFO オーバーフローによる障害
シスコでは、回復不能な先入れ先出し(FIFO)オーバーフロー状態が原因で、ファブリックASIC(FIA)がリセットされる問題を修正しました。これは、Cisco Bug ID CSCul66510 で対処されています。この問題は Trident ベースのライン カードのみに影響し、入力パスが大きく輻輳しているまれなケースでのみ発生します。この問題が発生すると、ラインカードがリセットされて状態が回復する前に、次のsyslogメッセージが表示されます。
RP/0/RSP0/CPU0:asr9k-2#show log
LC/0/3/CPU0:Nov 13 03:46:38.860 utc: pfm_node_lc[284]:
%FABRIC-FIA-0-ASIC_FATAL_FAULT Set|fialc[159814]
|Fabric Interface(0x1014000)|Fabric interface asic ASIC1 encountered fatal
fault 0x1b - OC_DF_INT_PROT_ERR_0
LC/0/3/CPU0:Nov 13 03:46:38.863 utc: pfm_node_lc[284]:
%PLATFORM-PFM-0-CARD_RESET_REQ : pfm_dev_sm_perform_recovery_action,
Card reset requested by: Process ID:159814 (fialc), Fault Sev: 0, Target node:
0/3/CPU0, CompId: 0x10, Device Handle: 0x1014000, CondID: 2545, Fault Reason:
Fabric interface asic ASIC1 encountered fatal fault 0x1b - OC_DF_INT_PROT_ERR_0
ファブリックの輻輳による仮想出力キュー（VOQ）の蓄積による障害
シスコは、長時間にわたる大量の輻輳がファブリックリソースの枯渇やトラフィックの損失につながる可能性があるという問題を修正しました。トラフィック損失は、無関係なフローでも発生する可能性があります。この問題は、Cisco Bug ID CSCug90300に記述されており、Cisco IOS XRリリース4.3.2以降で解決されています。この修正は、Cisco IOS XRリリース4.2.3 CSMU#3、Cisco Bug ID CSCui33805でも提供されています。この稀な問題は、TridentベースまたはTyphoonベースのラインカードのいずれかで発生する可能性があります。
関連するコマンド
次のコマンドの出力を収集します。
show tech-support fabricshow controller fabric fia bridge flow-control location<===すべてのLCに対してこの出力を取得しますshow controllers fabric fia q-depth location
以下にいくつかの出力例を示します。
RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia q-depth location 0/6/CPU0
Sun Dec 29 23:10:56.307 UTC
********** FIA-0 **********
Category: q_stats_a-0
Voq ddr pri pktcnt
11 0 2 7
********** FIA-0 **********
Category: q_stats_b-0
Voq ddr pri pktcnt
********** FIA-1 **********
Category: q_stats_a-1
Voq ddr pri pktcnt
11 0 0 2491
11 0 2 5701
********** FIA-1 **********
Category: q_stats_b-1
Voq ddr pri pktcnt
RP/0/RSP0/CPU0:asr9k-1#
RP/0/RSP0/CPU0:asr9k-1#show controllers pm location 0/1/CPU0 | in "switch|if"
Sun Dec 29 23:37:05.621 UTC
Ifname(2): TenGigE0_1_0_2, ifh: 0x2000200 : <==Corresponding interface ten 0/1/0/2
iftype 0x1e
switch_fabric_port 0xb <==== VQI 11
parent_ifh 0x0
parent_bundle_ifh 0x80009e0
RP/0/RSP0/CPU0:asr9k-1#
通常の条件下では、VOQ に多数のパケットがキューイングされることはほとんどありません。このコマンドは、FIA キューの簡単なリアルタイム スナップショットです。通常このコマンドでは、キューイングされたパケットがまったく表示されません。
Trident ベースのライン カードでのブリッジまたは FPGA のソフト エラーによるトラフィックへの影響
ソフト エラーは一時的なエラーであり、ステート マシンが同期ずれ状態になります。これらは、NP のファブリック側または FIA の入力側の、巡回冗長検査（CRC）、フレーム チェック シーケンス（FCS）、またはエラーを含むパケットとして認識されます。
この問題がどのように見えるかの例を以下にいくつか示します。
RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia drops ingress location 0/3/CPU0
Fri Dec 6 19:50:42.135 UTC
********** FIA-0 **********
Category: in_drop-0
DDR Rx FIFO-0 0
DDR Rx FIFO-1 32609856 <=== Errors
RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia errors ingress location 0/3/CPU0
Fri Dec 6 19:50:48.934 UTC
********** FIA-0 **********
Category: in_error-0
DDR Rx CRC-0 0
DDR Rx CRC-1 32616455 <=== Errors
RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/0/CPU0
Ingress Drop Stats (MC & UC combined)
**************************************
PriorityPacket Error Threshold
Direction Drops Drops
--------------------------------------------------
LP NP-3 to Fabric 0 0
HP NP-3 to Fabric 1750 0
RP/0/RSP1/CPU0:asr9k-1#
RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/6/CPU0
Sat Jan 4 06:33:41.392 CST
********** FIA-0 **********
Category: bridge_in-0
UcH Fr Np-0 16867506
UcH Fr Np-1 115685
UcH Fr Np-2 104891
UcH Fr Np-3 105103
UcL Fr Np-0 1482833391
UcL Fr Np-1 31852547525
UcL Fr Np-2 3038838776
UcL Fr Np-3 30863851758
McH Fr Np-0 194999
McH Fr Np-1 793098
McH Fr Np-2 345046
McH Fr Np-3 453957
McL Fr Np-0 27567869
McL Fr Np-1 12613863
McL Fr Np-2 663139
McL Fr Np-3 21276923
Hp ErrFrNp-0 0
Hp ErrFrNp-1 0
Hp ErrFrNp-2 0
Hp ErrFrNp-3 0
Lp ErrFrNp-0 0
Lp ErrFrNp-1 0
Lp ErrFrNp-2 0
Lp ErrFrNp-3 0
Hp ThrFrNp-0 0
Hp ThrFrNp-1 0
Hp ThrFrNp-2 0
Hp ThrFrNp-3 0
Lp ThrFrNp-0 0
Lp ThrFrNp-1 0
Lp ThrFrNp-2 0
Lp ThrFrNp-3 0
********** FIA-0 **********
Category: bridge_eg-0
UcH to Np-0 779765
UcH to Np-1 3744578
UcH to Np-2 946908
UcH to Np-3 9764723
UcL to Np-0 1522490680
UcL to Np-1 32717279812
UcL to Np-2 3117563988
UcL to Np-3 29201555584
UcH ErrToNp-0 0
UcH ErrToNp-1 0
UcH ErrToNp-2 129 <==============
UcH ErrToNp-3 0
UcL ErrToNp-0 0
UcL ErrToNp-1 0
UcL ErrToNp-2 90359 <==========
Trident ベースのライン カードでのブリッジまたは FPGA のソフト エラーで収集すべきコマンド
次のコマンドの出力を収集します。
show tech-support fabricshow tech-support npshow controller fabric fia bridge stats location <>（何度も取得する）
ブリッジまたは FPGA のソフト エラーからの回復
回復方法は、該当するラインカードをリロードすることです。
RP/0/RSP0/CPU0:asr9k-1#hw-module location 0/6/cpu0 reload
オンライン診断テスト レポート
「 show diagnostic result location
コマンドは、すべてのオンライン診断テストおよび障害の概要と、テストに合格した最後のタイムスタンプを提供します。パント ファブリック データ パス障害のテスト ID は 10 です。すべてのテストのリストとテストパケットの頻度は、 show diagnostic content location
コマンドを使用して、アップグレードを実行します。
パントファブリックデータパステストの結果の出力は、次の出力例のようになります。
RP/0/RSP0/CPU0:ios(admin)#show diagnostic result location 0/rsp0/cpu0 test 10 detail
Current bootup diagnostic level for RP 0/RSP0/CPU0: minimal
Test results: (. = Pass, F = Fail, U = Untested)
___________________________________________________________________________
10 ) FabricLoopback ------------------> .
Error code ------------------> 0 (DIAG_SUCCESS)
Total run count -------------> 357
Last test execution time ----> Sat Jan 10 18:55:46 2009
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> Sat Jan 10 18:55:46 2009
Total failure count ---------> 0
Consecutive failure count ---> 0
自動リカバリの機能拡張
Cisco Bug ID CSCuc04493で説明されているように、アクティブRP/RSPで発生したPUNT_FABRIC_DATA_PATHエラーに関連するすべてのポートをルータが自動的にシャットダウンする方法があります。
1つ目の方法は、Cisco Bug ID CSCuc04493で追跡されています。バージョン4.2.3では、これはCisco Bug ID CSCui33805に含まれています。このバージョンでは、該当するNPに関連付けられているすべてのポートを自動的にシャットダウンするように設定されています。
次に、syslogがどのように表示されるかを示す例を示します。
RP/0/RSP0/CPU0:Jun 10 16:11:26 BKK: pfm_node_rp[359]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|System
Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:
(0/1/CPU0, 0)
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface
TenGigE0/1/0/0, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line
protocol on Interface TenGigE0/1/0/0, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface
TenGigE0/1/0/1, changed state to Down
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line
protocol on Interface TenGigE0/1/0/1, changed state to Down
コントローラは、インターフェイスがダウンした理由が次の原因であることを示しています DATA_PATH_DOWNを参照。ランダム データの例は次のとおりです。
RP/0/RSP0/CPU0:ASR9006-E#show controllers gigabitEthernet 0/0/0/13 internal
Wed Dec 18 02:42:52.221 UTC
Port Number : 13
Port Type : GE
Transport mode : LAN
BIA MAC addr : 6c9c.ed08.3cbd
Oper. MAC addr : 6c9c.ed08.3cbd
Egress MAC addr : 6c9c.ed08.3cbd
Port Available : true
Status polling is : enabled
Status events are : enabled
I/F Handle : 0x04000400
Cfg Link Enabled : tx/rx enabled
H/W Tx Enable : no
UDLF enabled : no
SFP PWR DN Reason : 0x00000000
SFP Capability : 0x00000024
MTU : 1538
H/W Speed : 1 Gbps
H/W Duplex : Full
H/W Loopback Type : None
H/W FlowCtrl type : None
H/W AutoNeg Enable: Off
H/W Link Defects : (0x00080000) DATA_PATH_DOWN <<<<<<<<<<<
Link Up : no
Link Led Status : Link down -- Red
Input good underflow : 0
Input ucast underflow : 0
Output ucast underflow : 0
Input unknown opcode underflow: 0
Pluggable Present : yes
Pluggable Type : 1000BASE-LX
Pluggable Compl. : (Service Un) - Compliant
Pluggable Type Supp.: (Service Un) - Supported
Pluggable PID Supp. : (Service Un) - Supported
Pluggable Scan Flg: false
バージョン4.3.1以降では、この動作を有効にする必要があります。これを行うために使用される新しいadmin-configコマンドがあります。デフォルトの動作ではポートをシャットダウンしないため、手動で設定する必要があります。
RP/0/RSP1/CPU0:ASR9010-A(admin-config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status
64ビットCisco IOS XRでは、コンフィギュレーションコマンドはXR VMで使用できます（Sysadmin VMでは使用できません）。
RP/0/RSP0/CPU0:CORE-TOP(config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status
Cisco Bug ID CSCui15435は、「TridentベースのラインカードでのブリッジまたはFPGAのソフトエラーによるトラフィックへの影響」セクションで説明されている、Tridentベースのラインカードで発生するソフトエラーを解決します。この場合、Cisco Bug ID CSCuc04493で説明されている通常の診断方法とは異なる検出方法が使用されます。
このバグにより、新しいadmin-config CLIコマンドも導入されました。
(admin-config)#fabric fia soft-error-monitor <1|2> location
1 = shutdown the ports
2 = reload the linecard
Default behavior: no action is taken.
このエラーが発生すると、次のsyslogが表示されます。
RP/0/RSP0/CPU0:Apr 30 22:17:11.351 : config[65777]: %MGBL-SYS-5-CONFIG_I : Configured
from console by root
LC/0/2/CPU0:Apr 30 22:18:52.252 : pfm_node_lc[283]:
%PLATFORM-BRIDGE-1-SOFT_ERROR_ALERT_1 : Set|fialc[159814]|NPU
Crossbar Fabric Interface Bridge(0x1024000)|Soft Error Detected on Bridge instance 1
RP/0/RSP0/CPU0:Apr 30 22:21:28.747 : pfm_node_rp[348]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:
(0/2/CPU0, 2) (0/2/CPU0, 3)
LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINK-3-UPDOWN :
Interface TenGigE0/2/0/2, changed state to Down
LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINEPROTO-5-UPDOWN :
Line protocol on Interface TenGigE0/2/0/2, changed state to Down
RP/0/RSP1/CPU0:Apr 30 22:21:35.086 : pfm_node_rp[348]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED :
Set|online_diag_rsp[237646]|System Punt/Fabric/data Path Test(0x2000004)|failure
threshold is 3, (slot, NP) failed: (0/2/CPU0, 2) (0/2/CPU0, 3)
影響を受けるポートがシャットダウンされると、ネットワークの冗長性が引き継がれ、トラフィックのブラックホール化が回避されます。回復するには、ラインカードをリロードする必要があります。
よく寄せられる質問（FAQ）
Q. プライマリまたはスタンバイ ルート プロセッサ カードは、システム内のすべての NP にキープアライブ パケットまたはオンライン診断パケットを送信しますか。
A. あります。どちらのルート プロセッサ カードも、すべての NP にオンライン診断パケットを送信します。
Q.ルートプロセッサカード1(RSP1)がアクティブな場合のパスは同じですか。
A.診断パスはRSP0とRSP1で同じです。パスはRSPの状態によって異なります。詳細は、このドキュメントの「パント ファブリック診断パケット パス」のセクションを参照してください。
Q. RSPは診断パケットをどのくらいの頻度で送信し、アラームがトリガーされるまでに失われる診断パケットはいくつありますか。
A.各RSPは、1分に1回、診断パケットをすべてのNPに個別に送信します。3つの診断パケットに対して確認応答がない場合、どちらのRSPもアラームをトリガーできます。
Q. NPがオーバーサブスクライブされているか、またはオーバーサブスクライブされたかはどのように判断するのですか。
A. NPが現在オーバーサブスクライブされているか、過去にオーバーサブスクライブされていたかを確認する1つの方法は、NP内の特定の種類のドロップとFIA内のテールドロップを確認することです。NP 内の Ingress Front Direct Memory Access（IFDMA）ドロップは、NP がオーバーサブスクライブされており、受信トラフィックを処理しきれない場合に発生します。FIA のテール ドロップは、出力 NP がフロー制御を通知する（入力ライン カードに対し、送信トラフィックを減らすよう求める）ときに発生します。フロー制御シナリオでは、入力 FIA でテール ドロップが発生します。
Q. NPにリセットが必要な障害が発生しているかどうかはどのように判断するのですか。
A.通常、NP障害は高速リセットによって解消されます。高速リセットの理由はログに表示されます。
Q. NPを手動でリセットできますか。
A.はい。ラインカードKSHでは次のようになります。
run attach 0/[x]/CPU0 #show_np -e [np#] -d fast_reset
Q. NPで回復不能なハードウェア障害が発生した場合、何が表示されますか。
A. NPのパントファブリックデータパスの障害とNPループバックテストの障害の両方が発生しています。NP ループバック テスト障害のメッセージは、このドキュメントの「付録」で説明します。
Q. 1つのルートプロセッサカードから送信された診断パケットは、同じルートプロセッサカードに戻りますか。
A.診断パケットは両方のルートプロセッサカードから発信され、ルートプロセッサカード単位で追跡されるため、ルートプロセッサカードから発信された診断パケットは、NPによって同じルートプロセッサカードにループバックされます。
Q. Cisco Bug ID CSCuj10837 SMUでは、ファブリックリンクの再確立イベントに対する修正が提供されています。これは、多くのパント ファブリック データ パス障害の原因と解決策ですか。
A.はい。ファブリックリンクの再確立イベントを回避するには、Cisco Bug ID CSCul39674の置き換えSMUをロードする必要があります。
Q. 再確立の決定が行われた後、ファブリック リンクの再確立にはどれくらいの時間がかかりますか。
A.再確立の決定は、リンク障害が検出されるとすぐに行われます。リリース 4.3.2 よりも前は、再確立に数秒かかることがありました。リリース 4.3.2 以降は、再確立の時間が大幅に短縮され、1 秒未満で終わります。
Q.ファブリックリンクの再確立は、どの時点で決定されるのですか。
A. リンク障害が検出されるとすぐに、再確立の決定がファブリック ASIC ドライバによって行われます。
Q.利用可能なリンクが複数ある場合、最初のリンクを使用するのは、アクティブルートプロセッサカードのFIAとファブリックの間だけで、その後のリンクは最小ロードになります。
A. そのとおりです。アクティブ ルート プロセッサ上の最初の XBAR インスタンスに接続する最初のリンクが、ファブリックにトラフィックを注入するために使用されます。NP からの応答パケットは、ルート プロセッサ カードに接続するすべてのリンクのどのアクティブ ルート プロセッサ カードへも到達できます。リンクの選択は、リンクの負荷に応じて行われます。
Q.再確立の間に、そのファブリックリンクを介して送信されるすべてのパケットが失われますか。
A.はい。ただし、リリース4.3.2以降の機能拡張により、再確立は事実上検出できません。ただし、以前のコードでは、再確立に数秒かかる可能性があり、その間はパケットが損失していました。
Q. Cisco Bug ID CSCuj10837の修正を含むリリースまたはSMUにアップグレードした後、XBARファブリックリンクの再確立イベントが発生すると予想される頻度はどのくらいですか。
A. Cisco Bug ID CSCuj10837の修正を行っても、Cisco Bug ID CSCul39674が原因でファブリックリンクの再確立が起こる可能性があります。ただし、Cisco Bug ID CSCul39674の修正を行えば、RSP440とTyphoonベースのラインカード間のファブリックバックプレーンリンクでのファブリックリンクの再トレーニングは発生しなくなります。再確立が発生する場合は、Cisco Technical Assistance Center（TAC）にサービス要求を出して、問題のトラブルシューティングを行ってください。
Q. Cisco Bug ID CSCuj10837およびCisco Bug ID CSCul39674は、Typhoonベースのラインカードを搭載したASR 9922のRPに影響を与えますか。
A.はい
Q. Cisco Bug ID CSCuj10837およびCisco Bug ID CSCul39674は、ASR-9001およびASR-9001-Sルータに影響を与えますか。
A.いいえ
Q. 10スロットシャーシで、このメッセージ「PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed: (8, 0)」が表示されないスロットの障害が発生した場合、問題のあるスロットはどれか？
A.以前のリリースでは、次に示すように物理マッピングと論理マッピングを考慮する必要があります。この例では、スロット 8 が 0/6/CPU0 に対応しています。
For 9010 (10 slot chassis)
L P
#0 --- #0
#1 --- #1
#2 --- #2
#3 --- #3
RSP0 --- #4
RSP1 --- #5
#4 --- #6
#5 --- #7
#6 --- #8
#7 --- #9
For 9006 (6 slot chassis)
L P
RSP0 --- #0
RSP1 --- #1
#0 --- #2
#1 --- #3
#2 --- #4
#3 --- #5
サービス要求を作成する前に収集すべきデータ
アクションを実行する前に出力を収集するための最低限のコマンドを次に示します。
show loggingshow pfm location alladmin show diagn result loc 0/rsp0/cpu0 test 8 detailadmin show diagn result loc 0/rsp1/cpu0 test 8 detailadmin show diagn result loc 0/rsp0/cpu0 test 9 detailadmin show diagn result loc 0/rsp1/cpu0 test 9 detailadmin show diagn result loc 0/rsp0/cpu0 test 10 detailadmin show diagn result loc 0/rsp1/cpu0 test 10 detailadmin show diagn result loc 0/rsp0/cpu0 test 11 detailadmin show diagn result loc 0/rsp1/cpu0 test 11 detailshow controller fabric fia link-status locationshow controller fabric fia link-status locationshow controller fabric fia bridge sync-status locationshow controller fabric crossbar link-status instance 0 locationshow controller fabric crossbar link-status instance 0 locationshow controller fabric crossbar link-status instance 1 locationshow controller fabric ltrace crossbar locationshow controller fabric ltrace crossbar locationshow tech fabric locationshow tech fabric locationfile
有効な診断コマンド
ここでは、診断に役立つコマンドの一覧を示します。
show diagnostic ondemand settingsshow diagnostic content location < loc >show diagnostic result location < loc > [ test {id|id_list|all} ] [ detail ]show diagnostic statusadmin diagnostic start location < loc > test {id|id_list|test-suite}admin diagnostic stop location < loc >- admin diagnostic ondemand iterations < iteration-count >
admin diagnostic ondemand action-on-failure {continue failure-count|stop}- admin-config番号
[ no ] diagnostic monitor location < loc > test {id | test-name} [disable] - admin-config番号
[ no ] diagnostic monitor interval location < loc > test {id | test-name} day hour:minute:second.millisec - admin-config番号
[ no ] diagnostic monitor threshold location < loc > test {id | test-name} failure count
結論
Cisco IOS XRソフトウェアリリース4.3.4以降では、パントファブリックデータパスの障害に関連するほとんどの問題に対処しています。Cisco Bug ID CSCuj10837およびCisco Bug ID CSCul39674の影響を受けるルータでは、ファブリックリンクの再確立イベントを回避するために、Cisco Bug ID CSCul39674の置き換えSMUをロードします。
プラットフォーム チームは、データ パスの復旧可能な障害が発生した場合に、ルータが 1 秒未満で回復できるように、最新の障害処理を実装しました。ただし、そのような障害が検出されない場合でも、この問題について理解するために、このドキュメントを読むことをお勧めします。
付録
NP のループバック診断パス
ライン カードの CPU で実行される診断アプリケーションは、NP の動作状態を定期的に確認することで、各 NP の稼働状態を追跡します。ライン カードの CPU からローカル NP 宛に注入されたパケットは、NP によってループバックされ、ライン カードの CPU に返されます。このような定期パケットの損失は、すべてプラットフォームのログ メッセージに記録されます。そのようなメッセージの例を次に示します。
LC/0/7/CPU0:Aug 18 19:17:26.924 : pfm_node[182]:
%PLATFORM-PFM_DIAGS-2-LC_NP_LOOPBACK_FAILED : Set|online_diag_lc[94283]|
Line card NP loopback Test(0x2000006)|link failure mask is 0x8
このログ メッセージは、このテストが NP3 からのループバック パケットを受信しなかったことを意味します。リンク障害マスクは 0x8（ビット 3 がオン）であり、スロット 7 のライン カード CPU と、スロット 7 の NP3 の間の障害を示します。
より詳細な情報を得るには、次のコマンドの出力を収集します。
admin show diagnostic result location 0//cpu0 test 9 detail show controllers NP counter NP<0-3> location 0//cpu0
ファブリック デバッグ コマンド
このセクションに示すコマンドは、すべての Trident ベースのライン カードと、Typhoon ベースの 100GE ライン カードに適用されます。ブリッジ FPGA ASIC は、Typhoon ベースのライン カードにはありません（100GE Typhoon ベースのライン カードを除く）。したがって、 show controller fabric fia bridge 100GEバージョンを除き、Typhoonベースのラインカードにはコマンドは適用されません。
ここに示す図は、各 show コマンドをデータ パス内の場所にマッピングするのに役立ちます。パケット ドロップと障害を特定するには、これらの show コマンドを使用します。
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
2.0 |
26-Jun-2023 |
Cisco Bug ID CSCuc04493の「自動回復機能の強化」セクションと「FAQ」セクションを更新。 |
1.0 |
29-Oct-2013 |
初版 |
フィードバック