Dépannage de l'utilisation CPU élevée due au processus SNMP
Introduction
Ce document décrit une approche structurée pour dépanner et résoudre une utilisation CPU élevée au processus SNMP sur un contrôleur LAN sans fil 9800.
Composants utilisés
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- Contrôleur sans fil : C9800-80-K9 fonctionnant sous 17.09.03
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Collecte des journaux
Identification des modèles d'utilisation de l'UC Lors de la réception d'un rapport d'utilisation élevée de l'UC lié au processus SNMP, la première action consiste à collecter des journaux détaillés sur une période spécifiée. Cela va aider à établir un modèle ou une tendance dans l'utilisation du CPU, ce qui est essentiel pour identifier les moments où le processus SNMP est le plus actif et le plus gourmand en ressources.
Avant de commencer la collecte des journaux, il est impératif de recueillir des informations spécifiques utilisées pour prendre en charge la procédure de dépannage. Commencez par recueillir quelques informations sur le problème.
- Le système connaît-il des pics ou une utilisation élevée constante ?
- Quel est le pourcentage d'utilisation dans les deux cas ?
- Quelle est la fréquence d'utilisation élevée du CPU ?
- À quelle fréquence chaque serveur SNMP interroge le WLC ?
- Qui sont les meilleurs parleurs ?
Collectez le résultat de la commande du WLC 9800 à des intervalles de deux minutes sur une période de dix minutes. Ces données peuvent être utilisées pour analyser les problèmes d'utilisation élevée de l'UC, en particulier ceux liés au processus SNMP.
#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
Analyse des journaux
Après avoir collecté ces journaux, vous devez les analyser pour en comprendre l'impact.
Examinons un exemple de journaux d'utilisation du CPU et identifions le processus SNMP qui consomme le plus de CPU.
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
Le résultat de la commande show process cpu trié | La commande exclude 0.0 indique que le processus SNMP consomme en effet une quantité disproportionnée de ressources CPU. Plus précisément, le processus SNMP LA Cache pr est le plus intensif en CPU, suivi par d'autres processus liés à SNMP.
Le prochain jeu de commandes va nous aider à explorer le processus d'utilisation élevée du protocole SNMP.
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
Le résultat de la commande show snmp stats oid révèle la fréquence à laquelle divers OID sont interrogés. Un OID particulier, bsnAPIfDBNoisePower, se distingue par son nombre exceptionnellement élevé de demandes. Cela suggère que l'interrogation agressive de cet OID contribue probablement à l'utilisation élevée du CPU observée sur le WLC.
Essayons de comprendre ce que fait l'OID bsnAPIfDBNoisePower et ses temps de stockage des données.
Accédez à SNMP Object Navigator et recherchez l'OID « bsnAPIfDBNoisePower ».
Résultat de recherche OID
Vous comprenez donc maintenant que l'objet bsnAPIfDBNoisePower signale la puissance de bruit de chaque canal telle qu'elle est signalée par chaque point d'accès. Étant donné le grand nombre de canaux et d'AP gérés par le WLC, les données SNMP générées par cet OID peuvent être importantes. Lorsque le WLC dessert un grand nombre d'AP, le volume de données généré par l'interrogation de cet OID peut être immense. Cela peut conduire à une utilisation CPU élevée pendant que le WLC traite ces requêtes SNMP étendues.
De même, vous devez comprendre le comportement de l'OID spécifique qui est interrogé agressivement.
La commande suivante va vous aider à connaître les serveurs SNMP qui interrogent le WLC.
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
Cette commande fournit une liste des serveurs SNMP avec leur nombre de requêtes et le dernier horodatage de leur activité d'interrogation.
Vous pouvez voir que plusieurs serveurs différents interrogent le WLC 9800. Si vous regardez les données complètes des journaux collectées au cours des 10 dernières minutes, vous pouvez également mesurer leur fréquence d'interrogation.
Vous pouvez maintenant vous rendre sur chaque serveur et voir à quelle fréquence l'OID incriminé est interrogé. Dans cet exemple, l'OID est interrogé toutes les 30 secondes, ce qui est beaucoup plus fréquent que nécessaire. Puisque le WLC reçoit des données RF/RRM toutes les 180 secondes, l'interrogation de l'OID toutes les 30 secondes entraîne un traitement inutile et contribue à une utilisation élevée du CPU.
Une fois que l'OID incriminé et le serveur ont été identifiés, nous pouvons essayer plusieurs solutions différentes pour réduire la charge sur le WLC.
- Réduisez la fréquence d'interrogation sur le serveur SNMP.
- Si l'OID n'est pas nécessaire pour l'utilisation des opérations, désactivez l'interrogation de cet OID à partir du serveur SNMP.
- Si vous ne contrôlez pas le serveur SNMP, vous pouvez utiliser la vue SNMP pour bloquer l'OID incriminé.
Configuration de la vue SNMP
Définissez une nouvelle vue qui exclut l'OID que vous souhaitez bloquer. Par exemple, vous souhaitez bloquer l'OID 1.3.6.1.4.1.14179.2.2.15.1.21, créer une nouvelle vue et attacher l'OID à la vue.
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.Conseil de dépannage
- Utilisation CPU de référence : documentez les niveaux d'utilisation CPU normaux lorsque le processus SNMP n'entraîne pas une utilisation élevée.
- Configuration SNMP : vérifiez les paramètres de configuration SNMP actuels, notamment les chaînes de communauté, la version (v2c ou v3) et les listes d'accès.
- Meilleure pratique SNMP : utilisez le document de meilleures pratiques du WLC 9800 et faites correspondre la configuration suggérée pour SNMP aussi près que possible.
C9800(config)#snmp-server subagent cache
C9800(config)#snmp-server subagent cache timeout ?
<1-100> cache timeout interval (default 60 seconds)
- Fréquence de l'interrogation SNMP : Déterminez la fréquence à laquelle le WLC est interrogé par les requêtes SNMP, car une fréquence élevée peut contribuer à augmenter la charge du CPU.
- Topologie du réseau et gestionnaires SNMP : Comprenez la configuration du réseau et identifiez tous les gestionnaires SNMP qui interagissent avec le WLC.
- System Uptime : vérifiez le temps écoulé depuis le dernier redémarrage pour voir s'il existe une corrélation entre le temps de fonctionnement et l'utilisation du CPU.
- Modifications récentes : Notez toute modification récente de la configuration ou du réseau WLC qui peut avoir coïncidé avec le début d'une utilisation élevée du CPU.
- Avec le WLC 9800, l'accent a été mis sur la télémétrie. La télémétrie fonctionne dans un modèle « push » où le WLC envoie des informations pertinentes au serveur sans avoir besoin d'être interrogé. Si vos requêtes SNMP consomment des cycles CPU WLC et causent des problèmes de fonctionnement, il serait préférable de passer à la télémétrie.
Conclusion
En analysant méthodiquement les données d'utilisation du CPU et en les corrélant avec les activités d'interrogation SNMP, vous pouvez dépanner et résoudre les problèmes d'utilisation élevée du CPU causés par les processus SNMP sur le WLC Cisco 9800. La surveillance post-implémentation est essentielle pour confirmer le succès des efforts de dépannage et pour maintenir des performances réseau optimales.
Informations connexes
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
29-Jul-2024 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)