Netzwerk-Management Standards

Kommentieren Drucken
Teil 63 von 71 aus der Serie "Professionelle Datenkommunikation"
Alle Artikel der Serie "Professionelle Datenkommunikation":

Ohne Standards keine Kommunikation, ohne Standards kein Netzwerk-Management. Im Gegensatz zur Netzwerksteuerung in homogenen Welten, wie einem zentralen SNA-Netz kommen bei größeren LAN-Installationen ggf. viele Komponenten unterschiedlicher Hersteller zusammen und verbinden Stationen unterschiedlicher Herkunft. Das Management eines solchen heterogenen Systems basiert üblicherweise auf einer Management-Plattform. Diese benötigt Informationen von den Komponenten in einer standardisierten Form. Der wichtigste Standard in diesem Zusammenhang ist SNMP.

Mancher Leser wird sich sicherlich darüber wundern, dass die Management-Standards schon relativ alt sind und trotzdem heute noch die Grundlage aller wesentlichen Systeme bilden. Einerseits ist es so, dass es sehr lange gedauert hat, bis diese Standards definiert wurden. Andererseits hat sich aber nach der Einführung des Switchings bei den LANs auch nicht mehr viel geändert. Ob nun ein Netz die Datenpakete mit 10 Mbit/s. oder eintausend Mal schneller mit 10 Gbit/s. bewegt, ist aus der Perspektive des Netzwerk-Management-Systems zunächst unerheblich. Bei gleichlangen Paketen muss es nur ebenfalls eintausend Mal schneller arbeiten. Vergleicht man aber die heute für das Management verfügbare Hardware mit der von vor 20 Jahren, ist das unproblematisch. Wichtig ist aber, dass die Qualität der Datenaufbereitung ebenfalls Schritt halten kann, denn der Netzadministrator ist in den letzten 20 Jahren nur älter, aber nicht wesentlich schneller geworden. Diese Aufbereitung ist aber eine Aufgabe der Plattform selbst. Die Netzwerk-Management-Standards wie SNMP oder RMON sind lediglich dafür zuständig, die Daten von den einzelnen Komponenten in vereinheitlichter Form zu besorgen und sie der Management-Plattform zur Verfügung zu stellen.

Die Management-Plattform ist darauf angewiesen, von den unterschiedlichen Einrichtungen im Netz Informationen zu bekommen bzw. sich Informationen holen zu können. In den letzten Jahren hat es sich durchgesetzt, die Informations-Zubringer-Protokolle mit einem bestimmten Verarbeitungsmodell zusammen zu definieren. Allerdings wird dabei die Wichtigkeit der Zubringerprotokolle im Allgemeinen fürchterlich überschätzt. Wesentlich sind die auf den Plattformen bereitgestellten Netzwerk-Management-Anwendungen, die im Wesentlichen die in der letzten Folge dargestellten Aufgabenbereiche abdecken helfen. Die Zubringerprotokolle sind letztlich austauschbar, bei größeren Plattformen können sogar unterschiedliche Protokolle nebeneinander verwendet werden.

Die wichtigsten Standards sind heute SNMP und RMON aus dem TCP/IP-Umfeld. CMIP/CMIS aus der OSI-Welt hatte wie alle OSI-Protokolle eine Reihe von Startschwierigkeiten, die vor allem in der aufwendigen Implementierung begründet sind. So hat es sich bei den LANs nicht etablieren können.

Simple Network Management Protocol SNMP
Das Konzept von SNMP basiert im Wesentlichen auf einem Netzwerk-Management Programm (SNMP-Manager), welches z. B. auf einer Netzwerk-Management Workstation oder NMS (Network Management Station), implementiert ist und SNMP Agenten in den zu überwachenden Geräten. Die Implementierung des SNMP-Managers kann dabei in weiten Grenzen erfolgen z. B. als eigenständiges Gerät oder als Modul im Rahmen einer offenen, verteilbaren Multivendor-Netzwerk-Management Plattform. Dabei sind vor allem die zur Benutzeroberfläche gerichteten Funktionen relativ frei. So kann SNMP zwar Informationszulieferer für Zustandsanzeigen einer graphischen Darstellung des Netzes (Map) sein, durch die SNMP-Standards wird aber nichts über die Gestalt oder Bedienung einer derartigen Darstellung ausgesagt. SNMP ist eine Funktionensammlung zur Kommunikation zwischen Management-Station und Agenten, was letztlich daraus an Möglichkeiten für den Netzwerk-Manager erwächst, ist Sache der speziellen Implementierung.

Die Software-Architektur von SNMP ist sehr einfach: in einer Management-Station führen Management-Anwendungen Objekt-Management-Operationen auf den sog. SNMP Managed Objects aus. Das sind keine richtigen Objekte im Sinne einer objektorientierten Programmierung, man hat sich aber daran gewöhnt, Parameteransammlungen aus der MIB so zu nennen. Die eigentliche Kommunikation zwischen Manager und Agent geschieht wie oben ausgeführt, mittels der SNMP-Nachrichten. Diese wiederum benutzen das verbindungslose Protokoll UDP, IP und die Logische Netzwerkverbindung auf Schicht 2.

Die grundlegenden Dokumente zu SNMP sind:

RFC 1155: SMI (Structure of Management Information, Full Standard),
RFC 1156: MIB-I (Management Information Base Version I, Historical),
RFC 1213: MIB-II (MIB, Version II, Full Standard),
RFC 1157: SNMP (Simple Network Management Protocol, Full Standard).

Sie bilden die Referenz für alle SNMP-Systeme. Form und Speicherungen von Informationen in der MIB sind herstellerspezifisch und nicht vorgeschrieben. Als Minimum sind jedoch die Syntax und Semantik der MOs (Managed Objects) zu vereinbaren. Diese konkreten Beschreibungen bilden eine virtuelle Datenbasis, eben die MIB. Sie listet die Informationen, die von einem Agenten abgefragt werden können und enthält Pointer zum Auffinden der gewünschten Informationen. Allgemein verbindliche Objekte sind in der Standard-MIB (MIB-I oder MIB-II) festgelegt. Jeder Agent kann neben der Standard-MIB auch nicht standardisierte Objekte implementieren, sofern diese mit SMI konform gehen. SNMP ist also ein Oberbegriff für folgende drei Dinge:

  • das Protokoll SNMP,
  • die Structure of Management Information SMI, in der Regeln für die Struktur und die Notation der Management Information Base MIB festgelegt sind,
  • die MIB, in der die zu verwaltende Information beschrieben ist.

SNMP selbst ist ein verbindungsloses Protokoll, um den Aufwand seiner eigenen Implementierung zu verringern, und benutzt auch solche Protokolle, üblicherweise setzt es auf dem UDP/IP auf, dem verbindungslosen User Datagram Protocol der TCP/IP-Protokollfamilie. Sinn der Agenten ist die Bereitstellung wesentlicher Informationen für den Manager.

In der Kommunikation zwischen SNMP-Manager und SNMP-Agent werden folgende vier Protokoll-Elemente benutzt:

  • GET-REQUEST, GETNEXT-REQUEST,
  • SET-REQUEST,
  • GET-RESPONSE,
  • TRAP.

Die Request-Kommandos kommen vom SNMP-Manager. Eine SNMP-Management Workstation pollt ihre »Kunden«, die SNMP Agents in den zu überwachenden Einheiten, an. Die Agenten können nur mit Response antworten. Ein Trap ist eine Möglichkeit für einen Agenten, sich z. B. im Falle eines besonderen Ereignisses beim Manager bemerkbar zu machen.

Die von den Agenten zu behandelnden Geräte und Einrichtungen können äußerst unterschiedlicher Natur sein und ein sehr unterschiedliches Spektrum von Management-Parametern anbieten bzw. zur Steuerung und Beobachtung verlangen. In den Agenten werden Datenbanken, die sog. MIBs implementiert, die die wichtigsten und für das Management erforderlichen Daten enthalten. Neben der Standard-MIB haben sich im Laufe der Zeit viele weitere MIBs entwickelt, auf die wir gleich noch näher eingehen.

Mit GET-REQUEST erfragt der SNMP-Manager Werte von Variablen, die in der MIB des Agenten unterstützt werden. Dazu müssen die Variablen exakt angegeben werden. Der GETNEXT-REQUEST fordert ausgehend von einem beliebigen MIB-Objekt den im Agenten vorhandenen Nachfolger, was man z. B. für das Auslesen von Tabellen brauchen kann. Andererseits muß zwischen Manager und Agent Einigkeit über die Anordnung von Objekten bestehen, sonst gibt es ein heilloses Durcheinander. Dies erschwert die Implementierung von Agenten und Agenten MIBs und insbesondere die Verwendung unterschiedlicher Agenten unterschiedlicher Hersteller im Rahmen einer gemeinsamen Plattform.

SET-REQUEST weist einer Varibalen in einer MIB eines Agenten einen speziellen Wert zu. Auf diese Weise müssen auch Kommandos angestoßen werden, weil es keine Möglichkeit gibt, auf einem anderen Wege, z. B. direkt, Kommandos an einen Agenten zu schicken. Der SET-REQUEST ist Quell vieler Sicherheitsprobleme mit SNMP, da in der Anfangsversion die Kommunikation zwischen Agent und Manager kaum gesichert ist und deshalb auch irgendeine beliebige andere Station dem Agenten Parameter zusenden kann.

In einer Vorversion des SNMP gab es nur diese drei Kommandos. Man hat jedoch schnell erkannt, dass das permanente Anpollen von Agenten problematisch ist: bei zu langem Polling-Intervall bleiben Fehler gegebenenfalls zu lange unentdeckt und können sich ungünstig auswirken oder fortpflanzen. Bei zu kurzem Intervall verbraucht man einen zu großen Teil der Netzwerkkapazität. Bei funktionierendem Netz kann man davon ausgehen, dass bei fast allen Agenten fast immer fast alles »in Ordnung« ist. Diese Agenten immer anzupollen, um den zu »erwischen«, bei dem etwas nicht stimmt, ist unwirtschaftlich. Also hat man den TRAP-Mechanismus eingeführt, der es Agenten ermöglicht, in Fehlersituationen aktiv zu werden und an einen Manager eine Meldung zu senden. Auf das Pollen kann man aber dennoch nicht ganz verzichten, da ja ein Agent üblicherweise auf dem Gerät implementiert ist, für welches er Management-Informationen erzeugt. Fällt dieses Gerät ganz aus, kann der Agent auch keinen Trap mehr abschicken. Um also von einem Ausfall zu erfahren, muß ein (ergebnisloser) Poll durchgeführt werden.

Die MIB ist ein einheitlicher, hierarchisch aufgebauter, protokollunabhängiger Raum für Datenobjekte. Die MIB I enthält mehr als 160 Objekte in acht Gruppen:

  • System-Group,
  • Interface-Group,
  • Adress-Translation Group,
  • IP-Group,
  • ICMP-Group,
  • TCP-Group,
  • UDP-Group,
  • EGP-Group

und ist damit völlig auf die Bedarfe von Knotenrechnern im Internet abgestimmt.

ICMP und IGP sind Protokolle der TCP/IP-Protokollfamilie, die bei größeren oder zusammengeschalteten Netzen benötigt werden. Die Systemgruppe beinhaltet Identifikationsmerkmale des Systems und die Interface-Gruppe Anzahl und Art der Schnittstellen. Alle Objekte in der MIB werden einheitlich in ASN.1, der Abstract Notation Syntax One, die ursprünglich für die Definition abstrakter Transfersyntaxen in der Datendarstellungsschicht des OSI-Modells entworfen wurde, fomuliert, wodurch eine Normung der abstrakten Darstellungen gegeben ist. Objekte in ASN.1 können ggf. später auch von anderen Management-Protokollen benutzt werden.

Die MIB I reflektiert wie bereits gesagt, Protokolle des Internet. Dies ist für die meisten privaten Netze wie LANs aber nicht besonders interessant, wenn man z. B. Brücken, Router oder Server im Netz überwachen möchte. Deshalb verfolgt man das Konzept der privaten Erweiterungen. Sowohl ganze MIBs als auch Äste in Standard-MIBs können durch private, z. B. herstellerabhängige Definitionen erstellt bzw. ergänzt werden.

Dies hat in der Vergangenheit zunächst zu einer sehr hohen Zahl unterschiedlicher MIBs und Erweiterungen der Standard-MIB geführt. Dabei trat schnell das Problem auf, dass jeder Hersteller möglichst viel Information und viele Parameter für seine speziellen Produkte in eine MIB integrierte, die anschließend zu einer möglichst hohen Funktionalität der Management-Anwendungsprogramme auf einer von diesem Hersteller angebotenen Netzwerk-Management-Plattform führen sollten. Solange man bei einem Hersteller bleibt, ist dies sicher unproblematisch. Anwendungen auf einer Management-Station eines anderen Herstellers waren aber vielfach nicht in der Lage, die speziellen Parameter der herstellerspezifischen Erweiterung zu sehen oder mit ihnen zu arbeiten.

Glücklicherweise hat der Markt schnell erkannt, dass auf diese Weise kein Fortkommen im Hinblick auf eine herstellerneutrale Multivendor-Netzwerk-Management-Plattform möglich ist. Unter vielseitigem Druck haben sich die Hersteller mittlerweile etwas von ihrer Proprietät gelöst. Man kann die Integration heute auf verschiedene Art und Weise betreiben:

  • Erstellung von Konvertern,
  • Schaffung weiterer Standard-MIBs für wesentliche Grundfunktionen,
  • Portabilität von Management-Anwendungen, die spezielle Funktionen und Parameter benötigen, auf offene Multivendor-Plattformen.

Alle diese Methoden werden heute benutzt. Wer z. B. ziemlich viele Brücken eines Herstellers und nur wenige Router eines anderen Herstellers besitzt, und darüber hinaus noch nicht allzu viel mit SNMP steuert, wird das Management-System der Brücken mit einem Konverter auch zur Steuerung der Router benutzen wollen.

Sonderveranstaltung


Das PSTN stirbt: Die neue Kommunikation mit SIP/IP 09.10.2017 in Bremen


Die Deutsche Telekom hat angekündigt, bis 2018 das klassische PSTN-Netz, respektive analoge und ISDN-Anschlüsse abzuschalten. Dies betrifft alle Unternehmen, die weltweit kommunizieren wollen und müssen. Diese Sonderveranstaltung analysiert, wie der Wechsel von PSTN auf All-IP im Unternehmen verläuft. Sie zeigt auf, welche Funktionalität heute erreicht werden kann und mit welchem Aufwand für Anpassung und Fehlersuche zu rechnen ist.
Zur Veranstaltung»

Die Schaffung weiterer Standard MIBs ist ein wichtiger Weg zur Erschließung neuer, bisher nicht implementierter, Management Funktionen. So wurde z. B. 1992 die RMON-MIB verabschiedet, RMON steht für Remote Monitoring. Die RMON-MIB gestattet den unkomplizierten dauerhaften Einsatz von Analysatoren in einem SNMP-Umfeld. Die am Netz befindlichen Analysatoren liefern permanent Daten über Zustände und Bewegungen eines LAN-Subsystems bezogen auf die Funktionen der OSI-Schichten 1 und 2 sowie des Übertragungsmediums und der Komponenten des Übertragungssystems an eine SNMP-Management Station. Die wichtigsten Hersteller unterschiedlicher Analysatoren konnten sich auf den RMON-MIB-Standard einigen und so den flexiblen integrierten Einsatz ihrer Geräte in SNMP gesteuerten Netzen ermöglichen.

Die bekannten unabhängigen Multivendor Netzwerk-Management-Plattformen wie HP Open View oder Sun Net Manager basieren in der Regel auf UNIX-Systemen, wenn auch auf unterschiedlichen Versionen des Betriebssystems. Offenheit und Modularität dieser Plattformen erleichtern die Implementierung von Management-Anwendungen durch Dritte. Da in der Zukunft ohnehin mehrere Netz-Management Protokolle koexistieren werden, ist die Modularität einer Plattform die wichtigsten Anforderung schlechthin.

Wichtig für größere Netze ist die Möglichkeit, über die MIBs unterschiedliche Perspektiven auf das gleiche Gerät zu ermöglichen. Man definiert zunächst „Communities“, die aus einem oder mehreren Administratoren besteht und dann „MIB-Views“, die für jede Community festlegt, was diese dort sehen und beeinflussen darf.

Eine weitere Möglichkeit in SNMP ist die Schaffung von Proxy-Agenten, die es einer Management-Station erlauben, Netzwerk-Elemente zu beobachten und zu kontrollieren, die die SNMP-Spezifikation nicht implementiert haben.

« Teil 62: Methoden der Integration von Management-InstrumentenTeil 64: RMON: Remote Monitoring »


zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.