이 문서에서는 다양한 프로세스에 의해 발생하는 높은 CPU 사용률을 해결하는 방법에 대해 설명합니다.
이 문서를 진행하기 전에 Troubleshooting High CPU Utilization on Cisco Routers를 읽는 것이 좋습니다.
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 라이브 네트워크에서 작업하는 경우, 사용하기 전에 모든 명령의 잠재적인 영향을 이해해야 합니다.
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
라우터가 과도한 수의 ARP 요청을 발생해야 하는 경우 ARP(Address Resolution Protocol) 입력 프로세스에서 높은 CPU 사용률이 발생합니다. 라우터는 로컬 서브넷의 호스트뿐만 아니라 모든 호스트에 대해 ARP를 사용하며, ARP 요청은 브로드캐스트로 전송되므로 네트워크의 모든 호스트에서 CPU 사용률이 증가합니다. 동일한 IP 주소에 대한 ARP 요청은 2초마다 하나의 요청으로 제한되므로, ARP 요청 수가 너무 많으면 여러 IP 주소에 대해 시작해야 합니다. 이는 브로드캐스트 인터페이스를 가리키는 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 입력 프로세스가 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 브로드캐스트 - 라우터가 show ipx traffic 명령을 사용하여 IPX 브로드캐스트로 인해 압도되었는지 확인합니다.
IPX 라우팅 업데이트 - 네트워크에 많은 기능이 있는 경우 라우팅 업데이트 처리가 증가합니다.
참고: IPX RIP 대신 IPX EIGRP(증분)를 사용하여 특히 속도가 느린 직렬 링크에서 업데이트 양을 줄입니다(자세한 내용은 Routing 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 백그라운드 프로세스는 모든 터미널 라인(콘솔, 보조, 비동기 등)에서 사용되는 일반 프로세스입니다. 일반적으로 이 프로세스는 Cisco IOS 소프트웨어에서 예약해야 하는 다른 프로세스에 비해 우선 순위가 낮으므로 라우터의 성능에 영향을 미치지 않아야 합니다.
이 프로세스에서 CPU 사용률이 높은 경우 "line con 0"에서 "logging synchronous"가 구성되었는지 확인합니다. 가능한 원인은 Cisco 버그 ID CSCed16920(등록된 고객만 해당) Cisco 버그 ID 또는 CSCdy01705(등록된 고객만 해당)입니다.
"TAG Stats Background" 프로세스에 표시되는 CPU 사용률이 예상되며 트래픽 전달에 영향을 주지 않습니다.
TAG Stats Background는 낮은 우선 순위 프로세스입니다. 이 프로세스에서는 태그에 대한 통계를 수집하여 RP에 전달합니다. 이는 트래픽 양이 아니라 MPLS/LDP 컨트롤 플레인이 수행하는 작업의 양입니다. 이는 예상되는 동작이며 트래픽 전달에는 영향을 주지 않습니다. 이 문제는 버그 CSCdz32988에 설명되어 있습니다(등록된 고객만 해당).
새 사용자가 라우터 또는 액세스 서버에 연결될 때마다 새로운 가상 액세스 인터페이스마다 가상 템플릿(vtemplate)을 복제해야 합니다. Vtemplate Backgr 프로세스의 CPU 사용률은 사용자 수가 많을 경우 매우 높을 수 있습니다. 가상 템플릿의 사전 복제를 구성하면 이러한 문제가 발생하지 않습니다. 자세한 내용은 세션 확장성 개선 사항을 참조하십시오.
Net Background 프로세스는 버퍼가 필요할 때마다 실행되지만 프로세스 또는 인터페이스에서는 사용할 수 없습니다. 요청에 따라 기본 풀에서 원하는 버퍼를 생성합니다. 또한 네트 백그라운드에서 각 프로세스에서 사용하는 메모리를 관리하고 여유 메모리를 정리합니다. 이 프로세스는 주로 인터페이스와 관련이 있으며 상당한 CPU 리소스를 사용할 수 있습니다. 높은 CPU의 증상은 인터페이스에서 조절, 무시, 오버런 및 재설정의 증가를 나타냅니다.
IP 백그라운드 프로세스에는 다음 절차가 포함됩니다. 분당 ICMP 리디렉션 캐시의 주기적 에이징 인터페이스의 캡슐화 유형 변경 인터페이스를 새 상태, UP 및/또는 DOWN으로 이동 인터페이스의 IP 주소 변경 새 dxi 맵의 만료 다이얼러 타이머의 만료입니다.
IP Background 프로세스는 인터페이스의 상태에 따라 라우팅 테이블을 수정하는 반면, IP Background 프로세스는 링크 상태 변경 메시지를 수신할 때 링크 상태가 변경된다고 가정합니다. 그런 다음 모든 라우팅 프로토콜을 통지하여 영향을 받는 인터페이스를 확인합니다. 더 많은 인터페이스에서 라우팅 프로토콜을 실행하는 경우 IP 백그라운드 프로세스에 의해 더 높은 CPU 사용률이 발생합니다.
ARP 백그라운드 프로세스는 여러 작업을 처리하며 높은 CPU 사용률을 사용할 수 있습니다.
이 목록은 몇 가지 작업 예를 제공합니다.
인터페이스 up/down 이벤트로 인한 ARP 플러시
clear arp 명령을 통해 ARP 테이블 지우기
ARP 입력 패킷
ARP 관리자
다른 프로세스에서 많은 CPU 리소스를 사용하고 있으며 로깅된 메시지에 문제가 있다는 표시가 없는 경우 Cisco IOS® 소프트웨어의 버그로 인해 문제가 발생할 수 있습니다. 버그 툴킷(등록된 고객만 해당)을 사용하여 지정된 프로세스에 대한 검색을 실행하여 버그가 보고되었는지 확인합니다.
위의 트러블슈팅 단계를 거친 후에도 지원이 필요한 경우 Cisco TAC에서 서비스 요청을 생성하려면 다음 정보를 포함해야 합니다. |
---|
|
개정 | 게시 날짜 | 의견 |
---|---|---|
1.0 |
29-Sep-2008 |
최초 릴리스 |