Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

SNMP und Telemetrie

SNMP auf WLC konfigurieren

Über Webschnittstelle

Über die Befehlszeile

Objektnamen und Objekt-IDs (OIDs)

Was sind Objektnamen und OIDs?

MIBs und Liste aller Objektnamen und -IDs auf Cisco WLCs

OIDs zur Überwachung des WLC-Status verwenden

Überwachung über SNMPwalk

Überwachung über Python3 und die Pysnmp-Bibliothek

Integration mit Drittanbietersoftware (Grafana+Prometheus/PRTG Network Monitor/SolarWinds)

Integration in CUCM

Tabelle der am häufigsten überwachten OIDs

Überwachen des Standby-WLC in der HA

Direkte Überwachung des Standby-WLC

Überwachen des Standby-WLC über aktiven WLC

Einleitung

In diesem Dokument wird die Konfiguration des Simple Network Management Protocol (SNMP) zur Überwachung des Cisco 9800 Wireless LAN Controllers (WLC) beschrieben.

Voraussetzungen

Anforderungen

- Grundkenntnisse des 9800 WLC und des SNMP-Protokolls

- SNMP-Server/-Tool

Verwendete Komponenten

Alle Tests wurden unter MacOS 10.14 und einem 9800-CL WLC mit Image-Version 17.5.1 durchgeführt. Einige der in diesem Artikel erwähnten OIDs existieren nicht für ältere Bildversionen.

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

SNMP und Telemetrie

Ältere AireOS-WLCs verwenden SNMP als Hauptprotokoll für den Monitor. Der Großteil der relevanten Informationen wie Client-Anzahl, Anzahl der verbundenen Access Points, Prozessor- und Speichernutzung kann über SNMP-Abfragen vom überwachenden Tool an den WLC abgerufen werden.

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. Der Catalyst 9800 bietet weiterhin SNMP für Legacy-Zwecke. Einige Informationen können ausschließlich für die Telemetrie verwendet werden, und einige der zuvor bei AireOS verfügbaren OIDs sind für den 9800 noch nicht verfügbar.

SNMP auf WLC konfigurieren

Ab Cisco IOS XE Bengaluru 17.6.1 wird der Ethernet Service Port (Management Interface VRF/GigabitEthernet 0) vom Cisco Catalyst Wireless Controller der Serie 9800 unterstützt.

Vor dieser Version konnte der Catalyst 9800 WLC nur mit SNMP über seine Wireless-Management-Schnittstelle oder über eine Redundanz-Management-Schnittstelle überwacht werden (bei einem Standby-WLC im HA-Cluster auf Version 17.5.1 und höher).

Über Webschnittstelle

SNMPv2c ist eine auf der Community basierende Version von SNMP, und die gesamte Kommunikation zwischen den Geräten erfolgt in Klartext. SNMPv3 ist die sicherste Version, die Integritätsprüfungen, Authentifizierung und Verschlüsselung von Paketen ermöglicht. SNMPv1 ist extrem veraltet, existiert aber weiterhin, um die Kompatibilität älterer Software zu gewährleisten. Es wird in diesem Artikel nicht erwähnt.

Wichtig: SNMPv2c ist standardmäßig aktiviert, mit Community "private" mit Lese- und Schreibberechtigungen und Community "public" mit schreibgeschützten Berechtigungen. Es wird empfohlen, diese zu entfernen und eine neue Community mit einem anderen Namen zu erstellen.

Melden Sie sich bei der Webschnittstelle des 9800 WLC an. Stellen Sie unter Administration > Management > SNMP sicher, dass SNMP global aktiviert ist. Unter Community Strings werden alle aktuell konfigurierten Communities und ihre Berechtigungsstufe angezeigt:

Bevor ein SNMP V3-Benutzer erstellt wird, muss eine SNMP V3-Gruppe definiert werden. Um eine Gruppe von Benutzern mit Lese- und Schreibberechtigung zu erstellen, setzen Sie die Lese- und Schreibansicht auf v1default. Die schreibgeschützte Gruppe muss über eine leere Schreibansicht verfügen.

Auf der Registerkarte "SNMP V3-Benutzer" werden alle konfigurierten Benutzer sowie deren Berechtigungen und Protokolle angezeigt, die für die Authentifizierung und Verschlüsselung verwendet werden. Schaltfläche Neu ermöglicht die Erstellung eines neuen Benutzers.

Es stehen drei Sicherheitsmodi zur Verfügung:

1. AuthPriv = Nachrichten werden authentifiziert und verschlüsselt

2. AuthNoPriv = Nachrichten werden authentifiziert, aber nicht verschlüsselt

3. NoAuthNoPriv = Keine Sicherheit auf Nachrichten angewendet

Wählen Sie SHA als Authentifizierungsprotokoll und mindestens AES-128 als Datenschutzprotokoll aus.

Über die Befehlszeile

SNMP kann auch über die Befehlszeilenschnittstelle (Command Line Interface, CLI) konfiguriert werden. CLI bietet zusätzliche Konfigurationsparameter wie die Möglichkeit, einer v2-Community oder einem v3-Benutzer eine Zugriffsliste zuzuweisen.

Beispiel für eine Konfiguration der v2-Community mit Lese- und Schreibzugriff, der v3-Gruppe mit Lese- und Schreibzugriff und des v3-Benutzers, der zu dieser Gruppe gehört:

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

Beispiel einer Zugriffsliste, die nur zulässt, dass das Gerät mit der IP-Adresse 192.168.10.10 die WLC v2-Community mit dem Namen "ReadWriteCommunity" abfragt:

ip access-list standard 50

10 permit 192.168.10.10

20 deny   any

snmp-server manager

snmp-server community ReadWriteCommunity RW 50

Anmerkung: Zum Zeitpunkt der Erstellung dieses Dokuments werden nur Standardzugriffskontrolllisten unterstützt. Erweiterte ACLs können zugewiesen werden, funktionieren aber nicht.

Objektnamen und Objekt-IDs (OIDs)

Was sind Objektnamen und OIDs?

Objekt-IDs, kurz OIDs, sind eindeutige Bezeichner, die eine bestimmte Variable oder ein bestimmtes Objekt darstellen. Beispielsweise wird die aktuelle Prozessornutzung als variabel betrachtet, welche Werte mit dem Aufruf nach ihrer Objekt-ID abgerufen werden können. Jede OID ist eindeutig, und keine zwei kann weltweit gleich sein, ganz ähnlich wie eine MAC-Adresse.

Diese Bezeichner folgen einer Baumhierarchie, und jede OID kann bis zu ihrem Ursprung zurückverfolgt werden. Jeder Anbieter hat seine eigene Zweigstelle mit einem gemeinsamen Stamm.

Eine Analogie könnte eine Privatadresse sein, deren Ursprung das Land oder der Staat wäre, gefolgt von einer Postleitzahl, der Straße und schließlich der Hausnummer.

Die Zahlen, gefolgt von einem Punkt, stellen jeden Schritt dar, der erforderlich ist, um zu einem bestimmten Punkt in diesem Baum oder Zweig zu gelangen.

Alle diese Werte werden in einer Management Information Base, kurz MIB, in jedem Netzwerkgerät gespeichert. Jeder Bezeichner hat einen Namen und eine Definition (Wertebereich, Typ...).

Das Laden einer MIB auf das SNMP-Überwachungstool ist für die Verwendung von SNMP und die Abfrage eines Geräts nicht erforderlich.

Solange eine gültige OID bekannt ist, antwortet das Gerät mit dem Wert, der in der Variablen gespeichert ist, die die OID darstellt. Wenn Sie die MIB jedoch in das Abfrage-Tool laden, bietet dies den Vorteil, dass die Objektnamen in ihre IDs übersetzt werden und ihre Beschreibung bekannt ist.

In diesem Beispiel fragt das SNMP-Tool den SNMP-Agenten eines Geräts unter Verwendung der OID 1.3.6.1.2.1.1.1.0 nach seiner Systembeschreibung ab.

MIBs und Liste aller Objektnamen und -IDs auf Cisco WLCs

Cisco bietet Management Information Base (MIBs) für 9800 WLCs. Es ist nicht leicht lesbar, aber die MIB enthält alle verfügbaren Objektnamen und deren Beschreibung.

Alle 9800-Modelle (9800-80, 9800-40, 9800-L, 9800-CL, EWC) verwenden dieselbe MIB, die Sie hier herunterladen können: https://software.cisco.com/download/home/286322605/type/280775088/release/.

Das aktuellste ist das Datum mit dem neuesten Datum, nicht das mit dem höheren Code-Versionsnamen.

Die heruntergeladene Archivdatei enthält mehrere .my-Textdateien, die entweder in einen SNMP-Server eines Drittanbieters importiert oder einfach mit einem Texteditor geöffnet werden können. Um die OID eines bestimmten Objektnamens zu finden, müssen Sie zunächst die genaue Datei suchen, die ihn enthält.

Beispielsweise befinden sich alle Objekte, die mit der Überwachung des physischen Gerätestatus zusammenhängen (wie CPU und Speicher) innerhalb einer MIB namens CISCO-PROCESS-MIB.my.

Hier ist "cpmCPUMemoryUsed" der Objektname, der verwendet wird, um die vom WLC verwendete Speichermenge in Byte bereitzustellen. MIB-Dateien folgen alle einer ähnlichen Syntax. Die Informationen über das verwendete Speicherobjekt sehen wie folgt aus:

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 }

Der Großteil der zu überwachenden Drittanbietersoftware basiert auf OIDs und nicht auf Objektnamen. Die Umwandlung zwischen Objektname und Objekt-ID kann mithilfe des Cisco SNMP-Objektnavigationstools erfolgen.

Geben Sie den Objektnamen in die Suchleiste ein. Die Ausgabe enthält die OID und eine kurze Beschreibung. Darüber hinaus kann dasselbe Tool verwendet werden, um den Objektnamen der bereitgestellten OID zu finden.

OIDs zur Überwachung des WLC-Status verwenden

Nach der Erfassung der OID des zu überwachenden Objekts kann die erste SNMP-Abfrage ausgeführt werden.

In diesem Kapitel wird beschrieben, wie Sie einen WLC-freien Speicher (OID = 1.3.6.1.4.1.9.9.48.1.1.1.5) für die private SNMPv2-Community und SNMPv3-Benutzersnmpadmin mit dem SHA-Auth-Kennwort Cisco123# und dem AES-Datenschutzkennwort Cisco123 erwerben. Nr. Die Schnittstelle für das Controller-Management befindet sich unter 10.48.39.133.

Überwachung über SNMPwalk

SNMPwalk ist eine SNMP-Anwendung, die SNMP GETNEXT-Anforderungen verwendet, um eine Netzwerkentität nach einem Informationsbaum abzufragen. Es ist standardmäßig auf MacOS und den meisten Linux-Distributionen vorhanden. Für SNMPv2c folgt der Befehl der folgenden Syntax:

snmpwalk -v2c -c

Beispiel:

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

Wenn SNMPv3 verwendet wird, folgt der Befehl der folgenden Syntax:

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

Wählen Sie je nach Erstellung des SNMPv3-Benutzers auf dem Controller MD5/SHA und AES/DES aus.

Beispiel:

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

Überwachung über Python3 und die Pysnmp-Bibliothek

Codeausschnitte werden für Python 3.9 geschrieben und verwenden das pysnmp-Modul (pip install pysnmp), um SNMP-Abfragen für die Speichernutzung des Catalyst 9800-CL WLC durchzuführen. In diesen Beispielen wird die gleiche SNMPv2-Community und der gleiche SNMPv3-Benutzer verwendet, die in einem der vorherigen Kapitel erstellt wurden. Ersetzen Sie einfach die Variablenwerte und integrieren Sie den Code in Ihre eigenen Skripte.

SNMPv2-Beispiel:

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

Ausgabe druckt aus:

SNMPv2-SMI::enterprises.9.9.109.1.1.1.1.12.2 = 3783236

SNMPv3-Beispiel:

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

Integration mit Drittanbietersoftware (Grafana+Prometheus/PRTG Network Monitor/SolarWinds)

Die Cisco Prime-Infrastruktur ermöglicht die einfache Überwachung und Konfiguration mehrerer Netzwerkgeräte, darunter Wireless Controller.

In der Prime-Infrastruktur sind alle OIDs vorinstalliert. Die Integration mit dem WLC erfolgt einfach durch Hinzufügen der WLC-Anmeldeinformationen zu Prime. Bei 9800 WLCs verwendet Prime hauptsächlich Telemetrie, um den Großteil der Details vom WLC zu erfassen, während der kleine Teil der Informationen über SNMP abgerufen wird.

Andererseits kann der Cisco WLC auch in mehrere Überwachungslösungen von Drittanbietern integriert werden, sofern die OIDs bekannt sind.

Programme wie Grafana+Prometheus, PRTG Network Monitor und SolarWinds Server ermöglichen den Import der MIBs oder OIDs und die Darstellung der Werte in einem benutzerfreundlichen Diagramm.

Diese Integration kann einige Anpassungen auf SNMP-Serverseite erfordern. In diesem Beispiel wird der PRTG-Überwachungsserver mit der Pro-Core-CPU-Nutzungs-OID versehen, die die Zeichenfolge "0%/1%, 1%/1%, 0%/1%, 0%/1%" zurückgibt. PRTG erwartet einen Integerwert und löst einen Fehler aus.

Integration in CUCM

Cisco Unified Communications Manager (CUCM) verfügt über eine Funktion zur Wireless-Endpunktverfolgung, mit der der Client-Standort basierend auf dem AP, mit dem er verbunden ist, näherungsweise nachverfolgt werden kann. Damit diese Funktion funktioniert, muss der CUCM Informationen über SNMP-Abfragen vom WLC abrufen.

Wichtig: Viele CUCM-Versionen sind von der Cisco Bug-ID CSCv07486 betroffen - Access Points in WLC können aufgrund zu großer SNMP-Anforderungen nicht synchronisiert werden. Dieses Problem wird in Situationen ausgelöst, in denen der CUCM eine betroffene Version ausführt und der WLC über mehr als 10 Access Points verfügt. Aufgrund der falschen Art und Weise, wie CUCM große Mengen von OIDs in einer einzelnen Sammelanfrage abfragt, weigert sich der WLC entweder, die Anfrage zu beantworten, oder antwortet mit einer zu großen Antwort. Die tooBig-Antwort wird nicht immer sofort versendet und kann verzögert werden. SNMP-Debugging auf WLC-Druck "SNMP: Paket empfangen über UDP von x.x.x.x auf VlanXXSrParseV1SnmpMessage: Packlet is too large SrDoSnmp: ASN Parse Error".

Tabelle der am häufigsten überwachten OIDs

Die Tabelle enthält einige der gebräuchlichsten Objektnamen und ihre OIDs, wobei berücksichtigt wird, dass MIBs die Daten in einer nicht benutzerfreundlichen Syntax darstellen:

Anmerkung: Befehl "show snmp mib | in <Objektname>" kann verwendet werden, um zu überprüfen, ob ein bestimmter Objektname auf dem 9800 WLC verfügbar ist.

Beschreibung

Objektname

OID

Erwartete Antwort

Gesamte CPU-Auslastung in % in den letzten 5 Sekunden

cpmCPUTotal5sec

1.3.6.1.4.1.9.9.109.1.1.1.1.3

GANZZAHL: 5

Gesamte CPU-Auslastung in % in den letzten 1 min

cpmCPUTotal1min

1.3.6.1.4.1.9.9.109.1.1.1.1.4

GANZZAHL: 5

Gesamte CPU-Auslastung in % in den letzten 5 Min.

cpmCPUTotal5min

1.3.6.1.4.1.9.9.109.1.1.1.1.5

GANZZAHL: 5

Aktuell verwendeter Speicher in Byte

cpmCPUMemoryVerwendet

1.3.6.1.4.1.9.9.109.1.1.1.1.12

GANZZAHL: 3783236

Aktuell freier Speicher in Byte

cpmCPUMemoryFree

1.3.6.1.4.1.9.9.109.1.1.1.1.13

GANZZAHL: 4263578

Geringster freier Speicher seit dem letzten Start in Byte

cpmCPUMemoryNiedrigste

1.3.6.1.4.1.9.9.109.1.1.1.1.15

GANZZAHL: 4251212

Letzter Grund für Neuladen

WarumNeu laden

1.3.6.1.4.1.9.2.1.2

STRING: "reload"

Software-Image aller verbundenen APs

bsnAPSoftwareVersion

1.3.6.1.4.1.14179.2.2.1.1.8

STRING: "17.5.1.12"

Modellnummer aller verbundenen APs

bsnAPModel

1.3.6.1.4.1.14179.2.2.1.1.16

ZEICHENFOLGE: "AIR-AP1840I-E-K9"

Anzahl der Clients

X

X

X

Anzahl der verbundenen APs

X

X

X

Netzteil - Status

X

X

X

Lüfterstatus

X

X

X

Derzeit gibt es offene Erweiterungsanfragen zur Unterstützung von OIDs der Gesamtanzahl von Clients und der Anzahl verbundener Access Points:

Cisco Bug-ID CSCvu26309 - SNMP OID für Client-Anzahl auf 9800 nicht vorhanden

Cisco Bug-ID CSCv4430 - SNMP OID für AP nicht vorhanden auf 9800

Der Status der Stromversorgungseinheit (PSU) und des Lüfters werden zum Zeitpunkt der Verfassung dieses Artikels nicht unterstützt. Der Erweiterungsantrag wurde geöffnet:

Cisco Bug-ID CSCwa23598 - 9800 WLC Enhancement/Support für PSU und Fan State SNMP OID (1.3.6.1.4.1.9.9.13)

Überwachen des Standby-WLC in der HA

Die Überwachung eines Standby-WLC im Hochverfügbarkeits-Cluster ist erst ab Version 17.5.1 möglich. Der Standby-WLC kann entweder direkt über RMI oder mit der Abfrage des aktiven WLC überwacht werden.

Direkte Überwachung des Standby-WLC

Der Standby-WLC kann nur dann direkt überwacht werden, wenn die WLCs vom Typ RMI + RP HA ausgeführt werden. Dies erfolgt über die Standby Redundancy Management Interface (RMI)-IP-Adresse des Standby-WLC.

In diesem Szenario werden nur OIDs von IF-MIB offiziell unterstützt, wodurch nur der Status aller Schnittstellen auf dem Standby-WLC überwacht werden kann. Beispielausgabe von 9800-CL WLC:

Beschreibung

Objektname

OID

Erwartete Antwort

Schnittstellenname

ifDescr

1.3.6.1.2.1.2.2.1.2

SNMPv2-SMI::mib-2.2.2.1.2.1 = GigabitEthernet1

SNMPv2-SMI::mib-2.2.2.1.2.2 = GigabitEthernet2

SNMPv2-SMI::mib-2.2.2.1.2.3 = GigabitEthernet3

SNMPv2-SMI::mib-2.2.2.1.2.4 = VoIP-Null0

SNMPv2-SMI::mib-2.2.2.1.2.5 = Null0

SNMPv2-SMI::mib-2.2.2.1.2.6 = VLAN1

SNMPv2-SMI::mib-2.2.2.1.2.7 = Vlan39

Schnittstellenbetriebszustand (1 = aktiv, 2 = inaktiv)

ifOperStatus

1.3.6.1.2.1.2.2.1.8

SNMPv2-SMI::mib-2.2.2.1.8.1 = 2

SNMPv2-SMI::mib-2.2.2.1.8.2 = 2

SNMPv2-SMI::mib-2.2.2.1.8.3 = 1

SNMPv2-SMI::mib-2.2.2.1.8.4 = 2

SNMPv2-SMI::mib-2.2.2.1.8.5 = 2

SNMPv2-SMI::mib-2.2.2.1.8.6 = 1

Hinweis: Es wird erwartet, dass sich der Standby-WLC-Gig-2-Port (der Trunk-Port, der für das Switching von Datenverkehr verwendet wird) im deaktivierten Zustand befindet. Sobald ein Failover auftritt, wird der Gig 2-Port am Standby-WLC aktiviert. Ähnliches gilt für 10GbE-Ports bei 9800 physischen Appliances (9800-80, 9800-40 und 9800-CL).

Überwachen des Standby-WLC über aktiven WLC

Der Standby-WLC-Zustand kann auch mit der Abfrage an den aktiven WLC überwacht werden. Nur CISCO-LWAPP-HA-MIB und CISCO-PROCESS-MIB MIBs werden offiziell unterstützt. Wenn ein aktiver WLC in HA abgefragt wird, stellt die erste Antwort den Wert des aktiven WLC dar, während die zweite Antwort den Wert des Standby-WLC darstellt.

Beschreibung

Objektname

OID

Erwartete Antwort

Gesamte CPU-Auslastung in % in den letzten 5 Sekunden

cpmCPUTotal5sec

1.3.6.1.4.1.9.9.109.1.1.1.1.3

SNMPv2-SMI::Unternehmen.9.9.109.1.1.1.1.3.5 = 3

SNMPv2-SMI::Unternehmen.9.9.109.1.1.1.1.3.6 = 7

Gesamte CPU-Auslastung in % in den letzten 1 min

cpmCPUTotal1min

1.3.6.1.4.1.9.9.109.1.1.1.1.4

SNMPv2-SMI::Unternehmen.9.9.109.1.1.1.1.4.5 = 8

SNMPv2-SMI::Unternehmen.9.9.109.1.1.1.1.4.6 = 6

Gesamte CPU-Auslastung in % in den letzten 5 Min.

cpmCPUTotal5min

1.3.6.1.4.1.9.9.109.1.1.1.1.5

SNMPv2-SMI::enterprise.9.9.109.1.1.1.1.5.5 = 10

SNMPv2-SMI::enterprise.9.9.109.1.1.1.1.5.6 = 15

Aktuell verwendeter Speicher in Byte

cpmCPUMemoryVerwendet

1.3.6.1.4.1.9.9.109.1.1.1.1.12

SNMPv2-SMI::enterprise.9.9.109.1.1.1.1.12.5 = 4318980

SNMPv2-SMI::enterprise.9.9.109.1.1.1.1.12.6 = 3950332

Aktuell freier Speicher in Byte

cpmCPUMemoryFree

1.3.6.1.4.1.9.9.109.1.1.1.1.13

SNMPv2-SMI::enterprise.9.9.109.1.1.1.1.12.5 = 4318739

SNMPv2-SMI::enterprise.9.9.109.1.1.1.1.12.6 = 3950738

Geringster freier Speicher seit dem letzten Start in Byte

cpmCPUMemoryNiedrigste

1.3.6.1.4.1.9.9.109.1.1.1.1.15

SNMPv2-SMI::enterprise.9.9.109.1.1.1.1.15.5 = 3763868

SNMPv2-SMI::enterprise.9.9.109.1.1.1.1.15.6 = 4132588

Status des Standby-WLC (1 = aktiv, 0 = inaktiv)

cLHaPeerHotStandbyEreignis

1.3.6.1.4.1.9.9.843.1.3.4

SNMPv2-SMI::Unternehmen.9.9.843.1.3.4.0 = 1