Surveillance du WLC Catalyst 9800 via SNMP avec OID
Table des matières
Introduction
Ce document décrit comment configurer le protocole SNMP (Simple Network Management Protocol) pour surveiller le contrôleur LAN sans fil (WLC) Cisco 9800.
Conditions préalables
Exigences
- Connaissances de base des protocoles WLC et SNMP du 9800
- Serveur/outil SNMP
Composants utilisés
Tous les tests ont été effectués sur MacOS 10.14 et un WLC 9800-CL avec image version 17.5.1. Certains des OID mentionnés dans cet article n'existent pas sur les anciennes versions d'image.
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.
Comparaison SNMP/Télémétrie
Les anciens WLC AireOS utilisent SNMP comme protocole principal pour la surveillance. La majorité des informations pertinentes comme le nombre de clients, le nombre de points d'accès joints, l'utilisation du processeur et de la mémoire peuvent être obtenues via une requête SNMP de l'outil qui surveille, au WLC.
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é. Le Catalyst 9800 offre toujours SNMP pour les applications traditionnelles. Certaines informations peuvent être réservées à la télémétrie et certains des OID précédemment disponibles sur AireOS ne le sont pas encore sur le 9800.
Configurer SNMP sur WLC
À partir de Cisco IOS XE Bangalore 17.6.1, le port de service Ethernet (interface de gestion VRF/GigabitEthernet 0) est pris en charge par le contrôleur sans fil Cisco Catalyst 9800.
Avant cette version, le WLC Catalyst 9800 ne pouvait être surveillé avec SNMP que via son interface de gestion sans fil ou via l'interface de gestion de redondance (dans le cas d'un WLC en veille dans un cluster HA sur les versions 17.5.1 et ultérieures).
Via l'interface Web
SNMPv2c est une version communautaire de SNMP et toutes les communications entre les périphériques sont en texte clair. SNMPv3 est la version la plus sécurisée qui offre des contrôles d'intégrité des messages, l'authentification et le chiffrement des paquets. SNMPv1 est extrêmement obsolète, mais il existe toujours pour assurer la compatibilité des logiciels hérités. Il n'est pas mentionné dans cet article.
Connectez-vous à l'interface Web du WLC 9800. Sous Administration > Management > SNMP, vérifiez que le protocole SNMP est globalement activé. Sous Community Strings, toutes les communautés actuellement configurées et leur niveau d'autorisation s'affichent :
Avant de créer un utilisateur SNMP V3, vous devez définir un groupe SNMP V3. Pour créer un groupe d'utilisateurs avec l'autorisation de lecture et d'écriture, définissez l'affichage de lecture et l'affichage d'écriture sur v1 par défaut. Le groupe Lecture seule doit avoir la vue Écriture vide
Sous l'onglet SNMP V3 Users, vous pouvez voir tous les utilisateurs configurés, leurs privilèges et les protocoles utilisés pour l'authentification et le chiffrement. Le bouton Nouveau permet de créer un nouvel utilisateur.
Trois modes de sécurité sont disponibles :
- AuthPriv = Les messages sont authentifiés et chiffrés
- AuthNoPriv = Les messages sont authentifiés mais pas chiffrés
- NoAuthNoPriv = Aucune sécurité appliquée aux messages
Sélectionnez SHA comme protocole d'authentification et au moins AES-128 comme protocole de confidentialité est recommandé.
Ligne de commande directe
SNMP peut également être configuré via l'interface de ligne de commande (CLI). L'interface de ligne de commande offre des paramètres de configuration supplémentaires, comme la possibilité d'attribuer une liste d'accès à la communauté v2 ou à l'utilisateur v3.
Exemple de configuration de la communauté v2 read+write, du groupe v3 read+write et de l'utilisateur v3 appartenant à ce groupe :
snmp-server manager
snmp-server community
RW
snmp-server community
RO
snmp-server group
v3 auth write v1default snmp-server user
v3 auth sha
priv aes 128
access
Exemple d'une liste d'accès qui permet uniquement au périphérique sur l'adresse IP 192.168.10.10 d'interroger la communauté WLC v2 nommée « ReadWriteCommunity » :
ip access-list standard 50
10 permit 192.168.10.10
20 deny any
snmp-server manager
snmp-server community ReadWriteCommunity RW 50Noms et ID d'objet (OID)
Que sont les noms d'objet et les OID ?
Les ID d'objet, ou OID pour abréger, sont des identificateurs uniques qui représentent une certaine variable ou un certain objet. Par exemple, l'utilisation actuelle du processeur est considérée comme variable, les valeurs pouvant être récupérées avec l'appel sur leur ID d'objet. Chaque OID est unique et aucun ne peut être identique dans le monde entier, tout à fait similaire à une adresse MAC.
Ces identificateurs suivent une hiérarchie arborescente et chaque OID peut être retracé jusqu'à sa racine. Chaque fournisseur possède sa propre branche avec une racine commune.
Une analogie pourrait être une adresse personnelle, où la racine serait le pays ou l'état, suivi par un code postal de la ville, la rue et enfin le numéro de la maison.
Les nombres suivis d'un point représentent chaque étape nécessaire pour atteindre un certain point dans l'arbre ou la branche.
Toutes ces valeurs sont stockées dans une base d'informations de gestion, ou MIB pour abréger, dans chaque périphérique réseau. Chaque identifiant a un nom et une définition (plage de valeurs possibles, type...).
Pour charger une MIB sur votre outil de surveillance SNMP, il n'est pas nécessaire d'utiliser SNMP et d'interroger un périphérique.
Tant qu'un OID valide est connu, le périphérique répond avec la valeur qui est stockée dans la variable que l'OID représente. Cependant, si vous chargez la MIB sur votre outil de requête, il offre l'avantage de traduire les noms d'objet en leurs ID et permet de connaître leur description.
Dans cet exemple, l'outil SNMP interroge l'agent SNMP d'un périphérique pour obtenir la description de son système à l'aide de l'OID 1.3.6.1.2.1.1.1.0.
MIB et liste de tous les noms et ID d'objet sur les WLC Cisco
Cisco propose des bases MIB (Management Information Base) pour 9800 WLC. Il n'est pas facile à lire, mais la MIB contient tous les noms d'objets disponibles et leur description.
Tous les modèles 9800 (9800-80, 9800-40, 9800-L, 9800-CL, EWC) utilisent la même MIB qui peut être téléchargée ici : https://software.cisco.com/download/home/286322605/type/280775088/release/.
La plus à jour est celle avec la date la plus récente, et non celle avec le nom de version de code le plus élevé.
Le fichier d'archive téléchargé contient plusieurs fichiers texte .my qui peuvent être importés dans n'importe quel serveur SNMP tiers ou simplement ouverts avec un éditeur de texte. Afin de trouver l'OID d'un nom d'objet spécifique, vous devez d'abord localiser le fichier exact qui le contient.
Par exemple, tous les objets associés à la surveillance de l'état physique du périphérique (comme le processeur et la mémoire) sont situés à l'intérieur d'une MIB appelée CISCO-PROCESS-MIB.my.
Ici, « cpmCPUMemoryUsed » est le nom d'objet qui est utilisé pour fournir la quantité de mémoire utilisée par le WLC en octets. Les fichiers MIB suivent tous la même syntaxe. Les informations sur l'objet mémoire utilisé sont les suivantes :
cpmCPUMemoryUsed OBJECT-TYPE
SYNTAX Gauge32
UNITS "kilo-bytes"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The overall CPU wide system memory which is currently
under use."
::= { cpmCPUTotalEntry 12 }La plupart des logiciels tiers à surveiller reposent sur des OID et non sur des noms d'objet. La traduction entre le nom et l'ID de l'objet peut être effectuée à l'aide de l'outil de navigation d'objet SNMP de Cisco.
Entrez le nom de l'objet dans la barre de recherche. Le résultat fournit l'OID et une brève description. En outre, le même outil peut être utilisé pour rechercher le nom d'objet de l'OID fourni.
Utiliser des OID pour surveiller l'état du WLC
Après l'acquisition de l'OID de l'objet qui doit être surveillé, la première requête SNMP peut être exécutée.
Les exemples de ce chapitre montrent comment acquérir une mémoire libre WLC (OID = 1.3.6.1.4.1.9.9.48.1.1.1.5) pour SNMPv2 community private et SNMPv3 user snmpadmin avec le mot de passe d'authentification SHA Cisco123# et le mot de passe de confidentialité AES défini sur Cisco123#. L'interface de gestion du contrôleur se trouve sur 10.48.39.133.
Surveillance via Snmpwalk
Snmpwalk est une application SNMP qui utilise des requêtes SNMP GETNEXT pour interroger une entité réseau à la recherche d'une arborescence d'informations. Il est présent par défaut sur MacOS et la plupart des distributions Linux. Pour SNMPv2c, la commande suit la syntaxe :
snmpwalk -v2c -c
Exemple :
VAPEROVI:~ vaperovi$ snmpwalk -v2c -c private 10.48.39.133 1.3.6.1.4.1.9.9.109.1.1.1.1.12
SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.12.2 = 3783236 <-------- Free Memory in Bytes
Si SNMPv3 est utilisé, la commande suit la syntaxe :
snmpwalk -v3 -l authPriv -u <username> -a [MD5|SHA] -A <auth_password> -x [AES|DES] -X <priv_password> <WLC_management_interface_ip> <OID>
Sélectionnez MD5/SHA et AES/DES en fonction de la façon dont vous avez créé l'utilisateur SNMPv3 sur le contrôleur.
Exemple :
VAPEROVI:~ vaperovi$ snmpwalk -v3 -l authPriv -u snmpadmin -a SHA -A Cisco123# -x AES -X Cisco123# 10.48.39.133 1.3.6.1.4.1.9.9.109.1.1.1.1.12
SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.12.2 = 3783236 <-------- Free Memory in Bytes
#snmpwalk output still shows v2 even though v3 is used
Surveillance via Python3 et bibliothèque pysnmp
Les extraits de code sont écrits pour Python 3.9 et utilisent le module pysnmp (pip install pysnmp) pour faire des requêtes SNMP pour l'utilisation de mémoire du WLC Catalyst 9800-CL. Ces exemples utilisent la communauté SNMPv2 et l'utilisateur SNMPv3 créés dans l'un des chapitres précédents. Remplacez simplement les valeurs des variables et intégrez le code dans vos propres scripts personnalisés.
Exemple SNMPv2 :
from pysnmp.hlapi import *
communityName = 'private'
ipAddress = '10.48.39.133'
OID = '1.3.6.1.4.1.9.9.109.1.1.1.1.12'
for (errorIndication,
errorStatus,
errorIndex,
varBinds) in nextCmd(SnmpEngine(),
CommunityData(communityName),
UdpTransportTarget((ipAddress, 161)),
ContextData(),
ObjectType(ObjectIdentity(OID)),
lexicographicMode=False):
if errorIndication:
print(errorIndication)
elif errorStatus:
print('%s at %s' % (errorStatus.prettyPrint(),
errorIndex and varBinds[int(errorIndex) - 1][0] or '?'))
else:
for varBind in varBinds:
print(' = '.join([x.prettyPrint() for x in varBind]))Le résultat est imprimé :
SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.12.2 = 3783236
Exemple SNMPv3 :
from pysnmp.hlapi import *
username = 'snmpadmin'
ipAddress = '10.48.39.133'
OID = '1.3.6.1.4.1.9.9.109.1.1.1.1.12'
authKey = 'Cisco123#'
privKey = 'Cisco123#'
for (errorIndication,
errorStatus,
errorIndex,
varBinds) in nextCmd(SnmpEngine(),
UsmUserData(username, authKey, privKey,
authProtocol=usmHMACSHAAuthProtocol,
privProtocol=usmAesCfb128Protocol),
UdpTransportTarget((ipAddress, 161)),
ContextData(),
ObjectType(ObjectIdentity(OID)),
lexicographicMode=False):
if errorIndication:
print(errorIndication)
elif errorStatus:
print('%s at %s' % (errorStatus.prettyPrint(),
errorIndex and varBinds[int(errorIndex) - 1][0] or '?'))
else:
for varBind in varBinds:
print(' = '.join([x.prettyPrint() for x in varBind]))Intégration avec des logiciels tiers (Grafana+Prometheus/PRTG Network Monitor/SolarWinds)
L'infrastructure Cisco Prime permet de surveiller et de configurer facilement plusieurs périphériques réseau, y compris des contrôleurs sans fil.
Prime Infrastructure est livré préchargé avec tous les OID et l'intégration avec WLC consiste simplement en l'ajout des identifiants WLC à Prime. Avec 9800 WLC, Prime s'appuie principalement sur la télémétrie pour collecter la majorité des détails du WLC, tandis que la petite partie des informations est obtenue via SNMP.
D'autre part, Cisco WLC peut également être intégré à plusieurs solutions tierces pour la surveillance, tant que les OID sont connus.
Des programmes comme Grafana+Prometheus, PRTG Network monitor et SolarWinds server permettent d'importer les MIB ou OID et d'afficher les valeurs dans un graphique convivial.
Cette intégration peut nécessiter quelques modifications côté serveur SNMP. Dans cet exemple, le serveur de surveillance PRTG est fourni avec l'OID d'utilisation de CPU par coeur qui renvoie la chaîne « 0%/1%, 1%/1%, 0%/1%, 0%/1% ». PRTG attend une valeur entière et génère une erreur.
Intégration à CUCM
Cisco Unified Communications Manager (CUCM) dispose d'une fonctionnalité de suivi des terminaux sans fil qui lui permet de suivre approximativement l'emplacement du client en fonction du point d'accès auquel le client est connecté. Pour que cette fonctionnalité fonctionne, le CUCM doit extraire des informations du WLC via des requêtes SNMP.
Tableau des OID les plus fréquemment surveillés
Le tableau inclut certains des noms d'objet les plus courants et leurs OID, en tenant compte du fait que les MIB présentent les données dans une syntaxe non conviviale :
| Description |
Nom d'objet |
OID |
Réponse attendue |
| Utilisation totale de l'UC en % au cours des 5 dernières secondes |
cpmCPUTotal5s |
1.3.6.1.4.1.9.9.109.1.1.1.1.3 |
ENTIER : 5 |
| Utilisation totale de l'UC en % au cours des 1 dernières minutes |
cpmCPUTotal1min |
1.3.6.1.4.1.9.9.109.1.1.1.1.4 |
ENTIER : 5 |
| Utilisation totale de l'UC en % au cours des 5 dernières minutes |
cpmCPUTotal5min |
1.3.6.1.4.1.9.9.109.1.1.1.1.5 |
ENTIER : 5 |
| Mémoire actuelle utilisée en octets |
cpmCPUMemoryUtilisé |
1.3.6.1.4.1.9.9.109.1.1.1.1.12 |
ENTIER : 3783236 |
| Mémoire libre actuelle en octets |
cpmCPUMemoryFree |
1.3.6.1.4.1.9.9.109.1.1.1.1.13 |
ENTIER : 4263578 |
| Quantité de mémoire libre la plus faible depuis le dernier démarrage en octets |
cpmCPUMemoryLowest |
1.3.6.1.4.1.9.9.109.1.1.1.1.15 |
ENTIER : 4251212 |
| Motif du dernier rechargement |
pourquoiRecharger |
1.3.6.1.4.1.9.2.1.2 |
CHAÎNE : "reload" |
| Image logicielle de tous les points d'accès joints |
VersionLogicielleBSNap |
1.3.6.1.4.1.14179.2.2.1.1.8 |
CHAÎNE : "17.5.1.12" |
| Numéro de modèle de tous les points d'accès joints |
bsnAPModel |
1.3.6.1.4.1.14179.2.2.1.1.16 |
CHAÎNE : "AIR-AP1840I-E-K9" |
| Nombre de clients |
X |
X |
X |
| Nombre de points d'accès joints |
X |
X |
X |
| État du bloc d'alimentation |
X |
X |
X |
| État du ventilateur |
X |
X |
X |
Actuellement, des demandes d'amélioration sont ouvertes pour prendre en charge les OID du nombre total de clients et du nombre de points d'accès joints :
ID de bogue Cisco CSCvu26309 - OID SNMP pour le nombre de clients non présent sur le 9800
ID de bogue Cisco CSCv4330 - OID SNMP pour AP absent sur 9800
L'état de l'unité d'alimentation (PSU) et l'état du ventilateur ne sont pas pris en charge au moment de la rédaction de cet article. La demande d'amélioration a été ouverte :
ID de bogue Cisco CSCwa23598 - 9800 Amélioration WLC / Prise en charge de PSU et OID SNMP d'état de ventilateur (1.3.6.1.4.1.9.9.13)
Surveillance du WLC en veille dans HA
La surveillance d'un WLC en veille dans un cluster de haute disponibilité n'est possible qu'à partir de la version 17.5.1. Le WLC en veille peut être surveillé directement via RMI ou avec la requête du WLC actif.
Surveillance directe du WLC en veille
Un WLC de secours peut être surveillé directement uniquement si les WLC qui s'exécutent dans le type RMI + RP HA. Elle est effectuée via l'adresse IP de l'interface de gestion de redondance de secours (RMI) du WLC de secours.
Dans ce scénario, seuls les OID de IF-MIB sont officiellement pris en charge, ce qui permet seulement de surveiller l'état de toutes les interfaces sur le WLC en veille. Exemple de sortie du WLC 9800-CL :
| Description |
Nom d'objet |
OID |
Réponse attendue |
| Nom d'interface |
DescrSi |
1.3.6.1.2.1.2.2.1.2 |
SNMPv2-SMI::mib-2.2.2.1.2.1 = GigabitEthernet1 |
| État opérationnel de l'interface (1=up, 2=down) |
ÉtatOpérateur |
1.3.6.1.2.1.2.2.1.8 |
SNMPv2-SMI::mib-2.2.2.1.8.1 = 2 |
Surveillance du WLC en veille via le WLC actif
L'état du WLC en veille peut également être surveillé avec la requête au WLC actif. Seuls les MIB CISCO-LWAPP-HA-MIB et CISCO-PROCESS-MIB sont officiellement prises en charge. Lorsque le WLC actif dans HA est interrogé, la première réponse représente la valeur du WLC actif, tandis que la seconde réponse représente la valeur du WLC en veille.
| Description |
Nom d'objet |
OID |
Réponse attendue |
| Utilisation totale de l'UC en % au cours des 5 dernières secondes |
cpmCPUTotal5s |
1.3.6.1.4.1.9.9.109.1.1.1.1.3 |
SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.3.5 = 3 |
| Utilisation totale de l'UC en % au cours des 1 dernières minutes |
cpmCPUTotal1min |
1.3.6.1.4.1.9.9.109.1.1.1.1.4 |
SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.4.5 = 8 |
| Utilisation totale de l'UC en % au cours des 5 dernières minutes |
cpmCPUTotal5min |
1.3.6.1.4.1.9.9.109.1.1.1.1.5 |
SNMPv2-SMI::entreprises.9.9.109.1.1.1.1.5.5 = 10 |
| Mémoire actuelle utilisée en octets |
cpmCPUMemoryUtilisé |
1.3.6.1.4.1.9.9.109.1.1.1.1.12 |
SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.12.5 = 4318980 |
| Mémoire libre actuelle en octets |
cpmCPUMemoryFree |
1.3.6.1.4.1.9.9.109.1.1.1.1.13 |
SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.12.5 = 4318739 |
| Quantité de mémoire libre la plus faible depuis le dernier démarrage en octets |
cpmCPUMemoryLowest |
1.3.6.1.4.1.9.9.109.1.1.1.1.15 |
SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.15.5 = 3763868 |
| État du WLC en veille (1=up, 0=down) |
cLHaPeerHotStandbyEvent |
1.3.6.1.4.1.9.9.843.1.3.4 |
SNMPv2-SMI::enterprises.9.9.843.1.3.4.0 = 1 |
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
4.0 |
01-Apr-2022 |
OID supplémentaires mentionnés |
2.0 |
01-Oct-2021 |
Première publication |
1.0 |
12-Oct-2021 |
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)