Dirk Quitschau

Thema der Diplomarbeit

Planung und Entwurf eines Systemkerns für ein Netzwerkmanagementsystem zur Erstdiagnose

Stichworte

SNMP, VoIP, MIB, QoS, Thread Zustandsautomaten, Tomcat, JSP, Servlets, Struts, Validator-Framework, Tiles-Framework

Kurzzusammenfassung

Diese Arbeit befasst sich mit der Planung und dem Entwurf eines Netzwerk Management Systemkerns, mit dem es ermöglicht werden soll, Datenreihen auf Basis von SNMP-Abfragen von entfernten Systeme abzurufen und zu protokollieren. Diese Rohdaten können im weiteren Verlauf durch unterschiedliche Auswertungen bearbeitet und in Form von Diagramme zusammengefasst dargestellt werden.

Durch die Auswahl von verschiedenen Systemparametern unterschiedlicher Systeme, die gemeinsam durch Diagramme visuell dargestellt werden können, lassen sich u.U. durch einfache Korrelationsbildung Rückschlüsse bezüglich eines möglichen Ursprungs von Problemen und Phänomenen in Netzwerken ziehen.

Das Programm bietet die Möglichkeit, unterschiedliche Datensenken zu nutzen, die in XML konfiguriert werden können. Die View-Komponente ist exemplarisch in webbasierten Javatechniken (JSP, Servlets) implementiert worden.

Dirk Quitschau

Title of the paper

Planning and designing of a system core for a network management system assisting at first-level diagnostics

Keywords

SNMP, VoIP, MIB, QoS, thread state machines, Tomcat, JSP, Servlets, Struts, Validator-Framework, Tiles-Framework

Abstract

In this work we report on the concept and design of a network management core system. This lightweight approach allows for collecting and persisting SNMP data from distant systems, data processing and charting, with the aim of visualizing correlated performance data. These visualizations of relations and correlations between network parts enables the operator to quickly draw conclusions on trouble causes and easily detect irregular phenomena within the network. The core opens up the option to employ different databases, which can be freely configured by xml. The view components has been exemplarily implemented in web based java techniques (JSP, Servlets).

2

Dokumentation   

Bachelorarbeit  CoVioN  

Inhalt   

Inhalt.............................................................................................................................................   3

1.  Einleitung.  4

2.  Anforderungen an ein Netzwerkmanagementsystem zur Erstdiagnose vor Ort.  5

3.  Wesentliche Techniken und Standards in Netzwerk-Managementsystemen.  8

3.1  SNMP.  8

3.2  Management Information Base (MIB)  14

3.3  Qualitäts- und Diagnoseparameter bei Voice over IP- Netzwerken.  17

4.  Ein anschauliches Netzwerkmanagement zur Unterstützung einer vor Ort Diagnose  24

4.1  Situationsbeschreibung möglicher Zielumfelder.  26

4.2  Ein Lösungsansatz mit Korrelationsbildung  27

5.  Funktionalitäten und Grundkomponenten für CoVioN  30

5.1  Userinterface.  31

5.2  Trapmanager.  32

5.3  SNMP Job- Verwaltung  33

5.4  Netzwerkknoten - Verwaltung.  37

5.5  MIB-Browser.  38

5.6  Weiterverarbeitung der SNMP-Rohdaten  39

5.7  Architektur des Cores  40

5.7.1  Schichtenmodell  40

5.7.2  Ansteuerung des Kerns  41

5.7.3  Klassendiagramme.  43

5.7.4  Sequenzdiagramme und Zustandsautomaten.  45

6.  Implementierung  48

6.1  Package-Organisation  50

6.2  Klassenbeschreibungen  51

6  3 Implementierungsbeispiel mit Java Server Pages (JSP) und Servlets  55

6.  4 Implementierungsbeispiel des Persistenz-Interface mit db4Objects und MySQL.  59

7.  Durchgeführte Testszenarien an CoVioN.  63

8.  Zusammenfassung und Ausblick  65

A  Literaturverweise und Links  66

3

1. Einleitung

Aus heutiger Sicht bilden Netzwerke einen Großteil der Kommunikation in einem Unternehmen ab. Das Internet wird zur Informationsbeschaffung genutzt und dient häufig sogar als einzige Anbahnung von Geschäftsprozessen, wie z.B. bei einem Online-Shop. Allen kommunikativen Prozessen liegen Systeme zugrunde, deren Ausfall von wirtschaftlichen Verlusten und oft auch dem Verlust von Prestige begleitet wird.

Managementsysteme werden seit langem im Kontext mit aktiven Netzwerkkomponenten genutzt, da diese oftmals über Standards wie SNMP (simple network management protokol) und zusätzlich über propritäre Systemansteuerungen verfügen.

Die Telefonie über die Internetprotokollfamilie, kurz VoIP, nimmt ebenfalls immer größeren Stellenwert in der Kommunikationstechnik an. Allerdings findet sie ihre Anwendung weniger im privaten Bereich, sondern wird eher in unternehmenseigenen Netzwerken genutzt. Die Vorteile einer preiswerteren Infrastruktur, die höhere Flexibilität im Betrieb paketvermittelnder Dienste und der unkomplizierten Integration in die heutige Bürokommunikation, haben sich viele Unternehmen schon überzeugen lassen VoIP einzuführen.

Mit den leitungsvermittelnden Telefontechniken prägten Qualitätsanforderungen, tritt automatisch auch ein äquivalenter Anspruch an die Qualität gegenüber den paketvermittelnden Techniken in Vordergrund. Es wird versucht mit dem Einsatz von QoS diesem Anspruch gerecht zu werden. Mit unterschiedlichen Ansätzen soll die Qualität von Punkt zu Punktverbindungen mit Qualitätsmerkmalen zu versehen werden, wie z.B. einer bevorzugten Behandlung vorrangiger Pakete in einer Routerqueue.

Bei allen Überlegungen, die die Kostenreduzierung in den Vordergrund stellen, soll hier auch auf die Gefahren hingewiesen werden, die eine Zusammenführung von Sprache und Daten auf einem gemeinsamen Medium mit sich bringt. Wurden vor einer Umstellung noch zwei getrennte Netze genutzt, die einander im Notfall teilweise ersetzen konnten, steht danach nur noch ein Netz zur Verfügung und es kommt damit zu einer gesteigerten Abhängigkeit von Diensten. Die essentielle Frage bei Verwendung eines solchen Systems ist somit, wie einem Ausfall von Komponenten entgegenzuwirken ist. Oft steigt der Preis bei maximaler Ausfallsicherheit durch die Anschaffung zusätzlicher Hardware überproportional an, wie z.B. bei redundant ausgelegten

4

Anlagen. Eine Sekundäranlage überwacht die Funktionsweise der Primäranlage, um bei einer Störung Teilfunktionen oder die gesamte Funktion zu übernehmen.

Die Kosten könnten jedoch auch dadurch stark reduziert werden, dass anstelle von redundant ausgelegenem Anlangen die Wartungszeit bei Ausfällen möglichst gering gehalten wird. Ein Ansatz kann hierbei sein, das Wartungspersonal mit unterstützender Software bei der Fehlersuche auszurüsten, die eine geringere Einarbeitungszeit in das vorhandene Netzwerk gewährleistet und eine effektive Hilfestellung bei der Fehlereingrenzung bietet. Ein System zu administrieren, welches auf IP Strukturen aufsetzt, erfordert meist einen Überblick über zusammenhängende Komponenten. Eine Fehlersuche bei paketvermittelnden Systemen beschränkt sich nicht nur auf die simple Verfolgung von Punkt-zu-Punkt-Verbindungen in einem zentral gesteuerten System. Vielmehr kommen die Problemstellungen von Verteilten Systemen zum Tragen und eine Fehlerquelle aufzuspüren wird komplex. Bei einer Diagnose liegt der Schwerpunkt beim komplexen Komponenten- und Ereigniszusammenspiel. Ziel dieser Ausarbeitung soll ein System sein, welches einem Servicetechnikers bei der Erstdiagnose behilflich sein kann und Möglichkeiten bietet, Standardausfälle möglichst schnell zu entdecken und anschließend beheben zu können. Hierbei sind stetige Protokollierungsmöglichkeiten genau so wichtig, wie eine individuelle Datenerfassung von Systemparametern, die bei einer Langzeitüberwachung Aufschluss über sporadisch auftretende Fehlerquellen geben können.

Im weiteren Verlauf dieser Arbeit wird zunächst auf die Anforderungen eines Netzwerk Management Systems eingegangen und auf die wichtigsten Techniken, die im Zuge von Netzwerkmanagement standardisiert worden sind. Um die vordergründige Idee dieser Arbeit zu beschrieben werden der Ansatz der Korrelationsbildung von Datenreihen und das mögliche Zielumfeld des Systemkerns beschrieben werden.

Einen tieferen Einblick in den Systemkern CoVioN werden die Kapitel 5 und 6 gewähren, die darüber hinaus Aufschluss darüber geben werden, welche Funktionalitäten das Komponentendesign von CoVioN beinhalten wird. Auszüge der Implementierung sollen hierbei dem weiteren Verständnis dienlich sein.

2. Anforderungen an ein Netzwerkmanagementsystem zur

Erstdiagnose vor Ort

Zunächst soll eine Möglichkeit geschaffen werden, um Daten von Systemparametern in regelmäßigen Abständen zu erfassen, um sie später in Graphiken, bzw. Diagramme darzustellen.

5

So können Zusammenhänge visuell erfasst werden und unter Korrelationsbetrachtungen zu Lösungsansätzen führen. Die Nutzdaten werden aus SNMP-Anfragen generiert, um im nächsten Schritt persisiert zu werden. Der Anwender erhält nun die Möglichkeit, die Daten unverändert in einem Diagramm darzustellen oder aber vorher mit verarbeitenden Auswertungen vorzuverarbeiten, um neben den Daten noch statistische Werte anzeigen zu lassen, wie z.B. die Werte einer kontinuierlichen Mittelwertbildung.

Komponenten, die in ihrer Funktion nicht zufriedenstellend arbeiten, würde man einer Langzeitüberwachung von Systemparametern unterziehen. Unterstützt durch graphische Darstellungen von Datendurchsätzen unterschiedlicher Interfaces wären so eventuelle Ressourcen-Engpässe oder burstartige Belastungen, durch simple Korrelationsbildung der Graphen erhebbar. Mit den Ergebnissen ließe sich eine Argumentationskette bilden, um bestimmte Phänomene in einem Netzwerk erklärbar zu machen. Zusätzlich dazu stellen die Erzeugnisse eine Hilfestellung dar, die bei Beseitigungen unterschiedlicher Problematiken zu Rate gezogen werden können. Der Techniker wird durch die Protokolle des Tools bei einer schriftlichen Ausarbeitung seines Servicefalles unterstützt.

Beispiel:

Die Mitarbeiter einer Firma beklagen sich über eine sehr langsame Verbindung zum Internet. Dies kann mehrere Ursachen haben. Zum einen besteht die Möglichkeit, dass die Router-Queues ständig voll sind, z.B. durch Viren oder Würmer im Intranet, oder aber die Verbindung zum Provider wäre mit hohen Paketverlusten belastet. Beide Fälle könnte man mit Hilfe von SNMP-Anfragen an den Router herausbekommen. Eine Möglichkeit könnte es hierbei sein, den Counter zu beobachten, der in der Mib-2 genau das Resetvorkommen von TCP mitzählt.

Wenn man von einem fest installierten System beim Kunden vor Ort ausgeht, hätte man durch eine clientseitige Konfiguration die Möglichkeit geschaffen, so genannte Traps zentral zu erfassen, um somit Zusammenhänge im Netzwerk besser nachvollziehen zu können. Daten, die durch Auswahl von Systemparametern über eine bestimmte Zeit protokolliert werden, können auf unterschiedlichste Art weiter verarbeitet werden. Dabei ist es möglich, über eine simple Gegenüberstellung hinaus zu gehen. Nutzt man die mathematischen Vorgehensweisen der Korrelationsbildung, ließen sich hiermit Indizien erschließen, die einen Verdacht einer Verkettung von unterschiedlichen Systemphänomenen erhärten ließe.

6

Für den Korrelationskoeffizient gilt:

Bei einem Vergleich von Datenreihen ließe sich für r eine Aussage darüber treffen, wie sehr Datenreihen einander korrelieren. Es gestaltet sich ein Wertebereich für r in der Form:

In der Interpretation wären Wertereihen, die sich dem Wert r=1 annähern, sich bedingende Systemparameter (wenn a steigt, steigt auch b). Im Gegenzug wären Werte, die sich gegen r=-1 annähern, ein Hinweis dafür, dass sich Systemparameter gegensätzlich verhalten (wenn a steigt, sinkt b und umgekehrt). Um eine graphische Übertragung einer Aussagekraft zu erreichen, ließe sich die Regressionsgrade in die Diagramme integrieren, für deren Ermittlung folgende Rechenvorschrift gilt:

Mit dieser Betrachtungsweise könnte erhält man die Möglichkeit Fehlerquellen besser in einem verteilen System entdecken zu können, wie folgendes Beispiel illustrieren soll:

Abbildung 1: Beispiel zur Korrelationsbetrachtung

7

Entdeckt man beispielsweise in der Verbindung von System B nach System C, dass beim System B der Packetloss auf dem angeschlossen Interface stark zunimmt und beobachtet dabei, dass das selbe Phänomen zu der Zeit auch auf der Strecke zwischen System A und C auf dem Interfaces des Systems A stattfindet, lässt sich vermuten, dass der Fehler für diese ungewünschten Verhaltensweisen beim System C liegt. Eine Korrelationsbildung der Interfaces des Systems A und des Systems B könnte den Hinweis hierfür liefern.

3. Wesentliche Techniken und Standards in Netzwerk-

Managementsystemen

3.1 SNMP

SNMP (Simple Network Management Protokoll) reiht sich in eine Reihe von Protokollen ein, die es schon lange gibt, jedoch nie an Lebendigkeit eingebüßt haben. Es wurde bereits 1980 in der Version 1 standardisiert und 1998 zu einer Version 2 weiterentwickelt. Ein weiterer Schritt in Richtung Sicherheit und Authentifizierung von Managementsystemen wurde mit der Version 3 im Dezember 2002 unternommen.

Die Unterschiede der einzelnen Versionen erstrecken sich von Erweiterungen in der MIB-Struktur, bis hin zu Änderungen bezüglich der Authentifizierung der Management-Applikationen an einem Agent. Wurde in der Version 1 die Authentifizierung noch über einen so genannten „shared key“ vorgenommen, der im Klartext über das Netz versendet werden musste, so wurde diese Sicherheitslücke schließlich in Version 3 durch diversen AAA Mechanismen (authentication, authorisation and accounting) endgültig geschlossen.

Die Architektur von SNMP ist ein Zusammenspiel von Netzwerk Management Systemen (NMS) und SNMP Agents. Hierbei wird die Kommunikation zwischen den Parteien mit SNMP-Messages vorgenommen. Die Graphik in Abb. 2 soll das Zusammenspiel kurz illustrieren:

8

Abbildung 2: SNMP-Architektur

Die Kommunikation mit SNMP besteht aus SNMP-GET/-GET-NEXT, SNMP-SET, Reply und SNMP-TRAP Messages, die in UDP eingebettet werden.

Abbildung 3: SNMP Paketaufbau

Eine SNMP-Message ist in drei Teile unterteilt:

Der verwendeten Versionsnummer, gefolgt vom community-String, der zur Authentifizierung von SNMPv1 und SNMPv2c verwendet wird, und so genannten protocol data units (PDU). In den PDU’s werden die unterschiedlichen Anfragen an den Agenten, dessen Antworten und die Traps kodiert.

An einem Beispiel soll kurz illustriert werden, wie beide Komponenten, der Agent und die NMS mit einander SNMP sprechen:

9

Abbildung 4: Darstellung eines SNMP-GET Request-Paketes mit dem Ethereal Packet Sniffer

In der oberen Abbildung 3 kann man erkennen wie das SNMP Protokoll aufgebaut ist. Als erstes finden wir die Version des Paketes (hier Version1), gefolgt vom Community String. Der angehängte PDU Teil splittet sich bei einer Anfrage auf in PDU Type (0=GET), einer Request-ID, einem Error-Status und Error-Index (beides bei Anfragen auf 0 gesetzt), dem Object-Identifier und einem Wert auf. Außerdem benutzt SNMP den UDP Port 161 für Requests, Responses hingegen unterliegen der Dynamik des Client-Ports (>1024). Die Management-Applikation besitzt die IP-Adresse 192.168.0.113, der Agent befindet sich auf einem Siemens Optipoint 410 mit der IP 114 desselben Subnetzes, einem VoIP-Telefon, welches die MIB-2 implementiert. Die Applikation stellt den SNMP-Request mit der OID 1.3.6.1.2.1.1.0 (Systembezeichnung) an das Telefon. Die Antwort sieht man auf der folgenden Abb. 5.

10

Abbildung 5: Darstellung eines SNMP Response-Paketes mit dem Ethereal Packet Sniffer

Die Antwort auf die SNMP Anfrage lautet „optiPoint 410 phone“. Wie man sieht stehen alle relevanten Daten in Klartext zur Verfügung. Vor der Paketstruktur änderte sich nur der PDU Type, dieser bekleidet den Wert 2 für die Markierung eines Response Paketes.

Es stehen mit dem SNMP Protokoll drei Schlüsseloperationen zur Verfügung:

GET und GET-NEXT

Ermöglicht der Managementapplikation eine Anfrage an den entfernten Agent zu stellen, wobei GET-NEXT zur Abfrage von Tabellen genutzt werden, deren Dimension der

Managementapplikation nicht bekannt ist. Hier wird die OID der Tabelle gesendet und als Antwort erhält man den Wert der nächsten OID, die dem Agenten bekannt ist. Mit GET-NEXT besteht somit die Möglichkeit durch einen Baum oder Teilbaum zu iterieren.

SET

Ermöglicht der Managementapplikation einen Wert in der MIB Tabelle des Agents explizit zu verändern. Dies geht nur, wenn die Entität in der MIB als read-write deklariert wurde.

11

TRAP

Ermöglicht dem Agent einer vorher konfigurierten Management-Applikation Events zu senden, um über systemeigene Ereignisse ungefragt zu unterrichten. Traps sind grundsätzlich Bestandteil von MIBs, die gesondert aufgeführt werden. Es wird jedoch der Vorschlag in RFC 1215 [7] gemacht grundsätzlich coldStart(0), warmStart(1), linkDown(2), linkUp(3), authenticationFailure(4) und egbNeighborLoss(5) als Hersteller zu definieren.

Die Aufgabenverteilung von Agenten ist von MIB zu MIB unterschiedlich aufwendig. Die Agents bilden über eigene Systemaufrufe einen Informationsbaum, eine so genannte „MIB“ (Management Information Base), auf die im folgendem Punkt 3.2 näher eingegangen werden soll. Die Informationen stellt es den Management-Applikationen zur Abfrage zur Verfügung. Die Agents haben die Aufgabe, ihre unterstützen MIB´s kontinuierlich mit Werten zu füllen und zusätzlich Traps an voreingestellte Netzwerk Management Systeme (NMS) zu senden, wenn bestimmte Ereignisse eintreten. Außerdem müssen sie Schreiboperationen, über SNMP-SET-Requests an ihrer Datenbasis verarbeiten können, was sehr umfangreich werden kann, da hier auch definierte Zugriffsrechte der MIB mit berücksichtigt werden müssen. Hinter den NMS befinden sich Applikationen, die diese Traps weiter verarbeiten. Bei der Datenerfassung seitens der Management Applikation hingegen, kann keine universell einsetzbare Lösung geboten werden. Jedes System hat ein individuelles Umfeld, Router unterschiedlicher Hersteller, Switche und andere Komponenten mit laufenden SNMP-Agenten. Somit muss ein Managementsystem immer von Einsatzgebiet zu Einsatzgebiet unterschiedlichen Anforderungsmerkmalen gerecht werden, bzw. dementsprechend konfigurierbar sein.

Da die für die Netzwerksicherheit von SNMPv1 (von 1988) wegen der in Klartext versendeten Community-Strings, immer ein Sicherheitsrisiko war, fand SNMP in dieser Version kaum seinen Einsatz in kommerziellen Netzwerken. Wegen dieser Schwäche von SNMP wurde 1993 von einer unabhängigen Gruppe zunächst das SMP (Simple Management Protokoll) entwickelt, welches nicht nur UDP und IP nutzte, sondern auch diverse OSI Protokolle und sogar Apple Talk unterstützte [28]. Die Entwicklung von SMP wurde von den Standardisierungsgremien von SNMP zum Anlass genommen, zwei Arbeitsgruppen ins Leben zu rufen. Eine war eher funktionsorientiert, die andere beschäftige sich mit der Umsetzung von sicherheitsspezifischen Themen. Ziel war es SNMP mit den Sicherheitsaspekten von SMP zu vereinigen, um so wieder einem genutzten Standard zu schaffen. Dies krönte schließlich mit dem SNMPv2c Standard, der

12

1996 in den RFC’s 1901-1908 ([9] - [16]) verabschiedet wurde. Es wurden neue Datentypen verabschiedet, sowie weitere Access- Klauseln für Zugriffe auf Objectidentifier-Instanzen, wie accessible-for-notify (ein Objekt, welches nur zur Benachrichtigung beschreiben wird) und readcreate (nicht nur verändern, sondern auch hinzufügen von Zeilen in einer Tabelle). Zudem wurden PDU-Types entwickelt, die allein der Management-Management Kommunikation dienen sollten. Der generelle Paketaufbau blieb derselbe. Mit dem PDU GET-BULK-Request wurde der Managementapplikation zusätzlich die Möglichkeit eingeräumt, eine vordefinierte Anzahl von Objekten gleichzeitig abzurufen. Hiermit gestaltete sich die Abfrage von ganzen Unterbäumen einfacher; wurde vorher für jedes Objekt ein eigener Request gesendet, konnten nunmehr Requests von ihrer Anzahl her und damit auch der SNMP-UDP-Verkehr minimiert werden. Da die Version SNMPv2c bei der Handhabung der Sicherheit letztendlich dieselbe communitystringbehaftete Strategie gewählt hatte, wie ihr Vorgänger (daher auch das „c“ in SNMPv2c), wurde bereits im März 1997 eine neue IETF Gruppe gegründet, die die Sicherheitsmängeln von SNMP mit einem durchdachten Konzept begegnen wollte. Bis zum Januar 1998 hatte diese Gruppe mehrere vorgeschlagene Internet-Standards produziert, die als RFCs 2271-2275 ([17] - [21]) veröffentlicht wurden. In den RFCs wurden die Versionsunterschiede von Dispatcherinstanzen verarbeitet und gesteuert, die im Wesentlichen die alte communitystringbehaftete Startegie, als auch die neuen Sicherheitslösungen berücksichtigten. Die neuen Sicherheitsmechanismen umfassten MD5, SHA1, DES und HMAC (hash message authentication code).

13

Folgende Abb. 6 und Abb. 7 illustrieren den Aufbau von SNMPv3-Managern und SNMP-Agenten, die in RFC 3411 vorgeschlagen werden.

Nach diesem Leitbild implementiert Mibble SNMP in seinem Package.

3.2 Management Information Base (MIB)

Die Management Information Base stellt eine Konvention von unterstützten Systemparametern dar, die ein Agent für ein System ermittelt und per SNMP-Anfragen der Außenwelt zur Verfügung stellt. Sie besteht im einzelnen aus Elementen, die Objekte strukturiert in Baumform zusammenfasst. Für das SNMP-Protokoll fungiert sie wie eine Datenbank. Zur Beschreibung der Elemente wird ASN.1 (abstract syntax notation one) verwendet. Konstrukte und Datentypen sind in der SMI (structure of management information) standardisiert und festgelegt. Man verwendet ASN.1 bei der Beschreibung der MIB, um ein systemneutrales Instrument zu schaffen, welches von Softwarekomponenten zunächst interpretiert und verstanden werden muss, bevor man auf Systemobjekte über SNMP zugreifen kann. SMI ist in der RFC 1155 [5] beschrieben und umfasst

14