Cisco IOS XE 16.x의 Catalyst 스위치에서 CPU 사용량 문제 해결

소개

이 문서에서는 16.x 릴리스를 실행하는 Cisco IOS® XE 플랫폼의 중단으로 인한 높은 CPU 사용량의 문제를 해결하는 방법을 설명합니다.

배경 정보

이 문서는 Raymond Whiting과 Cisco TAC 엔지니어인 Yogesh Ramdoss가 작성했습니다.

또한 이 문서에서는 높은 CPU 사용량 문제를 해결하기 위해 필수적인 이 플랫폼의 몇 가지 새 명령을 소개합니다. Cisco IOS XE의 구축 방식을 이해하는 것이 중요합니다. Cisco IOS XE를 통해 Cisco는 Linux 커널로 전환했으며 모든 하위 시스템은 프로세스로 나누어졌습니다. 모듈 드라이버, 고가용성(HA) 등 이전에 Cisco IOS 내부에 있던 모든 하위 시스템이 이제 Linux 운영 체제(OS) 내에서 소프트웨어 프로세스로 실행됩니다. Cisco IOS 자체는 Linux OS 내에서 데몬(IOSd)으로 실행됩니다. Cisco IOS XE는 기존 Cisco IOS와 동일한 모양과 느낌은 물론 운영, 지원 및 관리까지 그대로 유지합니다.

몇 가지 유익한 정의를 소개합니다.

• FED(Forwarding Engine Driver): Cisco Catalyst 스위치의 핵심으로서 모든 하드웨어 프로그래밍/포워딩을 담당합니다.
• IOSd: Linux 커널에서 실행되는 Cisco IOS 데몬입니다. 커널 내에서 소프트웨어 프로세스의 형태로 실행됩니다.
• PDS(Packet Delivery System): 다양한 서브시스템에 패킷이 전달되고 그로부터 패킷이 전달되는 아키텍처 및 프로세스입니다. 예를 들면, FED에서 IOSd로 또는 그 반대로 패킷이 전달되는 방법을 제어합니다.
• 컨트롤 플레인(CP): 컨트롤 플레인은 Catalyst 스위치의 CPU와 관련된 기능 및 트래픽을 그룹화하는 데 사용되는 일반 용어입니다. 여기에는 STP(Spanning Tree Protocol), HSRP(Hot Standby Router Protocol) 및 스위치로 전송되거나 스위치에서 전송되는 라우팅 프로토콜과 같은 트래픽이 포함됩니다. 여기에는 SSH(Secure Shell) 및 SNMP(Simple Network Management Protocol)와 같은 애플리케이션 레이어 프로토콜도 포함되며 CPU에서 처리해야 합니다.
• 데이터 플레인(DP): 일반적으로 데이터 플레인에는 하드웨어 ASIC 및 제어 플레인의 지원 없이 전달되는 트래픽이 포함됩니다.
• Punt: DP에서 가로챈 인그레스 프로토콜 제어 패킷을 처리하기 위해 CP로 보냅니다.
• 주입: IP 생성 프로토콜 패킷이 IO 인터페이스에서 이그레스 아웃하기 위해 DP로 전송됩니다.
• LSMPI: Linux 공유 메모리 Punt 인터페이스.

데이터 플레인과 컨트롤 플레인 간의 통신 경로에 대한 상위 레벨 다이어그램:

높은 CPU 문제 해결 워크플로

이 섹션에서는 스위치의 높은 CPU 문제를 분류하는 체계적인 워크플로를 제공합니다. 이 섹션을 작성할 때 선택한 프로세스를 다룹니다.

사례 연구 1. 주소 확인 프로토콜 인터럽트

이 섹션의 트러블슈팅 및 확인 프로세스는 인터럽트로 인한 높은 CPU 사용량에 광범위하게 사용될 수 있습니다.

1단계. CPU 사이클을 사용하는 프로세스 식별

이 show process cpu  명령은 IOSd 데몬 내부의 현재 프로세스 상태를 표시하는 데 사용됩니다. 출력 수정을 추가하면 | exclude 0.00 현재 유휴 상태인 프로세스를 필터링합니다.

이 출력에는 두 가지 중요한 정보가 있습니다.

• 5초 동안의 CPU 사용률: 91%/30%
  • 첫 번째 숫자(91%)는 스위치의 전체 CPU 사용률입니다
  • 두 번째 숫자(30%)는 데이터 평면의 인터럽트로 인해 발생한 사용률입니다
• Address Resolution Protocol 프로세스(ARP) Input는 현재 리소스를 소비하는 상위 Cisco IOS 프로세스입니다.

Switch# show processes cpu sort | ex 0.00
CPU utilization for five seconds: 91%/30%; one minute: 30%; five minutes: 8%
 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
  37       14645         325      45061 59.53% 18.86%  4.38%   0 ARP Input
 137        2288         115      19895  1.20%  0.14%  0.07%   0 Per-minute Jobs
 373        2626       35334         74  0.15%  0.11%  0.09%   0 MMA DB TIMER
 218        3123       69739         44  0.07%  0.09%  0.12%   0 IP ARP Retry Age
 404        2656       35333         75  0.07%  0.09%  0.09%   0 MMA DP TIMER

이 show processes cpu platform sorted 명령은 Linux 커널의 프로세스 사용률을 표시하는 데 사용됩니다. 출력에서 IOSd 프로세스에 대한 ARP 요청 때문에 FED 프로세스가 높음을 알 수 있습니다.

Switch# show processes cpu platform sorted CPU utilization for five seconds: 38%, one minute: 38%, five minutes: 40% Core 0: CPU utilization for five seconds: 39%, one minute: 37%, five minutes: 39% Core 1: CPU utilization for five seconds: 41%, one minute: 38%, five minutes: 40% Core 2: CPU utilization for five seconds: 30%, one minute: 38%, five minutes: 40% Core 3: CPU utilization for five seconds: 37%, one minute: 39%, five minutes: 41% Pid PPid 5Sec 1Min 5Min Status Size Name -------------------------------------------------------------------------------- 22701 22439 89% 88% 88% R 2187444224 linux_iosd-imag 11626 11064 46% 47% 48% S 2476175360 fed main event 4585 2 7% 9% 9% S 0 lsmpi-xmit 4586 2 3% 6% 6% S 0 lsmpi-rx 

2단계. FED가 패킷을 컨트롤 플레인으로 보내는 이유를 조사합니다.

1단계에서 시작합니다. IOSd/ARP 프로세스가 높게 실행되지만 데이터 플레인에서 유입되는 트래픽의 희생양이 된다고 결론을 내릴 수 있습니다. FED 프로세스가 왜 트래픽을 CPU에 보내고 이 트래픽은 어디에서 오는지에 대한 추가 조사가 필요합니다.

에서는 show platform software fed switch active punt cause summary 푼트 이유를 개괄적으로 설명합니다. 이 명령의 여러 실행에서 증가하는 숫자는 다음을 나타냅니다.

Switch#show platform software fed switch active punt cause summary Statistics for all causes Cause Cause Info Rcvd Dropped ------------------------------------------------------------------------------ 7 ARP request or response 18444227 0 11 For-us data 16 0 21 RP<->QFP keepalive 3367 0 24 Glean adjacency 2 0 55 For-us control 6787 0 60 IP subnet or broadcast packet 14 0 96 Layer2 control protocols 3548 0 ------------------------------------------------------------------------------ 

FED에서 제어 평면으로 전송되는 패킷은 높은 우선순위 제어 트래픽을 보장하기 위해 분할 대기열 구조를 사용합니다. ARP와 같이 우선순위가 낮은 트래픽 뒤에서는 손실되지 않습니다. 를 사용하면 이러한 대기열에 대한 대략적인 개요를 볼 수 있습니다show platform software fed switch active cpu-interface. 이 명령을 여러 번 실행하면 (Forus - CPU로 가는 트래픽을 Forus Resolution  의미함) 대기열이 빠르게 증가하는 것을 확인할 수 있습니다.

Switch#show platform software fed switch active cpu-interface queue retrieved dropped invalid hol-block ------------------------------------------------------------------------- Routing Protocol 8182 0 0 0 L2 Protocol 161 0 0 0 sw forwarding 2 0 0 0 broadcast 14 0 0 0 icmp gen 0 0 0 0 icmp redirect 0 0 0 0 logging 0 0 0 0 rpf-fail 0 0 0 0 DOT1X authentication 0 0 0 0 Forus Traffic 16 0 0 0 Forus Resolution 24097779 0 0 0 Inter FED 0 0 0 0 L2 LVX control 0 0 0 0 EWLC control 0 0 0 0 EWLC data 0 0 0 0 L2 LVX data 0 0 0 0 Learning cache 0 0 0 0 Topology control 4117 0 0 0 Proto snooping 0 0 0 0 DHCP snooping 0 0 0 0 Transit Traffic 0 0 0 0 Multi End station 0 0 0 0 Webauth 0 0 0 0 Crypto control 0 0 0 0 Exception 0 0 0 0 General Punt 0 0 0 0 NFL sampled data 0 0 0 0 Low latency 0 0 0 0 EGR exception 0 0 0 0 FSS 0 0 0 0 Multicast data 0 0 0 0 Gold packet 0 0 0 0 

를 사용하면 이러한 show platform software fed switch active punt cpuq all  대기열을 더 자세히 볼 수 있습니다. 대기열 5는 ARP를 담당하며, 예상대로 명령의 여러 실행에 걸쳐 증가합니다. 읽기show plat soft fed sw active inject cpuq clear를 쉽게 하기 위해 카운터를 지우기 위해 이 명령을 사용할 수 있습니다.

Switch#show platform software fed switch active punt cpuq all <snip> CPU Q Id : 5 CPU Q Name : CPU_Q_FORUS_ADDR_RESOLUTION Packets received from ASIC : 21018219 Send to IOSd total attempts : 21018219 Send to IOSd failed count : 0 RX suspend count : 0 RX unsuspend count : 0 RX unsuspend send count : 0 RX unsuspend send failed count : 0 RX consumed count : 0 RX dropped count : 0 RX non-active dropped count : 0 RX conversion failure dropped : 0 RX INTACK count : 1050215 RX packets dq'd after intack : 90 Active RxQ event : 3677400 RX spurious interrupt : 1050016 <snip> 

여기서 몇 가지 옵션이 있습니다. ARP는 브로드캐스트 트래픽이므로, 브로드캐스트 트래픽 비율이 비정상적으로 높은 인터페이스를 찾을 수 있습니다(레이어 2 루프 트러블슈팅에도 유용함). 어떤 인터페이스가 활발하게 증가하는지 확인하려면 이 명령을 여러 번 실행해야 합니다.

Switch#show interfaces counters Port InOctets InUcastPkts InMcastPkts InBcastPkts Gi1/0/1 1041141009678 9 0 16267828358 Gi1/0/2 1254 11 0 1 Gi1/0/3 0 0 0 0 Gi1/0/4 0 0 0 0

다른 옵션은 EPC(Embedded Packet Capture) 툴을 사용하여 제어 평면에서 보이는 패킷의 샘플을 수집하는 것입니다.

Switch#monitor capture cpuCap control-plane in match any file location flash:cpuCap.pcap Switch#show monitor capture cpuCap Status Information for Capture cpuCap Target Type: Interface: Control Plane, Direction: IN Status : Inactive Filter Details: Capture all packets Buffer Details: Buffer Type: LINEAR (default) File Details: Associated file name: flash:cpuCap.pcap Limit Details: Number of Packets to capture: 0 (no limit) Packet Capture duration: 0 (no limit) Packet Size to capture: 0 (no limit) Packet sampling rate: 0 (no sampling)

이 명령은 제어 평면으로 전달되는 트래픽을 캡처하기 위해 스위치에서 내부 캡처를 구성합니다. 이 트래픽은 플래시의 파일에 저장됩니다. 이 파일은 스위치에서 내보내고 추가 분석을 위해 Wireshark에서 열 수 있는 일반적인 wireshark pcap파일입니다.

캡처를 시작하고 몇 초 동안 실행한 다음 캡처를 중지합니다.

Switch#monitor capture cpuCap start Enabling Control plane capture may seriously impact system performance. Do you want to continue? [yes/no]: yes Started capture point : cpuCap *Jun 14 17:57:43.172: %BUFCAP-6-ENABLE: Capture Point cpuCap enabled. Switch#monitor capture cpuCap stop Capture statistics collected at software: Capture duration - 59 seconds Packets received - 215950 Packets dropped - 0 Packets oversized - 0 Bytes dropped in asic - 0 Stopped capture point : cpuCap Switch# *Jun 14 17:58:37.884: %BUFCAP-6-DISABLE: Capture Point cpuCap disabled.

스위치의 캡처 파일을 볼 수도 있습니다.

Switch#show monitor capture file flash:cpuCap.pcap Starting the packet display ........ Press Ctrl + Shift + 6 to exit 1 0.000000 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 2 0.000054 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 3 0.000082 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 4 0.000109 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 5 0.000136 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 6 0.000162 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 7 0.000188 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 8 0.000214 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 9 0.000241 Xerox_d7:67:a1 -> Broadcast ARP 60 Who has 192.168.1.24? Tell 192.168.1.2 

이 출력에서 192.168.1.2 호스트는 스위치의 높은 CPU를 유발하는 상수 ARP의 소스임이 분명합니다. 호스트를 show ip arp 추적하고show mac address-table address 네트워크에서 제거하거나 ARP를 해결하려면 및 명령을 사용합니다. capture view 명령의 detail 옵션을 사용하여 캡처된 각 패킷의 전체 세부사항을 가져올 수도 있습니다show monitor capture file flash:cpuCap.pcap detail. Catalyst 스위치의 패킷 캡처에 대한 자세한 내용은 이 가이드를 참조하십시오.

사례 연구 2. CoPP를 사용한 IP 리디렉션

최신 Catalyst 스위치는 기본적으로 CoPP(Control Plane Policing)에 의해 보호됩니다. CoPP는 스패닝 트리 및 라우팅 프로토콜과 같은 중요한 기능을 유지하기 위해 스위치의 기능을 위태롭게 할 수 있는 악의적인 공격 및 잘못된 컨피그레이션으로부터 CPU를 보호하기 위해 사용됩니다. 이러한 보호로 인해 스위치에 약간 상승된 CPU만 있고 인터페이스 카운터가 지워져 있지만 트래픽이 스위치를 통과하는 동안 삭제되는 시나리오가 발생할 수 있습니다. 정상 작동 시 디바이스의 기준 CPU 사용률을 확인하는 것이 중요합니다. CPU 사용률을 높이는 것이 반드시 문제가 되는 것은 아니며 디바이스에서 활성화된 기능에 따라 다르지만 컨피그레이션 변경 없이 사용률이 증가하면 이는 문제의 징후가 될 수 있습니다.

이 시나리오를 고려해 보십시오. 게이트웨이 스위치에서 떨어진 호스트에 따르면 다운로드 속도가 느리고 인터넷에 ping이 손실됩니다. 스위치의 일반적인 상태 검사에서는 게이트웨이 스위치에서 제공된 경우 인터페이스에 오류가 없거나 ping 손실이 발생하지 않습니다.

CPU를 체크하면 인터럽트로 인해 약간 상승된 숫자가 표시됩니다.

Switch#show processes cpu sorted | ex 0.00 CPU utilization for five seconds: 8%/7%; one minute: 8%; five minutes: 8% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 122 913359 1990893 458 0.39% 1.29% 1.57% 0 IOSXE-RP Punt Se 147 5823 16416 354 0.07% 0.05% 0.06% 0 PLFM-MGR IPC pro 404 13237 183032 72 0.07% 0.08% 0.07% 0 MMA DP TIMER 

CPU 인터페이스를 선택하면 ICMP 리디렉션 카운터가 활발하게 증가합니다.

Switch#show platform software fed switch active cpu-interface queue retrieved dropped invalid hol-block ------------------------------------------------------------------------- Routing Protocol 12175 0 0 0 L2 Protocol 236 0 0 0 sw forwarding 714673 0 0 0 broadcast 2 0 0 0 icmp gen 0 0 0 0 icmp redirect 2662788 0 0 0 logging 7 0 0 0 rpf-fail 0 0 0 0 DOT1X authentication 0 0 0 0 Forus Traffic 21776434 0 0 0 Forus Resolution 724021 0 0 0 Inter FED 0 0 0 0 L2 LVX control 0 0 0 0 EWLC control 0 0 0 0 EWLC data 0 0 0 0 L2 LVX data 0 0 0 0 Learning cache 0 0 0 0 Topology control 6122 0 0 0 Proto snooping 0 0 0 0 DHCP snooping 0 0 0 0 Transit Traffic 0 0 0 0 

FED에서 삭제는 관찰되지 않지만 CoPP를 선택하면 ICMP 리디렉션 대기열에서 삭제는 관찰될 수 있습니다.

Switch#show platform hardware fed switch 1 qos queue stats internal cpu policer CPU Queue Statistics ============================================================================================ (default) (set) Queue QId PlcIdx Queue Name Enabled Rate Rate Drop(Bytes) ----------------------------------------------------------------------------- 0 11 DOT1X Auth Yes 1000 1000 0 1 1 L2 Control Yes 2000 2000 0 2 14 Forus traffic Yes 4000 4000 0 3 0 ICMP GEN Yes 600 600 0 4 2 Routing Control Yes 5400 5400 0 5 14 Forus Address resolution Yes 4000 4000 0 6 0 ICMP Redirect Yes 600 600 463538463 7 16 Inter FED Traffic Yes 2000 2000 0 8 4 L2 LVX Cont Pack Yes 1000 1000 0 <snip>

CoPP는 기본적으로 디바이스의 컨트롤 플레인에 적용되는 QoS 정책입니다. CoPP는 스위치의 다른 QoS와 동일하게 작동합니다. 즉, 특정 트래픽에 대한 큐가 모두 소진되면 해당 큐를 사용하는 트래픽이 삭제됩니다. 이러한 출력에서 트래픽은 ICMP 리디렉션으로 인해 소프트웨어 스위칭되고 있음을 알 수 있으며, ICMP 리디렉션 대기열의 속도 제한 때문에 이 트래픽이 삭제되고 있음을 알 수 있습니다. 컨트롤 플레인에 도달한 패킷이 사용자로부터의 것임을 확인하기 위해 컨트롤 플레인에서 캡처를 수행할 수 있습니다.

각 클래스에서 어떤 일치 논리를 사용하는지 확인하기 위해 특정 대기열에 도달한 패킷 유형을 식별하는 데 도움이 되는 CLI가 있습니다. 클래스에 맞는 항목을 확인하려면 다음 예를 system-cpp-routing-control 고려하십시오.



Switch#show platform software qos copp policy-info
Default rates of all classmaps are displayed:
 policy-map system-cpp-policy
 class system-cpp-police-routing-control
 police rate 5400 pps

Switch#show platform software qos copp class-info
ACL representable classmap filters are displayed:
class-map match-any system-cpp-police-routing-control
 description Routing control and Low Latency
 match access-group name system-cpp-mac-match-routing-control
 match access-group name system-cpp-ipv4-match-routing-control
 match access-group name system-cpp-ipv6-match-routing-control
 match access-group name system-cpp-ipv4-match-low-latency
 match access-group name system-cpp-ipv6-match-low-latency

mac access-list extended system-cpp-mac-match-routing-control
 permit any host 0180.C200.0014
 permit any host 0900.2B00.0004
 ip access-list extended system-cpp-ipv4-match-routing-control
 permit udp any any eq rip
 <...snip...>
 ipv6 access-list system-cpp-ipv6-match-routing-control
 permit ipv6 any FF02::1:FF00:0/104
 permit ipv6 any host FF01::1
<...snip...>
 ip access-list extended system-cpp-ipv4-match-low-latency
 permit udp any any eq 3784
 permit udp any any eq 3785
 ipv6 access-list system-cpp-ipv6-match-low-latency
 permit udp any any eq 3784
 permit udp any any eq 3785
 <...snip...> 

Switch#monitor capture cpuSPan control-plane in match any file location flash:cpuCap.pcap Control-plane direction IN is already attached to the capture Switch#monitor capture cpuSpan start Enabling Control plane capture may seriously impact system performance. Do you want to continue? [yes/no]: yes Started capture point : cpuSpan Switch# *Jun 15 17:28:52.841: %BUFCAP-6-ENABLE: Capture Point cpuSpan enabled. Switch#monitor capture cpuSpan stop Capture statistics collected at software: Capture duration - 12 seconds Packets received - 5751 Packets dropped - 0 Packets oversized - 0 Bytes dropped in asic - 0 Stopped capture point : cpuSpan Switch# *Jun 15 17:29:02.415: %BUFCAP-6-DISABLE: Capture Point cpuSpan disabled. Switch#show monitor capture file flash:cpuCap.pcap detailed Starting the packet display ........ Press Ctrl + Shift + 6 to exit Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
<snip>
Ethernet II, Src: OmronTat_2c:a1:52 (00:00:0a:2c:a1:52), Dst: Cisco_8f:cb:47 (00:42:5a:8f:cb:47)
<snip>
Internet Protocol Version 4, Src: 192.168.1.10, Dst: 8.8.8.8
 <snip>

이 호스트는 8.8.8.8에 ping을 수행할 때 목적지 주소가 VLAN 외부에 있으므로 게이트웨이의 MAC 주소로 ping을 전송합니다. 게이트웨이 스위치는 다음 홉이 동일한 VLAN에 있음을 탐지하고 대상 MAC 주소를 방화벽에 다시 쓴 다음 패킷을 전달합니다. 이 프로세스는 하드웨어에서 발생할 수 있지만 이 하드웨어 전달의 예외는 IP 리디렉션 프로세스입니다. 스위치에서 ping을 수신하면 동일한 VLAN에서 트래픽을 라우팅하는 것을 감지하고 호스트로 리디렉션 패킷을 다시 생성하기 위해 트래픽을 CPU에 적용합니다. 이 리디렉션 메시지는 목적지에 더 최적의 경로가 있음을 호스트에 알리기 위한 것입니다. 이 경우 레이어 2 next-hop은 설계에 따른 것이며, 리디렉션 메시지를 보내지 않고 패킷을 하드웨어에서 전달하도록 스위치를 구성해야 합니다. 이는 VLAN 인터페이스에서 리디렉션을 비활성화할 때 수행됩니다.

interface Vlan1 ip address 192.168.1.1 255.255.255.0 no ip redirects end 

IP 리디렉션이 해제되면 스위치에서 MAC 주소를 다시 쓰고 하드웨어로 전달합니다.

사례 연구 3. 간헐적으로 높은 CPU

스위치의 높은 CPU가 간헐적으로 발생하는 경우, 높은 CPU 이벤트가 발생할 때 이러한 명령을 자동으로 실행하기 위해 스위치에 스크립트를 설정할 수 있습니다. 이 작업은 Cisco IOS EEM(Embedded Event Manager)을 사용하여 수행합니다.

entry-val은 스크립트가 트리거되기 전에 CPU가 얼마나 높은지 확인하기 위해 사용됩니다. 스크립트는 5초 CPU 평균 SNMP OID를 모니터링합니다. 플래시에 2개의 파일이 작성되고, 명령 출력이tac-cpu-<timestamp>.txt 포함되며, tac-cpu-<timestamp>.pcap CPU 인그레스 캡처가 포함됩니다. 이 파일은 나중에 검토할 수 있습니다.

config t
no event manager applet high-cpu authorization bypass
event manager applet high-cpu authorization bypass
event snmp oid 1.3.6.1.4.1.9.9.109.1.1.1.1.3.1 get-type next entry-op gt entry-val 80 poll-interval 1 ratelimit 300 maxrun 180
action 0.01 syslog msg "High CPU detected, gathering system information."
action 0.02 cli command "enable"
action 0.03 cli command "term exec prompt timestamp"
action 0.04 cli command "term length 0"
action 0.05 cli command "show clock"
action 0.06 regex "([0-9]|[0-9][0-9]):([0-9]|[0-9][0-9]):([0-9]|[0-9][0-9])" $_cli_result match match1
action 0.07 string replace "$match" 2 2 "."
action 0.08 string replace "$_string_result" 5 5 "."
action 0.09 set time $_string_result
action 1.01 cli command "show proc cpu sort | append flash:tac-cpu-$time.txt"
action 1.02 cli command "show proc cpu hist | append flash:tac-cpu-$time.txt"
action 1.03 cli command "show proc cpu platform sorted | append flash:tac-cpu-$time.txt"
action 1.04 cli command "show interface | append flash:tac-cpu-$time.txt"
action 1.05 cli command "show interface stats | append flash:tac-cpu-$time.txt"
action 1.06 cli command "show log | append flash:tac-cpu-$time.txt"
action 1.07 cli command "show ip traffic | append flash:tac-cpu-$time.txt"
action 1.08 cli command "show users | append flash:tac-cpu-$time.txt"
action 1.09 cli command "show platform software fed switch active punt cause summary | append flash:tac-cpu-$time.txt"
action 1.10 cli command "show platform software fed switch active cpu-interface | append flash:tac-cpu-$time.txt"
action 1.11 cli command "show platform software fed switch active punt cpuq all | append flash:tac-cpu-$time.txt"
action 2.08 cli command "no monitor capture tac_cpu"
action 2.09 cli command "monitor capture tac_cpu control-plane in match any file location flash:tac-cpu-$time.pcap"
action 2.10 cli command "monitor capture tac_cpu start" pattern "yes"
action 2.11 cli command "yes"
action 2.12 wait 10
action 2.13 cli command "monitor capture tac_cpu stop"
action 3.01 cli command "term default length"
action 3.02 cli command "terminal no exec prompt timestamp"
action 3.03 cli command "no monitor capture tac_cpu"   

관련 정보

• Cisco IOS XE 16 살펴보기
• Catalyst 3850 시리즈 스위치 높은 CPU 사용량 문제 해결
• Cisco IOS 및 Cisco IOS XE를 위한 임베디드 패킷 캡처 구성 예
• Cisco IOS XE 16.x를 실행하는 Catalyst 스위치에서 Punt/Inject FED 패킷 캡처 구성
• Cisco 기술 지원 및 다운로드