ueberwachung_des_chassis-zustands_via_snmp
no way to compare when less than two revisions
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| — | ueberwachung_des_chassis-zustands_via_snmp [2014/06/18 19:59] (aktuell) – angelegt benny | ||
|---|---|---|---|
| Zeile 1: | Zeile 1: | ||
| + | Ü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-> | ||
| + | |||
| + | Chassis 1 | ||
| + | Model Name: OS6850E-24X, | ||
| + | Description: | ||
| + | Part Number: | ||
| + | Hardware Revision: | ||
| + | Serial Number: | ||
| + | Manufacture Date: DEC 04 2010, | ||
| + | Admin Status: | ||
| + | Operational Status: | ||
| + | Number Of Resets: | ||
| + | MAC Address: | ||
| + | |||
| + | |||
| + | OS6850E-> | ||
| + | | ||
| + | -----------------+---------------+--------+----------------------------------- | ||
| + | Kbase.img | ||
| + | Kadvrout.img | ||
| + | K2os.img | ||
| + | Keni.img | ||
| + | Ksecu.img | ||
| + | Kencrypt.img | ||
| + | </ | ||
| + | |||
| + | Zu allererst sollte ein Benutzer angelegt werden mit dem SNMP verwendet wird: | ||
| + | < | ||
| + | OS6850E-> | ||
| + | OS6850E-> | ||
| + | User name = snmp, | ||
| + | Password expiration | ||
| + | Password allow to be modified date = None, | ||
| + | Account lockout | ||
| + | Password bad attempts | ||
| + | Read Only for domains | ||
| + | Read/Write for domains | ||
| + | Snmp allowed | ||
| + | Snmp authentication | ||
| + | Snmp encryption | ||
| + | Console-Only | ||
| + | </ | ||
| + | <WRAP center round tip 60%> | ||
| + | In produktiven Netzwerken empfehlen wir den Einsatz von SNMPv3! | ||
| + | </ | ||
| + | |||
| + | Den SNMPv2 Zugriff mit der Community " | ||
| + | < | ||
| + | OS6850E-> | ||
| + | </ | ||
| + | |||
| + | Die Authentifizierung von Benutzern gegen die lokale Benutzerdatenbank aktivieren: | ||
| + | < | ||
| + | OS6850E-> | ||
| + | OS6850E-> | ||
| + | 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 | ||
| + | </ | ||
| + | <WRAP center round tip 60%> | ||
| + | In produktiven Netzwerken empfehlen wir den Einsatz von RADIUS-Authentifizierung. | ||
| + | </ | ||
| + | |||
| + | Da wir den Switch irgendwie erreichen müssen, erstellen wir ein IP-Interface: | ||
| + | < | ||
| + | OS6850E-> | ||
| + | </ | ||
| + | |||
| + | 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:: | ||
| + | SNMPv2-MIB:: | ||
| + | DISMAN-EVENT-MIB:: | ||
| + | SNMPv2-MIB:: | ||
| + | SNMPv2-MIB:: | ||
| + | SNMPv2-MIB:: | ||
| + | SNMPv2-MIB:: | ||
| + | IF-MIB:: | ||
| + | IF-MIB:: | ||
| + | ... | ||
| + | </ | ||
| + | |||
| + | 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 " | ||
| + | < | ||
| + | show temperature [number] | ||
| + | ... | ||
| + | MIB Objects | ||
| + | chasChassisTable | ||
| + | | ||
| + | </ | ||
| + | |||
| + | Ü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 | ||
| + | </ | ||
| + | |||
| + | 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:: | ||
| + | </ | ||
| + | |||
| + | <WRAP center round important 60%> | ||
| + | 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:: | ||
| + | </ | ||
| + | |||
| + | Dieser Status lässt sich auch über die CLI kontrollieren: | ||
| + | < | ||
| + | OS6850E-> | ||
| + | |||
| + | 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 | ||
| + | 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 | ||
| + | ... | ||
| + | | ||
| + | </ | ||
| + | |||
| + | Ü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 | ||
| + | </ | ||
| + | |||
| + | 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:: | ||
| + | </ | ||
| + | |||
| + | <WRAP center round important 60%> | ||
| + | Auch hier gilt oben beschriebener Hinweis zu SNMPGET und entsprechender Entity | ||
| + | </ | ||
| + | |||
| + | |||
| + | Dieser Status lässt sich auch über die CLI kontrollieren: | ||
| + | < | ||
| + | OS6850E-> | ||
| + | * - current value exceeds threshold | ||
| + | |||
| + | Device | ||
| + | Resources | ||
| + | -----------------+-------+------+------+-----+---- | ||
| + | Receive | ||
| + | Transmit/ | ||
| + | Memory | ||
| + | Cpu 80 | ||
| + | </ | ||
| + | |||
| + | <WRAP center round tip 60%> | ||
| + | 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, | ||
| + | |||
| + | < | ||
| + | PhysicalClass ::= TEXTUAL-CONVENTION | ||
| + | STATUS | ||
| + | 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, | ||
| + | instantiated by an agent. | ||
| + | ... | ||
| + | |||
| + | SYNTAX | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | Ü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 | ||
| + | </ | ||
| + | |||
| + | 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:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | </ | ||
| + | |||
| + | 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 | ||
| + | </ | ||
| + | |||
| + | 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:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | </ | ||
| + | |||
| + | Hier erkennen wir ebenfalls, dass die IDs 97 und 98 für das primäre bzw. sekundäre Netzteil stehen. | ||
| + | |||
| + | <WRAP center round tip 60%> | ||
| + | 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 | ||
| + | </ | ||
| + | |||
| + | 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:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | SNMPv2-SMI:: | ||
| + | </ | ||
| + | |||
| + | < | ||
| + | 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:: | ||
| + | |||
| + | 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:: | ||
| + | </ | ||
ueberwachung_des_chassis-zustands_via_snmp.txt · Zuletzt geändert: von benny
