Fachartikel

Netzwerküberwachung mit SNMP (2)

Netzwerke sind in der Regel sehr heterogen aufgebaut und bestehen aus zahlreichen, verteilten Komponenten. Für Sie als Administrator bedeutet dies, den Überblick zu behalten, um zeitnah auf Probleme reagieren zu können, oder diese im Idealfall von vornherein zu verhindern. Mit dem Simple Network Management Protocol (SNMP) steht Ihnen hier ein erfahrener Begleiter zur Seite. Im zweiten Teil der Serie sehen wir uns an, wie die Datenübertragung mit SNMP strukturiert ist und wie damit die Kommunikation im Netzwerk erfolgt.
Mit SNMP steht Ihnen ein fest verwurzelter Begleiter bei der Überwachung des Netzwerks zur Seite.
Aufbau von MIB-Einträgen
Die überwachten Objekte werden in der MIB-Datei nicht nur mit einer eindeutigen Adresse, der OID, definiert, sondern auch mit einem Namen und den dazugehörigen Informationen über den Objekt-Typ, Zugriffsrechte und Beschreibung, zu welchem Zweck es das Objekt gibt. Als Beispiel soll hier ein Eintrag aus der sogenannten IFMIB (RFC 1213), der Interfaces-MIB, mit der Adresse 1.3.6.1.2.1.2 dienen. In der IFMIB werden insgesamt 100 verschiedene Interfaces betreffende Objekte definiert. Die IF-MIB enthält fünf Tabellen mit insgesamt 53 Tabelleneinträgen und 91 Objekte mit einer eigenen OID. Einer der Einträge mit eigener OID ist zum Beispiel der "ifPhysAddress"-Eintrag.

Möchten Sie zum Beispiel wissen, welche MAC-Adresse einem der Netzwerk-Interfaces in seinem Netzwerk zugrunde liegt, senden Sie eine entsprechende SNMP-Abfrage, die vom ifPhysAddress-Eintrag in der IF-MIB Gebrauch macht:
fPhysAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The interface's address at its protocol sub-layer. […]"
::= { ifEntry 6 }
Wichtige Infos in diesem Eintrag sind, dass die Interface-Adresse nur abgefragt und nicht etwa über SNMP gesetzt werden kann, da read-only. Das Objekt ist daher für die Überwachung gedacht und nicht zur Konfiguration. Außerdem enthält der Eintrag die OID des Objektes ifPhysAddress: 1.3.6.1. 2.1.2.2.1.6.

Dies geht aus der letzten Zeile "ifEntry 6" hervor, die bedeutet, dass die Adresse von ifPhysAddress die OID von ifEntry plus die Zahl 6 ist. Die Beschreibung enthält oft wichtige Informationen zur Interpretation von Werten und bei Standard-MIBs Implementierungsrichtlinien für Hersteller. Aufbereitet durch ein Tool wie etwa dem Paessler MIB-Importer können derartige MIB-Einträge, hier ifType, auch visualisiert werden.

Objekte können in MIBs als einfache Objekte (scalars) oder auch in Tabellenform (tables, tabulars) definiert werden. Tabellen werden dann eingesetzt, 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 CPU-Werte 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.

Eine SNMP-Walk durch die Tabelle "ifTable" mit der OID 1.3.6.1.2.1.2.2 aus der MIB2 zeigt, dass pro OID so viele Indizes vergeben werden, wie es überwachbare Interfaces auf dem Gerät gibt. Zum Beispiel steht 1.3.6.1.2.1. 2.2.1.1.3 für die OID des ifIndex 1.3.6.1.2.1. 2.2.1.1 mit Index [3] am Schluss. Für jede OID der ifTable wird pro Index ein bestimmter Wert zurückgeliefert (siehe Tabelle "ifTable 1.3.6. 1.2.1.2.2"). Damit nicht jede MIB-Datei die in ihr vorhandenen und verwendeten Objekte und Definitionen immer von der Wurzel des Baumes aus definieren und neu auflisten muss, gibt es einen Mechanismus für die Einbindung anderer MIB-Dateien in eine vorhandene Datei. In so einem Fall ist von importierten MIBs die Rede. Die MIB-2 (alias RFC 1213) beispielsweise importiert verschiedene Definitionen aus den MIBs RFC1155-SMI und RFC-1212. MIBs können dabei beliebig tief verschachtelt importiert sein.



S
trukturierte Datenübertragung
Sehen Sie sich den ifPhysAddress-Eintrag links genauer an, so erkennen Sie an der Struktur des Eintrages, dass ifPhysAddress ein sogenanntes OBJECT-TYPE-Konstrukt ist. Denn die Struktur enthält Informationen zu den Kategorien SYNTAX, MAX-ACCESS, STATUS und DESCRIPTION. Dass ein OBJECT-TYPE-Konstrukt immer genau diese Kategorien enthält, ist durch die sogenannte Structure of Management Information (SMI) definiert. Doch warum gibt es diese SMI – also eine Struktur für diejenigen Informationen, die mit Hilfe von SNMP durch das Netzwerk übertragen werden können?

Der Grund hierfür liegt in der Heterogenität der Netzwerke. Es gibt in einem Netzwerk verschiedene Computerarchitekturen, verschiedene Betriebssysteme und verschiedene Compiler, die Daten auf verschiedene Arten und Weisen speichern und repräsentieren. Viele Architekturen haben zusätzlich unterschiedliche interne Datenformate. Manche speichern beispielsweise Integer nach dem Big-Endian-Prinzip, mit dem signifikantesten Byte zuerst, andere nach dem Little-Endian-Prinzip, mit dem am wenigsten signifikanten Byte voraus.

Woher soll ein Dienst, der Daten auslesen soll, nun wissen, wie er das tun muss? Würde er bei jedem System einfach dieselbe Methode anwenden, wären die Ergebnisse nicht vergleichbar. Und auf welche Weise soll zum Beispiel ein SNMP-Agent eine Antwort mit einem Integer Count an die Überwachungseinheit schicken – in Little-Endian oder Big-Endian kodiert?

Die Lösung ist eine maschinenunabhängige, vom Betriebssystem unabhängige und von der Programmiersprache unabhängige Festlegung zur Beschreibung von Integern und anderen Datentypen sowie Regeln, die definieren, auf welche Art und Weise jeder Datentyp durch das Netzwerk und damit von einer Maschine zu einer anderen Maschine transportiert wird. Denn wenn das Format ein bekanntes Format ist, dann kann jede Netzwerkmanagementinformation empfangen und im benötigten Format abgespeichert werden.

Seite 1: Strukturierte Datenübertragung
Seite 2: Kommunikation im Netzwerk mittels SNMP


Seite 1 von 2 Nächste Seite >>
13.11.2017/dr/ln/Martina Wittmann

Nachrichten

Mobiles Drucken [29.05.2018]

ThinPrint bringt sein neues Produkt 'ThinPrint Mobile Print' auf den Markt. Mit der Software können Unternehmen iOS- und Android-Geräte in ihre bestehende Druckinfrastruktur einbinden und Mitarbeiter alle vorhandenen Netzwerkdrucker nutzen. Nutzerberechtigungen werden automatisch aus dem Active Directory oder dem Druckserver übernommen und können bei Bedarf für den mobilen Einsatz erweitert oder eingeschränkt werden. [mehr]

Bessere Einblicke in große Netze [24.05.2018]

SolarWinds kündigt Aktualisierungen für sein Portfolio an Netzwerkmanagement-Produkten an. Diese können laut Hersteller nun bis zu viermal größere Netzwerke unterstützen als die vorherige Generation. IT-Experten sollen so von einer deutlich flexibleren Skalierbarkeit zur Unterstützung großer Rechenzentrumsnetzwerke mit wachsenden Workloads profitieren, aber auch von flexiblen Möglichkeiten der horizontalen Skalierung für komplexe verteilte Netzwerke. [mehr]

TeamViewer goes IoT [19.01.2018]

Tipps & Tools

Vorschau Juli 2018: Asset- & Lifecycle-Management [25.06.2018]

Das Asset- & Lifecycle-Management bildet die Basis für viele wichtige IT-Management- wie auch kaufmännische Aufgaben. Im Juli-Heft widmet sich IT-Administrator diesem Schwerpunktthema und beleuchtet, wie Sie Software, Hardware und Clouddienste richtig im Auge behalten. Dazu zählt neben der Erfassung auch die passende Betriebs- und Systemdokumentation sowie die Einführung einer CMDB. Auch spielen neue Technologien wie RFID und IoT immer mehr in das Asset-Management hinein. In einem großen Vergleichstest beweisen derweil Spiceworks, OCS Inventory, GLPI und Snipe-IT ihr Können. [mehr]

Microsoft IIS absichern [1.06.2018]

Viele Unternehmen beschäftigen sich auch angesichts der Datenschutz-Grundverordnung intensiv mit der Härtung von Windows Server 2016. Als besonders unsicheres Einfallstor erscheint dabei der Webserver IIS. Doch es gibt Maßnahmen und Einstellungen, um hier für einen umfassenden Schutz zu sorgen. [mehr]

Buchbesprechung

Anzeigen