排除ASR 9000系列Punt交換矩陣資料路徑故障
目錄
簡介
本檔案介紹在思科聚合服務路由器(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和Typed的線路卡上的錯誤。有關這些術語的說明，請參閱瞭解ASR 9000系列線卡型別。
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
如何使用本檔案
考慮有關如何使用本文檔，以收集基本詳細資訊，以及作為疑難排解過程中參考指南的建議：
- 如果突發交換矩陣資料路徑故障的根本原因並不緊急，請閱讀本文檔的所有部分。本文建立發生此類錯誤時隔離故障元件所需的必要背景。
- 如果您有需要快速回答的特定問題，請使用FAQ部分。如果問題未包括在常見問題部分中，則檢查主文檔是否解決了該問題。
- 使用Analyze Faults中的所有部分可在路由器出現故障時將問題隔離到故障元件，或檢查問題是否為已知問題。
背景資訊
根據線卡型別，資料包可通過交換機交換矩陣經過兩跳或三跳。Typen generation線卡新增了額外的交換矩陣元素，而基於Trident的線卡僅使用路由處理器卡上的交換矩陣來交換所有流量。以下圖表顯示這兩種線卡型別的交換矩陣元素，以及到路由處理器卡的交換矩陣連線：
Punt交換矩陣診斷資料包路徑
在路由處理器卡CPU上運行的診斷應用程式會定期向每個網路處理器(NP)注入診斷資料包。診斷資料包在NP內環回，然後被重新注入源於該資料包的路由處理器卡CPU。通過路由處理器卡上的診斷應用程式對每個NP具有唯一資料包的每個NP進行定期運行狀況檢查，可針對路由器操作期間資料路徑上的任何功能錯誤發出警報。必須注意的是，活動路由處理器和備用路由處理器上的診斷應用程式會定期為每個NP注入一個資料包，並維護每個NP的成功或失敗計數。當達到丟棄的診斷資料包的閾值時，應用程式會引發故障。
診斷路徑的概念檢視
在說明基於Trident和Typen的線卡上的診斷路徑之前，本節提供從活動路由處理器卡和備用路由處理器卡到線卡上的NP的交換矩陣診斷路徑的一般概述。
活動路由處理器卡和線卡之間的資料包路徑
從活動路由處理器注入到NP的交換矩陣的診斷資料包被交換矩陣視為單播資料包。對於單播資料包，交換機交換矩陣根據鏈路的當前流量負載選擇傳出鏈路，這有助於將診斷資料包置於路由器上的流量負載之下。當有多個指向NP的傳出鏈路時，交換矩陣ASIC會選擇當前負載最少的鏈路。
此圖說明源自活動路由處理器的診斷資料包路徑。
備用路由處理器卡和線卡之間的資料包路徑
從備用路由處理器注入到NP交換矩陣的診斷資料包被交換矩陣視為組播資料包。雖然它是組播資料包，但交換矩陣內部沒有複製。來自備用路由處理器的每個診斷資料包每次仍只能到達一個NP。從NP到路由處理器的響應資料包也是通過交換矩陣的組播資料包，沒有複製。因此，備用路由處理器上的診斷應用程式從NP接收單個響應資料包，一次一個資料包。診斷應用程式會跟蹤系統中的每個NP，因為它會為每個NP注入一個資料包，並期望每個NP的響應，一次一個資料包。對於組播資料包，交換機交換矩陣根據資料包報頭中的欄位值選擇傳出鏈路，這有助於在路由處理器卡和線卡之間的每條交換矩陣鏈路上注入診斷資料包。備用路由處理器在路由處理器卡和線卡插槽之間連線的每個交換矩陣鏈路上跟蹤NP運行狀況。
上圖說明源自備用路由處理器的診斷資料包路徑。請注意，與活動路由處理器機箱不同，所有將線卡連線到路由處理器上的XBAR的鏈路都會被執行。來自NP的響應資料包採用與路由處理器中的資料包到線卡方向相同的交換矩陣鏈路。此測試確保持續監控連線備用路由處理器和線卡的所有鏈路。
在基於Trident的線卡上提供交換矩陣診斷資料包路徑
此圖說明源自路由處理器的診斷資料包發往環迴路由處理器的NP。必須注意所有NP共用的資料路徑連結和ASIC，以及特定於NP子集的連結和元件。例如，網橋ASIC 0(B0)對於NP0和NP1是通用的，而FIA0對於所有NP是通用的。在路由處理器端，所有鏈路、資料路徑ASIC和現場可程式設計門陣列(FPGA)對於所有線卡都是通用的，因此對於機箱中的所有NP也是通用的。
在基於颱風的線路卡上提供交換矩陣診斷資料包路徑
此圖說明來源為路由處理器卡的診斷封包且目的地為NP且回送至路由處理器。必須注意所有NP共用的資料路徑連結和ASIC，以及特定於NP子集的連結和元件。例如，FIA0對於NP0和NP1是通用的。在路由處理器卡端，所有鏈路、資料路徑ASIC和FGPA對於所有線卡都是通用的，因此對於機箱中的所有NP也是通用的。
基於Tomahawk、Lightspeed和LightspeedPlus的線卡上的點陣結構診斷資料包路徑
戰斧式線卡上的FIA和NP之間有1:1的連通性。
在Lightspeed和LightspeedPlus線卡上，FIA整合在NP晶片中。
接下來的幾節將嘗試描繪通向每個NP的資料包路徑。這是瞭解點交換矩陣資料路徑錯誤消息以及定位故障點所必需的。
Punt交換矩陣診斷警報和故障報告
在基於ASR 9000的路由器中，如果未能從NP獲取響應，則會導致警報。當出現三個連續故障時，就會決定由路由處理器上執行的線上診斷應用程式發出警報。診斷應用程式為每個NP維護一個三資料包故障視窗。活動路由處理器和備用路由處理器獨立並行地進行診斷。主用路由處理器、備用路由處理器或兩個路由處理器卡都可能報告該錯誤。故障和丟包的位置決定了哪個路由處理器報告警報。
指向每個NP的診斷資料包的預設頻率為每60秒一個資料包或每分鐘一個資料包。
以下是警報訊息格式：
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到達NP 1、2、3、4、5、6和7的線卡0/7/cpu0。
從聯機診斷測試清單中，可以使用以下命令檢視punt fabric loopback test的屬性：
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測試頻率為每分鐘一個資料包，故障閾值為3，這表示不允許丟失三個連續的資料包，從而導致警報。顯示的測試屬性是預設值。要更改預設值，請輸入 diagnostic monitor interval 和 diagnostic monitor threshold 命令。
基於Trident的線路卡診斷資料包路徑
NP0診斷故障
交換矩陣診斷路徑
此圖說明路由處理器CPU和線卡NP0之間的資料包路徑。連線B0和NP0的鏈路是唯一一個特定於NP0的鏈路。所有其他鏈路都位於同一路徑中。
記下從路由處理器到NP0的資料包路徑。雖然有四條鏈路可用於從路由處理器發往NP0的資料包，但路由處理器和線卡插槽之間的第一條鏈路用於從路由處理器發往線卡的資料包。從NP0返回的資料包可以通過線卡插槽和活動路由處理器之間的兩個交換矩陣鏈路路徑中的任何一條傳送回活動路由處理器。選擇使用哪一條鏈路取決於當時的鏈路負載。從NP0到備用路由處理器的響應資料包使用兩條鏈路，但每次使用一條鏈路。根據診斷應用程式填充的報頭欄位來選擇鏈路。
NP0診斷故障分析
單一故障場景
如果檢測到單個平台故障管理器(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)
如前面的資料路徑圖所示，故障必須位於以下一個或多個位置：
- 連線NP0和B0的鏈路
- 指向NP0的B0隊列內部
- 內部NP0
多故障場景
多個NP故障
當在NP0上觀察到其他故障，或者同一線卡上的其他NP也報告故障PUNT_FABRIC_DATA_PATH_FAILED，則通過關聯所有故障來進行故障隔離。例如，如果NP0上同時發生PUNT_FABRIC_DATA_PATH_FAILED故障和LC_NP_LOOPBACK_FAILED故障，則NP已停止處理資料包。請參閱NP環回診斷路徑部分以瞭解環回故障。這可能是NP0內部出現嚴重故障的早期跡象。但是，如果僅發生兩個故障之一，則故障會定位到點交換矩陣資料路徑或線卡CPU上的NP路徑。
如果線卡上有多個NP存在點交換矩陣資料路徑故障，則必須沿交換矩陣鏈路的樹狀路徑向上移動，以隔離故障元件。例如，如果NP0和NP1都有故障，則故障必須位於B0或連線B0和FIA0的鏈路中。NP0和NP1同時遇到嚴重內部錯誤的可能性較小。雖然不太可能，但NP0和NP1可能會遇到由於不正確處理特定型別的資料包或錯誤資料包導致的嚴重錯誤故障。
兩個路由處理器卡都報告故障
如果活動路由處理器卡和備用路由處理器卡都向線卡上的一個或多個NP報告故障，則檢查受影響的NP與兩個路由處理器卡之間的資料路徑上的所有公共鏈路和元件。
NP1診斷故障
此圖說明路由處理器卡CPU和線卡NP1之間的資料包路徑。連線網橋ASIC 0(B0)和NP1的鏈路是唯一一個特定於NP1的鏈路。所有其他鏈路都位於同一路徑中。
記下從路由處理器卡到NP1的資料包路徑。雖然有四條鏈路可用於從路由處理器發往NP0的資料包，但路由處理器和線卡插槽之間的第一條鏈路用於從路由處理器發往線卡的資料包。從NP1返回的資料包可以通過線卡插槽和活動路由處理器之間的兩個交換矩陣鏈路路徑中的任何一條傳送回活動路由處理器。選擇使用哪一條鏈路取決於當時的鏈路負載。從NP1到備用路由處理器的響應資料包使用兩條鏈路，但每次使用一條鏈路。根據診斷應用程式填充的報頭欄位來選擇鏈路。
交換矩陣診斷路徑
NP1診斷故障分析
請參閱NP0診斷故障分析部分，但對NP1（而不是NP0）應用相同的推理。
NP2診斷故障
此圖說明路由處理器卡CPU和線卡NP2之間的資料包路徑。連線B1和NP2的鏈路是唯一一個特定於NP2的鏈路。所有其他鏈路都位於同一路徑中。
記下從路由處理器卡到NP2的資料包路徑。雖然有四個鏈路可用於從路由處理器發往NP2的資料包，但路由處理器和線卡插槽之間的第一個鏈路用於從路由處理器發往線卡的資料包。從NP2返回的資料包可以通過線卡插槽和活動路由處理器之間的兩個交換矩陣鏈路路徑中的任何一條傳送回活動路由處理器。選擇使用哪一條鏈路取決於當時的鏈路負載。從NP2到備用路由處理器的響應資料包使用兩條鏈路，但每次使用一條鏈路。根據診斷應用程式填充的報頭欄位來選擇鏈路。
交換矩陣診斷路徑
NP2診斷故障分析
請參閱NP0診斷故障分析部分，但對NP2（而不是NP0）應用相同的推理。
NP3診斷故障
此圖說明路由處理器卡CPU和線卡NP3之間的資料包路徑。連線網橋ASIC 1(B1)和NP3的鏈路是唯一特定於NP3的鏈路。所有其他鏈路都位於同一路徑中。
記下從路由處理器卡到NP3的資料包路徑。雖然有四條鏈路可用於從路由處理器發往NP3的資料包，但路由處理器和線卡插槽之間的第一條鏈路用於從路由處理器發往線卡的資料包。從NP3返回的資料包可以通過線卡插槽與活動路由處理器之間的兩個交換矩陣鏈路路徑中的任何一條傳送回活動路由處理器。選擇使用哪一條鏈路取決於當時的鏈路負載。從NP3到備用路由處理器的響應資料包使用兩條鏈路，但每次使用一條鏈路。根據診斷應用程式填充的報頭欄位來選擇鏈路。
交換矩陣診斷路徑
NP3診斷故障分析
請參閱NP0診斷故障分析部分，但對NP3（而不是NP0）應用相同的推理。
基於颱風的線路卡診斷資料包路徑
本節提供兩個示例，以便使用基於颱風的線卡建立交換矩陣分支資料包的背景。第一個示例使用NP1，第二個示例使用NP3。描述和分析可以擴展到任何基於颱風的線路卡上的其他NP。
颱風NP1診斷故障
下圖說明路由處理器卡CPU和線卡NP1之間的資料包路徑。連線FIA0和NP1的鏈路是唯一一個特定於NP1路徑的鏈路。線卡插槽和路由處理器卡插槽之間的所有其他鏈路都位於公共路徑中。將線卡上的交換矩陣XBAR ASIC連線到線卡上的FIA的鏈路特定於NP的子集。例如，線卡上FIA0和本地交換矩陣XBAR ASIC之間的兩條鏈路都用於發往NP1的流量。
記下從路由處理器卡到NP1的資料包路徑。雖然有八個鏈路可用於從路由處理器卡發往NP1的資料包，但路由處理器卡和線卡插槽之間使用一條路徑。從NP1返回的資料包可以通過線卡插槽和路由處理器之間的八個交換矩陣鏈路路徑傳送迴路由處理器卡。當診斷資料包將發迴路由處理器卡CPU時，每條鏈路都會執行一條鏈路。
交換矩陣診斷路徑
颱風NP3診斷故障
此圖說明路由處理器卡CPU和線卡NP3之間的資料包路徑。連線FIA1和NP3的鏈路是唯一一個特定於NP3路徑的鏈路。線卡插槽和路由處理器卡插槽之間的所有其他鏈路都位於公共路徑中。將線卡上的交換矩陣XBAR ASIC連線到線卡上的FIA的鏈路特定於NP的子集。例如，FIA1和線卡上的本地交換矩陣XBAR ASIC之間的兩條鏈路都用於到NP3的流量。
記下從路由處理器卡到NP3的資料包路徑。雖然有八個鏈路可用於從路由處理器卡發往NP3的資料包，但路由處理器卡和線卡插槽之間使用一條路徑。從NP1返回的資料包可以通過線卡插槽和路由處理器之間的八個交換矩陣鏈路路徑傳送迴路由處理器卡。當診斷資料包將發迴路由處理器卡CPU時，每條鏈路都會執行一條鏈路。
交換矩陣診斷路徑
基於Tomahawk的線卡診斷資料包路徑
由於FIA和NP之間存在1:1的連通性，通過FIA0的唯一流量是來自NP0。
基於Lightspeed — 和LightspeedPlus的線卡診斷資料包路徑
由於FIA整合在NP晶片中，通過FIA0的唯一流量是來往NP0。
分析故障
本節將故障分為硬故障和瞬時故障，並列出用於識別故障是硬故障還是瞬時故障的步驟。一旦確定故障型別，文檔將指定可在路由器上執行的命令，以便瞭解故障以及需要採取哪些糾正措施。
瞬時故障
如果一條PFM消息後跟一條clear 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)
瞬態故障糾正操作
建議對瞬態誤差採用的方法是僅監控此類誤差是否進一步出現。如果瞬變故障出現多次，則將瞬變故障視為硬故障，並使用建議和步驟來分析下一節中描述的此類故障。
硬故障
如果set 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)
硬錯誤糾正操作
在硬故障情形中，收集在服務請求建立之前收集的資料部分中提到的所有命令，然後開啟服務請求。在緊急情況下，收集所有故障排除命令輸出後，根據故障隔離啟動路由處理器卡或線卡重新載入。重新載入後，如果沒有復原錯誤，便會啟動退貨授權(RMA)。
分析瞬時故障
完成這些步驟，即可分析瞬時故障。
- 輸入
show logging | inc “PUNT_FABRIC_DATA_PATH"命令以發現錯誤是否發生一次或多次。 - 輸入
show pfm location all命令以確定當前狀態（SET或CLEAR）。錯誤是否未解決或已清除？如果錯誤狀態在SET和CLEAR之間變化，則交換矩陣資料路徑中的一個或多個故障會重複發生，並由軟體或硬體修復。 - 設定簡單網路管理協定(SNMP)陷阱或運行用於收集
show pfm location all命令輸出，並定期搜尋錯誤字串，以便監視將來出現的故障（當錯誤的最後狀態為CLEAR時，未出現新的故障）。
要使用的命令
輸入以下命令以分析瞬時故障：
show logging | inc “PUNT_FABRIC_DATA_PATH”show pfm location all
分析硬故障
如果將線卡上的交換矩陣資料路徑連結視為樹(背景資訊部分中介紹了詳細資訊)，則必須根據故障點推斷一個或多個NP是否不可訪問。當多個NP上出現多個故障時，請使用本節中列出的命令來分析故障。
要使用的命令
輸入以下命令以分析硬故障：
show logging | inc “PUNT_FABRIC_DATA_PATH”
輸出可以包含一個或多個NP（例如：NP2、NP3）。show controller fabric fia link-status location
由於NP2和NP3（在「颱風NP3診斷故障」部分）都通過單個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當前是否超額訂閱或過去是否超額訂閱的方法是檢查NP內部是否存在某種型別的丟包和FIA中的尾部丟包。當NP超訂用且無法跟上傳入流量時，NP內部的輸入前直接記憶體訪問(IFDMA)將會丟棄。當出口NP斷言流量控制（要求入口線卡傳送更少的流量）時，就會發生FIA尾部丟棄。在流量控制情況下，輸入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快速重置，則與這裡列出的日誌類似的日誌將顯示在基於颱風的線路卡中。健康監測機制在基於颱風的線卡上可用，但在基於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路由處理器和颱風線卡之間的故障
思科已解決以下問題：路由交換處理器(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上，並追蹤思科錯誤ID CSCuj10837和思科錯誤ID CSCul39674。
當路由器上發生此問題時，可能會發生以下任一情況：
- 鏈路關閉並啟動。（暫時）
- 鏈路將永久關閉。
思科錯誤ID CSCuj10837 - RSP和LC之間的交換矩陣重新培訓（TX方向）
為了確認，請從LC和兩個RSP收集ltrace輸出(show controller fabric crossbar ltrace location <>)，並檢查RSP跟蹤中是否顯示此輸出：
SMU已經可用
以下是範例：
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交叉開關交換矩陣介面的角度向基於Typed的線卡上的交換矩陣交叉開關介面的方向。
思科漏洞ID CSCuj10837的特徵在於，颱風線卡從RSP檢測到RX鏈路上的問題並啟動鏈路重新訓練。任一端（LC或RSP）均可啟動重新訓練事件。在思科錯誤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.
思科錯誤ID CSCul39674 - RSP和LC之間的交換矩陣重新培訓（RX方向）
為了確認，請從線卡和RSP(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 direction是指從RSP交叉開關交換矩陣介面的角度出發，從基於Typon的線卡上的交換矩陣交叉開關介面開始的方向。
思科漏洞ID CSCul39674的主要特徵是RSP從Typhoon線路卡檢測到RX鏈路上的問題並啟動鏈路重新訓練。任一端（LC或RSP）均可啟動重新訓練事件。在思科錯誤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版及更新版本中，為了減少重新培訓交換矩陣鏈路所需的時間，已經做了大量工作。交換矩陣重新訓練現在以亞秒為單位進行，對資料流是不可感知的。在Cisco IOS XR版本4.3.2中，發生交換矩陣鏈路重新訓練時，只看到這些系統日誌消息。
%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錯誤ID CSCul66510。此問題只影響基於Trident的線卡，並且僅在入口路徑嚴重擁塞的極少數情況下發生。如果遇到此問題，則在重置線路卡以從條件中恢復之前會顯示此系統日誌消息。
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錯誤ID CSCug90300解決，並在Cisco IOS XR版本4.3.2及更新版本中解決。Cisco IOS XR版本4.2.3 CSMU#3(思科錯誤ID CSCui33805)中也提供了此修補程式。基於三叉戟或颱風的線路卡上可能會遇到此罕見問題。
相關命令
從以下命令收集輸出：
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隊列的快速即時快照。此命令通常不會顯示任何排隊的資料包。
網橋/FPGA軟錯誤對基於Trident的線卡的影響
軟錯誤是導致狀態機不同步的非永久性錯誤。這些資料包在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
命令會提供所有聯機診斷測試和故障的摘要以及測試通過時的最後一個時間戳。Punt交換矩陣資料路徑故障的Test-ID為10。所有測試的清單以及測試資料包的頻率可在 show diagnostic content location
指令。
punt交換矩陣資料路徑測試結果的輸出與以下示例輸出類似：
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所述，現在有一種方法可讓路由器自動關閉與活動RP/RSP上引發的PUNT_FABRIC_DATA_PATH錯誤相關的所有連線埠。
第一個方法會透過思科錯誤ID CSCuc04493追蹤。版本4.2.3包含在思科錯誤ID CSCui33805中。在此版本中，它設定為自動關閉與受影響的NP關聯的所有埠。
以下範例顯示系統日誌的顯示方式：
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
思科錯誤ID CSCui15435解決了基於Trident的線卡上出現的軟錯誤，如Traffic Impact Due to Bridge/FPGA Soft Errors on Trident-Based Line Cards部分所述。這使用的檢測方法與思科錯誤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.
遇到此錯誤時，可觀察此系統日誌：
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)
問：主路由處理器卡或備用路由處理器卡是否向系統中的每個NP傳送keepalive或線上診斷資料包？
是的。兩個路由處理器卡將聯機診斷資料包傳送到每個NP。
問：路由處理器卡1(RSP1)處於活動狀態時，路徑是否相同？
A. RSP0或RSP1的診斷路徑相同。路徑取決於RSP的狀態。有關詳細資訊，請參閱本文檔的點陣結構診斷資料包路徑部分。
問：RSP傳送診斷資料包的頻率是多少？觸發警報之前必須丟失多少診斷資料包？
A.每個RSP每分鐘單獨向每個NP傳送一次診斷資料包。如果未確認三個診斷資料包，則任一RSP都可以觸發警報。
問：如何判斷某個NP是否超額使用？
A.檢查NP當前是否超額訂購或過去是否超額訂購的一種方法是，檢查NP內部是否存在某種型別的降落，以及FIA中是否存在尾部降落。當NP超訂用且無法跟上傳入流量時，NP內部的輸入前直接記憶體訪問(IFDMA)將會丟棄。當出口NP斷言流量控制（要求入口線卡傳送更少的流量）時，就會發生FIA尾部丟棄。在流量控制情況下，輸入FIA具有尾部捨棄專案。
問：如何判斷一個NP是否遇到需要重置的故障？
A.通常通過快速重置來清除NP故障。快速重置的原因顯示在日誌中。
問：是否可以手動重置NP?
A.是，從線卡KSH:
run attach 0/[x]/CPU0 #show_np -e [np#] -d fast_reset
問：如果一個NP出現不可恢復的硬體故障，會顯示什麼？
A.您可以看到該NP的點交換矩陣資料路徑故障以及NP環回測試故障。NP環回測試失敗消息將在本文檔的附錄部分討論。
問：來自一個路由處理器卡的診斷資料包是否會返回到同一個路由處理器卡？
A.由於診斷資料包源自兩個路由處理器卡，並且基於每個路由處理器卡進行跟蹤，因此，源自路由處理器卡的診斷資料包由NP環回到同一個路由處理器卡。
問：思科錯誤ID CSCuj10837 SMU修復了交換矩陣鏈路重新訓練事件。這是造成許多突發交換矩陣資料路徑故障的原因和解決方案嗎？
答：是，需要載入思科錯誤ID CSCul39674的替代SMU，才能避免交換矩陣鏈路重新訓練事件。
一旦做出重新訓練交換矩陣鏈路的決定，需要多長時間？
A.檢測到鏈路故障後立即作出重新訓練的決定。在4.3.2版之前，重新培訓可能需要幾秒時間。版本4.3.2之後，重新訓練時間已顯著改進，且花費不到一秒。
在什麼情況下會做出重新培訓交換矩陣鏈路的決定？
A.一旦檢測到鏈路故障，交換矩陣ASIC驅動程式就會做出重新訓練的決定。
問：只是在活動路由處理器卡上的FIA與您使用第一個鏈路的交換矩陣之間，然後是負載最小的鏈路（當有多個鏈路可用時）？
A.正確。使用連線到活動路由處理器上的第一個XBAR例項的第一條鏈路將流量注入交換矩陣。來自NP的響應資料包可以返回到連線到路由處理器卡的所有鏈路上的活動路由處理器卡。鏈路的選擇取決於鏈路負載。
問：在重新培訓期間，通過交換矩陣鏈路傳送的所有資料包是否都將丟失？
答：是，但是在4.3.2及更高版本中進行了增強，重新訓練幾乎無法檢測到。但是在早期的代碼中，重新訓練可能需要幾秒鐘，這會導致該時間段的資料包丟失。
問：升級到帶有思科錯誤ID CSCuj10837修復程式的版本或SMU後，您預計多長時間會看到XBAR交換矩陣鏈路重新培訓事件?
答：即使Cisco錯誤ID CSCuj10837已修正，由於Cisco錯誤ID CSCul39674，仍有可能看到交換矩陣鏈路重新訓練。但是，一旦您已修復Cisco錯誤ID CSCul39674,RSP440和基於Typen的線卡之間的交換矩陣背板鏈路上的交換矩陣鏈路再培訓就不應該發生。如果失敗，請向思科技術協助中心(TAC)提出服務要求以排解問題。
問：思科錯誤ID CSCuj10837和思科錯誤ID CSCul39674是否會影響帶有基於颱風的線卡的ASR 9922上的RP?
A.是
問：思科錯誤ID CSCuj10837和思科錯誤ID CSCul39674是否會影響ASR-9001和ASR-9001-S路由器？
A.否
問：如果您遇到插槽的故障，而此消息並不存在，則在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)」。
答：在早期版本中，必須考慮物理和邏輯對映，如下圖所示。在本示例中，插槽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 >- 管理診斷ondemand迭代< 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的時間框架起，大多數與分支交換矩陣資料路徑故障相關的問題都已得到解決。對於受思科錯誤ID CSCuj10837和思科錯誤ID CSCul39674影響的路由器，請載入取代思科錯誤ID CSCul39674的SMU，以避免交換矩陣鏈路重新培訓事件。
平台團隊安裝了最先進的故障處理功能，因此當發生任何資料路徑可恢復故障時，路由器可在數秒內恢復。但是，建議使用本文檔來瞭解此問題，即使未觀察到此類故障。
附錄
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（基於100GE颱風的線路卡除外）。所以， show controller fabric fia bridge 命令不適用於基於颱風的線卡，但100GE版本除外。
此圖形表示有助於將每個show命令對映到資料路徑中的位置。使用這些show命令以隔離封包捨棄和錯誤。
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
2.0 |
26-Jun-2023 |
已更新思科錯誤ID CSCuc04493的自動恢復增強功能部分，並更新常見問題部分。 |
1.0 |
29-Oct-2013 |
初始版本 |
意見