目录

简介

使用的组件

日志收集

日志分析

SNMP视图配置

故障排除提示

结论

相关信息

简介

本文档介绍一种结构化方法，用于对9800无线局域网控制器上的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生成的数据量可能非常大。当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的频率。在本例中，每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使用率之间是否存在关联。

- 最近的更改：注意任何可能与CPU使用率较高起始时间重合的WLC配置或网络近期更改。

- 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系列配置最佳实践