목차

소개

사전 요구 사항

요구 사항

사용되는 구성 요소

이 문서의 사용 방법

배경 정보

Punt 패브릭 진단 패킷 경로

진단 경로의 개념도

활성 Route Processor Card와 라인 카드 간의 패킷 경로

Standby Route Processor Card와 라인 카드 간의 패킷 경로

Trident 기반 라인 카드의 Punt 패브릭 진단 패킷 경로

태풍 기반 라인 카드의 Punt 패브릭 진단 패킷 경로

Tomahawk-, Lightspeed- 및 LightspeedPlus 기반 라인 카드의 Punt Fabric 진단 패킷 경로

Punt Fabric 진단 경보 및 오류 보고

Trident 기반 라인 카드 진단 패킷 경로

NP0 진단 실패

NP0 진단 실패 분석

NP1 진단 실패

NP1 진단 실패 분석

NP2 진단 실패

NP2 진단 실패 분석

NP3 진단 실패

NP3 진단 실패 분석

태풍 기반 라인 카드 진단 패킷 경로

태풍 NP1 진단 실패

태풍 NP3 진단 실패

토마호크 기반 라인 카드 진단 패킷 경로

Lightspeed 및 LightspeedPlus 기반 라인 카드 진단 패킷 경로

결함 분석

일시적 결함

일시적 결함 해결 조치

하드 결함

하드 결함 해결 조치

일시적 결함 분석

사용할 명령

하드 결함 분석

사용할 명령

과거 실패

NP 오버서브스크립션으로 인한 일시적인 오류

NP Fast Reset으로 인한 하드 결함

RSP440 Route Processor 및 Typhoon Line Card 간 장애

Cisco 버그 ID CSCuj10837 - RSP와 LC 사이의 패브릭 재교육(TX 방향)

Cisco 버그 ID CSCul39674 - RSP와 LC 사이의 패브릭 재교육(RX 방향)

Fabric Retrain 릴리스 4.3.2 이상에서 차이

패브릭 ASIC FIFO 오버플로로 인한 오류

패브릭 혼잡에서 과중한 VOQ(Virtual Output Queue) 빌드업으로 인한 실패

관련 명령

Trident 기반 라인 카드의 브리지/FPGA 소프트 오류로 인한 트래픽 영향

Trident 기반 라인 카드에서 브리지/FPGA 소프트 오류에 대해 수집할 명령

Bridge/FPGA 소프트 오류에서 복구

온라인 진단 테스트 보고서

자동 복구 개선 사항

FAQ(자주 묻는 질문)

서비스 요청 생성 전에 수집할 데이터

유용한 진단 명령

결론

부록

NP 루프백 진단 경로

패브릭 디버그 명령

소개

이 문서에서는 Cisco ASR(Aggregation Services Router) 9000 Series 작동 중에 나타나는 punt 패브릭 데이터 경로 오류 메시지에 대해 설명합니다.

메시지는 다음과 같은 형식으로 표시됩니다.

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에서는 다음 항목에 대해 높은 수준의 지식을 갖춘 것을 권장합니다.

- ASR 9000 라인 카드

- 패브릭 카드

- Route Processor

- 섀시 아키텍처

그러나 이 문서에서는 독자가 하드웨어 세부 사항을 숙지할 필요가 없습니다. 필요한 배경 정보는 오류 메시지가 설명되기 전에 제공됩니다. 이 문서에서는 Trident 및 Typhoon 기반 라인 카드의 오류를 설명합니다. 해당 용어에 대한 설명은 ASR 9000 Series 라인 카드 유형 이해를 참조하십시오.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

이 문서의 사용 방법

필수 세부 사항을 수집하고 트러블슈팅 프로세스에서 참조 설명서로 활용하기 위해 이 문서를 사용하는 방법에 대한 다음 제안을 고려하십시오.

- 펀트 패브릭 데이터 경로 오류를 근본 원인을 찾아내야 하는 긴급한 상황이 아니면 이 문서의 모든 섹션을 읽어 보십시오. 이 문서에서는 이러한 오류가 발생할 때 결함이 있는 구성 요소를 격리하기 위해 필요한 배경을 작성합니다.

- 빠른 답변이 필요한 특정 질문이 있는 경우 FAQ 섹션을 사용합니다. FAQ 섹션에 질문이 포함되어 있지 않으면 기본 문서에서 해당 질문을 다룹니다.

- 라우터에 결함이 발생했을 때 결함 구성 요소로 문제를 격리하거나 알려진 문제인지 확인하려면 Analyze Faults on의 모든 섹션을 사용합니다.

배경 정보

패킷은 라인 카드 유형에 따라 스위치 패브릭을 통해 2개의 홉 또는 3개의 홉을 통과할 수 있습니다. 태풍 발생 라인 카드는 추가 스위치 패브릭 요소를 추가하는 반면, 트라이던트 기반 라인 카드는 경로 프로세서 카드의 패브릭으로만 모든 트래픽을 전환합니다. 다음 다이어그램은 이러한 라인 카드 유형에 대한 패브릭 요소 및 Route Processor Card에 대한 패브릭 연결을 보여줍니다.

Punt 패브릭 진단 패킷 경로

경로 프로세서 카드 CPU에서 실행되는 진단 애플리케이션은 각 NP(Network Processor)에 진단 패킷을 주기적으로 삽입합니다. 진단 패킷은 NP 내부에서 루프백되고 패킷을 소싱한 경로 프로세서 카드 CPU에 다시 삽입됩니다. 라우트 프로세서 카드의 진단 애플리케이션이 NP당 고유한 패킷을 갖는 모든 NP에 대한 정기적인 상태 확인은 라우터 작동 중 데이터 경로의 모든 기능 오류에 대한 알림을 제공합니다. 액티브 경로 프로세서와 스탠바이 경로 프로세서의 진단 애플리케이션은 NP당 한 개의 패킷을 주기적으로 삽입하며 NP당 성공 또는 실패 횟수를 유지합니다. 삭제된 진단 패킷의 임계값에 도달하면 애플리케이션에서 오류를 발생시킵니다.

진단 경로의 개념도

이 문서에서는 Trident 및 Typhoon 기반 라인 카드의 진단 경로를 설명하기 전에 활성 및 대기 Route Processor 카드에서 라인 카드의 NP로 향하는 패브릭 진단 경로의 일반적인 개요를 제공합니다.

활성 Route Processor Card와 라인 카드 간의 패킷 경로

활성 경로 프로세서에서 NP를 향해 패브릭으로 주입된 진단 패킷은 스위치 패브릭에서 유니캐스트 패킷으로 처리됩니다. 유니캐스트 패킷을 사용하는 경우 스위치 패브릭은 링크의 현재 트래픽 로드를 기준으로 발신 링크를 선택합니다. 그러면 진단 패킷이 라우터의 트래픽 로드를 처리하는 데 도움이 됩니다. NP를 향하는 나가는 링크가 여러 개 있는 경우, 스위치 패브릭 ASIC는 현재 로드가 가장 적은 링크를 선택합니다.

이 다이어그램에는 활성 경로 프로세서에서 소싱된 진단 패킷 경로가 나와 있습니다.

참고: 라인 카드의 FIA(Fabric Interface ASIC)를 Route Processor 카드의 XBAR(Crossbar)에 연결하는 첫 번째 링크는 NP로 향하는 패킷에 대해 항상 선택됩니다. NP의 응답 패킷은 링크 부하 분산 알고리즘을 따릅니다(라인 카드가 태풍 기반인 경우). 즉, NP에서 활성 경로 프로세서로의 응답 패킷이 패브릭 링크 로드를 기반으로 라인 카드를 경로 프로세서 카드에 연결하는 패브릭 링크 중 하나를 선택할 수 있습니다.

Standby Route Processor Card와 라인 카드 간의 패킷 경로

스탠바이 경로 프로세서에서 NP를 향해 패브릭으로 주입된 진단 패킷은 스위치 패브릭에서 멀티캐스트 패킷으로 처리됩니다. 멀티캐스트 패킷이지만 패브릭 내에서는 복제가 이루어지지 않습니다. 대기 경로 프로세서에서 소싱된 모든 진단 패킷은 여전히 한 번에 하나의 NP에 도달합니다. NP에서 경로 프로세서로의 응답 패킷도 복제 없이 패브릭을 통한 멀티캐스트 패킷입니다. 따라서 대기 경로 프로세서의 진단 애플리케이션은 NP로부터 한 번에 하나의 패킷인 단일 응답 패킷을 수신합니다. 진단 애플리케이션은 NP당 하나의 패킷을 삽입하므로 시스템의 모든 NP를 추적하며, 모든 NP, 한 번에 하나의 패킷에서 응답을 기대합니다. 멀티캐스트 패킷에서는 스위치 패브릭이 패킷 헤더의 필드 값을 기반으로 발신 링크를 선택합니다. 그러면 경로 프로세서 카드와 라인 카드 사이의 모든 패브릭 링크에 진단 패킷을 삽입하는 데 도움이 됩니다. 대기 Route Processor는 Route Processor 카드와 라인 카드 슬롯 사이를 연결하는 모든 패브릭 링크에서 NP 상태를 추적합니다.

이전 다이어그램은 대기 경로 프로세서에서 소싱된 진단 패킷 경로를 나타냅니다. 활성 Route Processor 케이스와 달리 라인 카드를 Route Processor의 XBAR에 연결하는 모든 링크가 실행됩니다. NP의 응답 패킷은 경로 프로세서의 패킷에서 라인 카드 방향으로 사용한 것과 동일한 패브릭 링크를 사용합니다. 이 테스트에서는 대기 Route Processor를 라인 카드에 연결하는 모든 링크가 지속적으로 모니터링됩니다.

Trident 기반 라인 카드의 Punt 패브릭 진단 패킷 경로

이 다이어그램은 경로 프로세서를 향해 루프백되는 NP로 향하는 경로 프로세서 소스 진단 패킷을 보여줍니다. 모든 NP에 공통적인 데이터 경로 링크 및 ASIC는 물론 NP의 하위 집합에 특정한 링크 및 구성 요소에 주목해야 합니다. 예를 들어, Bridge ASIC 0(B0)은 NP0 및 NP1에 공통적인 반면, FIA0은 모든 NP에 공통적입니다. 라우트 프로세서 끝에서는 모든 링크, 데이터 경로 ASIC 및 FPGA(Field-Programmable Gate Array)가 모든 라인 카드에 공통되므로 섀시의 모든 NP에 공통됩니다.

태풍 기반 라인 카드의 Punt 패브릭 진단 패킷 경로

이 다이어그램에는 경로 프로세서 쪽으로 루프백되는 NP로 향하는 경로 프로세서 카드 소스 진단 패킷이 나와 있습니다. 모든 NP에 공통적인 데이터 경로 링크 및 ASIC는 물론 NP의 하위 집합에 특정한 링크 및 구성 요소에 주목해야 합니다. 예를 들어, FIA0는 NP0 및 NP1에 공통됩니다. Route Processor Card End에서 모든 링크, 데이터 경로 ASIC 및 FGPA는 모든 라인 카드에 공통되므로 섀시의 모든 NP에 공통됩니다.

Tomahawk-, Lightspeed- 및 LightspeedPlus 기반 라인 카드의 Punt Fabric 진단 패킷 경로

토마호크 라인 카드에는 FIA와 NP 간에 1:1 연결이 있습니다.

Lightspeed 및 LightspeedPlus 라인 카드에서 FIA는 NP 칩에 통합됩니다.

다음 섹션에서는 모든 NP에 대한 패킷 경로를 설명하려고 합니다. 이는 punt fabric 데이터 경로 오류 메시지를 이해하고 장애 지점을 찾기 위해서도 필요합니다.

Punt Fabric 진단 경보 및 오류 보고

ASR 9000 기반 라우터의 NP에서 응답을 가져오지 못하면 경보가 발생합니다. 경로 프로세서에서 실행되는 온라인 진단 애플리케이션에 의한 경보 발동 결정은 3개의 연속적인 실패들이 있을 때 발생한다. 진단 애플리케이션은 모든 NP에 대해 3개의 패킷 실패 창을 유지합니다. 활성 경로 프로세서와 대기 경로 프로세서는 독립적으로 병렬로 진단합니다. 활성 Route Processor, 대기 Route Processor 또는 두 Route Processor 카드 모두 오류를 보고할 수 있습니다. 결함의 위치와 패킷 손실에 따라 어떤 경로 프로세서가 경보를 보고하는지 결정됩니다.

각 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에서 라인 카드 0/7/cpu0의 NP 1, 2, 3, 4, 5, 6, 7에 도달하지 못하는 것을 보여줍니다.

온라인 진단 테스트 목록에서 다음 명령을 사용하여 punt fabric 루프백 테스트의 특성을 확인할 수 있습니다.

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분마다 1개 패킷이고 실패 임계값이 3개라는 것이 표시되어 있는데, 이는 연속된 3개 패킷의 손실이 허용되지 않으며 경보가 발생함을 의미합니다. 표시되는 테스트 특성은 기본값입니다. 기본값을 변경하려면 diagnostic monitor interval 및 diagnostic monitor threshold 관리 컨피그레이션 모드의 명령.

Trident 기반 라인 카드 진단 패킷 경로

NP0 진단 실패

패브릭 진단 경로

이 다이어그램은 경로 프로세서 CPU와 라인 카드 NP0 사이의 패킷 경로를 나타냅니다. B0와 NP0을 연결하는 링크는 NP0에 해당하는 유일한 링크입니다. 다른 모든 링크는 공통 경로에 속합니다.

경로 프로세서에서 NP0으로의 패킷 경로를 기록합니다. 경로 프로세서에서 NP0으로 향하는 패킷에 사용할 링크가 4개 있지만 경로 프로세서와 라인 카드 슬롯 간의 첫 번째 링크는 경로 프로세서에서 라인 카드로 향하는 패킷에 사용됩니다. NP0에서 반환된 패킷은 라인 카드 슬롯과 활성 경로 프로세서 사이의 두 패브릭 링크 경로 중 하나를 통해 활성 경로 프로세서로 다시 전송될 수 있습니다. 두 링크 중 어떤 링크를 사용할지 선택하는 것은 해당 시점의 링크 로드에 따라 달라집니다. NP0에서 대기 경로 프로세서로의 응답 패킷은 두 링크를 모두 사용하지만 한 번에 하나의 링크를 사용합니다. 링크를 선택하는 것은 진단 애플리케이션이 입력하는 헤더 필드를 기반으로 합니다.

NP0 진단 실패 분석

단일 결함 시나리오

실패 메시지에 NP0만 포함된 단일 PFM(Platform Fault Manager) punt fabric 데이터 경로 실패 경보가 감지되면, fault는 경로 프로세서와 라인 카드 NP0을 연결하는 패브릭 경로에서만 발생합니다. 이는 단일 결함입니다. 둘 이상의 NP에서 결함이 탐지된 경우, Multiple Fault Scenario 섹션을 참조하십시오.

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도 보고되면 모든 결함의 상관관계를 파악하여 결함 격리가 수행됩니다. 예를 들어 PUNT_FABRIC_DATA_PATH_FAILED 오류 및 LC_NP_LOOPBACK_FAILED 오류가 모두 NP0에서 발생하면 NP는 패킷 처리를 중지합니다. 루프백 오류를 이해하려면 NP 루프백 진단 경로 섹션을 참조하십시오. 이는 NP0 내부의 심각한 장애를 조기에 나타낼 수 있습니다. 그러나 두 결함 중 하나만 발생하는 경우, 결함은 punt fabric 데이터 경로로 현지화되거나 라인 카드 CPU에서 NP 경로로 현지화됩니다.

라인 카드의 둘 이상의 NP에 punt 패브릭 데이터 경로 결함이 있는 경우, 결함이 있는 구성 요소를 격리하려면 패브릭 링크의 트리 경로를 걸어 올라가야 합니다. 예를 들어, NP0과 NP1 모두에 결함이 있는 경우, 결함은 B0 또는 B0과 FIA0을 연결하는 링크에 있어야 합니다. NP0과 NP1 모두 동시에 중대한 내부 오류가 발생할 가능성이 적습니다. 가능성은 낮지만 NP0 및 NP1에서 특정 종류의 패킷 또는 잘못된 패킷을 잘못 처리했기 때문에 심각한 오류 결함이 발생할 수 있습니다.

두 Route Processor Card에서 모두 오류를 보고합니다.

활성 및 대기 경로 프로세서 카드가 모두 라인 카드의 하나 이상의 NP에 장애를 보고할 경우, 영향을 받는 NP와 두 경로 프로세서 카드 사이의 데이터 경로에 있는 모든 공통 링크 및 구성 요소를 확인합니다.

NP1 진단 실패

이 다이어그램은 라우트 프로세서 카드 CPU와 라인 카드 NP1 간의 패킷 경로를 나타냅니다. Bridge ASIC 0(B0)과 NP1을 연결하는 링크는 NP1과 관련된 유일한 링크입니다. 다른 모든 링크는 공통 경로에 속합니다.

Route Processor Card에서 NP1로의 패킷 경로를 기록합니다. 경로 프로세서에서 NP0으로 향하는 패킷에 사용할 링크가 4개 있지만 경로 프로세서와 라인 카드 슬롯 간의 첫 번째 링크는 경로 프로세서에서 라인 카드로 향하는 패킷에 사용됩니다. NP1에서 반환된 패킷은 라인 카드 슬롯과 활성 경로 프로세서 사이의 두 패브릭 링크 경로 중 하나를 통해 활성 경로 프로세서로 다시 전송될 수 있습니다. 두 링크 중 어떤 링크를 사용할지 선택하는 것은 해당 시점의 링크 로드에 따라 달라집니다. NP1에서 대기 경로 프로세서로의 응답 패킷은 두 링크를 모두 사용하지만 한 번에 하나의 링크를 사용합니다. 링크를 선택하는 것은 진단 애플리케이션이 입력하는 헤더 필드를 기반으로 합니다.

패브릭 진단 경로

NP1 진단 실패 분석

NP0 진단 실패 분석 섹션을 참조하되 NP1(NP0 대신)에 대해 동일한 추론을 적용합니다.

NP2 진단 실패

이 다이어그램은 라우트 프로세서 카드 CPU와 라인 카드 NP2 간의 패킷 경로를 나타냅니다. B1과 NP2를 연결하는 링크는 NP2에 해당하는 유일한 링크입니다. 다른 모든 링크는 공통 경로에 속합니다.

Route Processor Card에서 NP2로의 패킷 경로를 기록합니다. 경로 프로세서에서 NP2로 향하는 패킷에 사용할 링크가 4개 있지만 경로 프로세서와 라인 카드 슬롯 간의 첫 번째 링크는 경로 프로세서에서 라인 카드로 향하는 패킷에 사용됩니다. NP2에서 반환된 패킷은 라인 카드 슬롯과 활성 경로 프로세서 사이의 두 패브릭 링크 경로 중 하나를 통해 활성 경로 프로세서로 다시 전송될 수 있습니다. 두 링크 중 어떤 링크를 사용할지 선택하는 것은 해당 시점의 링크 로드에 따라 달라집니다. NP2에서 대기 경로 프로세서로의 응답 패킷은 두 링크를 모두 사용하지만 한 번에 하나의 링크를 사용합니다. 링크를 선택하는 것은 진단 애플리케이션이 입력하는 헤더 필드를 기반으로 합니다.

패브릭 진단 경로

NP2 진단 실패 분석

NP0 진단 실패 분석 섹션을 참조하되 NP2(NP0 대신)에 대해 동일한 추론을 적용합니다.

NP3 진단 실패

이 다이어그램은 라우트 프로세서 카드 CPU와 라인 카드 NP3 간의 패킷 경로를 나타냅니다. Bridge ASIC 1(B1)과 NP3을 연결하는 링크는 NP3에 해당하는 유일한 링크입니다. 다른 모든 링크는 공통 경로에 속합니다.

Route Processor Card에서 NP3로의 패킷 경로를 기록합니다. 경로 프로세서에서 NP3로 향하는 패킷에 사용할 링크가 4개 있지만 경로 프로세서와 라인 카드 슬롯 간의 첫 번째 링크는 경로 프로세서에서 라인 카드로 향하는 패킷에 사용됩니다. NP3에서 반환된 패킷은 라인 카드 슬롯과 활성 경로 프로세서 사이의 두 패브릭 링크 경로 중 하나를 통해 활성 경로 프로세서로 다시 전송될 수 있습니다. 두 링크 중 어떤 링크를 사용할지 선택하는 것은 해당 시점의 링크 로드에 따라 달라집니다. NP3에서 대기 경로 프로세서로의 응답 패킷은 두 링크를 모두 사용하지만 한 번에 하나의 링크를 사용합니다. 링크를 선택하는 것은 진단 애플리케이션이 입력하는 헤더 필드를 기반으로 합니다.

패브릭 진단 경로

NP3 진단 실패 분석

NP0 진단 실패 분석 섹션을 참조하되 NP0 대신 NP3에 대해 동일한 추론을 적용합니다.

태풍 기반 라인 카드 진단 패킷 경로

이 섹션에서는 Typhoon 기반 라인 카드로 패브릭 펀트 패킷에 대한 배경을 설정하기 위해 두 가지 예를 제공합니다. 첫 번째 예는 NP1을 사용하고 두 번째 예는 NP3을 사용합니다. 설명 및 분석은 어떤 Typhoon 기반 라인 카드에서도 다른 NP로 확장할 수 있습니다.

태풍 NP1 진단 실패

다음 다이어그램은 라우트 프로세서 카드 CPU와 라인 카드 NP1 사이의 패킷 경로를 나타냅니다. FIA0과 NP1을 연결하는 링크는 NP1 경로에 해당하는 유일한 링크입니다. 라인 카드 슬롯과 라우트 프로세서 카드 슬롯 사이의 다른 모든 링크는 공통 경로에 있습니다. 라인 카드의 패브릭 XBAR ASIC를 라인 카드의 FIA에 연결하는 링크는 NP의 하위 집합과 관련이 있습니다. 예를 들어 라인 카드의 로컬 패브릭 XBAR ASIC과 FIA0 사이의 두 링크는 모두 NP1로의 트래픽에 사용됩니다.

Route Processor Card에서 NP1로의 패킷 경로를 기록합니다. Route Processor Card에서 NP1로 향하는 패킷에 사용할 링크가 8개 있지만, Route Processor Card와 라인 카드 슬롯 간의 단일 경로가 사용됩니다. NP1에서 반환된 패킷은 라인 카드 슬롯과 경로 프로세서 사이의 8개의 패브릭 링크 경로를 통해 경로 프로세서 카드로 다시 전송될 수 있습니다. 이러한 8개의 링크는 진단 패킷이 경로 프로세서 카드 CPU로 돌아가는 한 번에 하나씩 실행됩니다.

패브릭 진단 경로

태풍 NP3 진단 실패

이 다이어그램은 라우트 프로세서 카드 CPU와 라인 카드 NP3 간의 패킷 경로를 나타냅니다. FIA1과 NP3를 연결하는 링크는 NP3 경로에 해당하는 유일한 링크입니다. 라인 카드 슬롯과 라우트 프로세서 카드 슬롯 사이의 다른 모든 링크는 공통 경로에 있습니다. 라인 카드의 패브릭 XBAR ASIC를 라인 카드의 FIA에 연결하는 링크는 NP의 하위 집합과 관련이 있습니다. 예를 들어, FIA1과 라인 카드의 로컬 패브릭 XBAR ASIC 간의 두 링크 모두 NP3로의 트래픽에 사용됩니다.

Route Processor Card에서 NP3로의 패킷 경로를 기록합니다. Route Processor Card에서 NP3로 향하는 패킷에 사용할 링크가 8개 있지만, Route Processor Card와 라인 카드 슬롯 간의 단일 경로가 사용됩니다. NP1에서 반환된 패킷은 라인 카드 슬롯과 경로 프로세서 사이의 8개의 패브릭 링크 경로를 통해 경로 프로세서 카드로 다시 전송될 수 있습니다. 이러한 8개의 링크는 진단 패킷이 경로 프로세서 카드 CPU로 돌아가는 한 번에 하나씩 실행됩니다.

패브릭 진단 경로

토마호크 기반 라인 카드 진단 패킷 경로

FIA와 NP 간의 1:1 연결로 인해 FIA0을 통과하는 트래픽은 NP0과 주고받는 트래픽뿐입니다.

Lightspeed 및 LightspeedPlus 기반 라인 카드 진단 패킷 경로

FIA가 NP 칩에 통합됨에 따라 FIA0을 통과하는 트래픽은 NP0과 주고받는 트래픽뿐입니다.

결함 분석

이 섹션에서는 결함을 하드 및 일시적 케이스로 분류하고, 결함이 하드 또는 일시적 결함인지 식별하는 데 사용되는 단계를 나열합니다. 결함 유형이 결정되면, 이 문서에서는 결함을 이해하고 필요한 수정 작업을 파악하기 위해 라우터에서 실행할 수 있는 명령을 지정합니다.

일시적 결함

설정된 PFM 메시지 뒤에 명확한 PFM 메시지가 올 경우, 결함이 발생했으며 라우터가 결함 자체를 수정했습니다. 일시적인 결함은 환경 조건 및 하드웨어 구성 요소의 복구 가능한 결함으로 인해 발생할 수 있습니다. 때때로 일시적인 결함을 임의의 특정 이벤트와 연관시키는 것은 어려울 수 있다.

명확성을 위해 일시적인 패브릭 결함의 예가 여기에 나열되어 있습니다.

RP/0/RSP0/CPU0:Feb  5 05:05:44.051 : pfm_node_rp[354]:

%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|

System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)

failed: (0/2/CPU0, 0)

RP/0/RSP0/CPU0:Feb  5 05:05:46.051 : pfm_node_rp[354]:

%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Clear|online_diag_rsp[237686]|

System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)

failed: (0/2/CPU0, 0)

일시적 결함 해결 조치

일시적 오류에 대한 제안 된 접근 방식은 이러한 오류의 추가 발생을 모니터링 하는 것입니다. 일시적 결함이 두 번 이상 발생하는 경우, 일시적 결함을 경질 결함으로 처리하고 권장 사항 및 단계를 사용하여 다음 섹션에 설명된 결함을 분석합니다.

하드 결함

설정된 PFM 메시지 뒤에 명확한 PFM 메시지가 오지 않을 경우, 결함이 발생했으며 라우터가 결함 처리 코드로 결함 자체를 수정하지 않았거나 하드웨어 결함의 특성을 복구할 수 없습니다. 하드웨어 구성 요소에서 환경 조건 및 복구 불가능한 결함으로 인해 하드 결함이 발생할 수 있습니다. 하드 폴트에 대한 제안 접근 방식은 하드 폴트 분석 섹션에 언급된 지침을 사용하는 것입니다.

명확한 설명을 위해 하드 패브릭 결함의 예가 여기에 나열되어 있습니다. 이 예제 메시지에는 해당 일반 PFM 메시지가 없습니다.

RP/0/RSP0/CPU0:Feb  5 05:05:44.051 : pfm_node_rp[354]:

%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|

System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)

failed: (0/2/CPU0, 0)

하드 결함 해결 조치

하드 결함 시나리오에서는 Data To Collect Before Service Request Creation(서비스 요청 생성 전에 수집할 데이터) 섹션에 언급된 모든 명령을 수집하고 서비스 요청을 엽니다. 긴급한 경우, 트러블슈팅 명령 출력을 모두 수집한 후, 결함 격리를 기반으로 라우트 프로세서 카드 또는 라인 카드 재로드를 시작합니다. 다시 로드한 후 오류가 복구되지 않으면 RMA(Return Material Authorization)를 시작합니다.

일시적 결함 분석

일시적인 결함을 분석하려면 다음 단계를 완료하십시오.

1. 다음을 입력합니다. show logging | inc “PUNT_FABRIC_DATA_PATH" 명령을 사용하여 오류가 한 번 또는 여러 번 발생했는지 확인합니다.

2. 다음을 입력합니다. show pfm location all 명령을 사용하여 현재 상태를 확인합니다(SET 또는 CLEAR). 오류가 미해결 상태입니까, 아니면 해결 상태입니까? SET와 CLEAR 간에 오류 상태가 변경되면 패브릭 데이터 경로 내의 하나 이상의 오류가 반복적으로 발생하고 소프트웨어 또는 하드웨어로 수정됩니다.

3. SNMP(Simple Network Management Protocol) 트랩을 프로비저닝하거나 수집하는 스크립트를 실행합니다. show pfm location all 명령 출력 및 주기적으로 오류 문자열을 검색하여 오류의 향후 발생(오류의 마지막 상태가 CLEAR이고 새 오류가 발생하지 않은 경우)을 모니터링합니다.

사용할 명령

일시적 결함을 분석하려면 다음 명령을 입력합니다.

- show logging | inc “PUNT_FABRIC_DATA_PATH”

- show pfm location all

하드 결함 분석

라인 카드의 패브릭 데이터 경로 링크를 트리로 보는 경우(Background Information(백그라운드 정보) 섹션에서 세부사항을 설명함), 장애 지점에 따라 하나 이상의 NP에 액세스할 수 있는지 유추해야 합니다. 여러 NP에서 여러 장애가 발생하는 경우, 결함을 분석하려면 이 섹션에 나열된 명령을 사용합니다.

사용할 명령

하드 결함을 분석하려면 다음 명령을 입력합니다.

- show logging | inc “PUNT_FABRIC_DATA_PATH”

출력에는 하나 이상의 NP(예: NP2, NP3)가 포함될 수 있습니다.

- show controller fabric fia link-status location

NP2와 NP3(Typhoon NP3 Diagnostic Failure(태풍 NP3 진단 실패) 섹션에서) 모두 단일 FIA를 통해 수신 및 전송되므로, 결함이 경로의 관련 FIA에 있다고 추론하는 것이 타당합니다.

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

라인 카드의 모든 NP가 진단 애플리케이션에 연결할 수 없는 경우, 라인 카드 슬롯을 경로 프로세서 카드에 연결하는 링크에 경로 프로세서 카드와 라인 카드 간에 트래픽을 전달하는 ASIC에 결함이 있을 수 있다고 유추하는 것이 합리적입니다.

show controller fabric crossbar link-status instance 0 location

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가 장애를 보고할 경우, 해당 장애는 Route Processor Card(Active Route Processor Card 또는 Standby Route Processor Card)에서 발생할 가능성이 높습니다. Route Processor Card CPU를 FPGA와 Route Processor Card FIA에 연결하는 링크는 Background Information 섹션에서 참고한다.

과거 실패

지금까지 99%의 fault가 복구 가능하며, 대부분의 경우 소프트웨어에서 시작한 복구 작업으로 fault가 해결되었습니다. 그러나 매우 드문 경우이지만 카드의 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(Ingress Front Direct Memory Access) 드롭이 발생합니다. 이그레스 NP가 흐름 제어를 어설션할 때 FIA 테일 드랍이 발생합니다(인그레스 라인 카드에 트래픽 전송 감소 요청). 플로우 제어 시나리오에서는 인그레스 FIA에 tail drop이 있습니다.

예를 들면 다음과 같습니다.

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 Fast Reset으로 인한 하드 결함

PUNT_FABRIC_DATA_PATH_FAILED가 발생하고 NP 빠른 재설정으로 인해 오류가 발생한 경우, 여기에 나열된 것과 유사한 로그가 태풍 기반 라인 카드에 나타납니다. 상태 모니터링 메커니즘은 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 Route Processor 및 Typhoon Line Card 간 장애

Cisco에서는 백플레인에 있는 RSP(Route Switch Processor) 440과 태풍 기반 라인 카드 간의 패브릭 링크가 재교육되는 경우가 거의 없는 문제를 해결했습니다. 신호 강도가 최적이 아니므로 패브릭 링크가 재학습됩니다. 이 문제는 기본 Cisco IOS® XR Software 릴리스 4.2.1, 4.2.2, 4.2.3, 4.3.0, 4.3.1 및 4.3.2에 있습니다. 각 릴리스에 대한 SMU(Software Maintenance Update)가 Cisco Connection Online에 게시되고 Cisco 버그 ID CSCuj10837 및 Cisco 버그 ID CSCul39674로 추적됩니다.

라우터에서 이 문제가 발생하면 다음 시나리오가 발생할 수 있습니다.

1. 링크가 중단되고 나타납니다. (임시)

2. 링크가 영구적으로 다운됩니다.

Cisco 버그 ID CSCuj10837 - RSP와 LC 사이의 패브릭 재교육(TX 방향)

확인하기 위해, LC 및 두 RSP에서 ltrace 출력을 수집합니다(show controller fabric crossbar ltrace location <>)을 클릭하고 RSP ltraces에 이 출력이 표시되는지 확인합니다.

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 크로스바 패브릭 인터페이스의 관점에서 태풍 기반 라인 카드 상의 패브릭 크로스바 인터페이스를 향하는 방향을 의미한다.

Cisco 버그 ID CSCuj10837은 Typhoon 라인 카드가 RSP에서 RX 링크의 문제를 감지하고 링크 재교육을 시작하는 것이 특징입니다. 어느 한 측(LC 또는 RSP)이 재교육 이벤트를 개시할 수 있다. Cisco 버그 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 버그 ID CSCul39674 - RSP와 LC 사이의 패브릭 재교육(RX 방향)

확인을 위해 라인 카드 및 두 RSP에서 ltrace 출력을 수집합니다(show controller fabric crossbar ltrace location <>)을 클릭하고 RSP ltraces에 이 출력이 표시되는지 확인합니다.

예를 들면 다음과 같습니다.

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 크로스바 패브릭 인터페이스의 관점에서, 태풍 기반 라인 카드 상의 패브릭 크로스바 인터페이스로부터의 방향을 의미한다.

Cisco 버그 ID CSCul39674는 RSP가 태풍 라인 카드에서 RX 링크의 문제를 감지하고 링크 재교육을 시작하는 것이 특징입니다. 어느 한 측(LC 또는 RSP)이 재교육 이벤트를 개시할 수 있다. Cisco 버그 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.

Fabric Retrain 릴리스 4.3.2 이상에서 차이

Cisco IOS XR 릴리스 4.3.2 이상에서 패브릭 링크를 재교육하는 데 걸리는 시간을 줄이기 위해 상당한 작업이 수행되었습니다. 이제 패브릭 재트레이닝은 1초 미만의 시간에 발생하며 트래픽 흐름에는 영향을 미치지 않습니다. Cisco IOS XR 릴리스 4.3.2에서는 패브릭 링크 재교육이 발생했을 때 이 syslog 메시지만 표시됩니다.

%PLATFORM-FABMGR-5-FABRIC_TRANSIENT_FAULT :  Fabric backplane crossbar link

underwent link retraining to recover from a transient error: Physical slot 1

패브릭 ASIC FIFO 오버플로로 인한 오류

Cisco는 복구할 수 없는 FIFO(First In First Out) 오버플로 조건으로 인해 FIA(Fabric ASIC)가 재설정될 수 있는 문제를 해결했습니다. 이 문제는 Cisco 버그 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(Virtual Output Queue) 빌드업으로 인한 실패

Cisco는 혼잡이 길어지면 패브릭 리소스가 소진되고 트래픽이 손실될 수 있는 문제를 해결했습니다. 트래픽 손실은 관련이 없는 플로우에서도 발생할 수 있습니다. 이 문제는 Cisco 버그 ID CSCug90300에서 해결되며 Cisco IOS XR 릴리스 4.3.2 이상에서 해결됩니다. 수정 사항은 Cisco IOS XR 릴리스 4.2.3 CSMU#3, Cisco 버그 ID CSCui33805에서도 제공됩니다. 이 드문 문제는 Trident 또는 Typhoon 기반 라인 카드에서 발생할 수 있습니다.

관련 명령

다음 명령의 출력을 수집합니다.

- show tech-support fabric

- show controller fabric fia bridge flow-control location

<=== 모든 LC에 대해 이 출력을 가져옵니다.

- show controllers fabric fia q-depth location

다음은 몇 가지 출력 예입니다.

RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia q-depth location 0/6/CPU0

Sun Dec 29 23:10:56.307 UTC

********** FIA-0 **********

Category: q_stats_a-0

Voq       ddr            pri            pktcnt

11        0              2              7

********** FIA-0 **********

Category: q_stats_b-0

Voq       ddr            pri            pktcnt

********** FIA-1 **********

Category: q_stats_a-1

Voq       ddr            pri            pktcnt

11        0              0              2491

11        0              2              5701

********** FIA-1 **********

Category: q_stats_b-1

Voq       ddr            pri            pktcnt

RP/0/RSP0/CPU0:asr9k-1#

RP/0/RSP0/CPU0:asr9k-1#show controllers pm location 0/1/CPU0 | in "switch|if"

Sun Dec 29 23:37:05.621 UTC

Ifname(2): TenGigE0_1_0_2, ifh: 0x2000200 : <==Corresponding interface ten 0/1/0/2

iftype             0x1e

switch_fabric_port 0xb   <==== VQI 11

parent_ifh         0x0

parent_bundle_ifh  0x80009e0

RP/0/RSP0/CPU0:asr9k-1#

정상적인 조건에서는 패킷이 대기열에 있는 VOQ를 볼 가능성이 매우 낮습니다. 이 명령은 FIA 대기열에 대한 빠른 실시간 스냅샷입니다. 이 명령은 일반적으로 큐에 있는 패킷을 전혀 표시하지 않습니다.

Trident 기반 라인 카드의 브리지/FPGA 소프트 오류로 인한 트래픽 영향

소프트 오류는 상태 컴퓨터가 동기화되지 않도록 하는 영구적이지 않은 오류입니다. 이는 NP의 패브릭 측 또는 FIA의 인그레스 측에서 CRC(Cyclic Redundancy Check), FCS(Frame Check Sequence) 또는 오류가 발생한 패킷으로 간주됩니다.

다음은 이 문제를 확인할 수 있는 몇 가지 예입니다.

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 <> (여러 번 가져오기)

Bridge/FPGA 소프트 오류에서 복구

복구 방법은 영향을 받는 라인 카드를 다시 로드하는 것입니다.

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

온라인 진단 테스트 보고서

이 show diagnostic result location

[test

detail

] 이 명령은 모든 온라인 진단 테스트 및 실패의 요약을 제공하고 테스트가 통과했을 때의 마지막 타임스탬프도 제공합니다. punt 패브릭 데이터 경로 장애의 Test-ID는 10입니다. 테스트 패킷의 빈도와 함께 모든 테스트의 목록을 show diagnostic content location

명령을 실행합니다.

punt fabric 데이터 경로 테스트 결과의 출력은 이 샘플 출력과 유사합니다.

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 오류와 연결된 모든 포트를 자동으로 종료하도록 할 수 있습니다.

첫 번째 방법은 Cisco 버그 ID CSCuc04493을 통해 추적됩니다. 버전 4.2.3의 경우 Cisco 버그 ID CSCui33805에 포함됩니다. 이 버전에서는 영향을 받는 NP와 연결된 모든 포트를 자동으로 종료하도록 설정됩니다.

다음은 syslog가 표시되는 방식을 보여 주는 예입니다.

RP/0/RSP0/CPU0:Jun 10 16:11:26 BKK: pfm_node_rp[359]:

%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|System

Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:

(0/1/CPU0, 0)

LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface

TenGigE0/1/0/0, changed state to Down

LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line

protocol on Interface TenGigE0/1/0/0, changed state to Down

LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface

TenGigE0/1/0/1, changed state to Down

LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line

protocol on Interface TenGigE0/1/0/1, changed state to Down

컨트롤러는 인터페이스의 작동이 중지된 이유가 DATA_PATH_DOWN. 예를 들면 다음과 같습니다.

RP/0/RSP0/CPU0:ASR9006-E#show controllers gigabitEthernet 0/0/0/13 internal

Wed Dec 18 02:42:52.221 UTC

Port Number       : 13

Port Type         : GE

Transport mode    : LAN

BIA MAC addr      : 6c9c.ed08.3cbd

Oper. MAC addr    : 6c9c.ed08.3cbd

Egress MAC addr   : 6c9c.ed08.3cbd

Port Available    : true

Status polling is : enabled

Status events are : enabled

I/F Handle        : 0x04000400

Cfg Link Enabled  : tx/rx enabled

H/W Tx Enable     : no

UDLF enabled      : no

SFP PWR DN Reason : 0x00000000

SFP Capability    : 0x00000024

MTU               : 1538

H/W Speed         : 1 Gbps

H/W Duplex        : Full

H/W Loopback Type : None

H/W FlowCtrl type : None

H/W AutoNeg Enable: Off

H/W Link Defects  : (0x00080000) DATA_PATH_DOWN  <<<<<<<<<<<

Link Up           : no

Link Led Status   : Link down -- Red

Input good underflow          : 0

Input ucast underflow         : 0

Output ucast underflow        : 0

Input unknown opcode underflow: 0

Pluggable Present   : yes

Pluggable Type      : 1000BASE-LX

Pluggable Compl.    : (Service Un) - Compliant

Pluggable Type Supp.: (Service Un) - Supported

Pluggable PID Supp. : (Service Un) - Supported

Pluggable Scan Flg: false

버전 4.3.1 이상에서는 이 동작을 활성화해야 합니다. 이 작업을 수행하기 위해 새로운 admin-config 명령이 사용됩니다. 기본 동작은 더 이상 포트를 종료하는 것이 아니므로 수동으로 구성해야 합니다.

RP/0/RSP1/CPU0:ASR9010-A(admin-config)#fault-manager datapath port ?

shutdown Enable auto shutdown

toggle Enable auto toggle port status

64비트 Cisco IOS XR에서 configuration 명령은 Sysadmin VM이 아닌 XR VM에서 사용할 수 있습니다.

RP/0/RSP0/CPU0:CORE-TOP(config)#fault-manager datapath port ?

shutdown Enable auto shutdown

toggle Enable auto toggle port status

Cisco 버그 ID CSCui15435는 Traffic Impact Due to Bridge/FPGA Soft Errors on Trident-Based Line Cards 섹션에 설명된 대로 Trident 기반 라인 카드에 나타나는 소프트 오류를 해결합니다. 이는 Cisco 버그 ID CSCuc04493에 설명된 일반적인 진단 방법과 다른 탐지 방법을 사용합니다.

또한 이 버그는 새로운 admin-config CLI 명령을 도입했습니다.

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

1 = shutdown the ports

2 = reload the linecard

Default behavior: no action is taken.

이 오류가 발생하면 이 syslog를 확인할 수 있습니다.

RP/0/RSP0/CPU0:Apr 30 22:17:11.351 : config[65777]: %MGBL-SYS-5-CONFIG_I : Configured

from console by root

LC/0/2/CPU0:Apr 30 22:18:52.252 : pfm_node_lc[283]:

%PLATFORM-BRIDGE-1-SOFT_ERROR_ALERT_1 : Set|fialc[159814]|NPU

Crossbar Fabric Interface Bridge(0x1024000)|Soft Error Detected on Bridge instance 1

RP/0/RSP0/CPU0:Apr 30 22:21:28.747 : pfm_node_rp[348]:

%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|

System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:

(0/2/CPU0, 2) (0/2/CPU0, 3)

LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINK-3-UPDOWN :

Interface TenGigE0/2/0/2, changed state to Down

LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINEPROTO-5-UPDOWN :

Line protocol on Interface TenGigE0/2/0/2, changed state to Down

RP/0/RSP1/CPU0:Apr 30 22:21:35.086 : pfm_node_rp[348]:

%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED :

Set|online_diag_rsp[237646]|System Punt/Fabric/data Path Test(0x2000004)|failure

threshold is 3, (slot, NP) failed: (0/2/CPU0, 2) (0/2/CPU0, 3)

영향을 받는 포트가 종료되면 네트워크 이중화가 트래픽을 인수하여 블랙홀을 방지할 수 있습니다. 복구하려면 라인 카드를 다시 로드해야 합니다.

FAQ(자주 묻는 질문)

Q. 기본 또는 대기 경로 프로세서 카드는 시스템의 모든 NP에 킵얼라이브 또는 온라인 진단 패킷을 전송합니까?

A. 예. 두 Route Processor Card는 모든 NP에 온라인 진단 패킷을 전송합니다.

Q. RSP1(Route Processor Card One)이 활성화되어 있으면 경로는 동일합니까?

A. 진단 경로는 RSP0 또는 RSP1과 동일합니다. 경로는 RSP의 상태에 따라 달라집니다. 자세한 내용은 이 문서의 Punt Fabric Diagnostic Packet Path 섹션을 참조하십시오.

Q. RSP에서 진단 패킷을 전송하는 빈도는 어떻게 되며, 경보가 트리거되기 전에 누락되는 진단 패킷의 수는 얼마나 됩니까?

A. 각 RSP는 분당 한 번씩 각 NP에 진단 패킷을 독립적으로 전송합니다. 세 개의 진단 패킷이 승인되지 않은 경우 RSP에서 알람을 트리거할 수 있습니다.

Q. NP가 초과 가입되었는지 또는 초과 가입되었는지 어떻게 확인합니까?

A. NP가 현재 초과 가입되어 있는지 또는 과거에 초과 가입되어 있는지 확인하는 한 가지 방법은 NP 내부에 특정 종류의 드롭이 있는지, FIA에 테일 드롭이 있는지 확인하는 것입니다. NP가 오버서브스크립션되어 수신 트래픽을 따라잡을 수 없을 때 NP 내부에 IFDMA(Ingress Front Direct Memory Access) 드롭이 발생합니다. 이그레스 NP가 흐름 제어를 어설션할 때 FIA 테일 드랍이 발생합니다(인그레스 라인 카드에 더 적은 트래픽을 보내도록 요청). 플로우 제어 시나리오에서는 인그레스 FIA에 tail drop이 있습니다.

Q. NP에 재설정이 필요한 결함이 있는지 어떻게 확인합니까?

A. 일반적으로 NP 결함은 빠른 재설정을 통해 해결됩니다. 빠른 재설정의 이유가 로그에 표시됩니다.

Q. NP를 수동으로 재설정하는 것이 가능합니까?

A. 예, 라인 카드 KSH에서:

run attach 0/[x]/CPU0

#show_np -e [np#] -d fast_reset

Q. NP에 복구할 수 없는 하드웨어 장애가 있는 경우 어떻게 표시됩니까?

A. 해당 NP에 대한 punt 패브릭 데이터 경로 실패와 NP 루프백 테스트 실패가 모두 표시됩니다. NP 루프백 테스트 실패 메시지에 대해서는 이 문서의 부록 섹션에서 설명합니다.

Q. 하나의 Route Processor 카드에서 소싱된 진단 패킷이 동일한 Route Processor 카드로 다시 돌아옵니까?

A. 진단 패킷은 두 Route Processor Card 모두에서 소싱되고 Route Processor Card 단위로 추적되므로, Route Processor Card에서 소싱된 진단 패킷은 NP에 의해 동일한 Route Processor Card로 루프백됩니다.

Q. Cisco 버그 ID CSCuj10837 SMU는 패브릭 링크 재교육 이벤트에 대한 수정을 제공합니다. 이것이 많은 punt fabric 데이터 경로 장애의 원인 및 해결책입니까?

A. 예, 패브릭 링크 재교육 이벤트를 방지하기 위해 Cisco 버그 ID CSCul39674에 대한 수퍼로딩 SMU를 로드해야 합니다.

Q. 패브릭 링크를 재교육하기로 결정한 후 재교육하는 데 시간이 얼마나 걸립니까?

A. 링크 장애가 탐지되는 즉시 재교육을 결정해야 합니다. 릴리스 4.3.2 이전에는 재교육에 몇 초가 걸릴 수 있습니다. 릴리스 4.3.2 이후 재교육 시간이 크게 향상되었으며 1초 미만이 소요됩니다.

Q. 패브릭 링크에 대한 재교육 결정은 어느 시점에 내려졌습니까?

A. 링크 결함이 감지되면 즉시 패브릭 ASIC 드라이버에서 재교육을 결정하게 됩니다.

Q. 활성 라우트 프로세서 카드의 FIA와 첫 번째 링크를 사용하는 패브릭 사이에만 해당되며, 그 이후에는 사용 가능한 링크가 여러 개 있을 때 로드가 가장 적은 링크입니까?

A. 맞습니다. 활성 경로 프로세서의 첫 번째 XBAR 인스턴스에 연결하는 첫 번째 링크는 트래픽을 패브릭에 주입하기 위해 사용됩니다. NP의 응답 패킷은 Route Processor Card에 연결된 모든 링크의 활성 Route Processor Card에 다시 도달할 수 있습니다. 링크 선택은 링크 로드에 따라 달라집니다.

Q. 재교육 중에 해당 패브릭 링크를 통해 전송된 모든 패킷이 손실됩니까?

A. 예. 그러나 릴리스 4.3.2 이상에서 향상된 기능을 통해 재교육을 탐지할 수 없습니다. 그러나 이전 코드에서는 재교육하는 데 몇 초가 걸릴 수 있으므로 해당 시간 프레임 동안 패킷이 손실됩니다.

Q. Cisco 버그 ID CSCuj10837에 대한 수정 사항이 있는 SMU 또는 릴리스로 업그레이드한 후 XBAR 패브릭 링크 재교육 이벤트를 얼마나 자주 볼 것으로 예상하십니까?

A. Cisco 버그 ID CSCuj10837에 대한 수정이 있더라도 Cisco 버그 ID CSCul39674로 인해 패브릭 링크 재교육을 볼 수 있습니다. 그러나 Cisco 버그 ID CSCul39674를 수정한 후에는 RSP440과 Typhoon 기반 라인 카드 간의 패브릭 백플레인 링크에 대한 패브릭 링크 재교육이 발생하지 않아야 합니다. 문제가 발생할 경우 Cisco TAC(Technical Assistance Center)에 서비스 요청을 하여 문제를 해결합니다.

Q. Cisco 버그 ID CSCuj10837 및 Cisco 버그 ID CSCul39674는 태풍 기반 라인 카드로 ASR 9922의 RP에 영향을 줍니까?

A. 예

Q. Cisco 버그 ID CSCuj10837 및 Cisco 버그 ID CSCul39674는 ASR-9001 및 ASR-9001-S 라우터에 영향을 줍니까?

A. 아니요

Q. 이 메시지와 함께 존재하지 않는 슬롯에 오류가 발생하면 10슬롯 섀시에서 "PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|System Punt/Fabric/data Path Test(0x2000004)|실패 임계값은 3이고 (슬롯, NP) 실패: (8, 0)"입니다. 어떤 슬롯에 문제가 있습니까?

A. 이전 릴리스에서는 여기에 표시된 대로 물리적 및 논리적 매핑을 고려해야 합니다. 이 예에서 슬롯 8은 0/6/CPU0에 해당합니다.

For 9010 (10 slot chassis)

L            P

#0  --- #0

#1  --- #1

#2  --- #2

#3  --- #3

RSP0 --- #4

RSP1 --- #5

#4 --- #6

#5 --- #7

#6 --- #8

#7 --- #9

For 9006 (6 slot chassis)

L               P

RSP0 --- #0

RSP1 --- #1

#0 --- #2

#1 --- #3

#2 --- #4

#3 --- #5

서비스 요청 생성 전에 수집할 데이터

다음은 작업을 수행하기 전에 출력을 수집하는 최소 명령입니다.

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

- show controller fabric fia link-status location

- show controller fabric fia bridge sync-status location

- show controller fabric crossbar link-status instance 0 location

- show controller fabric crossbar link-status instance 0 location

- show controller fabric crossbar link-status instance 1 location

- show controller fabric ltrace crossbar location

- show controller fabric ltrace crossbar location

- show tech fabric location

file

- show tech fabric location

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 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 Software Release 4.3.4 시간대에서는 punt 패브릭 데이터 경로 장애와 관련된 대부분의 문제가 해결되었습니다. Cisco 버그 ID CSCuj10837 및 Cisco 버그 ID CSCul39674의 영향을 받는 라우터의 경우, 패브릭 링크 재교육 이벤트를 방지하기 위해 Cisco 버그 ID CSCul39674에 대한 수퍼시딩 SMU를 로드합니다.

플랫폼 팀은 최첨단 장애 처리 기능을 설치하여 데이터 경로 복구 장애가 발생할 경우 라우터가 몇 초 이내에 복구되도록 합니다. 그러나 이러한 결함이 관찰되지 않더라도 이 문제를 이해하기 위해서는 이 문서를 사용하는 것이 좋습니다.

부록

NP 루프백 진단 경로

라인 카드 CPU에서 실행되는 진단 애플리케이션은 NP의 작업 상태를 정기적으로 확인하여 각 NP의 상태를 추적합니다. 패킷은 로컬 NP로 향하는 라인 카드 CPU에서 주입되며, 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 라인 카드에 적용됩니다. Bridge FPGA ASIC는 Typhoon 기반 라인 카드에 없습니다(100GE Typhoon 기반 라인 카드 제외). 따라서 show controller fabric fia bridge 100GE 버전을 제외한 Typhoon 기반 라인 카드에는 명령이 적용되지 않습니다.

이 그림 표현은 각 show 명령을 데이터 경로의 위치에 매핑하는 데 도움이 됩니다. 패킷 삭제 및 결함을 격리하려면 다음 show 명령을 사용합니다.