In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
Dieses Dokument beschreibt die Überwachung der CPU-Auslastung auf Catalyst 9800 Wireless LAN Controllern und enthält verschiedene Konfigurationsempfehlungen.
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 guter 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 behandelten Themen anzuwenden.
Die Catalyst Controller der Serie 9800 wurden als flexible Plattform konzipiert, die auf unterschiedliche Netzwerklasten ausgerichtet ist und sich auf die horizontale Skalierung konzentriert. Die interne Bezeichnung für die Entwicklung lautete eWLC mit dem "e" für "elastisch", um anzugeben, dass dieselbe Softwarearchitektur von einem kleinen, in eine CPU eingebetteten System auf mehrere große CPU/Core-Appliances ausgeführt werden kann.
Jeder WLC hat zwei verschiedene Seiten:
Vereinfacht ausgedrückt verfügt der Controller über Kommunikationsmechanismen zwischen der Kontroll- und Datenebene. Punkt: Der Controller sendet Datenverkehr vom Netzwerk zur Kontrollebene, und Injection: Übertragen von Frames von der Kontrollebene in das Netzwerk.
Im Rahmen einer Untersuchung zur möglichen hohen CPU-Fehlerbehebung müssen Sie den Punt-Mechanismus überwachen, um zu bewerten, welcher Datenverkehr die Kontrollebene erreicht und zu einer hohen Auslastung führen kann.
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. Ermöglicht beispielsweise ähnliche Funktionen für 9800CL im Vergleich zu 9800-40 bei unterschiedlichen Durchsatzskalen.
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 aufgrund seiner Client-Aktivität und des Access Points selbst hinzugefügt wird. Es gibt mehrere Mechanismen, um diesen Balancing auszuführen:
Wenn beispielsweise ein Router der Serie 9800-40 für eine Hauptniederlassung und fünf Zweigstellen mit unterschiedlichen AP-Nummern konfiguriert ist, könnte 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, es gibt insgesamt 6 Standort-Tags, und die Plattform verfügt über 5 WNCDs, sodass die Möglichkeit besteht, dass die am höchsten geladenen Standort-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. Er muss nicht exakt mit der AP-Anzahl übereinstimmen, wird aber normalerweise auf die erwarteten APs festgelegt, die beitreten können.
Für Hardwareplattformen ist die WNCD-Anzahl fest: 9800-40 hat 5, 9800-80 hat 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 herausfinden möchten, wie viele WNCDs im System ausgeführt werden, können Sie diesen Befehl in der Regel für alle Controller-Typen verwenden:
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 verwenden, show platform software system all
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
Die Zuordnung von AP zu WNCD wird während des AP-CAPWAP-Join-Vorgangs angewendet. Daher ist unabhängig von der Balancing-Methode keine Änderung während des Vorgangs zu erwarten, es sei denn, es gibt ein netzwerkweites CAPWAP-Reset-Ereignis, bei dem alle APs die Verbindung trennen und erneut verbinden.
Der CLI-Befehlshow wireless loadbalance tag affinity
bietet eine einfache Möglichkeit, den aktuellen Status des AP-Lastenausgleichs für alle WNCD-Instanzen anzuzeigen:
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-Auslastung korrelieren möchten, ist der einfachste Weg, das WCAE-Support-Tool zu verwenden und eine während der Stoßzeiten durchgeführte auszuladenshow tech wireless
. Das Tool fasst die Anzahl der WNCD-Clients zusammen, die von jedem AP genommen werden, der ihm zugeordnet ist.
Beispiel für einen richtig ausgeglichenen Controller bei geringer Nutzung und geringer Client-Anzahl:
Ein weiteres Beispiel für einen stärker ausgelasteten Controller, das die normale CPU-Auslastung zeigt:
Kurz gesagt, können Sie die verschiedenen Optionen in den folgenden Punkten zusammenfassen:
Dieser Schwellenwert von 500 APs ist zu markieren, wenn der Lastverteilungsmechanismus wirksam angewendet werden soll, da APs standardmäßig in Blöcken von 100 Einheiten gruppiert werden.
Es gibt Szenarien, in denen Sie ein erweitertes AP-Balancing durchführen möchten, 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 anstatt der reinen Fokussierung auf die Anzahl der im System vorhandenen Access Points ist.
Ein gutes Beispiel für diese Situation sind die Großveranstaltungen: In einem Gebäude könnten Tausende von Clients und über mehrere Hundert APs gehostet werden, und Sie müssten die Last auf so viele CPUs wie möglich aufteilen, aber gleichzeitig das Roaming optimieren. Sie können also nicht über WNCD roamen, es sei denn, es wird benötigt. Salz- und Pfefferstreuen sollten vermieden werden, wenn mehrere APs in verschiedenen WNCDs/Site-Tags am gleichen physischen Standort gemischt werden.
Mit dem WCAE-Tool können Sie die Access Point-RF-Ansicht optimieren und eine visuelle Darstellung der Verteilung bereitstellen:
Dies ermöglicht Ihnen, die AP/WNCD-Verteilung zu sehen, setzen Sie einfach auf WNCDView Type
. Hier würde jede Farbe eine WNCD/CPU repräsentieren. Sie können den RSSI-Filter auch auf -85 einstellen, um Low-Signal-Verbindungen zu vermeiden, die ebenfalls vom RRM-Algorithmus im Controller gefiltert werden.
Im vorherigen Beispiel, das mit Cisco Live EMEA 24 korrespondiert, können Sie sehen, dass die meisten benachbarten APs in einem WNCD-Cluster gut zusammengefasst sind, mit sehr begrenzten Überschneidungen.
Site-Tags, die demselben WNCD zugewiesen sind, erhalten dieselbe Farbe.
Denken Sie an das Konzept der Cisco IOS XE-Architektur, und beachten Sie, dass es zwei Hauptansichten der CPU-Auslastung gibt. Die eine Option stammt aus dem bisherigen Cisco IOS-Support und die andere aus der Hauptanwendung mit einem umfassenden Überblick über die CPU über alle Prozesse und Kerne hinweg.
Im Allgemeinen können Sie den Befehl verwenden, um detaillierte Informationen zu allen Prozessen in Cisco IOS XE zu sammelnshow processes cpu platform sorted
:
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
Hier sind einige wichtige Punkte hervorzuheben:
show tech wireless
bei IOSd-, smand-, pubd-Prozessen zu einer Spitzenlast führen, da eine sehr große Textausgabe erfasst wird und Hunderte von CLI-Befehlen ausgeführt werden. Dies ist kein Problem, und die Last fällt nach Abschluss der Ausgabe ab.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
überwachen. 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
Dies ist auf derMonitoring/System/CPU Utilization
Registerkarte verfügbar.
Die genaue Prozessliste hängt vom Controller-Modell und der Cisco IOS XE-Version ab. Dies ist eine Liste einiger der wichtigsten Prozesse, und es ist nicht beabsichtigt, alle möglichen Einträge abzudecken.
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 war die Auslastung hoch. Melden Sie, ob die Auslastung für 95 % oder mehr für mehrere Minuten feststeckt. |
linux_iosd-image |
IOS-Prozess |
Hohe Auslastung bei großer CLI-Ausgabe erwartet (Show Tech). Große oder zu häufige SNMP-Vorgänge können zu einer hohen CPU-Auslastung führen. |
Nginx |
Webserver |
Dieser Prozess kann Spitzen aufweisen und kann nur bei anhaltend hoher Belastung gemeldet werden. |
ucode_pkt_PPE0 |
Datenebene in 9800CL/9800L |
Verwenden Sie den Befehl |
Esman |
Chipsatzmanager für Schnittstellen |
Eine anhaltend hohe CPU hier könnte entweder auf ein HW-Problem oder ein mögliches Kernel-Software-Problem hinweisen. Es kann gemeldet werden. |
dbm |
Datenbank-Manager |
Eine anhaltend hohe CPU kann hier gemeldet werden. |
odm_X |
Operations Data Manager verwaltet die konsolidierte Datenbank prozessübergreifend. |
Hohe CPU auf geladenen Systemen erwartet. |
ungewollt |
Behandelt Funktionen für nicht autorisierte Zugriffe |
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. Übernimmt das CLI-Parsing und die Interaktion zwischen verschiedenen Prozessen. |
Hohe CPU bei Verarbeitung großer CLI-Ausgaben erwartet. Eine anhaltend hohe CPU kann bei nicht vorhandener Last gemeldet werden. |
Kneipe |
Teil der Telemetriehandlung |
Hohe CPU für große Telemetrie-Abonnements erwartet. Eine anhaltend hohe CPU kann bei nicht vorhandener Last gemeldet werden. |
Die Catalyst Wireless LAN Controller 9800 verfügen über umfassende Schutzmechanismen für die Netzwerk- oder Wireless-Client-Aktivität, um eine hohe CPU-Auslastung aufgrund von Zufällen oder Absichten zu vermeiden. Es gibt eine Reihe von wichtigen Funktionen, die Sie bei der Eindämmung problematischer Geräte unterstützen:
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:
Der Ausschluss des Clients schützt Ihren Controller, Ihre AP und Ihre AAA-Infrastruktur (Radius) vor verschiedenen Typen hoher Aktivität, die zu einer hohen CPU-Auslastung führen können. Im Allgemeinen ist es nicht ratsam, eine der Ausschlussmethoden zu deaktivieren, es sei denn, dies ist für eine Fehlerbehebung oder eine Kompatibilitätsanforderung erforderlich.
Die Standardeinstellungen funktionieren für fast alle Fälle, und nur in einigen Ausnahmefällen ist erforderlich, um die Ausschlusszeit zu erhöhen oder bestimmte Auslöser zu deaktivieren. Beispielsweise muss bei einigen älteren oder spezialisierten Clients (IOT/Medical) der Auslöser für den Verbindungsausfall deaktiviert werden, da Client-seitige Defekte vorliegen, die nicht einfach gepatcht werden können.
Sie können die Trigger in der Benutzeroberfläche anpassen: Konfiguration/Wireless-Schutz/Client-Ausschlussrichtlinien:
Der Auslöser für ARP-Ausschlüsse 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 mit dem Befehlsh wireless profile policy all
look for this specific output:
ARP Activity Limit
Exclusion : ENABLED
PPS : 100
Burst Interval : 5
Dies ist ein erweiterter Mechanismus in der Datenebene, der sicherstellt, dass der an die Kontrollebene gesendete Datenverkehr einen vordefinierten Satz von Schwellenwerten nicht überschreitet. Die Funktion wird als Punt Policers bezeichnet. In fast allen Szenarien ist es nicht erforderlich, diese zu berühren. Auch in diesem Fall muss lediglich mit dem Cisco Support zusammengearbeitet werden.
Der Vorteil dieses Schutzes besteht darin, dass er einen sehr detaillierten Einblick in die Vorgänge im Netzwerk bietet und Aufschluss darüber gibt, ob eine bestimmte Aktivität mit einer erhöhten Rate oder unerwartet hohen Paketen pro Sekunde stattfindet.
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, abhängig von der Softwareversion.
In der Tabellenausgabe möchten Sie die Spalte für verworfene Pakete zusammen mit allen Einträgen überprüfen, die einen Wert ungleich null für die hohe Verworfenzahl haben.
Um die Datensammlung zu vereinfachen, können Sie mit dem Befehlshow platform software punt-policer drop-only
nach Richtlinieneinträgen mit Verwerfungen 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. LFTS steht für Linux Forwarding Transport Service).
In allen aktuellen Wartungsversionen verfügt der Controller über einen Aktivitätsmonitor, um dynamisch auf hohe CPUs zu reagieren und sicherzustellen, dass AP-CAPWAP-Tunnel trotz nicht aufrecht zu erhaltenden Drucks aktiv bleiben. Die Funktion überprüft die WNCD-Last und drosselt neue Client-Aktivitäten, um sicherzustellen, dass genügend Ressourcen verbleiben, um die vorhandenen Verbindungen zu verarbeiten und die CAPWAP-Stabilität zu schützen. Dies ist standardmäßig aktiviert und verfügt nicht über Konfigurationsoptionen.
Es sind drei Schutzstufen definiert: L1 bei 80 % Last, L2 bei 85 % Last und L3 bei 89 %, von denen jede unterschiedliche eingehende Protokollverluste als Schutzmechanismen auslöst. Der Schutz wird automatisch entfernt, sobald die Last abnimmt.
In einem intakten Netzwerk können L2- oder L3-Lastereignisse nicht angezeigt werden. Wenn sie häufig auftreten, können sie untersucht werden.
Verwenden Sie zum Überwachen den Befehlwireless stats cac
, wie im Bild dargestellt.
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 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 die WNCD-CPU-Auslastung ohne jegliche Filterung aus verschiedenen Gründen erhöhen:
Mit dem folgenden Befehl können Sie die Größe der mDNS-Liste pro Dienst überprüfen:
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:
9800-1(config)# mdns-sd gateway
9800-1(config-mdns-sd)# transport ipv4
Standardmäßig wird IPv4-Transport verwendet. Aus Leistungsgründen ist es ratsam, entweder IPv6 oder IPv4 zu verwenden, aber nicht beides.
Falls Sie eine hohe CPU-Auslastung feststellen und keiner der vorherigen Schritte bei der Fehlerbehebung hilft, wenden Sie sich über ein Ticket an CX, und fügen Sie diese Daten als Ausgangspunkt hinzu:
show tech-support wireless
request platform software trace archive last <days> to-file bootflash:<archive file>
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
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 |