O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como monitorar o uso da CPU em Catalyst 9800 Wireless LAN Controllers, além de abordar várias recomendações de configuração.
Antes de aprofundar-se na solução de problemas de carga de CPU, você precisa entender os fundamentos de como as CPUs são usadas nos Controladores de LAN sem fio Catalyst 9800 e alguns detalhes sobre a arquitetura do software.
Em geral, o documento de práticas recomendadas do Catalyst 9800 define um conjunto de boas definições de configuração que podem evitar problemas no nível do aplicativo. Por exemplo, usar a filtragem de local para mDNS ou garantir que a exclusão de cliente esteja sempre habilitada. Recomenda-se que você aplique essas recomendações junto com os tópicos expostos aqui.
Os controladores Catalyst 9800 foram projetados como uma plataforma flexível, voltada para diferentes cargas de rede e focada no dimensionamento horizontal. O nome de desenvolvimento interno era eWLC com o e para elástico, significando que a mesma arquitetura de software, seria capaz de executar de um pequeno sistema incorporado de CPU única para vários dispositivos de grande escala de CPU/núcleo.
Cada WLC teve dois lados distintos:
Em uma visão simplificada, o controlador tem mecanismos de comunicação entre o plano de controle e de dados, punt, envia tráfego da rede para o plano de controle, e injeção, empurra quadros do plano de controle para a rede.
Como parte de uma possível investigação de identificação e solução de problemas de alta utilização da CPU, você precisa monitorar o mecanismo de punt para avaliar qual tráfego está chegando ao plano de controle e pode levar a uma carga alta.
Para o controlador Catalyst 9800, ele é executado como parte do Cisco Packet Processor (CPP), que é uma estrutura de software para desenvolver mecanismos de encaminhamento de pacotes, usados em vários produtos e tecnologias.
A arquitetura permite um conjunto de recursos comum, em diferentes implementações de hardware ou software. Por exemplo, permitindo recursos semelhantes para 9800CL vs 9800-40, em escalas de throughput diferentes.
A WLC executa o balanceamento de carga através das CPUs durante o processo de junção CAPWAP AP AP, com o diferenciador-chave sendo o nome da tag do site do AP. A ideia é que cada AP represente uma carga de CPU específica adicionada, proveniente de sua atividade de cliente e do próprio AP. Há vários mecanismos para executar esse balanceamento:
Por exemplo, se você tiver um 9800-40, lidando com um escritório principal, mais 5 filiais, com contagens de AP diferentes, a configuração poderia ser assim:
wireless tag site office-main
load 120
wireless tag site branch-1
load 10
wireless tag site branch-2
load 12
wireless tag site branch-3
load 45
wireless tag site branch-4
load 80
wireless tag site branch-5
load 5
Neste cenário, você não deseja que a tag do escritório principal esteja no mesmo WNCD que a filial 3 e a filial 4, há no total 6 tags de site e a plataforma tem 5 WNCDs, portanto pode haver uma chance de que as tags de site mais carregadas cheguem à mesma CPU. Usando o comando load, você pode criar uma topologia de balanceamento de carga de AP previsível.
O comando load é um tamanho esperado. Ele não precisa corresponder exatamente à contagem de APs, mas é normalmente definido para os APs esperados que podem se unir.
Para plataformas de hardware, a contagem WNCD é fixa: 9800-40 tem 5, 9800-80 tem 8. Para 9800CL (virtual), o número de WNCDs dependeria do modelo de máquina virtual usado durante a implantação inicial.
Como regra geral, se quiser descobrir quantos WNCDs estão em execução no sistema, você pode usar este comando em todos os tipos de controlador:
9800-40#show processes cpu platform sorted | count wncd
Number of lines which match regexp = 5
No caso do 9800-CL especificamente, você pode usar o comando show platform software system all
para coletar detalhes na plataforma virtual:
9800cl-1#show platform software system all
Controller Details:
=================
VM Template: small
Throughput Profile: low
AP Scale: 1000
Client Scale: 10000
WNCD instances: 1
A atribuição de AP para WNCD é aplicada durante o processo de junção de CAPWAP de AP, de modo que não se espera que seja alterada durante as operações, independentemente do método de balanceamento, a menos que haja um evento de redefinição de CAPWAP em toda a rede, em que todos os APs se desconectam e se unem novamente.
O comandoshow wireless loadbalance tag affinity
CLI pode fornecer uma maneira fácil de ver o estado atual do balanceamento de carga do AP em todas as instâncias WNCD:
98001#show wireless loadbalance tag affinity
Tag Tag type No of AP's Joined Load Config Wncd Instance
---------------------------------------------------------------------------------------------
Branch-tag SITE TAG 10 0 0
Main-tag SITE TAG 200 0 1
default-site-tag SITE TAG 1 NA 2
se você quiser correlacionar a distribuição do AP com a contagem de clientes e a carga da CPU, a maneira mais fácil é usar a ferramenta de suporte WCAE e carregar umashow tech wireless
tomada durante os horários de pico. A ferramenta resume a contagem de clientes WNCD, tirada de cada AP associado a ela.
Exemplo de um controlador balanceado corretamente, durante o baixo uso e a contagem de clientes:
Outro exemplo, para um controlador mais carregado, mostrando a utilização normal da CPU:
Resumindo, você pode resumir as diferentes opções em:
Esse limite de 500 APs deve ser marcado quando for eficaz aplicar o mecanismo de balanceamento de carga, pois ele agrupa APs em blocos de 100 unidades por padrão.
Há situações em que você deseja fazer um balanceamento de AP mais avançado e é desejável ter controle granular sobre como os APs são distribuídos nas CPUs. Por exemplo, cenários de densidade muito alta em que a principal métrica de carga é a contagem de clientes, em vez de focar apenas no número de APs presentes no sistema.
Um bom exemplo desta situação são os grandes acontecimentos: um prédio poderia hospedar milhares de clientes, mais de várias centenas de APs, e você precisaria dividir a carga em tantas CPUs quanto possível, mas otimizar o roaming ao mesmo tempo. Portanto, você não pode passar pelo WNCD a menos que seja necessário. Você deseja evitar situações de salt e pimenta em que vários APs em WNCDs diferentes/marcas de site são misturados no mesmo local físico.
Para ajudar a fazer o ajuste fino e fornecer uma visualização da distribuição, você pode usar a ferramenta WCAE e aproveitar o recurso AP RF View:
Isso permite que você veja a distribuição AP/WNCD, apenas definidaView Type
como WNCD. Aqui, cada cor representaria um WNCD/CPU. Você também pode definir o filtro RSSI como -85, para evitar conexões de sinal baixo, que também são filtradas pelo algoritmo RRM no controlador.
No exemplo anterior, correspondente ao Cisco Live EMEA 24, você pode ver que a maioria dos APs adjacentes são agrupados perfeitamente no mesmo WNCD, com sobreposição cruzada muito limitada.
As marcas de site alocadas para o mesmo WNCD obtêm a mesma cor.
É importante lembrar o conceito da arquitetura do Cisco IOS XE e ter em mente que há duas visões principais do uso da CPU. Um vem do suporte histórico do Cisco IOS, e o principal, com uma visão holística da CPU em todos os processos e núcleos.
Em geral, você pode usar o comandoshow processes cpu platform sorted
para coletar informações detalhadas de todos os processos no Cisco IOS XE:
9800cl-1#show processes cpu platform sorted
CPU utilization for five seconds: 8%, one minute: 14%, five minutes: 11%
Core 0: CPU utilization for five seconds: 6%, one minute: 11%, five minutes: 5%
Core 1: CPU utilization for five seconds: 2%, one minute: 8%, five minutes: 5%
Core 2: CPU utilization for five seconds: 4%, one minute: 12%, five minutes: 12%
Core 3: CPU utilization for five seconds: 19%, one minute: 23%, five minutes: 24%
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
19953 19514 44% 44% 44% S 190880 ucode_pkt_PPE0
28947 8857 3% 10% 4% S 1268696 linux_iosd-imag
19503 19034 3% 3% 3% S 247332 fman_fp_image
30839 2 0% 0% 0% I 0 kworker/0:0
30330 30319 0% 0% 0% S 5660 nginx
30329 30319 0% 1% 0% S 20136 nginx
30319 30224 0% 0% 0% S 12480 nginx
30263 1 0% 0% 0% S 4024 rotee
30224 8413 0% 0% 0% S 4600 pman
30106 2 0% 0% 0% I 0 kworker/u11:0
30002 2 0% 0% 0% S 0 SarIosdMond
29918 29917 0% 0% 0% S 1648 inet_gethost
Há vários pontos principais a serem destacados aqui:
show tech wireless
pode gerar uma carga de pico em processos IOSd, smand e pubd, como uma saída de texto muito grande está sendo coletada, com centenas de comandos CLI executados. Isso não é um problema e a carga diminui depois que a saída é concluída.Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
19371 19355 62% 83% 20% R 128120 smand
27624 27617 53% 59% 59% S 1120656 pubd
4192 4123 11% 5% 4% S 1485604 linux_iosd-imag
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
21094 21086 25% 25% 25% S 978116 wncd_0
21757 21743 21% 20% 20% R 1146384 wncd_4
22480 22465 18% 18% 18% S 1152496 wncd_7
22015 21998 18% 17% 17% S 840720 wncd_5
21209 21201 16% 18% 18% S 779292 wncd_1
21528 21520 14% 15% 14% S 926528 wncd_3
show processes cpu sorted
. Isso corresponde à atividade na parte do processo linux_iosd-image da lista do Cisco IOS XE.9800cl-1#show processes cpu sorted
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
215 81 88 920 1.51% 0.12% 0.02% 1 SSH Process
673 164441 7262624 22 0.07% 0.00% 0.00% 0 SBC main process
137 2264141 225095413 10 0.07% 0.04% 0.05% 0 L2 LISP Punt Pro
133 534184 21515771 24 0.07% 0.04% 0.04% 0 IOSXE-RP Punt Se
474 1184139 56733445 20 0.07% 0.03% 0.00% 0 MMA DB TIMER
5 0 1 0 0.00% 0.00% 0.00% 0 CTS SGACL db cor
6 0 1 0 0.00% 0.00% 0.00% 0 Retransmission o
2 198433 726367 273 0.00% 0.00% 0.00% 0 Load Meter
7 0 1 0 0.00% 0.00% 0.00% 0 IPC ISSU Dispatc
10 3254791 586076 5553 0.00% 0.11% 0.07% 0 Check heaps
4 57 15 3800 0.00% 0.00% 0.00% 0 RF Slave Main Th
8 0 1 0 0.00% 0.00% 0.00% 0 EDDRI_MAIN
Isso está disponível na guiaMonitoring/System/CPU Utilization
.
A lista de processos exata varia dependendo do modelo do controlador e da versão do Cisco IOS XE. Esta é uma lista de alguns dos principais processos e não se destina a cobrir todas as entradas possíveis.
Nome do processo |
O que ele faz |
Avaliação |
wncd_x |
Trata da maioria das operações sem fio. Dependendo do modelo 9800, você pode ter de 1 a 8 instâncias. |
Você pode ver picos de alta utilização durante horários de pico. Informar se a utilização ficou parada por 95% ou mais durante vários minutos. |
linux_iosd-image |
processo IOS |
Esperava-se alta utilização ao coletar grandes saídas de CLI (show tech). Operações SNMP grandes ou muito frequentes podem levar a uma alta utilização da CPU. |
nginx |
Servidor da Web |
Esse processo pode mostrar picos e só pode ser relatado em uma carga alta sustentada. |
ucode_pkt_PPE0 |
Plano de dados em 9800CL/9800L |
Use o comando |
ezman |
Gerenciador de chipset para interfaces |
Uma CPU alta sustentada aqui pode indicar um problema de HW ou um possível problema de software de kernel. Ele pode ser relatado. |
dbm |
Gerenciador de Banco de Dados |
Uma CPU alta sustentada aqui pode ser relatada. |
odm_X |
O Operation Data Manager lida com bancos de dados consolidados em todos os processos. |
Esperava-se alta utilização da CPU em sistemas carregados. |
desonesto |
Lida com a funcionalidade de invasor |
Uma CPU alta sustentada aqui pode ser relatada. |
smand |
O Shell Manager cuida da análise CLI e da interação em diferentes processos. |
CPU alta esperada ao manipular grande saída CLI. Uma CPU alta e sustentada na ausência de carga pode ser relatada. |
emd |
Gerenciador Shell. Cuida da análise de CLI e da interação em diferentes processos. |
CPU alta esperada ao manipular grande saída CLI. Uma CPU alta e sustentada na ausência de carga pode ser relatada. |
pubd |
Parte do tratamento de telemetria |
Alta utilização de CPU esperada para grandes assinaturas de telemetria. Uma CPU alta e sustentada na ausência de carga pode ser relatada. |
Os controladores de LAN sem fio Catalyst 9800 têm mecanismos de proteção extensivos em torno da atividade da rede ou do cliente sem fio, para evitar alta utilização da CPU devido a cenários acidentais ou intencionais. Há vários recursos importantes projetados para ajudá-lo a conter dispositivos problemáticos:
Essa opção é ativada por padrão, faz parte das Políticas de proteção sem fio e pode ser ativada ou desativada por Perfil de política. Isso pode detectar vários problemas de comportamento diferentes, remover o cliente da rede e defini-lo em uma lista de exclusão temporária. Enquanto o cliente está nesse estado excluído, os APs não se comunicam com eles, impedindo qualquer ação adicional.
Depois que o temporizador de exclusão tiver passado (60 segundos por padrão), o cliente poderá se associar novamente.
Há vários desencadeadores para a exclusão de clientes:
A exclusão de cliente protege seu controlador, AP e infraestrutura AAA (Radius) de vários tipos de alta atividade que podem levar a uma alta utilização da CPU. Em geral, não é aconselhável desativar qualquer um dos métodos de exclusão, a menos que seja necessário para um exercício de Troubleshooting ou requisito de compatibilidade.
As configurações padrão funcionam para quase todos os casos, e somente em alguns cenários excepcionais, são necessárias para aumentar o tempo de exclusão ou desativar algum disparador específico. Por exemplo, alguns clientes legados ou especializados (IOT/Médico) precisam ter o gatilho de falha de associação desabilitado, devido a defeitos no lado do cliente que não podem ser corrigidos facilmente
Você pode personalizar os disparadores na interface do usuário: Políticas de configuração/proteção sem fio/exclusão de cliente:
O disparador de exclusão ARP foi projetado para ser habilitado permanentemente em um nível global, mas pode ser personalizado em cada perfil de política. Você pode verificar o status com o comandosh wireless profile policy all
look for this specific output: (Procurar esta saída específica:)
ARP Activity Limit
Exclusion : ENABLED
PPS : 100
Burst Interval : 5
Este é um mecanismo avançado no Plano de dados, para garantir que o tráfego enviado para o Plano de controle não exceda um conjunto predefinido de limites. O recurso é chamado Punt Policers e, em quase todos os cenários, não é necessário tocá-los e, mesmo assim, só deve ser feito enquanto se trabalha com o Suporte da Cisco.
A vantagem dessa proteção é que ela fornece uma visão muito detalhada do que está acontecendo na rede e se há alguma atividade específica que esteja tendo uma taxa aumentada, ou pacotes inesperadamente altos por segundo.
Isso é exposto apenas por meio da CLI, pois eles normalmente fazem parte de uma funcionalidade avançada que raramente é necessária para modificação.
Para obter uma exibição de todas as políticas de punt:
9800-l#show platform software punt-policer
Per Punt-Cause Policer Configuration and Packet Counters
Punt Config Rate(pps) Conform Packets Dropped Packets Config Burst(pkts) Config Alert
Cause Description Normal High Normal High Normal High Normal High Normal High
-------------------------------------------------------------------------------------------------------------------------------------------------------------
2 IPv4 Options 874 655 0 0 0 0 874 655 Off Off
3 Layer2 control and legacy 8738 2185 33 0 0 0 8738 2185 Off Off
4 PPP Control 437 1000 0 0 0 0 437 1000 Off Off
5 CLNS IS-IS Control 8738 2185 0 0 0 0 8738 2185 Off Off
6 HDLC keepalives 437 1000 0 0 0 0 437 1000 Off Off
7 ARP request or response 437 1000 0 330176 0 0 437 1000 Off Off
8 Reverse ARP request or repso 437 1000 0 24 0 0 437 1000 Off Off
9 Frame-relay LMI Control 437 1000 0 0 0 0 437 1000 Off Off
10 Incomplete adjacency 437 1000 0 0 0 0 437 1000 Off Off
11 For-us data 40000 5000 442919246 203771 0 0 40000 5000 Off Off
12 Mcast Directly Connected Sou 437 1000 0 0 0 0 437 1000 Off Off
Pode ser uma lista grande, com mais de 160 entradas, dependendo da versão do software.
Na saída da tabela, você deseja verificar a coluna de pacotes descartados junto com qualquer entrada que tenha um valor diferente de zero na contagem alta de quedas.
Para simplificar a coleta de dados, você pode usar o comandoshow platform software punt-policer drop-only
, para filtrar apenas entradas de vigilante com quedas.
Esse recurso pode ser útil para identificar se há tempestades ARP ou inundações de sondagem 802.11 (eles usam pacotes de fila 802.11 para LFTS). LFTS significa Linux Forwarding Transport Service).
Em todas as versões de manutenção recentes, o controlador tem um monitor de atividade, para reagir dinamicamente à alta CPU e garantir que os túneis CAPWAP do AP permaneçam ativos, em face da pressão insustentável. O recurso verifica a carga WNCD e começa a acelerar a nova atividade do cliente, para garantir que recursos suficientes permaneçam para lidar com as conexões existentes e proteger a estabilidade CAPWAP. Isso é habilitado por padrão e não tem opções de configuração.
Há três níveis de proteção definidos: L1 com 80% de carga, L2 com 85% de carga e L3 com 89%, cada um disparando diferentes descartes de protocolo de entrada como mecanismos de proteção. A proteção é removida automaticamente assim que a carga diminui.
Em uma rede íntegra, você não pode ver eventos de carregamento de L2 ou L3 e, se eles estiverem acontecendo com frequência, pode ser investigado.
Para monitorar, use o comandowireless stats cac
como mostrado na imagem.
9800-l# show wireless stats cac
WIRESLESS CAC STATISTICS
---------------------------------------------
L1 CPU Threshold: 80 L2 CPU Threshold: 85 L3 CPU Threshold: 89
Total Number of CAC throttle due to IP Learn: 0
Total Number of CAC throttle due to AAA: 0
Total Number of CAC throttle due to Mobility Discovery: 0
Total Number of CAC throttle due to IPC: 0
CPU Throttle Stats
L1-Assoc-Drop: 0 L2-Assoc-Drop: 0 L3-Assoc-Drop: 0
L1-Reassoc-Drop: 0 L2-Reassoc-Drop: 0 L3-Reassoc-Drop: 0
L1-Probe-Drop: 12231 L2-Probe-Drop: 11608 L3-Probe-Drop: 93240
L1-RFID-Drop: 0 L2-RFID-Drop: 0 L3-RFID-Drop: 0
L1-MDNS-Drop: 0 L2-MDNS-Drop: 0 L3-MDNS-Drop: 0
O mDNS como protocolo permite uma abordagem automatizada para detectar serviços entre dispositivos, mas, ao mesmo tempo, pode ser muito ativo e gerar uma carga significativa, se não estiver configurado corretamente.
O mDNS, sem nenhuma filtragem, pode facilmente aumentar a utilização da CPU WNCD, vindo de vários fatores:
Você pode verificar o tamanho da lista mDNS por serviço com este comando:
9800-l# show mdns-sd service statistics
Service Name Service Count
-----------------------------------------------------------------------------
_ipp._tcp.local 84
_ipps._tcp.local 52
_raop._tcp.local 950
_airplay._tcp.local 988
_printer._tcp.local 13
_googlerpc._tcp.local 12
_googlecast._tcp.local 70
_googlezone._tcp.local 37
_home-sharing._tcp.local 7
_cups._sub._ipp._tcp.local 26
Isso pode fornecer uma ideia do tamanho que uma determinada consulta pode ter. Ele não denota um problema por si só, apenas uma forma de monitorar o que é rastreado.
Há algumas recomendações importantes de configuração do mDNS:
9800-1(config)# mdns-sd gateway
9800-1(config-mdns-sd)# transport ipv4
Por padrão, ele usa o transporte IPv4. Para desempenho, é recomendável usar IPv6 ou IPv4, mas não ambos.
Caso você esteja observando uma carga alta de CPU e nenhuma das etapas anteriores ajude, entre em contato com CX por meio de um caso e adicione esses dados como ponto de partida:
show tech-support wireless
request platform software trace archive last <days> to-file bootflash:<archive file>
Revisão | Data de publicação | Comentários |
---|---|---|
2.0 |
06-Jun-2025
|
Texto alternativo atualizado, requisitos de estilo, tradução automática, requisitos de marca e formatação para estar em conformidade com as diretrizes da Cisco para externalização |
1.0 |
09-May-2024
|
Versão inicial |