Table des matières

Introduction

Composants utilisés

Collecte des journaux

Analyse des journaux

Configuration de la vue SNMP

Conseil de dépannage

Conclusion

Informations connexes

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.

1. Réduisez la fréquence d'interrogation sur le serveur SNMP.

2. 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.

3. 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

- Surveillance du WLC Catalyst 9800 via SNMP avec OID

- Gestion des contrôleurs sans fil Catalyst 9800 avec Prime Infrastructure avec SNMP V2 et V3 et NetCONF

- Sécurisez votre protocole de gestion de réseau simple

- Meilleures pratiques de configuration de la gamme Cisco Catalyst 9800