Inhaltsverzeichnis
Überwachung des Chassis-Zustands via SNMP
In diesem Beitrag geht es darum per SNMP den Chassis-Zustand zu überwachen
Dieser Beitrag wurde auf Basis der folgenden Hardware und AOS-Software erstellt:
OS6850E-> show chassis Chassis 1 Model Name: OS6850E-24X, Description: 24 G 2 10G, Part Number: 902937-90, Hardware Revision: 04, Serial Number: L48xxxxx, Manufacture Date: DEC 04 2010, Admin Status: POWER ON, Operational Status: UP, Number Of Resets: 114 MAC Address: 00:e0:b1:xx:xx:xx, OS6850E-> show microcode Package Release Size Description -----------------+---------------+--------+----------------------------------- Kbase.img 6.4.4.645.R01 18674195 Alcatel-Lucent Base Software Kadvrout.img 6.4.4.645.R01 2882154 Alcatel-Lucent Advanced Routing K2os.img 6.4.4.645.R01 1959309 Alcatel-Lucent OS Keni.img 6.4.4.645.R01 5791055 Alcatel-Lucent NI software Ksecu.img 6.4.4.645.R01 649854 Alcatel-Lucent Security Management Kencrypt.img 6.4.4.645.R01 3437 Alcatel-Lucent Encryption Management
Zu allererst sollte ein Benutzer angelegt werden mit dem SNMP verwendet wird:
OS6850E-> user snmp password snmp12345 no auth read-write all OS6850E-> show user User name = snmp, Password expiration = None, Password allow to be modified date = None, Account lockout = None, Password bad attempts = 0, Read Only for domains = None, Read/Write for domains = All , Snmp allowed = YES, Snmp authentication = NONE, Snmp encryption = NONE, Console-Only = Disabled
In produktiven Netzwerken empfehlen wir den Einsatz von SNMPv3!
Den SNMPv2 Zugriff mit der Community „public“ aktivieren:
OS6850E-> snmp community map public user snmp enable
Die Authentifizierung von Benutzern gegen die lokale Benutzerdatenbank aktivieren:
OS6850E-> aaa authentication default local OS6850E-> show aaa authentication Service type = Default 1rst authentication server = local Service type = Console 1rst authentication server = local Service type = Telnet Authentication = Use Default, 1rst authentication server = local Service type = Ftp Authentication = Use Default, 1rst authentication server = local Service type = Http Authentication = Use Default, 1rst authentication server = local Service type = Snmp Authentication = Use Default, 1rst authentication server = local Service type = Ssh Authentication = Use Default, 1rst authentication server = local
In produktiven Netzwerken empfehlen wir den Einsatz von RADIUS-Authentifizierung.
Da wir den Switch irgendwie erreichen müssen, erstellen wir ein IP-Interface:
OS6850E-> ip interface vlan-1 address 192.168.10.1/24 vlan 1
Ein kurzer Test per snmpwalk zeigt dass SNMP funktioniert und wir die Werte abfragen können:
localhost:~ MichaelS$ snmpwalk -v 2c -c public 192.168.10.1 SNMPv2-MIB::sysDescr.0 = STRING: Alcatel-Lucent OS6850E-24X 6.4.4.645.R01 Service Release, September 24, 2013. SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.6486.800.1.1.2.1.7.1.47 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (174639100) 20 days, 5:06:31.00 SNMPv2-MIB::sysContact.0 = STRING: Alcatel-Lucent, http://alcatel-lucent.com/wps/portal/enterprise SNMPv2-MIB::sysName.0 = STRING: OS6850E-24X SNMPv2-MIB::sysLocation.0 = STRING: Showroom Stuttgart SNMPv2-MIB::sysServices.0 = INTEGER: 78 IF-MIB::ifNumber.0 = INTEGER: 41 IF-MIB::ifIndex.1001 = INTEGER: 1001 ...
Für die Abfrage des Chassis-Zustands müssen wir erst die zugehörige MIB finden.
Temperatur
Im Falle der Chassis-Temperatur finden wir die MIB über den „Alcatel-Lucent OmniSwitch AOS 6.4.4.R01 CLI Reference Guide“ indem wir das zugehörige CLI-Kommando nachschlagen das wir per SNMP ausführen möchten:
show temperature [number] ... MIB Objects chasChassisTable chasHardwareBoardTemp
Über den alcatel.tree welcher im MIB-Archiv zu jedem Release vorhanden ist finden wir leicht die dazugehörige OID:
1.3.6.1.4.1.6486.800.1.1.1.3.1.1.3.1.4 chasHardwareBoardTemp LEAF INTEGER
Diese OID fügen wir dann der SNMP-Abfrage hinzu:
localhost:~ MichaelS$ snmpwalk -v 2c -c public 192.168.10.1 1.3.6.1.4.1.6486.800.1.1.1.3.1.1.3.1.4 SNMPv2-SMI::enterprises.6486.800.1.1.1.3.1.1.3.1.4.569 = INTEGER: 32
Die Abfrage dieser OID funktioniert nur per SNMPWALK, da nach der OID noch die Entity spezifiert ist. Alternativ kann bei einer SNMPGET Abfrage die Entity mit angehängt werken:
localhost:~ MichaelS$ snmpget -v 2c -c public 192.168.10.1 1.3.6.1.4.1.6486.800.1.1.1.3.1.1.3.1.4.569 SNMPv2-SMI::enterprises.6486.800.1.1.1.3.1.1.3.1.4.569 = INTEGER: 32
Dieser Status lässt sich auch über die CLI kontrollieren:
OS6850E-> show temperature Temperature for chassis 1 Hardware Board Temperature (deg C) = 32, Temperature Upper Threshold Range (deg C) = 16 to 74, Temperature Upper Threshold (deg C) = 60, Temperature Status = UNDER THRESHOLD, Temperature Danger Threshold (deg C) = 74
CPU
Auch die zugehörige MIB zur CPU-Auslastung findet sich über oben beschriebenen Weg über den CLI-Guide:
show health [slot/port] [statistics] ... MIB Objects healthModuleTable ... healthModuleCpuLatest
Über den alcatel.tree findet sich auch hier die dazugehörige OID:
1.3.6.1.4.1.6486.800.1.2.1.16.1.1.2.1.1.14 healthModuleCpuLatest LEAF INTEGER
Diese OID fügen wir dann der SNMP-Abfrage hinzu:
localhost:~ MichaelS$ snmpwalk -v 2c -c public 192.168.10.1 1.3.6.1.4.1.6486.800.1.2.1.16.1.1.2.1.1.14 SNMPv2-SMI::enterprises.6486.800.1.2.1.16.1.1.2.1.1.14.1 = INTEGER: 23
Auch hier gilt oben beschriebener Hinweis zu SNMPGET und entsprechender Entity
Dieser Status lässt sich auch über die CLI kontrollieren:
OS6850E-> show health * - current value exceeds threshold Device 1 Min 1 Hr 1 Hr Resources Limit Curr Avg Avg Max -----------------+-------+------+------+-----+---- Receive 80 01 01 01 01 Transmit/Receive 80 01 01 01 01 Memory 80 51 51 51 51 Cpu 80 25 26 21 53
Die aktuelle CPU-Auslastung ändert sich häufiger, daher kann wie oben dargestellt durch die zeitliche Differenz zwischen SNMP- und CLI-Abfrage auch eine Differenz der ausgelesenen Werte auftreten
Netzteile
Bei der Abfrage der Netzteile und deren Status müssen wir über die Entity-MIB die einzelnen Instanzen finden, um deren Status abfragen zu können:
Innerhalb der Entity-MIB gibt es zum einen die PhysicalClass, über welche sich der Typ der Instanz herausgefunden werden kann:
PhysicalClass ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"An enumerated value which provides an indication of the
general hardware type of a particular physical entity.
There are no restrictions as to the number of
entPhysicalEntries of each entPhysicalClass, which must be
instantiated by an agent.
...
SYNTAX INTEGER {
other(1),
unknown(2),
chassis(3),
backplane(4),
container(5), -- e.g., chassis slot or daughter-card holder
powerSupply(6),
fan(7),
sensor(8),
module(9), -- e.g., plug-in card or daughter-card
port(10),
stack(11) -- e.g., stack of multiple chassis entities
}
Über die Suche nach PhysicalClass im alcatel.tree finden wir die passende OID für die Abfrage der Werte:
1.3.6.1.2.1.47.1.1.1.1.5 entPhysicalClass LEAF PhysicalClass
Angewendet durch ein SNMPWALK auf dem OmniSwitch erhalten wir folgendes Ergebnis:
localhost:~ MichaelS$ snmpwalk -v 2c -c public 192.168.10.1 1.3.6.1.2.1.47.1.1.1.1.5 SNMPv2-SMI::mib-2.47.1.1.1.1.5.1 = INTEGER: 9 SNMPv2-SMI::mib-2.47.1.1.1.1.5.65 = INTEGER: 9 SNMPv2-SMI::mib-2.47.1.1.1.1.5.97 = INTEGER: 6 SNMPv2-SMI::mib-2.47.1.1.1.1.5.98 = INTEGER: 6 SNMPv2-SMI::mib-2.47.1.1.1.1.5.154 = INTEGER: 10 SNMPv2-SMI::mib-2.47.1.1.1.1.5.155 = INTEGER: 10 SNMPv2-SMI::mib-2.47.1.1.1.1.5.569 = INTEGER: 3
Dadurch erkennen wir, dass die IDs 97 und 98 für das primäre bzw. sekundäre Netzteil stehen.
Alternativ oder zusätzlich kann über den PhysicalName die Bezeichnung der jeweiligen Entity geprüft werden. Auch hierzu findet sich die passende OID über den alcatel.tree:
1.3.6.1.2.1.47.1.1.1.1.7 entPhysicalName LEAF SnmpAdminString
Angewendet durch ein SNMPWALK auf dem OmniSwitch erhalten wir folgendes Ergebnis:
localhost:~ MichaelS$ snmpwalk -v 2c -c public 192.168.10.1 1.3.6.1.2.1.47.1.1.1.1.7 SNMPv2-SMI::mib-2.47.1.1.1.1.7.1 = STRING: "NI-1" SNMPv2-SMI::mib-2.47.1.1.1.1.7.65 = STRING: "CMM-A" SNMPv2-SMI::mib-2.47.1.1.1.1.7.97 = STRING: "PS-1" SNMPv2-SMI::mib-2.47.1.1.1.1.7.98 = STRING: "PS-2" SNMPv2-SMI::mib-2.47.1.1.1.1.7.154 = STRING: "port" SNMPv2-SMI::mib-2.47.1.1.1.1.7.155 = STRING: "port" SNMPv2-SMI::mib-2.47.1.1.1.1.7.569 = STRING: "Virtual Chassis"
Hier erkennen wir ebenfalls, dass die IDs 97 und 98 für das primäre bzw. sekundäre Netzteil stehen.
Auch bei der Abfrage von Temperatur und CPU-Auslastung haben wir diese IDs durch die Nutzung von SNMPWALK erkannt. Allerdings waren diese beiden Werte jeweils nur auf eine Entity bezogen.
Mit diesen ID-Informationen kann nun über die AlcatelIND1Chassis.mib der Status der Netzteile abgefragt werden:
chasEntPhysOperStatus OBJECT-TYPE
SYNTAX INTEGER
{
up(1),
down(2),
testing(3),
unknown(4),
secondary(5),
notPresent(6),
unpowered(7),
master(8)
}
...
Über den alcatel.tree suchen wir die passende OID:
1.3.6.1.4.1.6486.800.1.1.1.1.1.1.1.2 chasEntPhysOperStatus LEAF INTEGER
Nun gibt es zwei Möglichkeiten der Abfrage, entweder per SNMPWALK oder per SNMPGET auf die einzelnen Netzteil-Entities:
localhost:~ MichaelS$ snmpwalk -v 2c -c public 192.168.10.1 1.3.6.1.4.1.6486.800.1.1.1.1.1.1.1.2 SNMPv2-SMI::enterprises.6486.800.1.1.1.1.1.1.1.2.1 = INTEGER: 1 SNMPv2-SMI::enterprises.6486.800.1.1.1.1.1.1.1.2.65 = INTEGER: 1 SNMPv2-SMI::enterprises.6486.800.1.1.1.1.1.1.1.2.97 = INTEGER: 1 SNMPv2-SMI::enterprises.6486.800.1.1.1.1.1.1.1.2.98 = INTEGER: 1 SNMPv2-SMI::enterprises.6486.800.1.1.1.1.1.1.1.2.154 = INTEGER: 1 SNMPv2-SMI::enterprises.6486.800.1.1.1.1.1.1.1.2.155 = INTEGER: 1 SNMPv2-SMI::enterprises.6486.800.1.1.1.1.1.1.1.2.569 = INTEGER: 1
localhost:~ MichaelS$ snmpwalk -v 2c -c public 192.168.10.1 1.3.6.1.4.1.6486.800.1.1.1.1.1.1.1.2.97 SNMPv2-SMI::enterprises.6486.800.1.1.1.1.1.1.1.2.97 = INTEGER: 1 localhost:~ MichaelS$ snmpwalk -v 2c -c public 192.168.10.1 1.3.6.1.4.1.6486.800.1.1.1.1.1.1.1.2.98 SNMPv2-SMI::enterprises.6486.800.1.1.1.1.1.1.1.2.98 = INTEGER: 1