3650/3850 Stack Manager 다시 로드 문제 해결

다운로드 옵션

PDF (324.5 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (85.2 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (77.5 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2024년 4월 3일

문서 ID:201070

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 시스템 보고서를 활용하여 스택 문제를 진단하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

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

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

배경 정보

충돌이 없을 경우 시스템 보고서를 통해 스택 다시 로드 문제를 해결할 경우 NGWC 스위칭 플랫폼에서 일반적으로 stackwise 기술을 사용합니다. 현재 설명서는 시스템 보고서의 사용에 따라 제한되어 있으며 이 설명서에서는 이러한 보고서를 활용하여 스태킹 문제에서 일반적으로 발견되는 문제를 진단하는 방법에 대해 설명합니다. 이 가이드는 스태킹 기능을 지원하는 Cisco IOS® XE를 실행하는 Catalyst 3650/3850 스위치 아키텍처에 특히 중점을 둡니다.

스택와이즈 기술 문제의 대부분은 스택 내 멤버 간의 통신 문제에서 비롯됩니다. 멤버 간의 정보 불일치 또는 연결 손실로 인해 전체 스택에 문제가 침투하여 궁극적으로 스택 관리자를 통한 재설정이 이루어질 수 있습니다. 이 문서에서는 스택 관리자 다시 로드에서 나타나는 일반적인 실패 유형, 시스템 보고서 사용, 진단 및 다양한 유형의 문제를 진단하는 데 사용할 수 있는 관련 CLI 등에 대해 중점적으로 살펴볼 수 있습니다.

시스템 보고서와 스위치 보고서 비교

시스템 보고서는 스택 상태를 인식하는 방법을 기준으로 한 멤버의 종합적인 보고서입니다. 이는 crashinfo가 아니라(추가 디버깅을 위해 메모리를 덤프할 수 있음), 대신 Cisco 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 2014 07:14:32 -04:00 system-report_1_20141015-111342-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 2014 06:41:12 -04:00 system-report_1_20141015-104022-UTC.gz

참고: show tech에서 사용 가능한 파일 시스템이나 crashinfo 파일을 나열할 수 없으므로 해당 스택의 모든 스위치에 대한 dir crashinfo-x의 출력을 수집해야 합니다. 해당 스택의 각 멤버 및 모든 멤버의 전체 그림을 갖는 것이 중요합니다. 업데이트: 최신 Cisco IOS XE 릴리스 >3.6E부터 show tech는 dir crashinfo: + show file systems 출력을 반영할 수 있습니다. Cisco 버그 ID CSCun50428을 참조하십시오.

참고: 등록된 Cisco 사용자만 내부 Cisco 버그 정보 및 툴에 액세스할 수 있습니다.

시스템 보고서의 주목할 만한 섹션

TAC의 관점에서 볼 때, 이는 시스템 보고서 내에서 특정 문제의 이벤트를 진단하는 데 도움이 될 수 있는 몇 가지 항목입니다. 여기에 포함된 다른 서비스의 다른 로그도 개발자가 검토할 수 있습니다.

로그 파일: /mnt/pss/sup_sysmgr_reset.log

이는 재설정이 발견된 이유를 매우 일반적으로 이해하기 위한 짧은 출력입니다. 다음 실패 유형 섹션을 참조하여 이러한 사유가 어떻게 달라질 수 있는지 의미와 상황을 살펴보십시오.

로그 파일: Cisco IOS

Cisco IOSd 내에서 유지 관리되는 로그 버퍼입니다. 사용자가 실행한 모든 명령 또는 Cisco IOSd 내에서 생성된 syslog는 이 섹션에서 확인할 수 있습니다. 가장 최근의 로그는 이 출력의 끝으로 갑니다.

추적 버퍼: stack-mgr-events

다른 멤버가 스택에서 참가/제거될 때 또는 메시지가 들어오는 스택 포트를 포함할 수 있는 스택 관리자에서 표시되는 이벤트를 추적합니다.

추적 버퍼: redundancy-timer-ha_mgr

스택의 스위치 간 keep alive 이벤트를 표시합니다. 타임스탬프는 통신 중단이 언제 시작되었는지를 파악하는 데 도움이 될 수 있습니다.

실패 유형

이 섹션에서는 일반적으로 스택 관리자 프로세스에 의해 호출되는 시스템 보고서에서 일반적으로 나타나는 몇 가지 재설정을 강조할 수 있습니다. 스택 관리자는 스택의 멤버를 관리하는 Linux 프로세스이며 스택의 스위치 간 역할 변경을 감독할 수 있습니다. 스택 관리자는 초기화 또는 역할 선택 중에 문제를 탐지하면 스택을 재설정하기 위해 개별 스위치에 다시 로드 신호를 전송할 수 있습니다. 다음 목록에는 해당 실패 유형과 연결된 알려진 버그가 나열될 수도 있습니다.

참고: 일부 stack-manager 재로드가 소프트웨어 문제로 인한 것은 아닙니다. 실제로 이러한 문제는 핵심 하드웨어 문제의 2차/피해자 문제로 나타나는 경우가 더 많습니다.

Reset Reason: [stack-manager]에서 Reset/Reload를 요청했습니다. [ISSU 비호환성]

스택의 모든 멤버 간에 의 컨피그레이션을 동기화하려고 할 때 대량 동기화 오류가 발생할 경우 이 재설정 유형을 확인할 수 있습니다. 로그 파일 확인: Cisco IOS 또는 활성 스위치의 로그는 이 재설정에 기여한 컨피그레이션을 강조 표시할 수 있습니다.

재설정 사유: 서비스 [iosd] pid:[xyz]가 비정상적으로 [11] 종료되었습니다.

이는 Cisco IOSd 프로세스에서 스위치가 충돌할 때 나타납니다. crashinfo 디렉토리에서 crashinfo 파일 + 코어 덤프를 사용하여 이 오류를 더 디버깅할 수 있습니다.

hap_sup_reset: 재설정 이유:재설정/다시 로드가 [stack-manager]에 의해 요청되었습니다. [스택 병합]

스택 병합은 스택의 활성 스위치로 간주하는 스위치가 둘 이상 있는 경우 표시됩니다. 이는 스택 링에 브레이크가 있는 경우(즉, 2개의 케이블이 스택에서 연결 해제됨) 활성 및 대기 상태가 모두 다른 멤버와의 통신이 끊어질 때 표시됩니다. 이미 전력이 공급된 스위치를 현재 스택에 추가하면 스택에 2개의 활성 스위치가 있으므로 스택 병합이 발생할 수 있습니다.

Cisco 버그 ID CSCuh58098 - 3850 스택은 스택 케이블링 문제가 있을 때 다시 로드할 수 있습니다.

Cisco 버그 ID CSCui56058 - 스택 케이블의 디바운스 로직을 활성화합니다

Cisco 버그 ID CSCup5338 - 3850 IOSD 충돌 | Signal=SIGSEGV(11) @ pm_port_data_from_swidb

hap_sup_reset: 사유 코드: [4] 재설정 사유: [stack-manager]에서 재설정/재로드하도록 요청했습니다. [비호환성으로 인한 스택 병합]

이는 스택에 활성 및 대기 스위치가 있는 상황에서 확인되었습니다. 액티브 스위치가 스탠바이 스위치와의 통신을 끊으면 액티브 스위치가 아직 작동 중이지만 스탠바이 스위치가 액티브 스위치로 인수를 시도할 수 있습니다.

Cisco 버그 ID CSCuo49555

Cisco 버그 ID CSCup58016 - 관리 포트의 유니캐스트 플러드로 인해 3850/3650이 충돌함

Cisco 버그 ID CSCur07909 - 활성 및 대기 연결 손실로 인한 스택 병합

Reset Reason: [stack-manager]에서 Reset/Reload를 요청했습니다. [ASIC 투표 후 잘못된 인접 디바이스가 발견되었습니다.]

스위치는 스택 내에서 인접한 스위치를 결정하기 위해 부팅 중에 ASIC 투표에 참여합니다. 이 재설정은 인접 디바이스가 자신을 선언하기 위해 타이머가 만료되거나 브로드캐스트 대화 중에 논리 오류가 발생한 경우에 표시됩니다. 이는 교체를 통해 해결된 스택 케이블의 결함과 관련하여 발견되었습니다.

Cisco 버그 ID CSCun60777 - ASIC 투표 후 발생한 잘못된 네이버로 인해 스위치가 다시 로드되었습니다.

Cisco 버그 ID CSCud93761 - ASIC 투표 후 발생한 잘못된 네이버로 인해 스위치가 다시 로드되었습니다.

Cisco 버그 ID CSCun17506 - Amur:ng3k: 3개 멤버 스택의 두 스택 포트에 동일한 인접 디바이스가 표시됨

hap_sup_reset: 이유 코드: [4] 재설정 이유:재설정/다시 로드가 [stack-manager]에 의해 요청되었습니다. [active 및 standby 모두 손실됨]

이는 일반적으로 활성 또는 대기 역할이 아닌 스택의 멤버에서 나타납니다. 액티브에 장애가 발생한 경우 스택의 액티브 역할을 맡을 스탠바이 스위치가 없는 경우 전체 스택을 재설정할 수 있습니다. 스택이 불안정한 상태이거나 이중화 정책이 아직 동기화되지 않은 경우 이를 확인할 수 있습니다. 이는 액티브/스탠바이 스위치가 다운된 이유나 리던던시가 올바르게 동기화되지 않음을 나타낼 수 있습니다. 이는 하프 링 설정에서 스택이 구성된 경우에도 확인할 수 있습니다.

Cisco 버그 ID CSCup53882 - 3850 스택 재부팅 시 멤버 스위치 - [active 및 standby 모두 손실]

hap_sup_reset: 이유 코드: [1] 재설정 이유:재설정/다시 로드가 [stack-manager]에 의해 요청되었습니다. [Keepalive_Timeout]

Keep Alive 메시지가 스택의 스위치에서 수신되지 않을 때 표시됩니다. Trace Buffer: redundancy-timer-ha_mgr을 보면 keep alive 메시지의 교환을 보여주며 통신 중단이 시작된 시점을 파악할 수 있습니다. 스택의 나머지 부분에서 스위치 보고서를 수집하고 일정 기간 동안 로그를 살펴보는 것이 도움이 될 수 있습니다.

hap_sup_reset: 재설정 이유:재설정/다시 로드가 [stack-manager]에 의해 요청되었습니다. [Reload 명령]

이는 매우 직관적인 재설정 이유입니다. 이는 stack-manager가 CLI를 통해 호출되거나 SNMP(Management Device)를 통해 외부에서 호출될 수 있는 다시 로드 요청을 수신할 때 나타납니다. Cisco 버그 ID CSCuj17317의 경우, 이 역시 실행된 reload 명령으로 표시됩니다. 로그 파일: Cisco 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

잠재적인 스택 케이블 또는 포트 문제 진단

증상 1) 재설정 전에 스택 포트가 펄럭이는 경우 스택 케이블 문제의 징후가 나타납니다. 로그 파일: 재설정 전의 Cisco IOS 보고서는 일반적으로 시작하는 것이 좋습니다. 다음은 현재 SW2와 대기 SW1에 모두 등록된 스택 포트의 플래핑이 표시되는 예입니다. 이 동일한 스택 포트는 재설정의 각 인스턴스에서 플랩되고 있으며 스택 케이블을 교체한 시점으로 해결되었습니다.

=====================  log file: Cisco 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> read register SifRacDataCrcErrorCnt 스위치 <switch#>

데이터 CRC 오류가 있는 세그먼트입니다.

show platform port-asic <0-1> read register SifRacRwCrcErrorCnt 스위치 <switch#>

실패한 CRC 검사 시 증가합니다.

show platform port-asic <0-1> read register SifRacPcsCodeWordErrorCnt 스위치 <switch#>

탐지된 디스패리티 오류를 실행하는 잘못된 PCS 코드, 알 수 없는 PCS 코드워드에서 증가합니다.

show platform port-asic <0-1> read register SifRacInvalidRingWordCnt switch <switch#>

스택의 비트 오류로 인해 ringword CRC 오류가 발생했습니다.

Polaris(16.X 코드)의 경우 다음 명령이 있습니다.

show plat hardware fed sw <#/active/standby> fwd-asic register read register-name SifRacDataCrcErrorCnt asic <0-1>

show plat 하드웨어 fed sw <#/active/standby> fwd-asic 레지스터 읽기 레지스터 이름 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에 CRC가 있는 [0] 링이 증가하는 것을 볼 수 있으며 이 문제를 해결하려면 스택 케이블을 교체하십시오.

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에 도달하면 0x00000000으로 다시 래핑할 수 있습니다.

추가 팁

1. Crashinfo 디렉토리 보관

스택에 스위치가 많을수록 더 많은 보고서 파일을 수집할 수 있습니다. 생성되는 보고서 수에 압도당하기 쉽습니다. 실패를 분리하기 위해서는 조직이 필수적입니다. 가능한 경우 각 스위치가 특정 인시던트에 대한 보고서 파일을 작성한 시간의 타임스탬프와 일관성을 찾습니다. 클라이언트가 여러 파일을 업로드하지 않도록 해당 스위치에서 매우 구체적인 보고서를 요청하십시오. crashinfo 디렉토리도 아카이브하여 Cisco 사용자가 단일 아카이브에 관련 보고서가 포함되도록 할 수 있습니다. 다음 예에서는 flash 디렉토리에 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. 불안정한 스택 복구

스택 선택 프로세스가 발생한 후 부팅하는 동안 스택 다시 로드에서 여러 멤버가 표시되는 경우가 있습니다. 다시 로드된 스위치가 자신을 활성으로 간주할 경우, 이는 종종 스택 병합 이벤트로 이어지며 부팅 루프 상태가 될 수 있습니다. 이 경우 Cisco 고객에게 다음과 같은 질문을 하는 것이 좋습니다.

전체 스택의 전원을 끄고 모든 스택 케이블을 단단히 재설정합니다.
모든 멤버가 예상 상태로 수렴될 때까지 스택의 각 멤버 스위치를 하나씩 켭니다.
멤버가 스택에 조인하지 못하는 경우 스택에서 이를 제거하고 이 개인을 독립 실행형으로 부팅하여 추가 트러블슈팅을 시도합니다.

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>

개정	게시 날짜	의견
5.0	03-Apr-2024	재인증
1.0	14-Mar-2017	최초 릴리스