Seite 2 - Netzwerküberwachung mit SNMP (1)

Lesezeit
2 Minuten
Bis jetzt gelesen

Seite 2 - Netzwerküberwachung mit SNMP (1)

06.11.2017 - 00:00
Veröffentlicht in:
OIDs sind keine beliebig formatierten Adressen, sondern haben eine hierarchische Struktur, die graphisch in der Form eines Baumes dargestellt wird. Aus dieser Baumstruktur ergibt sich auch die Adresse der OIDs. Der abgebildete Baum zum Beispiel zeigt diejenigen Zweige an, entlang derer man zur MIB-2, einer Standard-MIB für das Netzwerkmanagement, kommt. Die Wurzel des Baumes ist oben.

Jeder Knotenpunkt hat einen Namen und eine Zahl. Je nach OID-Notierungsform steuern Name und/oder Zahl ihren Teil zur gesuchten OID-Adresse [1, 2] bei. Um also zum Beispiel zur MIB-2 zu gelangen, müssen Sie sechs Knotenpunkte passieren. In der am häufigsten genutzten Notierung mit Zahlen und Punkten als Trennzeichen ist die Adresse der MIB-2 folgende: 1.3.6.1.2.1. In der ASN.1-Schreibung wird der Weg bis zur MIB-2 nicht nur mit Zahlen, sondern auch mit den entsprechenden Knotennamen notiert:
{iso(1) identified-organization(3) dod(6) internet(1) mgmt(2) mib2(1)}
Von der Wurzel {} führt der Weg über die International Organization for Standardization (ISO) (1) zu den nach ISO/IEC 6523-2 identifizierten Organisationen (3), von da zum US Department of Defense (DOD) (6) bis zum Internet-Protokoll (1). Der Internet-Zweig ist ein sehr mächtiger Zweig des OID-Baumes, denn er umfasst den Großteil aller bestehenden OIDs. Er bietet insgesamt acht Unterknoten an, wobei der Bereich "IETF Management" die Nummer 2 und die MIB-2 wiederum dessen Kind (Child) Nummer 1 ist. In der MIB-2 sind alle wichtigen Standard-MIBs [1, 2] zum Netzwerkmanagement mit SNMP zu finden. Insgesamt hat die MIB-2 wiederum 228 Unterknoten, die ihrerseits wieder weiter spezifiziert sind und damit Kopf von vielen weiteren Unterverzweigungen zur MIB-2 sind. Einige bekannte MIBs der 228 MIB-2-Kinder sind beispielsweise system, interfaces, ip, icmp, tcp, udp, transmission und snmp.

Der IETF Management-Zweig (mgmt(2)) enthält die Standard-MIBs, die in der Regel in Requests for Comments (RFCs) der Internet Engineering Task Force (IETF) festlegt werden. Allerdings gehören nur etwa drei Prozent der OIDs zu diesem Zweig. Rund 92 Prozent aller OIDs stammen aus dem private-Zweig, also aus 1.3.6.1.4. Die Menge der OIDs im private-Zweig erklärt sich dadurch, dass es viele verschiedene Hersteller – derzeit über 46.000 gelistete Unternehmen und Organisationen – gibt, die viele verschiedene MIBs für ihre vielen jeweils spezifischen Geräte erstellen. Cisco-MIBs beispielsweise sind unter 1.3. 6.1.4.1.9 zu finden, Microsoft-MIBs unter 1.3.6.1.4.1.311 oder MIBs für Juniper-Geräte unter 1.3.6.1.4.1.2636. Das heißt auch, dass ab dem private-Knotenpunkt, also ab der Adresse 1.3.6.1.4, alle weiteren OID-Adressbestandteile weitestgehend herstellerspezifisch sind. Die Länge und Form der OID bestimmt im private-Zweig jeder Hersteller selbst. Cisco zum Beispiel vergibt für das Objekt "storageTextualConventions" in der MIB CISCO-ST-TC die OID 1.3. 6.1.4.1.9.12.999999, bei Juniper/NetScreen finden sich auch längere OIDs wie 1.3. 6.1.4.1.3224.13.1.1.4.171. OIDs können sogar bis zu 40 Tupel mit je einer beliebigen Anzahl an Ziffern lang sein.

Das Verhältnis von OIDs zu MIBs lässt sich analog mit dem Verhältnis von IP-Adressen zu DNS-Einträgen vergleichen: Auf Protokollebene wird die Adressierung über Nummern benutzt. Durch die Informationen in den MIBs beziehungsweise im DNS werden diese Adressen in für Menschen besser lesbare Namen umgewandelt und um Metainformationen, etwa zum Datentyp, erweitert. An der Anzahl der existierenden OIDs wird deutlich, dass der OID-Baum sehr mächtig ist, dass er eine Vielzahl an Objekten hierarchisiert und eine grafische Darstellung des gesamten Baumes mit allen Zweigen eine sehr große Herausforderung wäre. Ebenso wird klar, wie viele Objekte es in einem Netzwerk potentiell geben kann, die man mit SNMP überwachen und teilweise auch managen kann.

Seite 1: SNMP und Netzwerkmanagement
Seite 2: Aufbau von MIBs und OIDs

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. Im dritten Teil erklären wir, wie Sie die richtige SNMP-Version finden und was beim Monitoring mit SNMP dringend zu beachten ist.

<< Vorherige Seite Seite 2 von 2




dr/ln/Martina Wittmann

[1] www.iana.org/assignments/enterprise-numbers/enterprise-numbers
[2] www.iana.org/assignments/smi-numbers/smi-numbers.xhtml

Ähnliche Beiträge

Netzwerkverwaltung an der Medizinischen Universität Wien

Die IT-Abteilung der Medizinischen Universität Wien betreibt das Netzwerk der Universität, wozu die Betreuung von rund 10.000 Anschlüssen sowie Hunderten Endgeräten und Servern gehört. Für diese Aufgabe wurde eine neue Informations- und Planungssoftware für Kabelmanagement und Netzwerkdokumentation implementiert. Das neue Werkzeug ist flexibel, skalierbar und deckt die steigenden Sicherheitsanforderungen voll ab.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (3)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im dritten und letzten Teil gehen wir auf weitere Varianten ein, etwa die ZTP-Provisionierung ohne proprietären Server, die Boot-Loader-Variante iPXE oder das alte Verfahren AutoInstall.

Zero-Touch-Provisionierung von aktiven Netzwerkkomponenten (2)

Zero-Touch-Provisionierungsprozesse sind im Rollout von Client-PCs und Servern bereits lange Zeit Standard. Im Gegensatz dazu kommen diese Prozesse bei aktiven Netzwerkkomponenten wie Routern und Switches nur selten zum Einsatz. Im zweiten Teil der Workshopserie schildern wir den proprietären Cisco-Ansatz "Network-Plug-and-Play", der über eine GUI erfolgt und bei dem sich die ausgerollten Komponenten an die Gegebenheiten im Netzwerk anpassen lassen.