對Catalyst 4500交換機上的CPU使用率過高進行故障排除
目錄
簡介
本檔案將說明CPU封包處理架構，並介紹如何識別Catalyst 4500交換器上CPU使用率高的原因。
必要條件
需求
本文件沒有特定需求。
採用元件
本文中的資訊係根據以下軟體和硬體版本：
-
Catalyst 4500 系列交換器
-
Catalyst 4948 系列交換器
附註：本檔案僅適用於基於Cisco IOS®軟體的交換器。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
慣例
如需更多文件慣例的相關資訊，請參閱思科技術提示慣例。
背景資訊
Catalyst 4500系列交換器（包括Catalyst 4948交換器）具有適用於CPU型流量的複雜封包處理方法。通常認為存在的一個問題是這些交換機上的CPU利用率較高。本文提供有關CPU封包處理架構的詳細資訊，並說明如何識別這些交換器上CPU使用率高的原因。本檔案也列出導致Catalyst 4500系列上高CPU使用率的一些常見網路或設定案例
在檢視CPU資料包處理架構和排除CPU使用率過高故障之前，必須瞭解基於硬體的轉發交換機和基於Cisco IOS軟體的路由器使用CPU的不同方式。常見的誤解是CPU使用率高表示裝置上的資源耗盡和崩潰威脅。容量問題是Cisco IOS路由器上CPU使用率較高的症狀之一。但是，容量問題幾乎從來不是基於硬體的轉發交換機（如Catalyst 4500）的CPU使用率較高的症狀。Catalyst 4500可在硬體專用積體電路(ASIC)中轉發資料包，並達到高達每秒1.02億個資料包(Mpps)的流量轉發速度。
Catalyst 4500 CPU執行以下功能：
-
管理已配置的軟體協定，例如：
- 生成樹通訊協定(STP)
-
路由協定
-
Cisco Discovery Protocol(CDP)
-
連線埠彙總通訊協定(PAgP)
-
VLAN中繼線通訊協定(VTP)
-
動態Trunk通訊協定(DTP)
-
為硬體ASIC中的配置/動態條目程式設計，例如：
-
存取控制清單(ACL)
-
CEF條目
-
-
內部管理各種元件，例如：
-
乙太網供電(PoE)線卡
-
電源
-
風扇托架
-
-
管理對交換機的訪問，例如：
-
Telnet
-
主控台
-
簡易網路管理通訊協定(SNMP)
-
-
透過軟體路徑轉送封包，例如：
-
網際網路封包交換(IPX)路由的封包，僅在軟體路徑中支援
-
最大傳輸單位(MTU)分段
-
根據此清單，CPU接收或處理資料包可能導致CPU使用率高。某些為進程傳送的資料包對於網路運行可能是必需的。這些基本資料包的示例是橋接協定資料單元(BPDU)，用於生成樹拓撲配置。但是，其他資料包可以是軟體轉發的資料流量。這些情況要求交換ASIC將資料包傳送到CPU進行處理：
-
複製到CPU但原始資料包在硬體中交換的資料包。
例如，主機MAC地址學習。
-
傳送到CPU進行處理的資料包
示例包括：
-
路由協定更新
-
BPDU
-
有意或無意的交通洪流
-
-
傳送到CPU進行轉發的資料包
例如，需要IPX或AppleTalk路由的資料包。
瞭解Catalyst 4500 CPU封包處理架構
Catalyst 4500具有內建的服務品質(QoS)機制，以便區分目的地為CPU的流量型別。該機制基於第2層(L2)/第3層(L3)/第4層(L4)封包資訊進行區分。Supervisor資料包引擎有16個隊列，用於處理各種型別的資料包或事件。圖1 顯示了這些隊列。表1 列出了隊列以及在每個隊列中排隊的資料包型別。16個隊列允許Catalyst 4500根據資料包型別或優先順序對資料包進行排隊。
圖1 - Catalyst 4500使用多個CPU隊列
Catalyst 4500使用多個CPU佇列
表1 - Catalyst 4500隊列說明
| 隊列編號 | 隊列名稱 | 排隊的資料包 |
|---|---|---|
| 0 | Esmp | 用於線卡ASIC或其他元件管理的ESMP1資料包（內部管理資料包） |
| 1 | 控制 | L2控制平面資料包，例如STP、CDP、PAgP、LACP2或UDLD3 |
| 2 | 主機學習 | 具有未知源MAC地址的幀被複製到CPU以構建L2轉發表 |
| 3、4、5 | 第3層正向最高、第3層正向高/中、第3層正向低 | 必須在軟體中轉送的封包，例如GRE4通道如果目的地IP位址的ARP5未解析，則封包會傳送到此佇列。 |
| 6、7、8 | L2正向最高、L2正向高/中、L2正向低 | 由於橋接而轉發的資料包
|
| 9、10 | L3 Rx高、L3 Rx低 | 第3層控制平面流量，例如目的地為CPU IP地址的路由協定示例包括Telnet、SNMP和SSH8。 |
| 11 | RPF故障 | RPF9檢查失敗的組播資料包 |
| 12 | ACL轉發（窺探） | 由DHCP10監聽、動態ARP檢查或IGMP11監聽功能處理的資料包 |
| 13 | ACL日誌，無法訪問 | 使用thelogkeyword命中ACE12的資料包，或由於輸出ACL中的deny或缺少到達目的地的路由而丟棄的資料包這些資料包需要生成ICMP不可達消息。 |
| 14 | ACL sw處理 | 由於缺少安全ACL的額外ACL硬體資源（例如TCAM13）而被推到CPU的資料包 |
| 15 | MTU失敗/無效 | 由於輸出介面MTU大小小於資料包大小而需要分段的資料包 |
1ESMP =甚至簡單管理協定。
2LACP =鏈路聚合控制協定。
3UDLD =單向連結偵測。
4GRE =通用路由封裝。
5ARP =地址解析協定。
6SVI =交換虛擬介面。
7TTL =生存時間。
8SSH =安全外殼協定。
9RPF =反向路徑轉發
10DHCP =動態主機配置協定。
11IGMP =網際網路組管理協定。
12ACE =訪問控制條目。
13TCAM =三重內容可定址儲存器。
這些隊列是獨立的隊列：
-
第2層正向高級第3層正向最高
-
L2正向高/MediumrL3正向高/中
-
第2層正向低級第3層正向低
-
L3 Rx高或L3 Rx低
根據QoS標籤(來自IP服務型別(ToS)的差分服務代碼點(DSCP)值)將資料包排隊到這些隊列中。 例如，DSCP為63的資料包將排入L3正向最高隊列。在show platform cpu packet statistics all命令的輸出中，您可以看到這16個隊列的接收和捨棄的封包。此命令的輸出非常長。發出show platform cpu packet statistics命令，以僅顯示非零事件。另一個命令是 show platform cpuport 命令。如果執行Cisco IOS軟體版本12.1(11)EW或更低版本，請僅使用show platform cpuport 命令。此命令此後已被棄用。但是此舊版命令是Cisco IOS軟體版本12.2(20)EWA之前Cisco IOS軟體版本中show tech-supportcommand的一部分。
使用show platform cpu packet statistics命令進行所有故障排除。
Switch#show platform cpu packet statistics all !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 0 0 0 0 0 Control 48 0 0 0 0 Host Learning 0 0 0 0 0 L3 Fwd High 0 0 0 0 0 L3 Fwd Medium 0 0 0 0 0 L3 Fwd Low 0 0 0 0 0 L2 Fwd High 0 0 0 0 0 L2 Fwd Medium 0 0 0 0 0 L2 Fwd Low 0 0 0 0 0 L3 Rx High 0 0 0 0 0 L3 Rx Low 0 0 0 0 0 RPF Failure 0 0 0 0 0 ACL fwd(snooping) 0 0 0 0 0 ACL log, unreach 0 0 0 0 0 ACL sw processing 0 0 0 0 0 MTU Fail/Invalid 0 0 0 0 0 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 0 0 0 0 0 Control 0 0 0 0 0 Host Learning 0 0 0 0 0 L3 Fwd High 0 0 0 0 0 L3 Fwd Medium 0 0 0 0 0 L3 Fwd Low 0 0 0 0 0 L2 Fwd High 0 0 0 0 0 L2 Fwd Medium 0 0 0 0 0 L2 Fwd Low 0 0 0 0 0 L3 Rx High 0 0 0 0 0 L3 Rx Low 0 0 0 0 0 RPF Failure 0 0 0 0 0 ACL fwd(snooping) 0 0 0 0 0 ACL log, unreach 0 0 0 0 0 ACL sw processing 0 0 0 0 0 MTU Fail/Invalid 0 0 0 0 0
Catalyst 4500 CPU為表1列出的各種隊列分配權重。CPU根據重要性（或型別）以及流量優先順序（或DSCP）分配權重。CPU基於隊列的相對權重為隊列提供服務。例如，如果控制資料包（例如BPDU）和ICMP回應請求均處於掛起狀態，則CPU會先為控制資料包提供服務。過多低優先順序或不太重要的流量不會使CPU無法處理或管理系統。此機制可確保即使在CPU使用率較高的情況下，網路仍保持穩定。網路保持穩定的這一能力是您必須瞭解的關鍵資訊。
Catalyst 4500 CPU封包處理還有另一個非常重要的實作詳細資訊。如果CPU已經為高優先順序資料包或進程提供服務，但在特定時間段具有更多的備用CPU週期，則CPU為低優先順序隊列資料包提供服務，或執行較低優先順序的後台進程。由於低優先順序資料包處理或後台處理導致的CPU使用率較高，這被視為正常現象，因為CPU會不斷嘗試使用所有可用時間。這樣，CPU就力求在不影響交換機穩定性的情況下實現交換機和網路的最大效能。Catalyst 4500會考慮CPU使用不足，除非CPU在單個時隙中的使用率為100%。
Cisco IOS軟體版本12.2(25)EWA2和更新版本增強了CPU封包和程式處理機制以及計量。因此，在Catalyst 4500部署上使用這些版本。
確定Catalyst 4500上CPU使用率高的原因
現在您已瞭解Catalyst 4500 CPU封包處理架構和設計，仍可以確定您的Catalyst 4500 CPU使用率高的原因。Catalyst 4500具有確定CPU使用率高的根本原因所需的命令和工具。確定原因後，管理員可以執行以下任一操作：
-
糾正措施 — 這可能包括配置或網路更改，或建立思科技術支援服務請求以進行進一步分析。
-
無動作 — Catalyst 4500根據預期執行。由於Supervisor Engine會最大化CPU週期，以便執行所有必要的軟體資料包轉發和後台作業，因此CPU使用率較高。
確保確定CPU使用率高的原因，即使並非在所有情況下都需要採取糾正措施。CPU使用率高可能只是網路中出現問題的一個症狀。為了降低CPU利用率，可能需要解決此問題的根本原因。
圖2 顯示用於識別Catalyst 4500高CPU使用率的根本原因的故障排除方法。
圖2 - Catalyst 4500交換機上的CPU使用率高故障排除方法
Catalyst 4500交換機上的高CPU利用率故障排除方法
常規故障排除步驟如下：
-
發出show processes cpu 命令，以識別消耗CPU週期的Cisco IOS進程。
-
發出how platform healthcommand，以進一步識別平台特定的進程。
-
如果高活動進程為K2CpuMan Review，請發出how platform cpu packet statistics命令以標識進入CPU的流量型別。
如果活動不是由於K2CpuMan Reviewprocess所致，請跳過步驟4並繼續步驟5。
-
如有必要，使用故障排除工具來分析發往CPU的流量，確定發往CPU的資料包。
疑難排解工具的使用範例是CPU交換連線埠分析器(SPAN)。
-
檢查本文檔和常見原因的常見CPU使用率高問題故障排除部分。
如果仍然無法確定根本原因，請與思科技術支援聯絡。
基線CPU使用率
重要的第一步是瞭解您的配置和網路設定中交換機的CPU利用率。使用show processes命令以識別Catalyst 4500交換器上的CPU使用率。當您向網路設定新增更多配置或您的網路流量模式發生變化時，可能需要持續更新基線CPU利用率。圖2指示此要求。
此輸出來自滿載Catalyst 4507R。穩態CPU的佔用率約為32%至38%，這是執行此交換機管理功能所必需的：
Switch#show processes cpu CPU utilization for five seconds: 38%/1%; one minute: 32%; five minutes: 32% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 63 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 60 50074 1 0.00% 0.00% 0.00% 0 Load Meter 3 0 1 0 0.00% 0.00% 0.00% 0 Deferred Events !--- Output suppressed. 27 524 250268 2 0.00% 0.00% 0.00% 0 TTY Background 28 816 254843 3 0.00% 0.00% 0.00% 0 Per-Second Jobs 29 101100 5053 20007 0.00% 0.01% 0.00% 0 Per-minute Jobs 30 26057260 26720902 975 12.07% 11.41% 11.36% 0 Cat4k Mgmt HiPri 31 19482908 29413060 662 24.07% 19.32% 19.20% 0 Cat4k Mgmt LoPri 32 4468 162748 27 0.00% 0.00% 0.00% 0 Galios Reschedul 33 0 1 0 0.00% 0.00% 0.00% 0 Cisco IOS ACL Helper 34 0 2 0 0.00% 0.00% 0.00% 0 NAM Manager
五秒CPU利用率表示為：
x%/y%
X%表示總CPU使用率，andy%表示在中斷級別花費的CPU。對Catalyst 4500交換機進行故障排除時，僅關注總CPU利用率。
瞭解Catalyst 4500交換器上的show processes cpu命令
此show processes cpuoutput顯示有兩個使用CPU的進程 — Cat4k Mgmt HiPriandCat4k Mgmt LoPri。這兩個進程聚合了多個平台特定的進程，這些進程在Catalyst 4500上執行基本的管理功能。這些進程處理控制平面以及需要軟體交換或處理的資料包。
若要檢視哪些平台特定的進程在Cat4k Mgmt HiPriandCat4k Mgmt LoPri上下文中使用CPU，請發出show platform healthcommand。
每個特定於平台的進程都有目標/預期的CPU利用率。當該進程位於目標內時，CPU在高優先順序環境中執行該進程。thshow processes cpucommand output計算在Cat4k Mgmt HiPri下的利用率。如果某個進程超過了目標/預期利用率，則該進程將在低優先順序上下文中運行。thshow processes cpucommand output計算在Cat4k Mgmt LoPri下的額外利用率。此Cat4k管理LoPriis還用於運行後台和其他低優先順序進程，如一致性檢查和讀取介面計數器。此機制允許CPU在必要時運行高優先順序進程，其餘的空閒CPU週期用於低優先順序進程。稍稍超出目標CPU利用率，或瞬時出現利用率高峰，並不表示存在需要調查的問題。
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
S2w-JobEventSchedule 10.00 0.32 10 7 100 500 0 0 0 10:14
Stub-JobEventSchedul 10.00 12.09 10 6 100 500 14 13 9 396:35
StatValueMan Update 1.00 0.22 1 0 100 500 0 0 0 6:28
Pim-review 0.10 0.00 1 0 100 500 0 0 0 0:22
Ebm-host-review 1.00 0.00 8 0 100 500 0 0 0 0:05
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:01
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:00
Acl-Flattener e 1.00 0.00 10 0 100 500 0 0 0 0:00
KxAclPathMan create/ 1.00 0.00 10 5 100 500 0 0 0 0:39
KxAclPathMan update 2.00 0.00 10 0 100 500 0 0 0 0:00
KxAclPathMan reprogr 1.00 0.00 2 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 30.00 10.19 30 28 100 500 14 13 9 397:11
K2AccelPacketMan: Tx 10.00 2.20 20 0 100 500 2 2 1 82:06
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
K2AclCamMan stale en 1.00 0.00 10 0 100 500 0 0 0 0:00
K2AclCamMan hw stats 3.00 1.04 10 5 100 500 1 1 0 39:36
K2AclCamMan kx stats 1.00 0.00 10 5 100 500 0 0 0 13:40
K2AclCamMan Audit re 1.00 0.00 10 5 100 500 0 0 0 13:10
K2AclPolicerTableMan 1.00 0.00 10 1 100 500 0 0 0 0:38
K2L2 Address Table R 2.00 0.00 12 5 100 500 0 0 0 0:00
K2L2 New Static Addr 2.00 0.00 10 1 100 500 0 0 0 0:00
K2L2 New Multicast A 2.00 0.00 10 5 100 500 0 0 0 0:01
K2L2 Dynamic Address 2.00 0.00 10 0 100 500 0 0 0 0:00
K2L2 Vlan Table Revi 2.00 0.00 12 9 100 500 0 0 0 0:01
K2 L2 Destination Ca 2.00 0.00 10 0 100 500 0 0 0 0:00
K2PortMan Review 2.00 0.72 15 11 100 500 1 1 0 37:22
Gigaport65535 Review 0.40 0.07 4 2 100 500 0 0 0 3:38
Gigaport65535 Review 0.40 0.08 4 2 100 500 0 0 0 3:39
K2Fib cam usage revi 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib IrmFib Review 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Default Ro 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib AdjRepop Revie 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Unpunt Rev 2.00 0.01 15 0 100 500 0 0 0 0:23
K2Fib Consistency Ch 1.00 0.00 5 2 100 500 0 0 0 29:25
K2FibAdjMan Stats Re 2.00 0.30 10 4 100 500 0 0 0 6:21
K2FibAdjMan Host Mov 2.00 0.00 10 4 100 500 0 0 0 0:00
K2FibAdjMan Adj Chan 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibMulticast Signa 2.00 0.01 10 2 100 500 0 0 0 2:04
K2FibMulticast Entry 2.00 0.00 10 7 100 500 0 0 0 0:00
K2FibMulticast Irm M 2.00 0.00 10 7 100 500 0 0 0 0:00
K2FibFastDropMan Rev 2.00 0.00 7 0 100 500 0 0 0 0:00
K2FibPbr route map r 2.00 0.06 20 5 100 500 0 0 0 16:42
K2FibPbr flat acl pr 2.00 0.07 20 2 100 500 0 0 0 3:24
K2FibPbr consolidati 2.00 0.01 10 0 100 500 0 0 0 0:24
K2FibPerVlanPuntMan 2.00 0.00 15 4 100 500 0 0 0 0:00
K2FibFlowCache flow 2.00 0.01 10 0 100 500 0 0 0 0:23
K2FibFlowCache flow 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibFlowCache adj r 2.00 0.01 10 0 100 500 0 0 0 0:20
K2FibFlowCache flow 2.00 0.00 10 0 100 500 0 0 0 0:06
K2MetStatsMan Review 2.00 0.14 5 2 100 500 0 0 0 23:40
K2FibMulticast MET S 2.00 0.00 10 0 100 500 0 0 0 0:00
K2QosDblMan Rate DBL 2.00 0.12 7 0 100 500 0 0 0 4:52
IrmFibThrottler Thro 2.00 0.01 7 0 100 500 0 0 0 0:21
K2 VlanStatsMan Revi 2.00 1.46 15 7 100 500 2 2 1 64:44
K2 Packet Memory Dia 2.00 0.00 15 8 100 500 0 1 1 45:46
K2 L2 Aging Table Re 2.00 0.12 20 3 100 500 0 0 0 7:22
RkiosPortMan Port Re 2.00 0.73 12 7 100 500 1 1 1 52:36
Rkios Module State R 4.00 0.02 40 1 100 500 0 0 0 1:28
Rkios Online Diag Re 4.00 0.02 40 0 100 500 0 0 0 1:15
RkiosIpPbr IrmPort R 2.00 0.02 10 3 100 500 0 0 0 2:44
RkiosAclMan Review 3.00 0.06 30 0 100 500 0 0 0 2:35
MatMan Review 0.50 0.00 4 0 100 500 0 0 0 0:00
Slot 3 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 3 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 4 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 4 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 5 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 5 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 6 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 6 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 7 ILC Manager R 3.00 0.00 10 0 100 500 0 0 0 0:00
Slot 7 ILC S2wMan Re 3.00 0.00 10 0 100 500 0 0 0 0:00
EthHoleLinecardMan(1 1.66 0.04 10 0 100 500 0 0 0 1:18
EthHoleLinecardMan(2 1.66 0.02 10 0 100 500 0 0 0 1:18
EthHoleLinecardMan(6 1.66 0.17 10 6 100 500 0 0 0 6:38
-------------
%CPU Totals 212.80 35.63
瞭解Catalyst 4500交換器上的show platform health命令
show platform healthcommand提供大量只與開發工程師相關的資訊。若要疑難排解高CPU使用率問題，請在輸出的%CPU實際列中尋找更高的數字。此外，請務必檢視該行的右側，以便驗證該進程在1分鐘和1小時內的平均%CPU列的CPU使用率。有時，進程會暫時達到峰值，但不會長時間保持CPU。在硬體程式設計或最佳化程式設計期間，會遇到一些臨時較高的CPU使用率。例如，在TCAM中對大型ACL進行硬體程式設計時，CPU使用率峰值是正常的。
在show platform healthcommand輸出的show processes cpu命令部分中，瞭解Catalyst 4500交換機上的show processes cpu命令,Stub-JobEventScheduland K2CpuMan Reviewprocesses使用更多的CPU週期。表2提供有關thshow platformhealthcommand輸出中出現的常見平台特定進程的一些基本資訊。
表2 - show platform health命令中的平台特定進程說明
| 平台特定的進程名稱 | 說明 |
|---|---|
| Pim-review | 機箱/線卡狀態管理 |
| Ebm | 乙太網網橋模組，例如老化和監控 |
| Acl-Flatcher/K2AclMan | ACL合併過程 |
| KxAclPathMan — 路徑TagMan審閱 | ACL狀態管理和維護 |
| K2CpuMan回顧 | 執行軟體資料包轉發的進程如果由於此進程而導致CPU使用率高，請使用show platform cpu packet statistics命令調查到達CPU的數據包。 |
| K2AccelPacketMan | 與資料包引擎互動以傳送目的地為CPU的資料包的驅動程式 |
| K2AclCamMan | 管理QoS和安全功能的輸入和輸出TCAM硬體 |
| K2AclPolicerTableMan | 管理輸入和輸出策略器 |
| K2L2 | 代表Catalyst 4500 Cisco IOS軟體的L2轉發子系統這些進程負責維護各種L2表。 |
| K2PortMan回顧 | 管理各種與埠相關的程式設計功能 |
| K2Fib | FIB1管理 |
| K2FibFlowCache | PBR2緩存管理 |
| K2FibAdjMan | FIB鄰接表管理 |
| K2Fib多點傳送 | 管理組播FIB條目 |
| K2MetStatsMan回顧 | 管理MET3統計信息 |
| K2QosDblMan回顧 | 管理QoS DBL4 |
| IrmFibThrottler執行緒 | IP路由模組 |
| K2 L2老化表Re | 管理L2老化功能 |
| GalChassisVp-review | 機箱狀態監控 |
| S2w — 作業事件計畫 | 管理S2W5協議以監控線卡狀態 |
| 存根 — 作業事件計畫 | 基於末節ASIC的線卡監控和維護 |
| RkiosPortMan埠Re | 埠狀態監控和維護 |
| Rkios模組狀態R | 線路卡監控和維護 |
| EthHoleLinecardMan | 管理每個線卡中的GBIC6 |
1FIB =轉發資訊庫。
2PBR =基於策略的路由。
3MET =組播擴展表。
4DBL =動態緩衝區限制。
5S2W =串列對線。
6GBIC = Gigabit介面轉換器。
排除常見的CPU使用率較高的問題
本節介紹Catalyst 4500交換器上的一些常見高CPU使用率問題。
由於進程交換資料包導致的CPU使用率高
CPU使用率較高的常見原因之一是Catalyst 4500 CPU忙於處理軟體轉送的封包或控制封包的封包。軟體轉發資料包的示例包括IPX或控制資料包，例如BPDU。這些資料包中的少數幾個通常被傳送到CPU。但是，持續出現大量資料包可能表示存在配置錯誤或網路事件。您必須確定導致將資料包轉發到CPU進行處理的事件原因。通過此標識，可以調試高CPU使用率問題。
由於進程交換資料包導致的CPU使用率較高的一些常見原因如下：
將資料包切換到CPU的其他原因包括：
-
MTU分段 — 請確保沿封包路徑的所有介面具有相同的MTU。
-
ACL的TCP標誌不是已建立的
-
IP第6版(IPv6)路由 — 僅通過軟體交換路徑支援此功能。
-
GRE — 僅通過軟體交換路徑支援此操作。
-
拒絕輸入或輸出路由器ACL中的流量(RACL)
附註：此速率受Cisco IOS軟體版本12.1(13)EW1和更新版本的限制。
在ACL的介面下發出o ip unreachablescommand。
-
由於大量直連主機，導致過多的ARP和DHCP流量命中CPU進行處理
如果懷疑DHCP攻擊，請使用DCHP監聽來限制來自任何特定主機埠的DHCP流量。
-
合法或行為不當的終端站進行過多的SNMP輪詢
大量生成樹埠例項
Catalyst 4500在每VLAN生成樹+(PVST+)模式下支援3000個生成樹埠例項或活動埠。除管理引擎II+和II+TS以及Catalyst 4948外，所有管理引擎均支援該功能。管理引擎II+和II+TS以及Catalyst 4948最多支援1500個埠例項。如果超出這些STP例項建議，則交換機顯示較高的CPU利用率。
Catalyst 4500
此圖顯示Catalyst 4500具有三個主干連線埠，每個連線埠都承載VLAN 1到100。這相當於300個跨距樹狀目錄連線埠例項。通常，您可以使用以下公式計算生成樹埠例項：
Total number of STP instances = Number of access ports + Sum of all VLANs that are carried in each of the trunks
在圖中，沒有接入埠，但三個中繼承載VLAN 1至100:
Total number of STP instances = 0 + 100 + 100 + 100 = 300
步驟 1:使用Command檢查Cisco IOS過 show processes cpu 程。
本節介紹管理員使用的命令，以縮小CPU使用率較高的問題。如果您發出show processes cpu 命令，則可以看到兩個主要進程(Cat4k Mgmt LoPriandSpanning Tree)主要使用CPU。僅使用此資訊時，您就可以知道生成樹進程佔用了相當大一部分的CPU週期。
Switch#show processes cpu CPU utilization for five seconds: 74%/1%; one minute: 73%; five minutes: 50% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 198 20 0.00% 0.00% 0.00% 0 Chunk Manager 2 4 290 13 0.00% 0.00% 0.00% 0 Load Meter !--- Output suppressed. 25 488 33 14787 0.00% 0.02% 0.00% 0 Per-minute Jobs 26 90656 223674 405 6.79% 6.90% 7.22% 0 Cat4k Mgmt HiPri 27 158796 59219 2681 32.55% 33.80% 21.43% 0 Cat4k Mgmt LoPri 28 20 1693 11 0.00% 0.00% 0.00% 0 Galios Reschedul 29 0 1 0 0.00% 0.00% 0.00% 0 Cisco IOS ACL Helper 30 0 2 0 0.00% 0.00% 0.00% 0 NAM Manager !--- Output suppressed. 41 0 1 0 0.00% 0.00% 0.00% 0 SFF8472 42 0 2 0 0.00% 0.00% 0.00% 0 AAA Dictionary R 43 78564 20723 3791 32.63% 30.03% 17.35% 0 Spanning Tree 44 112 999 112 0.00% 0.00% 0.00% 0 DTP Protocol 45 0 147 0 0.00% 0.00% 0.00% 0 Ethchnl
步驟 2:使用show platform health命令檢查特定於Catalyst 4500的進程。
若要瞭解哪個平台特定的進程佔用CPU，請發出show platform healthcommand。從該輸出中，您可以看到K2CpuMan Reviewprocess（一個處理CPU繫結資料包的作業）耗盡了CPU:
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 30.00 37.62 30 53 100 500 41 33 1 2:12
K2AccelPacketMan: Tx 10.00 4.95 20 0 100 500 5 4 0 0:36
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
步驟 3:檢查接收流量的CPU隊列，以識別CPU繫結的流量型別。
發出show platform cpu packet statistics命令，以檢查哪個CPU隊列接收到CPU繫結的資料包。本節中的輸出顯示，控制佇列接收許多封包。使用表1中的資訊和步驟1中得出的結論。可以確定CPU處理的資料包以及CPU使用率較高的原因是BPDU處理。
Switch#show platform cpu packet statistics !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 202760 196 173 128 28 Control 388623 2121 1740 598 16 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Control 17918 0 19 24 3
步驟 4:確定根本原因。
發出命show spanning-tree summary令。您可以檢查BPDU的接收是否是因為生成樹埠例項數很多所致。輸出清楚地指出了根本原因：
Switch#show spanning-tree summary Switch is in pvst mode Root bridge for: none Extended system ID is enabled Portfast Default is disabled PortFast BPDU Guard Default is disabled Portfast BPDU Filter Default is disabled Loopguard Default is disabled EtherChannel misconfig guard is enabled UplinkFast is disabled BackboneFast is disabled Configured Pathcost method used is short !--- Output suppressed. Name Blocking Listening Learning Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------- 2994 vlans 0 0 0 5999 5999
使用PVST+模式配置的VLAN數量很多。為了解決此問題，請將STP模式更改為多生成樹(MST)。 在某些情況下，STP例項的數量非常大，因為所有中繼埠上轉發的VLAN數量很多。在這種情況下，手動修剪中繼中不必要的VLAN，以便將STP活動埠數降低到遠遠低於推薦值。
提示：請確保未將IP電話埠配置為中繼埠。這是常見的配置錯誤。使用語音VLAN配置配置IP電話埠。此組態會建立偽中繼，但不需要您手動修剪不必要的VLAN。有關如何配置語音埠的詳細資訊，請參閱配置語音介面軟體配置指南。非Cisco IP電話不支援此語音VLAN或輔助VLAN配置。您必須手動修整具有非Cisco IP電話的連線埠。
ICMP 重新導向;在同一介面上路由資料包
在同一介面上路由封包，或同一第3層介面上的流量輸入和輸出，都可能導致交換器進行ICMP重新導向。如果交換器知道通往最終目的地的下一個躍點裝置位於與傳送裝置相同的子網路中，則交換器會產生ICMP重新導向至來源。重定向消息指示源將資料包直接傳送到下一跳裝置。這些消息表明下一跳裝置具有到達目的地的更好路由，該路由比此交換機少一跳。
在本節的圖表中，PC A與Web伺服器通訊。PC A的預設網關指向VLAN 100介面IP地址。但是，使Catalyst 4500能夠到達目的地的下一跳路由器與PC A位於同一子網中。在這種情況下，最佳路徑是直接傳送到「路由器」。 Catalyst 4500向PC A傳送一則ICMP重新導向訊息。該訊息指示PC A透過路由器（而不是Catalyst 4500）將封包傳送到Web伺服器。但是大多數情況下，終端裝置不會回應ICMP重新導向。缺乏回應導致Catalyst 4500花費大量CPU週期來產生Catalyst透過與輸入封包相同的介面轉送的所有封包的這些ICMP重新導向。
預設情況下，ICMP重新導向已啟用。
預設會啟用ICMP重新導向。若要停用它，請使用命ip icmp redirects令。在相關SVI或L3介面下發出命令。
附註：由於ip icmp redirects是預設命令，因此它在命令輸出中不show running-configuration可見。
步驟 1:使用命令檢查Cisco IOS流show processes cpu程。
發出命令show processes cpu。您可以看到兩個主要進程(Cat4k Mgmt LoPriandIP Input)主要使用CPU。僅憑此資訊，您就會知道IP資料包的處理過程會佔用相當大的CPU部分。
Switch#show processes cpu CPU utilization for five seconds: 38%/1%; one minute: 32%; five minutes: 32% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 63 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 60 50074 1 0.00% 0.00% 0.00% 0 Load Meter 3 0 1 0 0.00% 0.00% 0.00% 0 Deferred Events !--- Output suppressed. 27 524 250268 2 0.00% 0.00% 0.00% 0 TTY Background 28 816 254843 3 0.00% 0.00% 0.00% 0 Per-Second Jobs 29 101100 5053 20007 0.00% 0.01% 0.00% 0 Per-minute Jobs 30 26057260 26720902 975 5.81% 6.78% 5.76% 0 Cat4k Mgmt HiPri 31 19482908 29413060 662 19.64% 18.20% 20.48% 0 Cat4k Mgmt LoPri !--- Output suppressed.show platform health35 60 902 0 0.00% 0.00% 0.00% 0 DHCP Snooping 36 504625304 645491491 781 72.40% 72.63% 73.82% 0 IP Input
步驟 2:使用命令檢查Catalyst 4500特定流show platform health程。
該命令的show platform health輸出確認使用CPU來處理繫結到CPU的資料包。
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 330.00 19.18 150 79 25 500 20 19 18 5794:08
K2AccelPacketMan: Tx 10.00 4.95 20 0 100 500 5 4 0 0:36
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
步驟 3:檢查接收流量的CPU隊列，以識別CPU繫結的流量型別。
發出show platform cpu packet statistics命令，以檢查哪個CPU隊列接收到CPU繫結的資料包。您可以看到L3正向低隊列接收相當多的流量。
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 48613268 38 39 38 39 Control 142166648 74 74 73 73 Host Learning 1845568 2 2 2 2 L3 Fwd High 17 0 0 0 0 L3 Fwd Medium 2626 0 0 0 0 L3 Fwd Low 4717094264 3841 3879 3873 3547 L2 Fwd Medium 1 0 0 0 0 L3 Rx High 257147 0 0 0 0 L3 Rx Low 5325772 10 19 13 7 RPF Failure 155 0 0 0 0 ACL fwd(snooping) 65604591 53 54 54 53 ACL log, unreach 11013420 9 8 8 8
步驟 4:確定根本原因。
在這種情況下，請使用CPU SPAN來確定到達CPU的流量。有關CPU SPAN的資訊，請參閱工具1:使用SPAN - Cisco IOS軟體版本12.1(19)EW和更新版本監控CPU流量部分。使用命令完成流量分析和配show running-configuration置。在這種情況下，封包會透過同一個介面路由，導致每個封包都發生ICMP重新導向問題。此根本原因是Catalyst 4500上CPU使用率較高的常見原因之一。
您可以預期來源搜尋裝置會執行Catalyst 4500傳送的ICMP重新導向，並變更目的地的下一躍點。但是，並非所有裝置都會響應ICMP重新導向。如果裝置沒有回應，Catalyst 4500必須針對交換器從傳送裝置接收的每個封包傳送重新導向。這些重定向會消耗大量CPU資源。解決方式為停用ICMP重新導向。在介面no ip redirects下發出命令。
當您還配置了輔助IP地址時，可能會發生這種情況。啟用輔助IP地址時，IP重定向將自動禁用。請確保沒有手動啟用IP重定向。
如此ICMP重新導向；相同介面上的路由封包已指示，大多數終端裝置不回應ICMP重新導向。因此，一般做法是禁用此功能。
IPX或AppleTalk路由
Catalyst 4500僅通過軟體轉發路徑支援IPX和AppleTalk路由。通過配置此類協定，CPU使用率較高是正常現象。
附註：在同一個VLAN中交換IPX和AppleTalk流量不需要進程交換。只有需要路由的資料包需要軟體路徑轉發。
步驟 1:使用命令檢查Cisco IOS過show processes cpu程。
發出show processes cpu 命令以檢查哪個Cisco IOS進程佔用CPU。在此命令輸出中，請注意，頂端程序為Cat4k Mgmt LoPri:
witch#show processes cpu CPU utilization for five seconds: 87%/10%; one minute: 86%; five minutes: 87% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 53 75 0.00% 0.00% 0.00% 0 Chunk Manager !--- Output suppressed. 25 8008 1329154 6 0.00% 0.00% 0.00% 0 Per-Second Jobs 26 413128 38493 10732 0.00% 0.02% 0.00% 0 Per-minute Jobs 27 148288424 354390017 418 2.60% 2.42% 2.77% 0 Cat4k Mgmt HiPri 28 285796820 720618753 396 50.15% 59.72% 61.31% 0 Cat4k Mgmt LoPri
步驟 2:使用命令檢查Catalyst 4500特定流show platform health程。
該命令的show platform health輸出確認使用CPU來處理繫結CPU的資料包。
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 4 100 500 0 0 0 0:00
K2CpuMan Review 30.00 27.39 30 53 100 500 42 47 42 4841:
K2AccelPacketMan: Tx 10.00 8.03 20 0 100 500 21 29 26 270:4
步驟 3:檢查接收流量的CPU隊列，以識別CPU繫結的流量型別。
若要判斷哪些流量會命中CPU，請發出show platform cpu packet statistics命令。
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 48613268 38 39 38 39 Control 142166648 74 74 73 73 Host Learning 1845568 2 2 2 2 L3 Fwd High 17 0 0 0 0 L3 Fwd Medium 2626 0 0 0 0 L3 Fwd Low 1582414 1 1 1 1 L2 Fwd Medium 1 0 0 0 0 L2 Fwd Low 576905398 1837 1697 1938 1515 L3 Rx High 257147 0 0 0 0 L3 Rx Low 5325772 10 19 13 7 RPF Failure 155 0 0 0 0 ACL fwd(snooping) 65604591 53 54 54 53 ACL log, unreach 11013420 9 8 8 8
步驟 4:確定根本原因。
由於管理員配置了IPX或AppleTalk路由，因此根本原因的確定必須直截了當。但是為了確認，請對CPU流量進行SPAN處理，並確保您看到的流量是預期的流量。有關CPU SPAN的資訊，請參閱工具1:使用SPAN - Cisco IOS軟體版本12.1(19)EW和更新版本監控CPU流量部分。
在這種情況下，管理員必須將基線CPU更新為當前值。Catalyst 4500 CPU處理軟體交換封包時的行為與預期相同。
主機學習
如果MAC地址表中沒有MAC地址，Catalyst 4500會獲取不同主機的MAC地址。交換引擎將包含新MAC地址的資料包副本轉發到CPU。
所有VLAN介面（第3層）都使用機箱基本硬體地址作為其MAC地址。因此，MAC地址表中沒有條目，而且發往這些VLAN介面的資料包不會傳送到CPU進行處理。
如果交換機要學習的新MAC地址數量過多，則可能導致CPU使用率高。
步驟 1:使用命令檢查Cisco IOS過show processes cpu程。
發出 show processes cpu此命令可檢查哪個Cisco IOS進程佔用了CPU。在此命令輸出中，請注意，頂部的進程是Cat4k Mgmt LoPri:
Switch#show processes cpu CPU utilization for five seconds: 89%/1%; one minute: 74%; five minutes: 71% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 53 75 0.00% 0.00% 0.00% 0 Chunk Manager !--- Output suppressed. 25 8008 1329154 6 0.00% 0.00% 0.00% 0 Per-Second Jobs 26 413128 38493 10732 0.00% 0.02% 0.00% 0 Per-minute Jobs 27 148288424 354390017 418 26.47% 10.28% 10.11% 0 Cat4k Mgmt HiPri 28 285796820 720618753 396 52.71% 56.79% 55.70% 0 Cat4k Mgmt LoPri
步驟 2:使用show platform health命令檢查特定於Catalyst 4500的進程。
show platform healthcommand的輸出確認使用CPU來處理繫結到CPU的資料包。
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 4 100 500 0 0 0 0:00
K2CpuMan Review 30.00 46.88 30 47 100 500 30 29 21 265:01
K2AccelPacketMan: Tx 10.00 8.03 20 0 100 500 21 29 26 270:4
步驟 3:檢查接收流量的CPU隊列，以識別CPU繫結的流量型別。
若要確定到達CPU的流量型別，請發出show platform cpu packet statistics命令。
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 48613268 38 39 38 39 Control 142166648 74 74 73 73 Host Learning 1845568 1328 1808 1393 1309 L3 Fwd High 17 0 0 0 0 L3 Fwd Medium 2626 0 0 0 0 L3 Fwd Low 1582414 1 1 1 1 L2 Fwd Medium 1 0 0 0 0 L2 Fwd Low 576905398 37 7 8 5 L3 Rx High 257147 0 0 0 0 L3 Rx Low 5325772 10 19 13 7 RPF Failure 155 0 0 0 0 ACL fwd(snooping) 65604591 53 54 54 53 ACL log, unreach 11013420 9 8 8 8
步驟 4:確定根本原因。
該命令的show platform health輸出顯示CPU看到許多新MAC地址。這種情況通常是由於網路拓撲不穩定造成的。例如，如果生成樹拓撲發生變化，交換機將生成拓撲更改通知(TCN)。 在PVST+模式下，TCN問題將老化時間縮短到15秒。如果在該時間段內未重新獲知地址，則會刷新MAC地址條目。在快速STP(RSTP)(IEEE 802.1w)或MST(IEEE 802.1s)的情況下，如果TCN來自另一台交換機，則條目立即過期。這種老化會導致重新獲取MAC地址。如果拓撲變化罕見，則這不是主要問題。但是，由於鏈路抖動、交換機故障或主機埠未啟用PortFast，拓撲更改可能會過多。可能會導致大量MAC表刷新和後續重新學習。確定根本原因的下一步是排除網路故障。交換器會按預期方式運作，並將封包傳送到CPU以進行主機位址學習。識別並修復導致過多TCN的故障裝置。
您的網路可以有許多裝置以脈衝串方式傳送流量，這會導致MAC位址老化，繼而在交換器上重新學習。在這種情況下，請增加MAC地址表老化時間，以便提供一些緩衝。隨著老化時間的延長，交換機在老化之前將裝置MAC地址保留在表中的時間更長。
注意：只有經過慎重考慮後，才能進行這種過時更改。如果網路中的裝置是移動的，則此更改可能導致流量黑洞。
安全ACL的硬體資源不足(TCAM)
Catalyst 4500使用Cisco TCAM對配置的ACL進行程式設計。TCAM允許在硬體轉發路徑中應用ACL。無論轉發路徑中是否包含ACL，對交換機的效能都沒有影響。無論ACL的大小如何，效能都是恆定的，因為ACL查詢的效能是以線速執行的。但是，TCAM資源有限。因此，如果您配置的ACL條目過多，則超過了TCAM容量。表3顯示了每個Catalyst 4500 Supervisor引擎和交換機上可用的TCAM資源數。
表3 - Catalyst 4500 Supervisor引擎/交換機上的TCAM容量
| 產品 | 功能TCAM（每個方向） | QoS TCAM（每個方向） |
|---|---|---|
| 管理引擎II+/II+TS | 具有1024個掩碼的8192個條目 | 具有1024個掩碼的8192個條目 |
| 管理引擎III/IV/V和Catalyst 4948 | 16,384個條目，帶2048掩碼 | 16,384個條目，帶2048掩碼 |
| 管理引擎V-10GE和Catalyst 4948-10GE | 16 384個條目，帶16 384個掩碼 | 16 384個條目，帶16 384個掩碼 |
交換器使用TCAM功能對安全ACL進行程式設計，例如RACL和VLAN ACL(VACL)。 交換器也使用TCAM功能提供安全功能，例如適用於動態ACL的IP來源防護(IPSG)。交換器使用QoS TCAM對分類和監察器ACL進行程式設計。
當在安全ACL的程式化過程中Catalyst 4500耗盡TCAM資源時，會透過軟體路徑套用ACL的一部分。命中這些ACE的資料包在軟體中處理，這會導致CPU使用率高。ACL是自上而下程式設計的。換句話說，如果ACL不適合TCAM，則ACL底部的ACE很可能不會在TCAM中進行程式設計。
發生TCAM溢位時，將顯示以下警告消息：
%C4K_HWACLMAN-4-ACLHWPROGERRREASON: (Suppressed 1times) Input(null, 12/Normal) Security: 140 - insufficient hardware TCAM masks. %C4K_HWACLMAN-4-ACLHWPROGERR: (Suppressed 4 times) Input Security: 140 - hardware TCAM limit, some packet processing can be software switched.
在show loggingcommand輸出中，可以看到以下錯誤消息。該消息明確表示可以執行某些軟體處理，因此可以有較高的CPU使用率。
附註：如果您變更了大型ACL，在TCAM中再次設定變更的ACL之前，您可以簡短看到以下訊息。
步驟 1:使用show processes cpu命令檢查Cisco IOS進程。
發出show processes cpucommand。您可以看到CPU使用率高，因為Cat4k Mgmt LoPriprocess佔用了大部分CPU週期。
Switch#show processes cpu CPU utilization for five seconds: 99%/0%; one minute: 99%; five minutes: 99% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 11 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 9716 632814 15 0.00% 0.00% 0.00% 0 Load Meter 3 780 302 2582 0.00% 0.00% 0.00% 0 SpanTree Helper !--- Output suppressed. 23 18208 3154201 5 0.00% 0.00% 0.00% 0 TTY Background 24 37208 3942818 9 0.00% 0.00% 0.00% 0 Per-Second Jobs 25 1046448 110711 9452 0.00% 0.03% 0.00% 0 Per-minute Jobs 26 175803612 339500656 517 4.12% 4.31% 4.48% 0 Cat4k Mgmt HiPri 27 835809548 339138782 2464 86.81% 89.20% 89.76% 0 Cat4k Mgmt LoPri 28 28668 2058810 13 0.00% 0.00% 0.00% 0 Galios Reschedul
步驟 2:使用命令檢查Catalyst 4500特定進show platform health程。
發出命show platform health令。您可以看到K2CpuMan Review（一個處理CPU繫結資料包的作業）使用CPU。
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.01 2 0 100 500 0 0 0 13:45
GalChassisVp-review 3.00 0.20 10 16 100 500 0 0 0 88:44
S2w-JobEventSchedule 10.00 0.57 10 7 100 500 1 0 0 404:22
Stub-JobEventSchedul 10.00 0.00 10 0 100 500 0 0 0 0:00
StatValueMan Update 1.00 0.09 1 0 100 500 0 0 0 91:33
Pim-review 0.10 0.00 1 0 100 500 0 0 0 4:46
Ebm-host-review 1.00 0.00 8 4 100 500 0 0 0 14:01
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:20
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:01
Acl-Flattener 1.00 0.00 10 5 100 500 0 0 0 0:04
KxAclPathMan create/ 1.00 0.00 10 5 100 500 0 0 0 0:21
KxAclPathMan update 2.00 0.00 10 6 100 500 0 0 0 0:05
KxAclPathMan reprogr 1.00 0.00 2 1 100 500 0 0 0 0:00
TagMan-InformMtegRev 1.00 0.00 5 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 14 100 500 0 0 0 0:18
K2CpuMan Review 30.00 91.31 30 92 100 500 128 119 84 13039:02
K2AccelPacketMan: Tx 10.00 2.30 20 0 100 500 2 2 2 1345:30
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
步驟 3:檢查接收流量的CPU隊列，以識別CPU繫結的流量型別。
您需要進一步瞭解哪個CPU隊列，以及哪些型別的流量會命中CPU隊列。發出how platform cpu packet statistics 命令。您可以看到ACL sw processingqueue收到大量資料包。因此，TCAM溢位是此高CPU利用率問題的原因。
Switch#show platform cpu packet statistics !--- Output suppressed. Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Control 57902635 22 16 12 3 Host Learning 464678 0 0 0 0 L3 Fwd Low 623229 0 0 0 0 L2 Fwd Low 11267182 7 4 6 1 L3 Rx High 508 0 0 0 0 L3 Rx Low 1275695 10 1 0 0 ACL fwd(snooping) 2645752 0 0 0 0 ACL log, unreach 51443268 9 4 5 5 ACL sw processing 842889240 1453 1532 1267 1179 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- L2 Fwd Low 3270 0 0 0 0 ACL sw processing 12636 0 0 0 0
步驟 4:解決問題。
在步驟3中，您確定了此情況的根本原因。刪除導致溢位的ACL或將ACL最小化以避免溢位。此外，請參閱使用ACL配置網絡安全配置指南，以最佳化硬體中的ACL配置和程式設計。
ACL中的log關鍵字
Catalyst 4500支援記錄到達任何特定ACL條目的資料包詳細資訊，但日誌記錄過多會導致CPU使用率高。避免使用oflogkeywords（流量發現階段除外）。在流量發現階段，您識別流經您網路但尚未明確配置ACE的流量。請勿使用thelogkeyword來收集統計資訊。在Cisco IOS軟體版本12.1(13)EW和更新版本中，訊息是速率限制的。如果使用elogmessages來計數與ACL相符的封包數量，則計數不準確。相反，請使用命令show access-list獲取準確的統計資訊。更容易確定此根本原因，因為檢視配置日誌消息可以指示ACL日誌記錄功能的使用。
步驟 1:使用show processes cpu命令檢查Cisco IOS進程。
發出show processes cpu以檢查哪個Cisco IOS進程佔用CPU。在此命令輸出中，您會發現頂端程序是Cat4k Mgmt LoPri:
Switch#show processes cpu CPU utilization for five seconds: 99%/0%; one minute: 99%; five minutes: 99% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 11 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 9716 632814 15 0.00% 0.00% 0.00% 0 Load Meter !--- Output suppressed. 26 175803612 339500656 517 4.12% 4.31% 4.48% 0 Cat4k Mgmt HiPri 27 835809548 339138782 2464 86.81% 89.20% 89.76% 0 Cat4k Mgmt LoPri 28 28668 2058810 13 0.00% 0.00% 0.00% 0 Galios Reschedul
步驟 2:使用show platform health命令檢查特定於Catalyst 4500的進程。
檢查使用CPU的平台特定進程。發出命show platform health令。在輸出中，請注意K2CpuMan Reviewprocess使用了大部分CPU週期。此活動表示CPU在處理髮往它的封包時正忙。
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.01 2 0 100 500 0 0 0 13:45
GalChassisVp-review 3.00 0.20 10 16 100 500 0 0 0 88:44
S2w-JobEventSchedule 10.00 0.57 10 7 100 500 1 0 0 404:22
Stub-JobEventSchedul 10.00 0.00 10 0 100 500 0 0 0 0:00
StatValueMan Update 1.00 0.09 1 0 100 500 0 0 0 91:33
Pim-review 0.10 0.00 1 0 100 500 0 0 0 4:46
Ebm-host-review 1.00 0.00 8 4 100 500 0 0 0 14:01
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:20
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:01
Acl-Flattener 1.00 0.00 10 5 100 500 0 0 0 0:04
KxAclPathMan create/ 1.00 0.00 10 5 100 500 0 0 0 0:21
KxAclPathMan update 2.00 0.00 10 6 100 500 0 0 0 0:05
KxAclPathMan reprogr 1.00 0.00 2 1 100 500 0 0 0 0:00
TagMan-InformMtegRev 1.00 0.00 5 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 14 100 500 0 0 0 0:18
K2CpuMan Review 30.00 91.31 30 92 100 500 128 119 84 13039:02
K2AccelPacketMan: Tx 10.00 2.30 20 0 100 500 2 2 2 1345:30
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
步驟 3:檢查接收流量的CPU隊列，以識別CPU繫結的流量型別。
要確定到達CPU的流量型別，請發出命 show platform cpu packet statistics令。在此命令輸出中，可以看到接收封包是由ACLlogkeyword所致：
Switch#show platform cpu packet statistics !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ----------------- -------------------- --------- --------- --------- ---------- Control 1198701435 35 35 34 35 Host Learning 874391 0 0 0 0 L3 Fwd High 428 0 0 0 0 L3 Fwd Medium 12745 0 0 0 0 L3 Fwd Low 2420401 0 0 0 0 L2 Fwd High 26855 0 0 0 0 L2 Fwd Medium 116587 0 0 0 0 L2 Fwd Low 317829151 53 41 31 31 L3 Rx High 2371 0 0 0 0 L3 Rx Low 32333361 7 1 2 0 RPF Failure 4127 0 0 0 0 ACL fwd (snooping) 107743299 4 4 4 4 ACL log, unreach 1209056404 1987 2125 2139 2089 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ----------------- -------------------- --------- --------- --------- ---------- ACL log, unreach 193094788 509 362 437 394
步驟 4:解決問題。
在步驟3中，您確定了此情況的根本原因。若要防止此問題，請從ACL中移除thelogkeyword。在Cisco IOS軟體版本12.1(13)EW1和更新版本中，封包是受速率限制的，因此CPU使用率不會變得過高。使用存取清單計數器作為記錄ACL命中的方法。您可以在中檢視訪問清單計數器 show access-list acl_id命令輸出。
第2層轉送環路
生成樹協定(STP)實施不力以及可能影響STP的各種問題可能會導致第2層轉發環路。
步驟 1:使用命令檢查Cisco IOS流show processes cpu程
本節介紹管理員使用的命令，以縮小CPU使用率較高的問題。如果您發出show processes cpu命令，則可以看到兩個主要進程(Cat4k Mgmt LoPriandSpanning Tree)主要使用CPU。僅使用此資訊時，您就可以知道生成樹進程佔用了相當大一部分的CPU週期。
Switch#show processes cpu CPU utilization for five seconds: 74%/1%; one minute: 73%; five minutes: 50% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 198 20 0.00% 0.00% 0.00% 0 Chunk Manager 2 4 290 13 0.00% 0.00% 0.00% 0 Load Meter !--- Output suppressed. 25 488 33 14787 0.00% 0.02% 0.00% 0 Per-minute Jobs 26 90656 223674 405 6.79% 6.90% 7.22% 0 Cat4k Mgmt HiPri 27 158796 59219 2681 32.55% 33.80% 21.43% 0 Cat4k Mgmt LoPri 28 20 1693 11 0.00% 0.00% 0.00% 0 Galios Reschedul 29 0 1 0 0.00% 0.00% 0.00% 0 IOS ACL Helper 30 0 2 0 0.00% 0.00% 0.00% 0 NAM Manager !--- Output suppressed. 41 0 1 0 0.00% 0.00% 0.00% 0 SFF8472 42 0 2 0 0.00% 0.00% 0.00% 0 AAA Dictionary R 43 78564 20723 3791 32.63% 30.03% 17.35% 0 Spanning Tree 44 112 999 112 0.00% 0.00% 0.00% 0 DTP Protocol 45 0 147 0 0.00% 0.00% 0.00% 0 Ethchnl
步驟 2:使用show platform health命令檢查Catalyst 4500特定進程
若要瞭解哪個平台特定的進程會消耗CPU，請發出show platform health命令。從該輸出中，您可以看到K2CpuMan Reviewprocess（一個處理CPU繫結資料包的作業）耗盡了CPU:
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
!--- Output suppressed.
TagMan-RecreateMtegR 1.00 0.00 10 0 100 500 0 0 0 0:00
K2CpuMan Review 30.00 37.62 30 53 100 500 41 33 1 2:12
K2AccelPacketMan: Tx 10.00 4.95 20 0 100 500 5 4 0 0:36
K2AccelPacketMan: Au 0.10 0.00 0 0 100 500 0 0 0 0:00
K2AclMan-taggedFlatA 1.00 0.00 10 0 100 500 0 0 0 0:00
步驟 3:檢查接收流量的CPU隊列，以識別CPU繫結的流量型別
發出show platform cpu packet statistics命令，以檢查哪個CPU隊列接收到CPU繫結的資料包。本節中的輸出顯示，控制佇列接收許多封包。使用表1中的資訊和步驟1中得出的結論。可以確定CPU處理的資料包以及CPU使用率較高的原因是BPDU處理。
Switch#show platform cpu packet statistics !--- Output suppressed. Total packet queues 16 Packets Received by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Esmp 202760 196 173 128 28 Control 388623 2121 1740 598 16 Packets Dropped by Packet Queue Queue Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Control 17918 0 19 24 3
步驟 4:確定根本原因並解決問題
通常，您可以完成以下步驟來進行疑難排解（視情況而定，某些步驟並非必需）：
-
確定環路。
-
發現環路的範圍。
-
中斷循環。
-
修復環路的原因。
-
恢復冗餘。
排除轉發環路故障 — 排除運行Cisco IOS系統軟體的Catalyst交換機上的STP故障中，詳細說明了每個步驟。
步驟 5:實施高級STP功能
-
BDPU防護 — 保護STP免受連線到已啟用portfast的埠的未授權網路裝置的影響。如需詳細資訊，請參閱跨距樹狀目錄PortFast BPDU防護增強功能。
-
環路防護 — 提高第2層網路的穩定性。如需詳細資訊，請參閱使用回圈防護和BPDU歪斜偵測功能的跨距樹狀目錄通訊協定增強功能。
-
根防護 — 強制在網路中放置根網橋。如需詳細資訊，請參閱跨距樹狀目錄通訊協定根防護增強功能。
-
UDLD — 檢測單向鏈路並防止轉發環路。如需詳細資訊，請參閱瞭解和設定單向連結偵測通訊協定功能。
CPU使用率高的其他原因
以下是導致CPU使用率較高的其他已知原因：
-
大型ACL程式設計期間的峰值
CPU使用率的峰值出現在應用或從介面中刪除大型ACL的過程中。
連結翻動過多
當一個或多個連線的鏈路開始過度擺動時，Catalyst 4500顯示較高的CPU利用率。低於Cisco IOS軟體版本12.2(20)EWA的Cisco IOS軟體版本會出現這種情況。
步驟 1:使用show processes cpu命令檢查Cisco IOS進程。
發出show processes命令，以檢查哪個Cisco IOS進程佔用CPU。在此命令輸出中，請注意，頂端程序為Cat4k Mgmt LoPri:
Switch#show processes cpu CPU utilization for five seconds: 96%/0%; one minute: 76%; five minutes: 68% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 2 9840 463370 21 0.00% 0.00% 0.00% 0 Load Meter 3 0 2 0 0.00% 0.00% 0.00% 0 SNMP Timers !--- Output suppressed. 27 232385144 530644966 437 13.98% 12.65% 12.16% 0 Cat4k Mgmt HiPri 28 564756724 156627753 3605 64.74% 60.71% 54.75% 0 Cat4k Mgmt LoPri 29 9716 1806301 5 0.00% 0.00% 0.00% 0 Galios Reschedul
步驟 2:使用show platform health命令檢查特定於Catalyst 4500的進程。
show platform healthcommand的輸出表示KxAclPathMan createprocess耗盡CPU。此程式用於內部路徑建立。
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.03 2 0 100 500 0 0 0 9:49
GalChassisVp-review 3.00 1.11 10 62 100 500 0 0 0 37:39
S2w-JobEventSchedule 10.00 2.85 10 8 100 500 2 2 2 90:00
Stub-JobEventSchedul 10.00 5.27 10 9 100 500 4 4 4 186:2
Pim-review 0.10 0.00 1 0 100 500 0 0 0 2:51
Ebm-host-review 1.00 0.00 8 4 100 500 0 0 0 8:06
Ebm-port-review 0.10 0.00 1 0 100 500 0 0 0 0:14
Protocol-aging-revie 0.20 0.00 2 0 100 500 0 0 0 0:00
Acl-Flattener 1.00 0.00 10 5 100 500 0 0 0 0:00
KxAclPathMan create/ 1.00 69.11 10 5 100 500 42 53 22 715:0
KxAclPathMan update 2.00 0.76 10 6 100 500 0 0 0 86:00
KxAclPathMan reprogr 1.00 0.00 2 1 100 500 0 0 0 0:00
TagMan-InformMtegRev 1.00 0.00 5 0 100 500 0 0 0 0:00
TagMan-RecreateMtegR 1.00 0.00 10 227 100 500 0 0 0 0:00
K2CpuMan Review 30.00 8.05 30 57 100 500 6 5 5 215:0
K2AccelPacketMan: Tx 10.00 6.86 20 0 100 500 5 5 4 78:42
步驟 3:確定根本原因。
為鏈路開啟/關閉消息啟用日誌記錄。預設情況下未啟用此日誌記錄。啟用功能有助於您迅速縮小違規連結。在所有介面下發出logging event link-statuscommand。您可以使用interface範圍命令，以方便在一系列介面上啟用，如以下範例所示：
Switch#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Switch(config)#interface range gigabitethernet 5/1 - 48 Switch(config-if-range)#logging event link-status Switch(config--if-range)#end
Switch#show logging !--- Output suppressed. 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to down 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to up 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to down 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to up 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to down 3w5d: %LINK-3-UPDOWN: Interface GigabitEthernet5/24, changed state to up
識別出有故障的或擺動的介面後，關閉該介面以解決CPU使用率較高的問題。Cisco IOS軟體版本12.2(20)EWA和更新版本已改善此抖動連結條件的Catalyst 4500行為。因此，對CPU的影響沒有改進前那麼大。請記住，此進程是後台進程。由於此問題而導致的CPU使用率較高不會對Catalyst 4500交換機造成不利影響。
由於FIB一致性檢查導致的CPU使用率峰值
Catalyst 4500可以在FIB表一致性檢查期間顯示CPU使用率的瞬時峰值。FIB表是CEF進程建立的L3轉發表。一致性檢查可維護Cisco IOS軟體FIB表和硬體條目之間的一致性。這種一致性可確保資料包不會發生錯誤路由。檢查每2秒執行一次，並以低優先順序後台進程運行。此進程是正常行為，不會干擾其他高優先順序進程或資料包。
show platform healthcommand的輸出顯示K2Fib Consistency Chaps佔用大部分CPU。
注意：此進程的平均CPU利用率在一分鐘或一小時內不顯著，這確認檢查是短暫的定期檢查。此後台進程僅使用空閒CPU週期。
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
!--- Output suppressed.
K2Fib cam usage revi 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib IrmFib Review 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Default Ro 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib AdjRepop Revie 2.00 0.00 15 0 100 500 0 0 0 0:00
K2Fib Vrf Unpunt Rev 2.00 0.01 15 0 100 500 0 0 0 0:23
K2Fib Consistency Ch 1.00 60.40 5 2 100 500 0 0 0 100:23
K2FibAdjMan Stats Re 2.00 0.30 10 4 100 500 0 0 0 6:21
K2FibAdjMan Host Mov 2.00 0.00 10 4 100 500 0 0 0 0:00
K2FibAdjMan Adj Chan 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibMulticast Signa 2.00 0.01 10 2 100 500 0 0 0 2:04
K2FibAdjMan主機移動進程中的CPU使用率高
Catalyst 4500可在K2FibAdjMan主機移動過程中顯示CPU使用率較高。此高使用率出現在show platform healthcommand的輸出中。許多MAC地址經常過期或在新埠上獲知，這會導致高CPU利用率。mac-address-table aging-time的預設值為5分鐘或300秒。此問題的解決方法是增加MAC地址老化時間，或者可以設計網路以避免大量的MAC地址移動。Cisco IOS軟體版本12.2(18)EW和更新版本已增強此程式行為，以便耗用更少的CPU。請參閱Cisco錯誤IDCSCed15021。
附註：只有註冊的思科使用者才能訪問內部思科工具和資訊。
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
S2w-JobEventSchedule 10.00 0.32 10 7 100 500 0 0 0 10:14
!--- Output suppressed.
K2FibAdjMan Stats Re 2.00 0.30 10 4 100 500 0 0 0 6:21
K2FibAdjMan Host Mov 2.00 18.68 10 4 100 500 25 29 28 2134:39
K2FibAdjMan Adj Chan 2.00 0.00 10 0 100 500 0 0 0 0:00
K2FibMulticast Signa 2.00 0.01 10 2 100 500 0 0 0 2:04
K2FibMulticast Entry 2.00 0.00 10 7 100 500 0 0 0 0:00
您可以在全域性配置模式下修改MAC地址的最長老化時間。命令語法ismac-address-table aging-time秒（對於路由器）和mac-address-table aging-time seconds [vlan vlan-id]（對於Catalyst交換機）。有關詳細資訊，請參閱Cisco IOS交換服務命令參考指南。
RkiosPortMan埠審查進程中的CPU使用率高
Catalyst 4500可以在Cisco IOS軟體版本12.2(25)EWA和12.2(25)EWA1的show platform 命令輸出中，在RkiosPortMan連線埠Reviewprocess中顯示高CPU使用率。Cisco錯誤IDCSCeh08768會導致高使用率，Cisco IOS軟體版本12.2(25)EWA2會解決高使用率。此程式是背景程式，並不影響Catalyst 4500交換器的穩定性。
附註：只有註冊的思科使用者才能訪問內部思科工具和資訊。
Switch#show platform health
%CPU %CPU RunTimeMax Priority Average %CPU Total
Target Actual Target Actual Fg Bg 5Sec Min Hour CPU
Lj-poll 1.00 0.02 2 1 100 500 0 0 0 1:09
GalChassisVp-review 3.00 0.29 10 3 100 500 0 0 0 11:15
S2w-JobEventSchedule 10.00 0.32 10 7 100 500 0 0 0 10:14
!--- Output suppressed.
K2 Packet Memory Dia 2.00 0.00 15 8 100 500 0 1 1 45:46
K2 L2 Aging Table Re 2.00 0.12 20 3 100 500 0 0 0 7:22
RkiosPortMan Port Re 2.00 87.92 12 7 100 500 99 99 89 1052:36
Rkios Module State R 4.00 0.02 40 1 100 500 0 0 0 1:28
Rkios Online Diag Re 4.00 0.02 40 0 100 500 0 0 0 1:15
使用中繼埠連線到IP電話時的CPU使用率高
如果為語音VLAN選項和接入VLAN選項配置了埠，則該埠充當多VLAN接入埠。其優勢在於，只有為語音和接入VLAN選項配置的VLAN才會建立中繼。
連線到電話的VLAN會增加STP例項的數量。交換機管理STP例項。對STP例項增加的管理，也會提高STP CPU利用率。
所有VLAN的中繼還會導致不必要的廣播、組播和未知的單點傳播流量到達電話鏈路。
Switch#show processes cpu CPU utilization for five seconds: 69%/0%; one minute: 72%; five minutes: 73% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 1 4 165 24 0.00% 0.00% 0.00% 0 Chunk Manager 2 29012 739091 39 0.00% 0.00% 0.00% 0 Load Meter 3 67080 13762 4874 0.00% 0.00% 0.00% 0 SpanTree Helper 4 0 1 0 0.00% 0.00% 0.00% 0 Deferred Events 5 0 2 0 0.00% 0.00% 0.00% 0 IpSecMibTopN 6 4980144 570766 8725 0.00% 0.09% 0.11% 0 Check heaps 26 539173952 530982442 1015 13.09% 13.05% 13.20% 0 Cat4k Mgmt HiPri 27 716335120 180543127 3967 17.61% 18.19% 18.41% 0 Cat4k Mgmt LoPri 33 1073728 61623 17424 0.00% 0.03% 0.00% 0 Per-minute Jobs 34 1366717824 231584970 5901 38.99% 38.90% 38.92% 0 Spanning Tree 35 2218424 18349158 120 0.00% 0.03% 0.02% 0 DTP Protocol 36 5160 369525 13 0.00% 0.00% 0.00% 0 Ethchnl 37 271016 2308022 117 0.00% 0.00% 0.00% 0 VLAN Manager 38 958084 3965585 241 0.00% 0.01% 0.01% 0 UDLD 39 1436 51011 28 0.00% 0.00% 0.00% 0 DHCP Snooping 40 780 61658 12 0.00% 0.00% 0.00% 0 Port-Security 41 1355308 12210934 110 0.00% 0.01% 0.00% 0 IP Input
使用RSPAN和第3層控制封包的CPU使用率高
使用RSPAN擷取的第3層控制封包是以CPU目的地，而不是僅以RSPAN目的地介面為目標，這會導致高CPU。L3控制資料包由靜態CAM條目通過轉發至CPU操作捕獲。靜態CAM條目對所有VLAN都是全域性的。為了避免不必要的CPU泛洪，請使用Cisco IOS軟體版本12.2(37)SG和更新版本中提供的每VLAN控制流量攔截功能。
Switch(config)#access-list hardware capture mode vlan
靜態ACL安裝在輸入功能TCAM的頂部，以捕獲發往224.0.0.*範圍內公認IP組播地址的控制資料包。靜態ACL會在啟動時安裝，並顯示在任何使用者配置的ACL之前。靜態ACL總是首先命中，並攔截發往所有VLAN上CPU的控制流量。
每個VLAN控制流量攔截功能提供選擇性每個VLAN路徑管理模式，用於捕獲控制流量。輸入特徵TCAM中相應的靜態CAM條目在新模式下失效。控制封包是由附加到已啟用窺探或路由功能的VLAN的功能特定ACL擷取。RSPAN VLAN沒有附加任何功能特定ACL。因此，從RSPAN VLAN接收的所有第3層控制封包不會轉送到CPU。
用於分析發往CPU的流量的故障排除工具
如本檔案所示，目的地為CPU的流量是Catalyst 4500上CPU使用率高的主要原因之一。目的地為CPU的流量可能是由於配置而有意為的，也可能是由於配置錯誤或拒絕服務攻擊而無意造成的。CPU具有內建QoS機制，可防止由於此流量而導致任何不利的網路影響。但是，請確定CPU繫結的流量的根本原因，並在不需要時消除流量。
工具1:使用SPAN - Cisco IOS軟體版本12.1(19)EW和更新版本監控CPU流量
Catalyst 4500允許使用標準SPAN功能監控與CPU繫結的流量（入口或出口）。目的地介面會連線到執行封包監聽器軟體的封包監控器或管理員膝上型電腦。此工具有助於快速準確地分析CPU處理的流量。該工具能夠監控繫結到CPU資料包引擎的各個隊列。
附註：交換引擎有32個隊列用於CPU流量，而CPU資料包引擎有16個隊列。
Switch(config)#monitor session 1 source cpu ?
both Monitor received and transmitted traffic
queue SPAN source CPU queue
rx Monitor received traffic only
tx Monitor transmitted traffic only
<cr>
Switch(config)#monitor session 1 source cpu queue ?
<1-32> SPAN source CPU queue numbers
acl Input and output ACL [13-20]
adj-same-if Packets routed to the incoming interface [7]
all All queues [1-32]
bridged L2/bridged packets [29-32]
control-packet Layer 2 Control Packets [5]
mtu-exceeded Output interface MTU exceeded [9]
nfl Packets sent to CPU by netflow (unused) [8]
routed L3/routed packets [21-28]
rpf-failure Multicast RPF Failures [6]
span SPAN to CPU (unused) [11]
unknown-sa Packets with missing source address [10]
Switch(config)#monitor session 1 source cpu queue all rx
Switch(config)#monitor session 1 destination interface gigabitethernet 1/3
Switch(config)#end
4w6d: %SYS-5-CONFIG_I: Configured from console by console
Switch#show monitor session 1
Session 1
---------
Type : Local Session
Source Ports :
RX Only : CPU
Destination Ports : Gi1/3
Encapsulation : Native
Ingress : Disabled
Learning : Disabled
如果連線到執行監聽器程式的PC，便可以快速分析流量。在本節視窗顯示的輸出中，您可以看到CPU使用率高的原因是STP BPDU數量過多。
附註：CPU監聽器中的STP BPDU是正常的。但是，如果您看到的內容超出預期，則表明您已經超出了Supervisor Engine的建議限制。如需詳細資訊，請參閱本檔案的大量跨距樹狀目錄連線埠例項一節。
CPU使用率過高是STP BPDU數量過多
工具2:內建CPU監聽器 — Cisco IOS軟體版本12.2(20)EW及更新版本
Catalyst 4500提供內建CPU監聽器和解碼器，以快速識別到達CPU的流量。您可以使用命令啟debug 用此工具，如本節中的示例所示。此功能實現了一個循環緩衝區，一次可保留1024個資料包。新封包到達時，會覆寫舊封包。在排查CPU使用率高問題時可以安全使用此功能。
Switch#debug platform packet all receive buffer platform packet debugging is on Switch#show platform cpu packet buffered Total Received Packets Buffered: 36 ------------------------------------- Index 0: 7 days 23:6:32:37214 - RxVlan: 99, RxPort: Gi4/48 Priority: Crucial, Tag: Dot1Q Tag, Event: Control Packet, Flags: 0x40, Size: 68 Eth: Src 00-0F-F7-AC-EE-4F Dst 01-00-0C-CC-CC-CD Type/Len 0x0032 Remaining data: 0: 0xAA 0xAA 0x3 0x0 0x0 0xC 0x1 0xB 0x0 0x0 10: 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 0x63 0x28 20: 0x62 0x0 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 30: 0x63 0x28 0x62 0x80 0xF0 0x0 0x0 0x14 0x0 0x2 40: 0x0 0xF 0x0 0x0 0x0 0x0 0x0 0x2 0x0 0x63 Index 1: 7 days 23:6:33:180863 - RxVlan: 1, RxPort: Gi4/48 Priority: Crucial, Tag: Dot1Q Tag, Event: Control Packet, Flags: 0x40, Size: 68 Eth: Src 00-0F-F7-AC-EE-4F Dst 01-00-0C-CC-CC-CD Type/Len 0x0032 Remaining data: 0: 0xAA 0xAA 0x3 0x0 0x0 0xC 0x1 0xB 0x0 0x0 10: 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 0x63 0x28 20: 0x62 0x0 0x0 0x0 0x0 0x80 0x0 0x0 0x2 0x16 30: 0x63 0x28 0x62 0x80 0xF0 0x0 0x0 0x14 0x0 0x2 40: 0x0 0xF 0x0 0x0 0x0 0x0 0x0 0x2 0x0 0x63
附註：發出命令時，CPU使debug 用率始終接近100%。發出命令時，CPU使用率較高是正常debug 的。
工具3:識別將流量傳送到CPU的介面 — Cisco IOS軟體版本12.2(20)EW及更高版本
Catalyst 4500提供了另一個有用的工具，用於確定傳送流量/資料包以進行CPU處理的頂級介面。此工具可幫助您快速識別向CPU傳送大量廣播攻擊或其他拒絕服務攻擊的錯誤裝置。當您排查CPU使用率較高的問題時，也可安全地使用此功能。
Switch#debug platform packet all count platform packet debugging is on Switch#show platform cpu packet statistics !--- Output suppressed. Packets Transmitted from CPU per Output Interface Interface Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Gi4/47 1150 1 5 10 0 Gi4/48 50 1 0 0 0 Packets Received at CPU per Input Interface Interface Total 5 sec avg 1 min avg 5 min avg 1 hour avg ---------------------- --------------- --------- --------- --------- ---------- Gi4/47 23130 5 10 50 20 Gi4/48 50 1 0 0 0
附註：發出debug指令時，CPU使用率一律接近100%。發出debug指令時，CPU使用率較高是正常現象。
摘要
Catalyst 4500交換器會在硬體中處理高速率的IP第4版(IPv4)封包轉送。某些功能或異常可能會導致某些資料包通過CPU進程路徑轉發。Catalyst 4500使用複雜的QoS機制來處理受CPU限制的資料包。此機制確保了交換機的可靠性和穩定性，同時最大限度地提高了CPU用於軟體轉發資料包。Cisco IOS軟體版本12.2(25)EWA2和更新版本提供封包/程式處理以及記帳的額外增強功能。Catalyst 4500還具有足夠的命令和功能強大的工具，有助於識別CPU使用率較高的問題的根本原因。但是，在大多數情況下，Catalyst 4500上的CPU使用率高不會導致網路不穩定，也不會引起擔憂。
相關資訊
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
2.0 |
01-Aug-2023 |
重新認證 |
1.0 |
13-Jul-2005 |
初始版本 |
意見