소개
이 문서에서는 소프트웨어 강제 충돌의 가장 빈번한 원인과 트러블슈팅을 위해 수집해야 하는 정보에 대해 설명합니다. 소프트웨어 강제 충돌에 대한 TAC 서비스 요청을 열 경우, 문제 해결을 위해 수집해야 할 정보가 필요합니다.
사전 요구 사항
요구 사항
이 문서의 독자는 다음 주제에 대해 알고 있어야 합니다.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
소프트웨어 강제 충돌은 라우터가 심각하고 복구할 수 없는 오류를 감지하고 손상된 데이터를 전송하지 않도록 스스로 다시 로드할 때 발생합니다. 대부분의 소프트웨어 강제 충돌은 Cisco IOS® 소프트웨어 버그로 인해 발생하지만 일부 플랫폼(예: 이전 Cisco 4000)에서는 하드웨어 문제를 소프트웨어 강제 충돌로 보고할 수 있습니다.
라우터의 전원을 껐다 켜거나 수동으로 다시 로드하지 않은 경우 show version 명령의 출력에는 다음 내용이 표시됩니다.
Router uptime is 2 days, 21 hours, 30 minutes
System restarted by error - Software-forced crash, PC 0x316EF90 at 20:22:37 edt
System image file is "flash:c2500-is-l.112-15a.bin", booted via flash
Cisco 디바이스에서 show version 명령을 출력한 경우 Cisco CLI Analyzer(등록된 고객만)를 사용하여 잠재적인 문제 및 수정 사항을 표시할 수 있습니다.
가능한 원인
이 표에서는 소프트웨어 강제 충돌의 가능한 이유를 설명합니다.
이유 |
설명 |
Watchdog 시간 초과 |
프로세서는 타이머를 사용하여 무한 루프를 방지하며 라우터의 응답을 중지합니다. 정상 작동 시 CPU는 정기적으로 타이머를 재설정합니다. 이렇게 하지 않으면 시스템이 다시 로드됩니다. 소프트웨어 강제 충돌로 보고되는 Watchdog 시간 초과는 소프트웨어와 관련이 있습니다. 다른 유형의 Watchdog 시간 제한에 대한 자세한 내용은 Troubleshooting Watchdog Timeouts(Watchdog 시간 제한 문제 해결)를 참조하십시오. 다시 로드하기 전에 시스템이 루프에 멈췄습니다. 따라서 스택 추적이 반드시 관련이 있는 것은 아닙니다. 콘솔 로그의 다음 행에서 이러한 유형의 소프트웨어 강제 충돌을 인식할 수 있습니다. %SYS-2-WATCHDOG: Process aborted on watchdog timeout, process = Exec
and
*** System received a Software forced crash ***
signal = 0x17, code = 0x24, context= 0x60ceca60
|
메모리 부족 |
라우터의 메모리가 너무 부족하면 결국 라우터가 다시 로드되어 소프트웨어 강제 충돌로 보고될 수 있습니다. 이 경우 메모리 할당 실패 오류 메시지가 콘솔 로그에 나타납니다. %SYS-2-MALLOCFAIL: Memory allocation of 734 bytes failed from 0x6015EC84,
pool Processor, alignment 0 |
손상된 소프트웨어 이미지 |
부팅할 때 라우터는 Cisco IOS 소프트웨어 이미지가 손상되었음을 감지하고 압축된 이미지 체크섬이 잘못된 메시지임을 반환하고 다시 로드를 시도할 수 있습니다. 이 경우 이벤트는 소프트웨어 강제 충돌로 보고됩니다. Error : compressed image checksum is incorrect 0x54B2C70A
Expected a checksum of 0x04B2C70A
*** System received a Software forced crash ***
signal= 0x17, code= 0x5, context= 0x0
PC = 0x800080d4, Cause = 0x20, Status Reg = 0x3041f003
이는 라우터로 전송하는 동안 실제로 손상된 Cisco IOS 소프트웨어 이미지에 의해 발생할 수 있습니다. 이 경우 라우터에 새 이미지를 로드하여 문제를 해결할 수 있습니다. [사용 중인 플랫폼의 ROMMON 복구 방법은 Cisco 7200, 7300, 7400, 7500, RSP7000, Catalyst 5500 RSM, uBR7100, uBR7200, uBR10000 및 12000 Series Router의 ROMmon 복구 절차를 참조하십시오.] 메모리 하드웨어에 결함이 있거나 소프트웨어 버그에 의해 발생할 수도 있습니다. |
기타 결함 |
충돌을 일으키는 오류는 ROM 모니터의 특수 오류 처리 코드를 자동으로 호출하는 프로세서 하드웨어에서 종종 탐지됩니다. ROM 모니터는 오류를 식별하고 메시지를 인쇄하며 오류 정보를 저장하고 시스템을 다시 시작합니다. 이 중 어느 것도 발생할 수 없는 충돌(Watchdog 시간 초과 참조)이 있으며, 소프트웨어가 문제를 감지하고 crashdump 기능을 호출하는 충돌이 있습니다. 이는 진정한 "소프트웨어 강제" 충돌입니다. Power PC 플랫폼에서 "소프트웨어 강제 크래시"는 크래시덤프 기능이 호출될 때 인쇄되는 재시작 이유가 아닙니다. 최소한 최근까지는 마찬가지입니다. 이러한 플랫폼(Cisco IOS Software Release 12.2(12.7) 이전)에서는 이러한 예외를 "SIGTRAP"이라고 합니다. 다른 모든 방식에서는 SIGTRAP과 SFC가 동일합니다. |
문제 해결
소프트웨어 강제 충돌은 일반적으로 Cisco IOS 소프트웨어 버그로 인해 발생합니다. 로그에 메모리 할당 실패 오류 메시지가 있는 경우 메모리 문제 해결을 참조하십시오.
메모리 할당 오류 메시지가 표시되지 않고 소프트웨어 강제 충돌 후 라우터를 수동으로 다시 로드하거나 전원을 껐다가 켜지 않은 경우, 가장 좋은 툴은 Cisco CLI Analyzer(등록된 고객만 해당)를 사용하여 알려진 일치 버그 ID를 검색하는 것입니다. 이 툴에는 이전 Stack Decoder 툴의 기능이 통합되어 있습니다.
예:
-
라우터에서 show stack의 출력을 수집합니다.
-
Cisco CLI Analyzer(등록된 고객만) 툴로 이동합니다.
-
풀다운 메뉴에서 Show stack을 선택합니다.
-
수집한 출력에 붙여넣습니다.
-
Submit(제출)을 클릭합니다.
show stack 명령의 디코딩된 출력이 알려진 소프트웨어 버그와 일치하면 소프트웨어 강제 충돌을 일으킬 수 있는 가장 가능성 있는 소프트웨어 버그의 버그 ID를 받게 됩니다.
-
버그 ID 하이퍼링크를 클릭하면 Cisco Bug Toolkit(등록된 고객만 해당)에서 추가 버그 세부사항을 확인할 수 있습니다. 이를 통해 올바른 버그 ID 일치를 확인할 수 있습니다.
오류와 일치하는 버그 ID를 식별한 경우 "fixed in" 필드를 참조하여 버그에 대한 수정 사항이 포함된 첫 번째 Cisco IOS 소프트웨어 버전을 확인합니다.
버그 ID 또는 문제 해결 방법이 포함된 Cisco IOS 소프트웨어 버전에 대해 잘 모르는 경우 Cisco IOS 소프트웨어를 릴리스 트레인의 최신 버전으로 업그레이드하십시오. 최신 버전에는 많은 수의 버그에 대한 수정 사항이 포함되어 있으므로 이 기능이 도움이 됩니다. 이 방법으로 문제를 해결하지 못하더라도 최신 버전의 소프트웨어를 사용할 경우 버그 보고 및 해결 프로세스가 더 간단하고 빠릅니다.
Cisco CLI Analyzer를 사용한 후, 해결되지 않은 버그가 의심스럽거나 확실하게 식별된 경우, TAC 서비스 요청을 열어 추가 정보를 제공하여 버그를 해결하고 버그가 최종적으로 해결되었을 때 더 빨리 알릴 것을 권장합니다.
컨피그레이션 절차
문제가 새 소프트웨어 버그로 확인되면 Cisco TAC 엔지니어가 코어 덤프를 수집하도록 라우터를 구성하도록 요청할 수 있습니다. 소프트웨어 버그를 수정하기 위해 수행할 수 있는 작업을 식별하려면 때때로 코어 덤프가 필요합니다.
코어 덤프에서 더 유용한 정보를 수집하려면 hidden debug sanity 명령을 사용하는 것이 좋습니다. 이렇게 하면 시스템에서 사용되는 모든 버퍼가 할당되고 해제될 때 온전성을 검사합니다. debug sanity 명령은 특권 EXEC 모드(활성화 모드)에서 실행해야 하며 일부 CPU와 관련되어 있지만 라우터의 기능에는 큰 영향을 미치지 않습니다. 온전성 검사를 비활성화하려면 undebug sanity 특권 EXEC 명령을 사용합니다.
기본 메모리가 16MB 이하인 라우터의 경우 TFTP(Trivial File Transfer Protocol)를 사용하여 코어 덤프를 수집할 수 있습니다. 라우터에 16MB 이상의 주 메모리가 있는 경우 FTP(File Transfer Protocol)를 사용하는 것이 좋습니다. 이 섹션의 컨피그레이션 절차를 사용합니다. 또는 코어 덤프 생성을 참조하십시오.
라우터를 구성하려면 다음 단계를 완료하십시오.
-
configure terminal 명령으로 라우터를 구성합니다.
-
예외 덤프 n.n.n.n을 입력합니다. 여기서 n.n.n.n은 원격 TFTP(Trivial File Transfer Protocol) 서버 호스트의 IP 주소입니다.
-
컨피그레이션 모드를 종료합니다.
TFTP 서버 호스트 컨피그레이션 절차
TFTP 서버 호스트를 구성하려면 다음 단계를 완료하십시오.
-
선택한 편집기의 도움을 받아 원격 호스트의 /tftpboot 디렉토리 아래에 파일을 만듭니다. 파일 이름은 Cisco 라우터 호스트 이름-코어입니다.
-
UNIX 시스템에서 "hostname-core" 파일의 권한 모드를 전역적으로 호환되도록 변경합니다(666). 해당 파일의 copy running-config tftp 명령을 통해 TFTP 설정을 확인할 수 있습니다.
-
/tftpboot 아래에 16MB가 넘는 사용 가능한 디스크 공간이 있는지 확인하십시오.
시스템이 crash하면 exception dump 명령은 위의 파일에 출력을 만듭니다. 라우터에 16MB가 넘는 기본 메모리가 있는 경우 FTP(File Transfer Protocol) 또는 RCP(Remote Copy Protocol)를 사용하여 코어 덤프를 가져옵니다. 라우터에서 다음을 구성합니다.
exception protocol ftp
exception dump n.n.n.n
ip ftp username
ip ftp password
ip ftp source-interface
exception core-file
코어 덤프를 수집하면 ftp://ftp-sj.cisco.com/incoming에 업로드하고(UNIX에서는 pftp ftp-sj.cisco.com을 입력한 다음 cd incoming) 케이스 소유자에게 알리고 파일 이름을 포함시킵니다.
TAC 서비스 요청을 열 경우 수집할 정보
위의 트러블슈팅 단계를 수행한 후에도 여전히 도움이 필요하며 Cisco TAC에 서비스 요청을 생성하려는 경우 다음 정보를 포함해야 합니다. |
- show technical-support output - show technical-support 명령의 출력은 라우터의 현재 상태에 대한 정보와 충돌 전에 라우터가 저장한 주요 정보를 제공합니다.
- 콘솔 로그 - syslog 서버에 저장되는 경우가 많은 콘솔 로그는 충돌 전에 라우터에서 발생하는 이벤트에 대한 중요한 정보를 제공할 수 있습니다. 이러한 단서는 종종 당신이 수집할 수 있는 가장 중요한 정보이다.
- crashinfo 파일(있는 경우) - Cisco에서는 성공적으로 문제를 해결하려면 crashinfo 기능을 지원하는 Cisco IOS 소프트웨어 릴리스를 사용하는 것이 좋습니다. 이를 위해 버전은 네트워크의 다른 요구 사항을 충족해야 합니다. Crashinfo 파일에서 정보 검색을 참조하거나 Software Advisor(등록된 고객만 해당) 툴을 사용하여 crashinfo 기능을 지원하는 Cisco IOS 소프트웨어 버전을 찾으십시오. 잠재적 보너스는 이전 버전의 Cisco IOS 소프트웨어가 있는 경우 이 기능을 지원하는 최신 IOS 소프트웨어 릴리스에서 이미 버그가 수정되었을 수 있다는 것입니다.
서비스 요청에 정보를 첨부하려면 TAC Service Request Tool을 통해 업로드하십시오(등록된 고객만 해당). TAC Service Request Tool에 액세스할 수 없는 경우, 이메일 첨부 파일의 정보를 메시지의 제목 줄에 케이스 번호가 포함된 attach@cisco.com으로 보낼 수 있습니다. 주의: 위 정보를 수집하기 전에 라우터를 수동으로 다시 로드하거나 전원을 껐다가 켜지 마십시오. 이 경우 문제의 근본 원인을 파악하는 데 필요한 중요한 정보가 손실될 수 있습니다. |
관련 정보