Genereller Ablauf bei SNMP-DPI-Kommunikation

Grundsätzlich beinhaltet die Welt, in der sich die weiteren Ausführungen bewegen drei verschiedene Komponenten: einen Manager, einen Agenten (eventuell auch mehr) und einen Subagenten (auch hier eventuell mehr). Zuerst betrachten wir hier nur den Manager und den Agenten. Das Wesen des Agenten ist es, Information in Form von Variablen bereitzustellen. Diese Variablen können vom Manager abgefragt werden. Dies geschieht in unserem Fall mittels SNMP (Simple Network Management Protocol). Welche Variablen von einem Agenten angeboten werden und welchen Typ sie besitzen, erfährt der Manager aus der speziellen MIB zu jedem Agenten. Typischerweise kann ein Manager mehrere Agenten abfragen.

Da dieses Verfahren bis hierher recht statisch ist, versucht man das Ganze etwas flexibler zu gestalten. Man führt Subagenten ein. Diese wiederum bieten auch Variablen mit Informationen an. Sie werden aber nicht direkt vom Manager abgefragt, sondern erweitern den Leistungsumfang eines Agenten. Wenn ein Manager also eine Variable eines Subagenten abfragen will, bittet er den Agenten darum. Dieser leitet die Anfrage über DPI an den Subagenten weiter. Es geht dabei sogar soweit, daß der Manager nicht weiß, ob die Variable vom Agenten oder von einem Subagenten stammt. Da sich Subagenten sehr einfach während der Laufzeit an einen Agenten ,,anhängen`` lassen, wird der Leistungsumfang eines Agenten dynamisch erweiterbar [3].

Angenommen der Manager und der Agent laufen beide und stehen schon in Verbindung miteinander und man will einen Subagenten zum Agenten anhängen. Dann muß der Subagent zuerst vom Agenten erfahren, auf welchem Port dieser bereit ist, eine DPI-Verbindung aufzubauen. Dazu schickt er ein spezielles SNMP-Packet an den Agenten. Dieser gibt einen Port zurück, auf dem die weitere Verbindung unter DPI stattfinden soll.
Auf diesem Port stellt nun der Subagent zum Beispiel eine TCP-Verbindung zum Agenten her. Anschließend verschickt der Subagent ein OPEN-Request unter DPI auf diesem Port. Damit übermittelt er den Wunsch, als Subagent unter dem Agenten ,,dienen `` zu dürfen. Er übermittelt mit diesem Open-Packet auch einige Parameter für die weitere Kommunikation. Dazu gehört zum Beispiel eine Time-out-Grenze, ein Maximum auf einmal anfragbarer Variablen, usw. .
Wenn der Agent das OPEN-Request positiv beantwortet, muß sich der Subagent registrieren, um weitermachen zu können. Registrieren heißt, er gibt an, welche Variablen er zur Verfügung stellt. Dazu meldet der Subagent die Wurzel des Baums der von ihm verwalteten Variablen.

Wurde auch das REGISTER-Request angenommen, so ist der Initialisierungsteil abgeschlossen. Der Subagent wartet nun typischerweise auf Anfragen des Agenten, die dieser wiederum vom Manager gestellt bekommen hat. Das heißt also, daß der Subagent ab jetzt nur noch mit dem Agenten kommuniziert. Der Agent wiederum dient nur als Verteiler der Nachrichten des Managers und des Subagenten. Deshalb wird in der weiteren Ausführung nur die Kommunikation zwischen dem Agenten und dem Subagenten betrachtet.
Anfragen, die auf den Subagenten zukommen können sind:

• ein GET-Request. Das GET-Request bedeutet, daß der Agent den Wert einer Variablen lesen möchte. Wenn der Subagent für diese Variable verantwortlich ist, muß er den Wert in einem Response-Paket zurückgeben. Falls er nicht verantwortlich ist, schickt er ein Error-Paket zurück.
• ein GETNEXT. Beim GETNEXT-Request bezeichnet der Agent, wie beim GET-Request eine Variable. Im Unterschied zum GET-Request interessiert er sich aber nicht für den Wert dieser Variablen, sondern für die Bezeichnung und den Wert, der in der MIB-Hierarchie nächsten Variable. Gibt es in der MIB-Hierarchie keine nächste Variable mehr, so wird kein Fehler, sondern ein EndOfMib als Typ der Variable versand. Diese Methode ist sinvoll, um sich durch eine unbekannte MIB zu ,,hangeln `` oder um um Tabellen zu lesen.
• ein SET-Request. Ein SET-Request gibt an, daß der Agent den Wert einer Varibalen vom Subagenten setzen möchte. Zu diesem Zeitpunkt soll die Variable aber noch nicht gesetzt werden, obwohl ihr Wert schon mitgeliefert wird. Der Subagent soll nur schon alle Vorkehrungen für ein schnelles Setzen treffen. Wenn der Subagent die Vorkehrungen getroffen hat, muß er den Erfolg mittels eines Response-Pakets an den Agenten melden. Anderenfalls muß er ein Error-Paket an den Agenten schicken.
• ein UNDO-Request. Ein UNDO-Request zeigt an, daß der Agent die angekündigte Änderung doch nicht durchführen will. Der Subagent soll alle getroffenen Vorkehrungen rückgängig machen. Hat der Subagent dies erfolgreich durchgeführt, so muss er ein erfolganzeigendes Response-Paket an den Agenten schicken. Anderenfalls sendet der Subagent ein Error-Paket.
• ein COMMIT-Request. Bei einem COMMIT-Request muß der Subagent die Variable setzen. Ist dies nicht erfolgreich, so ist unbedingt ein Error-Paket an den Agenten zu verschicken. Bei Erfolg wird ein dementsprechendes Response-Paket übermittelt.

Der etwas umständlich anmutende Mechanismus zum Setzen einer Variablen hat durchaus seine Berechtigung. Man muß sich vor Augen führen, daß der Manager in einer geschlossenen Transaktion nicht nur eine Variable setzen will, sondern eventuell mehr und dies noch bei verschiedenen Agenten bzw. Subagenten. Wenn nun bei einem Agenten bzw. Subagenten ein Problem auftaucht, die anderen aber alle die Variablen setzen würden, könnte es zu Inkonsistenzen kommen. Dies versucht man, durch Aufteilung in eine Ankündigung und ein Durchführen zu verhindern.

Der Subagent kann nach dem Initialisierungsteil nicht nur Nachrichten vom Agenten empfangen, sondern er muß ihm auch welche schicken. Dazu gehört wie oben gesehen die Response-Meldung. Diese wird, bis auf wenige Ausnahmen, immer als Antwort einer Anfrage des Agenten verschickt. Der Subagent hat aber auch eine Möglichkeit eine Meldung an den Agenten zu schicken, ohne daß eine Anfrage notwendig war. Dies sind sogenannte TRAP's. Mit einem TRAP kann ein Subagent zum Beispiel einen Zustandswechsel an den Agenten, und damit an den Manager melden.

Wird der Subagent beendet, so schickt dieser ein UNREGISTER-Request an den Agenten. Hat dieser das UNREGISTER-Request angenommen, so schickt der Subagent ein CLOSE-Request. Da es auf ein CLOSE-Request keine Antwort gibt, kann sich der Subagent nun ohne zu warten beenden. Der Agent würde es auch mitbekommen, wenn der Subagent andersweitig beendet wird (KILL, Ctrl-C, Absturz) [8]. Im Zuge einer sauberen Programmierung, ist die Variante eines kontrollierten und definierten Ausstiegs aus der Kommunikation aber vorzuziehen.

Die Umgebung, in die der erstellte Subagent eingebunden ist, wird in der Abbildung auf Seite dargestellt.

  

Abbildung: Beziehungen des Subagenten zu seiner Umgebung

2#2