CPU使用率が高い場合のトラブルシューティング
目次
原因の特定（システム プロセスまたはネットワーク トラフィック）
CPU 使用率の概要
スイッチのブート プロセスが完了すると、スイッチの CPU で、次の 2 つの異なる機能が同時に実行されます。
•
ネットワークでスイッチが稼動するために必要なさまざまなシステム プロセスが実行される。
CPU 使用率は、システム プロセスが時間を要するほど、またネットワーク パケットの送受信量が多いほど増大します。
通常の動作条件下では、スタック構成にできないスイッチの CPU は、CPU 時間の 5% 以上でビジー状態になります。スイッチがスタック構成の場合、CPU は、7 または 8% 以上の使用率でビジー状態になります。スイッチ スタックでは、CPU 使用率は、マスター スイッチでのみ測定されます。スタック内のメンバーの数が CPU 使用率全体に影響します。
スイッチ タイマーのシスコのバックグラウンド システム プロセスが毎秒数回実行するため、最も単純な配置であっても、スイッチの CPU 使用率が 0% と報告されることはありません。
（注） データ トラフィックの通常のパケット スイッチングは、スイッチ ハードウェアで行われ、CPU は関与しないので、過度にビジー状態の CPU の影響を受けることはありません。
CPU が過度にビジー状態になるのは、CPU がスイッチ ハードウェアから受信するパケットが多すぎる場合や、システム プロセスが CPU 時間を消費しすぎる場合です。このどちらかの作用が原因でもう一方に支障が出るほど CPU リソースを使用している場合に、CPU が過度にビジー状態になります。たとえば、ネットワーク上のブロードキャスト ストームのために CPU が多くのパケットを受信している場合は、そのすべてのパケットを処理することで過度にビジー状態になるため、別のシステム プロセスが CPU リソースにアクセスできなくなります。
スイッチの CPU 使用率を確認するには、 show processes cpu sorted 特権 EXEC コマンドを入力します。出力には、過去 5 秒、過去 1 分、および過去 5 分の CPU のビジー状態が表示されます。また、各システム プロセスがこれらの期間に使用した CPU 使用率も表示されます。
この出力では、過去 5 秒間の CPU 使用率には 2 つの数字（ 5%/0% ）が表示されています。
• 最初の数字 5% で、CPU が過去 5 秒間にどの程度ビジー状態だったかがわかります。この数字は、全アクティブ システム プロセスの総 CPU 使用率であり、割り込みレベルでの時間の割合も含まれています。
• 2 番目の数字 0% は、過去 5 秒間の割り込みレベルでの時間の割合が表示されています。割り込みの割合とは、スイッチ ハードウェアからのパケットの受信に費やされる CPU 時間のことです。割り込みレベルでの時間の割合は、常に総 CPU 使用率以下です。
その他の 2 つの重要な数字として、過去 1 分間の平均使用率（この例では 6%）および過去 5 分間の平均使用率（この例では 5%）が同じ出力行に表示されます。これらの値は、小規模な安定した環境での、スタック構成されていないスイッチにおける標準的な値です。
CPU では、常時多数のシステム プロセスがアクティブになっていると考えられます。この数字は、スイッチ モデル、Cisco IOS リリース、機能セット、およびスイッチ スタック内のスイッチの数（該当する場合）に基づいて変わる可能性があります。たとえば、IP ベース イメージが稼動する Catalyst 3750 スイッチのスタックでは、通常、475 のシステム プロセスがアクティブになっています。LAN ベース イメージが稼動する Catalyst 2960 スイッチのアクティブ プロセス数は、Catalyst 3750 スイッチよりも少なくなっています。一般に、Cisco IOS イメージの機能が多いほど、システム プロセス数も多くなります。
CPU 使用率が高いことが問題となっている場合
ここでは、CPU 使用率が高い場合にそれを特定し、それが問題であるかどうかを確認する方法について説明します。
• 「CPU 使用率が高いことに起因するネットワークの症状」
場合によっては、CPU 使用率が高いことは正常であり、ネットワークの問題の原因にはなりません。CPU 使用率が高いことが問題になるのは、スイッチが期待どおりに機能しない場合です。
show processes cpu history 特権 EXEC コマンドを入力し、過去 60 秒、60 分、および 72 時間の CPU 使用率を確認します。このコマンドの出力では、CPU のビジー状態の程度がグラフィカルに表示されます。CPU が絶えずビジー状態だったか、あるいは使用率が急増する箇所があったかどうかを確認できます。
この例では、スイッチが再起動されて間もない 46 時間前に CPU 使用率が 100% まで急増しています。また、過去 1 時間以内に 87% まで急増しています。
既知のネットワーク イベントやアクティビティによって CPU 使用率が急増することは、問題ではありません。87% の急増でも、原因によっては許容できる場合があります。たとえば、ネットワーク管理者が CLI で write memory 特権 EXEC コマンドを入力したことによる急増は許容範囲内です。また、大規模なレイヤ 2 ネットワークのトポロジを変更した場合の急増も、正常な反応です。CPU 使用率が急増する原因となるイベントおよびアクティビティのリストについては、「CPU 使用率が高くなる正常な状態」を参照してください。
時間の経過とともに、スイッチは一定の持続的な CPU 使用率の範囲で動作するため、それが通常動作の基準と見なされます。 show processes cpu history 特権 EXEC コマンドの出力を使用すると、過去 72 時間の通常動作の基準使用率を特定できます。不明な理由により CPU 使用率が通常動作の基準を超えている場合は、問題があるとわかります。
先ほどの例では、過去 37 時間の CPU 使用率は 40 ～ 56% でした。50% 未満の CPU 使用率は許容範囲内と考えられます。この例のような、50% 前後が続く場合も許容範囲内です。50% を超える CPU 使用率が続く場合は、問題が発生しているおそれがあります。このレベルの CPU 使用率では、スイッチは問題なく動作しているように思えますが、スイッチの CPU の使用率で 50% が続く場合は、ダイナミック ネットワーク イベントへの応答機能のセキュリティが侵害されています。
確立された通常動作基準に対して頻繁に発生する不可解な急増や説明のつかない使用率の急増は、不安材料となります。CPU 使用率が高くなる問題の原因を特定するには、「根本的な原因の特定」を参照してください。
CPU 使用率が高くなる正常な状態
一部のネットワーク配置では、CPU は、ビジー状態で正常です。一般に、レイヤ 2 またはレイヤ 3 のネットワークが大規模になるほど、CPU に対するネットワーク関連トラフィックの処理要求が増大します。次の例では、CPU 使用率が高くなる可能性のある動作を示します。
スパニングツリー
レイヤ 2 のスパニングツリー インスタンスは、レイヤ 2 スイッチの Per-VLAN Spanning-Tree（PVST; VLAN 単位のスパニングツリー）機能によって設定されたすべての VLAN で実行します。スパニングツリーによって費やされる CPU 時間は、スパニングツリー インスタンスの数およびアクティブなインターフェイスの数によって異なります。インスタンスの数やアクティブなインターフェイスの数が多くなるほど、CPU 使用率は増大します。
IP ルーティング テーブルの更新
IP ルーティングをイネーブルにしたレイヤ 3 スイッチが大量のルーティング テーブルを受信すると、そのスイッチでルーティング情報の更新処理を行う必要があります。処理中の CPU 使用率の急増は、次の要因に依存します。
Cisco IOS コマンド
Cisco IOS コマンドの中には、CPU 使用率が急増する原因となるものもあります。モジュールは次のとおりです。
• show tech-support 特権 EXEC コマンド。
• write memory 特権 EXEC コマンド（特にスイッチがスタック内にある場合）。
• スイッチ スタック マスターでの show-running configuration 特権 EXEC コマンド。
• 機能のデバッグをイネーブルにする debug 特権 EXEC コマンド。デバッグがイネーブルになっている間は、デバッグ メッセージのコンソール出力により CPU 使用率が増大します。
CPU 使用率が高くなる原因となるその他のイベント
• 高頻度または大量の IGMP 要求：CPU で IGMP メッセージが処理されます。
• 大量の IP SLA モニタリング セッション：CPU で ICMP パケットまたは traceroute パケットが生成されます。
• SNMP ポーリング アクティビティ（特に MIB Walk）：Cisco IOS SNMP エンジンで SNMP 要求が実行されます。
• 多数のクライアントへのリンクが復元されるときなどの大量の同時 DHCP 要求（スイッチが DHCP サーバとして機能している場合）。
CPU 使用率が高いことに起因するネットワークの症状
CPU が過度にビジー状態になっている場合は、システム プロセスが期待どおりに実行できなくなります。システム プロセスが実行しない場合、スイッチ（または直接接続されたネットワーク デバイス）は、ネットワークに問題があるかのように反応します。レイヤ 2 ネットワークの場合は、スパニングツリー再コンバージが行われることがあります。レイヤ 3 ネットワークでは、ルーティング トポロジが変更されることがあります。
スイッチの CPU が過度にビジー状態になっている場合は、次のような既知の症状が発生します。
• スパニングツリー トポロジの変更：レイヤ 2 ネットワーク デバイスがルート ポートでスパニングツリー BPDU を適度なタイミングで受信しない場合は、そのデバイスでルート スイッチへのレイヤ 2 パスがダウン状態と見なされ、新しいパスの検索が試行されます。スパニングツリーがレイヤ 2 ネットワークで再コンバージします。
• ルーティング トポロジ変更の変更（BGP ルート フラッピングまたは OSPF ルート フラッピング）。
• EtherChannel リンク バウンス：EtherChannel の相手側のネットワーク デバイスが、EtherChannel リンクを維持するために必要なプロトコル パケットを受信しない場合、これが原因でリンクがダウンすることがあります。
– 速度が遅いまたは開始できない Telnet セッションや SSH セッション
• UDLD フラッピング：スイッチが、アグレッシブ モードでピアからのキープアライブを利用します。
• 許容しきい値を超えた SLA 応答による IP SLA 障害。
• スイッチで要求の転送や応答ができない場合の DHCP または IEEE 802.1x の障害。
割り込みの割合の特定
CPU 使用率の履歴では、時間の経過に伴う総 CPU 使用率のみが表示され、割り込みに費やされた CPU 時間は表示されません。CPU 使用率の問題の原因を特定するためには、割り込みに費やされる時間を把握しておくことが重要です。CPU 使用率の履歴には、CPU が絶えずネットワーク パケットを受信している状況は表示されても、その原因は表示されません。
Cisco IOS show processes cpu sorted 5sec 特権 EXEC コマンドを入力すると、現在の CPU 使用率および最も CPU 時間を消費している IOS プロセスが表示されます。この例では、持続的な使用率が 50% という基準を超えているため、CPU は過度にビジー状態になっています。
矢印は、割り込みの割合値を示しています。この値は、5 秒間の使用率の割合における 2 番目の数字です。
割り込みの割合値が 0% より大きく 5% 未満の場合は正常です。この値が 5 ～ 10% の場合は許容範囲内です。割り込みの割合値が 10% を超えている場合は、調査する必要があります。調査内容については、「ネットワーク トラフィックの分析」を参照してください。
根本的な原因の特定
CPU が過度にビジー状態になっていると思われる場合は、その理由が、システム プロセスで CPU 時間を消費しすぎているためか、またはネットワーク パケットを大量に受信しているためかを最初に特定します。この 2 つの根本的な原因のデバッグ技法には、さまざまなものがあります。ここでは、原因を特定してトラブルシューティングを行う方法について説明します。
• 「原因の特定（システム プロセスまたはネットワーク トラフィック）」
（注） 必ず、特定のプラットフォーム、および使用しているスイッチのソフトウェア リリースについてのリリース ノートを参照して、Cisco IOS の既知のバグを確認してください。それらの問題はトラブルシューティング手順から除外できます。
スイッチの CPU がビジー状態になっている場合は、通常、Telnet や SSH のような管理ツールはあまり役に立ちません。CPU 使用率に関する問題のデバッグには、スイッチ コンソールを使用することをお勧めします。
原因の特定（システム プロセスまたはネットワーク トラフィック）
CPU のビジー状態の程度および最も CPU 時間を消費しているオペレーティング システム プロセスを特定するには、 show processes cpu sorted 5sec 特権 EXEC コマンドを入力します。この出力では、 CPU utilization for five seconds の 2 番目の数字が割り込みの割合です。割り込みの割合を使用して、問題の原因がシステム プロセスにあるか、または高ネットワーク トラフィックにあるかを特定します。
総 CPU 使用率の割合に比べて割り込みの割合が高すぎる場合、CPU 使用率の問題は、システム ハードウェアから受信するパケット数が多すぎることが原因です。割り込みの割合が高いことを特定する方法については、「割り込みの割合の特定」を参照してください。
• 割り込みの割合が高い場合は、ネットワーク トラフィックが多すぎることを表しています。これは、CPU 使用率が高くなる原因として最も一般的です。トラブルシューティングを行うには、「ネットワーク トラフィックの分析」を参照してください。
• CPU 使用率の割合が高く割り込みの割合が低い場合は、オペレーティング システム プロセスに問題があることを表しています。トラブルシューティングを行うには、「アクティブなプロセスのデバッグ」を参照してください。
• 両方の割合が高い場合や、割り込みの割合が CPU 使用率を大きく左右しているかどうかを特定できない場合は、最初に「ネットワーク トラフィックの分析」を参照してください。ここに記載されている情報では CPU 使用率が高くなる問題を解決できない場合は、「アクティブなプロセスのデバッグ」を参照してください。
この例では、CPU 使用率は 64% であり、割り込みの割合は 19% という高い状態にあります。使用率の問題は、CPU でネットワークから受信した過剰なパケットを処理していることが原因です。この場合は、「ネットワーク トラフィックの分析」を参照してください。
次の例では、割り込みの割合は CPU 使用率の割合に比べて低くなっています（82% に対して 5%）。CPU 使用率が高く割り込みの割合が比較的低い場合は、1 つ以上のシステム プロセスに時間がかかりすぎていることを表しています。この場合は、「アクティブなプロセスのデバッグ」を参照してください。
ネットワーク トラフィックの分析
割り込みの割合が高い場合、問題の根本的な原因は、CPU で受信しているパケット数が多すぎることです。この問題を解決するには、パケットの送信元を見つけて、フローを停止するか、スイッチのコンフィギュレーションを変更する必要があります。次の項を参照してください。
システム プロセスおよびネットワーク パケット
スイッチがパケットの管理に使用するシステム プロセスによって、CPU のフラッディングの原因となっているネットワーク パケットのタイプを特定できます。CPU の割り込みの割合が CPU 使用率全体の割合に比べて高い場合、最もアクティブなシステム プロセスを特定するには、 show processes cpu sorted 5sec 特権 EXEC コマンドを入力します。CPU では、複数のパケット タイプを受信し、アクティブなシステム プロセスを複数実行している可能性があります。この出力には、最もアクティブなプロセスが先頭に示されます。最もアクティブなシステム プロセスが、ネットワーク パケットの受信に対応していると考えられます。
表 1 に、一般的なシステム プロセスおよび関連するパケット タイプを示します。記載されているシステム プロセスのいずれかが CPU における最もアクティブなプロセスである場合は、そのプロセスによって、対応するネットワーク パケット タイプが CPU のフラッディングの原因になっていると考えられます。
パケットの送信元を見つけてトラブルシューティングを行う方法については、「CPU で受信したネットワーク パケットの特定」を参照してください。
システム プロセスおよびパント パケット
レイヤ 3 スイッチで、IP ルートが認識されない場合は、IP ルーティング用の IP パケットが CPU に パント （送信）されます。パント パケットは、割り込みレベルで処理されるので、CPU の過度なビジー状態の原因となる場合があります。コマンド出力で表示される割り込みの割合は高くても、表示されている中に最もアクティブなプロセスがない場合（ 表 1 ）や、CPU 使用率が高くなる原因となるだけのアクティブなプロセスがない場合は、出力例に示すように、ほとんど パント パケットが原因で CPU 使用率が高くなっていると考えられます。
表 2 に、CPU がパント IP パケットの処理でビジー状態になっている場合の最もアクティブなシステム プロセスを示します。パント パケットの CPU 処理は、示されたプロセスには関連付けられていません。
パント パケットのトラブルシューティング手順については、「スイッチ ハードウェアからパントされたパケットの特定」を参照してください。
CPU で受信したネットワーク パケットの特定
CPU に送信されているパケットのタイプを特定する次の技法は、相互補完的に使用したり、単独で使用したりすることができます。
• パケットは、各 CPU 受信キューにおいてカウントされます。このカウントを使用して、受信パケットのタイプを特定できます。「CPU 受信キューのパケット カウントのモニタリング」を参照してください。
• debug 特権 EXEC コマンドを使用すると、CPU で受信したすべてのパケットをコンソールに出力できます。 debug コマンドでは、各受信キューを個別にデバッグできます。「スイッチ CPU 受信キューからのパケットのデバッグ」を参照してください。
• 送受信される IP パケットはすべてカウントされます。この情報は、特に数の多いパケットや急増しているパケットを特定するのに役立ちます。「IP トラフィック カウントのモニタリング」を参照してください。
CPU 受信キューのパケット カウントのモニタリング
特定のパケット タイプがスイッチのフラッディングの原因となっている場合、そのパケット タイプは適切な CPU キューに格納され、カウントされます。キューごとのパケット カウントを確認するには、 show controllers cpu-interface 特権 EXEC コマンドを入力します。
また、輻輳のために廃棄される CPU バウンド パケットもカウントされます。各 CPU 受信キューには、パケット カウントの最大値が設定されています。受信キューが最大値に達すると、輻輳キュー宛てのパケットは廃棄されます。廃棄されたパケットは、キューごとにカウントされます。特定の CPU キューの廃棄カウントが増大している場合は、そのキューの使用頻度が高いことを意味します。
CPU 受信キュー廃棄カウントを確認し、パケットの廃棄カウントの多いキューを特定するには、 show platform port-asic stats drop 特権 EXEC コマンドを入力します。このコマンドが show controllers cpu-interface コマンドほど有用ではないのは、出力に受信キューの名前ではなく番号が表示され、廃棄数しか示されないためです。スーパーバイザに送信された CPU 受信キューのドロップ パケットはスイッチ ハードウェアで確認されるため、ドロップ パケットは、コマンド出力では Supervisor TxQueue Drop Statistics と呼ばれています。
この出力の Supervisor TxQueue Drop Statistics のキュー番号の順序は、 show controllers cpu-interface コマンド出力のキュー名の順序と同じです。たとえば、この出力の Queue 0 は、前の出力の rpc に対応しています。 Queue 15 は cpu heartbeat に対応しています。以下も同様です。
統計情報はリセットされません。アクティブなキュー廃棄を確認するには、このコマンドを何回か入力します。コマンド出力では、他のドロップ統計情報も表示されますが、例では、その一部が省略されています。
CPU キューの詳細については、「CPU 受信キュー」を参照してください。
スイッチ CPU 受信キューからのパケットのデバッグ
ネットワークから受信したパケットは、CPU の 16 個の異なるキューに格納されます。CPU に送信されたパケットを特定するには、キューのデバッグをイネーブルにします。 show controllers cpu-interface 特権 EXEC コマンドの出力を使用して、最初にデバッグを開始するキューを確認します。「CPU 受信キューのパケット カウントのモニタリング」を参照してください。
show controllers cpu-interface コマンドの出力では、どのキューから開始してよいかわからない場合は、コンソールにデバッグ メッセージが数多く表示されるまで 1 つずつキューのデバッグをイネーブルにすることをお勧めします。CPU 受信キューごとにデバッグをオン/オフにするには、別々に debug コマンドを使用します。
受信キューのデバッグを開始する前に、次の手順に従って、他のアプリケーションからコンソールに出力されないようにし、システム ログ バッファを拡大（デフォルトのサイズの場合）して、デバッグ メッセージに詳細なタイムスタンプが出力されるよう設定します。デバッグ セッションが完了すると、デバッグ メッセージがシステム ログに記録されています。
特権 EXEC モードから始め、次の手順に従って CPU キューのデバッグの準備を整えます。
これで、 undebug all 特権 EXEC コマンドを入力して、コンソールのパケット フラッディングを停止できます。コマンド プロンプトが表示されていなくても、 undebug all コマンドはいつでも使用できます。コマンドを入力した後、バッファに格納されたデバッグ メッセージが処理され、デバッグ メッセージ バッファが空になるまでに少し時間がかかります。
デバッグ メッセージにより、パケット フラッディングの原因を特定できます。この方法は、パケットがすべて同じタイプになっている場合や同じ送信元から発信されている場合に役に立ちます。
次の例では、コンソールにメッセージが大量に表示されるまで CPU キューを 1 つずつオンにしています。
• debug platform cpu-queue host-q コマンドが入力された後に、1 つのパケットが受信されました。これは正常です。
• 次のコマンド debug platform cpu-queue icmp-q が入力されたときに、フラッディングが始まりました。icmp-q で受信したパケットはすべて同じものです。3 つのパケットのみが表示されます。したがって、CPU では、ICMP パケットの受信でフラッディングが発生しています。
• このパケットの VLAN（200）および送信元 MAC アドレス（0000.0300.0101）（太字表示）を含む、送信元について出力を調べます。
• VLAN に対して show mac address-table 特権 EXEC コマンドを入力して、MAC アドレス テーブルを参照し、この MAC アドレスを学習したインターフェイスを検索します。この出力では、ギガビット イーサネット 1/0/3 インターフェイス（太字表示）でパケットが受信されていることを示しています。
1 つのフローが CPU のフラッディングの原因となっている場合は、さまざまなパケット タイプに対してこうした手順を実行できます。コンソールにメッセージが大量に表示されるまで、さまざまな CPU キューのデバッグをイネーブルにし続けます。CPU キューの詳細については、「CPU 受信キュー」を参照してください。
特権 EXEC モードから始め、次の手順に従ってシステム ログのデバッグ メッセージを表示します。
（注） デバッグする前にシステム ログ バッファの拡大またはタイムスタンプの追加によってコンフィギュレーションを変更した場合は、デバッグが完了したら、こうした設定をデフォルトのコンフィギュレーションに戻すことを考慮してください。
IP トラフィック カウントのモニタリング
CPU で受信した IP パケット タイプはすべてカウントされます。こうしたパケット カウントには、ハードウェアでスイッチングまたはルーティングされた IP パケットは含まれません。IP パケット タイプのカウントを表示するには、 show ip traffic 特権 EXEC コマンドを入力します。この出力では、IP パケットがレイヤ 4 タイプ（ICMP、マルチキャスト、ICMP、ARP）に分類されます。特定のカウントが急増している場合は、その IP パケット タイプが CPU のフラッディングの原因となっていると考えられます。
CPU へのネットワーク パケットの制限
問題のあるネットワーク パケットによる影響が CPU 使用率に及ばないようにするには、そうしたパケットを入力インターフェイスで阻止します。
• イーサネット ブロードキャストまたはマルチキャスト パケット ストームを制限するには、 storm-control { broadcast | multicast | unicast } level { level [ level-low ] | bps bps [ bps-low ] | pps pps [ pps-low ]} インターフェイス レベル コンフィギュレーション コマンドを使用します。スイッチのソフトウェア コンフィギュレーション ガイドの「Configuring Port-Based Traffic Control」の章を参照してください。
• CPU 使用率が高くなる根本的な原因がレイヤ 2 のループにある場合は、スパニングツリー コンフィギュレーションが問題となっている可能性があります。スイッチのソフトウェア コンフィギュレーション ガイドの「Configuring STP」の章を参照してください。
• トラフィック ポリシングにより、スイッチに入力されるパケット数を制限できます。ポリシングでは、入力トラフィックの拒否、指定ビット/秒レートへの入力トラフィックの制限、一部のトラフィックの許可と同時に他のトラフィックの制限を実施することができます。MAC アドレス、IPv4 ヘッダー、IPv6 ヘッダー（スイッチで IPv6 がサポートされている場合）、またはレイヤ 4 ポート番号でトラフィックをポリシングできます。スイッチのソフトウェア コンフィギュレーション ガイドの「Configuring Network Security with ACLs」、「Configuring IPv6 ACLs」（スイッチでサポートされている場合）、および「Configuring QoS」の章を参照してください。
• レイヤ 3 スイッチの CPU 使用率に IP ARP パケットによる影響が及ばないようにするには、Dynamic ARP Inspection（DAI; ダイナミック ARP インスペクション）を設定し、 ip arp inspection limit { rate pps [ burst interval seconds ] | none } インターフェイス コンフィギュレーション コマンドを入力して、レート制限機能を使用します。スイッチのソフトウェア コンフィギュレーション ガイドの「Configuring Dynamic ARP Inspection」の章を参照してください。
スイッチ ハードウェアからパントされたパケットの特定
通常のレイヤ 3 スイッチの動作の一環として、スイッチ ハードウェアに IP ルートがプログラミングされていない場合は、IP ルーティングに備えて IP パケットが CPU にパントされます。IP パケットが不定期に CPU にパントされることは正常であり予想の範囲ですが、パントされる IP パケットが多すぎる場合は、CPU が過度にビジー状態になっています。
IP ルーティングに備えて CPU にパントされる IP パケットはすべてカウントされます。各 CPU 受信キューに格納されるパケット数を確認するには、 show controllers cpu 特権 EXEC コマンドを使用します。スイッチ ハードウェアでパケットがパントされているときは、 sw forwarding という名前の行のカウントが増えていきます。 sw forwarding のカウントが急増しているかどうかを確認するには、このコマンドを何回か入力します。
また、 show platform ip unicast statistics 特権 EXEC コマンドを使用して、同様にパント パケットに関する情報を表示することもできます。パント IP パケットは、 CPUAdj （この例の太字表示）としてカウントされます。
こうした統計情報は 2 ～ 3 秒ごとに更新されます。 CPUAdj カウントの変化を確認するには、このコマンドを何回か入力します。 CPUAdj カウントが急増している場合は、IP ルーティングに備えて多くの IP パケットが CPU に転送されています。
TCAM 使用率に関する問題の特定
レイヤ 3 スイッチでは、TCAM を使用して IP ルーティング データベースが格納されます。レイヤ 3 ルーティング情報用の TCAM スペースは限られています。このスペースが満杯になると、Cisco IOS で学習した新たなルートを TCAM にプログラミングできなくなります。スイッチ ハードウェアで受信した IP パケットの宛先 IP アドレスが TCAM に存在しない場合、その IP パケットは CPU に パント されます。
TCAM が満杯かどうかを確認するには、 show platform tcam utilization 特権 EXEC コマンドを入力します。
この例では、最大値 2048 に対して 2047 を使用中と表示されていますが、 IP indirectly-connected routes リソースは満杯です。スイッチの TCAM が満杯の場合は、TCAM に存在する宛先 IP アドレスのパケットのみがルーティングされます。TCAM に宛先が存在しない他のすべての IP パケットは、CPU にパントされます。 show controllers cpu-interface コマンドの出力から、TCAM が満杯で sw forwarding カウントが増大している場合は、パント パケットが CPU 使用率が高くなる原因になっているということです。
Cisco IOS では、ルーティング プロトコル（BGP、RIP、OSPF、EIGRP、IS-IS など）から、また静的に設定されたルートから、ルートについて学習します。 show platform ip unicast counts 特権 EXEC コマンドを入力すると、こうしたルートのうち TCAM に正しくプログラミングされていないルートの数を確認できます。
この出力では 693 個のエラーが示されています。この統計情報を使用して、この時点でネットワーク内のアドバタイズされているルートを保持するのにさらに必要な TCAM リソースの数を確認できます。
各ルーティング プロトコルで使用されたルート エントリの数を表示するには、 show ip route summary 特権 EXEC コマンドを入力します。
SDM テンプレートの変更
Switch Database Management（SDM; スイッチ データベース管理）テンプレートにより、限られた TCAM リソースがさまざまな転送タイプに割り当てられます。TCAM 使用率に関する問題を解決するには、スイッチ アプリケーション用の適切な SDM テンプレートを選択する必要があります。
スイッチのアクティブな SDM テンプレートを確認するには、 show sdm prefer 特権 EXEC コマンドを入力します。
このスイッチのデフォルトのテンプレートでは、TCAM 内の 2048 個の間接レイヤ 3 ルートしか許可されていません。さらに TCAM リソースを間接レイヤ 3 ルートに割り当てるには、他の TCAM リソースをいくつか削減する必要があります。IP ルーティングに備えてより多くのリソースを確保するテンプレートに変更するには、 sdm prefer template-name グローバル コンフィギュレーション コマンドを使用します。
スイッチに使用可能な SDM テンプレートのリストを確認するには、 show sdm templates all 特権 EXEC コマンドを入力します。
（注） スイッチで使用可能なテンプレートおよび各テンプレートの予約 TCAM リソースを確認するには、スイッチのソフトウェア コンフィギュレーション ガイドの「Configuring SDM Templates」の章を参照してください。
IP ルートの最適化
レイヤ 3 スイッチの SDM テンプレートの変更が不可能な場合や現実的でない場合は、集約ルートを使用するかルートをフィルタリングすることによって、TCAM 内のルートの数を減らすことができます。
集約ルートを使用すると、ルーティング テーブル サイズが小さくなります。ピア ルータで集約ルートをイネーブルにします。集約ルートは、RIP および EIGRP のデフォルトではイネーブルになっており、OSPF のデフォルトではディセーブルになっています。集約ルートの詳細については、ソフトウェア コンフィギュレーション ガイドの「Configuring IP Unicast Routing」の章を参照してください（レイヤ 3 スイッチのみ）。
ルート フィルタリングを使用すると、不要なルートが TCAM にプログラミングされないようにすることができます。OSPF ルート フィルタリングの詳細については、次の URL にある機能ガイドを参照してください。
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/routmap.html
アクティブなプロセスのデバッグ
CPU 使用率の割合が高く、割り込みの割合が低い場合、CPU 使用率が高くなる原因は、CPU リソースを消費する 1 つ以上のシステム プロセスにあります。この状況は、CPU 使用率が高いことがネットワーク パケットの受信に起因する場合ほど一般的ではありません。システム プロセスが CPU リソースの大半を消費している場合、通常は、イベントからのトリガーによってそのプロセスがアクティブになっています。異常なイベントが発生していないか syslog を確認します。
表 3 に、CPU リソースの消費の割合が正常なプロセスと高いプロセスの例、それに対して考えられる根本的な原因、および推奨措置を示します。
短期間にスイッチで設定した ACL が多すぎます。ACL が自動で（スクリプトから）適用されている場合に、このようになります。 |
||||
| 「SNMP Engine プロセス」を参照してください。 |
||||
SNMP Engine プロセス
SNMP Engine システム プロセスは、スイッチが SNMP クエリーを受信している場合にのみアクティブになります。必要な CPU 時間は、受信した SNMP クエリー パケット数に正比例します。受信した各 SNMP クエリー パケットは、SNMP Engine システム プロセスに転送される前に割り込みレベルで処理されます。SNMP Engine プロセスがビジー状態の場合、 show processes cpu sorted コマンドの出力に表示される割り込みの割合の中には、ゼロでない割り込みの割合もいくつか含まれます。割り込みの割合は、SNMP Engine システム プロセスによって利用される CPU の割合と比べるとわずかです。
SNMP Engine システム プロセスの CPU 使用率を評価する場合は、スイッチの基準 CPU 使用率を特定することが重要です。通常は、スイッチが一定の時間間隔で SNMP クエリーを受信し、SNMP Engine システム プロセスがクエリーの処理に CPU リソースを消費します。この間隔は、 show processes cpu history コマンドの出力に表示されます。「CPU 使用率が高いことが問題となっている場合」の例を参照してください。
次のような場合には、SNMP Engine システム プロセスが原因で CPU 使用率が非常に高くなることがあります。
• スイッチでのフラッシュ ファイル システムの SNMP クエリー。フラッシュ ファイルへのアクセスは、SNMP Gets または SNMP GetNext 操作を目的とした CPU 中心の操作です。
役立つ情報
CPU 受信キュー
スイッチ ハードウェアで CPU に送信されるパケットは、パケット タイプに応じて 16 個の CPU キューのいずれかに格納されます。各キューは優先順位が設定されているので、優先順位の低いキューよりも先に優先順位の高いキューに格納されます。各キューには、キューに応じたパケットを保持するためにハードウェアでメモリが確保されているため、1 つのキューまたはパケット タイプで使用可能なすべてのメモリを使用できるわけではありません。
• rpc：リモート プロシージャ コール。シスコのシステム プロセスでスタック間通信に使用されます。
• stp：スパニングツリー プロトコル。独自のキューを備えたレイヤ 2 プロトコル。
• ipc：プロセス間通信。シスコのシステム プロセスでスタック間通信に使用されます。
• routing protocol：他のネットワーク デバイスで受信されるルーティング プロトコル パケットに使用されます。
• L2 protocol：LACP、UDLD などのプロトコル パケットに使用されます。
• remote console：スタック マスター スイッチで session switch-number 特権 EXEC コマンドを入力して別のスイッチ メンバーのコンソールを開くときのパケットに使用されます。
• sw forwarding：ルーティングするために CPU のハードウェアでパントされるパケットに使用されます。
• host：宛先 IP アドレスが任意のスイッチ IP アドレスと一致するパケットに使用されます。IP ブロードキャスト パケットにも使用されます。
• broadcast：レイヤ 2 ブロードキャスト パケットを受信します。
• cbt-to-spt：PIM_SM のマルチキャスト パケットを受信します。
• igmp snooping：IGMP パケットのキュー。
• logging：ACL ロギング用にハードウェアで生成されたパケットの受信に使用されます。
• rpf fail：リバース パス フォワーディング障害用のキュー。
CPU トラブルシューティングに使用されるコマンド
その他のドキュメント
Cisco.com にある別のドキュメントでは、Catalyst 3750 スイッチでの使用率が高いことに関する特定の問題に重点を置いています。ただし、その内容は他のスイッチにも当てはまります。『 Catalyst 3750 Series Switches High CPU Utilization Troubleshooting 』を参照してください。
マニュアルの入手方法およびテクニカル サポート
マニュアルの入手方法、テクニカル サポート、その他の有用な情報について、次の URL で、毎月更新される『 What's New in Cisco Product Documentation 』を参照してください。シスコの新規および改訂版の技術マニュアルの一覧も示されています。
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
『 What's New in Cisco Product Documentation 』は RSS フィードとして購読できます。また、リーダー アプリケーションを使用してコンテンツがデスクトップに直接配信されるように設定することもできます。RSS フィードは無料のサービスです。シスコは現在、RSS バージョン 2.0 をサポートしています。
フィードバック