CoVioN - Correlation Viewer on Networkparts

Inhalt

1. Einleitung

2. Anforderungen an ein Netzwerkmanagementsystem zur Erstdiagnose vor Ort

3. Wesentliche Techniken und Standards in Netzwerk-Managementsystemen
3.1 SNMP
3.2 Management Information Base (MIB)
3.3 Qualitäts- und Diagnoseparameter bei Voice over IP- Netzwerken

4. Ein anschauliches Netzwerkmanagement zur Unterstützung einer vor Ort Diagnose
4.1 Situationsbeschreibung möglicher Zielumfelder
4.2 Ein Lösungsansatz mit Korrelationsbildung

5. Funktionalitäten und Grundkomponenten für CoVioN
5.1 Userinterface
5.2 Trapmanager
5.3 SNMP Job- Verwaltung
5.4 Netzwerkknoten - Verwaltung
5.5 MIB-Browser
5.6 Weiterverarbeitung der SNMP-Rohdaten
5.7 Architektur des Cores
5.7.1 Schichtenmodell
5.7.2 Ansteuerung des Kerns
5.7.3 Klassendiagramme
5.7.4 Sequenzdiagramme und Zustandsautomaten

6. Implementierung
6.1 Package-Organisation
6.2 Klassenbeschreibungen
6 .3 Implementierungsbeispiel mit Java Server Pages (JSP) und Servlets
6. 4 Implementierungsbeispiel des Persistenz-Interface mit db4Objects und MySQL

7. Durchgeführte Testszenarien an CoVioN

8. Zusammenfassung und Ausblick

A Literaturverweise und Links

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 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.

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.

Für den Korrelationskoeffizient gilt:

Abbildung in dieser Leseprobe nicht enthalten

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:

Abbildung in dieser Leseprobe nicht enthalten

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:

Abbildung in dieser Leseprobe nicht enthalten

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 in dieser Leseprobe nicht enthalten

Abbildung 1: Beispiel zur Korrelationsbetrachtung

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:

Abbildung in dieser Leseprobe nicht enthalten

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 in dieser Leseprobe nicht enthalten

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:

Abbildung in dieser Leseprobe nicht enthalten

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.

Abbildung in dieser Leseprobe nicht enthalten

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.

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 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 read- create (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).

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

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Achitektur eines SNMPv3 Managers

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Architektur eines SNMPv3 Agenten

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 Regeln zur Erstellung von Mibs. Mit SNMP v2 wurde die SMI in RFC 1902 [10] zu SMIv2 weiter entwickelt und blieb hierbei abwärts kompatibel, indem die alten Datentypen erhalten blieben, jedoch z.B. Counter mit weiteren Datentypen versehen wurden, die ab Version 2 auch eine Ausprägung von 64 Bit haben können. Es gibt nur zwei unterschiedliche Strukturen von Datentypen; Scalare und zweidimensionale Tabellen, die wiederum Arrays von Scalaren darstellen. Die SMI hat auch die Baumstruktur vorgegeben, in der die Objekte oder Unterbäume angeordnet werden müssen. So definierte sie unter iso(1)-org(3)-dod(6)-internet(1) vier untergeordnete Nodes (directory-1 für jegliche Namensdienste, mgmt-2 für Menagementdienste, experimental-3 für experimentelle Nodes, um z.B. Standards, die sich noch in einem Entwicklungszustand befinden, vorübergehend einordnen zu können, und private-4 für herstellerspezifische Applikationen). Unter mgmt hatte vor der Mib-2 die Mib-1 ihre Position. Sie wurde vom IAB (Internet Architecture Board) in Zuge der Weiterentwicklung vollständig durch die Mib-II ersetzt. An dieser Stelle soll kurz darauf eingegangen werden, wie die Baumstruktur sich nach SMI in der MIB-II verändern darf:

- Durch vollständige Ersetzung eines Subtree’s, wie es bei der Mib-1 durch Mib-2 geschehen war.
- Durch Erweiterungen der Blätter experimental und private
- Durch Ergänzung der MIB-II

ASN.1 beschreibt 28 unterschiedliche UNIVERSAL Typen, woraus SMI nur bestimmte Typen zur Beschreibung zulässt und zusätzlich mit eigener Nomenklatur versieht. Folgende Tabelle enthält eine Gegenüberstellung der Typen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Typen Gegenüberstellung ASN.1 und SMI

In RFC 1155 wurde weitere Datentypen verabschiedet, darunter networkaddress, ipaddress, counter, gauge, timeticks und opaque.

Hierbei ist es von Agenten nicht zwingend notwendig, dass alle Werte der MIB mit Werten gefüllt werden. Sollten Einträge nicht vom Agenten unterstützt werden, darf er sie mit Null-Werten füllen. Außerdem sieht die Architektur von SMI vor, dass Agenten je nach Community-String, Teilbäume sichtbar machen können oder READ / READ-WRITE Access damit verknüpfen - view based access. Hiermit können unterschiedliche Accessgruppen für jeden definierten Community-String definiert werden. Wie schon vorher erwähnt, sind MIB’s grundsätzlich in einer Baumstruktur organisiert, wobei sich hinter jedem Knoten eine andere Auskunft über das System verbirgt. In der folgenden Abbildung wird ein Ausschnitt der MIB-2 dargestellt, die im RFC1213 (Request for Comments,[6]) als Standard verabschiedet wurde.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Abbildung der RFC1213 MIB-II

Soll beispielsweise die Systembeschreibung wie im vorangegangenen Punkt 3.1 über den Baum erreicht werden, so concatiniert man die Werte der benötigten Knoten, um an das gewünschte Blatt zu gelangen. Daraus erschließt sich eine OID (Objekt-Indentifier), die in einen SNMP-GET- Request gesetzt werden kann.

In dem gezeigten Beispiel erreicht man die Systembeschreibung über iso(1)=>org(3)=>dod(6)=>internet(1)=>mgmt(2)=>mib-2(1)=>system(1)=>SysDescr(1), also lautet die OID für die Systembeschreibung in diesem Fall „1.3.6.1.2.1.1.1“. Um die Instanz hinter der OID zu erhalten, ist es bei scalaren Werten so, dass als Instanz Identifizierer die Null konkatiniert wird. Somit ergibt sich der Vollständige Anfragestring „1.3.6.1.2.1.1.1.0“.

In der oberen Abbildung, der Darstellung der MIB-2, kann man schon am Aufbau der Struktur erkennen, dass sich auf Höhe der Baumtiefe 1.3.6.1.x unter anderem der Knoten private(4) befindet.

Unter diesem Node können Anbieter ihre eigenen MIBs für ihre Systeme veröffentlichen, um z.B. ganz spezielle Aspekte ihrer Hardware über SNMP zur Verfügung zu stellen.

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

In einem VoIP-Umfeld sollte dem Wunsch nachgekommen werden, eine ständige Erreichbarkeit mit einer hohen Sprachqualität zu kombinieren.

Nur zu unterschiedlich sind die Arten, wie Daten in der paketvermittelnden oder bei PSTN übertragen werden. In der Paketvermittlung von IP gibt es mehrere Störfaktoren, die in der Natur des Protokolls liegen. So ist es z.B. so, dass für den Sprachcodec G.711 Pakete erzeugt werden müssen, die einer 8 Bit Datenbreite bei einer Abtastrate von 8 kHZ gerecht werden muss, wie es bei ISDN der Fall ist. IP kann nicht 8 Bit-Pakete mit 8 kHz versenden. Es werden mehrere Informationen zu größeren Paketen zusammengefasst um die Netzauslastung zu optimieren hinsichtlich Nutzdaten und Kontrolldaten. Zusätzlich kommt bei VoIP die Tatsache zum Tragen, dass auf beiden Seiten Codecs rechnen, um die Sprachdaten zu komprimieren (z.B. bei Sprechpausen). All dies trägt dazu bei, dass die Sprachqualität darunter leidet.

Die Vermittlung von IP-Paketen funktioniert zunächst unter dem „best effort“- Ansatz. Außerdem verlaufen aufeinander folgende IP-Pakete nicht zwingend entlang des gleichen Weges, um zum Ziel zu gelangen, so dass ein Endsystem auch mit der Sortierung der Paketreihenfolge beschäftigt wird, was ein Phänomen ist, welches nicht zwingend durch unterschiedliche Wegesuche zu belegen ist. Dies kann auch passieren, wenn Router in ihren Queues Pakete durcheinander bringen.

Im Gegensatz dazu haben wir in der PSTN-Technik fest geschaltete Verbindungen. Es müssen keine Bandbreiten oder Queues durchflossen werden; die Daten werden mit konstanter Bitrate und ohne spürbare Qualitätsverluste übermittelt.

Die Qualität von VoIP stellt Ansprüche an ein Netz, wie geringes Delays, geringer Jitter und geringen Packetloss, sowie dass Pakete in möglichst in chronologisch richtiger Reihenfolge beim Endsystem ankommt. Sonnst muss das Endsystem Pakete umsortieren (packet reordering).

Als Delay bezeichnet man die Verzögerungen der Signale in einem Netzwerk. Delays wirken sich, so lange sie gering sind nicht so sehr auf die Qualität der Sprache aus. Man veranschlagt pro gesprochene Silbe ungefähr 100 ms. Dies wird auch in VoIP-Systemen als oberstes Limit erachtet. Bei einem wechselseitigen Gespräch jedoch hätten die Parteien bei zu hohem Delay eventuell das Problem, dass sie sich gegenseitig ständig ins Wort fallen würden.

Als Jitter bezeichnet man die Varianz der Delays, mit denen VoIP-Daten beim Empfänger ankommen. Wenn alle Pakete in einem Netzwerk die gleiche Verzögerung hätten, würde keiner eine Abnahme der Qualität verspüren, solange nur einer spricht. Wenn die ankommenden Pakete in ihrer Verzögerung stark variieren, schlägt sich dies sofort an der Softwarekomponente nieder, die die digitalen Daten in Echtzeit zurück in analoge Daten umwandeln werden müssen (z.B. den Ton zu einer Bildersequenz). In ihr existieren Buffermechanismen, die dem Jitterproblem entgegenwirken sollen, so genannte Jitterbuffer. Mit ihnen wird versucht unterschiedliche Delays in die Länge zu ziehen, um damit den Jitter zu kompensieren. Es ist also zunächst festzuhalten, dass Jitter direkten Einfluss auf die Sprachqualität ausüben, da ihre Glättung ein höheres Delay mit sich zieht und die Buffer nicht beliebig groß sein können, um sie zu kompensieren.

Wenn Pakete bei der Übermittlung verloren gehen, spricht man von Packetloss. Dieser sollte in einem VoIP-Netzwerk unter 1% liegen. Wie schon bei der Erklärung des Einflusses von Delays erwähnt, nimmt man pro gesprochen Silbe ein At von 100 ms an. Zu hoher Packetloss führt also direkt zu Verlusten von Sprachanteilen beim Abspielen der Gespräche – die Qualität von VoIP leidet imens unter Packetloss.

Endsysteme müssen, bevor sie Pakete verwerfen sicherstellen, dass sie in der Richtigen Reihenfolge verarbeitet werden. Kommen Pakete in nicht chronologischer Reihenfolge an, können auch hier bis zu einem gewissen Grad Buffermechanismen, sie wieder in die richtige Reihenfolge bringen, dies bezeichnet man Packetreordering am Endsystem. Treffen allerdings Pakete zu spät ein, werden sie verworfen. Da wir beim Packetreordering wieder Buffer genutzt werden, zieht dies wieder ein höheres Delay mit sich.

Die Wahl des Protokolls bei VoIP ist meist RTP (real time transport protcol). RTP wurde 2003 in RFC 3550 [25] von Schulzrinne et al in der Version 2 veröffentlicht und basiert auf der Vorgängerversion 1, welche in RFC 1889 [8] definiert ist. Das Protokoll setzt hierbei auf UDP auf und beinhaltet zeitliche Relationen zwischen allen Paketen mittels Timestamps.

[...]