von Redaktion IT-A…
Lesezeit
3 Minuten
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.
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:
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.
Strukturierte 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
dr/ln/Martina Wittmann
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.
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.
Strukturierte 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 >> |
dr/ln/Martina Wittmann
