目录

简介

使用的组件

日志收集

日志分析

SNMP视图配置

故障排除提示

结论

相关信息

简介

本文档介绍一种结构化方法，用于对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 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 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上的负载。

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

- 使用Prime基础设施管理Catalyst 9800无线控制器系列（SNMP V2和V3以及NetCONF）

- 保护您的简单网络管理协议

- Cisco Catalyst 9800系列配置最佳实践