Risoluzione dei problemi di carico della CPU del controller LAN wireless
Sommario
Introduzione
Questo documento descrive come monitorare l'utilizzo della CPU sui controller LAN wireless Catalyst 9800 e fornisce diverse raccomandazioni per la configurazione.
Informazioni sull'utilizzo della CPU
Prima di approfondire la risoluzione dei problemi relativi al carico della CPU, è necessario comprendere le nozioni di base sull'utilizzo delle CPU nei controller LAN wireless Catalyst 9800 e alcuni dettagli sull'architettura software.
In generale, il documento sulle best practice di Catalyst 9800 definisce un insieme di impostazioni di configurazione che possono prevenire problemi a livello di applicazione. Ad esempio, l'utilizzo del filtro percorso per mDNS o la verifica dell'esclusione dei client è sempre attivato. Si consiglia di applicare tali raccomandazioni insieme agli argomenti esposti in questa sezione.
Nozioni di base sulle piattaforme
I controller Catalyst 9800 sono stati progettati come piattaforma flessibile per gestire diversi carichi di rete e per offrire una scalabilità orizzontale. Il nome di sviluppo interno era eWLC con la "e" per elastico, per indicare che la stessa architettura software sarebbe stata eseguita da un sistema singolo incorporato CPU di piccole dimensioni a più appliance CPU/core su larga scala.
Ciascun WLC ha due lati distinti:
- Piano di controllo: Gestione di tutte le interazioni di gestione come CLI, UI, Netconf e tutti i processi di caricamento per client e access point.
- Piano dati: Responsabile dell'effettivo inoltro e decapsulamento dei pacchetti di CAPWAP, dell'applicazione delle policy AVC, oltre ad altre funzionalità.
Piano di controllo
- La maggior parte dei processi Cisco IOS® viene eseguita con BinOS (kernel Linux) con un proprio strumento di pianificazione e comandi di monitoraggio.
- Esiste un insieme di processi chiave, denominati WNCD (Wireless Network Control Daemon), ognuno dei quali dispone di un database in memoria locale, che gestisce la maggior parte dell'attività wireless. Ogni CPU possiede un WNCD per distribuire il carico su tutti i core CPU disponibili a ciascun sistema
- La distribuzione del carico tra WNCD viene completata durante un join AP. Quando un access point esegue un join CAPWAP al controller, un load balancer interno distribuisce l'access point utilizzando un set di regole possibili, per garantire un utilizzo corretto di tutte le risorse CPU disponibili.
- Il codice Cisco IOS® viene eseguito sul proprio processo denominato IOSd e dispone del relativo scheduler CPU. In questo modo vengono gestite funzionalità specifiche, ad esempio CLI, SNMP, multicast e routing.
In una visualizzazione semplificata, il controller dispone di meccanismi di comunicazione tra il control plane e il data plane, punt, invia il traffico dalla rete al control plane, esegue l'inserimento e spinge i frame dal control plane alla rete.
Nell'ambito di una possibile indagine per la risoluzione dei problemi di CPU elevata, è necessario monitorare il meccanismo punt per valutare quale traffico sta raggiungendo il control plane e può portare a un carico elevato.
Piano dati
Per il controller Catalyst 9800, viene eseguito come parte del Cisco Packet Processor (CPP), una struttura software per lo sviluppo di motori di inoltro pacchetti utilizzati in più prodotti e tecnologie.
L'architettura consente un set di funzionalità comuni a diverse implementazioni hardware o software. Ad esempio, consente funzioni simili per 9800CL rispetto a 9800-40 a diverse scale di velocità.
Bilanciamento del carico AP
Il WLC esegue il bilanciamento del carico tra le CPU durante il processo di join dell'access point CAPWAP, con l'elemento di differenziazione della chiave che è il nome tag del sito dell'access point. L'idea è che ogni access point rappresenti un carico di CPU specifico aggiunto, derivante dalla sua attività client e dallo stesso access point. Per eseguire questo bilanciamento, è possibile utilizzare diversi meccanismi:
- Se l'access point utilizza un tag predefinito, esegue il bilanciamento in modo round robin tra tutte le CPU/WNCD con ogni nuovo join dell'access point che passa al successivo WNCD. Questo è il metodo più semplice, ma ha alcune implicazioni:
- Si tratta dello scenario subottimale, in quanto i punti di accesso nello stesso dominio di roaming RF utilizzano spesso roaming inter-WNCD, che comporta una comunicazione interprocesso aggiuntiva. Il roaming tra istanze è più lento di una piccola percentuale.
- Per il tag del sito FlexConnect (remoto), non è disponibile alcuna distribuzione di chiavi PMK. Ciò significa che non è possibile completare il roaming veloce per la modalità Flex, con impatto sulle modalità di roaming OKC/FT.
In generale, il tag predefinito può essere utilizzato in scenari di carico inferiore (ad esempio, meno del 40% del carico di AP e client della piattaforma 9800) e per l'installazione di FlexConnect solo quando il roaming veloce non è un requisito.
- Se l'access point ha un tag del sito personalizzato, la prima volta che un access point appartiene al nome del tag del sito viene aggiunto al controller, il tag del sito viene assegnato a una specifica istanza WNCD. Tutti i successivi join aggiuntivi con lo stesso tag vengono assegnati allo stesso WNCD. Ciò garantisce che il roaming tra gli access point nello stesso tag di sito avvenga nell'unico contesto WCND. In questo modo si ottiene un flusso ottimale, con un utilizzo ridotto della CPU. Il roaming tra WNCD è supportato, ma non è ottimale nel roaming intra-WNCD.
- Decisione predefinita di bilanciamento del carico: Quando un tag viene assegnato a un WNCD, il servizio di bilanciamento del carico seleziona l'istanza con il numero di tag di sito più basso in quel momento. Il carico totale che il tag del sito può avere è sconosciuto, può portare a scenari di bilanciamento non ottimali. Ciò dipende dall'ordine di join dell'access point, dal numero di tag di sito definiti e dal fatto che il conteggio dell'access point sia asimmetrico.
- Load balancing statico: Per evitare l'assegnazione di tag di sito non bilanciati a WNCD, il comando caricamento sito è stato introdotto nella versione 17.9.3 e successive. In questo modo gli amministratori possono predefinire il carico previsto di ogni tag del sito. Ciò è utile quando si gestiscono scenari di campus o più filiali, ognuna mappata a diversi conteggi AP per garantire che il carico sia distribuito uniformemente in WNCD.
Se si dispone di uno switch 9800-40 che gestisce un ufficio principale più 5 filiali con diversi numeri di punti di accesso, la configurazione può avere il seguente aspetto:
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
In questo scenario, non si desidera che il tag dell'ufficio principale si trovi nello stesso WNCD della filiale 3 e della filiale 4. Sono presenti 6 tag del sito in totale e la piattaforma ha 5 WNCD ed è possibile che i tag del sito con il carico più elevato si trovino sulla stessa CPU. Eseguendo il comando load è possibile creare una topologia di bilanciamento del carico del punto di accesso prevedibile.
La dimensione prevista per il comando load. Non è necessario che corrisponda esattamente al numero di punti di accesso, tuttavia in genere è impostato sui punti di accesso previsti che possono essere aggiunti.
- Negli scenari in cui sono presenti edifici di grandi dimensioni gestiti da un singolo controller, è più semplice creare un numero di tag sito pari a quello dei WNCD per la piattaforma specifica (ad esempio, C9800-40 ha 5, C9800-80 ha 8). Assegnare i punti di accesso nella stessa area o nello stesso dominio di roaming agli stessi tag di sito per ridurre al minimo la comunicazione tra WNCD.
- Load balancing RF: In questo modo i punti di accesso vengono bilanciati tra le istanze WNCD, utilizzando la relazione di router adiacente RF di RRM, e vengono creati sottogruppi a seconda della vicinanza tra i punti di accesso. Deve essere completata dopo che i punti di accesso sono stati attivati per un certo periodo di tempo ed è stata eliminata la necessità di configurare eventuali impostazioni di bilanciamento del carico statico. È disponibile dalla versione 17.12 e successive.
Come trovare il numero di WNCD presenti
Per le piattaforme hardware, il conteggio WNCD è fisso: 9800-40 ha 5, 9800-80 ne ha 8. Per 9800CL (virtuale), il numero di WNCD dipende dal modello di macchina virtuale utilizzato durante la distribuzione iniziale.
Come regola generale, se si desidera determinare il numero di WNCD in esecuzione nel sistema, è possibile eseguire questo comando tra tutti i tipi di controller:
9800-40#show processes cpu platform sorted | count wncd
Number of lines which match regexp = 5
Nel caso di 9800-CL, è possibile eseguire il comando show platform software system all per raccogliere i dettagli sulla piattaforma virtuale:
9800cl-1#show platform software system all
Controller Details:
=================
VM Template: small
Throughput Profile: low
AP Scale: 1000
Client Scale: 10000
WNCD instances: 1
Monitoraggio del bilanciamento del carico AP
L'assegnazione da AP a WNCD viene applicata durante il processo di join CAPWAP AP e non dovrebbe cambiare durante le operazioni, indipendentemente dal metodo di bilanciamento. A meno che non si verifichi un evento di ripristino CAPWAP a livello di rete in cui tutti gli access point si disconnettono e si ricongiungono.
L'esecuzione del comando CLI show wireless loadbalance tag affinity può fornire un modo semplice per visualizzare lo stato corrente del bilanciamento del carico dell'access point in tutte le istanze 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 si desidera correlare la distribuzione AP al numero di client e al carico della CPU, è possibile utilizzare lo strumento di supporto WCAE e caricare un show tech wireless utilizzato durante i periodi di attività. Lo strumento riepiloga il numero di client WNCD, ricavato da ciascun access point associato.
Questo è un esempio di controller correttamente bilanciato, in condizioni di basso utilizzo e numero di client:
Un altro esempio riguarda un controller con un carico maggiore, che mostra il normale utilizzo della CPU:
Che cos'è il meccanismo di bilanciamento del carico AP consigliato
In breve, è possibile riepilogare le diverse opzioni in:
- Reti di piccole dimensioni, nessuna necessità di roaming veloce, meno del 40% del carico del controller: Tag predefinito.
- Se è richiesto il roaming veloce (OKC, FT, CCKM) o il numero elevato di client:
- Edificio singolo: Creare un numero di tag sito pari alle CPU (dipendenti dalla piattaforma).
- Prima delle 17.12 o meno di 500 AP count: Più edifici, filiali o campus di grandi dimensioni: Creare un tag di sito per posizione RF fisica e configurare il comando di caricamento per sito.
- 17.12 e superiore con più di 500 access point: utilizzare il bilanciamento del carico RF.
Questa soglia di 500 punti di accesso deve indicare quando è efficace applicare il meccanismo di bilanciamento del carico, in quanto per impostazione predefinita raggruppa i punti di accesso in blocchi di 100 unità.
Visualizzazione distribuzione WNCD AP
In alcuni scenari è possibile applicare il bilanciamento avanzato degli access point ed è consigliabile avere un controllo granulare sulla distribuzione degli access point tra le CPU. Ad esempio, scenari ad alta densità in cui la metrica del carico chiave è il conteggio dei client rispetto al numero di punti di accesso presenti nel sistema.
Un buon esempio di questa situazione sono i grandi eventi in cui un edificio può ospitare migliaia di client su diverse centinaia di punti di accesso, ed è necessario dividere il carico su quante più CPU possibile, ma ottimizzare il roaming allo stesso tempo. Non si effettua il roaming attraverso WNCD a meno che non sia necessario. Si desidera evitare situazioni in cui più access point in WNCD/tag di sito diversi sono interconnessi nella stessa posizione fisica.
Per ottimizzare e visualizzare la distribuzione, è possibile utilizzare lo strumento WCAE e sfruttare la funzionalità AP RF View:
In questo modo è possibile visualizzare la distribuzione AP/WNCD. È sufficiente impostare View Type (Tipo di visualizzazione) su WNCD. Ogni colore rappresenta un WNCD/CPU ed è possibile impostare il filtro RSSI su -85 per evitare connessioni di segnale basse. Questi vengono filtrati anche dall'algoritmo RRM nel controller.
Nell'esempio precedente, corrispondente a Cisco EMEA 24, è possibile vedere che la maggior parte degli access point adiacenti sono raggruppati nello stesso WNCD con sovrapposizione incrociata molto limitata. I tag del sito allocati allo stesso WNCD ricevono lo stesso colore.
Monitoraggio dell'utilizzo della CPU del Control Plane
È importante ricordare il concetto di architettura Cisco IOS XE e tenere presente che esistono due visualizzazioni principali dell'utilizzo della CPU. Una viene dal supporto Cisco IOS cronologico e l'altra principale con una visione olistica della CPU in tutti i processi e core.
In generale, è possibile eseguire il comando show processes cpu platform sort per raccogliere informazioni dettagliate per tutti i processi in 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
Ecco alcuni punti chiave da evidenziare:
- Il processo ucode_pkt_PPE0 gestisce il piano dati sulle piattaforme 9800L e 9800CL. Si prevede che l'utilizzo sarà sempre elevato, addirittura superiore al 100%. Si tratta di una parte dell'attuazione e non costituisce un problema.
- È importante differenziare l'utilizzo di picco rispetto a un carico sostenuto e isolare ciò che è previsto in un determinato scenario. Ad esempio, la raccolta di un output CLI molto grande, come show tech wireless, può generare un carico di picco sui processi IOSd, smand e pubd, poiché viene raccolto un output di testo molto grande con centinaia di comandi CLI eseguiti. Questo non è un problema e il carico diminuisce una volta che l'output è stato completato.
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
- L'utilizzo massimo per i core WNCD è previsto durante i periodi di attività client elevata. È possibile vedere picchi dell'80% senza alcun impatto funzionale, e in genere non causano problemi.
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
- È necessario analizzare un utilizzo elevato e prolungato della CPU in un processo superiore al 90% per più di 15 minuti.
- È possibile monitorare l'utilizzo della CPU IOSd eseguendo il comando show processes cpu sorted. Questa corrisponde all'attività nella parte del processo linux_iosd-image dell'elenco 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
- È possibile utilizzare l'interfaccia grafica 9800 per una rapida visualizzazione del caricamento IOSd, per utilizzo core e carico del piano dati:
Questa opzione è disponibile nella scheda Monitoraggio/Sistema/Utilizzo CPU.
Definizione di ogni processo
L'elenco dei processi varia a seconda del modello di controller e della versione di Cisco IOS XE. Questo è un elenco di alcuni processi chiave e non è destinato a coprire tutte le voci possibili.
| Nome processo |
Qual è la funzione? |
Valutazione |
| wncd_x |
Gestisce la maggior parte delle operazioni wireless. A seconda del modello 9800, potete avere da 1 a 8 varianti. |
È possibile osservare picchi di utilizzo elevato durante le ore di lavoro. Segnala se l'utilizzo è bloccato per almeno il 95% per diversi minuti. |
| linux_iosd-image |
Processo Cisco IOS |
Prevedere un utilizzo elevato se si raccolgono output CLI di grandi dimensioni (show tech). Operazioni SNMP di grandi dimensioni o troppo frequenti possono causare un utilizzo elevato della CPU. |
| ginex |
Server Web |
Questo processo può mostrare picchi e può essere riportato solo su un carico elevato sostenuto. |
| ucode_pkt_PPE0 |
Data Plane in 9800CL/9800L |
Eseguire il comando show platform hardware chassis active qfp datapath usage per monitorare questo componente. |
| ezman |
Chipset Manager per interfacce |
Un elevato livello di CPU sostenuto può indicare un problema hardware o un possibile problema software del kernel (può essere segnalato). |
| DB |
Gestione database |
In questo caso è possibile segnalare un CPU costantemente elevata. |
| odm_X |
Operation Data Manager gestisce il database consolidato tra i processi |
Prevista CPU elevata sui sistemi caricati. |
| disgustoso |
Gestisce la funzionalità "Rogue" |
In questo caso è possibile segnalare un CPU costantemente elevata. |
| smand |
Shell Manager si occupa dell'analisi CLI e dell'interazione tra i diversi processi. |
Prevista CPU elevata per la gestione di output CLI di grandi dimensioni. È possibile indicare un elevato utilizzo della CPU in assenza di carico. |
| emd |
Shell Manager: gestisce l'analisi CLI e le interazioni tra processi diversi |
Prevista CPU elevata per la gestione di output CLI di grandi dimensioni. È possibile indicare un elevato livello di CPU in assenza di carico. |
| pubd |
Parte della gestione della telemetria |
CPU elevata prevista per sottoscrizioni di telemetria di grandi dimensioni. È possibile indicare un elevato livello di CPU in assenza di carico. |
Meccanismi di protezione della CPU elevati
I controller LAN wireless Catalyst 9800 dispongono di meccanismi di protezione estesi per l'attività dei client wireless o di rete al fine di evitare un utilizzo eccessivo della CPU a causa di scenari accidentali o intenzionali. Sono disponibili diverse funzionalità principali progettate per contribuire a contenere i dispositivi che presentano problemi:
Esclusione client
Questa opzione è attivata per impostazione predefinita e fa parte dei criteri di protezione wireless e può essere attivata o disattivata per profilo criteri. In questo modo è possibile rilevare diversi problemi di comportamento, rimuovere il client dalla rete e impostarlo in un elenco di esclusione temporaneo. Mentre il client si trova in questo stato escluso, gli access point non comunicano con loro, impedendo ulteriori azioni.
Trascorso il timer di esclusione (60 secondi per impostazione predefinita), il client può eseguire nuovamente l'associazione.
Sono disponibili diversi trigger per l'esclusione dei client:
- Generazione di un flusso ARP
- Ripetuti errori di associazione
- 3 o più errori di autenticazione webauth, PSK o 802.1x
- Timeout di autenticazione ripetuti (nessuna risposta dal client)
- Tentativo di riutilizzare un indirizzo IP già registrato in un altro client
L'esclusione dei client protegge il controller, l'access point e l'infrastruttura AAA (Radius) da diversi tipi di attività elevate che possono portare a un utilizzo elevato della CPU. Non è consigliabile disattivare alcun metodo di esclusione, a meno che non sia necessario per un esercizio di risoluzione dei problemi o un requisito di compatibilità.
Le impostazioni predefinite funzionano per quasi tutti i casi e solo in alcuni scenari eccezionali sono necessari per aumentare il tempo di esclusione o disattivare alcuni trigger specifici. Ad esempio, alcuni client legacy o specializzati (IOT/medici) devono avere il trigger di errore dell'associazione da disabilitare, a causa di difetti sul lato client che non possono essere facilmente corretti
È possibile personalizzare i trigger nell'interfaccia utente: Criteri di configurazione/protezione wireless/esclusione client:
Il trigger di esclusione ARP è stato progettato per essere abilitato in modo permanente a livello globale, ma può essere personalizzato in ogni profilo di criterio. È possibile controllare lo stato eseguendo il comando sh wireless profile policy all e cercare questo output specifico:
ARP Activity Limit
Exclusion : ENABLED
PPS : 100
Burst Interval : 5
Control Plane Protection dal traffico dati
Si tratta di un meccanismo avanzato nel Data Plane per garantire che il traffico inviato al Control Plane non superi una serie predefinita di soglie. Questa funzione è denominata Punt Policers e in quasi tutti gli scenari, non è necessario toccarli, e anche in questo caso, deve essere utilizzata solo quando si lavora con il supporto Cisco.
Il vantaggio di questa protezione è la possibilità di ottenere informazioni dettagliate sulla rete e su eventuali attività specifiche che comportano un aumento della velocità o un numero elevato di pacchetti al secondo.
Questo problema viene riscontrato solo dalla CLI, in quanto normalmente fanno parte di funzionalità avanzate che raramente richiedono modifiche.
Per ottenere una visualizzazione di tutti i criteri 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
L'elenco può contenere più di 160 voci, a seconda della versione del software. Nell'output della tabella, controllare la colonna dei pacchetti ignorati insieme a tutte le voci che hanno un valore diverso da zero nel conteggio massimo dei pacchetti. Per semplificare la raccolta dei dati, è possibile eseguire il comando show platform software punt-policer drop-only per filtrare solo le voci di policer con drop.
Questa funzione può essere utile per identificare se ci sono tempeste ARP o allagamenti sonda 802.11 (usano la coda 802.11 Packets to LFTS e LFTS stand per Linux Forwarding Transport Service).
Controllo dell'ingresso delle chiamate wireless
In tutte le versioni di manutenzione recenti, il controller dispone di un monitoraggio delle attività che consente di reagire in modo dinamico a un'elevata CPU e di garantire che i tunnel AP CAPWAP rimangano attivi in caso di pressioni insostenibili. Questa funzionalità controlla il carico WNCD e avvia la limitazione delle nuove attività client per garantire che siano disponibili risorse sufficienti per gestire le connessioni esistenti e proteggere la stabilità di CAPWAP. Questa funzionalità è abilitata per impostazione predefinita e non dispone di opzioni di configurazione.
Esistono tre livelli di protezione definiti: L1 con carico dell'80%, L2 con carico dell'85% e L3 con carico dell'89%. Ognuno di essi, attivando diversi protocolli in ingresso, viene perso come meccanismo di protezione. La protezione viene rimossa automaticamente al diminuire del carico.
In una rete integra, non è possibile visualizzare gli eventi di caricamento L2 o L3 e, se si verificano di frequente, è possibile analizzarli.
Per eseguire il monitoraggio, eseguire il 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
Protezione mDNS
mDNS come protocollo consente un approccio zero-touch per l'individuazione dei servizi tra i dispositivi, ma allo stesso tempo può essere molto attivo e, se non è configurato correttamente, può comportare un carico di unità significativo.
mDNS, senza alcun filtro, può facilmente aumentare l'utilizzo della CPU WNCD, grazie a diversi fattori:
- criteri mDNS con apprendimento illimitato, il controller ottiene tutti i servizi offerti da tutti i dispositivi. Ciò può portare a elenchi di servizi di grandi dimensioni, con centinaia di voci.
- Se si impostano criteri senza filtro, il controller eseguirà il push di tali elenchi di servizi di grandi dimensioni a ogni client che chiede a chi sta fornendo un determinato servizio.
- Alcuni servizi specifici di mDNS vengono forniti da tutti i client wireless, con conseguente aumento del numero di servizi e dell'attività con variazioni di questo per versione del sistema operativo.
È possibile controllare le dimensioni dell'elenco mDNS per servizio eseguendo questo 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
In questo modo è possibile avere un'idea delle dimensioni di una determinata query. Non denota un problema di per sé, ma solo un modo per monitorare ciò che viene tracciato. Di seguito sono riportati alcuni importanti suggerimenti per la configurazione di mDNS:
- Impostare il trasporto mDNS su un singolo protocollo:
9800-1(config)# mdns-sd gateway
9800-1(config-mdns-sd)# transport ipv4
Per impostazione predefinita, viene utilizzato il trasporto IPv4. Per ottenere prestazioni ottimali, è consigliabile utilizzare IPv6 o IPv4, ma non entrambi.
- Impostare sempre un filtro di percorso nei criteri del servizio mDNS per evitare query/risposte non associate. In generale, si consiglia di utilizzare il tag site, ma altre opzioni potrebbero funzionare, a seconda delle esigenze.
Ho bisogno di più assistenza
Se il carico della CPU è elevato e nessuna delle operazioni precedenti è utile, contattare l'assistenza clienti (CX) in una richiesta e aggiungere questi dati come punto di partenza:
- Dati di base, che includono la configurazione di AP/controller, la rete e i valori operativi RF:
show tech-support wireless
- Archivia tutte le tracce del controller. Si tratta di un file di grandi dimensioni simile a un concetto di blackbox che può essere raccolto eseguendo questo comando:
request platform software trace archive last <days> to-file bootflash:<archive file>
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
3.0 |
03-Aug-2026
|
Introduzione aggiornata, ortografia, grammatica, righe orizzontali inserite per separare sezioni/leggibilità, errori CCW corretti. |
2.0 |
06-Jun-2025
|
Aggiornamento del testo alternativo, dei requisiti di stile, della traduzione automatica, dei requisiti di personalizzazione e della formattazione in conformità alle linee guida Cisco per l'esternalizzazione |
1.0 |
09-May-2024
|
Versione iniziale |
Feedback