Konzepte für das Netzwerk-Monitoring
SNMP in der Praxis
In den 80er-Jahren als Protokoll zum Management von Netzwerkgeräten entwickelt, hat sich SNMP schnell als eines der wichtigsten Monitoring-Protokolle in der IT etabliert. Seitdem entstanden zahlreiche neue Methoden sowie Protokolle zum Monitoring von Geräten und Datenverkehr. Immer wieder war vom Ende von SNMP die Rede. Dennoch „lebt“ SNMP nach wie vor und bildet weiterhin ein wichtiges Standbein des IT-Monitorings.
SNMP dient heute in erster Linie als Standardprotokoll zur Überwachung von Netzwerkgeräten. Darüber hinaus ist es mit SNMP jedoch auch möglich, Konfigurationsaufgaben zu erledigen und Einstellungen aus der Ferne zu ändern. SNMP-kompatible Hardware umfasst in der Regel Router, Switches und Server. Auch Drucker, Umgebungssensoren (Temperatur, Feuchtigkeit etc.) und viele andere Geräte kann ein Netzbetreiber mit SNMP überprüfen und steuern.
Voraussetzung ist, dass das zu überwachende Gerät über eine Netzwerkverbindung (Ethernet, TCP/IP) verfügbar ist und Zugriff auf einen SNMP-Server hat. Es muss zudem ein aktives Gerät sein, das auf Anfragen reagieren kann. SNMP stellt also gewisse Mindestanforderungen an die unterstützten Geräte und ist damit auf Hardware für den professionellen Einsatz ausgelegt.
SNMP nutzt für die Client-Server-Kommunikation das „User Datagram Protocol“ (UDP): Eine Überwachungs- oder Verwaltungssoftware sendet (als Client) ein UDP-Paket an den SNMP-Server, den sogenannten Agenten. Bei diesem handelt es sich normalerweise um eine Software, die auf einem Gerät läuft. Der Server reagiert, indem er ein SNMP-Paket als Antwort sendet. Jeder einzelne Frage-Antwort-Zyklus ermöglicht es dem Client, eine „Messung“ vom Gerät abzurufen, etwa Netzwerkverkehr, CPU-Last, Temperatur etc. Abhängig von der Abfragemethode sind auch mehrere Messungen gleichzeitig übertragbar.
Neben bei der beschriebenen UDP-Kommunikation, bei der der Client aktiv Informationen vom Server anfordert, erlaubt SNMP auch die Verwendung von sogenannten Traps. Dies sind Datenpakete, die der SNMP-Server ohne explizite Anforderung an den Client sendet. Wenn ein Gerät (oder der SNMP-Server auf diesem Gerät) entsprechend konfiguriert ist, wird ein
SNMP-Trap an den SNMP-Client gesendet, sobald auf dem Gerät ein definiertes Ereignis stattfindet. Den SNMP-Client nennt man in diesem Fall in der Regel einen Trap-Receiver. Aus Pull wird Push, unabhängig von definierten Abfrageintervallen und analog zu anderen Eventlog-basierenden Methoden wie etwa Syslog.
SNMP-Versionen
Die erste SNMP-Version (v1) ist seit 1988 definiert. Obwohl diese Version aufgrund ihrer Einfachheit keinen Abhörschutz durch Verschlüsselung oder andere Mechanismen enthält, ist sie noch immer die am häufigsten verwendete Variante in „privaten LANs“ hinter einer Firewall. Und obwohl die Verwendung von v1 für öffentliche Netze nicht zu empfehlen ist, bieten auch heute noch viele einfache Geräte nur SNMP v1 an.
Viele Sicherheitsfragen rückten 1993 und 1996 stärker in den Vordergrund. Die damals diskutierten Lösungen haben sich allerdings nie wirklich durchgesetzt. Nur eine leicht verbesserte Nachfolgeversion kommt häufiger zum Einsatz. Wenn von SNMP v2 die Rede ist, ist meist die Version „v2c“ gemeint.
Die aktuelle Version ist SNMP v3, die die Sicherheit von SNMP erhöht. Da der Einsatz von SNMP v3 jedoch relativ komplex und anspruchsvoll ist, hat sich diese Version seit ihrer Spezifikation im Jahr 2002 für den Einsatz in Intranets nicht flächendeckend durchsetzen können.
SNMP im Einsatz: MIBs und OIDs
Sobald es zum Einsatz von SNMP in der Monitoring-Praxis kommt, dreht sich alles um OIDs und MIBs. OIDs sind Object Identifier, die der Hersteller eines Geräts oder einer Applikation definiert. MIB steht für Management Information Base. Dies sind Dateien, in denen der Hersteller alle OIDs seiner Geräte bereitstellt. Dabei kann eine MIB die OIDs eines Geräts, einer Geräteserie oder auch aller Geräte eines Herstellers enthalten. MIBs lassen sich gewöhnlich im Supportbereich der Homepage des Herstellers oder von einschlägigen Internetportalen herunterladen.
Wie aber funktioniert der Umgang mit OIDs und MIBs in der Praxis? Angenommen, ein Administrator hat einen Drucker und will nicht nur wissen, wie viel Toner noch vorhanden ist (OID1), sondern auch, wie viele Blätter er bereits gedruckt hat (OID2) und wie viele Blätter derzeit in der Warteschlange stehen (OID3). Auf dem Drucker ist ein SNMP-Server, der die entsprechenden OIDs bereithält. Damit der SNMP-Client, also die Monitoring-Lösung, die gewünschte Information anfordern kann, muss er die entsprechenden OIDs kennen und adressieren können. Dazu müssen OIDs aus der MIB des Geräts oder des Herstellers isoliert und als OID-Library in der Monitoring-Lösung hinterlegt sein. Monitoring-Lösungen setzen dabei auf unterschiedliche Modelle, die man sich im Einzelnen ansehen kann.
Alles in Handarbeit: Für jedes Gerät, jeden Wert, der via SNMP zu ermitteln ist, muss die entsprechende OID aus der MIB des Herstellers extrahiert und in der Monitoring-Lösung hinterlegt werden. Dies hält die Monitoring-Lösung schlank und genau auf die Bedürfnisse des Nutzers zugeschnitten. Zeitgleich erfordert diese Vorgehensweise natürlich einiges an Aufwand und Erfahrung.
Alles drin: Viele SNMP-basierende Monitoring-Lösungen haben bereits OID-Libraries für sehr viele Hersteller und deren Geräte hinterlegt, sodass der Nutzer nur noch auswählen muss, welche Werte er im Detail überwachen will. Dies ist schnell und spart einiges an Aufwand. Ist das zu überwachende Gerät allerdings nicht hinterlegt, ist der Hersteller der Monitoring-Lösung meist die einzige Möglichkeit, die entsprechenden OIDs in die Monitoring-Software zu integrieren. Dies ist zeit- und manchmal auch kostenintensiv.
Der Kompromiss: Manche Lösungen setzen auf einen Kompromiss. Die wichtigsten Hersteller und ihre Geräte sind hinterlegt, was die tägliche Arbeit mit dem Tool deutlich erleichtert. Für nicht hinterlegte Geräte bieten die Lösungen Import-Tools, die es erleichtern, OIDs aus MIBs zu extrahieren und in die Monitoring-Lösung zu integrieren.
- SNMP in der Praxis
- SNMP-Kritik
Lesen Sie mehr zum Thema
