시스템 보고서를 통해 스택 관리자에 의한 3650/3850 재로드 문제 해결
목차
소개
스택 기술을 사용하는 NGWC 스위칭 플랫폼에서는 충돌이 없는 경우 시스템 보고서를 통해 트러블슈팅 스택이 다시 로드됩니다.현재 설명서는 시스템 보고서 사용에 따라 제한되며, 이 설명서는 스태킹 문제로 일반적으로 발견되는 문제를 진단하기 위해 이러한 보고서를 활용하는 방법을 설명하기 위해 작성되었습니다.이 가이드는 스태킹 기능을 지원하는 IOS-XE를 실행하는 Catalyst 3650/3850 스위칭 아키텍처를 위해 특별히 제작되었습니다.
스택와이즈 기술과 관련된 문제의 대부분은 스택 내의 멤버 간 통신 문제로 인해 발생합니다.멤버 간에 일관성이 없거나 연결이 끊기면 전체 스택에 걸쳐 문제가 발생하여 결국 스택 관리자를 사용하여 재설정할 수 있습니다.이 문서에서는 스택 관리자 리로드와 함께 나타나는 몇 가지 일반적인 장애 유형, 시스템 보고서 사용, 진단과 다양한 유형의 문제를 진단할 수 있는 관련 CLI를 중점적으로 살펴봅니다.
배경 정보:
시스템 보고서와 스위치 보고서 비교
시스템 보고서는 멤버가 스택의 상태를 인식하는 방법에 대한 종합적인 보고서입니다.이 보고서는 crashinfo가 아닙니다(추가 디버깅을 위해 메모리를 덤프함). 대신 IOS-XE에서 실행되는 다양한 서비스에 대한 로그 및 디버깅 정보를 포함하는 보고서입니다. 이 보고서는 해당 서비스의 상태를 추적하는 개발에도 유용합니다.시스템 보고서는 스택 관리자에 의해 스위치가 다시 로드되거나, 프로세스 충돌이 발생했거나, 실시간 작업 중에 사용자가 수동으로 생성할 때 생성할 수 있습니다.
대부분의 경우 스택에서 단일 스위치가 실패할 수 있지만 나머지 멤버는 그대로 유지될 수 있습니다.지정된 시간에 스택 상태에 대한 정보로 수집하기 위해 나머지 멤버가 멤버 작동이 중지된 것을 감지하면 나머지 멤버가 생성되도록 switch_reports가 도입되었습니다.switch_report 는 해당 멤버가 스택의 현재 상태를 인식하는 방법에 대한 로컬 보고서가 됩니다.
시스템/스위치 보고서 수집 위치
시스템 보고서는 일반적으로 crashinfo에 기록됩니다.해당 스택의 멤버 디렉토리예를 들어 x-member 스위치 스택이 있는 경우 각 스위치에는 "dir crashinfo-x"를 사용하여 액세스할 수 있는 고유한 crashinfo 디렉토리가 있습니다. 여기서 'x'는 스택 내의 해당 멤버에 해당합니다.
3850#dir crashinfo-1:
crashinfo 디렉토리:/
11 -rwx 355 2015년 8월 14일 07:48:17 -04:00 last_systemreport_log
12 -rwx 724015년 10월 15일 07:14:32 -04:00 system-report_1_20141015-11342-UTC.gz
3850#dir crashinfo-2:
crashinfo-2 디렉토리:/
11 -rwx 357 2015년 8월 14일 07:50:49 -04:00 last_systemreport_log
12 -rwx 751340 10월 15일 06:41:12 -04:00 system-report_1_20141015-104022-UTC.gz
시스템 보고서의 흥미로운 섹션
TAC의 관점에서 볼 때, 이러한 항목은 시스템 보고서 내에서 특정 문제의 이벤트를 진단하는 데 도움이 되는 자주 표시되는 항목 중 일부입니다.여기에 포함된 다른 서비스의 다른 로그도 있습니다. 이 경우 개발 팀에서 검토하고자 할 수 있습니다.
로그 파일:/mnt/pss/sup_sysmgr_reset.log
이는 재설정이 표시되는 이유를 매우 일반적으로 이해하는 짧은 출력입니다.이러한 사유가 어떻게 달라지는지에 대한 의미와 상황을 보려면 아래의 실패 유형 섹션을 참조하십시오.
로그 파일:IOS
이는 IOSd 내에서 유지 관리되는 로그 버퍼입니다.IOSd 내에서 생성된 사용자 또는 syslog에서 실행된 명령은 이 섹션에서 확인할 수 있습니다.가장 최근 로그는 이 출력의 끝을 향해 있습니다.
추적 버퍼:stack-mgr-events
스택 관리자에서 보이는 이벤트를 추적하여 다른 멤버가 스택에서 연결/제거되거나 메시지가 들어오는 스택 포트를 포함합니다.
추적 버퍼:이중화 timer-ha_mgr
스택의 스위치 간 연결 유지 이벤트를 표시합니다.타임스탬프는 통신 중단이 시작된 시기를 결정하는 데 도움이 됩니다.
실패 유형
이 섹션에서는 일반적으로 스택 관리자 프로세스에 의해 호출되는 시스템 보고서에서 일반적으로 보이는 일부 재설정을 강조 표시합니다.Stack Manager는 스택의 멤버를 관리하고 스택의 스위치 간 역할 변경을 감독하는 Linux 프로세스입니다.초기화 또는 역할 선택 중에 스택 관리자가 문제를 탐지하면 스택이 재설정되도록 개별 스위치에 다시 로드 신호를 보냅니다.아래에는 해당 오류 유형과 연결된 알려진 버그도 나열됩니다.
참고:모든 stack-manager 재로드가 소프트웨어 문제로 인한 것은 아닙니다.실제로 이러한 문제가 하드웨어 문제의 보조/피해자 문제로 나타나는 경우가 많습니다.
재설정 사유: [stack-manager]에서 재설정/다시 로드를 요청했습니다.[ISSU 비호환성]
스택의 모든 멤버 간에 활성 상태의 컨피그레이션을 동기화하는 동안 대량 동기화 오류가 발생하면 이 유형의 재설정이 표시될 수 있습니다.로그 파일 확인:IOS 또는 활성 스위치의 로그에는 이 재설정에 기여한 컨피그레이션이 강조 표시될 수 있습니다.
재설정 사유:서비스 [osd] pid:[xyz]이(가) 비정상적으로 [11]에 종료되었습니다.
이는 스위치가 IOSd 프로세스에서 충돌할 때 나타납니다.crashinfo 파일의 crashinfo 디렉토리 및 코어 덤프를 확인하여 이 오류를 더 디버깅할 수 있습니다.
hap_sup_reset:재설정 사유: [stack-manager]에서 재설정/다시 로드를 요청했습니다.[스택 병합]
스택 병합은 스택의 활성 스위치라고 믿는 둘 이상의 스위치가 있을 때 나타납니다.이는 스택 링이 끊어질 때(예: 두 개의 케이블이 스택에서 분리됨)이므로 활성 및 대기 모두 다른 멤버와의 통신이 끊길 때 나타납니다.이미 전원이 공급되는 스위치를 기존 스택에 추가하면 스택에 두 개의 활성 스위치가 있으므로 스택 병합이 발생할 수 있습니다.
CSCuh58098 
- 스택 케이블링 문제가 있을 때 3850 스택이 다시 로드될 수 있음
CSCui56058 - 스택 케이블에 대한 Debounce 로직 활성화
CSCup53338 - 3850 OSD 충돌 | Signal=SIGSEGV(11) @ pm_port_data_from_swidb
hap_sup_reset:이유 코드:[4] 재설정 이유: [stack-manager]에서 재설정/다시 로드합니다.[비호환성으로 인한 스택 병합]
이는 액티브 및 스탠바이 스위치가 스택에 있을 때 확인되었습니다.액티브 스위치가 스탠바이 스위치와의 통신이 끊기면, 스탠바이는 액티브 가 아직 작동 중임에도 불구하고 액티브 스위치로 인계 받기를 시도합니다.
CSCuo49555 /CSCup58016 - 관리 포트의 유니캐스트 플러드로 인해 3850/3650이 충돌합니다.
CSCur07909 - 활성 및 대기 연결이 끊겨 스택 병합
재설정 사유: [stack-manager]에서 재설정/다시 로드를 요청했습니다.[ASIC 투표 후 잘못된 인접 디바이스가 발견되었습니다.]
스위치는 부팅 중에 ASIC 투표에 참여하여 스택 내에서 인접 스위치를 확인합니다.네이버가 자신을 선언하기 위해 타이머가 만료되거나 브로드캐스트 대화 중에 논리 오류가 발생한 경우 이 재설정을 확인할 수 있습니다.이는 교체를 통해 해결된 결함이 있는 스택 케이블 상황에서 확인되었습니다.
CSCun60777 - ASIC 투표 후 잘못된 인접 디바이스가 발견되어 스위치가 다시 로드되었습니다.
CSCud93761 - ASIC 투표 후 잘못된 인접 디바이스가 발견되어 스위치가 다시 로드되었습니다.
hap_sup_reset:이유 코드:[4] 재설정 이유: [stack-manager]에서 재설정/다시 로드를 요청했습니다.[활성 및 대기 둘 다 손실됨]
이는 일반적으로 활성 또는 대기 역할이 아닌 스택의 멤버에서 볼 수 있습니다.액티브 가 실패할 때 스택의 활성 역할을 맡을 스탠바이 스위치가 없으면 전체 스택이 재설정됩니다.스택이 불안정한 상태이거나 이중화 정책이 아직 동기화되지 않은 경우 이를 확인할 수 있습니다.이는 액티브/스탠바이 스위치가 다운된 이유나 리던던시가 올바르게 동기화되지 않는다는 징후일 가능성이 높습니다.이는 하프 링 설정에서 스택이 구성된 경우에도 볼 수 있습니다.
CSCup53882 - 3850 스택 리부팅의 멤버 스위치 - [활성 및 대기 둘 다 손실됨]
hap_sup_reset:이유 코드:[1] 재설정 이유: [stack-manager]에서 재설정/다시 로드를 요청했습니다.[Keepalive_Timeout]
스택의 스위치에서 Keep Alive 메시지를 받지 못할 때 표시됩니다."추적 버퍼:redundancy-timer-ha_mgr"은 연결 유지 메시지의 교환을 표시하고 통신 분석이 시작된 시점의 시간 관점을 제공해야 합니다.나머지 스택에서 스위치 보고서를 수집하고 시간 프레임 동안 로그를 확인하는 것이 도움이 될 수 있습니다.
hap_sup_reset:재설정 사유: [stack-manager]에서 재설정/다시 로드를 요청했습니다.[다시 로드 명령]
이는 매우 직관적인 재설정 사유입니다. 스택 관리자가 CLI를 통해 또는 SNMP(Management Device)를 통해 외부에서 호출할 수 있는 다시 로드 요청을 수신할 때 나타납니다. CSCuj17317의 경우 또한 'reload command'가 실행된 것으로 표시됩니다.로그 파일에서:다음과 같은 IOS를 볼 수 있습니다.
CMD: 'reload'
%SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload command.
%STACKMGR-1-RELOAD_REQUEST: 1 stack-mgr: Received reload request for all switches, reason Reload command
%STACKMGR-1-RELOAD: 1 stack-mgr: Reloading due to reason Reload command
관련 버그
CSCur76872 - 시스템이 SDP 버퍼가 부족하면 스택 관리자가 중단됩니다.
CSCup49704 - 3850 FED 충돌 - SPI 채널 FED_SPI_FLCD,FED_SPI_FAST를 기다리는 중...
잠재적 스택 케이블/포트 문제 진단
증상 1) 재설정 전에 스택 포트의 플래핑에 따라 스택 케이블 연결 문제가 발생하는 모든 징후를 확인할 수 있습니다."로그 파일:재설정 전 IOS" 보고서는 일반적으로 시작하기에 좋습니다.다음은 현재 SW2와 스탠바이 SW1에 모두 등록된 스택 포트의 플래핑이 표시되는 예입니다. 이 동일한 스택 포트는 리셋의 각 인스턴스에서 플래핑되고 있으며 스택 케이블을 교체하여 해결되었습니다.
===================== log file: IOS =====================
.
.
Aug 8 21:40:14.532 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr: Stack port 1 on switch 1 is down (SW1-1)
Aug 8 21:40:17.242 UTC: %STACKMGR-1-STACK_LINK_CHANGE: STANDBY:1 stack-mgr: Stack port 1 on switch 1 is up (SW1-1)
Aug 8 21:46:11.194 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is down
Aug 8 21:46:12.937 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is up
Aug 8 21:48:23.063 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is down
Aug 8 21:48:24.558 UTC: %STACKMGR-1-STACK_LINK_CHANGE: 2 stack-mgr: Stack port 2 on switch 2 is up
Aug 8 21:50:40.666 UTC: %STACKMGR-6-SWITCH_REMOVED: 2 stack-mgr: Switch 1 has been removed from the stack.
Aug 8 21:50:40.671 UTC: Starting SWITCH-DELETE sequence, switch 1
증상 2) stackwise 설정이 사용됨(180, 480, 더하기)에 따라 포트 ASIC당 전송 링 수가 달라집니다. 이러한 명령은 각 전송 링에 대해 표시되는 읽기 오류 수의 합계를 유지하는 글로벌 레지스터를 폴링합니다.'Port-asic 0'은 스택 포트 1에 해당하고 'port-asic 1'은 스택 포트 2에 해당합니다. 모든 스위치에 대해 이 값을 실행해야 하며, 증가된 카운트의 징조는 포트에서 문제가 있는지 또는 스택 케이블에 문제가 있는지 여부를 격리할 수 있습니다.
몇 분 동안 여러 번 수집하여 카운트의 델타를 비교할 수 있습니다.
show platform port-asic <0-1> register SifRacDataCrcErrorCnt 스위치 <switch#> 읽기
- 데이터 CRC 오류가 있는 세그먼트
show platform port-asic <0-1> register SifRacRwCrcErrorCnt 스위치 <switch#> 읽기
- 실패한 모든 CRC 확인 시 증가됨
show platform port-asic <0-1> 읽기 레지스터 SifRacPcsCodeWordErrorCnt 스위치 <switch#>
- 잘못된 PCS 코드에서 증가하며 알 수 없는 PCS 코드, 실행 불균형 오류가 감지되었습니다.
show platform port-asic <0-1> 읽기 레지스터 SifRacInvalidRingWordCnt 스위치 <switch#>
- 스택의 비트 오류로 인해 링워드 CRC 오류 발생
Polaris(16.X 코드)의 경우 명령은 다음과 같습니다.
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacDataCrcErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacRwCrcErrorCnt asic<0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacPcsCodeWordErrorCnt asic <0-1>
show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacInvalidRingWordCnt asic <0-1>
다음은 스택 병합 이벤트를 통해 플랩 스택 포트의 아무런 흔적도 없이 2멤버 스택의 두 멤버를 모두 확인한 예입니다.스위치 1의 스택 포트-1에서 링[0]이(가) CRC로 증가하여 스택 케이블을 교체하면서 이 문제가 해결되었습니다.
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 11%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:49.119 EDT Thu Aug 20 2015
For asic 0
SifRacRwCrcErrorCnt on Asic 0
[0]
count 0x00000031 <<
[1]
count 0x00000001
[2]
count 0x00000000
[3]
count 0x00000001
[4]
count 0x00000000
[5]
count 0x00000001
3850#$show platform port-asic 0 read register SifRacRwCrcErrorCnt switch 1
Load for five secs: 9%/4%; one minute: 11%; five minutes: 12%
Time source is NTP, 14:02:53.550 EDT Thu Aug 20 2015
For asic 0
SifRacRwCrcErrorCnt on Asic 0
[0]
count 0x000000c9 <<
[1]
count 0x00000001
[2]
count 0x00000000
[3]
count 0x00000001
[4]
count 0x00000000
[5]
count 0x00000001
참고:살펴보는 레지스터에 따라 마스크는 각 경우에 다를 수 있습니다.위의 예에서 마스크는 마지막 14비트에서 감싸집니다.따라서 카운터가 0x00003FFF에 도달하면 0x0000000으로 다시 래핑됩니다.
추가 팁
1 . Crashinfo 디렉토리 보관
스택에 스위치가 더 많을수록 더 많은 보고서 파일이 수집됩니다.생성되는 보고서 수에 압도되기 쉽습니다.조직은 장애를 격리하는 데 매우 중요합니다.가능한 경우 각 스위치가 지정된 인시던트에 대해 보고서 파일을 작성할 때 타임스탬프를 사용하여 일관성을 찾습니다.여기에서 고객이 여러 파일을 업로드하지 않도록 해당 스위치에서 해당 특정 보고서를 요청합니다.crashinfo 디렉토리도 아카이빙하여 고객이 관심 있는 보고서를 포함하는 단일 아카이브를 보낼 수 있습니다.다음은 플래시 디렉토리에 'crashinfo-archive.tar'라는 아카이브를 만듭니다.
F340.03.10-3800-1#archive tar /create ?
WORD Tar filename
F340.03.10-3800-1#archive tar /create crashinfo-archive.tar ?
WORD Dir to archive files from
F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo ?
WORD File or Dir
<cr>
F340.03.10-3800-1#archive tar /create crashinfo-archive.tar crashinfo:
2. 불안정한 스택 복구
스택 선택 프로세스가 수행된 후 부팅 중에 스택에서 여러 멤버가 다시 로드되는 경우가 있을 수 있습니다.다시 로드된 스위치가 자신을 활성으로 간주하는 경우 이는 종종 스택 병합 이벤트로 이어질 수 있으며 부팅 루프 상태가 됩니다.이러한 상황에서 고객에게 다음과 같은 질문을 하는 것이 좋습니다.
- 전체 스택의 전원을 끄고 모든 스택 케이블을 단단히 재장착합니다.
- 모든 멤버가 예상 상태로 통합될 때까지 스택의 각 멤버 스위치의 전원을 하나씩 켜십시오.
- 구성원이 스택에 조인하지 못한 경우 스택에서 이를 제거하고 이 개인을 독립형 유닛으로 부팅하여 추가 문제를 해결하십시오.
3. 수동으로 시스템 보고서 생성
시스템 보고서를 수동으로 생성하려면 '서비스 내부'를 활성화해야 합니다.이렇게 하면 시스템 보고서가 스위치별로 수행할 수 있는 텍스트 파일로 작성됩니다.
3800-1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
3800-1(config)#service internal
3800-1(config)#exit
3800-1#resource create_system_report ?
WORD system report filename
3800-1#resource create_system_report sysreport.txt ?
switch Switch number
<cr>
3800-1#resource create_system_report sysreport.txt switch ?
<1-1> Switch number
3800-1#resource create_system_report sysreport.txt switch 1 ?
<cr>
피드백