目錄

簡介

採用元件

日誌收集

日誌分析

SNMP檢視配置

疑難排解提示

結論

相關資訊

簡介

本文描述一種結構化方法，用於對9800無線Lan控制器上的SNMP進程進行故障排除和解決CPU使用率較高的故障。

採用元件

本文中的資訊係根據以下軟體和硬體版本：

- 無線控制器：運行17.09.03的C9800-80-K9

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

日誌收集

辨識CPU使用率模式當收到與SNMP進程連結的CPU使用率較高的報告時，第一個操作過程是收集指定時間範圍內的詳細日誌。這將有助於建立CPU使用率模式或趨勢，這對於確定SNMP進程最活躍和最耗費資源的時間至關重要。

在開始收集日誌之前，必須收集用於支援故障排除過程的特定資訊。首先收集少量關於此問題的資訊。

- 系統是否出現尖峰或持續高使用率？

- 這兩種情況下的利用率百分比是多少？

- 高CPU使用率的頻率是多少？

- 每個SNMP伺服器輪詢WLC的頻率如何？

- 最大流量生成者是誰？

在10分鐘的範圍內，以2分鐘的間隔收集9800 WLC的命令輸出。此資料可用於分析CPU使用率較高的問題，尤其是與SNMP進程有關的問題。

#terminal length 0

#show clock

#show process cpu sorted | exclude 0.0

#show process cpu history

#show processes cpu platform sorted | exclude 0.0

#show snmp stats oid

#show snmp stats hosts

日誌分析

收集這些日誌後，您必須對其進行分析以瞭解其影響。

我們來看一個示例CPU使用率日誌，確定佔用最多CPU的SNMP進程。

WLC#show process cpu sorted | exclude 0.0

CPU utilization for five seconds: 96%/7%; one minute: 76%; five minutes: 61%

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

250   621290375    58215467      10672 58.34% 39.84% 34.11%   0 SNMP LA Cache pr  <-- High utilization

93   167960640   401289855        418 14.50% 11.88%  9.23%   0 IOSD ipc task

739   141604259   102242639       1384  8.57%  6.95%  7.21%   0 SNMP ENGINE

763        7752       34896        222  4.00%  3.41%  1.83%   5 SSH Process

648     6216707   181047548         34  0.72%  0.37%  0.31%   0 IP SNMP

376     3439332    51690423         66  0.40%  0.36%  0.25%   0 SNMP Timers

143     3855538   107654825         35  0.40%  0.35%  0.23%   0 IOSXE-RP Punt Se

108     6139618    17345934        353  0.40%  0.30%  0.34%   0 DBAL EVENTS

show process cpu sorted命令的輸出 | exclude 0.0命令表明SNMP進程的確消耗了超出比例的CPU資源。具體而言，SNMP LA Cache pr進程是CPU使用率最高的進程，其次是其他與SNMP相關的進程。

下一組命令將幫助我們深入瞭解SNMP高使用率流程。

WLC#show snmp stats oid

time-stamp               #of times requested             OID

11:02:33 Austral Jun 8 2023      27698                   bsnAPIfDBNoisePower  <-- Frequently polled OID

11:02:23 Austral Jun 8 2023      1                       sysUpTime

11:02:23 Austral Jun 8 2023      17                      cLSiD11SpectrumIntelligenceEnable

11:02:23 Austral Jun 8 2023      1                       cLSiD11SpectrumIntelligenceEnable

11:02:23 Austral Jun 8 2023      6                       cLSiD11Band

11:02:23 Austral Jun 8 2023      1                       cLSiD11Band

11:02:23 Austral Jun 8 2023      1                       cLSiD11Band

11:02:23 Austral Jun 8 2023      1                       cLSiD11Band

11:02:19 Austral Jun 8 2023      24                      clcCdpApCacheApName

11:02:19 Austral Jun 8 2023      1                       clcCdpApCacheDeviceIndex

11:02:19 Austral Jun 8 2023      9                       cLApCpuAverageUsage

11:02:19 Austral Jun 8 2023      1315                    cLApCpuCurrentUsage

11:02:19 Austral Jun 8 2023      2550                    bsnAPIfDBNoisePower

show snmp stats oid命令的輸出顯示了輪詢各種OID的頻率。特定OID bsnAPIfDBNoisePower因其請求數量異常多而引人注目。這表示主動輪詢此OID很可能是造成WLC上觀察到的高CPU使用率的原因。

讓我們嘗試瞭解OID bsnAPIfDBNoisePower的作用及其資料儲存時間。

導航到SNMP對象導航器，然後搜尋OID「bsnAPIfDBNoisePower」。

OID搜尋結果

因此，現在您瞭解到bsnAPIfDBNoisePower對象會報告每個AP報告的每個通道的雜訊功率。鑑於WLC管理著大量的通道和AP，此OID生成的SNMP資料可能非常大。當WLC為大量AP提供服務時，透過輪詢此OID生成的資料量可能很大。隨著WLC處理這些大量的SNMP請求，這可能導致高CPU使用率。

同樣，您需要瞭解正在被主動輪詢的特定OID的行為。

下一個命令將幫助您瞭解輪詢WLC的SNMP伺服器。

WLC#show snmp stats hosts

Request Count    Last Timestamp  Address

77888844          00:00:00 ago   10.10.10.120

330242            00:00:08 ago   10.10.10.150

27930314          00:00:09 ago   10.10.10.130

839999            00:00:36 ago   10.10.10.170

6754377           19:45:34 ago   10.10.10.157

722               22:00:20 ago   10.10.10.11

此命令提供SNMP伺服器的清單及其請求計數和輪詢活動的最後時間戳。

您可以看到有多個不同的伺服器正在輪詢9800 WLC。如果您檢視過去10分鐘內收集的完整日誌資料，還可以測量它們的輪詢頻率。

現在，您可以訪問每台伺服器，檢視違規的OID輪詢的頻率。在此範例中，OID每30秒輪詢一次，這比必要的頻率高得多。由於WLC每180秒接收一次RF/RRM資料，因此每30秒輪詢OID會導致不必要的處理，並導致CPU使用率較高。

辨識出違規的OID和伺服器後，我們可以嘗試多個不同的解決方案，以降低WLC上的負載。

1. 降低SNMP伺服器上的輪詢頻率。

2. 如果作業使用不需要OID，請停用從SNMP伺服器輪詢該OID。

3. 如果您無法控制SNMP伺服器，則可以使用SNMP檢視阻止違規的OID。

SNMP檢視配置

定義排除要阻止的OID的新檢視。例如，您想要封鎖OID 1.3.6.1.4.1.14179.2.2.15.1.21、建立新檢視並將OID附加到檢視中。

snmp-server view blockOIDView 1.3.6.1.4.1.14179.2.2.15.1.21 excluded  <-- This is the OID of bsnAPIfDBNoisePower

snmp-server community TAC view blockOIDView RO <-- This command assigns the blockOIDView to the community myCommunity with read-only (RO) access.

snmp-server group TAC v3 priv read blockOIDView <-- This command assigns the blockOIDView to the group myGroup with the priv security level for SNMPv3.

疑難排解提示

- 基準CPU使用率：記錄SNMP進程未導致高使用率時的正常CPU使用率水準。

- SNMP配置：檢視當前SNMP配置設定，包括社群字串、版本（v2c或v3）和訪問清單。

- SNMP最佳實踐：使用9800 WLC最佳實踐文檔，並儘可能密切地匹配SNMP的建議配置。

C9800(config)#snmp-server subagent cache

C9800(config)#snmp-server subagent cache timeout ?

<1-100>  cache timeout interval (default 60 seconds)

- SNMP輪詢頻率：確定SNMP查詢輪詢WLC的頻率，因為高頻率可能導致CPU負載增加。

- 網路拓撲和SNMP管理器：瞭解網路設定並確定與WLC互動的所有SNMP管理器。

- 系統正常運行時間：檢查自上次重新啟動以來經過的時間，以檢視正常運行時間與CPU利用率之間是否存在關聯。

- 最近更改：注意最近對WLC配置或網路進行的任何更改，這些更改可能與CPU使用率過高發病的時間相吻合。

- 9800 WLC的重點在於遙測。遙測在「推送」模式下工作，WLC無需查詢即可向伺服器傳送相關資訊。如果您的SNMP查詢佔用WLC CPU週期並導致操作問題，則最好移至遙測模式。

結論

透過系統地分析CPU利用率資料並將其與SNMP輪詢活動關聯，您可以對Cisco 9800 WLC上的SNMP進程導致的CPU利用率過高問題進行故障排除和解決。實施後監控對於確認故障排除工作是否成功以及保持最佳網路效能至關重要。

相關資訊

- 使用OID透過SNMP監控Catalyst 9800 WLC

- 使用SNMP V2、V3和NetCONF的Prime基礎設施管理Catalyst 9800無線控制器系列

- 保護您的簡單網路管理協定

- Cisco Catalyst 9800系列配置最佳實踐