由於SNMP進程導致的CPU使用率較高故障排除
簡介
本文描述一種結構化方法，用於對9800無線Lan控制器上的SNMP進程進行故障排除和解決CPU使用率高的問題。
採用元件
本文中的資訊係根據以下軟體和硬體版本：
- 無線控制器：運行17.09.03的C9800-80-K9
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。
日誌收集
識別CPU使用模式在收到連結到SNMP進程的CPU使用率較高的報告後，第一步是收集指定時間範圍內的詳細日誌。這將有助於建立CPU使用率模式或趨勢，這對於確定SNMP進程最活躍和最耗費資源的時間至關重要。
在開始收集日誌之前，必須收集用於支援故障排除過程的特定資訊。首先收集極少有關此問題的資訊。
- 系統是否出現峰值或持續高使用率？
- 兩種情況的利用率是多少？
- CPU使用率高的頻率是多少？
- 每個SNMP伺服器輪詢WLC的頻率如何？
- 誰是最大的說話者？
在10分鐘的時間間隔內，以兩分鐘的時間間隔收集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 的輸出已排序 | 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 Object Navigator，然後搜尋OID「bsnAPIfDBNoisePower」。
OID搜尋結果因此，現在您瞭解bsnAPIfDBNoisePower對象報告每個AP報告的每個通道的雜訊功率。由於WLC管理著大量的通道和AP，因此此OID生成的SNMP資料可能很大。當WLC為大量AP提供服務時，輪詢此OID生成的資料量可能很大。這會導致CPU使用率高，因為WLC會處理這些大量的SNMP請求。
同樣，您需要瞭解正在接受積極輪詢的特定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的頻率。在此示例中，每30秒輪詢一次OID，此頻率明顯高於所需的頻率。由於WLC每180秒接收一次RF/RRM資料，因此每30秒輪詢OID會導致不必要的處理並導致CPU使用率高。
一旦識別出有問題的OID和伺服器，我們可以嘗試多個不同的解決方案來減少WLC上的負載。
- 降低SNMP伺服器上的輪詢頻率。
- 如果操作使用不需要OID，請從SNMP伺服器禁用該OID的輪詢。
- 如果您對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利用率高的問題。實施後監控對於確認故障排除工作成功並維持最佳網路效能至關重要。
相關資訊
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
29-Jul-2024
|
初始版本 |
意見