von Redaktion IT-A…
Lesezeit
2 Minuten
Netzwerk-Monitoring mit den Net-SNMP-Tools: Basisinformationen im Netz
Zahlreiche Hersteller von Routern, Firewalls, Hubs und anderen Netzwerkkomponenten sowie die namhaften Hersteller von Servern und Desktopsystemen liefern ihre Systeme mit passenden Remote-Management-Lösungen aus. Diese liefern Daten zum Systemstatus und ermöglichen das Setzen von Konfigurationsparametern. Allen proprietären Anmutungen zum Trotz ist diesen Lösungen eines gemeinsam: Ihre Basis bildet in der Regel das "Simple Network Management Protocol" (SNMP). In diesem Workshop möchten wir die Net-SNMP-Tools vorstellen – ein freies Paket von Werkzeugen, das SNMP-Operationen per Kommandozeile ermöglicht.
Erst mit der Version SNMPv3, die ihre Vorgänger noch nicht vollständig verdrängen konnte, hielten Verschlüsselung und ein abgestuftes Zugriffsmodell einschließlich Benutzerverwaltung Einzug in das Protokoll. Sollte zunächst bereits mit der zweiten Version des SNMP-Standards das Sicherheitsmodell überarbeitet werden, beließ man es nach Verzögerungen in der Entwicklung bei den Communitys, so dass der Standard SNMPv2C getauft wurde. Dieser bildet in diesem Workshop die Basis für unseren Überblick über die Net-SNMP-Tools. Ausführliche Hintergrundinformationen zur Entwicklung der SNMP-Standards liefert [4].
Die Architektur
Der Aufbau der SNMP-Architektur ist denkbar einfach konzipiert und wird somit dem Namen des Protokolls vollkommen gerecht. Auf Seiten des zu verwaltenden Clients regelt ein SNMP-Agent den Zugriff auf dessen "Management Information Base" (MIB) – eine hierarchisch aufgebaute Baumstruktur, die sämtliche abfragbaren Parameter enthält (siehe Bild 1).
Bild 1: Managementstation und Client kommunizieren per SNMP miteinander. Erlaubt sind die drei Operationen "get", "set" und "trap".
Die Managementstation dagegen verfügt im einfachsten Fall über die Net-SNMP-Tools, deren grundlegende Funktionalität sich auf zwei Operationen reduziert:"get" liest Werte vom Client, "set" ändert sie. Darüber hinaus kann der Client auch selbst so genannte Traps, also Meldungen über bestimmte Systemzustände, an die Managementstation schicken.
Werfen wir zunächst einen genaueren Blick auf die MIB, deren Struktur der Organisation von Domains und Hosts im DNS ähnelt (siehe Bild 2). Beginnend mit einer Wurzel – symbolisiert durch den Punkt – verzweigt die MIB zu einem Baum, dessen "Blätter" jeweils den per SNMP abfragbaren Objekten entsprechen. Der absolute Pfad zu einem Blatt, der so genannte "Object Identifier" (OID), ist in punktierter Dezimalnotation von links nach rechts aufgebaut. So findet sich zum Beispiel eine Variable, die eine Beschreibung des Client-Systems als String aufnehmen kann, unter dem OID ".1.3.6.1.2.1.1.1.0" beziehungsweise ausformuliert unter ".iso.org.dod.internet.mgmt.mib-2.system. sysDscr.0".
Bild 2: Die "Management Information Base" (MIB) ist als Baumstruktur organisiert.
Dieser Wert stellt einen Bestandteil der MIB-II dar – einer Teilmenge der MIB, die per RFC standardisiert und somit herstellerübergreifend implementiert ist. Jedoch handelt es sich bei der MIB nicht um ein monolithisches Konstrukt, vielmehr sind auch herstellerspezifische Erweiterungen zulässig. Um diese zu implementieren, erhält ein Hersteller nach dessen Registrierung einen eigenen Bereich unterhalb des Astes "enterprises". So stellen etwa Produkte des Herstellers Cisco gerätespezifische Parameter unterhalb von ".1.3.6.1.4.1.9" bereit, Daten zu Intel-basierenden HP-Systemen finden Sie unter ".1.3.6.1.4.1.232", während der SNMP-Informant Daten zum Windows-Betriebssystem unterhalb von ".1.3.6.1.4.1.9600" sammelt.
Jeder Hersteller dokumentiert den von ihm verwalteten Bereich in der Regel in einer MIB-Spezifikation, die neben einer Beschreibung das MIB-Modul enthält, welches wiederum auf der Managementstation hinterlegt wird. Zwar können Sie herstellerspezifische Informationen über den OID in Dezimalnotation grundsätzlich auch abfragen, ohne ein entsprechendes Modul zu besitzen. Erst das Modul erschließt jedoch den ausformulierten OID und somit dessen Bedeutung. Die MIB setzt sich somit aus vielen (Teil-)MIBs zusammen. Detaillierte Informationen zur Syntax der MIBs finden Sie in [3]. Damit nun Informationen aus der MIB vom Client zur Managementstation gelangen, kommt SNMP als Protokoll der Applikationsschicht zum Einsatz, das wiederum auf UDP aufsetzt.
Ausgabe 11/06 des IT-Administrator Magazins S. 36 - 39, Autor: Christian Knermann
Die Architektur
Der Aufbau der SNMP-Architektur ist denkbar einfach konzipiert und wird somit dem Namen des Protokolls vollkommen gerecht. Auf Seiten des zu verwaltenden Clients regelt ein SNMP-Agent den Zugriff auf dessen "Management Information Base" (MIB) – eine hierarchisch aufgebaute Baumstruktur, die sämtliche abfragbaren Parameter enthält (siehe Bild 1).
Bild 1: Managementstation und Client kommunizieren per SNMP miteinander. Erlaubt sind die drei Operationen "get", "set" und "trap".
Die Managementstation dagegen verfügt im einfachsten Fall über die Net-SNMP-Tools, deren grundlegende Funktionalität sich auf zwei Operationen reduziert:"get" liest Werte vom Client, "set" ändert sie. Darüber hinaus kann der Client auch selbst so genannte Traps, also Meldungen über bestimmte Systemzustände, an die Managementstation schicken.
Werfen wir zunächst einen genaueren Blick auf die MIB, deren Struktur der Organisation von Domains und Hosts im DNS ähnelt (siehe Bild 2). Beginnend mit einer Wurzel – symbolisiert durch den Punkt – verzweigt die MIB zu einem Baum, dessen "Blätter" jeweils den per SNMP abfragbaren Objekten entsprechen. Der absolute Pfad zu einem Blatt, der so genannte "Object Identifier" (OID), ist in punktierter Dezimalnotation von links nach rechts aufgebaut. So findet sich zum Beispiel eine Variable, die eine Beschreibung des Client-Systems als String aufnehmen kann, unter dem OID ".1.3.6.1.2.1.1.1.0" beziehungsweise ausformuliert unter ".iso.org.dod.internet.mgmt.mib-2.system. sysDscr.0".
Bild 2: Die "Management Information Base" (MIB) ist als Baumstruktur organisiert.
Dieser Wert stellt einen Bestandteil der MIB-II dar – einer Teilmenge der MIB, die per RFC standardisiert und somit herstellerübergreifend implementiert ist. Jedoch handelt es sich bei der MIB nicht um ein monolithisches Konstrukt, vielmehr sind auch herstellerspezifische Erweiterungen zulässig. Um diese zu implementieren, erhält ein Hersteller nach dessen Registrierung einen eigenen Bereich unterhalb des Astes "enterprises". So stellen etwa Produkte des Herstellers Cisco gerätespezifische Parameter unterhalb von ".1.3.6.1.4.1.9" bereit, Daten zu Intel-basierenden HP-Systemen finden Sie unter ".1.3.6.1.4.1.232", während der SNMP-Informant Daten zum Windows-Betriebssystem unterhalb von ".1.3.6.1.4.1.9600" sammelt.
Jeder Hersteller dokumentiert den von ihm verwalteten Bereich in der Regel in einer MIB-Spezifikation, die neben einer Beschreibung das MIB-Modul enthält, welches wiederum auf der Managementstation hinterlegt wird. Zwar können Sie herstellerspezifische Informationen über den OID in Dezimalnotation grundsätzlich auch abfragen, ohne ein entsprechendes Modul zu besitzen. Erst das Modul erschließt jedoch den ausformulierten OID und somit dessen Bedeutung. Die MIB setzt sich somit aus vielen (Teil-)MIBs zusammen. Detaillierte Informationen zur Syntax der MIBs finden Sie in [3]. Damit nun Informationen aus der MIB vom Client zur Managementstation gelangen, kommt SNMP als Protokoll der Applikationsschicht zum Einsatz, das wiederum auf UDP aufsetzt.
Seite 1 von 2 Nächste Seite>>
Ausgabe 11/06 des IT-Administrator Magazins S. 36 - 39, Autor: Christian Knermann
