Cisco IOS XE 16.x上のCatalystスイッチにおけるCPU使用率のトラブルシューティング

はじめに

このドキュメントでは、16.xリリースを実行しているCisco IOS® XEプラットフォームで中断が発生してCPU使用率が高くなる場合のトラブルシューティング方法について説明します。

背景説明

このドキュメントの著者は、Cisco TACエンジニアのRaymond WhitingおよびYogesh Ramdossです。

また、このドキュメントでは、CPU使用率が高い問題のトラブルシューティングに不可欠な、このプラットフォームでの新しいコマンドについても紹介します。Cisco IOS XEの構築方法を理解することが重要です。Cisco IOS XEにより、シスコはLinuxカーネルに移行し、すべてのサブシステムがプロセスに分割されました。モジュールドライバやハイアベイラビリティ(HA)など、以前Cisco IOS内にあったサブシステムはすべて、Linuxオペレーティングシステム(OS)内のソフトウェアプロセスとして動作するようになりました。Cisco IOS 自体は、Linux OS 内のデーモン（IOSd）として動作します。Cisco IOS XEは、従来のCisco IOSと同じルックアンドフィールだけでなく、その運用、サポート、および管理も維持しています。

いくつかの有用な定義を次に示します。

• Forwarding Engine Driver(FED)：これはCisco Catalystスイッチの中核であり、すべてのハードウェアのプログラミング/転送を行います。
• IOSd:Linuxカーネルで動作するCisco IOSデーモンです。カーネル内のソフトウェア プロセスとして実行されます。
• Packet Delivery System（PDS；パケット配信システム）：さまざまなサブシステムとの間でパケットを配信する方法のアーキテクチャとプロセスです。たとえば、FED と IOSd の間でのパケットの送受信を制御します。
• コントロールプレーン(CP)：コントロールプレーンは、CatalystスイッチのCPUに関連する機能とトラフィックをグループ化するために使用される総称です。これには、スパニングツリープロトコル(STP)、ホットスタンバイルータプロトコル(HSRP)、およびスイッチを宛先とする、またはスイッチから送信されるルーティングプロトコルなどのトラフィックが含まれます。これには、セキュアシェル(SSH)やCPUで処理するSimple Network Management Protocol(SNMP)などのアプリケーション層プロトコルも含まれます。
• データプレーン(DP)：通常、データプレーンには、コントロールプレーンの支援なしで転送されるハードウェアASICとトラフィックが含まれます。
• パント：入力プロトコル制御パケットは、DPによって代行受信され、CPに送信されて処理されます。
• インジェクト：CPによって生成されたプロトコルパケットが、IOインターフェイスから出力するためにDPに送信されます。
• LSMPI: Linux Shared Memory Punt Interfaceの略。

データプレーンとコントロールプレーンの間の通信パスの概要図：

CPU使用率が高い場合のトラブルシューティングワークフロー

このセクションでは、スイッチのCPU高使用率の問題をトリアージするための体系的なワークフローについて説明します。このセクションでは、このセクションの作成時点で選択したプロセスを取り上げます。

ケース スタディ 1Address Resolution Protocol(ARP)割り込み

このセクションのトラブルシューティングと検証のプロセスは、割り込みによってCPU使用率が高くなる場合に幅広く使用できます。

ステップ 1：CPU サイクルを消費しているプロセスを特定する

コマshow process cpu  ンドは、IOSdデーモン内部の現在のプロセス状態を表示するために使用されます。出力modifyを追加すると| exclude 0.00、現在アイドル状態のプロセスがフィルタで除外されます。

この出力には、次の2つの重要な情報が含まれています。

• 5秒間のCPU使用率：91 %/30 %
  • 最初の数字(91 %)は、スイッチの全体的なCPU使用率です
  • 2番目の数値(30 %)は、データプレーンからの割り込みによって発生する使用率です
• Address Resolution Protocol（ARP；アドレス解決プロトコル）(ARP) Input(ARP)プロセスは、現在、リソースを消費している上位の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カーネルからのプロセス使用率を表示するために使用されます。出力から、FEDプロセスが高いことが確認できます。これは、IOSdプロセスにパントされたARP要求によるものです。

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 Resolution  （Forus:CPU宛てのトラフィック）キューが急速に増加することがわかります。

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

もう1つのオプションは、Embedded Packet Capture(EPC)ツールを使用して、コントロールプレーンで確認されるパケットのサンプルを収集することです。

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 pcapファイルで、スイッチからエクスポートしてWiresharkで開き、詳細な分析を行うことができます。

キャプチャを開始し、数秒間実行し、キャプチャを停止します。

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スイッチでのパケットキャプチャの詳細については、『このガイド』を参照してください。

ケース スタディ 2CoPPによるIPリダイレクト

最新世代のCatalystスイッチは、デフォルトでコントロールプレーンポリシング(CoPP)によって保護されます。CoPPは、スパニングツリーやルーティングプロトコルなどの重要な機能を維持するためにスイッチの機能を損なう可能性がある、悪意のある攻撃や設定ミスからCPUを保護するために使用されます。これらの保護により、スイッチのCPUとクリアインターフェイスカウンタがわずかに上昇するだけで、スイッチを通過する間にトラフィックがドロップされるシナリオが発生する可能性があります。通常の動作時のデバイスのベースラインCPU使用率に注意することが重要です。これは必ずしもCPU使用率の上昇が問題になるとは限らず、デバイスで有効になっている機能によって異なります。しかし、設定を変更せずにこの使用率が上昇した場合、これは懸念のサインである可能性があります。

ゲートウェイスイッチの外に存在するホストから、ダウンロード速度が遅く、インターネットへのpingが失われるというシナリオを考えてみましょう。スイッチの一般的なヘルスチェックでは、インターフェイスでエラーが発生していないか、ゲートウェイスイッチから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ネクストホップは設計上、想定どおりであるため、リダイレクトメッセージを送信してハードウェアでパケットを転送しないようにスイッチを設定する必要があります。これは、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 Embedded Event Manager(EEM)を使用して行われます。

entry-valは、スクリプトがトリガーされる前のCPUの使用率を判断するために使用されます。スクリプトは、5秒間のCPUの平均SNMP OIDを監視します。2つのファイルがフラッシュに書き込まれ、コマンド出力とtac-cpu-<timestamp>.txtCPU入力キャプチャが含tac-cpu-<timestamp>.pcapまれています。これらのファイルは後で確認できます。

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スイッチでのパント/インジェクトFEDパケットキャプチャの設定
• シスコのテクニカルサポートとダウンロード