Fachbereich Informatik Department of Computer Science. Abschlussarbeit. im Bachelor Studiengang

Transkript

1 Fachhochschule Bonn-Rhein-Sieg University of Applied Sciences Fachbereich Informatik Department of Computer Science Abschlussarbeit im Bachelor Studiengang Konzeption und Implementierung eines Netzwerkprobes für den Einsatz im Netzlabor von Erstbetreuer: Prof. Dr. Martin Leischner Zweitbetreuer: Prof. Dr. Kerstin Uhde Eingereicht am:

2 Eidesstattliche Erklärung Hiermit erkläre ich, dass ich diese Arbeit selbstständig durchgeführt und abgefasst habe. Quellen, Literatur und Hilfsmittel, die von mir benutzt wurden, sind als solche gekennzeichnet. Brohl-Lützing, Seite I

3 Abstract Die Überwachung, Aufzeichnung und Auswertung von Netzwerkverkehr gewinnt durch die hohe Integration bestehender Dienste in die Datennetze immer mehr an Bedeutung. Die bestehenden Lösungen sind meist groß, teuer und unflexibel. Sie bieten keine Möglichkeit, eigene Anwendungen zu integrieren. Diese Arbeit soll einen universell einsetzbaren, frei konfigurierbaren Netzwerkprobe hervorbringen, auf dem neue Verfahren des Netzwerkmonitorings im Rahmen der Netzlabore der Fachhochschule getestet werden können. Der Schwerpunkt liegt im Formulieren von Anforderungen und Kriterien für das Gerät anhand theoretischer Betrachtung von Komponenten und Einsatzszenarien sowie Messung mit einem Referenzsystem. Nach der Hardwareauswahl mündet der Prozess in der Beschaffung. Die Leistungsfähigkeit der beschafften Hardware wird anhand einer Basisimplementierung verifiziert. Seite II

4 Inhaltsverzeichnis 1 Einleitung Motivation Umfeld Zielsetzung Aufbau Anforderungsanalyse Allgemeine Anforderungen Anforderungen durch das Netzlabor Grundüberlegungen Anbindungsszenarien Art der Messdaten Funktionale Monitoring-Szenarien Ausgelagertes SNMP Integriertes System Weitere Modelle Dimensionierung des Netzwerkprobes Theoretische Betrachtung Messungen Marktanalyse Auswahl der Hardware Implementierung mit ausgewählter Hardware Montage Betriebssystem Funktionstest Implementierung der Szenarien Ergebnis Abschließende Betrachtung Diskussion der Ergebnisse Ausblick Literaturverzeichnis A Anhang I CD-Inhaltsverzeichnis II Abkürzungsverzeichnis III Preislistenauszüge IV Angebote V Ubuntu Netzwerk Installation VI CPU-Chronik Seite III

5 Kapitel 1 - Einleitung 1 Einleitung 1.1 Motivation Das Datenaufkommen in Netzwerken steigt stetig, immer mehr Aktivitäten werden über IP-Netzwerke abgewickelt. Die geschäftliche sowie private Kommunikation wird mehr und mehr ins Internet sowie in die Unternehmensnetze verlagert. Auch klassische Kommunikationsdienste wie das Telefon werden z.b. durch Voice over IP in die Unternehmensnetzwerke integriert. Hierdurch vergrößern sich die Netze ständig, so wird zum Beispiel jedes Telefon zu einer Netzkomponente. Diese Entwicklung gilt nicht nur für den Telefonverkehr, auch weitere Dienste werden immer häufiger in die Kommunikationsnetze integriert. Auch in Zukunft ist ein steigendes Datenaufkommen zu erwarten, da noch weitere Möglichkeiten bestehen, Dienste zu integrieren. Auch die Chancen bestehender Dienste sind noch nicht ausgenutzt und lassen eine Steigerung erwarten. 1 Ein Nachteil der starken Integration und der Abwicklung des gesamten Verkehrs über nur ein Netz zeigt sich jedoch in Fehlerfällen oder bei einem Ausfall. Treten Probleme im Kernnetz auf, ist die gesamte Kommunikation betroffen. Die Betreuer eines Netzwerkes stehen hier vor dem Problem, Überlast- und Fehlersituationen frühzeitig zu erkennen und darauf entsprechend reagieren zu müssen. Auch muss die Auslastung des Netzes bekannt sein, um rechtzeitig die Kapazität erweitern zu können, damit Ausfällen vorgebeugt werden kann. Eine weitere Aufgabe in diesem Bereich ist es, die Qualität eines Netzwerkes beurteilen zu können. Als einfaches Beispiel lässt sich hier die Zeit anführen, die ein Paket im Netzwerk braucht, um von einem Kommunikationspartner zu einem anderen und wieder zurück zu gelangen, auch als Round-Trip-Time (RTT) bezeichnet. 2 Zur Erfüllung dieser Aufgaben setzen Firmen mit ihren Netzwerkmonitoring- oder Netzwerkanalysesystemen an. Unter Monitoring versteht man im Allgemeinen das Überwachen eines Vorgangs oder Prozesses mittels technischer Hilfsmittel oder anderer Beobachtungssysteme. 3 Das Netzwerkmonitoring kann dabei auf verschiedenste Weisen geschehen. Speziell auf einzelne Aufgaben hin entwickelte Systeme werden meist als Paket von Hard- und Software angeboten (Appliance). Die Anschaffung einer solchen Monitoring- Infrastruktur kann schnell einige tausend Euro kosten. Ist es nun nötig, weitere spezielle Parameter zu überwachen, die von der gekauften Infrastruktur nicht unterstützt werden, ist eine erneute hohe Investition nötig. Die Geräte sind also nicht flexibel auf die gewünschten Situationen anpassbar. Wird auf die Investition in eine eigene Management- oder Monitoring-Infrastruktur verzichtet und damit auf die integrierten Überwachungsfunktionen in einigen Netzwerkkomponenten gesetzt, können auch hier Probleme auftreten. Kommt es zu einer Situation, in der es notwendig wird, an einer bestimmten Stelle des Netzwerks den Verkehr zu überwachen, kann dies zum Problem werden. Denn hier müssen oftmals die Konfigurationen der Komponenten angepasst werden, um die richtigen Daten zu erhalten und analysieren zu können. Hier stellt sich die Frage, ob dass so einfach und schnell möglich ist. Oftmals ist dies nicht möglich, da zum Beispiel Berechtigungen fehlen. Das Aktivieren der integrierten Managementfunktionen eines Gerätes kann weiterhin ein enormes Sicherheitsrisiko mit sich bringen. Die Managementoberflächen ermöglichen oftmals nicht nur eine Überwachung der Funktionen, sondern auch ein Ändern der Konfiguration des Gerätes, was hier nicht gewünscht ist. Ein Angreifer könnte in diesem Fall z.b. gezielt für einen Ausfall sorgen. Der größte Nachteil ist jedoch, dass die Geräte keine Möglichkeit bieten, eigene Anwendungen oder Applikationen zu integrieren. Dies ist besonders im Umfeld einer 1 Vgl. Hegering 1999, S.4 2 Vgl. Leischner Plötner / Wendzel 2007, S.197 Seite 1

6 Kapitel 1 - Einleitung Fachhochschule ein Problem, wo in Projekten neue Monitoringverfahren entwickelt werden und getestet werden müssen. Hier fehlt es an Geräten die frei konfigurierbar sind und die Möglichkeit bieten, sich den ändernden Situationen anzupassen. Es muss also möglich sein, eigene Anwendungen zu integrieren. Hier soll diese Arbeit ansetzen. 1.2 Umfeld Diese Arbeit wird im Umfeld des Fachbereichs Informatik der Fachhochschule Bonn- Rhein-Sieg erstellt. Der Fachbereich Informatik ist unterteilt in verschiedene Schwerpunkte. Diese Arbeit findet im Schwerpunkt Telekommunikation statt. Im Speziellen soll der Netzwerkprobe in den Netzlaboren eingesetzt werden. Dies sind zur Zeit C015 und C055, sie befassen sich mit den Lehrgebieten "Netzwerksysteme und Telekommunikation" sowie "Hochleistungsnetze und Mobilkommunikation". Die Labore werden unter anderem für Praxisprojekte, Abschlussarbeiten und Forschungsprojekte genutzt. Der Netzwerkprobe soll hier als Basis für solche Projekte dienen und für den Lehrbertrieb eingesetzt werden Zielsetzung Ziel dieser Arbeit ist es, im Rahmen der Konzeption eine Hardwarebasis für einen Netzwerkprobe zu dimensionieren. Mit diesem Monitoring-Gerät soll es möglich sein, den Netzwerkverkehr an verschieden Stellen im Netzwerk aufzuzeichnen, eventuell unter Zuhilfenahme weiterer Geräte, um Zugriff auf den Datenverkehr zu erhalten. Daher soll er transportierbar und leicht aufzubauen sein. Der Netzwerkprobe soll frei zu konfigurieren sein und es ermöglichen jetzt und auch später, weitere Monitoring- Szenarien zu erfüllen. Daher soll es auf diesem Gerät möglich sein, eigene Anwendungen zu installieren. Im Umfeld der Fachhochschule soll der Probe als Hardwarebasis zum Test neuer Monitoringverfahren dienen. 1.4 Aufbau Die Arbeit gliedert sich in zwei Haupteile. Der erste Teil umfasst die Dimensionierung der Hardware, worin auch die Auswahl der Komponenten und deren Beschaffung enthalten sind. Im Anschluss soll als zweiter Teil der Arbeit mit der beschafften Hardware eine Basisimplementierung durchgeführt werden. Konzeption/Dimensionierung Bevor es zu einer Hardwarebeschaffung kommen kann, muss die richtige Hardware ausgewählt werden. Hierzu sind die Anforderungen an den Netzwerkprobe auszuarbeiten und zu formulieren. Auch auf die speziellen Anforderungen, die durch den Einsatz im Labor gestellt werden, ist zu achten. Das ergibt den ersten Rahmen für das zu dimensionierende Gerät. Die weitere Beschaffenheit des Gerätes richtet sich nach dem späteren Einsatz. Hier bietet es sich an, typische Monitoringszenarien zu entwickeln, die dann der Dimensionierung zu Grunde gelegt werden können. In diesem Zusammenhang ist die Anbindung des Probes an das Netzwerk ein wichtiger Punkt, der Einfluss auf die Beschaffenheit und Ausstattung des Gerätes hat. Um einen genaueren Eindruck der benötigten Systemperformance zu bekommen, soll basierend auf ausgewählten Szenarien ein Messmodell erstellt werden. Probemessungen mit Standard PC- Hardware und mittels eines Lastgenerators sollen Anhaltspunkte für die benötigten Systemkomponenten liefern. Weitere Hilfe soll eine Analyse der am Markt erhältlichen, kommerziellen Geräte ergeben. 4 Vgl. Netlab Wiki 2007 a Seite 2

7 Kapitel 1 - Einleitung Im nächsten Schritt soll die Hardware ausgewählt und beschafft werden. Es ist abzuwägen, welche Szenarien vor dem Hintergrund der Basisanforderungen und der durchgeführten Probemessungen realisiert werden können. Es gilt also eine Auswahl an Szenarien zu treffen und die Hardware entsprechend zu beschaffen. Hier ist auch zu beachten, ob zusätzlich weitere Hardware nötig ist, um die Szenarien zu erfüllen. Implementierung Sobald die Hardware zur Verfügung steht, soll mit dem Netzwerkprobe ein Szenario prototypisch implementiert werden. Zunächst sind die Komponenten zu montieren und ein Betriebssystem inklusive der nötigen Treiber zu installieren. Danach soll ein einfaches Monitoring-Szenario mit dem Gerät realisiert werden. Mittels Lastgenerator ist zu messen, ob die ausgewählten Komponenten im Zusammenspiel die Erwartungen erfüllen. Seite 3

8 Kapitel 2 - Anforderungsanalyse 2 Anforderungsanalyse In diesem Kapitel sollen die ersten Anforderungen an den zu dimensionierenden Netzwerkprobe festgelegt werden. Die Anforderungen wurden in Gesprächen mit den zuständigen Personen festgelegt. Zuerst wurde ein grundlegendes Modell erstellt, welches durch das zu dimensionierende Gerät realisiert werden soll. Das allgemeine Monitoringmodell zeigt Abbildung 2-1. Die vier Aufgaben Netzwerkzugriff, Datensammlung, Verarbeitung und Darstellung stellen den Ablauf dar, wie die Informationen über das Netzwerk dem Netzwerkbetreuer zugänglich gemacht werden. Diese Aufgaben können alle durch den Netzwerkprobe selbst erledigt werden oder auf verschiedene Geräte verteilt sein. Zunächst muss der Netzwerkprobe über einen Zugang zum Netzwerk verfügen, jedoch ohne dieses zu beeinflussen. Das bedeutet, das Gerät darf den Netzwerkverkehr nicht verändern, wenn es ihn überwacht. Der Netzwerkzugriff kann im Gerät selbst realisiert werden oder durch zusätzliche Hardware geschehen. Der Netzwerkprobe soll die Daten in Form von Ethernet-Frames erfassen und zumindest zwischenspeichern, die weiteren Schritte können je nach Einsatzzweck verschiedene Ausprägungen haben. Der Probe kann die Daten dann selbst verarbeiten und anzeigen oder zur Abfrage durch ein anderes Gerät bereithalten. Die Verarbeitung, Auswertung und Darstellung kann im Probe selbst oder auf einem oder mehreren weiteren Gerät erfolgen. Die Dimensionierung der eventuell zusätzlich benötigten Geräte für die Verarbeitung und Darstellung der Daten ist nicht Gegenstand dieser Arbeit. Mit verschiedenen speziellen Monitoring-Modellen, die sich auf dieser Grundlage realisieren lassen, beschäftigt sich Kapitel 4. Vorher werden in Kapitel 3 die hierfür benötigten Grundlagen betrachtet. Außer dem angesprochenen allgemeinen Modell werden an den Netzwerkprobe weitere Anforderungen gestellt. Zunächst allgemeine Anforderungen, weiterhin aber auch solche, die sich durch den Einsatz in einer Laborumgebung, hier speziell im Netzlabor der Fachhochschule ergeben. Manche dieser Aufgaben stellen zunächst Anforderungen an die eingesetzte Software, jedoch ergeben sich hieraus auch Anforderungen an die Hardware. Allgemeine Anforderungen: - Einsetzbarkeit in verschiedene Monitoring-Szenarien - Transportierbarkeit - Einfache Konfigurierbarkeit - Erweiterbarkeit - Gigabit-Ethernet-Monitoringfähigkeit - Fernwartbarkeit Anforderungen durch das Netzlabor: - Ubuntu als Betriebssystem - Einsetzbar als Hardwarebasis für das RTT-Projekt - Vernünftiges Kosten/Nutzen-Verhältnis - Out-Band-Managementfähigkeit - SNMP-Fähigkeit Seite 4

9 Kapitel 2 - Anforderungsanalyse 2.1 Allgemeine Anforderungen Einsetzbarkeit in verschiedenen Monitoring-Szenarien Innerhalb des oben angesprochenen Modellrahmens soll es die zu dimensionierende Hardware für den Netzwerkprobe ermöglichen, so viele Monitoring-Szenarien wie möglich darauf zu implementieren. Einsetzbar bedeutet, dass ein Szenario möglichst vollständig umgesetzt werden kann ohne Einschränkungen zum Beispiel durch Verluste von Paketen in Kauf nehmen zu müssen. Da hier je nach Szenario verschiedene Anforderungen an Schnittstellen, Prozessor und weitere Hardwarekomponenten gestellt werden, befassen sich die folgenden Kapitel mit den verschiedenen Szenarien und Möglichkeiten, die Daten zu erfassen. In diesen Kapiteln wird dann genauer darauf eingegangen, welche Anforderungen jeweils an die Hardware gestellt werden. Um die Einsetzbarkeit in verschiedenen Szenarien zu gewährleisten, muss es möglich sein, eigene evtl. neu entwickelte Szenarien selbst auf dem Gerät implementieren zu können. Transportierbarkeit Eine wichtige Voraussetzung ist die Größe des Gerätes, da in diesem Projekt ein universell einsetzbarer, transportabler Netzwerkprobe benötigt wird. Um das Gerät auch in Situationen einsetzen zu können, in denen an verschiedenen Positionen nacheinander Messungen vorgenommen werden, ist es unabdingbar, dass der Probe einfach zu transportieren ist. Das bedeutet, dass das Gerät nicht wie andere Produkte kommerzieller Hersteller als im Rack montierbare Version ausgeführt sein sollte. Daraus folgt, dass es nötig ist, möglichst kleine Komponenten auszuwählen, die dennoch den Leistungsanforderungen entsprechen. Hieraus ergibt sich auch, dass der Verkabelungsaufwand beim Aufstellen und bei Inbetriebnahme des Gerätes möglichst gering gehalten werden muss. Das Gerät soll nach Möglichkeit eine Einheit bilden und wenige zusätzlich anzuschließende Komponenten benötigen. Hier wäre zum Beispiel ein internes Netzteil sinnvoll. Einfache Konfigurierbarkeit Bedingt durch die vorherigen Punkte hier besonders durch die Einsetzbarkeit in verschiedenen Monitoring-Szenarien, ist es notwendig, die Konfiguration und Anpassung des Gerätes auf die Szenarien so einfach wie möglich zu machen. Dies kann besonders dann zum Tragen kommen, wenn das Gerät im Netzlabor zu Lehrzwecken eingesetzt wird. Dabei müssen unter Umständen in kurzer Zeit verschiedene Szenarien mit solch einem Probe realisiert werden. Ist die Konfiguration zu umständlich, kann das Gerät zu Lehrzwecken nicht eingesetzt werden. Eine Möglichkeit wäre zum Beispiel der direkte Systemzugriff über eine Remote- Konsole. Noch einfacher könnte die Konfiguration über den Anschluss von Peripherie, wie Tastatur und Bildschirm direkt am Gerät geschehen. Erweiterbarkeit Die Technik im Bereich der Netzwerke entwickelt sich immer weiter. Die möglichen Übertragungsraten der bestehenden Verkabelung erhöhen sich, neue Medien mit noch größeren Bitraten kommen zum Einsatz. Da dieser Netzwerkprobe nicht auf den heutigen Stand der Technik beschränkt sein soll, ist es wichtig, das Gerät so auszulegen, dass eine Erweiterbarkeit später noch möglich ist, wenn auch in begrenztem Maße. Hierzu zählt zunächst, die bestehende Hardware erweitern zu können. Das heißt zum Beispiel zusätzliche Netzwerkschnittstellen später hinzufügen zu können. Aber auch eine Aufrüstung bestehender Komponenten soll möglich sein. Als Beispiel wäre hier der Arbeitsspeicher oder der Prozessor zu nennen. Seite 5

10 Kapitel 2 - Anforderungsanalyse Ein weiterer Punkt, die eine Erweiterbarkeit nötig machen, ist die Anpassung des Geräts an spezielle Szenarien. Dadurch könnten beispielsweise weitere oder spezielle Schnittstellen notwendig werden. Gigabit-Ethernet-Monitoringfähigkeit In der heutigen Zeit wird Gigabit Ethernet auf Basis von Kupfer- oder Glasfaserkabeln nicht nur zur Anbindung von Servern oder im Kernbereich eines Netzes, sondern auch zur Anbindung der Arbeitsplätze genutzt. Da Monitoring meist an zentraler Stelle im Netzwerk geschieht, ist es eine Forderung an die Hardware mindestens Gigabit Ethernet Monitoring zu unterstützen. Dies stellt Anforderungen an die Schnittstellen sowie an die Verarbeitungshardware. Auch der Speicherplatz spielt hier eine Rolle. Ebenso wird im Umfeld der Fachhochschule, besonders im Netzlabor Gigabit Ethernet eingesetzt, hier meist auf Basis von Kupferkabeln. Soll der Netzwerkprobe im Lehrumfeld zum Einsatz kommen, ist es also sinnvoll auch das Aufzeichnen von Datenströmen im Gigabit Ethernet zu ermöglichen. 5 Fernwartbarkeit Der Netzwerkprobe soll an vielen Stellen im Netzwerk zum Einsatz kommen. Es könnte auch vorkommen, dass mehrere Probes an verschiedenen Stellen positioniert werden. Soll nun eine Änderung der Konfiguration vorgenommen werden, müsste die zuständige Person sich einzeln an jedes Gerät begeben und dies vor Ort vornehmen, unter Umständen dann sogar noch Peripherie anschließen. Um diesen Umstand zu vermeiden, ist es unverzichtbar, die Fernwartbarkeit des Gerätes vorzusehen. Zum Beispiel könnte ein Zugriff per Remote-Konsole stattfinden. Da es sich bei dem überwachten Netzwerkverkehr um sicherheitskritische Daten handeln könnte, sollte beim Fernzugriff eine verschlüsselte Variante gewählt werden. 2.2 Anforderungen durch das Netzlabor Ubuntu als Betriebssystem Im Umfeld des Netzlabors kommt neben Microsoft Betriebssystemen hauptsächlich die Linux Distribution Ubuntu zum Einsatz. Ubuntu ist eine Debian-basierte Distribution, die versucht dessen stabile und sichere Architektur mit aktuellen Paketen zu verbinden. Dies soll vor allem die Benutzerfreundlichkeit steigern. Ubuntu empfiehlt sich daher besonders für Einsteiger, da es sehr schnell ermöglicht ein benutzbares System aufzusetzen. Ein Grund für den Einsatz im Netzlabor ist, dass es inzwischen eine der meist eingesetzten Linux Distributionen ist. Durch seine Debian-Wurzeln lassen sich mit Ubuntu auch komplexere Problemstellungen angehen. Zurzeit wird die aktuellste Version mit Long Term Support (LTS), Version 6.06LTS, eingesetzt. Hier wird der Support im Gegensatz zu den normalen Versionen von 18 Monaten auf 3 Jahre beim Desktop und 5 Jahre bei der Server Version erweitert. Die normalen Versionen erscheinen halbjährig wobei die Versionsnummer das Jahr und den Erscheinungsmonat angibt, die LTS-Versionen werden in größeren Zeitabständen veröffentlicht. Die nächste erscheint voraussichtlich im April 2008 und wird dann 8.04LTS heißen. Auch diese soll dann im Labor zum Einsatz kommen. Daher soll auch der Netzwerkprobe als Betriebssystem möglichst Ubuntu verwenden, weil so eine einheitliche Systembasis besteht. So ist ein Umdenken bei der Konfiguration und dem Arbeiten mit den Geräten nicht nötig. 6 5 Vgl. Netlab Wiki 2007 b 6 Vgl. Fischer 2007 Seite 6

11 Kapitel 2 - Anforderungsanalyse Einsetzbar als Hardwarebasis für das RTT-Projekt Die Internetverzögerungszeit wird immer mehr zu einer wichtigen Maßzahl, um die Qualität einer Verbindung zu bewerten. Kunden verlangen von ihren Internetprovidern eine möglichst geringe Latenzzeit. Besonders Spieler von Onlinespielen legen hierauf großen Wert. Diese Verzögerungszeit kann einfach aktiv mittels eines ping-befehls gemessen werden. Hier wird die so genannte Round-Trip-Time (RTT) gemessen, die Zeit eines IP-Paketes vom Sender zum Empfänger und zurück. Diese Methode der Messung hat jedoch auch Nachteile. Hierzu zählt zum Beispiel die erhöhte Netzlast. Weiterhin werden der ping bzw. die dadurch versendeten Pakete oft aus Sicherheitsgründen geblockt. Auch können die durch den ping erzeugten ICMP-Pakete priorisiert werden. Aus diesen Gründen können die Messungen verfälscht werden. Um dieses Problem zu lösen, entwickelt ein Projekt unter der Leitung von Herrn Prof. Dr. Martin Leischner ein Verfahren zur passiven Messung von RTT-Werten. Hierbei wird die RTT durch die Beobachtung des Netzwerkverkehrs an einem Beobachtungspunkt ermittelt. An diesem Beobachtungspunkt steht ein Netzwerkprobe, der durch Betrachtung von drei aufeinander folgenden TCP-Segmenten auf die RTT schließt. Eine genauere Beschreibung des Verfahrens, im Bezug auf die Anforderungen, die an den Probe gestellt werden, folgt in Kapitel 4.3.Im weiteren Verlauf des Projektes soll eine verteilte Messung mit mehreren Sonden oder Netzwerkprobes einen Überblick über die Entwicklung der RTT in einem Netzwerk bieten. 7 Der hier zu dimensionierende Netzwerkprobe soll als Hardwarebasis für solch eine Sonde dienen und die Messdaten an eine zentrale Verarbeitungseinheit weitergeben. Welche weiteren Anforderungen sich hieraus ergeben wird in diesem Kapitel näher erläutert. Vernünftiges Kosten/Nutzen-Verhältnis Für den zu dimensionierenden Netzwerkprobe müssen die Kosten in einem vernünftigen Verhältnis zum erreichten Nutzen stehen. Es ist zum Beispiel nicht sinnvoll, für wenig zusätzliche Leistung enorme Kosten in Kauf zu nehmen. Da für die Labore eventuell mehrere Netzwerkprobes angeschafft werden sollen, würden sonst erhebliche Kosten für die Fachhochschule entstehen. Weiterhin waren hohe Investitionen ja gerade ein Problem kommerzieller Geräte, das durch diese Arbeit zumindest abgeschwächt werden sollte. Dennoch sollten keine Abstriche bei Leistung und Qualität in Kauf genommen werden. Es muss also ein guter Mittelweg gefunden werden. Out-Band-Managementfähigkeit Um die Managementinformationen, also die Daten, die der Netzwerkprobe erfasst bzw. zur Verfügung stellt, von dem Netzwerkprobe abzurufen oder auf eine zentrale Einheit zu übertragen, bestehen zwei verschiedene Ansätze, nämlich In-Band und Out-Band- Management. Beim In-Band-Management werden die Management-Daten über dasselbe Netzwerk oder dieselben Kommunikationswege wie die eigentlichen Nutzdaten transportiert. Im Gegensatz hierzu wird beim Out-Band-Management der normale zu überwachende Netzwerkverkehr streng vom Managementverkehr getrennt. Beim Einsatz von In-Band-Management haben die ausgetauschten Managementinformationen Einfluss auf den überwachten Verkehr. In bestimmten Szenarien ist dies nicht gewollt und führt zu einer Verfälschung der Messergebnisse. Aus diesem Grund ist es eine Anforderung an den zu dimensionierenden Netzwerkprobe, auch Out-Band-Management zu unterstützen. 8 7 Vgl. Leischner Vgl. Schwenkler 2006, S Seite 7

12 Kapitel 2 - Anforderungsanalyse SNMP-Fähigkeit Die heutige Basis für Netzmanagement IP-basierter Netzwerke ist das Simple Network Management Protokoll (SNMP). SNMP Version 1 ist in RFC definiert. SNMP ist die Grundlage für herstellerübergreifende Managementlösungen. SNMP ermöglicht sowohl das Überwachen, als auch das Konfigurieren von Netzkomponenten. Eine Management-Station greift hier auf einen SNMP-Agent auf einer Netzkomponente zu und liest Werte von Objekten innerhalb einer Management Information Base (MIB) aus. Je nach Gerät und eingesetzter MIB ist es auch möglich, Objekten Werte zuzuweisen, so dass eine Konfiguration der Geräte möglich ist. Die meisten Agents bringen eine Standard-MIB mit, in der Basiswerte abgefragt werden können, die MIB-2. Da jedes Gerät Besonderheiten hat, z.b. kann bei manchen Switches die Übertragungsrate jedes Ports abgefragt werden, gibt es die Möglichkeit, hersteller- bzw. gerätespezifische MIBs durch einen Agent bereit zu stellen. Diese müssen dann auch der Management-Station bekannt sein. 10 Das hier zu dimensionierende Gerät soll zumindest die Möglichkeit bieten, Basiswerte per SNMP abzufragen. So kann auf eine einfache Weise eine Grundfunktionalität hergestellt werden, ohne spezielle Verfahren oder Anwendungen auf dem Gerät implementieren zu müssen. 9 Vgl. Case u.a Vgl. Hegering 1999, S.143ff u. Schwenkler 2006, S.69ff Seite 8

13 Kapitel 3 - Grundüberlegungen 3 Grundüberlegungen 3.1 Anbindungsszenarien Dieses Kapitel befasst sich mit den verschiedenen Möglichkeiten, die Messdaten einer Verbindung zum Netzwerkrobe zu führen. Bevor die Daten im Probe verarbeitet werden können, muss über ein geeignetes Verfahren Zugriff auf diese erlangt werden. Wichtige Anforderungen, die an alle Verfahren gestellt werden, sind: - Die Daten zwischen den Kommunikationspartnern dürfen nicht verändert werden. - Es müssen alle Daten der Kommunikation ohne Verluste zum Probe gelangen. Der Zugriff auf die Verbindung kann an verschiedenen Stellen im Netzwerk erfolgen, je nach dem, was überwacht werden soll und mit welchem Verfahren dies erfolgt. Verschiedene Möglichkeiten zeigt Abbildung 3-1. Im Folgenden werden nun diese Verfahren beziehungsweise Geräte dargestellt, die es ermöglichen, den Netzwerkverkehr unter Berücksichtigung der oben genannten Kriterien zum Netzwerkprobe zu leiten. Hierbei werden die Vor- und Nachteile aufgezeigt und im Anschluss die Anforderungen ermittelt, die durch dieses Verfahren an die Hardware des Netzwerkprobe gestellt werden. Netzwerkprobe Firewall Hub Inline- Monitoring Tap Hub Tap Switch mit SPAN Port Internes Netzwerk DMZ Switch mit SPAN Port Abbildung 3-1: Netzwerkzugriff Seite 9

14 Kapitel 3 - Grundüberlegungen Hubs Die einfachste Möglichkeit, alle Daten aller Kommunikationspartner zu empfangen, ist die Verwendung eines Hubs. Ein Hub ist ein Halbduplex-Gerät, das alle Daten, die von einem Kommunikationspartner gesendet werden, auf alle anderen Anschlüsse weiterleitet, außer dem Anschluss, auf dem sie empfangen wurden. Ein Hub ist ein ISO/OSI Schicht 1 Gerät und leitet somit nur die physikalischen Signale auf die anderen Ports weiter. So ist der Hub zunächst optimal geeignet, um einfach ein Monitoring einer Verbindung durchzuführen. Der Hub wird mit zwei seiner Ports in die bestehende Verbindung geschaltet wie Abbildung 3-2 zeigt. An einen anderen Port wird nun der Netzwerkprobe angeschlossen. Alle Daten, die zwischen den Kommunikationspartnern ausgetauscht werden, erreichen auch den Probe. So wäre es auch möglich, mehrere Monitoring- Geräte mit verschiedenen Aufgaben einfach an verschiedene Ports des Hubs anzuschließen, alle würden dieselben Informationen erhalten. Jedoch hat der Hub einige entscheidende Nachteile. Da er ein reines Halbduplex-Gerät ist, limitiert er die Verbindung, in die er geschaltet wird, auch auf Halbduplex-Betrieb. Dies bringt Performanceeinbußen mit sich, da die angeschlossenen Kommunikationspartner nur wechselseitig senden können (ein gleichzeitiges Senden und Empfangen ist hier nicht möglich) und nun durch den Halbduplex-Betrieb auch Kollisionen auftreten können. Auch ist die Geschwindigkeit eines Hubs auf 100Mbit/s beschränkt, weshalb das Überwachen einer Gigabit-Ethernet-Verbindung nur mit starken Einbußen möglich ist. Hier würde also Einfluss auf die Netzwerkverbindung ausgeübt. Einen weiteren Nachteil stellt ein möglicher Ausfall eines Hubs dar. Ist er, wie in Abbildung 3-1 gezeigt, an einer zentralen Stelle im Netzwerk positioniert und fällt aus, ist nicht nur das Monitoring nicht mehr möglich, sondern die Verbindung zwischen den Kommunikationspartner ist völlig unterbrochen. 11 Anforderungen an die Hardware Wie Abbildung 3-2 zeigt, wird der Netzwerkprobe an einen der freien Ports des Hubs angeschlossen. Daher ist beim zu konzipierenden Monitoring-Gerät ein Ethernet-Port pro überwachte Verbindung vorzusehen. Da der Hub nur mit 100Mbit/s arbeiten kann, ist ein 100Mbit/s Ethernet-Port völlig ausreichend. An die Performance werden daher auch keine erhöhten Anforderungen gestellt. 11 Vgl. Bejtlich 2004, S u. Bejtlich 2005, S.105 Seite 10

15 Kapitel 3 - Grundüberlegungen SPAN-Port Eine weitere Möglichkeit, alle Daten einer Verbindung zu erhalten, ist der SPAN-Port. SPAN steht hierbei für Switch Port Analyzer. Solch ein Port, manchmal auch Mirror- Port oder Monitor-Port genannt, wird von den meisten Herstellern in ihren Switches der höheren Preisklasse unterstützt. In der Regel verfügen die Geräte über einen, manchmal aber auch mehrere SPAN-Ports. Ein SPAN-Port kann frei konfiguriert werden. Er wird einem anderen Switch Port zugeordnet und spiegelt allen Verkehr von diesem Port. Abbildung 3-3 zeigt ein einfaches Beispiel. Hier wird der gesamte Verkehr der Verbindungen des Ports, an dem Gerät B angeschlossen ist, auf den Span-Port gespiegelt. Der restliche Verkehr auf dem Switch bleibt davon unberührt. Der Vorteil gegenüber einem Hub ist, dass solch ein Port auch den durch den Switch unterstützten Vollduplex-Verkehr spiegelt und die Übertragungsrate der überwachten Verbindung nicht beschränkt. 12 Weiterhin bietet dieses Konzept den Vorteil, die Kabel nicht auftrennen zu müssen, wenn eine bestimmte Verbindung überwacht werden soll. Dies geschieht einfach durch Ändern der Konfiguration des Ports. Durch das kurzzeitige Auftrennen der Verbindung, wie es beim Einbringen eines Hub oder TAP in die Verbindung der Fall ist, können unerwünschte Paketverluste auftreten. Von Vorteil ist auch, dass SPAN-Ports in vielen Switches schon vorhanden sind und, da diese Geräte an zentralen Stellen im Netzwerk integriert sind, ein einfaches Monitoring ermöglichen. Ein großer Vorzug ist auch, dass im Idealfall alle Ports eines Switches gleichzeitig auf den SPAN-Port gespiegelt werden können. SPAN-Ports bieten nicht nur Vorteile. Geräte mit diesen Ports sind teurer und werden daher nicht in allen Bereichen eines Netzwerks eingesetzt, was ein Monitoring von bestimmten Verbindungen mit SPAN-Ports unmöglich macht, wenn nicht Komponenten getauscht werden. Ein weiterer Nachteil ergibt sich aus der Tatsache, dass Ports eines Switches den Vollduplex-Betrieb unterstützen. Arbeitet ein Port in Sende- und Empfangsrichtung mit maximalem Durchsatz, muss der SPAN-Port den doppelten Durchsatz verarbeiten können. Wird eine Verbindung eines 100Mbit/s Ports gespiegelt, könnte das Problem mit einem 1Gbit/s Port gelöst werden. Die auftretenden 200Mbit/s werden von diesem problemlos abtransportiert. Eine weitere Möglichkeit ist das Aufteilen von Sende- und Empfangsrichtung auf getrennte Span-Ports. Hierzu muss aber eine ausreichende Menge Ports vorhanden sein. Diese Problematik wird gesteigert durch die zuvor angesprochene Möglichkeit mehrere Ports gleichzeitig auf 12 Vgl. Bejtlich 2005, S.106 Seite 11

16 Kapitel 3 - Grundüberlegungen einen SPAN-Port zu spiegeln. Durch die Zusammenfassung vieler Verbindungen treten hier noch höhere Übertragungsraten auf. Hierdurch kann es zu Paketverlusten für den SPAN-Port kommen, wenn die tatsächlichen Übertragungsraten der überwachten Ports die des SPAN-Port übersteigt. Aber auch bei den überwachten Verbindungen kann es zu Einschränkung der Übertragungsrate kommen. Ein Grund für diese Probleme kann auch die höhere Last für den Switch sein. Durch das Kopieren des Verkehrs wird zum Beispiel der Prozessor des Gerätes stärker belastet. 13 Muss eine Verbindung kurzfristig analysiert werden, kann dies mittels SPAN-Port zum Problem werden, da nicht immer voller Zugriff auf eine Netzwerkkomponente besteht, weil z.b. die Konfiguration der Switche nur wenigen Mitarbeitern zugänglich ist. Hier spielen andere Konzepte ihre Vorteile aus. Hubs beispielsweise können einfach integriert werden, man muss jedoch die zuvor besprochenen Nachteile in Kauf nehmen. 14 In manchen Analyse-Szenarien zeigt sich ein weiterer Nachteil beim Einsatz von SPAN-Ports. Sollen auch Low-Level-Fehler, wie z.b. defekte Frames, analysiert werden oder in die Statistik mit eingehen, ist dies meistens nicht möglich. Der Grund ist, dass fast alle Hersteller Low-Level-Fehler nicht auf den Monitor-Port weiterleiten. 15 So wird die Fehlersuche erschwert. Anforderungen Wie in Abbildung 3-3 zu sehen, wird das Monitoring- oder Analyse-Gerät mit einem Kabel direkt an den SPAN-Port eines Switches angeschlossen. Dies erfordert am Monitoring-Gerät einen Ethernet-Port pro Verbindung. Wie zuvor gezeigt, sind auch Konfigurationen mit je einem SPAN-Port für Sende- und Empfangsrichtung möglich. Dieses Szenario erfordert zwei Ethernet-Ports am Netzwerkprobe. Weiterhin muss der Verkehr von Sende- und Empfangsrichtung im Probe wieder zu einem Datenstrom zusammengefügt werden. An die Performance des Systems werden weit höhere Anforderungen gestellt als dies beim Einsatz eines Hubs der Fall ist. Im Extremfall muss der Probe die Daten von Sende- und Empfangsrichtung bei maximaler Auslastung des Ports und damit mit gesamter Datenübertragungsrate verarbeiten. Wenn der Switch-Port 1000Mbit/s verarbeiten kann, muss der Netzwerkprobe 2x1000Mbit/s verarbeiten. Wenn also keine Paketverluste in Kauf genommen werden sollen, muss das zu konzipierende Gerät mindestens über zwei Ports mit mindestens der Übertragungsrate der Switch-Ports verfügen. Genauere Abschätzungen bezüglich der benötigten Performance des Geräts sollen in Kapitel 5.2 durch Messungen mit Standard-Hardware gemacht werden TAP Ein speziell für Monitoring-Anwendungen konstruiertes Netzwerkgerät ist der TAP, oder Test Access Port. Ein TAP ist ausgelegt, Verbindungen ständig passiv zu überwachen. Er verändert in keinster Weise die Daten auf der überwachten Verbindung. Er wird wie in Abbildung 3-4 und Abbildung 3-5 zu sehen zwischen zwei beliebige Netzwerkkomponenten geschaltet und spiegelt ähnlich einem SPAN-Port die gesamte Kommunikation zwischen den beiden angeschlossenen Komponenten an den Ausgang oder die Ausgänge zum Anschluss eines Analysegerätes. Im Gegensatz zum SPAN-Port, auf den die Frames kopiert werden, erfolgt die Spiegelung auf physikalischer Ebene, so dass keine Veränderung der Pakete oder Frames erfolgt und auch defekte Frames nicht gefiltert werden. Auch findet eine Regenerierung der Signale statt. Hier kommt der TAP der Funktion eines Hubs nahe. Jedoch kann ein 13 Vgl. Cisco Systems Vgl. Bejtlich 2004, S Vgl. Bejtlich 2004, S Vgl. Netoptics 2007 Seite 12

17 Kapitel 3 - Grundüberlegungen TAP im Vollduplexbetrieb arbeiten. TAPs sind in verschiedenen Geschwindigkeiten lieferbar und limitieren damit nicht die Übertragungsrate der überwachten Verbindung. Weiterhin sind diese Geräte auch für andere Medien wie Glasfaser lieferbar und daher nicht auf Kupferkabel beschränkt. Ein TAP kann wie ein Hub flexibel in Verbindungen eingebracht werden, spart also die Konfiguration am Switch. Dies bringt aber auch den Nachteil mit sich, die Verbindung auftrennen zu müssen und so einen Paketverlust in Kauf zu nehmen. Sollte ein TAP zum Beispiel durch Spannungsverlust ausfallen, besteht die Verbindung weiter, bei manchen Herstellern sogar ohne jegliche Paketverluste. Eine Signalregenerierung ist dann jedoch nicht mehr möglich. TAPs sind in verschiedenen Ausprägungen lieferbar, auf die wichtigsten wird im Folgenden eingegangen und die spezifischen Eigenarten werden aufgezeigt. Die beiden Hauptgruppen sind hierbei Regeneration-TAP und Aggregation-TAP. Es gibt aber auch Kombinationen aus beiden Typen Regeneration-TAP Die Urform des TAP ist ein Regeneration-TAP. Dieser einfache Typ eines TAPs verfügt normalerweise über vier Ports, wie Abbildung 3-4 zeigt. Regeneration-Tap Monitoring Ports A -> B B -> A Gerät A Netzwerkprobe Gerät B An den ersten beiden Ports wird die zu überwachende Verbindung angeschlossen. Von den beiden weiteren Ports liefert jeder eine Richtung des Verkehrs, der eine Port eine Kopie der Sendedaten, der andere eine Kopie der Empfangsdaten. So kann der TAP auch bei maximaler Übertragungsrate der Verbindung alle Daten an einen Netzwerkprobe weiterleiten. Da die Verkehrsdaten der zu überwachenden Verbindung hier aufgeteilt werden, muss beim Probe oder vor diesem eine Möglichkeit bestehen, beide Richtungen des Verkehrs wieder zu einem Datenstrom zusammenzufügen. 18 Einige Hersteller bauen TAPs mit sechs, acht oder mehr Ports, wobei die jeweils zwei zusätzlichen Anschlüsse für ein weiteres Monitoring-Gerät vorgesehen sind, also nur eine weitere Kopie des Datenverkehrs bereit halten Vgl. Bejtlich 2004, S Vgl. Bejtlich 2004, S Vgl. Bejtlich 2005, S.106ff Seite 13

18 Kapitel 3 - Grundüberlegungen Anforderungen: Durch die Trennung von Sende- und Empfangsrichtung auf zwei Ports des TAPs ergibt sich für die Dimensionierung des Monitoring-Geräts, dass zwei Ethernet-Schnittstellen für die Monitoring-Daten vorzusehen sind. Ein Port würde hier nicht ausreichen, da dies zu einem unvollständigen Ergebnis führt. In vielen Szenarien ist der Einweg- Verkehr völlig nutzlos. An die Performance des Systems werden ähnliche Anforderungen gestellt wie beim Monitoring von Sende- und Empfangsrichtung durch zwei separate SPAN-Ports Aggregation-TAP: Da Regeneration-TAPs Monitoring-Geräte mit zwei Ports oder zusätzliche Hardware erfordern, wurden auch andere Modelle entwickelt, diese heißen Aggregation-TAPs. Diese aggregieren wie der Name schon vermuten lässt, mehrere Verbindungen auf einen Ausgang zum Monitoring-Gerät. Wie Abbildung 3-5 veranschaulicht, verfügen diese TAPs standardmäßig über drei Anschlüsse, zwei für die zu überwachende Verbindung und einen auf dem der zusammengefasste Verkehr zum Netzwerkprobe geleitet wird. Das spart an diesem einen Ethernet-Port und das spätere Zusammenfassen von Daten der Sende- und Empfangsrichtung. Da hier nur ein Port zur Verfügung steht, um den Verkehr einer Vollduplex-Verbindung zum Probe zu transportieren, können auch hier, ähnlich wie beim Einsatz eines SPAN-Ports, Paketverluste auftreten. Da der TAP völlig passiv arbeitet, gehen die Frames nicht in der überwachten Verbindung verloren, sondern nur dem Monitoring-Gerät. Um Paketverlust durch Spitzen im Netzwerkverkehr auszugleichen, verfügen die Geräte über unterschiedlich dimensionierte Puffer. Sollte jedoch eine dauerhaft hohe Last auf der Verbindung bestehen, laufen die Puffer voll und es kommt zu Paketverlusten für den Netzwerkprobe. Auch hier gibt es weitere Varianten der Geräte mit mehreren Monitoring-Ports. 20 Anforderungen: Beim Aggregation-TAP ist am Monitoring-Gerät nur ein Ethernet-Port pro überwachter Verbindung vorzusehen, also im einfachsten Fall nur einer. Da hier maximal 1Gbit/s an Datenrate anliegt, sind die Anforderungen an die Performance nicht ganz so hoch wie beim Einsatz eines Regeneration-TAPs. 20 Vgl. Bejtlich 2005, S.106ff Seite 14

19 Kapitel 3 - Grundüberlegungen Do-it-yourself TAP Neben professionellen TAPs der Hersteller werden im Internet Anleitungen gegeben, sich einen völlig passiven TAP für Kupfer Kabel selbst zu bauen, die sog. Do-it-yourself TAPs. 21 Passiv bezieht sich hier auf die Funktion ohne Spannungsversorgung. Bei dieser Konstruktion werden mittels eines Patchpanel zwei Ports gebrückt, an denen die zu überwachende Verbindung angeschlossen wird. Zusätzlich wird jeweils das Adernpaar der Senderichtung auf die Anschlüsse für die Empfangsrichtung eines separaten Ports gelegt, wie Abbildung 3-6 zeigt. So liegt an den zwei weiteren Ports je eine Richtung des Datenverkehrs an. Diese Konstruktion arbeitet ohne Spannungsversorgung, bringt aber einige Probleme mit sich. Anders als beim professionellen TAP findet in diesem Gerät keine Regenerierung der Signale statt. Dies kann bei längeren Kabeln und schlechter Kabelwege zum Problem werden, wenn in solch eine Verbindung auch noch ein selbst gebauter TAP eingebracht wird. Des Weiteren können Fehler entstehen, da diese Eigenbau-TAPs einzelne Adernpaare aufteilen, die im normalen Kabel in bestimmten Intervallen selbst und gegeneinander verdreht sind, um Nebensprechen und Rauschen zu reduzieren. Dieses Verhältnis wird hier gestört, da die Adern im Kabel zum Netzwerkprobe anders verdreht sind. Ein weiteres Problem ist, dass manche Netzwerkhardware auf bestimmten Adernpaaren Signale zur Autonegotation erwarten. Autonegotation wird eingesetzt um Informationen und Linkeigenschaften für den Betrieb einer Verbindung zwischen zwei Kommunikationspartnern auszuhandeln. 22 Fehlen diese Signale, kann die Verbindung fehlschlagen. Professionelle TAPs stellen diese Signale auch für die Monitoring-Ausgänge zur Verfügung. Abgesehen von diesen Nachteilen funktionieren diese TAPs ähnlich wie ein Regeneration-TAP, nur dass hier durch den Eigenbau eine enorme Fehlerquelle besteht. Die Literaturquellen raten vom Einsatz solcher Geräte in professionellen Umgebungen ab. 23 Konstruktionsbedingt funktionieren diese Geräte nicht bei Gigabit-Ethernet. Bei der Übertragung von Gigabit-Ethernet über Kupferkabel, werden anders als bei Fast-Ethernet alle Leitungspaare verwendet, d.h. es werden 4 Kanäle mit 250Mbit/s parallel benutzt. Das Entscheidende ist jedoch die simultane bidirektionale Übertragung auf diesen Kanälen. Das gleichzeitige Senden und Empfangen auf einem Kanal wird durch Echo-Cancelation erreicht. Durch Subtraktion des eigenen Sendesignals vom Gesamtsignal erhält man das Signal vom anderen 21 Vgl. Snort Vgl. Kemmler 1998, S Vgl. Bejtlich 2005, S.75 Seite 15

20 Kapitel 3 - Grundüberlegungen Sender. 24 Es ist also nicht so einfach möglich, die jeweiligen Sendeleitungen oder Kanäle auf einen anderen Anschluss zu brücken. Anforderungen: Die Anforderungen entsprechen denen eines Regeneration-TAP. Am Netzwerkprobe sind zwei Ethernet-Ports vorzusehen, dieser muss dann den Datenverkehr der beiden Richtungen dann nachträglich zusammenführen. Sollten diese TAPs bis zu hohen Übertragungsraten funktionieren, werden an die Performance genau so hohe Anforderungen gestellt wie bei Regeneration-TAPs für 100Mbit/s Inline-Monitoring-Systeme Bisher wurden nur Szenarien betrachtet, bei denen ein Gerät in eine Verbindung eingebracht wurde oder schon in der Verbindung war. Diese Komponente lieferte dann eine Kopie des Netzwerkverkehrs an das Monitoring-Gerät. Die in die Verbindung eingebrachten Komponenten arbeiten völlig passiv und das Mitschneiden oder Abhören des Verkehrs ist transparent für die Kommunikationspartner. Beim Inline- Monitoring jedoch wird eine Komponente in die Verbindung eingebracht, die den Verkehr nicht nur auf einen oder mehrere andere Ports kopiert, sondern ihn direkt verarbeitet. Diese Komponenten sind meist spezialisierte Server mit mehreren Netzwerkkarten. Diese Server sind dann die Monitoring-Systeme und greifen den Netzwerkverkehr direkt intern an den Karten ab. Der Vorteil dieser Systeme ist, dass sie sehr flexibel sind und dass keine weitere Hardware beschafft werden muss, die den Verkehr ausleitet. Da die Netzwerkkarten intern durch eine Softwarekomponente gebrückt sind, kann es hier leicht zu Problemen führen. Schon eine Umkonfiguration oder Fehlkonfiguration kann zum Abbruch der Verbindung oder zumindest zu Paketverlusten führen. Ist das Inline-Monitoring-System an einer Zentralen Stelle im Netzwerk positioniert wie z.b. in Abbildung 3-1, führt der Ausfall des Systems direkt zu einem Verlust der Gesamten Verbindung. Bei erhöhter Gesamtlast für das Gerät kann es auch zu einem Einbrechen der Übertragungsrate für die durchgeschleifte Verbindung kommen. Als Inline-Monitoring-Systeme kann man auch jeden Server betrachten, der Verkehr weiterleitet, zum Beispiel eine Firewall. Soll der Verkehr über solch ein Gerät betrachtet werden, so ist es relativ einfach, den Verkehr intern abzugreifen. Ein kurzfristiges Monitoring ist hier jedoch eher aufwändig, da wichtige Konfigurationen verändert werden müssen, was auch aus Sicherheitsgründen nicht möglich sein kann. 25 Anforderungen: Da hier die überwachte Verbindung direkt ans Monitoring-System, also den Netzwerkprobe angeschlossen wird, sind an diesem je zwei Schnittstellen pro überwachte Verbindung notwendig. Es werden jedoch hohe Anforderungen an die Performance gestellt, da die Verbindungen gebrückt werden müssen und die Daten intern noch verarbeitet werden sollen. Es ist darauf zu achten, dass auch bei maximaler Auslastung der Verbindungskapazität und somit hoher Last bei der internen Verarbeitung keine Einflüsse auf die Verbindung zu spüren sind. 3.2 Art der Messdaten Soll der Netzwerkprobe die Daten des Netzwerkverkehrs nicht nur zum Beispiel durch SNMP zur Abfrage bereit halten, sondern auch den Verkehr sammeln, eventuell verarbeiten und zum Auslesen durch andere Stellen im Netzwerk bereit halten, stellt dies besondere Anforderungen an die Hardware. Sollen die Daten archiviert werden, 24 Vgl. Kemmler 1998, S Vgl. Bejtlich 2004, S Seite 16