利用率 99 % で動作する VIP CPU および Rx サイド バッファリングについて
目次
概要
このドキュメントでは、Versatile Interface Processor（VIP）CPU が 99 %で動作する理由と、Rx サイド バッファについて説明します。
前提条件
要件
このドキュメントに関する固有の要件はありません。
使用するコンポーネント
このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
背景説明
Rx サイドバッファリングはアウトバウンドインターフェイス時プロセスです発生する:
-
混雑させます。
-
戦略を並べる First In First Out （FIFO; 先入れ先出し）を使用します。
受信 Versatile Interface Processor （VIP）はパケットをすぐに廃棄しません。 その代り、それはバッファが発信インターフェイスに利用できるまでパケットメモリのパケットをバッファリングします。 VIP の種類に基づいて、パケットメモリはスタティックRAM （SRAM）または同期ダイナミックRAM （SDRAM）のどれである場合もあります。
Cisco 7500 シリーズ アーキテクチャの基礎
各インターフェイスプロセッサ（レガシー IP か VIP）は CyBus と呼ばれる高速拡張システムバスへの 1 つの接続を備えています。 Route/Switch Processor （RSP）は 2 CyBuses に接続されます（図を 1）参照して下さい。
図 1 – Cisco 7500 シリーズ アーキテクチャ 
パケットバッファ の タイプ
このセクションはさまざまなパケットバッファ の タイプを記述します。
-
RSP のプロセッサメモリのシステムバッファ
これらのバッファはプロセス交換パケットのために使用されます。 show interfaces （入出力キュー）および show buffers コマンドの出力のこれらのバッファを表示できます。 Cisco 7500 シリーズ ルータは多くのプロセス交換をしてはなりません。 従って、システムバッファに問題があれば、過剰なパケットがプロセス レベルに送信されることを意味します。 これは多くのファクタが原因、である場合もあります（以下を参照）:
-
ブロードキャスト ストーム
-
ルーティング更新を引き起こすネットワークの不安定な状態
-
DoS (Denial of Service) 攻撃
-
ファストスイッチング パスでサポートされない機能（たとえば、X.25）
-
オプションの IP パケット。
余分なプロセス スイッチングを解決する方法の情報に関してはこれらの文書を参照して下さい:
-
-
RSP （MEMD）バッファのパケットメモリ
MEMDサイズは RSP7000、RSP1、RSP2 および RSP4 の 2 MB で固定です。 RSP8 では、MEMD サイズは 8 MB です。 MEMD はブートアップの時にすべてのインターフェイスの間で Online Insertion and Removal （OIR）、microcode reload、最大伝送ユニット （MTU）変更、または Cbus Complex があるとき、配られます。 Cbus Complex に関する詳細については、"%RSP-3-RESTART を引き起こすものにより参照して下さい: cbus complex"?」を参照してください。 MEMD バッファのステータスをチェックする show controllers cbus コマンドを使用できます。
MEMD が割り当てられるとき、これらの構造は作成されます:
-
local free queue （lfreeq） —それは各インターフェイスに割り当てられ、このインターフェイスで受信されるパケットのために使用されます。
-
global free queue （gfreeq） —それはまた割り当てられ、インターフェイスはいくつかの制限内のそのキューに戻って落ちることができます。
-
送信キュー（txqueue か txq） —それは各インターフェイスに割り当てられ、このインターフェイスを通って出かけるパケットのために使用されます。
-
transmit accumulator （txacc） —それはアウトプットインターフェイス 送信キュー（txqueue）の要素の数を表します。 transmit accumulator （txacc）が transmit limit （txlimit）に匹敵する時、すべてのバッファは解放されます。 txacc が 0 のとき、キューは充満し、より並べて割り当てられません。
-
-
パケットメモリ
VIP で、パケットメモリはから受信されるか、または VIPインターフェイスに送信されるパケットに使用するパケット バッファ（パーティクル）が含まれています。 図 2 パケットフローを表します。
図 2 –パケットフロー
このセクションは Distributed Switching が有効に なる VIP にパケットがスイッチングパスのこの型に続くと Rx サイドバッファリングが通常発生するので、焦点を合わせます。 ここに説明される異なるシナリオは可能性のあるです、:
シナリオ 1： アウトバウンドインターフェイスに輻輳がない時。
-
パケットはポート アダプタ（PA）で受信され、パケット メモリ内のパケット バッファに移されます。
-
VIP がパケットをディストリビューティッドスイッチングができない場合、スイッチング決定を行う RSP にパケットをフォワーディングします。
-
VIP がスイッチング決定を行い、出力インターフェイスが同一 VIP 上にある場合、パケットは出力インターフェイスに送られます。 パケットは cbus を交差させないので「ローカルで VIP で」交換されると言われます。
-
VIP がスイッチング決定を行い、発信インターフェイスが別のスロットにある場合、VIP はパケットを CyBus を経由して発信インターフェイスの txqueue（MEMD 内）にコピーしようとします。
-
その後、パケットは CyBus を経由して出力（V）IP にコピーされ、回線に送信されます。
シナリオ 2： アウトバウンドインターフェイスが混雑する時。
2 つの可能性があります。
-
出力インターフェイスでキューイングが設定されている場合、VIP はパケットを MEMD 内の txqueue に転送し、パケットはキューイング コードによってキューからすぐに取り出されます。
-
RSP ベースのキューイングが設定されている場合、パケットは DRAM 内のシステム バッファにコピーされます。
-
VIP ベースのキューイングが使われている場合、パケットは出力側 VIP の SRAM にコピーされます。
-
-
アウトバウンドインターフェイスのキューイング 戦略が FIFO である場合、インターフェイスはアウトバウンドインターフェイスが混雑するとき）パケットをすぐに廃棄しません（これは普通起こること FIFO とです。 その代り、受信 VIP はいくつかのバッファが発信インターフェイスに再度利用できるまでパケットメモリのパケットをバッファリングします。 これは Rx サイド バッファリングと呼ばれます。
-
Rx サイドバッファリングのステータスをチェックする show controllers vip accumulator コマンドを使用して下さい。 ステータスは示します:
-
アウトプットインターフェイスの数はルータで示します。
-
何パケット VIP にこれらのインターフェイスのための Rx-buffered があるか。
-
VIP に Rx-buffered がなぜあるか。
-
VIP がドロップしたパケットの数、およびその理由
99% CPU稼働率の VIP 実行
Rx サイドバッファリングにより、最終的に VIP が 99% の CPU 利用率で動作します。 VIP は絶えずアウトバウンドインターフェイスの txqueue のステータスを監察し、解放されたバッファがあるとすぐ、txqueue に cbus 上のパケットをコピーします。
Rx バッファリングが発生するとき VIP が 99% で動作するときそれ自体警告する何もありません。 VIP が過負荷になっていないことを意味します。 VIP がより優先度の高いもの（たとえば、スイッチングすべき別のパケット）を受信した場合、高 CPU 稼働率の影響は受けません。
これを説明するためにラボですることができる簡単 な テストはここにあります:
シリアル 2/0/0 に 128 キロビット/秒のクロック レートがあり、行比率でトラフィックを受信します。 トラフィックはシリアル 10/0 にクロック レートが 64 キロビット/秒である、キューイング 戦略は FIFO ですところで切り替えられ。 パケットのドロップのみが行われます。
router#show controller cbus MEMD at 40000000, 8388608 bytes (unused 697376, recarves 6, lost 0) RawQ 48000100, ReturnQ 48000108, EventQ 48000110 BufhdrQ 48000130 (21 items), LovltrQ 48000148 (15 items, 2016 bytes) IpcbufQ 48000158 (24 items, 4096 bytes) IpcbufQ_classic 48000150 (8 items, 4096 bytes) 3570 buffer headers (48002000 - 4800FF10) pool0: 8 buffers, 256 bytes, queue 48000138 pool1: 2940 buffers, 1536 bytes, queue 48000140 pool2: 550 buffers, 4512 bytes, queue 48000160 pool3: 4 buffers, 4544 bytes, queue 48000168 slot2: VIP2, hw 2.11, sw 22.20, ccb 5800FF40, cmdq 48000090, vps 8192 software loaded from system IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) ROM Monitor version 122.0 Mx Serial(4), HW Revision 0x3, FW Revision 1.45 Serial2/0/0, applique is V.35 DCE received clockrate 2015232 gfreeq 48000140, lfreeq 480001D0 (1536 bytes) rxlo 4, rxhi 336, rxcurr 16, maxrxcurr 293 txq 48001A00, txacc 48001A02 (value 294), txlimit 294 Serial2/0/1, applique is V.35 DTE received clockrate 246 gfreeq 48000140, lfreeq 480001D8 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48001A08, txacc 48001A0A (value 6), txlimit 6 Serial2/0/2, applique is Universal (cable unattached) received clockrate 246 gfreeq 48000140, lfreeq 480001E0 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48001A10, txacc 48001A12 (value 6), txlimit 6 Serial2/0/3, applique is Universal (cable unattached) received clockrate 246 gfreeq 48000140, lfreeq 480001E8 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48001A18, txacc 48001A1A (value 6), txlimit 6 slot10: FSIP, hw 1.12, sw 20.09, ccb 5800FFC0, cmdq 480000D0, vps 8192 software loaded from system Serial10/0, applique is V.35 DTE gfreeq 48000140, lfreeq 48000208 (1536 bytes) rxlo 4, rxhi 336, rxcurr 1, maxrxcurr 1 txq 48000210, txacc 480000B2 (value 2), txlimit 294 Serial10/1, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000218 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000220, txacc 480000BA (value 6), txlimit 6 Serial10/2, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000228 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000230, txacc 480000C2 (value 6), txlimit 6 Serial10/3, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000238 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000240, txacc 480000CA (value 6), txlimit 6 Serial10/4, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000248 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000250, txacc 480000D2 (value 6), txlimit 6 Serial10/5, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000258 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000260, txacc 480000DA (value 6), txlimit 6 Serial10/6, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000268 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000270, txacc 480000E2 (value 6), txlimit 6 Serial10/7, applique is Universal (cable unattached) gfreeq 48000140, lfreeq 48000278 (1536 bytes) rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 txq 48000280, txacc 480000EA (value 6), txlimit 6 router#
2 つのバッファだけ残されることを値 2 は意味します。 Rx バッファリングは txacc が 4.より小さいとき MEMD のパケットをキューに入れません。
VIP からの show controllers vip 2 tech-support コマンドは 99% CPU で動作することを示します:
router#show controllers vip 2 tech-support show tech-support from Slot 2: ------------------ show version ------------------ Cisco Internetwork Operating System Software IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE SOFTWARE (fc1) Copyright (c) 1986-2000 by cisco Systems, Inc. Compiled Tue 18-Jul-00 22:03 by htseng Image text-base: 0x600108F0, data-base: 0x602E0000 ROM: System Bootstrap, Version 11.1(4934) [pgreenfi 122], INTERIM SOFTWARE VIP-Slot2 uptime is 1 week, 23 hours, 27 minutes System returned to ROM by power-on Running default software cisco VIP2 (R4700) processor (revision 0x02) with 32768K bytes of memory. Processor board ID 00000000 R4700 CPU at 100Mhz, Implementation 33, Rev 1.0, 512KB L2 Cache 4 Serial network interface(s) Configuration register is 0x0 ... ------------------ show process cpu ------------------ CPU utilization for five seconds: 99%/97%; one minute: 70%; five minutes: 69%
VIP は 99% CPU稼働率で 128 キロビット/秒だけ受け取るのに動作します。 これは CPU稼働率がパケットの数 毎秒にリンクされないことを示します。 これは VIP 2 がこれよりもっとたくさんのパケットを交換できるという理由によります。 それは Rx サイドバッファリングのサイン単にです。
どんな Rx サイドバッファリングがするかチェックするために、これらのコマンドを実行して下さい:
router#show controllers vip 2 accumulator
show vip accumulator from Slot 2:
Buffered RX packets by accumulator:
...
Serial10/0:
MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps
No MEMD acc: 544980 in
Limit drops : 2644102 normal pak drops, 80 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
No MEMD buf: 0 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
...
Interface x:
MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps
No MEMD acc: i in
Limit drops : j normal pak drops, k high prec pak drops
Buffer drops : l normal pak drops, m high prec pak drops
No MEMD buf: n in
Limit drops : o normal pak drops, p high prec pak drops
Buffer drops : q normal pak drops, r high prec pak drops
| キー | 説明 |
|---|---|
| a | MEMD 内の txacc のアドレスです。 システム内の各 txacc に 1 つの Rx サイドバッファ キューがあります（最大 4096）。 |
| b | パケットの数 Rx-buffered である。 |
| c | VIP が廃棄したパケットの数。 パケットメモリバッファが十分ある場合、VIP は Rxバッファ トラフィックの 1秒までできます。 しかし、インターフェイスが継続的に輻輳状態にある場合、ドロップを回避することは不可能です。 |
| d | 現在 Rx バッファリングされているパケットの数。 |
| e | 現在 Rx バッファリングされているパーティクルの数。 パケットには複数のパーティクルが含まれる場合があります。 |
| f | VIP メモリが低い時パーティクルの最大数であるソフト制限。 |
| g | いつでも使用できるパーティクルの最大数であるハードな制限。 |
| h | 出力インターフェイスのスピード（kbps）。 |
| i | MEMD で txacc が使用できなかったために Rx バッファリングされたパケットの数。 これは出力キューが混雑したことを意味します（これ以上の解放されたバッファは tx-queue で利用できません）。 この問題へのソリューションはアウトプットインターフェイス 帯域幅を増加することです（もし可能なら）。 |
| j | MEMD acc がないので送信できなかった 7 か 6 以外の IP 優先順位のパケットの数は、およびパーティクルのソフトかハードな制限が達したので廃棄されます。 |
| k | IP 優先順位 6 または 7 のパケットのための j と同じ、しかし（インターネットワークおよびネットワーク）。 |
| l | VIP は Rxバッファにほしいと思う 7 か 6 以外の IP 優先順位の解放されたバッファの欠如によるパケットの数、パケットメモリのドロップ。 Cisco IOS ソフトウェア リリース 12.0(13)S から 12.1(4) 前に、また廃棄されるパケットの数を見る show controller vip [すべて/slot#] packet-memory-drops コマンドを使用し。 この場合、パケット メモリのアップグレードが役立ちます。 |
| m | IP 優先順位 6 または 7 のパケットのための l と同じ、しかし（インターネットワークおよびネットワーク）。 |
| n | MEMDバッファがない試みたり、しかしパケットメモリの不足バッファがそう原因ですることができないので VIP が Rxバッファにパケットの数。 パケットメモリをこの場合アップグレードして下さい。 Cisco IOS ソフトウェア リリース 12.0(13)S から 12.1(4) 前に、またパケットがなぜ廃棄されたか理解する show controllers vip [すべて/slot#] packet-memory-drops コマンドを使用し。 |
| o | MEMDバッファ無しの 6 かソフト（f）かハードな（g）制限が達したので廃棄される 7 以外の IP 優先順位の Rx-buffered パケットの数。 この場合、RSP16 はそれ以上の MEMD メモリ（RSP1、RSP2、RSP4 および RSP7000 のための 2 MB と比較される 8 MB）があるので助けます。 またいくつかのインターフェイスの MTU を（ATM、POS、または FDDI のような）この場合減らすことができます。 これらのインターフェイスに通常 4470 バイト MTU があり、バッファがより大きくなければならないので少数の MEMD バッファは割り当てることができます。 |
| p | IP 優先順位 6 または 7 のパケットのための o と同じ、しかし（インターネットワークおよびネットワーク）。 |
| q | MEMDバッファがないので VIP が Rxバッファに試みる 7 か 6 以外の IP 優先順位のパケットの数は、しかしパケットメモリの不足バッファがそう原因ですることができません。 パケットメモリのアップグレードはこの場合助けます。 Cisco IOS ソフトウェア リリース 12.0(13)S から 12.1(4) 前に、またよりよくパケットがなぜ廃棄されたか理解する show controllers vip [すべて/slot#] packet-memory-drops コマンドを使用し。 |
| r | IP 優先順位 6 または 7 のパケットのための q と同じ、しかし（インターネットワークおよびネットワーク）。 |
ルータが 12.0(13)ST 以前の Cisco IOS ソフトウェア バージョンを実行する場合 12.1(04)DB、12.1(04)DC、12.0(13)S、12.1(4) 12.1(4)AA 12.1(4)T 012.0(13)、または 12.0(13)SC は、show controllers vip [すべて/slot#]アキュムレータの出力上の簡単バージョンを提供します。 それは Rx サイドバッファリングが理由で破棄された パケットの異なる IP 優位を考慮に入れません。
出力は、次のようになります。
Serial10/0: MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps No MEMD acc: 544980 in, 2644182 limit drops, 0 no buffer No MEMD buf: 0 in, 0 limit drops, 0 no buffer Interface x: MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps No MEMD acc: i in, j+k limit drops, l+m no buffer No MEMD buf: n in, o+p limit drops, q+r no buffer
Rx 側のバッファの例
例 1： スロット 2 の VIP は 128Kbps のトラフィックを受信し、シリアル 10/0 （64Kbps）にそれをルーティングします。
Serial10/0:
MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps
No MEMD acc: 544980 in
Limit drops : 2644102 normal pak drops, 80 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
No MEMD buf: 0 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
-
ここでは、544980 のパケットは正常に Rx-buffered であり、2644182 は廃棄されます。 廃棄される 2644182 からの 80 のパケットに 6 か 7.の IP 優先順位がありました。
-
126 のパケットは現在 Rx-buffered であり、378 のパーティクルを使用します。
-
すべてのパケットは MEMD の tx-queue の解放されたバッファの欠如のために Rx-buffered です。 これは、出力インターフェイスが輻輳状態であることを意味します。 ドロップは Rx-buffered パケットの最大数に達するので行われます。 典型的なソリューションはアウトバウンドインターフェイス 帯域幅を、再ルーティングしますトラフィックをアウトバウンドインターフェイスがより少なくアップグレードすること混雑する、またはより少なく重要なトラフィックを廃棄するキューイングをですように有効に すること。
例 2： ドロップのない Rx 側バッファ。
ATM1/0:
MEMD txacc 0x0082: 203504 in, 0 drops (0 paks, 0/81/37968 bufs) 155520kbps
No MEMD acc: 85709 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
No MEMD buf: 117795 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
-
この例では、85709 のパケットは ATM 1/0 が混雑するが、パケットが廃棄されないので Rx-buffered です。
-
117795 のパケットは VIP が MEMDバッファを得ることができないので Rx-buffered です。 パケットは廃棄されません。 典型的なソリューションはより多くの MEMD バッファが割り当てることができるようにいくつかの MTU を減少させることです。 また RSP8 ヘルプ。
例 3： ローカル スイッチング。
SRP0/0/0: local txacc 0x1A02: 2529 in, 0 drops (29 paks, 32/322/151855 bufs) 622000kbps
ローカル txacc はこのアウトプットインターフェイスがパケットが受信されるインターフェイスと同じ VIP にあることを意味します。 これらのパケットはローカルで交換されますが、アウトバウンドインターフェイスは（この場合、SRP 0/0/0）混雑します。 2529 のパケットは Rx-buffered であり、パケットは廃棄されません。
例 4： 前方キュー。
router#show controllers vip 2 accumulator
Buffered RX packets by accumulator:
Forward queue 0 : 142041 in, 3 drops (0 paks, 0/24414/24414 bufs) 100000kbps
No MEMD buf: 142041 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 3 normal pak drops, 0 high prec pak drops
Forward queue 9 : 68 in, 0 drops (0 paks, 0/15/484 bufs) 1984kbps
No MEMD buf: 68 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
Forward queue 13: 414 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps
No MEMD buf: 414 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
Forward queue 14: 46 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps
No MEMD buf: 46 in
Limit drops : 0 normal pak drops, 0 high prec pak drops
Buffer drops : 0 normal pak drops, 0 high prec pak drops
いくつかのパケットは分散スイッチングできません。 この場合、VIP は切り替え決定を作る RSP の rawキューにパケットを転送しなければなりません。 パケットが MEMD にすぐにコピーすることができないとき VIP Rx バッファはそれらインバウンドインターフェイスごとの Rx-buffered は何パケットであるか把握し。
フォワーディング キュー 0～7 は第 1 ポート アダプタ（PA）用、8～15 は第 2 PA 用です。
| フォワーディング キュー番号 | …で…受信される Rx-buffered パケットの数を示します |
|---|---|
| 0 | 1番目の ポート アダプタ（PA）の第 1 プラグホール |
| 8 | 2番目のPA の第 1 プラグホール |
| 9 | 2番目のPA の第 2 プラグホール |
VIP においてCPU 利用率が高い数値を示す他の原因
Rx サイドバッファリングが非アクティブであるために確認されているときこれらのファクタの 1 により VIP の CPU使用率が高い状態を引き起こす場合があります:
-
Distributed Traffic Shaping によって引き起こされる VIP の 99% CPU稼働率
Distributed Traffic Shaping （DTS）が設定されるとき、VIP CPU は 99% に 1 パケットが dTS キューを入力するとすぐ跳びます。
これは正しいおよび予期された動作です。 dTS が設定されるときチェックするために、トラフィックがないとき） CPU が使用中ではないと間隔（Tc）が着く時次に VIP CPU はかどうか回ります（すなわち。 さもなければ、確認は tx/rx 割り込みルーチンで便乗されます。 使用中のときだけ CPU を回します。 従って、パフォーマンスは影響を受けていません。
トークンバケットはであるもの「次のタイムインターバル」が意味するものを理解するために、参照して下さいか。
注: トラフィック シェーピングはシェーピングキューイングのパケットをキューにいれなければならないときだけアクティブになります。 すなわち、トラフィック量がシェーピング速度を超過する時。 これは dTS が設定されるとき VIP CPU が 99% なぜ常にではないか説明します。 dTS に関する詳細については、参照して下さい:
-
にせ の メモリアクセスおよびアラインメント エラーによって引き起こされる VIP の CPU使用率が高い状態
アラインメント エラーおよびにせ の メモリアクセスは VIP をクラッシュする必要なしで Cisco IOSソフトウェアによって解決されるソフトウェア障害です。 これらのエラーが頻繁に現われる場合、それによりオペレーティング システムは CPU使用率が高い状態に導く場合がある多くの修正をします。
アラインメント エラーおよびにせ の メモリアクセスに関する詳細については、トラブルシューティング:スプリアス アクセス、アラインメント エラー、スプリアス割り込みを参照して下さい。
にせ の メモリアクセスおよびアラインメント エラーがあるかどうか点検するために、show alignment コマンドを使用して下さい。 このようにそのようなエラーなの例:
VIP-Slot1#show alignment No alignment data has been recorded. No spurious memory references have been recorded.
CPU使用率が高い状態のその他 の 原因は有効に なる分散機能の量およびエクステントのどれである場合もあります。 これは原因である可能性があることまたはのこの資料で説明される CPU使用率が高い状態のための原因特定できなければ疑えば Cisco Technical Assistance Center （TAC）とのサービス リクエストを開きなさい。
TAC のサービスリクエストをオープンする場合に収集すべき情報
| 上記のトラブルシューティング の 手順に従った、Cisco TAC のサービス リクエスト（登録ユーザのみ）を開きたいと思う後更にアシスタンスを必要としたらこの情報を含むこと確実でであって下さい: |
|---|
注: これが問題の根本的な原因を判別するために必要である重要な情報を失います場合があるので（リストア ネットワーク オペレーションに必要とされて）上の情報を収集する前に手動で ルータをリロードしましたり、またはパワーサイクルを行わないで下さい。 |
フィードバック