이 문서에서는 서로 다른 프로세스로 인해 발생하는 높은 CPU 사용률을 트러블슈팅하는 방법에 대해 설명합니다.
이 문서를 진행하기 전에 Troubleshooting High CPU Utilization on Cisco Routers(Cisco 라우터의 높은 CPU 사용률 문제 해결)를 읽어보는 것이 좋습니다.
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 라이브 네트워크에서 작업 중인 경우, 사용하기 전에 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
ARP(Address Resolution Protocol) 입력 프로세스의 높은 CPU 사용률은 라우터가 과도한 수의 ARP 요청을 생성해야 하는 경우 발생합니다. 라우터는 로컬 서브넷에 있는 호스트뿐만 아니라 모든 호스트에 대해 ARP를 사용하며, ARP 요청이 브로드캐스트로 전송되어 네트워크의 모든 호스트에서 CPU 사용률이 증가합니다. 동일한 IP 주소에 대한 ARP 요청은 2초마다 1개의 요청으로 속도 제한되므로, 서로 다른 IP 주소에 대해 과도한 수의 ARP 요청을 생성해야 합니다. 이는 IP 경로가 브로드캐스트 인터페이스를 가리키도록 구성된 경우 발생할 수 있습니다. 가장 명백한 예는 다음과 같은 기본 경로입니다.
ip route 0.0.0.0 0.0.0.0 Fastethernet0/0
이 경우 라우터는 특정 경로를 통해 연결할 수 없는 각 IP 주소에 대해 ARP 요청을 생성합니다. 이는 사실상 라우터가 인터넷의 거의 모든 주소에 대해 ARP 요청을 생성함을 의미합니다. 고정 라우팅을 위한 next hop 주소 구성에 대한 자세한 내용은 고정 경로를 위한 Next Hop IP 주소 지정을 참조하십시오.
또는 로컬로 연결된 서브넷을 통해 스캔하는 악성 트래픽 스트림에 의해 과도한 ARP 요청이 발생할 수 있습니다. 이러한 스트림을 나타내는 것은 ARP 테이블에 불완전한 ARP 항목이 매우 많다는 것입니다. ARP 요청을 트리거하는 수신 IP 패킷을 처리해야 하므로, 이 문제를 해결하는 것은 기본적으로 IP 입력 프로세스에서 높은 CPU 사용률을 해결하는 것과 동일합니다.
IPX 입력 프로세스는 IPX 패킷을 스위칭한다는 점을 제외하면 프로세스 스위칭을 담당한다는 점에서 IP 입력 프로세스와 유사합니다. 거의 모든 IPX 패킷은 IPX SAP In, IPX RIP In 등과 같은 다른 IPX 프로세스로 대기되기 전에 IPX Input에서 검토하는 프로세스 레벨에 있습니다. IP와 달리 IPX는 인터럽트 스위칭 모드를 하나만 지원하며, 이는 기본적으로 활성화된 IPX 고속 스위칭입니다. IPX 빠른 전환은 ipx route-cache interface 명령을 사용하여 활성화됩니다.
IPX 입력 프로세스 중에 높은 CPU 사용률이 표시되면 다음을 확인합니다.
IPX 빠른 전환이 비활성화되어 있습니다. IPX 빠른 전환이 비활성화된 경우 show ipx interface 명령을 사용합니다.
일부 IPX 트래픽은 IPX 고속 스위칭이 될 수 없습니다.
IPX broadcast - show ipx traffic 명령을 사용하여 라우터에 IPX 브로드캐스트가 과도하게 공급되는지 확인합니다.
IPX 라우팅 업데이트 - 네트워크에 많은 불안정성이 있을 경우 라우팅 업데이트 처리가 증가합니다.
참고: IPX RIP 대신 IPX EIGRP(증분)를 사용하여 특히 저속 직렬 링크를 통한 업데이트 양을 줄입니다(자세한 내용은 Novell IPX Over Slow Serial Lines 및 SAP Management 라우팅 참조).
주: Novell IPX 기술 지원 페이지에서 추가 IPX 관련 문서를 찾을 수 있습니다.
TCP(Transmission Control Protocol) 타이머 프로세스에서 CPU 리소스를 많이 사용하는 경우 TCP 연결 엔드포인트가 너무 많다는 것을 나타냅니다. 이는 피어가 많은 DLSw(data-link switching) 환경 또는 라우터에서 여러 TCP 세션이 동시에 열리는 다른 환경에서 발생할 수 있습니다.
FIB 제어 타이머는 VLAN별 통계 및 글로벌 통계에 대한 FIB 통계 수집 타이머를 초기화 및 시작하고, FIB/ADJ 요청/예외 타이머를 초기화 및 시작하고, FIB 관련 레지스트리 기능을 유지하고, BGP 어카운팅 타이머를 초기화합니다. 이러한 프로세스는 EARL이 초기화되면 시작됩니다.
TTY 백그라운드 프로세스는 모든 터미널 라인(console, aux, async 등)에서 사용되는 일반 프로세스입니다. 일반적으로 이 프로세스는 Cisco IOS 소프트웨어에서 예약해야 하는 다른 프로세스에 비해 우선순위가 낮기 때문에 라우터의 성능에 영향을 주지 않아야 합니다.
이 프로세스에서 CPU 사용률이 높은 경우 "line con 0" 아래에서 "logging synchronous"가 구성되어 있는지 확인합니다. 가능한 원인은 Cisco 버그 ID CSCed16920(등록된 고객만) Cisco 버그 ID 또는 CSCdy01705(등록된 고객만)입니다.
"TAG Stats Background(TAG 통계 백그라운드)" 프로세스에 대해 표시되는 CPU 사용률이 예상되며, 트래픽 포워딩에는 영향을 미치지 않습니다.
TAG Stats Background는 우선 순위가 낮은 프로세스입니다. 이 프로세스는 태그에 대한 통계를 수집하고 RP에 전달합니다. 트래픽 양의 함수가 아니라 MPLS/LDP 제어 평면이 수행하는 작업 양의 함수입니다. 이는 예상된 동작이며 트래픽 포워딩에는 영향을 미치지 않습니다. 이 문제는 버그 CSCdz32988(등록된 고객만 해당)에 설명되어 있습니다.
새 사용자가 라우터 또는 액세스 서버에 연결될 때마다 새 가상 액세스 인터페이스마다 가상 템플릿(vtemplate)을 복제해야 합니다. 사용자 수가 많은 경우 Vtemplate 백업 프로세스의 CPU 사용률이 매우 높아질 수 있습니다. 가상 템플릿의 사전 복제를 구성하면 이러한 문제를 방지할 수 있습니다. 자세한 내용은 세션 확장성 개선 사항을 참조하십시오.
Net Background 프로세스는 버퍼가 필요할 때마다 실행되지만 프로세스 또는 인터페이스에서 사용할 수 없습니다. 요청을 기반으로 기본 풀에서 원하는 버퍼를 생성합니다. 또한 Net background는 각 프로세스에서 사용하는 메모리를 관리하고 여유 메모리를 정리합니다. 이 프로세스는 주로 인터페이스와 연관되어 있으며 상당한 CPU 리소스를 소비할 수 있습니다. 높은 CPU의 증상은 인터페이스에서 스로틀이 증가하고 무시되고 오버런되며 재설정됩니다.
IP 백그라운드 프로세스에는 ICMP 리디렉션 캐시의 매분 주기적인 에이징, 인터페이스의 캡슐화 유형 변경, 인터페이스의 새 상태(UP 및/또는 DOWN)로의 이동, 인터페이스의 IP 주소 변경, 새 dxi 맵 만료, 다이얼러 타이머 만료 등의 절차가 포함됩니다.
IP 백그라운드 프로세스는 인터페이스의 상태에 따라 라우팅 테이블을 수정하는 반면, IP 백그라운드 프로세스는 링크 상태 변경 메시지를 수신할 때 링크 상태 변경이 있는 것으로 가정합니다. 그런 다음 모든 라우팅 프로토콜에 이를 알림으로써 영향을 받는 인터페이스를 확인합니다. 더 많은 인터페이스에서 라우팅 프로토콜을 실행하는 경우 IP 백그라운드 프로세스로 인해 CPU 사용률이 더 높아집니다.
ARP 백그라운드 프로세스는 여러 작업을 처리하며 높은 CPU 사용률을 소비할 수 있습니다.
이 목록에서는 몇 가지 예제 작업을 제공합니다.
인터페이스 up/down 이벤트로 인한 ARP 플러시
clear arp 명령을 통해 ARP 테이블 지우기
ARP 입력 패킷
ARP 저장
다른 프로세스에서 많은 CPU 리소스를 사용하고 있고 로깅된 메시지에 문제가 있음을 나타내지 않는 경우 Cisco IOS® 소프트웨어의 버그로 인해 문제가 발생할 수 있습니다. 버그 툴킷(등록된 고객만 해당)을 사용하여 지정된 프로세스에 대한 검색을 실행하여 버그가 보고되었는지 확인합니다.
위의 트러블슈팅 단계를 수행한 후에도 여전히 도움이 필요하며 Cisco TAC에 서비스 요청을 만들려면 다음 정보를 포함해야 합니다. |
---|
개정 | 게시 날짜 | 의견 |
---|---|---|
1.0 |
29-Sep-2008 |
최초 릴리스 |