Fehlerbehebung bei hoher CPU-Auslastung aufgrund des SNMP-Prozesses
Einleitung
In diesem Dokument wird ein strukturierter Ansatz zur Fehlerbehebung und Behebung einer hohen CPU-Auslastung beim SNMP-Prozess auf einem Wireless LAN-Controller der Serie 9800 beschrieben.
Verwendete Komponenten
Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:
- Wireless-Controller: C9800-80-K9 mit 17.09.03
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Protokollsammlung
Identifizieren von CPU-Auslastungsmustern Nach Erhalt eines Berichts über eine hohe CPU-Auslastung, der mit dem SNMP-Prozess verknüpft ist, besteht die erste Vorgehensweise darin, detaillierte Protokolle über einen festgelegten Zeitraum zu sammeln. Dies hilft, ein Muster oder einen Trend bei der CPU-Auslastung zu ermitteln, das bzw. der ausschlaggebend dafür ist, wann der SNMP-Prozess am aktivsten und ressourcenintensivsten ist.
Vor Beginn der Protokollsammlung müssen spezifische Informationen gesammelt werden, die zur Unterstützung des Fehlerbehebungsprozesses verwendet werden. Sammeln Sie zunächst nur wenige Informationen zu dem Problem.
- Kommt es im System zu Spitzenlasten oder ist die Nutzung durchgängig hoch?
- Wie hoch ist der prozentuale Anteil der Nutzung in beiden Fällen?
- Wie oft wird die CPU ausgelastet?
- Wie häufig fragt jeder SNMP-Server den WLC ab?
- Wer sind die Top Talkers?
Sammeln Sie die Befehlsausgabe von 9800 WLC in zweiminütigen Intervallen über einen Zeitraum von zehn Minuten. Diese Daten können verwendet werden, um Probleme mit der CPU-Auslastung zu analysieren, insbesondere solche, die mit dem SNMP-Prozess zusammenhängen.
#terminal length 0 #show clock #show process cpu sorted | exclude 0.0 #show process cpu history #show processes cpu platform sorted | exclude 0.0 #show snmp stats oid #show snmp stats hosts
Protokollanalyse
Nachdem Sie diese Protokolle gesammelt haben, müssen Sie sie analysieren, um die Auswirkungen zu verstehen.
Betrachten wir ein Beispiel für CPU-Nutzungsprotokolle, um den SNMP-Prozess zu identifizieren, der die meiste CPU beansprucht.
WLC#show process cpu sorted | exclude 0.0 CPU utilization for five seconds: 96%/7%; one minute: 76%; five minutes: 61% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 250 621290375 58215467 10672 58.34% 39.84% 34.11% 0 SNMP LA Cache pr <-- High utilization 93 167960640 401289855 418 14.50% 11.88% 9.23% 0 IOSD ipc task 739 141604259 102242639 1384 8.57% 6.95% 7.21% 0 SNMP ENGINE 763 7752 34896 222 4.00% 3.41% 1.83% 5 SSH Process 648 6216707 181047548 34 0.72% 0.37% 0.31% 0 IP SNMP 376 3439332 51690423 66 0.40% 0.36% 0.25% 0 SNMP Timers 143 3855538 107654825 35 0.40% 0.35% 0.23% 0 IOSXE-RP Punt Se 108 6139618 17345934 353 0.40% 0.30% 0.34% 0 DBAL EVENTS
Die Ausgabe des Anzeigeprozesses cpu sortiert | exclude 0.0-Befehl gibt an, dass der SNMP-Prozess tatsächlich eine unverhältnismäßig große Menge an CPU-Ressourcen beansprucht. Insbesondere der SNMP LA Cache pro Prozess ist am CPU-intensivsten, gefolgt von anderen SNMP-bezogenen Prozessen.
Der nächste Befehlssatz soll uns dabei helfen, detaillierte Informationen zum Prozess der hohen SNMP-Auslastung zu erhalten.
WLC#show snmp stats oid time-stamp #of times requested OID 11:02:33 Austral Jun 8 2023 27698 bsnAPIfDBNoisePower <-- Frequently polled OID 11:02:23 Austral Jun 8 2023 1 sysUpTime 11:02:23 Austral Jun 8 2023 17 cLSiD11SpectrumIntelligenceEnable 11:02:23 Austral Jun 8 2023 1 cLSiD11SpectrumIntelligenceEnable 11:02:23 Austral Jun 8 2023 6 cLSiD11Band 11:02:23 Austral Jun 8 2023 1 cLSiD11Band 11:02:23 Austral Jun 8 2023 1 cLSiD11Band 11:02:23 Austral Jun 8 2023 1 cLSiD11Band 11:02:19 Austral Jun 8 2023 24 clcCdpApCacheApName 11:02:19 Austral Jun 8 2023 1 clcCdpApCacheDeviceIndex 11:02:19 Austral Jun 8 2023 9 cLApCpuAverageUsage 11:02:19 Austral Jun 8 2023 1315 cLApCpuCurrentUsage 11:02:19 Austral Jun 8 2023 2550 bsnAPIfDBNoisePower
Die Ausgabe des Befehls show snmp stats oid gibt die Häufigkeit an, mit der verschiedene OIDs abgefragt werden. Eine bestimmte OID, bsnAPIfDBNoisePower, sticht durch die außerordentlich hohe Anzahl von Anfragen hervor. Dies deutet darauf hin, dass ein aggressives Polling dieser OID wahrscheinlich zu der hohen CPU-Auslastung beiträgt, die auf dem WLC beobachtet wird.
Versuchen wir zu verstehen, was die OID bsnAPIfDBNoisePower tut und seine Datenspeicherzeiten.
Navigieren Sie zu SNMP Object Navigator, und suchen Sie die OID "bsnAPIfDBNoisePower".
OID-Suchergebnis
Das Objekt bsnAPIfDBNoisePower gibt die Rauschleistung der einzelnen Kanäle an, die von den einzelnen Access Points gemeldet werden. Angesichts der großen Anzahl von Kanälen und APs, die vom WLC verwaltet werden, können die von dieser OID generierten SNMP-Daten erheblich sein. Wenn der WLC eine große Anzahl von APs bedient, kann das durch das Polling dieser OID erzeugte Datenvolumen immens sein. Dies kann zu einer hohen CPU-Auslastung führen, da der WLC diese umfangreichen SNMP-Anforderungen verarbeitet.
Ebenso müssen Sie das Verhalten der spezifischen OID verstehen, die aggressiv abgefragt wird.
Der nächste Befehl dient dazu, Sie über die SNMP-Server zu informieren, die den WLC abfragen.
WLC#show snmp stats hosts Request Count Last Timestamp Address 77888844 00:00:00 ago 10.10.10.120 330242 00:00:08 ago 10.10.10.150 27930314 00:00:09 ago 10.10.10.130 839999 00:00:36 ago 10.10.10.170 6754377 19:45:34 ago 10.10.10.157 722 22:00:20 ago 10.10.10.11
Dieser Befehl stellt eine Liste der SNMP-Server mit ihrer Anfrageanzahl und dem letzten Zeitstempel ihrer Abfrageaktivität bereit.
Wie Sie sehen, werden vom 9800 WLC mehrere verschiedene Server abgefragt. Wenn Sie sich die vollständigen Protokolldaten ansehen, die in den letzten 10 Minuten gesammelt wurden, können Sie auch deren Abfragehäufigkeit messen.
Sie können nun zu jedem Server gehen und sehen, wie oft die OID abgefragt wird, die eine Sicherheitsverletzung darstellt. In diesem Beispiel wird die OID alle 30 Sekunden abgefragt, was deutlich häufiger als erforderlich ist. Da der WLC alle 180 Sekunden RF/RRM-Daten empfängt, führt das Polling der OID alle 30 Sekunden zu unnötiger Verarbeitung und trägt zu einer hohen CPU-Auslastung bei.
Sobald die OID des Angreifers und der Server identifiziert wurden, können wir mehrere verschiedene Lösungen ausprobieren, um die Belastung des WLC zu reduzieren.
- Reduzieren Sie die Abfragehäufigkeit auf dem SNMP-Server.
- Wenn die OID für die Betriebsnutzung nicht benötigt wird, deaktivieren Sie das Polling dieser OID vom SNMP-Server.
- Wenn Sie keine Kontrolle über den SNMP-Server haben, können Sie die SNMP-Ansicht verwenden, um die beanstandete OID zu blockieren.
Konfiguration der SNMP-Ansicht
Definieren Sie eine neue Ansicht, die die zu sperrende OID ausschließt. Sie möchten z. B. die OID 1.3.6.1.4.1.14179.2.2.15.1.21 blockieren, eine neue Ansicht erstellen und die OID an die Ansicht anhängen.
snmp-server view blockOIDView 1.3.6.1.4.1.14179.2.2.15.1.21 excluded <-- This is the OID of bsnAPIfDBNoisePower
snmp-server community TAC view blockOIDView RO <-- This command assigns the blockOIDView to the community myCommunity with read-only (RO) access.
snmp-server group TAC v3 priv read blockOIDView <-- This command assigns the blockOIDView to the group myGroup with the priv security level for SNMPv3.Tipp zur Fehlerbehebung
- Baseline-CPU-Auslastung: Dokumentieren der normalen CPU-Auslastung, wenn der SNMP-Prozess keine hohe Auslastung verursacht.
- SNMP-Konfiguration: Überprüfen Sie die aktuellen SNMP-Konfigurationseinstellungen, einschließlich Community-Strings, Version (v2c oder v3) und Zugriffslisten.
- SNMP Best Practice: Verwenden Sie das Dokument mit den Best Practices für den 9800 WLC, und ordnen Sie die vorgeschlagene Konfiguration für SNMP so genau wie möglich zu.
C9800(config)#snmp-server subagent cache
C9800(config)#snmp-server subagent cache timeout ?
<1-100> cache timeout interval (default 60 seconds)
- Häufigkeit des SNMP Polling: Bestimmen Sie, wie oft der WLC von SNMP-Abfragen abgefragt wird, da eine hohe Frequenz zu einer höheren CPU-Last beitragen kann.
- Netzwerktopologie und SNMP-Manager: Verstehen der Netzwerkeinrichtung und Identifizieren aller SNMP-Manager, die mit dem WLC interagieren.
- Systemverfügbarkeit: Überprüfen Sie die seit dem letzten Neustart verstrichene Zeit, um festzustellen, ob ein Zusammenhang zwischen der Verfügbarkeit und der CPU-Auslastung besteht.
- Zuletzt durchgeführte Änderungen: Notieren Sie alle aktuellen Änderungen an der WLC-Konfiguration oder am Netzwerk, die mit dem Beginn einer hohen CPU-Auslastung einhergehen können.
- Bei 9800 WLC liegt der Fokus auf Telemetrie. Die Telemetrie funktioniert in einem "Push"-Modell, bei dem der WLC relevante Informationen an den Server sendet, ohne dass eine Abfrage erforderlich ist. Wenn Ihre SNMP-Abfragen WLC-CPU-Zyklen beanspruchen und Betriebsprobleme verursachen, ist es besser, zu Telemetrie zu wechseln.
Schlussfolgerung
Durch eine methodische Analyse der CPU-Nutzungsdaten und deren Korrelation mit SNMP-Polling-Aktivitäten können Sie Probleme mit der CPU-Nutzung, die durch SNMP-Prozesse auf dem Cisco 9800 WLC verursacht werden, beheben und beheben. Die Überwachung nach der Implementierung ist wichtig, um den Erfolg der Fehlerbehebung zu bestätigen und eine optimale Netzwerkleistung sicherzustellen.
Zugehörige Informationen
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
29-Jul-2024 |
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)