路由器 : Cisco ASR 9000 系列汇聚服务路由器

ASR 9000系列平底船结构数据路径失败排除故障指南

2016 年 10 月 24 日 - 机器翻译
其他版本: 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)

本文供要了解错误消息的人和应该采取的行动使用,如果问题被看到。

贡献由Mahesh Shirshyad,大卫鲍尔斯和吉恩克里斯托夫乘坐了, Cisco TAC工程师。

先决条件

要求

思科建议您有这些主题一高层次知识:

  • ASR 9000线卡
  • 结构卡
  • 路由处理器
  • 机箱体系结构

然而,本文不要求读者熟悉硬件详细信息。必要的背景信息,在错误消息解释前,提供。本文描述在三叉戟和基于台风的线卡的错误。 请参阅ASR 9000系列卡类型关于那些期限的说明。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。

如何使用本文

考虑关于如何的这些建议使用本文为了搜集重要详细信息和,在排除故障进程的参考指南:

  • 当没有紧急对根本原因每平底船结构数据路径失败时,请阅读本文的所有部分。当这样错误出现时,本文构件需要的必要的背景为了隔离有故障的组件。

  • 请使用FAQ部分,如果有一个特定问题在头脑里一快速答案是需要的。 如果问题在FAQ部分没有包括,则检查主要文件是否忙于问题。

  • 请使用所有从分析的部分故障为了离析问题有故障的组件,当路由器发生故障或为了检查时它是否是已知问题。

背景信息

数据包能通过交换矩阵横断两跳或三跳根据卡类型。而基于三叉戟的线卡交换与结构的所有流量在仅,路由处理器卡台风生成线卡添加一个额外的交换矩阵元素。这两种卡类型的这些图表show fabric元素,以及对路由处理器卡的结构连接:

平底船结构诊断程序包路径

在路由处理器卡CPU运行的诊断应用程序注入诊断程序包周期地被注定对每个网络处理器(NP)。诊断程序包被反向循环在NP里面,并且给再注射往源信息包数据包的路由处理器卡CPU。每位NP的此定期健康检查用一唯一数据包每位由诊断应用程序的NP在路由处理器卡为所有功能错误提供一警报在数据路径在路由器操作时。注意到是重要的,在活动路由处理器和暂挂路由处理器的诊断应用程序周期地注入每位NP一数据包并且维护a每NP成功或故障计数。当已丢失诊断程序包阈值达到时,应用程序培养故障。

诊断路径概念性视图

在本文描述三叉戟和基于台风的线卡的前诊断路径,此部分在线卡提供结构诊断路径的大纲从活动和暂挂路由处理器卡的往NP。

活动路由处理器卡和线卡之间的信息包路径

从活动路由处理器注入的诊断程序包往NP的结构被对待作为单播信息包由交换矩阵。使用单播信息包,交换矩阵选择根据链路的当前数据流负载的流出的链接,帮助对在路由器的数据流负载服从诊断程序包。当有往NP时的多个流出的链接,交换矩阵ASIC选择当前最不已加载的链路。

此图表表示从活动路由处理器来源的诊断程序包路径。

注意:连接在线卡的矩阵接口ASIC (FIA)到纵横制的第一条链路(XBAR)在路由处理器卡选择所有数据包的时期被注定对NP。(如果线卡台风根据),从NP的响应数据包对林克负载分布式算法被服从。这意味着从NP的响应数据包往活动路由处理器能选择连接线卡对根据结构连接装入的路由处理器卡的其中任一条结构链路。

暂挂路由处理器卡德和线卡之间的信息包路径

从暂挂路由处理器注入的诊断程序包往NP的结构被对待作为组播信息包由交换矩阵。虽然它是组播信息包,没有复制在结构里面。从暂挂路由处理器发出的每个诊断程序包每次只仍然到达一位NP。从NP的响应数据包往路由处理器也是在结构的一个组播信息包没有复制。因此,在暂挂路由处理器的诊断应用程序每次收到从NP的单个响应数据包,一数据包。诊断应用程序跟踪系统的每位NP,因为注入每位NP一数据包,并且每次预计从每位NP的答复,一数据包。使用组播信息包,交换矩阵选择根据在信息包报头的一个字段值的流出的链接,帮助注入在每个结构的诊断程序包连接路由处理器卡和线卡之间。待机路由处理器跟踪在连接在路由处理器卡和线路卡插槽之间的每条结构链路的NP健康。

上一个图表表示从暂挂路由处理器来源的诊断程序包路径。注意,不同于活动路由处理器盒,连接线卡对在路由处理器的XBAR练习的所有链路。从NP的响应数据包采取由数据包使用在对线卡方向的路由处理器的同一条结构链路。此测验保证连接暂挂路由处理器对线卡的所有链路不断地监控。

平底船结构基于三叉戟的线卡的诊断程序包路径

此图表表示路由处理器被发出的诊断程序包被注定对是循环往路由处理器的NP。注释对所有NP是普通是特定对NP的一子集的数据路径链路和ASIC是重要的,以及链路和组件。例如,网桥ASIC 0 (B0)对NP0NP1是普通,而FIA0对所有NP是普通。在路由处理器末端,所有链路、数据路径ASIC和现场可编程门阵列(FPGA)对所有线卡是普通,并且对在机箱的所有NP。

平底船结构基于台风的线卡的诊断程序包路径

此图表表示路由处理器卡被发出的诊断程序包被注定对是循环往路由处理器的NP。注释对所有NP是普通以及链路和组件是特定对NP的一子集的数据路径链路和ASIC是重要的。例如, FIA0NP0NP1是普通。在路由处理器卡末端,所有链路、数据路径ASIC和FGPA对所有线卡是普通,并且对在机箱的所有NP。

下几个部分尝试表示信息包路径到每位NP。这是必要为了了解平底船结构数据路径错误消息,并且为了找出失败点。

平底船结构诊断报警和失败报告

疏忽从ASR的NP得到答复9000根据路由器导致报警。决策由在路由处理器执行的在线诊断应用程序发出报警发生,当有三连续的失败。诊断应用程序维护每位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/7/cpu0 NP 1234567从路由处理器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测验频率每分钟是一数据包,并且失败阈值是三,暗示三连续数据包损耗没有被容忍并且导致报警。显示的测验属性是默认值。为了更改默认,请输入diagnostic monitor间隔diagnostic monitor阈值in命令管理配置模式。

基于三叉戟的线卡诊断程序包路径

NP0诊断失败

结构诊断路径

此图表表示路由处理器CPU和线卡NP0之间的信息包路径。连接B0和NP0的链路是唯一的链路特定对NP0。所有其他链路在普通的路径下跌。

记录下来信息包路径由往NP0的路由处理器。虽然有使用的四条链路数据包被注定往从路由处理器的NP0,路由处理器和线路卡插槽之间的第一条链路使用从路由处理器的数据包往线卡。从NP0的返回的数据包可以被退还的到在的活动路由处理器任何线路卡插槽和活动路由处理器之间的两个结构链路路径。选择哪个两条链路使用那时取决于连接装入。从NP0的响应数据包往暂挂路由处理器每次使用两条链路,但是一条链路。链路的选择根据诊断应用程序填充的报头字段。

NP0诊断故障分析

单个故障方案

如果有仅NP0的单个平台Fault Manager (PFM)平底船结构数据路径故障告警在故障消息检测,故障仅在连接路由处理器和线卡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
  • 内部的B0队列将NP0指向
  • 内部的NP0

多个故障方案

多个NP故障

当其他故障在NP0时被观察或故障PUNT_FABRIC_DATA_PATH_FAILED由在同一线卡的其他NP也报告,然后故障隔离由关联所有故障完成。例如,如果PUNT_FABRIC_DATA_PATH_FAILED故障和LC_NP_LOOPBACK_FAILED故障在NP0发生,然后NP停止处理数据包。参考的NP Loopback Diagnostic路径部分为了了解环回故障。这能是一个致命故障的一个早期的征兆在NP0里面。然而,如果仅一两个故障发生,然后故障本地化到平底船结构数据路径或在对NP路径的线路卡CPU。

如果超过线卡的一位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对在线卡的FIAs的链路是特定对NP的一子集。例如, FIA0和本地结构XBAR在线卡的ASIC之间的链路使用对NP1的流量。

记录下来信息包路径由往NP1的路由处理器卡。虽然有使用的八条链路数据包被注定往从路由处理器卡的NP1,使用路由处理器卡和线路卡插槽之间的一单一路径。从NP1的返回的数据包可以被退还的到路由处理器卡线路卡插槽和路由处理器之间的八个结构链路路径。当诊断程序包是注定的回到路由处理器卡CPU时,这八条链路中的每一条练习一次一个。

结构诊断路径

台风NP3诊断失败

此图表表示路由处理器卡CPU和线卡NP3之间的信息包路径。连接FIA1和NP3的链路是唯一的链路特定到NP3路径。所有线路卡插槽和路由处理器卡槽之间的其他链路在普通的路径下跌。连接在线卡的结构XBAR ASIC对在线卡的FIAs的链路是特定对NP的一子集。例如, FIA1和本地结构XBAR在线卡的ASIC之间的链路使用对NP3的流量。

记录下来信息包路径由往NP3的路由处理器卡。虽然有使用的八条链路数据包被注定往从路由处理器卡的NP3,使用路由处理器卡和线路卡插槽之间的一单一路径。从NP1的返回的数据包可以被退还的到路由处理器卡线路卡插槽和路由处理器之间的八个结构链路路径。当诊断程序包是注定的回到路由处理器卡CPU时,这八条链路中的每一条练习一次一个。

结构诊断路径

分析故障

如果故障是一个硬或瞬变故障,此部分分类故障到硬和瞬变案件,并且列出用于的步骤为了识别。一旦确定故障类型,本文指定在路由器可以被执行为了了解故障的命令,并且什么纠正措施是需要的。

瞬变故障

如果集合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)

困难的过失纠正措施

在一个困难的过失方案下,请收集在数据提及的所有命令收集,在服务请求创建部分和打开服务请求前。在紧急案件中,在您收集所有故障排除命令输出后,请启动根据故障隔离或线卡重新加载的路由处理器卡。在重新加载,如果错误没有被恢复后,启动退货授权(RMA)。

分析瞬变故障

完成这些步骤为了分析瞬变故障。

  1. 输入show logging|Inc “PUNT_FABRIC_DATA_PATH”命令为了发现,如果错误曾经或多次出现。

  2. 输入all命令显示pfm的位置为了确定当前状态(SET或结算)。错误是否是未清或清除?如果错误状态更改在SET和结算之间,则在结构数据路径内的一个或更多故障由软件或硬件重复发生和纠正。

  3. 设置简单网络管理协议(SNMP)陷阱或运行收集周期地显示pfm位置all命令输出和搜索错误串的为了监控故障的将来出现的脚本(当错误的最后状况是清楚的时,并且新的故障不发生)。

命令使用

输入这些命令为了分析瞬变故障:

  • show logging|Inc “PUNT_FABRIC_DATA_PATH”
  • 显示pfm位置全部 

分析困难的过失

如果查看结构数据路径在线卡连接作为树(其中详细信息在Background Information部分描述),则您必须推断-基于问题的故障-一个或更多NP是否是不可访问的。当多个故障在多个NP时发生,然后请使用列出的命令在此部分为了分析故障。

命令使用

输入这些命令为了分析困难的过失:

  • show logging|Inc “PUNT_FABRIC_DATA_PATH”

    输出也许包含一个或更多NP (示例:NP2, NP3)。

  • show controller结构fia link-status位置<lc>

    因为NP2和NP3 (在台风NP3诊断失败部分)通过单个FIA接收和发送,推断是合理的故障在路径的相关的FIA。

  • show controller结构纵横制link-status实例<0和1>位置<LC或RSP>

    如果在线卡的所有NP为诊断应用程序不是可及的,则推断是合理的连接线路卡插槽对路由处理器卡的链路也许有在的一个故障任何ASIC路由处理器卡和线卡之间的向前流量。

    show controller结构纵横制link-status实例0位置<lc>

    show controller结构纵横制link-status实例0位置0/rsp0/cpu0

    show controller结构纵横制link-status实例1位置0/rsp0/cpu0

    show controller结构纵横制link-status实例0位置0/rsp1/cpu0

    show controller结构纵横制link-status实例1位置0/rsp1/cpu0

  • show controller结构fia link-status位置0/rsp*/cpu0

    show controller结构fia link-status位置0/rsp0/cpu0

    show controller结构fia link-status位置0/rsp1/cpu0

  • show controller结构fia桥接同步状态位置0/rsp*/cpu0

    show controller结构fia桥接同步状态位置0/rsp0/cpu0

    show controller结构fia桥接同步状态位置0/rsp1/cpu0

    show tech结构终端


注意:如果所有在所有的NP线卡报告故障,则故障是很可能在路由处理器卡(活动路由处理器卡或待机路由处理器卡)。参考连接路由处理器卡CPU对FPGA和路由处理器卡FIA在Background Information部分的链路。

通过失败

历史上,故障的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的尾部丢弃。入口前面直接存储器访问(IFDMA)丢包在NP里面发生,当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快速重置,然后记录类似于列出得什么此处为一基于台风的线卡出现。健康监控机制是可用的在基于台风的线卡,但是不在基于三叉戟的线卡。

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

对于基于三叉戟的线卡,此日志在NP的快速重置看到:

LC/0/1/CPU0:Mar 29 15:27:43.787 test:
pfm_node_lc[279]: Fast Reset initiated on NP3

在RSP440路由处理器和台风线卡之间的失败

思科修复很少路由交换机处理器(RSP) 440和基于台风的线卡之间的结构链路在背板间被再培训的问题。因为信号强度不是最佳的,结构链路被再培训。此问题是存在基本Cisco IOS XR软件版本4.2.1, 4.2.2, 4.2.3, 4.3.0, 4.3.1和4.3.2。软件维护更新(SMU)为这些版本中的每一在Cisco在线连接被张贴,并且跟踪与Cisco Bug ID CSCuj10837和Cisco Bug ID CSCul39674

当此问题在路由器时出现,这些方案中的任一个能发生:

  1. 链路断开并且出来。(临时)
  2. 链路断开永久。

Cisco Bug ID CSCuj10837在RSP和LC (TX方向)之间的结构再培训

为了确认,从LC请收集ltrace输出和RSPs (show controller结构纵横制ltrace位置<>)和检查此输出是否在RSP ltrace被看到:

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方向是指从RSPs Crossbar结构接口的支架的方向往一个结构纵横制接口的在一基于台风的线卡。

Cisco Bug ID CSCuj10837描绘为一问题的台风线卡的检测在RX链路再培训的链路从RSP和开始的。任一侧(LC或RSP)可以启动再培训事件。一旦Cisco Bug ID CSCuj10837, LC启动再培训,并且可以由init xbar_trigger_link_retrain检测:在跟踪的消息在LC。

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在trace输出中报告一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方向)之间的结构再培训

为了确认,从线卡请收集ltrace输出和RSPs (show controller结构纵横制ltrace位置<>)和检查此输出是否在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方向是指从RSPs Crossbar结构接口的支架的方向从一个结构纵横制接口的在一基于台风的线卡。

Cisco Bug ID CSCul39674描绘为一问题的RSP的检测在RX链路再培训的链路从台风线卡和开始的。任一侧(LC或RSP)可以启动再培训事件。一旦Cisco Bug ID CSCul39674, RSP启动再培训,并且可以由init xbar_trigger_link_retrain检测:在跟踪的消息在RSP。

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在trace输出中报告一个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的一条结构链路及以后的重大工作是完成为了减小时间。结构再培训当前在分秒的时期发生并且是细微的对通信流。在这些的版本,当结构链路再培训发生, 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溢出

思科修复ASIC矩阵的问题(FIA)也许获得重置由于一个不可恢复的先入先出(FIFO)溢出条件。这寻址与Cisco Bug ID CSCul66510。此问题只影响基于三叉戟的线卡和在罕见的情况下只遇到与大量入口路径拥塞。如果此问题遇到,此系统消息显示,在线路卡重置从情况前恢复。 

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)积累

思科修复延长的严重拥塞也许导致结构资源耗尽和数据流损失的问题。数据流损失在无关的流能均等发生。此问题在IOS-XR版本4.3.2涉及与Cisco Bug ID CSCug90300和被解决及以后。修正在版本4.2.3 CSMU#3也传送, SMU CSCui33805。此少见问题在三叉戟或基于台风的线卡也许遇到。

相关命令

您应该搜集这些命令:

  • show tech-support fabric
  • show controller结构fia桥接flow-control位置<LC> <===得到所有LCs的此输出
  • show controllers结构fia问深度位置<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#

在nomal情况下,发现一个VOQ用排队的数据包是不太可能的。此命令是FIA队列的一个快速实时快照。它是普通为了此命令能不显示排队的任何数据包。 

流量影响由于Bridge/FPGA软件错误在基于三叉戟的线卡

软件错误是造成状态机是不同步的编外的错误。 这些被看到作为循环冗余冗余校验(CRC),帧校验序列或者错误状态的数据包在NP的结构侧或在FIA的入口侧。

这是一些示例此问题如何能被看到:

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 <==========

命令为在基于三叉戟的线卡的Bridge/FPGA软件错误采集

您应该搜集这些命令:

  • show tech-support fabric
  • show tech-support np
  • show controller结构fia桥接stats位置<> (请得到几次)

从Bridge/FPGA软件错误的恢复

恢复方法将重新加载受影响的线卡。

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

Test报告的在线诊断

当测验通过, show diagnostic结果位置<node> [test <test-id> detail]命令提供所有在线诊断测验摘要和失败以及上次时间标记。平底船结构数据路径失败的TEST ID是十。所有的列表与频率的测验测试数据包一起能在show diagnostic content位置<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 Bug ID CSCuc04493所描述,自动地当前有方式安排路由器关闭关联与PUNT_FABRIC_DATA_PATH错误的所有端口。

第一种方法通过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和以上,必须启用此行为。有config命令新的admin使用为了完成此。因为默认行为不再是关闭端口,必须手工配置这。

RP/0/RSP1/CPU0:ASR9010-A(admin-config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status

Cisco Bug ID CSCui15435论及在基于三叉戟的线卡被看到的软件错误,如描述此处。这比在Cisco Bug ID CSCuc04493描述的通常诊断方法使用一不同的Detection Method。

此bug也介绍CLI命令一新的admin的配置

(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.主要的或暂挂路由处理器卡是否发送Keepalive或在线诊断数据包到系统的每位NP ?

A. 可以。两个路由处理器卡发送在线诊断数据包到每位NP。

问。 路径同样,当路由处理器卡一(RSP1)时是活跃的?

A. 诊断路径是相同的为RSP0或RSP1。路径依靠RSP的状态。欲了解更详细的信息参考本文的平底船结构诊断程序包路径部分。

Q.必须未命中多频繁RSPs发送诊断程序包,并且多少个诊断程序包,在报警被触发前?

A. 每RSP独立地发送诊断程序包到每位NP一次每分钟。如果三个诊断程序包没有aknowledged,任一RSP能触发报警。

问。 如何确定NP是否是或过度了预定?

A. 一种方式检查如果NP从前当前过度预定或过度了预定将检查一某一丢弃在NP里面和在FIA的尾部丢弃。入口前面直接存储器访问(IFDMA)丢包在NP里面发生,当NP是订购过量的,并且不能跟上流入的数据流。FIA尾部丢弃发生,当出口NP明示流量控制(请求进入线路卡发送较少流量)。在流量控制方案下,入口FIA有尾部丢弃。

问。 如何确定NP是否遭受要求重置的它的故障?

A. 一般,非难快速重置清除NP。快速重置的原因在日志显示。

问。 如果NP有一个非可重获的硬件故障,什么显示?

A. 您为该NP看到平底船结构数据路径失败以及NP环回测试失败。NP环回测试故障消息在附录本文部分讨论。

问。 从一个路由处理器卡被发出的诊断程序包是否将来上一步到同样一个?

A. 因为诊断程序包从两个路由处理器卡在a被发出并且被跟踪每个路由处理器卡基本类型,从路由处理器卡发出的诊断程序包被反向循环对同样路由处理器卡由NP。

问。 Cisco Bug ID CSCuj10837 SMU为结构链路再培训事件提供一个修正。这原因和解决方案为许多平底船结构数据路径失败?

A. 是,它将要求装载Cisco Bug ID的CSCul39674取代的SMU为了避免结构链路再培训事件。

Q.,一旦决定如此执行做出,为了多长时间需要再培训结构链路?

A. 当链路故障检测,决定再培训做出。在版本4.3.2前,再培训可能用几秒钟。在版本4.3.2以后,再培训时间少于一秒钟极大改善并且采取。

问。 在什么点决策再培训是否是结构链路做?

A.当链路故障检测,决定再培训由ASIC矩阵驱动程序做出。

问。 仅它在活动路由处理器卡的FIA和结构之间您使用第一条链路,然后以后它是最少已加载链路,当有可用的多条链路?

A.正确。连接对第一个XBAR在活动路由处理器的实例的第一条链路用于为了注入流量结构。从NP的响应数据包能到达回到在的活动路由处理器卡任何连接对路由处理器卡的所有链路。链路的选择取决于连接装入。

问。 在再培训期间,在该结构链路被发送的所有信息包丢失?

A. 是,但是与在版本4.3.2的增强及以后,再培训实际上undetectible。然而,用早期代码,它可能用几秒钟再培训,导致该时间段的丢失的数据包。

问。 多么,在您升级对版本或SMU以修正Cisco Bug ID的CSCuj10837后,频繁地期望发现XBAR结构连接再培训事件?

A. 以Cisco Bug ID的CSCuj10837修正发现结构连接再培训由于Cisco Bug ID CSCul39674是可能的。 但是,一旦客户有Cisco Bug ID的CSCul39674修正,结构在结构背板链路的链路再培训RSP440和基于台风的线卡之间不应该发生。如果它,则提高一服务请求以Cisco技术支持中心(TAC)为了排除故障问题。

问。 Cisco Bug ID是否CSCuj10837CSCul39674影响在ASR 9922的RP与基于台风的线卡?

A. 是

问。 Cisco Bug ID是否CSCuj10837CSCul39674影响ASR-9001和ASR-9001-S路由器?

A. 否

问。如果遇到不存在与此消息slot的失败, "PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED :Set|online_diag_rsp[237686]|System平底船/结构/数据路径Test(0x2000004)|failure阈值是3, (slot, NP)失败:(8, 0),"在10 SLOT机箱, slot有问题?

A.在更旧的版本中,您必须占物理和逻辑映射如显示此处。在本例中, slot 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
  • 显示pfm位置全部
  • admin显示diagn结果位置0/rsp0/cpu0测验8详细信息
  • admin显示diagn结果位置0/rsp1/cpu0测验8详细信息
  • admin显示diagn结果位置0/rsp0/cpu0测验9详细信息
  • admin显示diagn结果位置0/rsp1/cpu0测验9详细信息
  • admin显示diagn结果位置0/rsp0/cpu0测验10详细信息
  • admin显示diagn结果位置0/rsp1/cpu0测验10详细信息
  • admin显示diagn结果位置0/rsp0/cpu0 test11详细信息
  • admin显示diagn结果位置0/rsp1/cpu0 test11详细信息
  • show controller结构fia link-status位置<lc>
  • show controller结构fia link-status位置<both rsp>
  • show controller结构fia桥接同步状态位置<both rsp>
  • show controller结构纵横制link-status实例0位置<lc>
  • show controller结构纵横制link-status实例0位置<both rsp>
  • show controller结构纵横制link-status实例1位置<both rsp>
  • show controller结构ltrace纵横制位置<both rsp>
  • show controller结构ltrace纵横制位置<affected lc>
  • show tech结构显示lc>文件<path的位置<fault对file>
  • show tech结构位置<both rsp>对file>的文件<path

有用的诊断命令

这是有用的诊断目的命令的列表:

  • show diagnostic ondemand setting
  • show diagnostic content位置<位置>
  • show diagnostic结果位置<位置> [测验{id|id_list|所有}] [detail]
  • show diagnostic状态
  • admin诊断启动位置<位置>测验{id|id_list|测试套件}
  • admin诊断停靠地点<位置>
  • admin diagnostic ondemand iterations <迭代计数>
  • admin diagnostic ondemand action-on-failure {请继续故障计数|终止}
  • Adminconfig# [no] diagnostic monitor位置<位置>测验{id|TEST NAME} [disable]
  • Adminconfig# [no] diagnostic monitor间隔位置<位置>测验{id|TEST NAME}天小时:分钟:second.millisec
  • Adminconfig# [no] diagnostic monitor阈值位置<位置>测验{id|TEST NAME}故障计数

结论

从Cisco IOS XR软件版本4.3.4时间段,涉及的多数问题踢结构数据路径失败解决。对于Cisco Bug ID影响的路由器CSCuj10837CSCul39674的,请装载CSCul39674的取代的SMU为了避免结构链路再培训事件。

平台团队安装科技目前进步水平故障处理,以便路由器在低秒回复,如果和当所有数据路径可退回的失败发生。然而,推荐本文为了了解此问题,即使这样故障没有被观察。

附录

NP Loopback Diagnostic路径

诊断应用程序在线路卡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设置),指示在线路卡CPU之间的一失败在slot 7.的slot的7和NP3。

为了得到更多详细信息,请收集这些命令输出:

  • admin show diagnostic结果位置0/<x>/cpu0测验9详细信息
  • show controllers NP抵抗NP<0-3>位置0/<x>/cpu0 

结构调试指令

在此部分列出的命令适用对所有基于三叉戟的线卡以及基于台风的100GE线卡。网桥FPGA ASIC不是存在基于台风的线卡(除了100GE基于台风的线卡)。因此, show controller结构fia桥接命令不适用于基于台风的线卡,除了100GE版本。

此绘画作品在数据路径帮助映射中的每一show命令对位置。请使用这些显示命令为了隔离丢包和故障。



Document ID: 116727