Solucionar problemas de carga de CPU del controlador LAN inalámbrico
Contenido
Introducción
Este documento describe cómo monitorear el uso de la CPU en los controladores de LAN inalámbrica de Catalyst 9800 y cubre varias recomendaciones de configuración.
Comprensión del uso de CPU
Antes de profundizar en la resolución de problemas de carga de la CPU, debe comprender los conceptos básicos de cómo se utilizan las CPU en los controladores de LAN inalámbrica de Catalyst 9800 y algunos detalles sobre la arquitectura del software.
En general, el documento Prácticas recomendadas de Catalyst 9800 define un conjunto de configuraciones que pueden evitar problemas en el nivel de la aplicación. Por ejemplo, utilizar el filtrado de ubicación para mDNS o garantizar que la exclusión de clientes siempre está habilitada. Se aconseja que aplique esas recomendaciones junto con los temas expuestos aquí.
Fundamentos de plataforma
Los controladores Catalyst 9800 se diseñaron como una plataforma flexible dirigida a diferentes cargas de red y centrada en la escalabilidad horizontal. La denominación de desarrollo interno fue eWLC con la "e" para elastic, para significar que la misma arquitectura de software se ejecutaría desde un solo sistema integrado de CPU pequeño a varios dispositivos de gran escala de CPU/núcleo.
Cada WLC tiene dos lados distintos:
- Plano de control: Manejo de todas las interacciones de administración como CLI, UI, Netconf y todos los procesos de incorporación para clientes y AP.
- Plano de datos: Responsable del reenvío de paquetes y la desencapsulación de CAPWAP, la aplicación de políticas AVC, entre otras funcionalidades.
Plano de Control
- La mayoría de los procesos de Cisco IOS® se ejecutan bajo BinOS (Linux Kernel) con su propio planificador especializado y comandos de monitoreo.
- Hay un conjunto de procesos clave, denominados Wireless Network Control Daemon (WNCD), cada uno de los cuales tiene una base de datos en memoria local, que gestiona la mayor parte de la actividad inalámbrica. Cada CPU posee un WNCD para distribuir la carga a través de todos los núcleos de CPU disponibles a cada sistema
- La distribución de la carga a través de WNCDs se completa durante una unión AP. Cuando un AP realiza una unión CAPWAP al controlador, un balanceador de carga interno distribuye el AP usando un conjunto de reglas posibles, para asegurar el uso correcto de todos los recursos de CPU disponibles.
- El código de Cisco IOS® se ejecuta en su propio proceso llamado IOSd y tiene su programador de CPU. Esto se ocupa de funciones específicas, por ejemplo, CLI, SNMP, multidifusión y routing.
En una vista simplificada, el controlador tiene mecanismos de comunicación entre el plano de control y el plano de datos, punt, envía tráfico de la red al plano de control, inyección y envía tramas desde el plano de control a la red.
Como parte de una posible investigación de resolución de problemas de CPU alta, debe monitorear el mecanismo de punt para evaluar qué tráfico está alcanzando el plano de control y puede conducir a una carga alta.
Plano de Datos
Para el controlador Catalyst 9800, esto se ejecuta como parte del procesador de paquetes de Cisco (CPP), que es un marco de software para desarrollar motores de reenvío de paquetes utilizados en múltiples productos y tecnologías.
La arquitectura permite un conjunto de funciones comunes a través de diferentes implementaciones de hardware o software. Por ejemplo, permite funciones similares para 9800CL frente a 9800-40 en diferentes escalas de rendimiento.
Balanceo de Carga de AP
El WLC realiza el balanceo de carga a través de las CPU durante el proceso de unión CAPWAP AP AP, con el diferenciador clave que es el nombre de la etiqueta del sitio AP. La idea es que cada AP represente una carga específica de CPU agregada, viniendo de su actividad de cliente y del AP mismo. Existen varios mecanismos para realizar este equilibrio:
- Si el AP está utilizando una etiqueta predeterminada, se equilibra en una forma de ordenamiento cíclico a través de todas las CPU/WNCD con cada nueva unión del AP que va al WNCD siguiente. Este es el método más simple, sin embargo, tiene algunas implicaciones:
- Este es el escenario subóptimo, ya que los AP en el mismo dominio de roaming de RF tienen roaming entre WNCD frecuente, lo que implica una comunicación entre procesos adicional. La itinerancia entre instancias es un poco más lenta.
- En el caso de la etiqueta del sitio (remoto) de FlexConnect, no hay ninguna distribución de claves PMK disponible. Esto significa que no puede completar la itinerancia rápida para el modo Flex, lo que afecta a los modos de itinerancia OKC/FT.
En general, la etiqueta predeterminada se puede utilizar en escenarios de carga más baja (por ejemplo, menos del 40% de la carga de AP y cliente de la plataforma 9800), y para la implementación de FlexConnect solo cuando no se requiere la itinerancia rápida.
- Si el AP tiene una etiqueta de sitio personalizada, la primera vez que un AP pertenece al nombre de la etiqueta de sitio se une al controlador, la etiqueta de sitio se asigna a una instancia WNCD específica. Todas las uniones de AP adicionales subsiguientes con la misma etiqueta se asignan al mismo WNCD. Esto garantiza que el roaming entre los AP en la misma etiqueta del sitio se produce en el contexto WCND. Esto proporciona un flujo más óptimo, con un menor uso de la CPU. Se admite la itinerancia a través de WNCD, pero no es tan óptima en la itinerancia dentro de WNCD.
- Decisión de equilibrio de carga predeterminada: Cuando se asigna una etiqueta a un WNCD, el equilibrador de carga selecciona la instancia con el recuento de etiquetas de sitio más bajo en ese momento. Se desconoce la carga total que puede tener la etiqueta del sitio, lo que puede llevar a situaciones de equilibrio subóptimas. Esto depende del orden en que el AP se une, cuántas etiquetas de sitio se han definido y si el conteo de AP es asimétrico a través de ellas.
- Balanceo de Carga Estático: Para evitar la asignación desequilibrada de etiquetas de sitio a WNCD, el comando site load se introdujo en la versión 17.9.3 y posteriores. Esto permite a los administradores predefinir la carga esperada de cada etiqueta de sitio. Esto es útil cuando se manejan escenarios de campus o varias sucursales, cada una asignada a diferentes conteos de AP para garantizar que la carga se distribuye uniformemente a través de WNCD.
Si tiene un 9800-40 manejando una oficina principal, más 5 sucursales con diferentes conteos de AP, la configuración puede verse de la siguiente manera:
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
En este escenario, no desea que la etiqueta de la oficina principal esté en el mismo WNCD que la sucursal 3 y la sucursal 4. Hay 6 etiquetas de sitio en total y la plataforma tiene 5 WNCD y existe la posibilidad de que las etiquetas de sitio cargadas más altas aterricen en la misma CPU. Al ejecutar el comando load, puede crear una topología de balanceo de carga de AP predecible.
El comando load es de un tamaño esperado. No necesita coincidir exactamente con el conteo de AP, sin embargo, normalmente se configura en los AP esperados que pueden unirse.
- En los escenarios en los que hay edificios grandes gestionados por un solo controlador, es más fácil crear tantas etiquetas de sitio como WNCD para esa plataforma específica (por ejemplo, C9800-40 tiene 5, C9800-80 tiene 8). Asigne AP en la misma área o dominio de roaming a las mismas etiquetas del sitio para minimizar la comunicación entre WNCD.
- Equilibrio de carga de RF: Esto equilibra los AP a través de las instancias WNCD, usando la relación de vecino RF de RRM, y crea subgrupos dependiendo de lo cerca que están los AP entre sí. Debe completarse después de que los AP hayan estado funcionando por un tiempo y eliminar la necesidad de configurar cualquier configuración de equilibrio de carga estática. Está disponible a partir de las 17.12 horas.
Cómo averiguar cuántas WNCD hay presentes
Para las plataformas de hardware, el recuento de WNCD es fijo: 9800-40 tiene 5, 9800-80 tiene 8. Para 9800CL (virtual), el número de WNCD depende de la plantilla de máquina virtual utilizada durante la implementación inicial.
Como regla general, si desea determinar cuántos WNCD se están ejecutando en el sistema, puede ejecutar este comando en todos los tipos de controladores:
9800-40#show processes cpu platform sorted | count wncd
Number of lines which match regexp = 5
En el caso de 9800-CL, puede ejecutar el comando show platform software system all para recopilar detalles en la 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
Monitoreo del Balanceo de Carga de AP
La asignación de AP a WNCD se aplica durante el proceso de unión CAPWAP AP AP y no se espera que cambie durante las operaciones, independientemente del método de equilibrio. A menos que, haya un evento de reinicio CAPWAP en toda la red donde todos los AP se desconecten y se vuelvan a unir.
La ejecución del comando CLI show wireless loadbalance tag affinity puede proporcionar una manera fácil de ver el estado actual del equilibrio de carga de AP en todas las instancias 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
Si desea correlacionar la distribución de AP con el conteo de clientes y la carga de CPU, puede utilizar la herramienta de soporte WCAE y cargar un show tech wireless tomado durante las horas de mayor actividad. La herramienta resume el conteo de clientes WNCD, tomado de cada AP que está asociado con él.
Este es un ejemplo de un controlador debidamente balanceado, durante el bajo uso y el conteo de clientes:
Otro ejemplo es para un controlador más cargado, que muestra el uso normal de la CPU:
¿Cuál es el mecanismo de equilibrio de carga de AP recomendado?
En resumen, puede resumir las diferentes opciones en:
- Redes pequeñas, sin necesidad de itinerancia rápida, menos del 40% de la carga del controlador: Etiqueta predeterminada.
- Si se requiere la itinerancia rápida (OKC, FT, CCKM) o una gran cantidad de clientes:
- Edificio único: Cree tantas etiquetas de sitio como CPU (según la plataforma).
- Antes de 17.12, o menos de 500 AP count: Varios edificios, sucursales o grandes campus: Cree una etiqueta de sitio por ubicación de RF física y configure el comando de carga por sitio.
- 17.12 y superior con más de 500 AP: use el balanceo de carga de RF.
Este umbral de 500 AP es para marcar cuándo es efectivo aplicar el mecanismo de balanceo de carga, ya que agrupa los AP en bloques de 100 unidades de forma predeterminada.
Visualización de distribución WNCD de PA
Hay escenarios donde puede aplicar el equilibrio avanzado de AP, y es deseable tener un control granular sobre cómo los AP se distribuyen a través de las CPU. Por ejemplo, escenarios de densidad muy alta donde la métrica de carga clave es el conteo de clientes frente al enfoque en el número de AP presentes en el sistema.
Un buen ejemplo de esta situación son los grandes eventos en los que un edificio puede alojar miles de clientes en varios cientos de AP, y es necesario dividir la carga en tantas CPU como sea posible, pero optimizar el roaming al mismo tiempo. No se desplaza por WNCD a menos que sea necesario. Desea evitar situaciones en las que varios AP en diferentes WNCD/etiquetas de sitio se entremezclan en la misma ubicación física.
Para ayudar a ajustar y proporcionar una visualización de la distribución, puede utilizar la herramienta WCAE y aprovechar la función AP RF View:
Esto le permite ver la distribución AP/WNCD, simplemente establezca el Tipo de vista en WNCD. Cada color representa un WNCD/CPU y puede establecer el filtro RSSI en -85 para evitar conexiones de señal baja. Estos también se filtran por el algoritmo RRM en el controlador.
En el ejemplo anterior, correspondiente a Cisco Live EMEA 24, puede ver que la mayoría de los AP adyacentes están agrupados en el mismo WNCD con superposición cruzada muy limitada. Las etiquetas de sitio asignadas al mismo WNCD reciben el mismo color.
Supervisión del uso de CPU del plano de control
Es importante recordar el concepto de la arquitectura Cisco IOS XE y tener en cuenta que hay dos vistas principales del uso de la CPU. Uno proviene de la compatibilidad histórica con Cisco IOS y el principal tiene una vista holística de la CPU en todos los procesos y núcleos.
En general, puede ejecutar el comando show processes cpu platform sorted para recopilar información detallada de todos los procesos en 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
Hay varios puntos clave que destacar:
- El proceso ucode_pkt_PPE0 gestiona el plano de datos en las plataformas 9800L y 9800CL. Se espera que observe una alta utilización en todo momento, incluso superior al 100%. Esto forma parte de la aplicación y no constituye un problema.
- Es importante diferenciar el uso máximo frente a una carga sostenida y aislar lo que se espera en un escenario determinado. Por ejemplo, la recopilación de una salida CLI muy grande, como show tech wireless, puede generar una carga máxima en los procesos IOSd, smand y pubd, ya que se está recopilando una salida de texto muy grande con cientos de comandos CLI ejecutados. Esto no es un problema y la carga disminuye una vez que se ha completado la salida.
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
- Se espera un uso máximo de los núcleos WNCD durante los periodos de mayor actividad de los clientes. Es posible ver picos del 80% sin ningún impacto funcional, y normalmente no causan un problema.
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
- Debe investigarse un uso elevado y sostenido de la CPU en un proceso superior al 90% durante más de 15 minutos.
- Puede monitorear el uso de la CPU IOSd ejecutando el comando show processes cpu sorted. Esto corresponde a la actividad del proceso linux_iosd-image de la lista de 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
- Puede utilizar la GUI del 9800 para obtener una vista rápida de la carga de IOSd, el uso por núcleo y la carga del plano de datos:
Esto está disponible en la pestaña Monitoring/System/CPU Utilization.
Qué es cada proceso
La lista de procesos varía según el modelo de controlador y la versión de Cisco IOS XE. Esta es una lista de algunos procesos clave y no pretende cubrir todas las entradas posibles.
| Nombre del proceso |
¿Qué hace? |
Evaluación |
| wncd_x |
Gestiona la mayoría de las operaciones inalámbricas. Según el modelo 9800, puede haber entre 1 y 8 instancias. |
Se pueden ver picos de alta utilización durante las horas punta. Informe si la utilización se bloquea durante un 95% o más durante varios minutos. |
| linux_iosd-image |
Proceso de Cisco IOS |
Espere ver una alta utilización si recopila una salida CLI grande (show tech). Las operaciones SNMP grandes o demasiado frecuentes pueden conducir a una CPU alta. |
| nginx |
Servidor Web |
Este proceso puede mostrar picos y solo se puede informar sobre una carga alta sostenida. |
| ucode_pkt_PPE0 |
Plano de datos en 9800CL/9800L |
Ejecute el comando show platform hardware chassis active qfp datapath utilization para monitorear este componente. |
| ezman |
Administrador de chipsets para interfaces |
Una CPU alta sostenida puede indicar un problema de hardware o un posible problema de software del núcleo (se puede informar). |
| dbm |
Administrador de bases de datos |
Aquí se puede informar de una CPU alta y sostenida. |
| odm_X |
Operation Data Manager gestiona las bases de datos consolidadas entre los procesos |
Se esperaba una CPU alta en los sistemas cargados. |
| pícaro |
Gestiona la funcionalidad de acceso no deseado |
Aquí se puede informar de una CPU alta y sostenida. |
| smand |
Shell Manager se encarga del análisis de la CLI y de la interacción entre los diferentes procesos. |
Se espera un uso elevado de la CPU al gestionar una salida CLI de gran tamaño. Se puede informar de una CPU alta y sostenida en ausencia de carga. |
| emd |
Shell Manager: gestiona el análisis de CLI y las interacciones entre los diferentes procesos |
Se espera un uso elevado de la CPU al gestionar una salida CLI de gran tamaño. Se puede informar de una CPU alta y sostenida en ausencia de carga. |
| púbico |
Parte de la gestión de telemetría |
Se esperaba una CPU alta para suscripciones de telemetría grandes. Se puede informar de una CPU alta y sostenida en ausencia de carga. |
Mecanismos de protección de CPU altos
Los controladores de LAN inalámbrica de Catalyst 9800 cuentan con mecanismos de protección extensos en torno a la actividad de la red o del cliente inalámbrico para evitar un uso elevado de la CPU debido a situaciones accidentales o intencionales. Existen varias funciones clave diseñadas para ayudar a contener los dispositivos problemáticos:
Exclusión de clientes
Esta opción está activada de forma predeterminada y forma parte de las políticas de protección inalámbrica, y se puede activar o desactivar según el perfil de política. Esto puede detectar varios problemas de comportamiento diferentes, quitar el cliente de la red y configurarlo en una lista de exclusión temporal. Mientras que el cliente está en este estado excluido, los AP no hablan con ellos, evitando cualquier acción adicional.
Una vez transcurrido el temporizador de exclusión (60 segundos de forma predeterminada), se permite al cliente volver a asociarse.
Existen varios desencadenadores para la exclusión de clientes:
- Generación de una inundación ARP
- Fallos de asociación repetidos
- 3 o más errores de autenticación webauth, PSK o 802.1x
- Tiempos de espera de autenticación repetidos (sin respuesta del cliente)
- Intentando reutilizar una dirección IP, ya registrada en otro cliente
La exclusión de clientes protege el controlador, el punto de acceso y la infraestructura AAA (Radius) de varios tipos de actividad alta que pueden provocar un uso elevado de la CPU. No es recomendable deshabilitar ningún método de exclusión a menos que sea necesario para un ejercicio de solución de problemas o un requisito de compatibilidad.
La configuración predeterminada funciona para casi todos los casos y solo en algunos escenarios excepcionales se requieren para aumentar el tiempo de exclusión o deshabilitar algunos desencadenadores específicos. Por ejemplo, algunos clientes antiguos o especializados (IOT/Medicina) deben tener el desencadenador de fallo de asociación para que se deshabilite, debido a defectos del lado del cliente que no se pueden solucionar fácilmente
Puede personalizar los desencadenadores en la interfaz de usuario: Políticas de configuración/protección inalámbrica/exclusión de clientes:
El disparador ARP Exclusion fue diseñado para ser habilitado permanentemente a nivel global, sin embargo, puede ser personalizado en cada perfil de política. Puede verificar el estado ejecutando el comando sh wireless profile policy all y buscar este resultado específico:
ARP Activity Limit
Exclusion : ENABLED
PPS : 100
Burst Interval : 5
Protección del plano de control frente al tráfico de datos
Se trata de un mecanismo avanzado en el plano de datos para garantizar que el tráfico enviado al plano de control no supere un conjunto predefinido de umbrales. Esta función se llama Punt Policers y en casi todos los escenarios no es necesario tocarlos, e incluso entonces, solo se debe usar cuando se trabaja con el Soporte de Cisco.
La ventaja de esta protección es que proporciona información detallada sobre la red y si hay alguna actividad específica que tenga una velocidad aumentada o paquetes altos inesperados por segundo.
Esto sólo se expone a través de CLI, ya que normalmente forman parte de una funcionalidad avanzada que rara vez necesita modificarse.
Para recibir una vista de todas las 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
Esta puede ser una lista grande con más de 160 entradas, dependiendo de la versión del software. En el resultado de la tabla, verifique la columna de paquetes descartados junto con cualquier entrada que tenga un valor distinto de cero en el conteo de caídas alto. Para simplificar la recolección de datos, puede ejecutar el comando show platform software punt-policer drop-only para filtrar solamente las entradas del regulador con caídas.
Esta función puede ser útil para identificar si hay tormentas ARP o inundaciones de sonda 802.11 (utilizan paquetes de cola 802.11 a LFTS y LFTS significa servicio de transporte de reenvío de Linux).
Control de admisión de llamadas inalámbrico
En todas las versiones de mantenimiento recientes, el controlador tiene un monitor de actividad para reaccionar dinámicamente a la CPU alta y asegurarse de que los túneles CAPWAP AP AP permanezcan activos ante una presión insostenible. Esta función verifica la carga WNCD y comienza a regular la nueva actividad del cliente para garantizar que haya suficientes recursos disponibles para manejar las conexiones existentes y proteger la estabilidad CAPWAP. Esto se habilita de forma predeterminada y no tiene opciones de configuración.
Hay tres niveles de protección definidos: L1 con una carga del 80%, L2 con una carga del 85% y L3 con una carga del 89%. Cada una activa diferentes caídas de protocolo entrante como mecanismos de protección. La protección se elimina automáticamente en cuanto disminuye la carga.
En una red saludable, no puede ver los eventos de carga L2 o L3 y si ocurren con frecuencia, se pueden investigar.
Para monitorear, ejecute el comando wireless stats cac:
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
Protecciones mDNS
mDNS como protocolo permite un enfoque sin intervención del usuario para detectar servicios en todos los dispositivos, pero al mismo tiempo, puede ser muy activo y aumentar considerablemente la carga si no se configura correctamente.
mDNS, sin ningún tipo de filtrado, puede aumentar fácilmente la utilización de la CPU WNCD, viniendo de varios factores:
- políticas mDNS con aprendizaje ilimitado, el controlador obtiene todos los servicios ofrecidos por todos los dispositivos. Esto puede dar lugar a listas de servicios de gran tamaño, con cientos de entradas.
- Las políticas establecidas sin filtrado hacen que el controlador envíe esas listas de servicios grandes a cada cliente que pregunta quién está proporcionando un servicio determinado.
- Algunos servicios específicos de mDNS los proporcionan todos los clientes inalámbricos, lo que conlleva un mayor número de servicios y actividad, con variaciones de este valor según la versión del sistema operativo.
Puede comprobar el tamaño de la lista mDNS por servicio ejecutando 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
Esto puede dar una idea de cuán grande puede llegar a ser una consulta dada. No denota un problema por sí solo, solo una manera de supervisar lo que se rastrea. Existen algunas recomendaciones importantes para la configuración de mDNS:
- Establezca el transporte mDNS en un único protocolo:
9800-1(config)# mdns-sd gateway
9800-1(config-mdns-sd)# transport ipv4
De forma predeterminada, utiliza transporte IPv4 y, para el rendimiento, se recomienda utilizar IPv6 o IPv4, pero no ambos.
- Establezca siempre un filtro de ubicación en la directiva de servicio mDNS para evitar consultas o respuestas independientes. En general, se recomienda utilizar la etiqueta del sitio, pero otras opciones podrían funcionar, dependiendo de sus necesidades.
Necesito más ayuda
Si observa una carga de CPU elevada y ninguno de los pasos anteriores le ayuda, póngase en contacto con Experiencia del cliente (CX) a través de un caso y agregue estos datos como punto de partida:
- Datos básicos, como esto incluye la configuración del controlador/AP, la red y los valores operativos de RF:
show tech-support wireless
- Archivar todos los seguimientos del controlador. Se trata de un archivo de gran tamaño similar a un concepto de caja negra que se puede recopilar ejecutando este comando:
request platform software trace archive last <days> to-file bootflash:<archive file>
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
3.0 |
03-Aug-2026
|
Actualización Introducción, ortografía, gramática, líneas horizontales insertadas para separar las secciones/legibilidad, corrección de errores de CCW. |
2.0 |
06-Jun-2025
|
Texto alternativo actualizado, requisitos de estilo, traducción automática, requisitos de marca y formato para cumplir con las directrices de Cisco para la externalización |
1.0 |
09-May-2024
|
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)