ASR 9000 Series Punt Fabric 데이터 경로 오류 트러블슈팅
목차
소개
이 문서에서는 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는 현재 로드가 가장 적은 링크를 선택합니다.
이 다이어그램에는 활성 경로 프로세서에서 소싱된 진단 패킷 경로가 나와 있습니다.
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)를 시작합니다.
일시적 결함 분석
일시적인 결함을 분석하려면 다음 단계를 완료하십시오.
- 다음을 입력합니다.
show logging | inc “PUNT_FABRIC_DATA_PATH"명령을 사용하여 오류가 한 번 또는 여러 번 발생했는지 확인합니다. - 다음을 입력합니다.
show pfm location all명령을 사용하여 현재 상태를 확인합니다(SET 또는 CLEAR). 오류가 미해결 상태입니까, 아니면 해결 상태입니까? SET와 CLEAR 간에 오류 상태가 변경되면 패브릭 데이터 경로 내의 하나 이상의 오류가 반복적으로 발생하고 소프트웨어 또는 하드웨어로 수정됩니다. - 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 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%의 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로 추적됩니다.
라우터에서 이 문제가 발생하면 다음 시나리오가 발생할 수 있습니다.
- 링크가 중단되고 나타납니다. (임시)
- 링크가 영구적으로 다운됩니다.
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 fabricshow controller fabric fia bridge flow-control location<=== 모든 LC에 대해 이 출력을 가져옵니다.show controllers fabric fia q-depth location
다음은 몇 가지 출력 예입니다.
RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia q-depth location 0/6/CPU0
Sun Dec 29 23:10:56.307 UTC
********** FIA-0 **********
Category: q_stats_a-0
Voq ddr pri pktcnt
11 0 2 7
********** FIA-0 **********
Category: q_stats_b-0
Voq ddr pri pktcnt
********** FIA-1 **********
Category: q_stats_a-1
Voq ddr pri pktcnt
11 0 0 2491
11 0 2 5701
********** FIA-1 **********
Category: q_stats_b-1
Voq ddr pri pktcnt
RP/0/RSP0/CPU0:asr9k-1#
RP/0/RSP0/CPU0:asr9k-1#show controllers pm location 0/1/CPU0 | in "switch|if"
Sun Dec 29 23:37:05.621 UTC
Ifname(2): TenGigE0_1_0_2, ifh: 0x2000200 : <==Corresponding interface ten 0/1/0/2
iftype 0x1e
switch_fabric_port 0xb <==== VQI 11
parent_ifh 0x0
parent_bundle_ifh 0x80009e0
RP/0/RSP0/CPU0:asr9k-1#
정상적인 조건에서는 패킷이 대기열에 있는 VOQ를 볼 가능성이 매우 낮습니다. 이 명령은 FIA 대기열에 대한 빠른 실시간 스냅샷입니다. 이 명령은 일반적으로 큐에 있는 패킷을 전혀 표시하지 않습니다.
Trident 기반 라인 카드의 브리지/FPGA 소프트 오류로 인한 트래픽 영향
소프트 오류는 상태 컴퓨터가 동기화되지 않도록 하는 영구적이지 않은 오류입니다. 이는 NP의 패브릭 측 또는 FIA의 인그레스 측에서 CRC(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 fabricshow tech-support npshow 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
이 명령은 모든 온라인 진단 테스트 및 실패의 요약을 제공하고 테스트가 통과했을 때의 마지막 타임스탬프도 제공합니다. 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 loggingshow pfm location alladmin show diagn result loc 0/rsp0/cpu0 test 8 detailadmin show diagn result loc 0/rsp1/cpu0 test 8 detailadmin show diagn result loc 0/rsp0/cpu0 test 9 detailadmin show diagn result loc 0/rsp1/cpu0 test 9 detailadmin show diagn result loc 0/rsp0/cpu0 test 10 detailadmin show diagn result loc 0/rsp1/cpu0 test 10 detailadmin show diagn result loc 0/rsp0/cpu0 test 11 detailadmin show diagn result loc 0/rsp1/cpu0 test 11 detailshow controller fabric fia link-status locationshow controller fabric fia link-status locationshow controller fabric fia bridge sync-status locationshow controller fabric crossbar link-status instance 0 locationshow controller fabric crossbar link-status instance 0 locationshow controller fabric crossbar link-status instance 1 locationshow controller fabric ltrace crossbar locationshow controller fabric ltrace crossbar locationshow tech fabric locationshow tech fabric locationfile
유용한 진단 명령
다음은 진단용으로 유용한 명령 목록입니다.
show diagnostic ondemand settingsshow diagnostic content location < loc >show diagnostic result location < loc > [ test {id|id_list|all} ] [ detail ]show diagnostic statusadmin diagnostic start location < loc > test {id|id_list|test-suite}admin diagnostic stop location < loc >- 관리 진단 온디맨드 반복 < 반복 수 >
admin diagnostic ondemand 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 명령을 사용합니다.
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
2.0 |
26-Jun-2023 |
Cisco 버그 ID CSCuc04493에 대한 자동 복구 개선 사항 섹션을 업데이트하고 FAQ 섹션을 업데이트했습니다. |
1.0 |
29-Oct-2013 |
최초 릴리스 |
피드백