Introdução
Este documento descreve uma abordagem estruturada para solucionar problemas e resolver a alta utilização da CPU para o processo SNMP em um controlador de LAN sem fio 9800.
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- Controlador sem fio: C9800-80-K9 executando 17.09.03
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Coleção de logs
Identificando padrões de utilização da CPU Ao receber um relatório de alta utilização da CPU vinculado ao processo SNMP, o primeiro curso de ação é coletar logs detalhados em um período de tempo especificado. Isso vai ajudar a estabelecer um padrão ou tendência no uso da CPU, que é essencial para identificar os momentos em que o processo SNMP é mais ativo e consome mais recursos.
Antes de iniciar a coleta de logs, é essencial coletar informações específicas que sejam usadas para dar suporte ao processo de solução de problemas. Comece coletando poucas informações sobre o problema.
- O sistema está experimentando picos ou uso consistentemente alto?
- Qual é a % de utilização em ambos os casos?
- Qual é a frequência de alta utilização da CPU?
- Com que frequência cada servidor SNMP está sondando a WLC?
- Quem são os principais falantes?
Colete a saída do comando da WLC 9800 em intervalos de dois minutos em um intervalo de dez minutos. Esses dados podem ser usados para analisar problemas de alta utilização da CPU, especialmente aqueles relacionados ao processo 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
Análise de registros
Depois de coletar esses registros, você deve analisá-los para entender o impacto.
Vejamos um exemplo de registros de utilização da CPU e identifiquemos o processo SNMP que está consumindo a maior parte da CPU.
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
A saída do comando show process cpu sorted | exclude 0.0 indica que o processo SNMP está realmente consumindo uma quantidade desproporcional de recursos da CPU. Especificamente, o cache de LAN SNMP por processo é o mais intensivo de CPU, seguido por outros processos relacionados ao SNMP.
O próximo conjunto de comandos nos ajudará a detalhar o processo de alta utilização de 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
A saída do comando show snmp stats oid revela a frequência na qual vários OIDs estão sendo pesquisados. Um OID específico, bsnAPIfDBNoisePower, se destaca devido ao seu número excepcionalmente alto de solicitações. Isso sugere que o polling agressivo desse OID está provavelmente contribuindo para a alta utilização da CPU observada no WLC.
Vamos tentar entender o que o OID bsnAPIfDBNoisePower faz e seus tempos de armazenamento de dados.
Navegue até SNMP Object Navigator e pesquise o OID "bsnAPIfDBNoisePower".
Resultado da pesquisa do OID
Agora você compreende que o objeto bsnAPIfDBNoisePower relata a potência de ruído de cada canal conforme relatado por cada AP. Dado o grande número de canais e APs gerenciados pelo WLC, os dados de SNMP gerados por este OID podem ser substanciais. Quando a WLC serve a um grande número de APs, o volume de dados gerados pelo polling deste OID pode ser imenso. Isso pode levar a uma alta utilização da CPU, à medida que a WLC processa essas solicitações de SNMP extensivas.
Da mesma forma, você precisa entender o comportamento do OID específico que está sendo interrogado agressivamente.
O próximo comando vai ajudá-lo a conhecer os servidores SNMP que estão fazendo o polling na WLC.
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
Esse comando fornece uma lista de servidores SNMP, juntamente com suas contagens de solicitações e o último carimbo de data/hora de sua atividade de polling.
Você pode ver que há vários servidores diferentes que estão sondando a WLC 9800. Se você observar os dados de registros completos coletados durante os últimos 10 minutos, poderá medir também a frequência de interrogação.
Agora você pode ir a cada servidor e ver com que frequência o OID ofensivo está sendo interrogado. Neste exemplo, o OID está sendo interrogado a cada 30 segundos, o que é significativamente mais frequente do que o necessário. Como a WLC recebe dados de RF/RRM a cada 180 segundos, fazer polling no OID a cada 30 segundos resulta em processamento desnecessário e contribui para a alta utilização da CPU.
Uma vez que o OID e o servidor ofensivos tenham sido identificados, podemos tentar várias soluções diferentes para reduzir a carga na WLC.
- Reduza a frequência de polling no servidor SNMP.
- Se o OID não for necessário para o uso da operação, desative a interrogação desse OID no servidor SNMP.
- Se você não tiver controle sobre o servidor SNMP, poderá usar a visualização SNMP para bloquear o OID ofensivo.
Configuração do SNMP View
Defina uma nova exibição que exclua o OID que você deseja bloquear. Por exemplo, você deseja bloquear o OID 1.3.6.1.4.1.14179.2.2.15.1.21, criar uma nova exibição e anexar o OID à exibição.
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.
Dica de solução de problemas
- Uso da CPU de Linha de Base: documente os níveis normais de utilização da CPU quando o processo SNMP não estiver causando uso alto.
- Configuração SNMP: revise as definições de configuração SNMP atuais, incluindo strings de comunidade, versão (v2c ou v3) e listas de acesso.
- Prática recomendada de SNMP: use o documento de práticas recomendadas da WLC 9800 e corresponda à configuração sugerida para SNMP o mais próximo possível.
C9800(config)#snmp-server subagent cache
C9800(config)#snmp-server subagent cache timeout ?
<1-100> cache timeout interval (default 60 seconds)
- Frequência de pesquisa SNMP: determine a frequência com que a WLC está sendo pesquisada por consultas SNMP, pois uma alta frequência pode contribuir para o aumento da carga da CPU.
- Topologia de rede e gerenciadores SNMP: entenda a configuração da rede e identifique todos os gerenciadores SNMP que estão interagindo com a WLC.
- Tempo de atividade do sistema: verifique o tempo decorrido desde a última reinicialização para ver se há uma correlação entre tempo de atividade e utilização da CPU.
- Alterações recentes: observe quaisquer alterações recentes na configuração ou na rede da WLC que possam ter coincidido com o início da alta utilização da CPU.
- Com a WLC 9800, o foco foi colocado na telemetria. A telemetria funciona em um modelo "push", em que a WLC envia informações relevantes ao servidor sem a necessidade de consulta. Se suas consultas SNMP estiverem consumindo ciclos de CPU de WLC e causando problemas de operação, seria melhor mudar para Telemetria.
Conclusão
Analisando metodicamente os dados de utilização da CPU e correlacionando-os com as atividades de pesquisa SNMP, você pode solucionar problemas e resolver problemas de alta utilização da CPU causados por processos SNMP no Cisco 9800 WLC. O monitoramento pós-implementação é essencial para confirmar o sucesso dos esforços de solução de problemas e para manter o desempenho ideal da rede.
Informações Relacionadas