본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.
Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.
스택 기술을 사용하는 NGWC 스위칭 플랫폼에서는 충돌이 없는 경우 시스템 보고서를 통해 트러블슈팅 스택이 다시 로드됩니다.현재 설명서는 시스템 보고서 사용에 따라 제한되며, 이 설명서는 스태킹 문제로 일반적으로 발견되는 문제를 진단하기 위해 이러한 보고서를 활용하는 방법을 설명하기 위해 작성되었습니다.이 가이드는 스태킹 기능을 지원하는 IOS-XE를 실행하는 Catalyst 3650/3850 스위칭 아키텍처를 위해 특별히 제작되었습니다.
스택와이즈 기술과 관련된 문제의 대부분은 스택 내의 멤버 간 통신 문제로 인해 발생합니다.멤버 간에 일관성이 없거나 연결이 끊기면 전체 스택에 걸쳐 문제가 발생하여 결국 스택 관리자를 사용하여 재설정할 수 있습니다.이 문서에서는 스택 관리자 리로드와 함께 나타나는 몇 가지 일반적인 장애 유형, 시스템 보고서 사용, 진단과 다양한 유형의 문제를 진단할 수 있는 관련 CLI를 중점적으로 살펴봅니다.
시스템 보고서는 멤버가 스택의 상태를 인식하는 방법에 대한 종합적인 보고서입니다.이 보고서는 crashinfo가 아닙니다(추가 디버깅을 위해 메모리를 덤프함). 대신 IOS-XE에서 실행되는 다양한 서비스에 대한 로그 및 디버깅 정보를 포함하는 보고서입니다. 이 보고서는 해당 서비스의 상태를 추적하는 개발에도 유용합니다.시스템 보고서는 스택 관리자에 의해 스위치가 다시 로드되거나, 프로세스 충돌이 발생했거나, 실시간 작업 중에 사용자가 수동으로 생성할 때 생성할 수 있습니다.
대부분의 경우 스택에서 단일 스위치가 실패할 수 있지만 나머지 멤버는 그대로 유지될 수 있습니다.지정된 시간에 스택 상태에 대한 정보로 수집하기 위해 나머지 멤버가 멤버 작동이 중지된 것을 감지하면 나머지 멤버가 생성되도록 switch_reports가 도입되었습니다.switch_report 는 해당 멤버가 스택의 현재 상태를 인식하는 방법에 대한 로컬 보고서가 됩니다.
참고:이러한 보고서는 작성되고 압축되므로 'more'를 사용하여 터미널에 인쇄할 수 없습니다.로그를 보려면 스위치에서 분리하고 압축 해제해야 합니다.
시스템 보고서는 일반적으로 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
참고:'show tech'는 사용 가능한 파일 시스템이나 crashinfo 파일을 나열하지 않으므로 해당 스택의 모든 스위치에 대해 "dir crashinfo-x:"의 출력을 수집해야 합니다.해당 스택의 각 멤버 및 모든 멤버에 대한 전체 그림을 가지고 있어야 합니다.업데이트:최신 IOS-XE 릴리스 3.6E부터 show tech는 "dir crashinfo:' + 'show file systems' 출력을 반영합니다.CSCun50428 참조 .
TAC의 관점에서 볼 때, 이러한 항목은 시스템 보고서 내에서 특정 문제의 이벤트를 진단하는 데 도움이 되는 자주 표시되는 항목 중 일부입니다.여기에 포함된 다른 서비스의 다른 로그도 있습니다. 이 경우 개발 팀에서 검토하고자 할 수 있습니다.
로그 파일:/mnt/pss/sup_sysmgr_reset.log
이는 재설정이 표시되는 이유를 매우 일반적으로 이해하는 짧은 출력입니다.이러한 사유가 어떻게 달라지는지에 대한 의미와 상황을 보려면 아래의 실패 유형 섹션을 참조하십시오.
로그 파일:IOS
이는 IOSd 내에서 유지 관리되는 로그 버퍼입니다.IOSd 내에서 생성된 사용자 또는 syslog에서 실행된 명령은 이 섹션에서 확인할 수 있습니다.가장 최근 로그는 이 출력의 끝을 향해 있습니다.
추적 버퍼:stack-mgr-events
스택 관리자에서 보이는 이벤트를 추적하여 다른 멤버가 스택에서 연결/제거되거나 메시지가 들어오는 스택 포트를 포함합니다.
추적 버퍼:이중화 timer-ha_mgr
스택의 스위치 간 연결 유지 이벤트를 표시합니다.타임스탬프는 통신 중단이 시작된 시기를 결정하는 데 도움이 됩니다.
이 섹션에서는 일반적으로 스택 관리자 프로세스에 의해 호출되는 시스템 보고서에서 일반적으로 보이는 일부 재설정을 강조 표시합니다.Stack Manager는 스택의 멤버를 관리하고 스택의 스위치 간 역할 변경을 감독하는 Linux 프로세스입니다.초기화 또는 역할 선택 중에 스택 관리자가 문제를 탐지하면 스택이 재설정되도록 개별 스위치에 다시 로드 신호를 보냅니다.아래에는 해당 오류 유형과 연결된 알려진 버그도 나열됩니다.
참고:모든 stack-manager 재로드가 소프트웨어 문제로 인한 것은 아닙니다.실제로 이러한 문제가 하드웨어 문제의 보조/피해자 문제로 나타나는 경우가 많습니다.
스택의 모든 멤버 간에 활성 상태의 컨피그레이션을 동기화하는 동안 대량 동기화 오류가 발생하면 이 유형의 재설정이 표시될 수 있습니다.로그 파일 확인:IOS 또는 활성 스위치의 로그에는 이 재설정에 기여한 컨피그레이션이 강조 표시될 수 있습니다.
이는 스위치가 IOSd 프로세스에서 충돌할 때 나타납니다.crashinfo 파일의 crashinfo 디렉토리 및 코어 덤프를 확인하여 이 오류를 더 디버깅할 수 있습니다.
스택 병합은 스택의 활성 스위치라고 믿는 둘 이상의 스위치가 있을 때 나타납니다.이는 스택 링이 끊어질 때(예: 두 개의 케이블이 스택에서 분리됨)이므로 활성 및 대기 모두 다른 멤버와의 통신이 끊길 때 나타납니다.이미 전원이 공급되는 스위치를 기존 스택에 추가하면 스택에 두 개의 활성 스위치가 있으므로 스택 병합이 발생할 수 있습니다.
CSCuh58098 - 스택 케이블링 문제가 있을 때 3850 스택이 다시 로드될 수 있음
CSCui56058 - 스택 케이블에 대한 Debounce 로직 활성화
CSCup53338 - 3850 OSD 충돌 | Signal=SIGSEGV(11) @ pm_port_data_from_swidb
이는 액티브 및 스탠바이 스위치가 스택에 있을 때 확인되었습니다.액티브 스위치가 스탠바이 스위치와의 통신이 끊기면, 스탠바이는 액티브 가 아직 작동 중임에도 불구하고 액티브 스위치로 인계 받기를 시도합니다.
CSCuo49555 /CSCup58016 - 관리 포트의 유니캐스트 플러드로 인해 3850/3650이 충돌합니다.
CSCur07909 - 활성 및 대기 연결이 끊겨 스택 병합
스위치는 부팅 중에 ASIC 투표에 참여하여 스택 내에서 인접 스위치를 확인합니다.네이버가 자신을 선언하기 위해 타이머가 만료되거나 브로드캐스트 대화 중에 논리 오류가 발생한 경우 이 재설정을 확인할 수 있습니다.이는 교체를 통해 해결된 결함이 있는 스택 케이블 상황에서 확인되었습니다.
CSCun60777 - ASIC 투표 후 잘못된 인접 디바이스가 발견되어 스위치가 다시 로드되었습니다.
CSCud93761 - ASIC 투표 후 잘못된 인접 디바이스가 발견되어 스위치가 다시 로드되었습니다.
이는 일반적으로 활성 또는 대기 역할이 아닌 스택의 멤버에서 볼 수 있습니다.액티브 가 실패할 때 스택의 활성 역할을 맡을 스탠바이 스위치가 없으면 전체 스택이 재설정됩니다.스택이 불안정한 상태이거나 이중화 정책이 아직 동기화되지 않은 경우 이를 확인할 수 있습니다.이는 액티브/스탠바이 스위치가 다운된 이유나 리던던시가 올바르게 동기화되지 않는다는 징후일 가능성이 높습니다.이는 하프 링 설정에서 스택이 구성된 경우에도 볼 수 있습니다.
CSCup53882 - 3850 스택 리부팅의 멤버 스위치 - [활성 및 대기 둘 다 손실됨]
스택의 스위치에서 Keep Alive 메시지를 받지 못할 때 표시됩니다."추적 버퍼:redundancy-timer-ha_mgr"은 연결 유지 메시지의 교환을 표시하고 통신 분석이 시작된 시점의 시간 관점을 제공해야 합니다.나머지 스택에서 스위치 보고서를 수집하고 시간 프레임 동안 로그를 확인하는 것이 도움이 될 수 있습니다.
이는 매우 직관적인 재설정 사유입니다. 스택 관리자가 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#> 읽기
show platform port-asic <0-1> register SifRacRwCrcErrorCnt 스위치 <switch#> 읽기
show platform port-asic <0-1> 읽기 레지스터 SifRacPcsCodeWordErrorCnt 스위치 <switch#>
show platform port-asic <0-1> 읽기 레지스터 SifRacInvalidRingWordCnt 스위치 <switch#>
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으로 다시 래핑됩니다.
스택에 스위치가 더 많을수록 더 많은 보고서 파일이 수집됩니다.생성되는 보고서 수에 압도되기 쉽습니다.조직은 장애를 격리하는 데 매우 중요합니다.가능한 경우 각 스위치가 지정된 인시던트에 대해 보고서 파일을 작성할 때 타임스탬프를 사용하여 일관성을 찾습니다.여기에서 고객이 여러 파일을 업로드하지 않도록 해당 스위치에서 해당 특정 보고서를 요청합니다.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:
스택 선택 프로세스가 수행된 후 부팅 중에 스택에서 여러 멤버가 다시 로드되는 경우가 있을 수 있습니다.다시 로드된 스위치가 자신을 활성으로 간주하는 경우 이는 종종 스택 병합 이벤트로 이어질 수 있으며 부팅 루프 상태가 됩니다.이러한 상황에서 고객에게 다음과 같은 질문을 하는 것이 좋습니다.
- 전체 스택의 전원을 끄고 모든 스택 케이블을 단단히 재장착합니다.
- 모든 멤버가 예상 상태로 통합될 때까지 스택의 각 멤버 스위치의 전원을 하나씩 켜십시오.
- 구성원이 스택에 조인하지 못한 경우 스택에서 이를 제거하고 이 개인을 독립형 유닛으로 부팅하여 추가 문제를 해결하십시오.
시스템 보고서를 수동으로 생성하려면 '서비스 내부'를 활성화해야 합니다.이렇게 하면 시스템 보고서가 스위치별로 수행할 수 있는 텍스트 파일로 작성됩니다.
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>