目錄

簡介

必要條件

需求

採用元件

慣例

背景資訊

排除常見的CPU使用率較高的問題

IGMP離開消息風暴導致的CPU高

由於GRE通道而導致CPU使用率高

配置更改期間的CPU使用率高

由於ARP請求過多，導致高CPU

由於IP SNMP進程而導致CPU使用率高

SDM模板導致的CPU使用率高

基於策略的路由導致CPU使用率高

ICMP重定向過多導致CPU使用率高

相關資訊

簡介

本檔案將說明Cisco Catalyst 3750系列交換器上CPU使用率高的原因。與Cisco路由器類似，交換機使用show processes cpu命令來顯示CPU利用率，以確定CPU利用率高的原因。但是，由於Cisco路由器和交換機之間的體系結構和轉發機制存在差異，因此show processes cpu命令的典型輸出明顯不同。本文還列出導致Catalyst 3750系列交換器上CPU使用率較高的一些常見症狀。

必要條件

需求

本文件沒有特定需求。

採用元件

本檔案中的資訊是根據Catalyst 3750交換器。

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

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

背景資訊

在檢視CPU資料包處理架構和排除CPU使用率過高故障之前，必須瞭解基於硬體的轉發交換機和基於Cisco IOS®軟體的路由器使用CPU的不同方式。常見的誤解是CPU使用率高表示裝置上的資源耗盡和崩潰威脅。容量問題是Cisco IOS路由器上CPU使用率較高的症狀之一。但是，容量問題幾乎從來不是基於硬體的轉發交換機的CPU使用率較高的症狀。

排查CPU使用率高問題的第一步是檢查Catalyst 3750交換器的Cisco IOS版本版本說明中是否存在已知的IOS錯誤。如此一來，您就可以從疑難排解步驟中移除IOS錯誤。有關Catalyst 3750交換器的版本說明清單，請參閱Cisco Catalyst 3750系列交換器版本說明。

排除常見的CPU使用率較高的問題

本節介紹Catalyst 3750交換器上的一些常見高CPU使用率問題。

IGMP離開消息風暴導致的CPU高

CPU使用率較高的常見原因之一是Catalyst 3750 CPU正忙於處理網際網路組管理協定(IGMP)離開消息的風暴。如果執行Cisco IOS軟體版本12.1(14)EA1a的Catalyst 3750交換器堆疊連線到另一台交換器（例如執行CatOS的Cat6500）（其會使用IP選項產生基於MAC的IGMP查詢），則3750在IGMPSN（窺探）過程中會遇到高CPU使用率。這是堆疊中循環的基於MAC的查詢封包的結果。您還可以看到HRPC hl2mm請求進程的CPU使用率高。如果您在Catalyst 3750堆疊上使用Cisco IOS軟體版本12.1(14)EA1a設定了EtherChannel，可能會產生IGMP離開訊息風暴。

Catalyst 3750接收許多IGMP查詢。這使得IGMP查詢計數器開始以每秒數百的速度遞增。這會導致Catalyst 3750交換機中的CPU使用率較高。請參閱Cisco錯誤ID CSCeg55298(僅限註冊客戶)。 此錯誤是在Cisco IOS軟體版本12.1(14)EA1a中識別，並在Cisco IOS軟體版本12.2(25)SEA和更新版本中修正。永久解決方案是升級到最新的Cisco IOS版本。臨時解決方法是停用Catalyst 3750堆疊上的IGMP窺探，或停用連線到3750堆疊的交換器上基於MAC的查詢。

以下是show ip traffic命令的輸出範例，顯示具有錯誤選項的IP封包和快速遞增的警示：

Switch#show ip traffic

Rcvd: 48195018 total, 25628739 local destination

0 format errors, 0 checksum errors, 10231692 bad hop count

0 unknown protocol, 9310320 not a gateway

0 security failures, 10231 bad options, 2640539 with options

Opts: 2640493 end, 206 nop, 0 basic security, 2640523 loose source route

0 timestamp, 0 extended security, 16 record route

0 stream ID, 0 strict source route, 10231 alert, 0 cipso, 0 ump

0 other

Frags: 16 reassembled, 0 timeouts, 0 couldn't reassemble

32 fragmented, 0 couldn't fragment

Bcast: 308 received, 0 sent

Mcast: 4221007 received, 4048770 sent

Sent: 25342014 generated, 20710669 forwarded

Drop: 617267 encapsulation failed, 0 unresolved, 0 no adjacency

0 no route, 0 unicast RPF, 0 forced drop

0 options denied, 0 source IP address zero

!--- Output suppressed.

show processes cpu命令顯示有關交換機中的活動進程及其相應的CPU利用率統計資訊的資訊。這是CPU使用率正常時show processes cpu命令的輸出示例：

switch#show processes cpu

CPU utilization for five seconds: 8%/4%; one minute: 6%; five minutes: 5%

PID  Runtime(ms)  Invoked  uSecs   5Sec  1Min     5Min  TTY   Process

1      384       32789     11  0.00%  0.00%   0.00%   0    Load Meter

2     2752        1179   2334  0.73%  1.06%   0.29%   0    Exec

3   318592        5273  60419  0.00%  0.15%   0.17%   0    Check heaps

4        4           1   4000  0.00%  0.00%   0.00%   0    Pool Manager

5     6472        6568    985  0.00%  0.00%   0.00%   0    ARP Input

6    10892        9461   1151  0.00%  0.00%   0.00%   0    IGMPSN

!--- CPU utilization at normal condition.

7    67388       53244   1265  0.16%  0.04%   0.02%   0    CDP Protocol

8   145520      166455    874  0.40%  0.29%   0.29%   0    IP Background

9     3356        1568   2140  0.08%  0.00%   0.00%   0    BOOTP Server

10       32        5469      5  0.00%  0.00%   0.00%   0    Net Background

11    42256      163623    258  0.16%  0.02%   0.00%   0    Per-Second Jobs

12   189936      163623   1160  0.00%  0.04%   0.05%   0    Net Periodic

13     3248        6351    511  0.00%  0.00%   0.00%   0    Net Input

14      168       32790      5  0.00%  0.00%   0.00%   0    Compute load avgs

15   152408        2731  55806  0.98%  0.12%   0.07%   0    Per-minute Jobs

16        0           1      0  0.00%  0.00%   0.00%   0    HRPC hI2mm reque

!--- Output suppressed.

以下是show processes cpu命令輸出的示例，該命令是因為IGMP監聽進程而導致CPU使用率較高的：

switch#show processes cpu

CPU utilization for five seconds: 8%/4%; one minute: 6%; five minutes: 5%

PID  Runtime(ms)  Invoked  uSecs   5Sec  1Min     5Min  TTY   Process

1        384       32789     11  0.00%  0.00%   0.00%   0    Load Meter

2       2752        1179   2334  0.73%  1.06%   0.29%   0    Exec

3     318592        5273  60419  0.00%  0.15%   0.17%   0    Check heaps

4          4           1   4000  0.00%  0.00%   0.00%   0    Pool Manager

5       6472        6568    985  0.00%  0.00%   0.00%   0    ARP Input

6      10892        9461   1151    100    100     100   0    IGMPSN

!--- Due to high CPU utilization.

7      67388       53244   1265  0.16%  0.04%   0.02%   0    CDP Protocol

8     145520      166455    874  0.40%  0.29%   0.29%   0    IP Background

9       3356        1568   2140  0.08%  0.00%   0.00%   0    BOOTP Server

10         32        5469      5  0.00%  0.00%   0.00%   0    Net Background

11      42256      163623    258  0.16%  0.02%   0.00%   0    Per-Second Jobs

12     189936      163623   1160  0.00%  0.04%   0.05%   0    Net Periodic

13       3248        6351    511  0.00%  0.00%   0.00%   0    Net Input

14        168       32790      5  0.00%  0.00%   0.00%   0    Compute load avgs

15     152408        2731  55806  0.98%  0.12%   0.07%   0    Per-minute Jobs

16          0        2874      0    100    100     100   0    HRPC hI2mm reque

!--- Output suppressed.

由於GRE通道而導致CPU使用率高

Cisco Catalyst 3750系列交換器不支援通用路由封裝(GRE)通道。雖然可以使用CLI配置此功能，但資料包既不能通過硬體進行交換，也不能通過軟體進行交換，這會增加CPU利用率。

注意：Catalyst 3750中的組播路由僅支援距離向量組播路由協定(DVMRP)隧道介面。即使如此，也不能使用硬體交換資料包。透過此通道路由的封包必須透過軟體交換。通過此通道轉發的較大資料包數會增加CPU利用率。

此問題沒有解決方法。這是Catalyst 3750系列交換器中的硬體限制。

配置更改期間的CPU使用率高

如果Catalyst 3750交換器連線在一個堆疊中，且如果對交換器進行任何組態變更，hulc running config流程將喚醒並產生執行組態的新副本。然後傳送到堆疊中的所有交換器。新的運行配置是CPU密集型。因此，構建新的運行配置進程以及將新配置轉發到其他交換機時，CPU使用率較高。但是，此高CPU使用率應只存在於執行show running-configuration命令中的構建配置步驟所需的相同時間內。

此問題不需要解決方法。在這些情況下，CPU使用率通常較高。

以下是show processes cpu命令輸出的示例，該命令在CPU利用率因運行hulc進程而高時執行命令：

switch#show processes cpu

CPU utilization for five seconds: 63%/0%; one minute: 27%; five minutes: 23%

PID Runtime(ms) Invoked   uSecs   5Sec   1Min   5Min   TTY   Process

1      384      32789      11  0.00%  0.00%   0.00%   0    Load Meter

2     2752       1179    2334  0.73%  1.06%   0.29%   0    Exec

3   318592       5273   60419  0.00%  0.15%   0.17%   0    Check heaps

4        4          1    4000  0.00%  0.00%   0.00%   0    Pool Manager

5     6472       6568     985  0.00%  0.00%   0.00%   0    ARP Input

6    10892       9461    1151  0.00%  0.00%   0.00%   0    IGMPSN

7    67388      53244    1265  0.16%  0.04%   0.02%   0    CDP Protocol

8   145520     166455     874  0.40%  0.29%   0.29%   0    IP Background

9     3356       1568    2140  0.08%  0.00%   0.00%   0    BOOTP Server

10       32       5469       5  0.00%  0.00%   0.00%   0    Net Background

11    42256     163623     258  0.16%  0.02%   0.00%   0    Per-Second Jobs

12   189936     163623    1160  0.00%  0.04%   0.05%   0    Net Periodic

13     3248       6351     511  0.00%  0.00%   0.00%   0    Net Input

14      168      32790       5  0.00%  0.00%   0.00%   0    Compute load avgs

15   152408       2731   55806  0.98%  0.12%   0.07%   0    Per-minute Jobs

16        0          1       0  0.00%  0.00%   0.00%   0    HRPC h12mm reque

17    85964        426  201793 55.72% 12.05%   5.36%   0    hulc running

!--- Output suppressed.

由於ARP請求過多，導致高CPU

如果路由器必須發出過量的ARP請求，則會發生地址解析協定(ARP)輸入進程的CPU使用率過高。對同一IP地址的ARP請求速率限製為每兩秒一個請求。因此，必須為不同的IP地址發出過多的ARP請求。如果已配置IP路由並指向廣播介面，則會發生這種情況。一個明顯的示例是預設路由，例如：

ip route 0.0.0.0 0.0.0.0 Fastethernet0/0

在這種情況下，路由器會為無法通過更具體路由訪問的每個IP地址生成ARP請求，這意味著路由器會為網際網路上的幾乎每個地址生成ARP請求。有關如何為靜態路由配置下一跳IP地址的詳細資訊，請參閱為靜態路由指定下一跳IP地址。

或者，惡意流量通過本地連線的子網進行掃描，可能會造成過多的ARP請求。這種流的一個指示是ARP表中存在大量不完整ARP條目。由於必須處理觸發ARP請求的傳入IP資料包，因此解決此問題與IP輸入過程中解決CPU使用率高問題實質上相同。

由於IP SNMP進程而導致CPU使用率高

在適用於Catalyst 3750的最新Cisco IOS版本中，簡易網路管理通訊協定(SNMP)要求由SNMP引擎處理。由於此SNMP ENGINE進程，CPU正常會變高。SNMP進程的優先順序較低，不應影響交換機上的任何功能。

請參閱IP簡易網路管理通訊協定(SNMP)導致高CPU使用率，以瞭解更多有關SNMP引擎進程導致高CPU使用率的資訊。

SDM模板導致的CPU使用率高

Catalyst 3750系列交換器上的交換器資料庫管理(SDM)管理在三重內容可定址記憶體(TCAM)中維護的第2層和第3層交換資訊。 SDM範本用於設定交換器中的系統資源，以最佳化對特定功能的支援，具體功能取決於交換器在網路中的使用方式。可以選擇SDM範本，以便為某些功能提供最大的系統使用量，或使用預設範本以平衡資源。這些模板將系統資源按優先順序排序，以最佳化對這些功能型別的支援：

- 路由 — 路由模板可最大化單播路由的系統資源，單播路由通常需要位於網路中心的路由器或聚合器。

- VLAN - VLAN模板禁用路由並支援最大數量的單播MAC地址。這通常為第2層交換機選擇。

- Access — 訪問模板可最大化訪問控制清單(ACL)的系統資源以容納大量ACL。

- 預設(Default) — 預設模板使所有函式保持平衡。

每個模板有兩個版本：案頭模板和聚合器模板。

註：桌面交換機的預設模板是預設案頭模板。Catalyst 3750-12S的預設模板是預設聚合器模板。

選擇適當的SDM模板，為使用的功能提供最大的系統使用率。不適當的SDM模板可能會使CPU過載並嚴重降低交換機效能。

發出show platform tcam utilization命令，檢視當前已利用的TCAM和可用的TCAM數量。

Switch#show platform tcam utilization

CAM Utilization for ASIC# 0                      Max            Used

Masks/Values    Masks/values

Unicast mac addresses:                        784/6272         12/26

IPv4 IGMP groups + multicast routes:          144/1152          6/26

IPv4 unicast directly-connected routes:       784/6272         12/26

IPv4 unicast indirectly-connected routes:     272/2176          8/44

IPv4 policy based routing aces:                 0/0             0/0

IPv4 qos aces:                                528/528          18/18

IPv4 security aces:                          1024/1024         27/27

Note: Allocation of TCAM entries per feature uses

a complex algorithm. The above information is meant

to provide an abstract view of the current TCAM utilization

如果任一引數的TCAM利用率接近最大值，請檢查任何其他模板功能是否可以對該引數進行最佳化。

show sdm prefer access | default | dual-ipv4-and-ipv6 | routing | vlan

Switch# show sdm prefer routing

"desktop routing" template:

The selected template optimizes the resources in

the switch to support this level of features for

8 routed interfaces and 1024 VLANs.

number of unicast mac addresses:             3K

number of igmp groups + multicast routes:    1K

number of unicast routes:                    11K

number of directly connected hosts:        3K

number of indirect routes:                 8K

number of policy based routing aces:         512

number of qos aces:                          512

number of security aces:                     1K

若要指定要在交換器上使用的SDM範本，請發出sdm prefer global configuration指令。

注意：要使用新的SDM模板，需要重新載入交換機。

基於策略的路由導致CPU使用率高

Cisco Catalyst 3750交換器中的原則型路由(PBR)實作有一些限制。如果不遵循這些限制，則可能會導致CPU使用率高。

- 您可以在路由埠或SVI上啟用PBR。

- 交換機不支援PBR的路由對映deny語句。

- 組播流量不是策略路由的。PBR僅適用於單播流量。

- 不要與允許資料包傳送到本地地址的ACL匹配。PBR轉發這些資料包，這可能導致ping或Telnet故障或路由協定抖動。

- 不要將ACL與拒絕ACE進行匹配。與deny ACE匹配的資料包將傳送到CPU，這可能導致CPU使用率高。

- 要使用PBR，必須首先使用sdm prefer routing 全域性配置命令啟用路由模板。VLAN或預設模板不支援PBR。

有關完整清單，請參閱PBR配置指南。

ICMP重定向過多導致CPU使用率高

當一個VLAN（或任何第3層連線埠）收到來源IP位於一個子網上、目的地IP位於另一個子網上，而下一個躍點位於同一個VLAN或第3層網段上的封包時，可以收到ICMP捨棄的重新導向。

以下是範例：

您可以在show log中看到以下訊息：

51w2d: ICMP-Q:Dropped redirect disabled on L3 IF: Local Port Fwding

L3If:Vlan7 L2If:GigabitEthernet2/0/13 DI:0xB4, LT:7, Vlan:7

SrcGPN:65, SrcGID:65, ACLLogIdx:0x0, MacDA:001a.a279.61c1,

MacSA: 0002.5547.3bf0  IP_SA:64.253.128.3 IP_DA:208.118.132.9 IP_Proto:47

TPFFD:EDC10041_02C602C6_00B0056A-000000B4_EBF6001B_0D8A3746

當封包在VLAN 7上使用來源IP 64.253.128.3接收並嘗試到達目的地IP 208.118.132.9時，會發生這種問題。您可以看到交換器中設定的下一個躍點（本例中為64.253.128.41）也位於同一個VLAN 7中。

相關資訊

- 瞭解 EtherChannel 不一致偵測

- 多點傳送在Catalyst交換器中的同一個VLAN中無法運作

- 執行CatOS軟體的Catalyst 4500/4000、2948G、2980G和4912G交換器上的CPU使用率

- Catalyst 6500/6000交換器CPU使用率高

- LAN 產品支援頁面

- LAN 交換支援頁面

- 技術支援與文件 - Cisco Systems