IP 입력 프로세스에서 높은 CPU 사용률 문제 해결

소개

이 문서에서는 IP 입력 프로세스로 인해 높은 CPU 사용률을 해결하는 방법을 설명합니다.

참고: 이 문서에서는 서로 다른 유형의 공격을 방지하는 전략을 제공하지 않습니다.

사전 요구 사항

요구 사항

이 문서를 진행하기 전에 Cisco 라우터에서 Troubleshooting High CPU Utilization(CPU 사용률 높은 문제 해결)을 읽어 보시기 바랍니다.

사용되는 구성 요소

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

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 라이브 네트워크에서 작업하는 경우, 사용하기 전에 모든 명령의 잠재적인 영향을 이해해야 합니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

IP 입력

IP 입력이라는 Cisco IOS^® 소프트웨어 프로세스는 프로세스 스위칭 IP 패킷을 처리합니다. IP 입력 프로세스에서 비정상적으로 높은 CPU 리소스를 사용하는 경우 라우터는 많은 IP 트래픽을 프로세스 스위칭합니다. 다음 문제를 확인합니다.

• 트래픽이 많은 인터페이스(또는 인터페이스)에서 인터럽트 스위칭이 비활성화됨

  인터럽트 스위칭은 프로세스 스위칭이 아닌 스위칭 알고리즘을 사용하는 것을 의미합니다. 예를 들면 고속 스위칭, 최적 스위칭, Cisco Express Forwarding 스위칭 등이 있습니다(자세한 내용은 성능 튜닝 기본 사항 참조). show interfaces switching 명령의 출력을 검사하여 어떤 인터페이스가 트래픽으로 배분되는지 확인합니다. show ip interface 명령을 확인하여 각 인터페이스에서 사용되는 스위칭 방법을 확인할 수 있습니다. 해당 인터페이스에서 인터럽트 스위칭을 다시 활성화합니다. 일반 고속 스위칭은 출력 인터페이스에 구성됩니다. 인터페이스에서 빠른 스위칭이 구성된 경우 해당 인터페이스에서 나가는 패킷은 빠르게 스위칭됩니다. Cisco Express Forwarding 스위칭은 입력 인터페이스에 구성됩니다. 특정 인터페이스에서 FIB(Forwarding Information Base) 및 인접성 테이블 항목을 생성하려면 해당 인터페이스로 라우팅되는 모든 인터페이스에서 Cisco Express Forwarding 전환을 구성합니다.

• 동일한 인터페이스에서 빠른 스위칭이 비활성화됨

  인터페이스에 많은 보조 주소 또는 하위 인터페이스가 있고 인터페이스에서 소싱되고 동일한 인터페이스의 주소로 향하는 트래픽이 많은 경우 이러한 모든 패킷은 프로세스 스위칭됩니다. 이 경우 인터페이스에서 ip route-cache same-interface를 활성화해야 합니다. Cisco Express Forwarding 스위칭을 사용할 경우 동일한 인터페이스에서 Cisco Express Forwarding 스위칭을 별도로 활성화할 필요가 없습니다.

• 정책 라우팅을 제공하는 인터페이스에서 빠른 스위칭이 비활성화됨

  인터페이스에 route-map이 구성되어 있고 많은 트래픽이 route-map에 의해 처리되면 라우터가 이 트래픽을 전환합니다. 이 경우 인터페이스에서 ip route-cache 정책을 활성화해야 합니다. Configuring Policy-Based Routing(정책 기반 라우팅 구성)의 "Enabling Fast-Switched Policy-Based Routing(빠른 전환 정책 기반 라우팅 활성화)" 섹션에서 언급된 제한을 확인합니다.

• 인터럽트 스위칭할 수 없는 트래픽이 도착합니다.

  이는 나열된 트래픽 유형 중 하나일 수 있습니다. 자세한 내용을 보려면 연결된 항목을 클릭하십시오.

  • 스위칭 캐시에 아직 항목이 없는 패킷

    고속, 최적 또는 Cisco CEF(Express Forwarding Switching)가 구성된 경우에도 고속 스위칭 캐시 또는 FIB 및 인접성 테이블에 일치하는 패킷이 처리됩니다. 그런 다음 적절한 캐시 또는 테이블에 항목이 생성되며, 동일한 기준과 일치하는 모든 후속 패킷은 고속, 최적 또는 CEF 스위치입니다. 일반적으로 이러한 처리된 패킷은 CPU 사용률이 높지 않습니다. 그러나 네트워크에 1) 라우터를 통해 연결할 수 있는 디바이스에 대해 매우 높은 속도로 패킷을 생성하는 디바이스가 있고 2) 서로 다른 소스 또는 목적지 IP 주소를 사용하는 경우, 스위칭 캐시 또는 테이블에서 이러한 패킷에 대한 일치 항목이 없으므로 IP 입력 프로세스에 의해 처리됩니다(NetFlow 스위칭이 구성된 경우 소스 및 목적지 TCP 포트도 NetFlow 캐시의 항목을 기준으로 확인). 이 소스 디바이스는 작동하지 않는 디바이스이거나 공격을 시도하는 디바이스일 가능성이 높습니다.

    (*) 인접성이 적은 경우에만 가능합니다. Cisco Express Forwarding 인접성에 대한 자세한 내용은 Cisco Express Forwarding을 참조하십시오.

  • 라우터로 향하는 패킷

    다음은 라우터로 향하는 패킷의 예입니다.

    • 매우 높은 속도로 전달되는 라우팅 업데이트 라우터에서 처리해야 하는 라우팅 업데이트가 너무 많은 경우 이 작업은 CPU를 과부하 시킬 수 있습니다. 일반적으로 안정적인 네트워크에서는 이러한 현상이 발생하지 않습니다. 추가 정보를 수집하는 방법은 구성한 라우팅 프로토콜에 따라 달라집니다. 그러나 show ip route summary 명령의 출력을 주기적으로 확인하기 시작할 수 있습니다. 빠르게 변하는 값은 불안정한 네트워크의 징후입니다. 라우팅 테이블이 자주 변경되므로 라우팅 프로토콜 처리가 증가하여 CPU 사용률이 증가합니다. 이 문제를 해결하는 방법에 대한 자세한 내용은 Internetwork Troubleshooting Guide의 Troubleshooting TCP/IP 섹션을 참조하십시오.

    • 라우터로 향하는 다른 트래픽 유형 라우터에 로그온한 사용자와 사용자 작업을 확인합니다. 누군가 로그온하여 긴 출력을 생성하는 명령을 실행하면 "IP input" 프로세스에 의한 높은 CPU 사용률이 뒤에 Virtual Exec 프로세스에 의해 훨씬 더 높은 CPU 사용률이 나옵니다.

    • 스푸핑 공격. 문제를 식별하려면 show ip traffic 명령을 실행하여 IP 트래픽의 양을 확인합니다. 문제가 있는 경우 로컬 대상이 있는 수신된 패킷의 수가 상당합니다. 그런 다음 show interface의 출력을 검토하고 패킷이 들어오는 인터페이스를 확인하기 위해 show interfaces switching 명령을 확인합니다. 수신 인터페이스를 식별한 후 발신 인터페이스에서 ip 어카운팅을 켜고 패턴이 있는지 확인합니다. 공격이 있는 경우 소스 주소는 거의 항상 다르지만 대상 주소는 동일합니다. 일시적으로 문제를 해결하도록 액세스 목록을 구성할 수 있지만(패킷의 소스에 가장 가까운 디바이스에서 권장), 실제 솔루션은 소스 디바이스를 추적하고 공격을 중지하는 것입니다.

  • 브로드캐스트 트래픽

    show interfaces 명령 출력에서 브로드캐스트 패킷 수를 확인합니다. 브로드캐스트의 양을 인터페이스에서 수신된 총 패킷 양과 비교하는 경우 브로드캐스트의 오버헤드가 있는지 알 수 있습니다. 여러 스위치가 라우터에 연결된 LAN이 있는 경우 스패닝 트리에 문제가 있을 수 있습니다.

  • 옵션이 있는 IP 패킷

  • 프로토콜 변환이 필요한 패킷

  • Multilink Point-to-Point 프로토콜(Cisco Express Forwarding 스위칭에서 지원)

  • 압축된 트래픽

    라우터에 CSA(Compression Service Adapter)가 없는 경우 압축된 패킷은 프로세스 스위칭이어야 합니다.

  • 암호화된 트래픽

    라우터에 ESA(Encryption Service Adapter)가 없는 경우 암호화된 패킷은 프로세스 스위칭이어야 합니다.

  • X.25 캡슐화를 사용하여 직렬 인터페이스를 통과하는 패킷

    X.25 프로토콜 제품군에서 흐름 제어는 두 번째 OSI(Open System Interconnection) 레이어에 구현됩니다.

• ARP(Address Resolution Protocol) 테이블에 항목이 없는, 직접 연결된 서브넷의 대상에 대해 매우 높은 속도로 도착하는 많은 패킷. 이는 윈도우 메커니즘 때문에 TCP 트래픽에서 발생해서는 안 되지만 UDP(User Datagram Protocol) 트래픽에서 발생할 수 있습니다. 문제를 식별하려면 스푸핑 공격을 추적하기 위해 제안된 작업을 반복합니다.

• 많은 멀티캐스트 트래픽이 라우터를 통과합니다. 안타깝게도 멀티캐스트 트래픽의 양을 쉽게 검사할 수 있는 방법은 없습니다. show ip traffic 명령은 요약 정보만 표시합니다. 그러나 라우터에서 멀티캐스트 라우팅을 구성한 경우 ip mroute-cache interface configuration 명령을 사용하여 멀티캐스트 패킷의 빠른 스위칭을 활성화할 수 있습니다(멀티캐스트 패킷의 빠른 스위칭은 기본적으로 해제됨).

• 라우터가 초과 가입되었습니다. 라우터가 과도하게 사용되어 이 양의 트래픽을 처리할 수 없는 경우 다른 라우터에 로드를 분산하거나 하이엔드 라우터를 구입하십시오.

• 라우터에 IP NAT(Network Address Translation)가 구성되고 많은 DNS(Domain Name System) 패킷이 라우터를 통해 전달됩니다. 소스 또는 목적지 포트 53(DNS)이 있는 UDP 또는 TCP 패킷은 항상 NAT에 의해 프로세스 레벨로 펀딩됩니다.

• 처리로 전환되는 다른 패킷 유형이 있습니다.

• IP 데이터그램의 단편화가 있습니다. IP 데이터그램의 프래그먼트로 인해 CPU 및 메모리 오버헤드가 약간 증가했습니다. 이 문제 해결 방법에 대한 자세한 내용은 GRE 및 IPSEC의 IP 조각화, MTU, MSS 및 PMTUD 문제 해결을 참조하십시오.

IP 입력 프로세스에서 CPU 사용률이 높은 이유가 무엇이든 IP 패킷을 디버깅할 경우 문제의 원인을 추적할 수 있습니다. CPU 사용률이 이미 높으므로 디버그 프로세스는 매우 주의해야 합니다. 디버그 프로세스에서는 많은 메시지를 생성하므로 로깅 버퍼링만 구성해야 합니다.

콘솔에 로그인하면 CPU에 불필요한 인터럽트가 발생하고 CPU 사용률이 증가합니다. 호스트에 로깅(또는 모니터링 로깅)을 수행하면 인터페이스에서 추가 트래픽이 생성됩니다.

디버그 프로세스는 debug ip packet detail exec 명령으로 시작할 수 있습니다. 이 세션은 3~5초를 초과할 수 없습니다. 디버깅 메시지는 로깅 버퍼에 기록됩니다. 샘플 IP 디버깅 세션의 캡처는 이 문서의 Sample IP Packet Debugging Session 섹션에 제공됩니다. 원치 않는 IP 패킷의 소스 디바이스가 발견되면 이 디바이스가 네트워크에서 연결이 해제되거나 라우터에서 액세스 목록을 생성하여 해당 대상에서 패킷을 삭제할 수 있습니다.

샘플 IP 패킷 디버깅 세션

구성된 로깅 대상은 먼저 show logging 명령을 사용하여 확인해야 합니다.

router#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) 
    Console logging: level debugging, 52 messages logged 
    Monitor logging: level debugging, 0 messages logged 
    Buffer logging: level debugging, 148 messages logged 
    Trap logging: level informational, 64 message lines logged 
        Logging to 192.168.100.100, 3 message lines logged 
        Logging to 192.168.200.200, 3 message lines logged 
 --More--

로깅 버퍼를 제외한 모든 로깅 대상을 비활성화하고 로그 버퍼를 지웁니다.

router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
router(config)#no logging console 
router(config)#no logging monitor 
router(config)#no logging 192.168.100.100 
router(config)#no logging 192.168.200.200 
router(config)#^Z 
router#clear logging 
Clear logging buffer [confirm]
router#

디버깅 출력을 보다 쉽게 읽을 수 있도록 datetime 및 밀리초 타임스탬프를 활성화해야 합니다.

router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
router(config)#service timestamps log datetime msec 
router(config)#service timestamps debug datetime msec 
router(config)#end 
router#

이제 디버깅 세션을 시작할 수 있습니다.

router#debug ip packet detail 
IP packet debugging is on (detailed)

디버깅은 3~5초를 초과할 수 없습니다. 모든 exec 명령을 undebug로 세션을 중지할 수 있습니다.

router#undebug all 
All possible debugging has been turned off

show logging exec 명령을 사용하여 결과를 확인할 수 있습니다.

router#show logging 
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) 
    Console logging: disabled 
    Monitor logging: disabled 
    Buffer logging: level debugging, 145 messages logged 
    Trap logging: level informational, 61 message lines logged 
Log Buffer (64000 bytes): 

*Mar  3 03:43:27.320: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.204 
   (Ethernet0/0), g=10.200.40.1, len 100, forward 
*Mar  3 03:43:27.324: ICMP type=8, code=0      
*Mar  3 03:43:27.324: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.205 
   (Ethernet0/0), g=10.200.40.1, len 100, forward 
*Mar  3 03:43:27.324: ICMP type=8, code=0      
*Mar  3 03:43:27.328: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.206 
   (Ethernet0/0), g=10.200.40.1, len 100, forward 
*Mar  3 03:43:27.328: ICMP type=8, code=0      
... 

로그에는 다음이 표시됩니다.

• 패킷이 4밀리초마다 수신되었습니다.

• 소스 IP 주소는 192.168.40.53입니다.

• 패킷이 인터페이스 Ethernet0/1에서 수신되었습니다.

• 패킷에 다른 대상 IP 주소가 있습니다.

• 패킷이 인터페이스 Ethernet0/0에서 전송되었습니다.

• next-hop IP 주소는 10.200.40.1입니다.

• 패킷은 ICMP 요청(type=8)입니다.

  이 예에서는 IP 입력 프로세스의 높은 CPU 사용률이 IP 주소 192.168.40.53의 ping 플러드로 인해 발생했음을 확인할 수 있습니다.

  디버깅 출력에 SYN 플래그 표시가 표시되므로 SYN 플러드는 이 방법으로 쉽게 탐지할 수 있습니다.

  *Mar 3 03:54:40.436: IP: s=192.168.40.53 (Ethernet0/1), d=144.254.2.204 
     (Ethernet0/0), g=10.200.40.1, len 44, forward     
  *Mar 3 03:54:40.440: TCP src=11004, dst=53, 
     seq=280872555, ack=0, win=4128 SYN

관련 정보

• Cisco 라우터의 높은 CPU 사용률 문제 해결
• show processes 명령
• Catalyst 2900XL/3500XL 스위치의 높은 CPU 사용률
• 성능 튜닝 기본 사항
• 기술 지원 및 문서 − Cisco Systems

Revision History