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

TeamViewer goes IoT [19.01.2018]

TeamViewer bringt TeamViewer IoT auf den Markt. Die Software kombiniert die Fernzugriffs- und Fernsteuerungsfunktionen von TeamViewer mit Monitoring-Funktionen. TeamViewer IoT unterstützt Raspbian, kann aber laut Hersteller problemlos auf andere Linux-Distributionen portiert werden. An der Unterstützung weiterer IoT-Plattformen würde bereits gearbeitet. [mehr]

Alles unter einem Dach [30.11.2017]

Von Hewlett Packard Enterprise kommt mit 'HPE OneSphere' eine Multi-Cloud-Management-Lösung für Public Cloud, Private Cloud und Software-definierte Infrastrukturen. Das SaaS-Portal gibt Kunden einen einheitlichen Zugang zu einem Pool von IT-Ressourcen, der sowohl externe Cloud-Plattformen als auch die eigene, lokal betriebene IT-Umgebung umfasst. [mehr]

Tipps & Tools

Granulare Zeitpläne für PRTG [18.02.2018]

Aus unterschiedlichen Gründen kann es beim Monitoring nötig sein, für verschiedene Zeitfenster die Überwachung zu pausieren. Wer mit PRTG arbeitet, dem bietet sich mit der Zeitplan-Funktion jedoch nicht die Granularität, Sensoren oder ganze Gruppen anhalten zu können - beispielsweise jeden zweiten Dienstag im Monat von 16:00 bis 18:00 Uhr. Es gibt jedoch eine andere Möglichkeit über ein spezielles Scheduler-Tool. [mehr]

ZFS-Mirror mit pfSense nutzen [21.01.2018]

Die Open-Source-Firewall pfSense unterstützt neben UFS auch das ZFS-Dateisystem. Seit pfSense Version 2.4 ist es möglich, bereits bei der Installation ein ZFS-Dateisystem zu erstellen und damit beispielsweise einen ZFS-n-Way-Mirror anzulegen. Dieser spiegelt die Daten wie bei einem RAID 1 auf alle installierten Festplatten. Bei der Installation von pfSense und für die Überwachung des Mirrors sind jedoch einige Dinge zu beachten. [mehr]

Buchbesprechung

Software Defined Networking

von Konstantin Agouros

Anzeigen