Quo Vadis, SNMP?
Whitepaper Teil 2: SNMP praktisch anwenden
Einleitung
Im ersten Teil dieses Whitepapers wurden bereits die Grundzüge von SNMP, die Geschichte, Probleme und Zukunftsaussichten betrachtet sowie Alternativen zu dem zwar etablierten, aber oft auch problematischen Protokoll aufgezeigt. In diesem zweiten Teil steht die technische Seite im Vordergrund—von der Verwendung der MIBs bis zur praktischen Einrichtung einer Netzwerküberwachung. Als Hersteller einer etablierten Netzwerk Monitoring Software setzt sich die Paessler AG seit 1996 intensiv mit SNMP und seinen Möglichkeiten auseinander—und mit seinen Unzulänglichkeiten.
Management Information Base (MIB)
Voraussetzung für eine erfolgreiche Übermittlung von Werten und damit für eine Netzwerküberwachung mittels SNMP ist eine funktionierende Kommunikation zwischen SNMP-Client und -Server. Dafür müssen die verfügbaren SNMP-Objekte über eindeutige Adressen verfügen, die auf beiden Seiten bekannt sind.
Damit der Zugriff auch herstellerübergreifend und mit unterschiedlichen Client-Server-Kombinationen funktioniert, wurde die „Management Information Base“ (MIB) als unabhängiges Format zur Speicherung von Geräteinformationen entwickelt. In einer MIB-
Datei werden alle in einem Gerät abfragbaren Objekte mittels „Object Identifier“ (OID) beschrieben. Über diese OIDs werden SNMP-Objekte mit einer eindeutigen Adresse, einem Namen und Informationen über Typ, Zugriffsrechte und Beschreibung definiert.
Die MIB unterstützt auch Tabellen, die eingesetzt werden, wenn auf mehrere gleichartige Objekte von einer für die MIB unbekannten Anzahl von Instanzen zugegriffen werden soll. Typische Beispiele hierfür sind die verschiedenen Ports eines Switches oder die Auslastungswerte eines Servers mit mehreren Prozessoren. Hierfür werden zunächst die OIDs aller Spalten einer Tabellenzeile definiert. Auf die spezifischen Objekte in der Tabelle wird dann über diese OIDs mit einem angehängten Indexwert zugegriffen.
Damit ein Programm SNMP-fähige Geräte managen kann, sollte es idealerweise die MIB-Definitionsdateien importieren und interpretieren können. Diese Dateien für die Definition der MIB erkennt man üblicherweise an den Dateiendungen .mib oder .my.
Damit nicht jede Datei den Baum von ganz oben aus definieren muss, gibt es einen Mechanismus für die Einbindung (Import) anderer MIB-Dateien in eine vorhandene Datei, die dann beliebig tief verschachtelt sein können.
ABBILDUNG 1: Beispiel für einen typischen OID-Eintrag in der MIB-Datei IF-MIB.mib
ifInOctets OBJECT-TYPE
SYNTAX Counter32
ACCESS read-only
STATUS mandatory
DESCRIPTION
“The total number of octets received on the interface,
including framing characters.”
::= { ifEntry 10 }
Abbildung 1 zeigt einen typischen OID-Eintrag in einer MIB: Es handelt sich um den Zähler für eingehenden Traffic aus der MIB-Datei für Standardinterfaces, z.B. für einen Switch. Dieser OID hat die Adresse 1.3.6.1.2.1.2.2.1.10.[index]. Wenn also der eingehende Traffic des dritten Ports ausgewertet werden soll, wird darauf mit 1.3.6.1.2.1.2.2.1.10.3 zugegriffen.
Herausforderungen bei der SNMP-Einrichtung
Obwohl SNMP in der Regel sehr zuverlässig funktioniert, wurden im ersten Teil bereits einige Hindernisse erwähnt, denen der Administrator vor allem bei der Ersteinrichtung einer Netzwerküberwachung mittels dieses Protokolls begegnen kann. Die damit verbundenen Herausforderungen sollten den Verantwortlichen nicht abschrecken. Auf Basis des entsprechenden Know-hows lassen sich alle Probleme lösen. Das Wissen um die Art möglicher Tücken ist dabei schon der erste Schritt. Im Folgenden ermöglichen einige ausgewählte praxisnahe Szenarien bzw. Erfahrungen aus Sicht eines Monitoring-Spezialisten einen tieferen Einblick in die Thematik.
The four most common stumbling blocks when setting up SNMP
1. Lastprobleme
Meistens wird bei einer SNMP-Überwachung jeder Messwert einzeln abgerufen. Sollen Informationen von vielen SNMP-Objekten erfasst werden, entstehen bei einem sehr detaillierten Monitoring zahlreiche Abfragen pro Intervall und damit auch hohe Anfragevolumen. Nicht jedes Gerät und nicht jede Applikation können dieses Aufkommen problemlos bewältigen. Sind die Abfrageintervalle zu kurz eingestellt, ist unter Umständen mit einer zusätzlichen, starken Belastung des Netzwerks zu rechnen. Es ist daher wichtig, mit moderaten Standardeinstellungen zu beginnen (beispielsweise jede Minute ein Abruf aller Counter) und die tatsächlich anfallende Last zu beobachten. Eine geeignete Monitoring-Lösung unterstützt den Administrator bei dieser Aufgabe und lässt ihn Lastprobleme frühzeitig erkennen. Er ist so in der Lage, die Abfrageintervalle entsprechend anzupassen und die optimalen Einstellungen zu ermitteln.
Je öfter die Daten abgerufen werden, desto detaillierter sind später die Monitoring-Daten. Dabei sollte die Waage zwischen Last und Ergebnisgenauigkeit gehalten werden, denn nicht für jeden Anwendungszweck sind Daten im größtmöglichen Detail notwendig. Ebenso ist zu berücksichtigen, wie kurz ein Abfrageintervall überhaupt sein darf. Dies hängt davon ab, wie oft ein Gerät intern Messwerte zur Verfügung stellt. Beim SNMP-Objekttyp „Counter“ ist es wiederum wichtig, das Abfrageintervall nicht zu lang zu wählen. Handelt es sich um einen 32-Bit Counter, dann werden die Daten sonst nicht oft genug abgerufen und es kann hier durch den Pufferüberlauf zu falschen Messwerten kommen.
2. Einrichtungsaufwand
Oft stellen die Hardware-Hersteller passende MIB-Dateien bereit. Ist dies nicht der Fall, kann es sehr aufwändig sein, die passenden Informationen in unabhängigen Internet-Datenbanken zu finden. Hat man die passende MIB-Datei gefunden, benötigt diese oft noch weitere Include-Dateien, die idealerweise bereits mitgeliefert werden, aber in einem ungünstigen Fall ebenfalls schwer zu beschaffen sind. Zudem wurden Protokolle und MIBs oft nur oberflächlich oder ungenau implementiert. Kommt der MIB-Parser ins
Stocken, müssen Dateien häufig manuell gepatcht werden, um sie mit dem jeweils vorhandenen Parser zum Laufen zu bringen. Paessler unterstützt den Anwender in seiner Knowledge-Base mit Links zum Aufspüren von MIB-Dateien3 sowie entsprechender
Software zum Import. Noch leichter geht es mit einer Auto-Discovery-Funktion. Verfügt der SNMP-Client über eine solche automatische Suche, dann können Geräte im Netzwerk oft automatisch erkannt werden. Dabei scannt der SNMP-Client das Netzwerk nach vorhandenen Geräten und richtet die SNMP-Objekte automatisch für die Überwachung ein, sodass sich der Administrator erst gar nicht mit MIB-Dateien befassen muss.
Eine „intelligente“ Netzwerküberwachungs-Software verhält sich fehlertolerant, sodass SNMP-Implementierungsfehler der Hardwarehersteller unbemerkt im Hintergrund abgefangen werden, ohne dass man davon überhaupt etwas bemerkt.
3. Veränderte OIDs
Manche Geräte wechseln bei jedem Neustart die OIDs ihrer SNMP-Objekte. Da für eine Überwachung meist feste OIDs in die Konfiguration eingetragen werden, kann dies zu Behinderungen beim Monitoring führen: Werden die SNMP-Objekte nach einem Neustart unter ihrer vorherigen OID-Adresse von der Client-Software nicht mehr gefunden, können keine Daten mehr abgefragt werden – das Monitoring steht still. Vermieden wird dieses Problem mittels einer Software, die eine automatische Neuzuordnung der OIDs durchführt. Damit ist sichergestellt, dass SNMP-Objekte auch unter einer anderen OID weiterhin für ein Monitoring zur Verfügung stehen.
4. Verschlüsselung
Die Einrichtung einer verschlüsselten Übertragung ist nicht trivial. Gerade wenn man eine komplexe Verschlüsselung benötigt (SNMP V3), kann dies einen unerfahrenen Administrator schnell überfordern. Bei unvollständiger Einrichtung kann es unerwartet doch zu unverschlüsselten Übertragungen kommen, die dann ein erhebliches Sicherheitsrisiko darstellen. Der Verantwortliche sollte die Konfiguration der Geräte sorgfältig überprüfen, zum Beispiel mit dem kostenlosen SNMP-Tester4 von Paessler. Dieser ermöglicht ein unkompliziertes Abfragen der SNMP-Daten von jedem beliebigen Gerät im Netzwerk. Unterstützt werden SNMP V1 bis V3.
Ein kleines Beispiel (Kommandozeile)
Es ist nicht schwer, die SNMP-Kommunikation zu einem Gerät herzustellen. Wie eine solche Verbindung funktioniert, zeigt das folgende kleine Beispiel, in dem auf Kommandozeilenebene einige Daten von einem Cisco-Switch abgefragt werden. Dazu kommt die Open Source Net-SNMP Library zum Einsatz‚ die es für Windows und Linux zum Download gibt. Die Aufrufe sind auf beiden Betriebssystemen identisch.
Zunächst wird mit snmpget ein einzelner Counter abgefragt, hier die Uptime des Switches (siehe Abbildung 2).
ABBILDUNG 2: Abrufen eines einzelnen Wertes mit snmpget; hier wird die Uptime eines Switches abgefragt
>snmpget -c public -v 1 -O f 10.0.0.127 1.3.6.1.2.1.1.3.0
.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.sysUpTimeInstance =
Timeticks: (128229595) 14 days, 20:11:35.95
Die Optionen des Aufrufs im Einzelnen:
Option
-c public
-v 1
-O f
10.0.0.127
1.3.6.1.2.1.1.3.0
Beschreibung
Der “SNMP Community String”, das Passwort für den Zugriff (hier: “public”)
Setzt SNMP-Version 1
Setzt eine Option für die Ausgabe der kompletten OID
Dies ist die IP-Adresse des abgefragten Switches
Dies ist die OID zum Abfragen der Uptime
snmpwalk ruft einen Teil des MIB-Baumes ab. Der Walk gibt alle OIDs unterhalb der angegebenen OID aus. Dazu verwendet er intern ein getnext, um von der aktuellen OID zur nächsten zu kommen.
ABBILDUNG 3: Abrufen eines Teil-MIB Baumes mit snmpwalk
>snmpwalk -c public -v 1 -O f 10.0.0.127 1.3.6.1.2.1.1
.iso.org.dod.internet.mgmt.mib-2.system.sysDescr.0 = STRING: 48-Port
10/100/1000 Gigabit Switch with WebView
.iso.org.dod.internet.mgmt.mib-2.system.sysObjectID.0 = OID: .iso.org.dod.
internet.private.enterprises.3955.6.1.2048.1
.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.sysUpTimeInstance =
Timeticks: (128404187) 14 days, 20:40:41.87
.iso.org.dod.internet.mgmt.mib-2.system.sysContact.0 = STRING:
.iso.org.dod.internet.mgmt.mib-2.system.sysName.0 = STRING: Core Switch 1
.iso.org.dod.internet.mgmt.mib-2.system.sysLocation.0 = STRING: BSX
Serverraum
.iso.org.dod.internet.mgmt.mib-2.system.sysServices.0 = INTEGER: 2
.iso.org.dod.internet.mgmt.mib-2.system.sysORLastChange.0 = Timeticks: (0)
0:00:00.00
.iso.org.dod.internet.mgmt.mib-2.system.sysORTable.sysOREntry.sysORID.1 =
OID: .iso.org.dod.internet.private.enterprises.89.73
.iso.org.dod.internet.mgmt.mib-2.system.sysORTable.sysOREntry.sysORDescr.1
= STRING: RS capabilities
.iso.org.dod.internet.mgmt.mib-2.system.sysORTable.sysOREntry.
sysORUpTime.1 = Timeticks: (0) 0:00:00.00
ABBILDUNG 4: Mit der Net-SNMP Library können Daten des Switches abgerufen werden
Diese Funktion ist auch beim Debugging hilfreich. In der Ausgabe in Abbildung 3 ist wieder die Uptime enthalten, die zuvor direkt mit der OID [...].3.0 abgerufen wurde (Abbildung 2).
Praktischer Einsatz von SNMP
Eine Software zur Netzwerküberwachung übernimmt den Abruf und die Auswertung der per SNMP gesammelten Daten. Wie eine solche Überwachung vonstatten geht, zeigt der Einsatz von SNMP am Beispiel der beiden Programme MRTG (erhältlich für Unix, Windows und NetWare) und PRTG (für Windows) in der Praxis.
Beide Lösungen überwachen einen Cisco-Switch, der als Firewall zwischen einem LAN und einer 4-MBit-Leitung steht. Die IP-Adresse lautet 10.0.0.127, der Community-String ist „public“, die verwendete SNMP-Version ist V1.
MRTG Multi Router Traffic Grapher
Um MRTG für die Netzwerküberwachung einzurichten, muss zunächst die Konfiguration erstellt werden. Dies erfolgt mit einem Shell-Skript (siehe Abbildung 5).
ABBILDUNG 5: Dieses Shell-Skript erzeugt eine Konfigurationsdatei für MRTG
cfgmaker --global ‘WorkDir: /home/httpd/mrtg’ \
--global ‘Options[_]: bits,growright’ \
--output /home/mrtg/cfg/mrtg.cfg \
[email protected]
Via Skript Konfigurationsdateien erstellen
Nach dem Skriptaufruf verbindet sich MRTG mit dem angegebenen Gerät, liest die abfragbaren Schnittstellen aus und listet sie in einer Konfigurationsdatei wie in Abbildung auf. Diese Datei verwendet MRTG später, um den Switch zu überwachen.
ABBILDUNG 6: Auszug aus der MRTG-Konfigurationsdatei für die Überwachungs eines Cisco-Switches
# Created by
#cfgmaker [email protected] --global ‘WorkDir: /home/httpd/mrtg’ --global
´Options[_]: bits,growright’ --output /home/mrtg/cfg/mrtg.cfg
### Global Config Options
# for UNIX
# WorkDir: /home/http/mrtg
# or for NT
# WorkDir: c:\mrtgdata
### Global Defaults
# to get bits instead of bytes and graphs growing to the right
# Options[_]: growright, bits
EnableIPv6: no
RunAsDaemon: yes
Options[_]: bits,growright
#####################################################################
# System: cisco.bsx
# Description: Cisco Internetwork Operating System Software
# IOS (tm) 3600 Software (C3620-IK9O3S7-M), Version 12.3(15a), RELEASE
SOFTWARE (fc2)
# Technical Support: http://www.cisco.com/techsupport
# Copyright (c) 1986-2005 by cisco Systems, Inc.
# Compiled Fri 22-Jul-05
# Contact: [email protected]
# Location: BSX-Datacenter
In die fertige Konfigurationsdatei sollte man noch die Option RunAsDaemon: yes einarbeiten und MRTG als cronjob laufen lassen, damit kontinuierlich „ge-monitort“ wird. Eine genauere Beschreibung steht im „MRTG Installation Guide“ zur Verfügung.
Den allgemeinen Einstellungen folgen einige Abschnitte, welche die gefundenen Interfaces (hier also Netzwerkanschlüsse im Switch) repräsentieren. Abbildung 7 zeigt exemplarisch den Abschnitt für das interne Interface.
ABBILDUNG 7: Auszug aus der MRTG-Konfigurationsdatei; Abschnitt zur Konfiguration des internen Cisco-Interfaces
### Interface 2 >> Descr: ‘Ethernet0/1’ | Name: ‘Et0/1’ | Ip: ‘10.0.0.127’
| Eth: ‘00-02-16-48-a8-e1’ ###
Target[10.0.0.127_2]: 2:[email protected]:
SetEnv[10.0.0.127_2]: MRTG_INT_IP=”10.0.0.127” MRTG_INT_
DESCR=”Ethernet0/1”
MaxBytes[10.0.0.127_2]: 1250000
Title[10.0.0.127_2]: Traffic Analysis for 2 -- cisco.bsx
PageTop[10.0.0.127_2]: <h1>Traffic Analysis for 2 -- cisco.bsx</h1>
<div id=”sysdetails”>
<table>
<tr>
<td>System:</td>
<td>cisco.bsx in BSX-Datacenter</td>
</tr>
<tr>
<td>Maintainer:</td>
<td>[email protected]</td>
</tr>
<tr>
<td>Description:</td>
<td>Ethernet0/1 1:private-bsx.paessler.com
[10.0.0.0/16] </td>
</tr>
<tr>
<td>ifType:</td>
<td>ethernetCsmacd (6)</td>
</tr>
<tr>
<td>ifName:</td>
<td>Et0/1</td>
</tr>
<tr>
<td>Max Speed:</td>
<td>1250.0 kBytes/s</td>
</tr>
<tr>
<td>Ip:</td>
<td>10.0.0.127 (firewall1.bsx)</td>
</tr>
</table>
</div>
Einstellungsänderungen erfolgen durch das Editieren der Konfigurationsdatei in einem Texteditor. Hilfreich ist dabei die „MRTG Configuration Reference“.
Die Ergebnisse werden in einer HTML-Datei abgelegt
Das Monitoring-Ergebnis lässt sich am Ende in einer HTML-Datei betrachten, die MRTG am angegebenen Output-Pfad ablegt. Dabei werden auch grafische Übersichten erstellt (siehe Abbildung 8).
ABBILDUNG 8: Beispiel eines Graphen, erzeugt von MRTG
PRTG Network Monitor
In PRTG erfolgt die Einrichtung der Überwachung des Switches in einer grafischen, webbasierenden Benutzeroberfläche (siehe Abbildung 9 und 10). Dabei unterstützt ein Assistent, der durch die drei Konfigurationsschritte führt.
Bei der Einrichtung der Geräte unterstützt ein Assistent
ABBILDUNG 9: Startbildschirm des PRTG-Webinterfaces
Zunächst wird ein „Gerät“ mit der IP-Adresse des Switches angelegt. Falls die Standardeinstellungen für SNMP-Port und Zugangsdaten abweichen, kann man dies ebenfalls mit Hilfe des Assistenten ändern. Anschließend verbindet sich PRTG mit dem Switch und überprüft ihn mit seiner eingebauten Funktion zur automatischen Erkennung auf verfügbare SNMP-Objekte.
ABBILDUNG 10: In drei Schritten richten Sie in der graphischen Benutzeroberfläche Ihr Gerät ein
Innerhalb weniger Minuten wird automatisch jeweils ein „Sensor“ für jeden SNMP-Counter hinzugefügt – in unserem Beispiel sind dies 31 Sensoren, hauptsächlich vom Typ „SNMP Traffic“. Zusätzlich legt die automatische Suche einen Ping-Sensor an, der die generelle Erreichbarkeit des Gerätes überwacht. Eine einfache Möglichkeit, die das Debugging unterstützt. Falls einmal keine Daten mehr vom Switch empfangen werden können, erkennt der Administrator auf diese Weise schnell den Grund dafür: Ist der Ping-Sensor „Down“, so liegt wahrscheinlich eine Unterbrechung in der physikalischen Verbindung zum Switch vor, und nicht etwa geänderte Einstellungen im Gerät, wie z.B. neu vergebene Zugangsdaten.
ABBILDUNG 11: Switch mit 31 automatisch erkannten Sensoren
Jeder Sensor nimmt sofort seine Tätigkeit zur Netzwerküberwachung auf. Die Daten werden in der Standardeinstellung in einem Intervall von einer Minute vom Gerät abgeholt. In der Geräteübersicht (Abbildung 11) kann der Administrator jederzeit alle verfügbaren Counter einsehen und weitere Details und Statistiken abrufen. Es werden auch Graphen erstellt, welche die Netzwerkaktivität übersichtlich darstellen (Abbildung 12).
ABBILDUNG 12: Detailansicht eines Sensors mit Graph (Live-Daten)
Alternativ können die MIB-Dateien des Herstellers verwendet werden
Für Geräte, bei denen die automatische Suche keine oder nicht alle SNMP-Objekte findet, können alternativ MIB-Dateien importiert werden, aus denen PRTG dann die nötigen Geräteinformationen bezieht. Hierfür werden die MIB-Dateien zunächst in eine „OIDlib“-Datei konvertiert, die PRTG ausliest.
Die Netzwerküberwachung erfolgt mit einer lokalen Sonde
PRTG wird über das Webinterface bedient; die eigentliche Netzwerküberwachung erfolgt jedoch mit einer so genannten „lokalen Sonde“. Das ist ein Windows-Dienst, der auf dem PC ständig im Hintergrund läuft und regelmäßig Daten von den Netzwerkgeräten
abruft. Die weiteren Sensoren „Sondenzustand“, „Laufwerk“ und die Sensoren für die Netzwerkadapter überwachen den Sonden-PC und geben dem Administrator die Möglichkeit, frühzeitig eine Überlastung zu erkennen. Dies würde sich mit einer hohen Prozessorlast bemerkbar machen, einer großen SNMP-Intervallverzögerung, sehr viel belegtem Arbeitsspeicher, einer vollen Festplatte oder besonders viel Traffic an der Netzwerkkarte. All diese Probleme erkennt das System selbstständig, damit der
Administrator gegebenenfalls Scanning-Intervalle oder die Menge der vorgehaltenen Daten verringern kann.
Berichte der gesammelten Daten erstellen
Im Laufe der Zeit werden eine Menge historischer Daten gespeichert, welche mit einer Funktion zur Berichterstellung ausgegeben werden können und somit einen Überblick über die Netzwerknutzung über einen bestimmten Zeitraum hinweg geben. In der Freeware-Version kann PRTG mit einer limitierten Anzahl von Sensoren betrieben werden. Für größere Projekte stehen die zeitlich begrenzte Trial-Version oder die Commercial Edition zur Verfügung.
SNMP weiterhin Standard
Das Whitepaper zeigt praxisnah auf, wie vielseitig SNMP eingesetzt werden kann—gerade auf Grund seiner Simplizität und trotz mancher Unzulänglichkeiten. Kennt der Administrator die wichtigsten Hürden bei der Einrichtung, so kann er mit Hilfe dieses Protokolls recht schnell ein effektives Netzwerk-Monitoring für seine Geräte und Computer einrichten. Eine geeignete Monitoring-Lösung unterstützt ihn hierbei, minimiert den Einrichtungsaufwand und bietet darüber hinaus durch eine statistische Aufbereitung der aufgezeichneten Überwachungsdaten einen großen Mehrwert.