ルータ : Cisco ASR 9000 シリーズ アグリゲーション サービス ルータ

ASR 9000 シリーズ パント ファブリック データ パス障害のトラブルシューティング ガイド

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

目次

関連するシスコ サポート コミュニティ ディスカッション

概要

このドキュメントでは、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)

このドキュメントは、エラー メッセージを理解する必要がある人を対象に、問題が表示された場合に実行すべき処置について説明しています。

著者:Cisco TAC エンジニア、Mahesh Shirshyad、David Powers、Jean-Christophe Rode

前提条件

要件

シスコでは、次の項目について高度な知識があることを推奨しています。

  • 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 宛のパケットに対しては、ライン カード上のファブリック インターフェイス ASIC(FIA)をルート プロセッサ カード上のクロスバー(XBAR)に接続する最初のリンクが常に選択されます。 NP からの応答パケットには、リンク負荷分散アルゴリズムが適用されます(ライン カードが Typhoon ベースの場合)。 つまり、NP からアクティブ ルート プロセッサへの応答パケットは、ファブリック リンクの負荷に基づいて、ライン カードをルート プロセッサ カードに接続するどのファブリック リンクでも選択できます。

スタンバイ ルート プロセッサ カードとライン カードの間のパケット パス

スタンバイ ルート プロセッサから NP へ向かうファブリックに注入される診断パケットは、スイッチ ファブリックによってマルチキャスト パケットとして扱われます。 マルチキャスト パケットではあっても、ファブリック内部での複製は行われません。 スタンバイ ルート プロセッサから送信されたすべての診断パケットは、やはり一度に 1 つの NP のみに到達します。 NP からルート プロセッサ宛の応答パケットも、ファブリック上のマルチキャスト パケットであり、複製は行われません。 したがって、スタンバイ ルート プロセッサ上の診断アプリケーションは、NP からの 1 個の応答パケットを、一度に 1 パケットずつ受信します。 診断アプリケーションは、システム内のすべての NP を追跡します。これは、NP ごとに 1 個のパケットを注入し、一度に 1 パケットずつ、すべての NP からの応答を期待するためです。 マルチキャスト パケットの場合、スイッチ ファブリックはパケット ヘッダーのフィールド値に基づいて送信リンクを選択します。これは、ルート プロセッサ カードとライン カード間のすべてのファブリック リンク上で診断パケットを注入するのに役立ちます。 スタンバイ ルート プロセッサは、ルート プロセッサ カードとライン カード スロットの間を接続するすべてのファブリック リンク上で NP の稼働状態を追跡します。

前述の図は、スタンバイ ルート プロセッサから送信された診断パケットのパスを示しています。 アクティブ ルート プロセッサの場合とは異なり、ライン カードをルート プロセッサ上の XBAR に接続するすべてのリンクが調べられることに注意してください。 NP からの応答パケットは、ルート プロセッサからライン カードの方向にパケットが使用したのと同じファブリック リンクを使用します。 このテストにより、スタンバイ ルート プロセッサをライン カードに接続するすべてのリンクが継続的にモニタされます。

Trident ベースのライン カード上のパント ファブリック診断パケット パス

次の図は、ルート プロセッサが NP 宛に送信した診断パケットが、ルート プロセッサに向けてループバックされる様子を示しています。 すべての NP に共通するデータ パス リンクおよび ASIC と、NP のサブセットに固有のリンクおよびコンポーネントに注意することが重要です。 たとえば、ブリッジ ASIC 0(B0)は NP0NP1 に共通ですが、FIA0 はすべての NP に共通です。 ルート プロセッサ側では、すべてのリンク、データ パス ASIC、および Field-Programmable Gate Array(FPGA)がすべてのライン カードに共通であることから、シャーシ内のすべての NP に共通です。

Typhoon ベースのライン カード上のパント ファブリック診断パケット パス

次の図は、ルート プロセッサ カードが NP 宛に送信した診断パケットが、ルート プロセッサに向けてループバックされる様子を示しています。 すべての NP に共通するデータ パス リンクおよび ASIC と、NP のサブセットに固有のリンクおよびコンポーネントに注意することが重要です。 たとえば、FIA0NP0NP1 に共通です。 ルート プロセッサ カード側では、すべてのリンク、データ パス ASIC、および FGPA がすべてのライン カードに共通であることから、シャーシ内のすべての 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/7/cpu0 上の NP 123456、および 7 への、ルート プロセッサ 0/rsp0/cpu0 からの到達障害として読み取る必要があります。

オンライン診断テストのリストから、次のコマンドを使用してパント ファブリック ループバック テストの属性を確認できます。

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 つずつ調べられます。

ファブリック診断パス

障害の分析

ここでは、障害をハード障害と一時的な障害に分類し、障害がハード障害なのか一時的な障害なのかを特定するために使用する手順を示します。 障害の種類が判明した後で、障害と必要な修正措置について理解するために、ルータに対して実行可能なコマンドを示します。

一時的な障害

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)を開始します。

一時的な障害の分析

一時的な障害を分析するには、次の手順を実行します。

  1. show logging | inc "PUNT_FABRIC_DATA_PATH" コマンドを入力し、エラーが 1 回発生したか複数回発生したかを確認します。

  2. show pfm location all コマンドを入力し、現在のステータス(SET または CLEAR)を確認します。 エラーが残っているか、クリアされたかを判断します。 SET と CLEAR の間でエラー ステータスが変化する場合、ファブリック データ パス内で 1 つ以上の障害が繰り返し発生し、ソフトウェアまたはハードウェアで修正されます。

  3. Simple Network Management Protocol(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 <lc>

    NP2 と NP3(「Typhoon NP3 診断障害」のセクション)はいずれも 1 つの FIA を経由して送受信するため、障害がパス上の関連する FIA にあると推測するのが妥当です。

  • show controller fabric crossbar link-status instance <0 and 1> location <LC or RSP>

    ライン カード上のすべての NP に診断アプリケーションが到達不能な場合、ライン カード スロットをルート プロセッサ カードに接続するリンクで、ルート プロセッサ カードとライン カードの間のトラフィックを転送するいずれかの ASIC が障害になっていると推測するのが妥当です。

    show controller fabric crossbar link-status instance 0 location <lc>

    show controller fabric crossbar link-status instance 0 location 0/rsp0/cpu0

    show controller fabric crossbar link-status instance 1 location 0/rsp0/cpu0

    show controller fabric crossbar link-status instance 0 location 0/rsp1/cpu0

    show controller fabric crossbar link-status instance 1 location 0/rsp1/cpu0

  • show controller fabric fia link-status location 0/rsp*/cpu0

    show controller fabric fia link-status location 0/rsp0/cpu0

    show controller fabric fia link-status location 0/rsp1/cpu0

  • show controller fabric fia bridge sync-status location 0/rsp*/cpu0

    show controller fabric fia bridge sync-status location 0/rsp0/cpu0

    show controller fabric fia bridge sync-status location 0/rsp1/cpu0

    show tech fabric terminal


: すべてのライン カードのすべての NP で障害が報告される場合、障害の可能性が最も高いのはルート プロセッサ カードです(アクティブ ルート プロセッサ カードまたはスタンバイ ルート プロセッサ カード)。 「背説明景」のセクションで、ルート プロセッサ カードの CPU を FPGA およびルート プロセッサ カードの FIA に接続するリンクを参照してください。

過去の障害

これまでの例を見ると、障害の 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 で追跡されています。

この問題がルータで発生すると、以下のシナリオのいずれかが発生する可能性があります。

  1. リンクがダウンしアップします (一時的)。
  2. リンクがダウンしたままになります。

Cisco Bug ID CSCuj10837:RSP と LC の間のファブリックの再確立(TX 方向)

確認するためには、LC と両方の RSP から ltrace の出力を収集し(show controller fabric crossbar ltrace location <>)、RSP の ltrace に次の出力が表示されるかどうかを確認します。

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 の ltrace に次の出力が表示されるかどうかを確認します。

次に例を示します。

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 以降でのファブリックの再確立の違い

IOS-XR リリース 4.3.2 以降では、ファブリック リンクの再確立に要する時間を短縮するために、多くの作業が行われました。 ファブリックの再確立は、現在では 1 秒未満で実行されるようになり、トラフィック フローからは知覚できません。 リリース 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 で対処され、IOS-XR リリース 4.3.2 以降で解決されています。 この修正は、リリース 4.2.3 CSMU#3、SMU CSCui33805 でも提供されています。 このまれに発生する問題は、Trident または Typhoon ベースのライン カードで発生する可能性があります。

関連するコマンド

以下のコマンドを収集する必要があります。

  • show tech-support fabric
  • show controller fabric fia bridge flow-control location <LC> <=== この出力はすべての LC に対して取得します
  • show controllers fabric fia q-depth location <LC>

以下にいくつかの出力例を示します。

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 fabric
  • show tech-support np
  • show controller fabric fia bridge stats location <>(数回取得)

ブリッジまたは FPGA のソフト エラーからの回復

リカバリー方法は影響を受けたラインカードをリロードすることです。

RP/0/RSP0/CPU0:asr9k-1#hw-module location 0/6/cpu0 reload

オンライン診断テスト レポート

show diagnostic result location <node> [test <test-id> detail] コマンドは、すべてのオンライン診断テストおよび障害の要約と、テストに合格した場合の最後のタイムスタンプを表示します。 パント ファブリック データ パス障害のテスト ID は 10 です。 すべてのテストの一覧と、テスト パケットの頻度は、show diagnostic content location <node> コマンドで表示できます。

パント ファブリック データ パス テストの結果出力は、次の出力例のようになります。

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 バグ ID CSCuc04493 に記述されているように、ルータを PUNT_FABRIC_DATA_PATH エラーと対応づけられるポートすべてをシャットダウンしてもらう自動的に方法があります。

最初の方式は Cisco バグ ID CSCuc04493 によってトラッキングされます。 バージョン 4.2.3 に関しては、これは Cisco バグ ID CSCui33805 に含まれています。 このバージョンでは自動的に NPs と対応づけられるポートすべてをシャットダウンすることを、設定 します影響を受けている。

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

Cisco バグ ID によって CSCui15435 はここに記述されているように Trident ベースのラインカードで見られるソフトウェアエラーが、当たります。 これは Cisco バグ ID CSCuc04493 に説明がある通常診断方式より別の検出方法を使用します。

この不具合はまた新しい admin 設定 CLI コマンドをもたらしました:

(admin-config)#fabric fia soft-error-monitor <1|2> location <specific>

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 分あたり各 NP に独自に 診断パケットを一度送ります。 どちらかの RSP は 3 つの診断パケットが not aknowledged 場合アラームを引き起こすことができます。

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.  その NP については、パント ファブリック データ パス障害と、NP ループバック テスト障害の両方が表示されます。 NP ループバック テスト障害のメッセージは、このドキュメントの「付録」で説明します。

Q.  あるルート プロセッサ カードから送信された診断パケットは、同じルート プロセッサ カードに戻りますか。

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 CSCuj10837CSCul39674 は、Typhoon ベースのライン カードを使用した ASR 9922 上の RP に影響を与えますか。

A.  はい

Q.  Cisco Bug ID CSCuj10837CSCul39674 は、ASR-9001 および ASR-9001-S ルータに影響を与えますか。

A.  いいえ

Q. 存在しないスロットの障害が発生し、メッセージ「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)」が 10 スロット シャーシで表示される場合、どのスロットに問題がありますか。

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 logging
  • Show pfm location all
  • admin show diagn result loc 0/rsp0/cpu0 test 8 detail
  • admin show diagn result loc 0/rsp1/cpu0 test 8 detail
  • admin show diagn result loc 0/rsp0/cpu0 test 9 detail
  • admin show diagn result loc 0/rsp1/cpu0 test 9 detail
  • admin show diagn result loc 0/rsp0/cpu0 test 10 detail
  • admin show diagn result loc 0/rsp1/cpu0 test 10 detail
  • admin show diagn result loc 0/rsp0/cpu0 test 11 detail
  • admin show diagn result loc 0/rsp1/cpu0 test 11 detail
  • show controller fabric fia link-status location <lc>
  • show controller fabric fia link-status location <both rsp>
  • show controller fabric fia bridge sync-status location <both rsp>
  • show controller fabric crossbar link-status instance 0 location <lc>
  • show controller fabric crossbar link-status instance 0 location <both rsp>
  • show controller fabric crossbar link-status instance 1 location <both rsp>
  • show controller fabric ltrace crossbar location <both rsp>
  • show controller fabric ltrace crossbar location <affected lc>
  • show tech fabric location <fault showing lc> file <path to file>
  • show tech fabric location <both rsp> file <path to file>

有効な診断コマンド

ここでは、診断に役立つコマンドの一覧を示します。

  • show diagnostic ondemand settings
  • show diagnostic content location < loc >
  • show diagnostic result location < loc > [ test {id|id_list|all} ] [ detail ]
  • show diagnostic status
  • admin 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 CSCuj10837CSCul39674 の影響を受けるルータでは、ファブリック リンクの再確立イベントを回避するために、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/<x>/cpu0 test 9 detail
  • show controllers NP counter NP<0-3> location 0/<x>/cpu0 

ファブリック デバッグ コマンド

このセクションに示すコマンドは、すべての Trident ベースのライン カードと、Typhoon ベースの 100GE ライン カードに適用されます。 ブリッジ FPGA ASIC は、Typhoon ベースのライン カードにはありません(100GE Typhoon ベースのライン カードを除く)。 そのため、show controller fabric fia bridge コマンドは、Typhoon ベースのライン カードには適用されません(100GE 版を除く)。

ここに示す図は、各 show コマンドをデータ パス内の場所にマッピングするのに役立ちます。 パケット ドロップと障害を特定するには、これらの show コマンドを使用します。


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 116727