高CPUと基本的なトラブルシューティングについて

About High Cpu Basic Troubleshooting

実際のネットワークでは、デバイスのCPUは常に高くなります。この場合、CPUが高い状態が続くと、デバイスのパフォーマンスが低下し、デバイスがダウンする可能性があるため、ネットワーク管理者はしばしば心配します。 。

このレコードは主に、高CPUとトラブルシューティング方法に関する基本的な知識を記録します。



1.高CPUについて

デバイスが起動すると、CPUには2つの異なる機能があります。1つはIOSでさまざまなプロセスを実行すること、もう1つは処理のためにスイッチングハードウェアからパケットを送受信することです。 CPUは両方の機能を同時に実行します。

IOSプロセスがCPUを大量に使用する場合でも、CPUがハードウェアから受信するパケットが多すぎる場合でも、CPUがハイになり、2つは相互に影響します。たとえば、CPUが多数の受信パケットの処理でビジー状態の場合、IOSプロセスがCPUリソースにアクセスできない可能性があります。

通常の状況下で、一部の非スタックスイッチでは、CPUに特定のベースライン使用率があります。デバイスのモデルとタイプに応じて、この範囲は5%から40%の範囲になります(デバイス設計の違い)。スイッチがスタックされている場合、CPUは通常の動作の少なくとも数パーセントポイントになる可能性があります。スタック内のメンバーの数は、全体的なCPU使用率に影響します。スタックスイッチでは、CPU使用率はマスタースイッチにのみ反映されます。さらに、バックグラウンドで複数のIOSを実行すると、1秒間に複数回実行されるため、スイッチは0%のCPU使用率を報告しません。

異なる範囲とそれらの範囲内のモデルがベースライン使用率で異なる理由の1つは、設計の違いです。マイクロコントローラをほとんど使用しないスイッチの初期のモデルでは、後のモデルはこれらをより多く利用します。より多くのタスクがこれらのマイクロコントローラーにオフロードされるにつれて、CPUとマイクロコントローラー間の通信が増加します。これが報告されるプロセスは次のとおりです。HULC主導そしてそのRedearth Tx aRxプロセス

show processs cpu sortedコマンドを使用すると、過去5秒間、1分間、および5分間にCPUがどれだけビジーであったかを確認できます。また、各システムプロセスによって使用されているCPUの割合を確認することもできます。

スイッチ# ソートされたプロセスのCPUを表示

5秒間のCPU使用率: 5%/0%1分:6%5分:5% PIDランタイム(ミリ秒)呼び出されたuSecs 5Sec 1Min 5MinTTYプロセス 1 4539 89782 50 0.00%0.00%0.00%0チャンクマネージャー 2 1042 1533829 0 0.00%0.00%0.00%0ロードメーター 3 0 1 0 0.00%0.00%0.00%0 DiagCard3 / -1 4 14470573 1165502 12415 0.00%0.13%0.16%0ヒープを確認します 5 7596 212393 35 0.00%0.00%0.00%0プールマネージャー 6 0 2 0 0.00%0.00%0.00%0タイマー 7 0 1 0 0.00%0.00%0.00%0画像ライセンス 8 0 2 0 0.00%0.00%0.00%0ライセンスクライアントN 9 1442263 25601 56336 0.00%0.08%0.02%0ライセンス自動U 10 0 1 0 0.00%0.00%0.00%0クラッシュライター 11 979720 2315501 423 0.00%0.00%0.00%0ARP入力 12 0 1 0 0.00%0.00%0.00%0 CEF MIB API 上記の出力例のように、過去5秒間のCPU使用率は2パーセント(5%/ 0%)です。
5%-最後の5秒間にビジー状態をCPUに通知します。これは、割り込みレベルのパーセンテージを含む、アクティブなシステムプロセスの合計CPU使用率です。
0%-過去5秒間の割り込みレベルの占有率を反映します。割り込みパーセンテージは、スイッチハードウェアから受信したデータパケットにCPUによって費やされます。パーセンテージは常に合計CPU使用率以下です 2.高いCPUを識別して判断します 2.1通常の高CPU
場合によっては、通常の高CPUがネットワークに影響を与えません。 show processs cpu historyを使用して、過去60秒、60分、および72時間のCPU使用率を表示できます。 CPU使用率、および緊急事態が発生しているかどうかを確認できます。
いくつかの例では、CPUスパイクは、「書き込みメモリ」、「大規模なL2ネットワーク」トポロジの変更、「IPルーティングテーブルの更新」、「その他のIOSコマンド」などの既知のネットワークイベントである可能性があります。
  • 大規模なL2ネットワークのトポロジの変更:STPの計算では、インスタンスが多いほど、アクティブなインターフェイスが表示される可能性が高くなります。
  • IPルーティングテーブルの更新:更新されたルーティングテーブルが大きいほど、サイクルの頻度が高くなり、更新を受信するルーティングプロトコルプロセスの数、ルートマップまたはフィルタなどが原因である可能性があります。
  • IOSコマンド:show tech、write memory、show-running configuration、debug、その他のコマンド
  • その他のイベント:
頻繁または多数のIGMP要求、CPUはIGMPメッセージを処理します
多数のIPSLA監視セッションでは、CPUはICMPまたはtracerouteパケットを生成します
SNMPポーリングアクティビティ、特にMIBウォーク、Cisco IOSSNMPエンジンはSNMP要求を実行します
多数の同時DHCP要求
ARPブロードキャストストーム
イーサネットブロードキャストストーム。

2.2高いCPUによって引き起こされる症状

CPUが高いと、システムプロセスの通常の動作に影響します。システムプロセスが実行されていない場合、スイッチまたは直接接続されたネットワークデバイスはネットワークの問題を反映します。 L2ネットワークの場合、STPの再コンバージェンスが発生する可能性があり、L3ネットワークの場合、ルーティングトポロジが変更される可能性があります。

スイッチのCPUが高いときに発生する可能性のある既知の症状:
2.2.1。 STPトポの変更:レイヤ2ネットワークデバイスがRPでSTP BPDUを時間内に受信しない場合、ルートスイッチのレイヤ2パスをダウンとして扱い、スイッチは新しいパスを見つけようとします。その後、STPはコンバージェンスを再開します。
2.2.2、ルーティングトポの変更:たとえば、BGPルートフラッピングまたはOSPFルートフラッピング。
2.2.3、EtherChannelリンクのリバウンド:EtherChannelのもう一方の端にあるネットワークデバイスが、EtherChannelリンクを維持するために必要なプロトコルデータパケットを受信しない場合、リンクが切断される可能性があります。 2.2.4。スイッチは通常の管理要求に応答できません。
  • ICMPping要求
  • SNMPタイムアウト
  • TelnetまたはSSHセッションが遅いか、確立できない
  • UDLDフラッピング
  • IPSLAの障害
  • DHCPまたは802.1xの障害
  • パケット損失または遅延の増加
  • HSRPフラッピング

2.3中断の割合の決定

CPU使用率の履歴には、時間の経過とともに変化する合計CPU使用率のみが表示されます。割り込みに費やされたCPU時間は表示されません。 CPU使用率の原因を特定するには、割り込みにかかる時間を理解することが重要です。 CPU使用率の履歴には、CPUがネットワークパケットを受信し続けるタイミングが表示されますが、理由は表示されません。

CiscoIOSデバイスを入力してください現在のCPU使用率と、どのIOSプロセスが最もCPU時間を占有しているかを表示するには、show processes cpu sorted5secコマンドを入力します。。通常、中断率は0%より大きく5%未満です。中断率は5%から10%の間です。 10%を超える中断の割合を調査する必要があります。

3.根本原因を特定します 出力例として、スイッチがデータパケットを管理するために使用するシステムプロセスは、CPUにフラッディングするネットワークパケットのタイプを識別できます。 CPU割り込みの割合が比較的高い場合は、show services cpu sorted 5secコマンドを入力して、最もアクティブなプロセスを確認します。出力には、最初に最もアクティブなプロセスが一覧表示されます。Switch# 5秒でソートされたプロセスのCPUを表示 5秒間のCPU使用率:64%/ 19%1分:65%5分:70% PIDランタイム(ミリ秒)呼び出されたuSecs 5Sec 1Min 5MinTTYプロセス 186 19472027 64796535 300 35.14%37.50%36.05%0IP入力 192 24538871 82738840 296 1.11%0.71%0.82%0スパニングツリー 458 5514 492 11207 0.63%0.15%0.63%2 Virtual Exec 61 3872439 169098902 22 0.63%0.63%0.41%0 RedEarth Tx Mana 99 10237319 12680120807 0.47%0.66%0.59%0hpmカウンター手順 131 4232087 224923936 18 0.31%0.50%1.74%0ハルクLEDプロセス 152 2032186 7964290 255 0.31%0.21%0.25%0 PIMATMエージングPr 140 22911628 12784253 1792 0.31%0.23%0.26%0 HRPCqosリクエスト 250 27807274 62859001 442 0.31%0.34%0.34%0RIPルーター 表1に、いくつかの一般的なシステムプロセスと関連するパケットタイプを示します。リストされたシステムプロセスの1つがCPUで最もアクティブなプロセスである場合、対応するタイプのネットワークパケットがCPUをフラッディングする可能性があります。

レイヤ3スイッチでは、IPルートが不明な場合、スイッチハードウェアはIPルーティングのためにIPパケットをCPUに送信します。送信されたパケットは割り込みレベルで処理され、CPUがビジー状態になります。コマンド出力に表示される割り込みの割合が高いが、最もアクティブなプロセスが上記の表に示されているものではない場合、またはCPU使用率を証明するのに十分な効果のあるプロセスがない場合は、CPU使用率が高いことが原因である可能性があります。サンプル出力に示されているCPUのデータパケットが原因です。

スイッチ# 5秒でソートされたプロセスのCPUを表示

5秒間のCPU使用率:53%/28%1分:48%5分:45% PIDランタイム(ミリ秒)呼び出されたuSecs 5Sec 1Min 5MinTTYプロセス 78 461805 220334990 2 11.82%11.53%10.37%0HLFMアドレスリー 309 99769798 1821129 54784 5.27%1.53%1.39%0RIPタイマー 192 19448090 72206697 269 1.11%0.87%0.81%0スパニングツリー 250 25992246 58973371 440 0.63%0.27%0.29%0RIPルーター 99 6853074 11856895 577 0.31%0.46%0.44%0hpmカウンター手順 131 3184794 210112491 15 0.31%0.13%0.12%0ハルクLEDプロセス 140 20821662 11950171 1742 0.31%0.28%0.26%0 HRPCqosリクエスト 139 3166446 1498429 2113 0.15%0.11%0.11%0HQMスタックプロセス 67 2809714 11642483 241 0.15%0.03%0.00%0 hrpc<- response 223 449344 16515401 27 0.15%0.03%0.00%0 Marvell wk-a Pow 10 0 1 0 0.00%0.00%0.00%0クラッシュライター 11 227226 666257 341 0.00%0.00%0.00%0ARP入力 !表2に、CPUがCPUに送信されたデータパケットの処理でビジー状態のときに最もアクティブなシステムプロセスを示します。パンチされたパケットのCPUプロセスは、リストされているプロセスとは関係ありません。

CPU受信キューのパケット数を監視します

スイッチが特定のパケットタイプでフラッディングされた場合、ハードウェアはパケットタイプを適切なCPUキューに入れ、それをカウントします。各キューのパケット数を表示するには、show controllerscpu-interfaceコマンドを入力します。

スイッチ#show controllerscpu-interface

ASIC Rxbiterr Rxunder Fwdctfix Txbuflos Rxbufloc Rxbufdrain -------------------------------------------------- ----------------------- ASIC0 0 0 0 0 0 0 ASIC1 0 0 0 0 0 0 取得されたcpu-queue-framesは、無効なhol-block迷子をドロップしました ----------------- ---------- ---------- ---------- --- ------- ---------- rpc 726325 0 0 0 0 お願いします161080 0 0 0 ipc 56771 0 0 0 0 ルーティングプロトコル39490 0 0 0 L2プロトコル8270 0 0 0 リモートコンソール580 0 0 0 sw転送00 0 0 0 ホスト00 0 0 0 放送3820 0 0 0 cbt-to-spt 0 0 0 0 0 igmpスヌーピング35670 0 0 0 icmp 11256 0 0 0 0 ロギング00 0 0 0 rpf-fail 0 0 0 0 0 dstats 0 0 0 0 0 CPUハートビート3224090 0 0 0 スイッチは、輻輳が原因でドロップされたCPUバウンドパケットも計算します。各CPU受信キューには、最大パケット数があります。受信キューの最大値に達すると、スイッチハードウェアは輻輳キューに送信されたデータパケットをドロップします。スイッチは、キューごとにドロップされたパケットを計算します。特定のCPUキューの廃棄数の増加は、キューの使用率が高いことを意味します。

show platform port-asic stats dropコマンドを入力して、CPU受信キューのドロップカウントを表示し、パケットをドロップしたキューを特定します。このコマンドは、出力に名前ではなく受信キューの番号が表示され、破棄されたもののみが表示されるため、show controllerscpu-interfaceコマンドほど有用ではありません。スイッチハードウェアは、CPU受信キューによってドロップされたパケットをハイパーバイザーに送信されたものとして扱うため、ドロップされたパケットは、コマンド出力ではスーパーバイザTxQueueドロップ統計と呼ばれます。スイッチ# プラットフォームのポートを表示-ASIC統計のドロップ Port-asicポートドロップ統計-要約 ======================================== RxQueueドロップ統計Slice0 RxQueue 0ドロップ統計スライス0:0 RxQueue 1ドロップ統計スライス0:0 RxQueue 2ドロップ統計スライス0:0 RxQueue 3ドロップ統計スライス0:0 RxQueueドロップ統計スライス1 RxQueue 0ドロップ統計スライス1:0 RxQueue 1ドロップ統計スライス1:0 RxQueue 2ドロップ統計スライス1:0 RxQueue 3ドロップ統計スライス1:0 ポート27TxQueueドロップ統計:0 スーパーバイザTxQueueドロップ統計 キュー0:0 キュー1:0 キュー2:0 キュー3:0 キュー4:0 キュー5:0 キュー6:0 キュー7:0 キュー8:0 キュー9:0 キュー10:0 キュー11:0 キュー12:0 キュー13:0 キュー14:0 キュー15:0 ! Supervisor TxQueue Drop Statisticsのこの出力のキュー番号は、show controllerscpu-interfaceコマンドの出力のキュー名と同じ順序です。たとえば、この出力のキュー0は、前の出力のrpcに対応します。キュー15はCPUハートビートなどに対応します。

統計はリセットされません。コマンドを複数回入力して、アクティブなキュードロップを表示します。コマンド出力には、他の廃棄統計も表示されます。この例では、一部が切り捨てられています。その他の補助コマンド:A。showplatform ip unicast statisticsを使用して、送信されたパケットに関する同じ情報を表示することもできます。送信されたIPパケットはCPUAdjとしてカウントされ、この例では太字で示されています。スイッチ#プラットフォームIPユニキャスト統計情報を表示 グローバル統計: HWFwdLoc:0 HWFwdSec:0 UnRes:0 UnSup:0 NoAdj:0 EncapFail:0 CPUAdj:1344291253 Null:0ドロップ:0 前のグローバル統計: HWFwdLoc:0 HWFwdSec:0 UnRes:0 UnSup:0 NoAdj:0 EncapFail:0 CPUAdj:1344291253 Null:0ドロップ:0これらの統計は、2〜3秒ごとに更新されます。コマンドを複数回入力して、CPUAdjカウントの変更を表示します。CPUAdjカウントが急速に増加すると、IPルーティングのために多くのIPパケットがCPUに転送されます。 B.レイヤ3スイッチでは、ハードウェアはTCAMを使用してIPルーティングデータベースを格納します。レイヤ3ルーティング情報用のTCAMスペースは限られています。このスペースがいっぱいになると、CiscoIOSによって学習された新しいルートをTCAMにプログラムできなくなります。スイッチハードウェアが受信したIPパケットのターゲットIPアドレスがTCAMにない場合、ハードウェアはIPパケットをCPUに送信します。 スイッチ#プラットフォームのtcam使用率を表示 ASIC#0のCAM使用率最大使用量 マスク/値マスク/値 ユニキャストMACアドレス:6364/6364 31/31 IPv4 IGMPグループ+マルチキャストルート:1120/1120 1/1 IPv4ユニキャスト直接接続ルート:6144/6144 4/4 IPv4ユニキャスト間接接続ルート:2048/2048 2047/2047 IPv4ポリシーベースのルーティングエース:452/452 12/12 IPv4のQoSエース:512/512 21/21 IPv4セキュリティエース:964/964 30/30 注:機能ごとのTCAMエントリの割り当ては使用します 複雑なアルゴリズム。上記の情報は 現在のTCAM使用率の抽象的なビューを提供しますCisco IOSは、ルーティングプロトコル(BGP、RIP、OSPF、EIGRP、IS-ISなど)および静的に設定されたルートからルートを学習します。show platform ip unicast countsコマンドを入力して、これらのルートのうち、TCAMに適切にプログラムされていないものがいくつあるかを確認できます。 Switch#show platform ip unicast counts HL3Uフィブの数2426 HL3U adjs4の数 HL3Umpathの数0 HL3Uカバーの数-fibs0 形容詞の失敗を伴うHL3Uフィブの数0 プレフィックス長0のFibs、TCAMの失敗:0 プレフィックス長1のFibs、TCAMの失敗:0 TCAMが失敗したプレフィックス長2のFibs:0 プレフィックス長3のFibs、TCAMの失敗:0 プレフィックス長4のFibs、TCAMの失敗:0 プレフィックス長5のFibs、TCAMの失敗:0 プレフィックス長6のFibs、TCAMの失敗:0 プレフィックス長7のFibs、TCAMの失敗:0 プレフィックス長8のFibs、TCAMの失敗:0 プレフィックス長9のFibs、TCAMの失敗:0 プレフィックス長10のFibs、TCAMの失敗:0 プレフィックス長11のFibs、TCAMの失敗:0 プレフィックス長12のFibs、TCAMの失敗:0 プレフィックス長13のFibs、TCAMの失敗:0 プレフィックス長14のFibs、TCAMの失敗:0 プレフィックス長15のFibs、TCAMの失敗:0 プレフィックス長16のFibs、TCAMの失敗:0 プレフィックス長17のFibs、TCAMの失敗:0 プレフィックス長18のFibs、TCAMの失敗:0 プレフィックス長19のFibs、TCAMの失敗:0 プレフィックス長20のFibs、TCAMの失敗:0 プレフィックス長21のFibs、TCAMの失敗:0 プレフィックス長22のFibs、TCAMの失敗:0 プレフィックス長23のFibs、TCAMの失敗:0 プレフィックス長24のFib、TCAMの失敗:0 プレフィックス長25のFibs、TCAMの失敗:0 プレフィックス長26のFibs、TCAMの失敗:0 プレフィックス長27のFibs、TCAMの失敗:0 プレフィックス長28のFibs、TCAMの失敗:0 プレフィックス長29のFibs、TCAMの失敗:0 プレフィックス長30のFibs、TCAMの失敗:0 プレフィックス長31のFibs、TCAMの失敗:0 プレフィックス長32のFibs、TCAMの失敗:693 プレフィックス長33のFibs、TCAMの失敗:0各ルーティングプロトコルで使用されるルーティングエントリの数を表示するには、show ip routesummaryコマンドを入力します。 スイッチ# show ip route summary IPルーティングテーブル名はDefault-IP-Routing-Table(0)です。 IPルーティングテーブルの最大パスは32です ルートソースネットワークサブネットオーバーヘッドメモリ(バイト) 接続済み50 320 760 静的00 0 0 リップ02390 152960 363280 内部11172 合計62390153280365212 Switch#リファレンス:https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/troubleshooting/cpu_util.html#pgfId-999591