Fehlerbehebung: CPU-Last des Wireless LAN-Controllers
Inhalt
Einleitung
Dieses Dokument beschreibt die Überwachung der CPU-Auslastung auf Catalyst 9800 Wireless LAN Controllern und enthält verschiedene Konfigurationsempfehlungen.
Verständnis der CPU-Nutzung
Bevor Sie sich mit der Fehlerbehebung bei CPU-Auslastung befassen, müssen Sie sich mit den Grundlagen der Verwendung von CPUs in Catalyst 9800 Wireless LAN Controllern sowie mit einigen Details zur Softwarearchitektur vertraut machen.
Im Allgemeinen definiert das Catalyst 9800 Best Practices-Dokument eine Reihe von Konfigurationseinstellungen, die Probleme auf Anwendungsebene verhindern können. Verwenden Sie z. B. die Standortfilterung für mDNS, oder stellen Sie sicher, dass der Client-Ausschluss immer aktiviert ist. Es wird empfohlen, diese Empfehlungen zusammen mit den hier vorgestellten Themen anzuwenden.
Plattformgrundlagen
Die Catalyst Controller der Serie 9800 wurden als flexible Plattform für unterschiedliche Netzwerklasten mit Schwerpunkt auf horizontaler Skalierung konzipiert. Die interne Bezeichnung für die Entwicklung lautete eWLC mit dem "e" für "elastisch", um zu signalisieren, dass dieselbe Softwarearchitektur von einem kleinen, in eine einzelne CPU eingebetteten System auf mehrere große CPU/Core-Appliances ausgeführt wird.
Jeder WLC hat zwei verschiedene Seiten:
- Steuern Sie Fläche: Verarbeitung aller Management-Interaktionen wie CLI, UI, Netconf und aller Onboarding-Prozesse für Clients und APs
- Daten-Fläche: Verantwortlich für die tatsächliche Paketweiterleitung und -entkapselung von CAPWAP, die Durchsetzung von AVC-Richtlinien und anderen Funktionen.
Steuern Sie Fläche
- Die meisten Cisco IOS®-Prozesse werden unter BinOS (Linux Kernel) mit eigenen speziellen Scheduler- und Überwachungsbefehlen ausgeführt.
- Es gibt eine Reihe von Schlüsselprozessen, die als Wireless Network Control Daemon (WNCD) bezeichnet werden und jeweils über eine lokale In-Memory-Datenbank verfügen, die den Großteil der Wireless-Aktivitäten verarbeitet. Jede CPU besitzt einen WNCD, um die Last auf alle verfügbaren CPU-Kerne in jedem System zu verteilen.
- Die Lastverteilung auf WNCDs ist während des AP-Joins abgeschlossen. Wenn ein WAP eine CAPWAP-Verbindung mit dem Controller durchführt, verteilt ein interner Load Balancer den WAP unter Verwendung einer Reihe möglicher Regeln, um die ordnungsgemäße Verwendung aller verfügbaren CPU-Ressourcen sicherzustellen.
- Der Cisco IOS®-Code wird auf einem eigenen Prozess namens IOSd ausgeführt und verfügt über einen CPU-Scheduler. Dies übernimmt bestimmte Funktionen, z. B. CLI, SNMP, Multicast und Routing.
In einer vereinfachten Ansicht verfügt der Controller über Kommunikationsmechanismen zwischen der Kontroll- und Datenebene (Punkt). Er sendet Datenverkehr vom Netzwerk zur Kontrollebene und leitet dabei Frames von der Kontrollebene in das Netzwerk ein.
Im Rahmen einer Untersuchung zur möglichen hohen CPU-Fehlerbehebung müssen Sie den Punt-Mechanismus überwachen, um zu beurteilen, welcher Datenverkehr die Kontrollebene erreicht und zu einer hohen Auslastung führen kann.
Daten-Fläche
Für den Catalyst Controller der Serie 9800 wird dies im Rahmen des Cisco Packet Processor (CPP) ausgeführt, einem Software-Framework zur Entwicklung von Paketweiterleitungs-Engines, die für verschiedene Produkte und Technologien verwendet werden.
Die Architektur ermöglicht ein gemeinsames Feature-Set für verschiedene Hardware- oder Software-Implementierungen. Dies ermöglicht beispielsweise ähnliche Funktionen für 9800CL im Vergleich zu 9800-40 bei unterschiedlichen Durchsatzskalierungen.
AP-Lastenausgleich
Der WLC führt während des CAPWAP-Join-Prozesses einen Lastenausgleich über die CPUs hinweg durch, wobei das Hauptunterscheidungsmerkmal der Tag-Name des AP-Standorts ist. Die Idee dahinter ist, dass jeder Access Point eine spezifische CPU-Last repräsentiert, die durch seine Client-Aktivität und den Access Point selbst hinzugefügt wird. Es gibt mehrere Mechanismen, um diesen Balancing auszuführen:
- Wenn der Access Point ein Standard-Tag verwendet, gleicht er alle CPUs/WNCDs nach einem Round-Robin-Verfahren aus, wobei jeder neue AP-Join zum nächsten WNCD führt. Dies ist die einfachste Methode, hat jedoch einige Auswirkungen:
- Dies ist ein suboptimales Szenario, da die Access Points in derselben RF-Roaming-Domäne häufig Inter-WNCD-Roaming nutzen, was eine zusätzliche Kommunikation zwischen den Prozessen erfordert. Das Roaming zwischen Instanzen ist um einen kleinen Prozentsatz langsamer.
- Für das FlexConnect-Site-Tag (remote) ist keine PMK-Schlüsselverteilung verfügbar. Dies bedeutet, dass Sie kein schnelles Roaming für den Flex-Modus durchführen können, was sich auf den OKC/FT-Roaming-Modus auswirkt.
Im Allgemeinen kann das Standard-Tag bei Szenarien mit geringerer Auslastung (z. B. weniger als 40 % der AP- und Client-Auslastung der 9800-Plattform) und bei FlexConnect-Bereitstellungen nur dann verwendet werden, wenn kein schnelles Roaming erforderlich ist.
- Wenn der Access Point über ein benutzerdefiniertes Site-Tag verfügt, wird das Site-Tag einer bestimmten WNCD-Instanz zugewiesen, wenn ein Access Point zum ersten Mal zu dem Namen des Site-Tags gehört, der mit dem Controller verknüpft ist. Alle nachfolgenden zusätzlichen AP-Joins mit demselben Tag werden demselben WNCD zugewiesen. Dadurch wird sichergestellt, dass das Roaming zwischen APs mit demselben Site-Tag im selben WCND-Kontext erfolgt. Dies sorgt für einen optimierten Datenfluss bei geringerer CPU-Auslastung. Roaming zwischen WNCDs wird unterstützt, beim Intra-WNCD-Roaming jedoch nicht.
- Standardentscheidung für den Lastenausgleich: Wenn einem WNCD ein Tag zugewiesen wird, wählt der Load Balancer die Instanz mit der niedrigsten Anzahl von Site-Tags zu diesem Zeitpunkt aus. Die Gesamtlast, die das Site-Tag haben kann, ist unbekannt. Dies kann zu suboptimalen Ausgleichsszenarien führen. Dies hängt von der Reihenfolge der AP-Joins ab, von der Anzahl der definierten Site-Tags und davon, ob die Anzahl der APs in diesen Geräten asymmetrisch ist.
- Statischer Lastenausgleich: Um eine unausgewogene Zuweisung von Sitetags zu WNCD zu verhindern, wurde der Befehl site load in Version 17.9.3 und höher eingeführt. So können Administratoren die erwartete Last für jeden Site-Tag vorab definieren. Dies ist bei Campus-Szenarien oder mehreren Zweigstellen nützlich, die jeweils unterschiedlichen AP-Zählern zugeordnet sind, um sicherzustellen, dass die Last gleichmäßig auf die WNCD verteilt wird.
Wenn ein Router der Serie 9800-40 eine Hauptniederlassung sowie fünf Zweigstellen mit unterschiedlichen AP-Nummern verwaltet, kann die Konfiguration wie folgt aussehen:
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 diesem Szenario soll sich das Tag der Hauptniederlassung nicht auf demselben WNCD wie branch-3 und branch-4 befinden. Insgesamt gibt es 6 Site-Tags, und die Plattform verfügt über 5 WNCDs, und es besteht die Möglichkeit, dass die am höchsten geladenen Site-Tags auf derselben CPU landen. Mit dem Befehl load können Sie eine vorhersagbare AP-Lastenausgleichstopologie erstellen.
Der Befehl load entspricht einer erwarteten Größe. Die Anzahl der Access Points muss nicht exakt der Anzahl der Access Points entsprechen. Normalerweise wird sie jedoch auf die erwarteten Access Points festgelegt, die hinzugefügt werden können.
- In Szenarien, in denen große Gebäude von einem einzelnen Controller verwaltet werden, ist es einfacher, so viele Site-Tags wie WNCDs für diese spezielle Plattform zu erstellen (z. B. C9800-40 hat 5, C9800-80 hat 8). Weisen Sie APs im gleichen Bereich oder in der gleichen Roaming-Domäne den gleichen Standort-Tags zu, um die Kommunikation zwischen WNCDs zu minimieren.
- RF-Lastenausgleich: Auf diese Weise werden APs zwischen WNCD-Instanzen mithilfe der RF-Nachbarbeziehung von RRM ausgeglichen, und es werden Untergruppen erstellt, je nachdem, wie nahe die APs aneinander liegen. Dieser Vorgang muss abgeschlossen werden, nachdem die Access Points eine Weile in Betrieb waren. Außerdem müssen keine statischen Lastenausgleichseinstellungen mehr konfiguriert werden. Diese Version ist ab dem 17.12. und höher verfügbar.
So finden Sie heraus, wie viele WNCDs vorhanden sind
Für Hardwareplattformen ist die WNCD-Anzahl fest: 9800-40 hat 5, 9800-80 8. Für 9800CL (virtuell) hängt die Anzahl der WNCDs von der Vorlage des virtuellen Systems ab, die bei der Erstbereitstellung verwendet wurde.
Wenn Sie ermitteln möchten, wie viele WNCDs im System ausgeführt werden, können Sie diesen Befehl in der Regel für alle Controller-Typen ausführen:
9800-40#show processes cpu platform sorted | count wncd
Number of lines which match regexp = 5
Im Fall von 9800-CL können Sie den Befehl show platform software system all ausführen, um Details zur virtuellen Plattform zu sammeln:
9800cl-1#show platform software system all
Controller Details:
=================
VM Template: small
Throughput Profile: low
AP Scale: 1000
Client Scale: 10000
WNCD instances: 1
Überwachen des AP-Lastenausgleichs
Die Zuordnung von AP zu WNCD wird während des AP-CAPWAP-Join-Prozesses angewendet, und es wird nicht erwartet, dass sie sich während des Betriebs ändert, unabhängig von der Balancing-Methode. Es sei denn, es findet ein netzwerkweites CAPWAP-Zurücksetzungsereignis statt, bei dem alle APs die Verbindung trennen und erneut beitreten.
Mit dem Befehl CLI show wireless load balance tag affinity kann der aktuelle Status des AP-Lastenausgleichs für alle WNCD-Instanzen angezeigt werden:
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
Wenn Sie die AP-Verteilung mit der Client-Anzahl und der CPU-Last korrelieren möchten, können Sie das WCAE-Support-Tool verwenden und ein Show-Wireless-Netzwerk laden, das während Spitzenzeiten verwendet wurde. Das Tool fasst die Anzahl der WNCD-Clients zusammen, die von jedem AP genommen werden, der ihm zugeordnet ist.
Dies ist ein Beispiel für einen Controller, der bei geringer Nutzung und bei geringer Client-Anzahl einen angemessenen Ausgleich bietet:
Ein weiteres Beispiel ist für einen stärker ausgelasteten Controller, der die normale CPU-Auslastung anzeigt:
Was ist der empfohlene AP-Lastenausgleichsmechanismus?
Kurz gesagt, können Sie die verschiedenen Optionen in den folgenden Punkten zusammenfassen:
- Kleine Netzwerke, kein schnelles Roaming erforderlich, weniger als 40 % der Controller-Last: Standard-Tag.
- Wenn schnelles Roaming erforderlich ist (OKC, FT, CCKM), oder eine große Client-Anzahl:
- Zentrales Gebäude: Erstellen Sie so viele Site-Tags wie CPUs (plattformabhängig).
- Vor 17.12 oder weniger als 500 APs: Mehrere Gebäude, Zweigstellen oder große Anlagen: Erstellen Sie ein Site-Tag pro physischem RF-Standort, und konfigurieren Sie den Ladebefehl pro Standort.
- 17.12 und höher mit mehr als 500 APs: RF-Lastenausgleich verwenden.
Dieser Schwellenwert von 500 APs ist zu markieren, wenn der Lastverteilungsmechanismus wirksam angewendet wird, da APs standardmäßig in Blöcken von 100 Einheiten gruppiert werden.
AP-WNCD-Verteilungsvisualisierung
Es gibt Szenarien, in denen Sie erweitertes AP-Balancing anwenden können, und es ist wünschenswert, eine präzise Kontrolle darüber zu haben, wie APs über CPUs verteilt sind. Beispiel: Szenarien mit sehr hoher Dichte, bei denen die Hauptauslastungsmetrik die Client-Anzahl im Vergleich zur Anzahl der im System vorhandenen APs ist.
Ein gutes Beispiel für diese Situation sind große Ereignisse, bei denen ein Gebäude Tausende von Clients über mehrere Hundert APs hosten kann, und Sie müssen die Last auf so viele CPUs wie möglich aufteilen, aber gleichzeitig das Roaming optimieren. Sie roamen nicht über WNCD, es sei denn, es wird benötigt. Sie möchten Situationen vermeiden, in denen mehrere APs in verschiedenen WNCDs/Site-Tags am gleichen physischen Standort gemischt sind.
Mit dem WCAE-Tool können Sie die AP-RF-Ansicht optimieren und eine visuelle Darstellung der Verteilung bereitstellen:
Dadurch können Sie die AP/WNCD-Verteilung anzeigen, setzen Sie einfach den View Type auf WNCD. Jede Farbe repräsentiert eine WNCD/CPU und Sie können den RSSI-Filter auf -85 einstellen, um Verbindungen mit niedrigen Signalen zu vermeiden. Diese werden ebenfalls durch den RRM-Algorithmus im Controller gefiltert.
Im vorherigen Beispiel, das mit Cisco Live EMEA 24 korrespondiert, können Sie sehen, dass die meisten benachbarten APs über denselben WNCD geclustert sind und sich nur sehr begrenzt überschneiden. Site-Tags, die demselben WNCD zugewiesen sind, erhalten dieselbe Farbe.
Überwachung der CPU-Nutzung der Kontrollebene
Denken Sie an das Konzept der Cisco IOS XE-Architektur, und beachten Sie, dass es zwei Hauptansichten der CPU-Auslastung gibt. Die eine Lösung basiert auf dem bisherigen Cisco IOS-Support, die andere auf einem ganzheitlichen Überblick über die CPU aller Prozesse und Kerne.
Im Allgemeinen können Sie den Befehl show processes cpu platform sortiert ausführen, um detaillierte Informationen zu allen Prozessen in Cisco IOS XE zu sammeln:
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
Die wichtigsten Punkte sind:
- Der Prozess ucode_pkt_PPE0 verarbeitet die Datenebene auf 9800L- und 9800CL-Plattformen. Es wird erwartet, dass es eine hohe Auslastung die ganze Zeit, sogar höher als 100%. Dies ist Teil der Umsetzung und stellt kein Problem dar.
- Es ist wichtig, die Spitzenauslastung von der Dauerauslastung zu unterscheiden und die erwarteten Ergebnisse für ein bestimmtes Szenario zu isolieren. Beispielsweise kann das Erfassen einer sehr großen CLI-Ausgabe, wie show tech wireless, eine Spitzenlast für IOSd-, smand- und pubd-Prozesse erzeugen, da eine sehr große Textausgabe mit Hunderten von ausgeführten CLI-Befehlen erfasst wird. Dies ist kein Problem und die Last nimmt ab, sobald die Ausgabe abgeschlossen ist.
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
- Die Spitzenauslastung der WNCD-Kerne wird bei hohen Client-Aktivitäten erwartet. Man kann Spitzen von 80% sehen, ohne dass die Funktion beeinträchtigt wird, und sie verursachen in der Regel kein Problem.
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
- Eine anhaltend hohe CPU-Auslastung bei einem Prozess, der länger als 15 Minuten über 90 % liegt, muss untersucht werden.
- Sie können die IOSd-CPU-Auslastung überwachen, indem Sie den Befehl show processes cpu sorted ausführen. Dies entspricht der Aktivität im linux_iosd-imag Prozess Teil der Cisco IOS XE Liste.
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
- Sie können die Benutzeroberfläche des 9800 für eine kurze Übersicht über die IOSd-Last, die Nutzung pro Kern und die Last auf Datenebene verwenden:
Diese Funktion steht auf der Registerkarte Monitoring/System/CPU Utilization (Überwachung/System/CPU-Auslastung) zur Verfügung.
Was ist der jeweilige Prozess?
Die Prozessliste hängt vom Controller-Modell und der Cisco IOS XE-Version ab. Dies ist eine Liste einiger wichtiger Prozesse, die nicht alle möglichen Einträge abdecken soll.
| Prozessname |
Aufgaben |
Evaluierung |
| wcd_x |
Verarbeitung der meisten Wireless-Vorgänge Je nach Modell 9800 können zwischen 1 und 8 Instanzen vorhanden sein. |
Zu Spitzenzeiten ist die Auslastung hoch, auch zu Spitzenzeiten. Melden Sie, ob die Auslastung für 95 % oder mehr für mehrere Minuten feststeckt. |
| linux_iosd-image |
Cisco IOS-Prozess |
Bei großen CLI-Ausgaben ist eine hohe Auslastung zu erwarten (show tech). Große oder zu häufige SNMP-Vorgänge können zu einer hohen CPU-Auslastung führen. |
| Nginx |
Webserver |
Dieser Vorgang kann Spitzen aufweisen und nur bei anhaltend hoher Belastung gemeldet werden. |
| ucode_pkt_PPE0 |
Datenebene in 9800CL/9800L |
Führen Sie den Befehl show platform hardware chassis active qfp datapath usage aus, um diese Komponente zu überwachen. |
| Esman |
Chipsatz-Manager für Schnittstellen |
Eine anhaltend hohe CPU kann entweder auf ein HW-Problem oder ein mögliches Kernel-Software-Problem hinweisen (es kann berichtet werden). |
| dbm |
Datenbank-Manager |
Eine anhaltend hohe CPU kann hier gemeldet werden. |
| odm_X |
Operations Data Manager verwaltet eine konsolidierte Datenbank prozessübergreifend |
Hohe CPU auf geladenen Systemen erwartet. |
| ungewollt |
Behandelt nicht autorisierte Funktionen |
Eine anhaltend hohe CPU kann hier gemeldet werden. |
| klug |
Shell Manager übernimmt das CLI-Parsing und die Interaktion zwischen verschiedenen Prozessen. |
Hohe CPU bei Verarbeitung großer CLI-Ausgaben erwartet. Eine dauerhaft hohe CPU kann bei nicht vorhandener Last gemeldet werden. |
| Mittelwert |
Shell-Manager - Verarbeitet CLI-Parsing und Interaktionen über verschiedene Prozesse hinweg |
Hohe CPU bei Verarbeitung großer CLI-Ausgaben erwartet. Eine anhaltend hohe CPU kann bei nicht vorhandener Last gemeldet werden. |
| Kneipe |
Teil der Telemetriehandhabung |
Hohe CPU für große Telemetrie-Abonnements erwartet. Eine anhaltend hohe CPU kann bei nicht vorhandener Last gemeldet werden. |
Hohe CPU-Schutzmechanismen
Die Catalyst Wireless LAN Controller der Serie 9800 verfügen über umfassende Schutzmechanismen für Netzwerk- oder Wireless-Client-Aktivitäten, um eine hohe CPU-Auslastung aufgrund von versehentlichen oder absichtlichen Szenarien zu vermeiden. Es gibt eine Reihe wichtiger Funktionen, die bei der Eindämmung problematischer Geräte helfen:
Client-Ausschluss
Diese Funktion ist standardmäßig aktiviert und ist Teil der Wireless-Sicherheitsrichtlinien. Sie kann über das Richtlinienprofil aktiviert oder deaktiviert werden. Dadurch können verschiedene Verhaltensprobleme erkannt, der Client aus dem Netzwerk entfernt und in eine temporäre Ausschlussliste gesetzt werden. Während sich der Client in diesem ausgeschlossenen Zustand befindet, kommunizieren die Access Points nicht mit ihnen und verhindern somit weitere Aktionen.
Nach Ablauf des Ausschlusszeitgebers (standardmäßig 60 Sekunden) kann der Client erneut eine Verbindung herstellen.
Es gibt mehrere Auslöser für den Ausschluss von Clients:
- Generieren einer ARP-Flut
- Wiederholte Zuordnungsfehler
- 3 oder mehr WebAuth-, PSK- oder 802.1x-Authentifizierungsfehler
- Timeouts für wiederholte Authentifizierung (keine Antwort vom Client)
- Es wird versucht, eine bereits bei einem anderen Client registrierte IP-Adresse wiederzuverwenden.
Der Ausschluss des Clients schützt Ihren Controller, AP und Ihre AAA-Infrastruktur (Radius) vor verschiedenen Typen hoher Aktivität, die zu einer hohen CPU-Auslastung führen können. Es ist nicht ratsam, Ausschlussmethoden zu deaktivieren, es sei denn, dies ist für eine Fehlerbehebungsübung oder eine Kompatibilitätsanforderung erforderlich.
Die Standardeinstellungen gelten für fast alle Fälle, und nur in bestimmten Ausnahmefällen ist eine Verlängerung der Ausschlusszeit oder die Deaktivierung bestimmter Auslöser erforderlich. Beispielsweise muss bei einigen älteren oder spezialisierten Clients (IOT/Medical) der Auslöser für den Verbindungsausfall deaktiviert sein, da Client-seitige Defekte vorliegen, die nicht einfach behoben werden können.
Sie können die Trigger in der Benutzeroberfläche anpassen: Konfiguration/Wireless-Schutz/Client-Ausschlussrichtlinien:
Der ARP-Ausschlussauslöser wurde so konzipiert, dass er auf globaler Ebene dauerhaft aktiviert ist. Er kann jedoch für jedes Richtlinienprofil angepasst werden. Sie können den Status überprüfen, indem Sie den Befehl sh wireless profile policy all ausführen und nach der folgenden Ausgabe suchen:
ARP Activity Limit
Exclusion : ENABLED
PPS : 100
Burst Interval : 5
Schutz der Kontrollebene vor Datenverkehr
Dies ist ein erweiterter Mechanismus in der Datenebene, der sicherstellt, dass der an die Kontrollebene gesendete Datenverkehr einen vordefinierten Satz von Schwellenwerten nicht überschreitet. Diese Funktion wird als Punt Policers bezeichnet. In fast allen Szenarien ist es nicht erforderlich, diese zu berühren, und selbst dann muss sie nur bei der Arbeit mit dem Cisco Support verwendet werden.
Der Vorteil dieses Schutzes besteht darin, dass er einen detaillierten Einblick in das Netzwerk bietet und Aufschluss darüber gibt, ob eine bestimmte Aktivität eine erhöhte Geschwindigkeit oder unerwartet hohe Datenpakete pro Sekunde aufweist.
Dies wird nur über die CLI verfügbar gemacht, da sie normalerweise Teil erweiterter Funktionen sind, die selten geändert werden müssen.
So erhalten Sie einen Überblick über alle Strategien:
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
Dies kann eine große Liste mit mehr als 160 Einträgen sein, je nach Softwareversion. Überprüfen Sie in der Tabellenausgabe die Spalte für verworfene Pakete sowie alle Einträge, deren Wert ungleich null ist, für die hohe Anzahl verworfener Pakete. Um die Datenerfassung zu vereinfachen, können Sie den Befehl show platform software punt-policer drop-only ausführen, um nur nach Richtlinieneinträgen mit Verwerfungen zu filtern.
Diese Funktion kann nützlich sein, um ARP-Stürme oder 802.11-Überflutungen zu identifizieren (sie verwenden die Warteschlange 802.11 Packets to LFTS und LFTS steht für Linux Forwarding Transport Service).
Wireless-Anrufzugangskontrolle
In allen aktuellen Wartungsversionen verfügt der Controller über einen Aktivitätsmonitor, der dynamisch auf hohe CPU-Auslastungen reagiert und sicherstellt, dass AP-CAPWAP-Tunnel bei nicht nachhaltigem Druck aktiv bleiben. Diese Funktion überprüft die WNCD-Last und drosselt neue Client-Aktivitäten, um sicherzustellen, dass genügend Ressourcen verfügbar bleiben, um bestehende Verbindungen zu verarbeiten und die CAPWAP-Stabilität zu schützen. Diese Funktion ist standardmäßig aktiviert und verfügt über keine Konfigurationsoptionen.
Es sind drei Schutzstufen definiert: L1 bei 80 % Last, L2 bei 85 % Last und L3 bei 89 %. Jede einzelne löst verschiedene eingehende Protokolle aus und wird als Schutzmechanismus verworfen. Der Schutz wird automatisch entfernt, sobald die Last abnimmt.
In einem intakten Netzwerk können L2- oder L3-Lastereignisse nicht angezeigt werden, und wenn sie häufig auftreten, können sie untersucht werden.
Führen Sie zum Überwachen den Befehl wireless stats cac aus:
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
mDNS-Schutz
mDNS als Protokoll ermöglicht einen Zero-Touch-Ansatz zur Erkennung von Diensten auf verschiedenen Geräten. Gleichzeitig kann es jedoch sehr aktiv sein und die Auslastung deutlich erhöhen, wenn es nicht richtig konfiguriert ist.
mDNS kann ohne jegliche Filterung die WNCD-CPU-Auslastung aus verschiedenen Gründen erhöhen:
- mDNS-Richtlinien mit uneingeschränktem Lernen: Der Controller bezieht alle Dienste, die von allen Geräten angeboten werden. Dies kann zu umfangreichen Servicelisten mit Hunderten von Einträgen führen.
- Wenn Richtlinien ohne Filterung festgelegt werden, überträgt der Controller diese umfangreichen Servicelisten an jeden Client, der fragt, wer einen bestimmten Service bereitstellt.
- Einige mDNS-spezifische Dienste werden von allen Wireless-Clients bereitgestellt, was zu einer höheren Anzahl von Diensten und einer höheren Aktivität führt, wobei diese je nach Betriebssystemversion variieren.
Sie können die Größe der mDNS-Liste pro Dienst überprüfen, indem Sie den folgenden Befehl ausführen:
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
Dies kann eine Vorstellung davon geben, wie groß eine bestimmte Abfrage werden kann. Es stellt kein Problem an sich dar, sondern lediglich eine Möglichkeit, zu überwachen, was verfolgt wird. Es gibt einige wichtige Empfehlungen für die mDNS-Konfiguration:
- Legen Sie für den mDNS-Transport ein einzelnes Protokoll fest:
9800-1(config)# mdns-sd gateway
9800-1(config-mdns-sd)# transport ipv4
Standardmäßig wird IPv4-Transport verwendet. Aus Leistungsgründen wird IPv6 oder IPv4 empfohlen, jedoch nicht beides.
- Legen Sie in der mDNS-Dienstrichtlinie immer einen Standortfilter fest, um ungebundene Abfragen/Antworten zu vermeiden. Im Allgemeinen wird empfohlen, site-tag zu verwenden, aber andere Optionen können je nach Ihren Anforderungen funktionieren.
Ich benötige mehr Unterstützung
Wenn Sie eine hohe CPU-Auslastung feststellen und keiner der vorherigen Schritte bei der Fehlerbehebung hilfreich ist, wenden Sie sich an Customer Experience (CX), und fügen Sie diese Daten als Ausgangspunkt hinzu:
- Basisdaten, einschließlich AP/Controller-Konfiguration, Netzwerk- und RF-Betriebswerte:
show tech-support wireless
- Archiv für alle Controller-Traces. Dies ist eine große Datei, die einem Blackbox-Konzept ähnelt und mit dem folgenden Befehl erfasst werden kann:
request platform software trace archive last <days> to-file bootflash:<archive file>
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
3.0 |
03-Aug-2026
|
Aktualisierte Einführung, Rechtschreibung, Grammatik, eingefügte horizontale Linien für separate Abschnitte/Lesbarkeit, korrigierte CCW-Fehler. |
2.0 |
06-Jun-2025
|
Aktualisierter Alternativer Text, Stilanforderungen, maschinelle Übersetzung, Branding-Anforderungen und Formatierung im Einklang mit den Richtlinien von Cisco für die Externalisierung |
1.0 |
09-May-2024
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)