排除由於SNMP進程而導致的CPU使用率較高的故障
簡介
本文描述一種結構化方法，用於對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上的負載。
- 降低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 |
初始版本 |
意見