이 문서는 응답하지 않는 시스템의 문제를 해결하는 데 도움이 됩니다. 또한 이 문서에서는 그 원인과 문제를 해결할 수 있는 방법에 대해 설명합니다.
시스템이 콘솔에 응답하지 않거나 네트워크에서 보낸 쿼리(예: 텔넷, SNMP(Simple Network Management Protocol) 등)에 응답하지 않으면 라우터가 작동을 중지하는 것처럼 보입니다. 이러한 문제는 크게 두 가지로 분류할 수 있습니다.
콘솔이 응답하지 않는 경우.
트래픽이 통과하지 않는 경우.
이 문서에 대한 특정 요건이 없습니다.
이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
모든 Cisco IOS® 소프트웨어 버전
모든 Cisco 라우터
이 문서는 Cisco Catalyst 스위치 또는 MGX 플랫폼에 적용되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
콘솔 문제는 라우터가 콘솔 포트의 입력에 응답하지 않을 때 발생합니다. 콘솔이 응답하지 않으면 우선 순위가 높은 프로세스로 인해 콘솔 드라이버가 입력에 응답하지 못합니다.
케이블 연결을 확인합니다.
전원 공급 장치가 켜져 있는지 확인합니다.
라우터 LED 상태를 확인합니다. 모든 LED가 꺼진 경우 라우터의 전원 공급 장치에 문제가 있을 가능성이 높습니다.
트래픽이 여전히 라우터를 통과하는 경우:
네트워크 인터페이스의 연결을 끊고 라우터가 응답하는지 확인합니다. 라우터가 EXEC 세션을 서비스하는 데 너무 중요한 역할을 한다고 생각하는 경우가 많습니다.
다음 명령을 실행한 후 문제를 재현할 수도 있습니다.
Cisco 7200 및 7500 Series의 경우:
configure terminal scheduler allocate 3000 1000 ^Z
scheduler allocate 명령은 우선순위가 낮은 프로세스에 대한 CPU 시간을 보장합니다. 네트워크 인터럽트 컨텍스트당 고속 스위칭(3000마이크로초 - usec) 및 프로세스 스위칭(1000usec)에 할당된 최대 시간을 사용합니다.
다른 모든 플랫폼에서 다음을 사용합니다.
configure terminal scheduler interval 500 ^Z
scheduler interval 명령을 사용하면 우선 순위가 낮은 프로세스를 500usec마다 예약할 수 있으므로 CPU 사용량이 100%인 경우에도 일부 명령을 입력할 수 있습니다.
이러한 명령에 대한 자세한 내용은 Cisco IOS Software 명령 참조에서 기본 시스템 관리 명령을 확인하십시오.
라우터 CPU 사용률이 높아서 콘솔이 응답하지 않을 경우 CPU 사용률이 높은 원인을 찾아 수정해야 합니다. 예를 들어 프로세스 전환 IP 트래픽으로 인해 문제가 발생하는 경우 이는 show processes cpu 명령의 출력에 있는 "IP Input" 프로세스에 반영됩니다. 이 경우 문제를 더 진단하기 위해 show interfaces, show interfaces stat 및 가능한 show process의 출력을 수집해야 합니다. 문제를 해결하려면 프로세스 전환되는 IP 트래픽의 양을 줄여야 합니다. 자세한 내용은 Cisco 라우터의 높은 CPU 사용률 문제 해결을 참조하십시오.
메모리 할당 실패의 또 다른 가능한 원인은 라우터가 사용 가능한 메모리를 모두 사용했거나, 메모리가 작은 조각으로 분할되어 라우터가 사용 가능한 블록을 찾을 수 없는 경우입니다. 자세한 내용은 메모리 문제 해결을 참조하십시오.
라우터는 웜 또는 바이러스와 같은 보안 관련 문제로 인해 응답을 중지할 수 있습니다. 라우터 IOS 업그레이드와 같이 네트워크에 최근에 변경된 사항이 없는 경우 특히 이 문제가 원인일 가능성이 높습니다. 일반적으로 액세스 목록에 행을 추가하는 등 컨피그레이션을 변경하면 이 문제의 영향을 줄일 수 있습니다. Cisco Security Advisories and Notices(Cisco 보안 권고 및 공지) 페이지에는 가장 가능성 있는 원인 탐지 및 구체적인 해결 방법에 대한 정보가 포함되어 있습니다.
자세한 내용은 다음을 참조하십시오.
부팅 프로세스 중에 라우터가 정지된 것으로 보이는 경우, 잘못 구성된 기능 또는 구성된 기능의 소프트웨어 결함 때문일 수 있습니다. 이는 라우터가 정지되기 직전에 콘솔에 경고 또는 오류 메시지가 나타나는 것을 보면 알 수 있습니다.
이 문제를 해결하려면 라우터를 ROMMON으로 부팅하고 저장된 컨피그레이션을 우회한 다음 다시 구성합니다. 다음 단계를 완료하십시오.
터미널 또는 터미널 에뮬레이션이 있는 PC를 라우터의 콘솔 포트에 연결합니다.
다음 터미널 설정을 사용합니다.
전송 속도 9600
패리티 없음
8 데이터 비트
1 스톱 비트
흐름 제어 없음
전원을 켠 60초 이내에 터미널 키보드에서 Break를 눌러 라우터를 재부팅하고 ROMMON으로 전환합니다. 브레이크 시퀀스가 작동하지 않으면 다른 키 조합에 대한 암호 복구 중 표준 브레이크 키 시퀀스 조합을 참조하십시오.
컨피그레이션 레지스터를 0x2142로 변경한 다음 라우터를 재설정합니다. 이를 위해 rommon 1> 프롬프트에서 confreg 0x2142 명령을 실행합니다. 그런 다음 rommon 2> 프롬프트에 reset을 입력합니다. 이렇게 하면 컨피그레이션을 로드하지 않고 라우터가 플래시에서 부팅됩니다.
각 설정 질문 뒤에 no를 입력하거나 Ctrl-C를 눌러 초기 설정 절차를 건너뜁니다.
enable을 Router> 프롬프트에 입력합니다.
활성화 모드에 있으며 Router# 프롬프트를 확인합니다.
이제 빈 컨피그레이션을 저장할 수 있습니다(모든 명령이 제거됨). copy running-config startup-config 명령을 실행합니다. 또는 특정 명령으로 인해 문제가 발생한다고 의심되는 경우 컨피그레이션을 수정할 수 있습니다. 이렇게 하려면 copy startup-config running-config 명령을 실행합니다. 그런 다음 configure terminal을 입력하고 변경합니다.
완료되면 컨피그레이션 레지스터를 다시 0x2102로 변경합니다. 이를 위해 config-register 0x2102를 입력합니다. copy running-config startup-config 명령을 실행하여 변경 사항을 커밋합니다.
트래픽이 라우터를 통해 흐르지 않는 경우
트래픽이 더 이상 라우터를 통과하지 못하고 콘솔이 응답하지 않는 경우 시스템에 문제가 있을 수 있습니다. 일반적으로 이는 라우터가 연속 루프에 걸리거나 기능에 고착되었음을 의미합니다. 이는 거의 항상 소프트웨어의 버그로 인해 발생합니다. 현재 실행 중인 Cisco IOS 소프트웨어 트레인의 최신 유지 관리 릴리스를 설치합니다.
Cisco TAC에서 서비스 요청을 생성하기 전에 ROM Monitor에서 스택 추적을 가져옵니다. 문제가 발생한 동안 스택 추적을 가져오면 코드에서 라우터가 루핑되거나 고착된 위치를 확인할 수 있습니다.
트래픽 문제는 콘솔이 응답 상태를 유지하지만 트래픽이 라우터를 통과하지 못할 때 발생합니다. 이 경우 트래픽의 일부 또는 인터페이스의 일부가 응답하지 않습니다. 이러한 행동은 다양한 다른 원인에 의해 발생할 수 있다. 이 문제가 발생하면 콘솔 포트를 통해 라우터에서 정보를 수집할 수 있습니다. 이러한 트래픽 문제의 원인은 인터페이스의 오류부터 소프트웨어 및 하드웨어 문제까지 다양합니다.
라우팅 문제 - 네트워크 토폴로지 또는 일부 라우터의 컨피그레이션을 변경하면 라우팅 테이블에 영향을 미칠 수 있습니다.
High CPU Utilization(높은 CPU 사용률) - show process cpu 명령을 실행합니다. CPU가 95% 이상인 경우 라우터의 성능에 영향을 줄 수 있으며 패킷이 지연되거나 삭제될 수 있습니다. 자세한 내용은 라우터에서 높은 CPU 사용률 문제 해결을 참조하십시오.
인터페이스 다운 - 라우터 인터페이스 중 하나가 다운될 수 있습니다. 이를 야기할 수 있는 이벤트는 여러 가지가 있으며, 잘못된 컨피그레이션 명령부터 인터페이스 또는 케이블의 하드웨어 장애까지 다양할 수 있습니다. show interfaces 명령을 실행할 때 일부 인터페이스가 다운된 경우 원인을 파악해 보십시오.
쐐기형 인터페이스 - 이는 버퍼 누수의 특정 경우로, 인터페이스의 입력 대기열이 패킷을 더 이상 수락할 수 없는 지점까지 채워집니다. 라우터를 다시 로드합니다. 이렇게 하면 해당 입력 대기열이 해제되고 대기열이 다시 가득 찰 때까지 트래픽이 복원됩니다. 이는 유출의 심각도에 따라 몇 초에서 몇 주 정도 걸릴 수 있습니다.
쐐기형 인터페이스를 식별하는 가장 쉬운 방법은 show interfaces 명령을 실행하고 다음과 유사한 방법을 찾는 것입니다.
Output queue 0/40, 0 drops; input queue 76/75, 27 drops
K-trace는 ROM 모니터에서 라우터에서 스택 추적을 가져오는 데 사용되는 절차를 나타냅니다. 이전 ROM 모니터 코드가 있는 라우터에서는 k 명령을 사용하여 스택 추적을 가져옵니다. 최신 ROM Monitor 코드를 실행하는 라우터에서는 stack 명령도 사용할 수 있습니다.
응답하지 않는 라우터에서 스택 추적을 가져오려면 다음 단계를 완료합니다.
브레이크 시퀀스를 활성화합니다. 이를 위해 컨피그레이션 레지스터 값을 변경합니다. 8번째 비트 값은 break가 무시되지 않도록 0으로 설정되어야 합니다. 0x2002 값이 작동합니다.
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#config-register 0x2002
새 컨피그레이션 레지스터 값이 사용되도록 라우터를 다시 로드합니다.
문제가 발생하면 중단 시퀀스를 보냅니다. ROM 모니터 프롬프트 ">" 또는 "rommon 1 >"를 표시해야 합니다.
스택 추적 캡처 이를 위해 k 50 또는 stack 50 명령 중 하나에서 출력을 수집합니다. 명령에 50을 추가하여 더 긴 스택 추적을 인쇄합니다.
계속하려면 c 또는 cont 명령을 실행합니다.
마지막 세 단계를 여러 번 반복하여 연속 루프의 여러 점이 캡처되었는지 확인합니다.
여러 스택 추적을 얻은 후 라우터를 재부팅하여 정지 상태에서 복구합니다.
다음은 이 절차의 예입니다.
User break detected at location 0x80af570 rommon 1 > k 50 Stack trace: PC = 0x080af570 Frame 00: FP = 0x02004750 RA = 0x0813d1b4 Frame 01: FP = 0x02004810 RA = 0x0813a8b8 Frame 02: FP = 0x0200482c RA = 0x08032000 Frame 03: FP = 0x0200483c RA = 0x040005b0 Frame 04: FP = 0x02004b34 RA = 0x0401517a Frame 05: FP = 0x02004bf0 RA = 0x04014d9c Frame 06: FP = 0x02004c00 RA = 0x040023d0 Frame 07: FP = 0x02004c68 RA = 0x04002e9e Frame 08: FP = 0x02004c78 RA = 0x040154fe Frame 09: FP = 0x02004e68 RA = 0x04001fc0 Frame 10: FP = 0x02004f90 RA = 0x0400c41e Frame 11: FP = 0x02004fa4 RA = 0x04000458 Suspect bogus FP = 0x00000000, aborting rommon 2 > cont
시스템 문제가 발생할 경우 이 절차를 여러 번 반복하여 스택 추적의 여러 인스턴스를 수집합니다.
라우터가 응답하지 않으면 거의 항상 소프트웨어 문제가 발생합니다. 이 경우 TAC 서비스 요청을 열기 전에 스택 추적을 포함하여 가능한 많은 정보를 수집해야 합니다. show version, show run 및 show interfaces 명령의 출력도 포함해야 합니다.
TAC 서비스 요청을 열 경우 라우터 중단 문제 해결 요청에 다음 정보를 첨부하십시오. |
참고: 콘솔이 응답하면 문제의 근본 원인을 파악하는 데 필요한 중요한 정보가 손실될 수 있으므로 위 정보를 수집하기 전에 라우터를 수동으로 다시 로드하거나 전원을 껐다가 다시 켜지 마십시오. 단, 트러블슈팅에 필요한 경우는 예외입니다. |
개정 | 게시 날짜 | 의견 |
---|---|---|
1.0 |
02-Aug-2006 |
최초 릴리스 |