Monitoraggio di Catalyst 9800 WLC tramite SNMP con OID

Introduzione

Questo documento descrive come configurare Simple Network Management Protocol (SNMP) per monitorare Cisco 9800 Wireless LAN Controller (WLC).

Prerequisiti

Requisiti

• Conoscenze base del protocollo 9800 WLC e SNMP
• Server/strumento SNMP

Componenti usati

Tutti i test sono stati eseguiti su MacOS 10.14 e su un WLC 9800-CL con immagine versione 17.5.1. Alcuni degli OID menzionati in questo articolo non esistono nelle versioni precedenti delle immagini.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Confronto tra SNMP e telemetria

I precedenti WLC di AireOS si basano sul protocollo SNMP come protocollo principale per il monitoraggio. La maggior parte delle informazioni importanti, come il numero di client, il numero di access point uniti, l'utilizzo di processore e memoria, possono essere ottenute tramite query SNMP dallo strumento di monitoraggio al WLC.

Con 9800 WLC, l'attenzione è stata posta sulla telemetria. La telemetria funziona in un modello "push" in cui il WLC invia informazioni rilevanti al server senza che sia necessario interrogarlo. Catalyst 9800 offre ancora il protocollo SNMP per scopi legacy. Alcune informazioni possono essere esclusive per la telemetria e alcuni OID precedentemente disponibili su AireOS non sono ancora disponibili su 9800.

Configurazione di SNMP su WLC

Da Cisco IOS XE Bengaluru 17.6.1, la porta servizio Ethernet (interfaccia di gestione VRF/Gigabit Ethernet 0) è supportata nei controller wireless Cisco Catalyst serie 9800.
Prima di questa release, il WLC di Catalyst 9800 poteva essere monitorato solo con il protocollo SNMP tramite l'interfaccia di gestione wireless o tramite l'interfaccia di gestione della ridondanza (nel caso di un WLC in standby in un cluster HA della versione 17.5.1 e successive). 

Tramite interfaccia Web

SNMPv2c è una versione basata sulla community del protocollo SNMP e tutte le comunicazioni tra i dispositivi sono in formato testo non crittografato. SNMPv3 è la versione più sicura che offre il controllo dell'integrità dei messaggi, l'autenticazione e la crittografia dei pacchetti. L'SNMPv1 è obsoleto, ma esiste ancora per garantire la compatibilità con il software legacy. Non è menzionato in questo articolo.

Importante: SNMPv2c è abilitato per impostazione predefinita con la community "private" con privilegi di lettura e scrittura e la community "public" con privilegi di sola lettura. Si consiglia di rimuoverli e creare una nuova community con un nome diverso.

Accedere all'interfaccia Web del WLC 9800. In Amministrazione > Gestione > SNMP verificare che SNMP sia abilitato a livello globale. In Stringhe della community vengono visualizzate tutte le community configurate e il relativo livello di autorizzazione:

Prima di creare un utente SNMP V3, è necessario definire un gruppo SNMP V3. Per creare un gruppo di utenti con l'autorizzazione di lettura e scrittura, impostare Visualizzazione lettura e Visualizzazione scrittura su v1 predefinito. Il gruppo di sola lettura deve avere la visualizzazione in scrittura vuota

Nella scheda Utenti SNMP V3, è possibile visualizzare tutti gli utenti configurati, i relativi privilegi e protocolli utilizzati per l'autenticazione e la crittografia. Pulsante Nuovo consente di creare un nuovo utente.

Sono disponibili 3 modalità di protezione:

1. AuthPriv = I messaggi vengono autenticati e crittografati
2. AuthNoPriv = I messaggi sono autenticati ma non crittografati
3. NoAuthNoPriv = Nessuna protezione applicata ai messaggi

Selezionare SHA come protocollo di autenticazione e almeno AES-128 come protocollo di privacy.

Tramite riga di comando

Il protocollo SNMP può essere configurato anche tramite l'interfaccia della riga di comando (CLI). CLI offre parametri di configurazione aggiuntivi, ad esempio la possibilità di assegnare un elenco degli accessi alla community v2 o all'utente v3.

Configurazione di esempio della community di lettura/scrittura v2, del gruppo di lettura/scrittura v3 e dell'utente v3 appartenente a questo gruppo:

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 

Esempio di elenco degli accessi che consente solo al dispositivo sull'indirizzo IP 192.168.10.10 di eseguire una query sulla community WLC v2 denominata "ReadWriteCommunity":

ip access-list standard 50
 10 permit 192.168.10.10
 20 deny   any
snmp-server manager
snmp-server community ReadWriteCommunity RW 50

Nota: Al momento della scrittura del documento, sono supportati solo gli ACL standard. È possibile assegnare gli ACL estesi, ma non funzionano.

Nomi di oggetti e ID di oggetti (OID)

Che cosa sono i nomi degli oggetti e gli OID?

Gli ID oggetto, o OID brevi, sono identificatori univoci che rappresentano una determinata variabile o oggetto. Ad esempio, l'utilizzo corrente del processore è considerato una variabile i cui valori possono essere recuperati con la chiamata al relativo ID oggetto. Ogni OID è univoco e non può essere lo stesso in tutto il mondo, analogamente a un indirizzo MAC.

Questi identificatori seguono una gerarchia ad albero e ogni OID può essere rintracciato fino alla relativa radice. Ogni fornitore ha una propria filiale con una radice comune.
Un'analogia potrebbe essere l'indirizzo di un'abitazione, dove la radice potrebbe essere il paese o lo stato, seguito da un CAP della città, la strada e infine il numero dell'abitazione. 

I numeri seguiti da un punto rappresentano ogni passaggio necessario per raggiungere un determinato punto nell'albero o nel ramo. 

Tutti questi valori vengono memorizzati in un Management Information Base (MIB), o abbreviato, in ciascun dispositivo di rete. Ogni identificatore ha un nome e una definizione (intervallo di valori possibili, tipo...).

Non è necessario caricare un MIB sullo strumento di monitoraggio SNMP per utilizzare il protocollo SNMP ed eseguire query su un dispositivo.

Se è noto un OID valido, il dispositivo risponde con il valore archiviato nella variabile rappresentata dall'OID. Tuttavia, se caricate il file MIB sullo strumento di query, questo offre il vantaggio di tradurre i nomi degli oggetti nei relativi ID e consente di conoscerne la descrizione.

In questo esempio, lo strumento SNMP esegue una query sull'agente SNMP di un dispositivo per ottenere la descrizione del sistema con l'utilizzo di OID 1.3.6.1.2.1.1.1.0.

MIB ed elenco di tutti i nomi di oggetto e gli ID sui WLC Cisco

Cisco offre i MIB (Management Information Base) per i WLC 9800. Non è facilmente leggibile, ma il MIB contiene tutti i nomi oggetto disponibili e la relativa descrizione.

Tutti i modelli 9800 (9800-80, 9800-40, 9800-L, 9800-CL, EWC) utilizzano lo stesso MIB scaricabile qui: https://cfnng.cisco.com/mibs

Il più aggiornato è quello con la data più recente, non quello con il nome di versione del codice più alto. 

Il file di archivio scaricato contiene più file di testo My che possono essere importati in qualsiasi server SNMP di terze parti o semplicemente aperti con un editor di testo. Per trovare l'OID di un nome oggetto specifico, è necessario innanzitutto individuare il file esatto che lo contiene.

Ad esempio, tutti gli oggetti correlati al monitoraggio dello stato fisico del dispositivo (come CPU e memoria) si trovano all'interno di un MIB denominato CISCO-PROCESS-MIB.my.

"cpmCPUMemoryUsed" è il nome dell'oggetto utilizzato per fornire la quantità di memoria utilizzata dal WLC in byte. I file MIB seguono tutti una sintassi simile. Le informazioni sull'oggetto di memoria utilizzato sono simili alle seguenti:

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 maggior parte del software di terze parti da monitorare si basa sugli OID e non sui nomi degli oggetti. La conversione tra il nome e l'ID dell'oggetto può essere eseguita con lo strumento di navigazione degli oggetti SNMP di Cisco. 

Immettere il nome dell'oggetto nella barra di ricerca. Nell'output sono disponibili l'OID e una breve descrizione. È inoltre possibile utilizzare lo stesso strumento per trovare il nome dell'OID specificato.

Uso degli OID per monitorare lo stato del WLC

Dopo l'acquisizione dell'OID dell'oggetto da monitorare, è possibile eseguire la prima query SNMP.

Gli esempi di questo capitolo mostrano come acquisire una memoria WLC libera (OID = 1.3.6.1.4.1.9.9.48.1.1.1.5) per la community SNMPv2 private e l'utente SNMPv3 snmpadmin con password SHA Auth Cisco123# e password AES Privacy impostata su Cisco123#. L'interfaccia di gestione del controller si trova sulla versione 10.48.39.133.

Monitoraggio tramite Snmpwalk

Snmpwalk è un'applicazione SNMP che utilizza le richieste GETNEXT di SNMP per eseguire query su un'entità di rete per ottenere una struttura di informazioni. È presente per impostazione predefinita su MacOS e nella maggior parte delle distribuzioni Linux. Per SNMPv2c, il comando segue la sintassi:

snmpwalk -v2c -c   

Esempio:

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

Se si utilizza SNMPv3, il comando segue la sintassi:

snmpwalk -v3 -l authPriv -u <username> -a [MD5|SHA] -A <auth_password> -x [AES|DES] -X <priv_password> <WLC_management_interface_ip> <OID>

Selezionare MD5/SHA e AES/DES in base alla modalità di creazione dell'utente SNMPv3 sul controller.

Esempio:

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

Monitor tramite Python3 e libreria pysnmp

I frammenti di codice vengono scritti per Python 3.9 e utilizzano il modulo pysnmp (pip install pysnmp) per creare query SNMP per l'utilizzo della memoria di Catalyst 9800-CL WLC. In questi esempi viene utilizzata la stessa community SNMPv2 e lo stesso utente SNMPv3 creati in uno dei capitoli precedenti. È sufficiente sostituire i valori delle variabili e integrare il codice negli script personalizzati.

Esempio di 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]))

Uscita delle stampe:

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.12.2 = 3783236

Esempio di 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]))

Integrazione con software di terze parti (Grafana+Prometheus/PRTG Network Monitor/SolarWinds)

Cisco Prime Infrastructure consente di monitorare e configurare facilmente più dispositivi di rete, inclusi i controller wireless.

Prime Infrastructure viene fornito con tutti gli OID e l'integrazione con WLC consiste semplicemente nell'aggiunta delle credenziali WLC a Prime. Con 9800 WLC, Prime si basa principalmente sulla telemetria per raccogliere la maggior parte dei dettagli dal WLC, mentre la piccola parte delle informazioni è ottenuta tramite SNMP.

D'altra parte, Cisco WLC può anche essere integrato con più soluzioni di terze parti per monitor, purché gli OID siano noti.

Programmi come Grafana+Prometheus, PRTG Network Monitor e il server SolarWinds consentono l'importazione dei MIB o degli OID e la visualizzazione dei valori in un grafico di facile utilizzo.

Questa integrazione può richiedere alcune modifiche sul lato server SNMP. In questo esempio, il server di monitoraggio PRTG viene fornito con l'OID di utilizzo della CPU per core che restituisce la stringa "0%/1%, 1%/1%, 0%/1%, 0%/1%". PRTG prevede un valore intero e genera un errore.

Integrazione con CUCM

Cisco Unified Communications Manager (CUCM) dispone di una funzionalità di rilevamento degli endpoint wireless che consente di tenere traccia in modo approssimativo della posizione del client in base all'access point a cui è connesso. Affinché questa funzione funzioni, il CUCM deve estrarre le informazioni dal WLC tramite query SNMP.

Importante: Molte versioni CUCM sono interessate dall'ID bug Cisco CSCv07486 - Impossibile sincronizzare i punti di accesso nel WLC a causa di richieste SNMP troppo grandi. Questo problema si verifica quando CUCM esegue una versione interessata e il WLC dispone di più di 10 access point. A causa del modo errato in cui CUCM interroga una grande quantità di OID in una singola richiesta in blocco, il WLC rifiuta di rispondere o risponde con una risposta troppo grande. La risposta "tooBig" non è sempre inviata immediatamente e può essere posticipata. Debug SNMP sulla stampa WLC "SNMP: Pacchetto ricevuto tramite UDP da x.x.x.x su VlanXSrParseV1SnmpMessaggio: Pacchetto troppo grande SrDoSnmp: Errore di analisi ASN".

Tabella degli OID monitorati più comunemente

La tabella include alcuni dei nomi di oggetto più comuni e i relativi OID, con la considerazione che i MIB presentano i dati in una sintassi non descrittiva:

Nota: Comando "show snmp mib | in <Nome oggetto>" può essere utilizzato per verificare se un determinato nome oggetto è disponibile sul WLC 9800.

Al momento sono presenti richieste di miglioramento aperte per supportare OID del numero totale di client e del numero di punti di accesso collegati:

ID bug Cisco CSCvu26309 - OID SNMP per il numero di client non presente su 9800

Lo stato dell'alimentatore (PSU) e della ventola non sono supportati al momento della scrittura di questo articolo. Richiesta di miglioramento aperta:
Cisco bug ID CSCwa23598 - Miglioramento/supporto WLC 9800 per PSU e Fan State SNMP OID (1.3.6.1.4.1.9.9.13) 

Monitor Standby WLC in HA

Per monitorare un WLC in standby in un cluster ad alta disponibilità è possibile solo dalla release 17.5.1. Il WLC in standby può essere monitorato direttamente tramite RMI o con la query del WLC attivo.

Monitoraggio diretto del WLC in standby

Il WLC in standby può essere monitorato direttamente solo se i WLC vengono eseguiti nel tipo RMI + RP HA. Questa operazione viene eseguita tramite l'indirizzo IP RMI (Redundancy Management Interface) in standby del WLC di standby.

In questo scenario, solo gli OID di IF-MIB sono ufficialmente supportati, il che rende possibile solo monitorare lo stato di tutte le interfacce sul WLC di standby. Esempio di output da 9800-CL WLC:

Nota: La porta WLC Gig 2 in standby (porta trunk utilizzata per la commutazione del traffico) dovrebbe essere nello stato shutdown. Una volta eseguito il failover, viene visualizzata la porta Gig 2 sul WLC in standby. Una situazione simile si verifica con le porte 10 Gigabit sui dispositivi fisici 9800 (9800-80, 9800-40 e 9800-CL).

Monitorare il WLC in standby tramite il WLC attivo

Lo stato WLC in standby può essere monitorato anche con la query sul WLC attivo. Sono ufficialmente supportati solo i MIB CISCO-LWAPP-HA-MIB e CISCO-PROCESS-MIB. Quando si esegue una query sul WLC attivo in HA, la prima risposta rappresenta il valore del WLC attivo, mentre la seconda risposta rappresenta il valore del WLC in standby.