瞭解99%的VIP CPU運行率和Rx端緩衝

下載選項

PDF (360.9 KB)
在多種裝置上使用 Adobe Reader 檢視
ePub (105.8 KB)
在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
Mobi (Kindle) (183.8 KB)
在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視

已更新: 2005 年 7 月 7 日

文件 ID:12810

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

本文解釋為什麼多功能介面處理器(VIP)CPU的運行速度為99%，以及什麼是Rx端緩衝器。

必要條件

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。

背景資訊

Rx端緩衝是傳出介面發生以下情況的程式：

擁塞。
使用先進先出(FIFO)隊列策略。

傳入多功能介面處理器(VIP)不會立即捨棄封包。相反，它會在其資料包記憶體中緩衝資料包，直到緩衝區可用於傳出介面。根據VIP的型別，資料包記憶體可以是靜態RAM(SRAM)或同步動態RAM(SDRAM)。

Cisco 7500系列架構基礎知識

每個介面處理器（傳統IP或VIP）都具有一個到稱為CyBus的高速擴展系統匯流排的連線。路由/交換機處理器(RSP)連線到兩個CyBus(請參見圖1)。

圖1 - Cisco 7500系列架構

封包緩衝區型別

本節介紹各種型別的資料包緩衝區。

RSP上處理器記憶體中的系統緩衝區

這些緩衝區用於進程交換資料包。您可以在show interfaces（輸入和輸出隊列）和show buffers命令的輸出中看到這些緩衝區。Cisco 7500系列路由器不能執行太多進程交換。因此，如果系統緩衝區出現問題，則表示傳送到進程級別的資料包過多。這可能是由於許多因素造成的，例如：
- 廣播風暴
- 網路中導致路由更新的不穩定性
- 一種「拒絕服務」(DoS)攻擊
- 快速交換路徑不支援的功能（例如X.25）
- 包含選項的IP資料包。
有關如何對過度進程交換進行故障排除的資訊，請參閱以下文檔：
- 疑難排解思科路由器 CPU 高使用率的問題
- 疑難排解輸入佇列捨棄和輸出佇列捨棄問題
RSP(MEMD)緩衝區上的資料包記憶體

在RSP7000、RSP1、RSP2和RSP4上，MEMD大小固定為2 MB。在RSP8和RSP16上，MEMD大小為8 MB。啟動時，當存在聯機插入和刪除(OIR)、微代碼重新載入、最大傳輸單元(MTU)更改或匯流排複合體時，MEMD分佈在所有介面之間。有關cbus complex的詳細資訊，請參閱導致「%RSP-3-RESTART:cbus complex"?.您可以使用show controllers cbus 命令檢查MEMD緩衝區的狀態。

分配MEMD時，將建立以下結構：
- local free queue(lfreeq) — 分配給每個介面，用於在此介面上接收的資料包。
- global free queue(gfreeq) — 也會分配它，並且介面可以在某些限制內回退到該隊列。
- 傳輸佇列（txqueue或txq） — 分配給每個介面，並用於通過該介面傳出的封包。
- transmit accumulator(txacc) — 它表示輸出介面傳輸隊列(txqueue)上的元素數。當傳輸累加器(txacc)等於傳輸限制(txlimit)時，釋放所有緩衝區。當txacc為0時，隊列已滿，不再允許進行佇列。
資料包記憶體

在VIP上，封包記憶體包含封包緩衝區（粒子），用於從VIP介面接收或傳送到VIP介面的封包。圖2表示資料包流。
圖2 — 資料包流

本節重點介紹啟用分散式交換的VIP，因為當資料包遵循此類交換路徑時，通常會發生Rx端緩衝。可能出現不同的情境，如下所述：

案例 1:出站介面上沒有擁塞時。
- 封包在連線埠配接器(PA)上接收，並移動到封包記憶體中的封包緩衝區中。
- 如果VIP無法分發交換資料包，則會將資料包轉發到RSP，RSP將做出交換決策。
- 如果VIP可以做出交換決定，且傳出介面位於同一個VIP上，則資料包將在傳出介面上傳送。資料包在VIP上稱為「本地交換」，因為它不通過cbus。
- 如果VIP可以做出交換決定，並且傳出介面位於另一個插槽中，則VIP會嘗試通過cbus將資料包複製到傳出介面的txqueue（在MEMD中）。
- 然後，資料包通過cbus複製到傳出(V)IP，並線上路上傳送。
案例 2:出站介面擁塞時。

可能發生兩種情況：
- 如果在傳出介面上設定了佇列，VIP會將封包傳輸到MEMD中的txqueue，並立即透過佇列碼從佇列中擷取封包。
  - 如果配置了基於RSP的佇列，則封包會複製到RSP上處理器記憶體中的系統緩衝區中。
  - 如果使用基於VIP的佇列，封包會複製到傳出VIP的封包記憶體中。
- 如果出站介面的隊列策略是FIFO，則介面不會立即丟棄資料包（這是出站介面擁塞時FIFO通常發生的情況）。相反，入站VIP會將資料包緩衝在其資料包記憶體中，直到某些緩衝區再次可供出站介面使用。這稱為Rx端緩衝。

使用show controllers vip accumulator命令檢查Rx端緩衝的狀態。狀態顯示：

路由器中存在的輸出介面數。
VIP為這些介面緩衝了多少資料包。
為什麼VIP具有Rx緩衝功能。
VIP丟棄了多少資料包，以及原因。

VIP的運行速度為99%的CPU利用率

Rx端緩衝的後果是VIP在99%的CPU利用率下運行。VIP會持續監控傳出介面的txqueue狀態，並在有可用緩衝區時，將封包透過cbus複製到txqueue。

當VIP運行99%時，進行Rx緩衝時，其本身並不令人擔憂。這並不意味著貴賓超載。如果VIP收到更重要的事務（例如，另一個資料包到交換機），這不會受到CPU使用率較高的影響。

以下是可以在實驗室中執行的簡單測試，以說明此情況：

Serial 2/0/0的時鐘速率為128 Kbps，以線速接收流量。流量被切換到串列10/0，其中時鐘速率為64 Kbps，排隊策略為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表示僅剩下兩個緩衝區。當txacc小於4時，Rx-buffering不會在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的CPU使用率為99%，即使它只收到128 Kbps。這表明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

主要	說明
答	MEMD中txacc的地址。系統中每個txacc都有一個Rx端緩衝隊列（最多4096）。
b	Rx緩衝的資料包數。
思	VIP丟棄的資料包數。如果有足夠的資料包記憶體緩衝區，VIP最多可以Rx緩衝一秒的流量。但是，如果介面持續擁塞，則無法避免丟包。
d	當前Rx緩衝的資料包數。
e	當前Rx緩衝的粒子數。一個包可以由多個粒子組成。
思	軟限制，即VIP記憶體不足時的最大粒子數。
g	硬限制，它是可供隨時使用的粒子的最大數量。
h	傳出介面的速度（以kbps為單位）。
i	由於MEMD中沒有可用的txacc而導致Rx緩衝的資料包數。這表示輸出佇列擁塞（tx-queue中沒有更多可用緩衝區）。此問題的解決方法是增加輸出介面頻寬（如果可能）。
j	IP優先順序不是6或7的資料包數量，該數量無法傳送，因為沒有MEMD控制，並且由於達到粒子的軟或硬限制而被丟棄。
k	與j相同，但適用於IP優先順序為6或7的封包（網際網路和網路）。
l	VIP希望使用Rx緩衝區的IP優先順序不是6或7的資料包數，但由於資料包記憶體中缺少可用緩衝區而丟棄的資料包數。從Cisco IOS軟體版本12.0(13)S和12.1(4)開始，您還可以使用show controller vip [all / slot#] packet-memory-drops指令來檢視捨棄的封包數量。在這種情況下，升級封包記憶體會有幫助。
m	與l相同，但適用於IP優先順序為6或7的封包（網際網路和網路）。
否	由於沒有MEMD緩衝區，VIP嘗試進行Rx-buffer的資料包數，但由於缺少資料包記憶體緩衝區而無法進行。升級資料包記憶體。從Cisco IOS軟體版本12.0(13)S和12.1(4)開始，您還可以使用show controllers vip [all / slot#] packet-memory-drops命令來了解封包遭捨棄的原因。
o	IP優先順序為6或7且沒有MEMD緩衝區的Rx緩衝的封包數量，此封包由於達到軟(f)或硬(g)限制而被捨棄。在這種情況下，RSP16會有所幫助，因為它具有更多的MEMD記憶體（8 MB，而RSP1、RSP2、RSP4和RSP7000為2 MB）。在此案例中，您還可以降低某些介面（例如ATM、POS或FDDI）的MTU。這些介面通常具有4470位元組的MTU，且可以分配的MEMD緩衝區較少，因為緩衝區必須較大。
p	與o相同，但適用於IP優先順序為6或7的封包（網際網路和網路）。
q	VIP嘗試進行Rx-buffer的IP優先順序不是6或7的資料包數，因為沒有MEMD緩衝區，但是由於缺少資料包記憶體緩衝區而無法進行。在這種情況下，升級封包記憶體會有幫助。從Cisco IOS軟體版本12.0(13)S和12.1(4)開始，您還可以使用show controllers vip [all / slot#] packet-memory-drops指令來更好地了解封包遭捨棄的原因。
r	與q相同，但適用於IP優先順序為6或7的封包（網際網路和網路）。

如果路由器運行的Cisco IOS軟體版本低於12.0(13)ST、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 [all / slot#] accumulator的輸出提供上述功能的簡化版本。由於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緩衝並丟棄2644182個資料包。從被捨棄的封包2644182有80個封包的IP優先順序為6或7。
126個資料包目前經過Rx緩衝，它們使用378個粒子。
由於MEMD中tx佇列中缺少可用緩衝區，因此所有封包都進行Rx緩衝。這表示輸出介面擁塞。之所以發生丟棄，是因為達到了Rx緩衝的資料包的最大數量。典型的解決方案是升級出站介面頻寬、重新路由某些流量以使出站介面減少擁塞，或啟用某些排隊以丟棄不太重要的流量。

範例 2：Rx-side Buffers without Drops。

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些封包是以Rx緩衝的，因為ATM 1/0擁塞，但沒有封包被捨棄。
117795封包是以Rx緩衝的，因為VIP無法取得MEMD緩衝區。沒有丟棄資料包。典型的解決方案是減少一些MTU，以便分配更多的MEMD緩衝區。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緩衝的，沒有封包被捨棄。

範例 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的原始隊列，然後由原始隊列做出交換決策。當封包無法立即複製到MEMD時，VIP Rx會緩衝這些封包，並追蹤每個傳入介面有多少封包是以Rx緩衝的。

轉發隊列0-7用於第一個埠介面卡(PA),8-15用於第二個PA。

轉發隊列編號	...顯示在上接收的Rx緩衝資料包數……
0	第一個埠介面卡(PA)的第一個插孔
8	第二個人助理的第一插孔
9	第二個人助理的第二插孔

VIP上CPU使用率高的其他原因

當Rx端緩衝被發現處於非活動狀態時，下列因素之一可能導致VIP上的CPU使用率高：

分散式流量整形導致VIP上99%的CPU利用率

當設定分散式流量調節(dTS)時，每當有一個封包進入dTS佇列，VIP CPU就會躍升至99%。

這是正確和預期的行為。當配置了dTS時，VIP CPU旋轉以檢查下一個時間間隔(Tc)是否在CPU不忙時（即沒有流量時）到達。否則，在tx/rx中斷常式中傳送驗證。只在CPU不忙時旋轉。因此，效能不會受到影響。

要瞭解「下一時間間隔」的含義，請參閱什麼是令牌桶？

注意：僅當必須將資料包入隊到整形隊列中時，流量整形才會變為活動狀態。換句話說，當流量量超過整形速率時。這解釋了為什麼在配置dTS時VIP CPU並不總是為99%。有關dTS的詳細資訊，請參閱：
- 分散式流量調節
- 設定分散式流量調節
由於偽記憶體訪問和對齊錯誤導致VIP上的CPU使用率高

校準錯誤和虛假記憶體訪問是Cisco IOS軟體糾正的軟體故障，無需使VIP崩潰。如果這些錯誤頻繁出現，將導致作業系統進行大量更正，從而導致CPU使用率高。

有關校準錯誤和偽記憶體訪問的更多資訊，請參閱對偽訪問、校準錯誤和偽中斷進行故障排除。

要檢查虛假記憶體訪問和對齊錯誤，請使用show alignment命令。此類錯誤的示例如下所示：
```
VIP-Slot1#show alignment
No alignment data has been recorded.
No spurious memory references have been recorded.
```

CPU使用率較高的其他原因可能是所啟用的分散式功能的數量和範圍。如果您懷疑這可能是原因，或者如果您無法確定本文檔中說明的任何導致CPU使用率較高的原因，請向思科技術支援中心(TAC)提交服務請求。

開啟TAC服務請求時要收集的資訊

如果您在執行上述疑難排解步驟後仍需要協助，並想向Cisco TAC開啟服務請求(僅限註冊客戶)，請確保包含以下資訊：
show controllers vip [all / slot#] accumulator命令的輸出相關RSP和VIP的show technical-support命令輸出請將收集的資料以非壓縮的純文字檔案格式(.txt)附加到您的服務請求。若要將資訊附加到服務請求，請透過TAC服務請求工具(僅限註冊客戶)上傳。如果您無法訪問服務請求工具，可將相關資訊附加到您的服務請求，並將其傳送至attach@cisco.com，並將您的服務請求編號包含在消息的主題行中。註：在收集上述資訊之前（除非恢復網路操作時需要這樣做），請不要手動重新載入或重新啟動路由器，因為這可能導致丟失確定問題根本原因所需的重要資訊。

如果您在執行上述疑難排解步驟後仍需要協助，並想向Cisco TAC開啟服務請求(僅限註冊客戶)，請確保包含以下資訊：

show controllers vip [all / slot#] accumulator命令的輸出
相關RSP和VIP的show technical-support命令輸出

請將收集的資料以非壓縮的純文字檔案格式(.txt)附加到您的服務請求。若要將資訊附加到服務請求，請透過TAC服務請求工具(僅限註冊客戶)上傳。如果您無法訪問服務請求工具，可將相關資訊附加到您的服務請求，並將其傳送至attach@cisco.com，並將您的服務請求編號包含在消息的主題行中。

註：在收集上述資訊之前（除非恢復網路操作時需要這樣做），請不要手動重新載入或重新啟動路由器，因為這可能導致丟失確定問題根本原因所需的重要資訊。