TECHNISCHE UNIVERSITÄT DRESDEN

Transkript

1 TECHNISCHE UNIVERSITÄT DRESDEN Fakultät für Informatik Institut für Systemarchitektur Professur für Rechnernetze Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Großer Beleg zum Thema Leistungsanalyse, Qualitätsüberwachung und Problemfrüherkennung in Rechnernetzwerken Eingereicht von: Daniel Rudolph Matr.-Nr.: Betreuer: Dr. rer. nat. Dietbert Gütter

2 2

3 Unterschriebene Aufgabe! 3

4 4

5 Erklärung Hiermit erkläre ich, Daniel Rudolph, den vorliegenden Großen Beleg mit dem Thema: Leistungsanalyse, Qualitätsüberwachung und Problemfrüherkennung in Rechnernetzwerken selbständig und ausschließlich unter Verwendung der im Quellenverzeichnis aufgeführten Literatur- und sonstigen Informationsquellen verfasst zu haben. Daniel Rudolph Dresden,

6 6

7 Inhaltsverzeichnis 1 Einleitung Historische Einordnung Netzwerkkomponenten Struktur und Hierarchie von Netzwerken Links, Netztopologie und eingesetzte Medien Vermittlungseinrichtungen Veraltete Vermittlungseinrichtungen Hubs und Repeater Switches und Bridges Router Adressierung in Netzwerken Abgrenzung des Themengebiets Unmanaged Networks Anforderungen an Netzwerkinstallationen Eingesetzte Protokolle und Strukturen Wie funktionieren Ethernet/IP Netzwerke Wie finden Ethernet Pakete ihren Weg Adressierung im Netzwerk Wie finden IP Pakete ihren Weg Aktuelle Ethernet Standards Qualität in Ethernet Netzen Definition und Einflussquellen Bandbreite Latenz Paketverluste Häufig verwendete, qualitätsrelevante Protokolle in Ethernet Netzwerken UDP ICMP SNMP TCP RTP Netflow und SFlow RMON und SMON Protokolle - Zusammenfassung Netzwerkelemente und ihr Einfluss auf die Netzwerkqualität Einfluss und Bedeutung von Links

8 Kupferkabel als Transportmedium Glasfaser als Transportmedium Bandbreite in Links Latenz in Links Packet Loss bzw. Fehlerraten in Links Einfluss von Nodes auf die Netzwerkqualität Wie werden Pakete in Nodes behandelt Faktoren für die wahrnehmbare Qualität von Nodes Bandbreite in Nodes Latenz bei Nodes Packet Loss bzw. Fehlerraten bei Nodes Einfluss und Bedeutung von Switches Historische Entwicklung von Switch-Vermittlungseinrichtungen Qualitätsrelevante Features und Methoden von Switches Bandbreite bei Switches bzw. Switch Ports Latenz bei Switches Packet Loss bzw. Fehlerraten bei Switches Bestimmen von Leistungs- und Qualitätskenngrößen für ein Ethernet Analyse und Vorstellung von verfügbaren Tools, Protokollen und Methoden Messmethoden und Protokolle Messmethoden und Protokolle für Messungen an zentralen Einrichtungen Methoden und Protokolle für Node-zu-Node-Messungen Messmethoden an einer Node Analyse und Übersicht zu Hard- und Softwaretools Toolklassen Tools für Messungen an einer Node traffic.cgi Iptraf Tcpdump Tools zur Node-zur-Node-Messung ICMP Ping Iperf Tools zur Paketgenerierung Packgen Ostinato

9 Ixia Tools Tools für zentrale Messungen und Überwachung Smokeping Nagios soltflowd Cacti WildPackets Tools ntop Tools zu Analyse von Paketaufzeichnungen Wireshark Tshark Experimentelle Bestimmung von Kenngrößen in der Praxis Vorgehensweise Messwerte Fazit Einordung der Kenngrößen und ihrer Bedeutung in einem Ethernet Relevanz und Einordnung der Kenngröße Bandbreite Relevanz und Einordnung von Paketverlusten im Ethernet Relevanz und Einordnung der Kenngröße Latenz sowie PDV Dauerhafte Qualitätsüberwachung und Früherkennung von Fehlern oder Engpässen Ethernet Funktionsweise und Konsequenzen für die Angreifbarkeit und Qualitätssicherung Eigenentwicklung eines Tools zur zentralen Netzwerküberwachung Motivation und Ziel Architektur Umsetzung Ausblick Leassons Learned Auswertung Zusammenfassung und Resümee Ausblick auf mögliche weitere Themenschwerpunkte in Leistungsanalyse und Qualitätsmanagement in Netzwerken Abbildungsverzeichnis Literaturverzeichnis Angang

10 10

11 1 Einleitung In dieser Arbeit werden Grundlagen vorgestellt und Methoden präsentiert, mit denen es sowohl möglich ist, eine Leistungsanalyse in einem Ethernet vorzunehmen als auch eine ständige Qualitätsüberwachung und Problemfrüherkennung. Ziel der Arbeit soll es daher sein, Methoden und Tools aufzuzeigen, mit denen eine Qualitätsanalyse und Qualitätssicherung möglich ist. Diese Informationen können dann zur Früherkennung und zur Vorbeugung vor Fehlern eingesetzt werden. Durch die Überwachung und Analyse wird zudem deutlich, an welchen Stellen ein Netzwerk ausgebaut werden sollte. In der Arbeit wird die Sicherungsschicht Ethernet in Wechselwirkung mit heute verwendeten Protokollen und Standards sowie den zeitgemäßen Anwendungen beleuchtet. Der Ethernet Standard hat sich von seiner Entstehungszeit 1985 bis zur heutigen Zeit als der Netzwerkstandard für lokale, aber auch überregionale Netzwerke durchgesetzt und hat damit Standards wie den token bus oder ATM in der Praxis verdrängt. In der Einleitung werden nach einer sich direkt anschließenden historischen Einordnung und einer kurzen Darstellung der Entwicklung des Ethernet Standards die Grundlagen eines Ethernet Netzwerks betrachtet und welche Elemente ein einem Ethernet vorzufinden sind. Abschließend wird in der Einleitung eine Abgrenzung des Themengebiets vorgenommen. Im folgenden Abschnitt werden Grundlagen beschrieben, die im Anschluss verwendet werden, um qualitätsrelevante Aspekte in Ethernet Netzwerken zu beschreiben. Dabei werden Begriffe und Größen etabliert, die es ermöglichen, Qualität in einem Ethernet vergleichbar und messbar zu machen. Des Weiteren werden wichtige Unterschiede für die in der Praxis eingesetzten Transport Protokolle, sowie der jeweilige Einfluss von Ethernet-Komponenten auf Qualität in einem Ethernet Netzwerk analysiert. Im Abschnitt Bestimmen von Leistungs- und Qualitätskenngrößen für ein Ethernet wird beschrieben, welche grundsätzlichen Herausforderungen bei der Bestimmung der vorgestellten Werte bestehen. Daraufhin wird eine die Analyse von verfügbaren Tools und deren eingesetzte Methoden dargestellt. Dabei wurden Tools auch im Hinblick auf mögliche Lücken in der Qualitätsüberwachung untersucht, um sie dann eventuell in der Eigenentwicklung schließen zu können. Auf die Analyse von Tools aufbauend werden im folgenden Verlauf experimentell bestimmte Kenngrößen kurz zusammengefasst. Diese Messungen sollen vor allem Aussagen aus dem voran gegangenen Abschnitt Qualität in Ethernet Netzen 11

12 Definition und Einflussquellen überprüfen und praktisch vorhandene Abhängigkeiten auch in ihrer Dimension aufzeigen. Weiterhin sollen Wege zur dauerhaften Qualitätsüberwachung sowie Fehlerfrüherkennung beschrieben werden. Diese Ausführungen gehen in einen Abschnitt der Problemanalyse über. Zusätzlich zu den durch die Analyse der Tools gewonnenen Ergebnissen sind insbesondere die Erfahrungen des Autors, die er bereits in seiner Tätigkeit als Administrator in Studentenwohnheimnetzen, Lan Partys und Firmennetzwerken gesammelt hat, in die Auswertung eingegangen. Weiterführend wird die Entwicklung eines eigenen Linux Monitoring Tools vorgestellt, welches zur Qualitätssicherung und Überwachung in einem Netzwerk ergänzend beitragen kann. Es soll zukünftig die Möglichkeit bieten, Bereiche und Eigenschaften von Netzwerken zentral zu überwachen, welche von den analysierten Tools bisher nicht erschlossen wurden. Abschließend werden die gewonnen Erkenntnisse zusammengefasst und bewertet, wobei ebenfalls ein Ausblick auf mögliche Detailthemen, die gegebenenfalls in weiterführenden Arbeiten vertieft werden sollten, aufgezeigt wird. 12

13 1.1 Historische Einordnung Erstmalig fand der Begriff Ethernet Erwähnung in einem Memo 1973, geschrieben von Bob Metcalive am Xerox PARC [1]. Der noch im gleichen Jahr gebaute Prototyp schaffte es auf eine Bandbreite von 2,94 Mbps. Bob Metcalive gründete 1979 die Firma 3COM, um dieses Ethernet zu kommerzialisieren. [2] In den folgenden Jahren entstanden die wichtigen [3] IEEE Standards in Zusammenarbeit von verschiedenen Firmen. Diese IEEE 802.3x Standards sicherten die Grundlage für das kompatible Ethernet, so wie es noch heute im Einsatz ist [3]. Der Begriff Ethernet Beschreibt eine Familie von Protokollen für den Einsatz in lokalen Computernetzwerken, welche Packet basierte Netze in verschiedensten Ausbaustufen beschreiben [4]. Seit den Anfängen haben sich die Anforderungen an Netze ständig durch neue Anwendungen, die diese Netze genutzt haben, geändert. Sie wurden dabei nicht nur schneller, sondern auch robuster, einfacher zu warten und zu installieren [4]. Abbildung 1 - Netzwerkstandard Entwicklung und Einordnung [5] Insbesondere in den letzten 10 Jahren wandelte sich das Ethernet immer mehr zum schnellen Allzweckstandard, der Speziallösungen verschwinden lässt[4]. War es 1990 noch 10Base-T, ist es 2006 schon 10GBase-T (Abbildung 1). Damit ist die Entwicklung nicht abgeschlossen, die Ethernet Alliance [5] gibt schon jetzt den Ausblick auf Terrabit Ethernet [5]. Im Juli 2010 wurde bereits ein 100 Gbit beziehungsweise ein 40Gbit Standard für die Verwendung in zentralen Vermittlungseinrichtungen verabschiedet. Mittlerweile gibt es auch erste Geräte, die diese Standards auf dem Markt implementieren. 13

14 Insgesamt kann festgehalten werden, dass dieser Wandel von immer höheren Anforderungen an das Ethernet durch neue Dienste und Anwendungsfälle ausgelöst und getrieben wurde. Ein prominentes Beispiel für diesen Wandel ist die Zunahme von Echtzeitprotokollen im Netzwerk, wie zum Beispiel in der Echtzeitsprachübermittlung, auch VOIP genannt. Durch diese neuen Einsatzgebiete werden neue Anforderungen an ein Netzwerk gestellt: Pakete möglichst in Echtzeit und ohne Paketverlust von einem Teilnehmer (Node) zum anderen zu übertragen. Auch andere Dienste, wie zum Beispiel moderne Domain Controller, YouTube oder generell Videoübertragungen belasten die Netze und stellen somit neue Anforderungen an Rechenzentren, großen Unternehmen, aber auch an das Heim Netz eines Anwenders [6]. Dabei ist das Ethernet mittlerweile zum allgemeinen Datennetzwerk geworden und VOIP Datenverkehr existiert parallel zu hochgradig bandbreitenrelevanten Dienste wie Backup oder Videostreaming. Damit ist Ethernet ein Medium, auf dem zeitkritische Anwendungen parallel mit sehr datenintensiven Anwendungen gleichzeitig funktionieren sollen. Als ein weiteres Beispiel kann das HD Fernsehen genannt werden. Wird dieses live über das Internet übertragen, ist bei bis zu 10MBit Bitrate pro HTPV MPEG4 Stream [7] selbst zu Hause ein modernes Netz nötig, um dieses bis zum Endgerät übertragen zu können. Weiterhin schaffen viele größere Einrichtungen ihr vom Ethernet getrenntes Telefonnetz ab und ersetzen es durch VOIP Installationen, um Kosten zu sparen und Netze zu konsolidieren. Wichtig dabei bleibt der universelle Charakter des Ethernets, bei dem sich viele parallele VOIP Streams mit datenintensiven Datenaustausch in demselben Netz reibungslos mischen können. Diese Beispiele sollen eine kurzen Einblick über die Entwicklungen geben, generell kann festgehalten werden, dass in allen Bereichen immer modernere Netze benötigt werden, um die Erwartungen der Nutzer erfüllen zu können. Gerade die immer höheren Geschwindigkeiten und ihre vom Nutzer empfundene Selbstverständlichkeit stellen Netzwerke vor neuen Herausforderungen [6]. Wie bereits erwähnt spielt das Wohnheimnetzwerk der TU Dresden für die vorliegende Arbeit eine wesentliche Rolle. So war die gesamte TU Dresden von Dezember 2000 bis 2006 mit 622 Mbps an das DFN angeschlossen, 2006 waren es dann 10 Gbps, Gbps und 2009 bereits 30 Gbps. Aber auch im lokalen Netzwerk wurde die Bandbreite erhöht. Im Jahr 2000 waren die Core Router im Campus Bereich noch mit 155 Mbps angebunden. Ab 2003 wurde das Netz auf 1Gbps im Backbone Bereich erhöht und ist nun in einzelnen Bereichen bis auf 20Gbit ausgebaut. Das Beispiel der TU Dresden verdeutlicht, dass der Bedarf für schnelle und kosteneffiziente Netzwerke allgegenwärtig ist. Dabei wachsen nicht nur die Anforderungen an lokale Netze, sondern auch Anforderungen an das Internet. 14

15 Ein schneller Datenaustausch ist dabei nur noch eine Komponente in Qualitätsbetrachtungen von lokalen Netzwerken. Anforderungsprofile an Netze sind vielfältig und werden vor allem von Nutzern oder dem Anwendungsfall bestimmt. Ethernet hat sich in den letzten 10 Jahren aufgrund seiner Performance und Flexibilität zu dem Standard entwickelt, mit dem die meisten Netze betrieben werden. Dabei hat Ethernet andere Standards wie ATM auch in Wide Area Netzwerken aufgrund geringerer Kosten verdrängt [4] 1.2 Netzwerkkomponenten Ein Ethernet besteht aus 3 Komponenten: Endgeräten (Nodes), Vermittlungseinrichtungen und ein Medium, welches diese verbindet (Link). Aus diesen Grundkomponenten können beliebig komplexe Netzwerke aufgebaut werden. Endgeräte (Nodes) sind dabei PC, Laptops, Server, Industrieanlagen und andere Geräte, die jeweils durch ihre MAC (Media Access Control Adresse) im Netzwerksegment adressierbar sind. MAC Adressen sind die eindeutige Hardwareadressen einer Nodes und dienen zur Identifizierung im Netzwerk. Diese Adresse besteht aus zwei Teilen und ist in 6 Bytes codiert. Die ersten 3 Bytes beschreiben den Hersteller, die folgenden 3 Bytes vergibt der Hersteller [4]. Das Medium, hier beschrieben als ein Link, verbindet jeweils ein Node mit einem Vermittlungselement oder Vermittlungselemente untereinander. Betrachtet werden dabei in dieser Arbeit Links in einer Stern-Topologie, welche sich heutzutage durch viele Vorteile bezüglich Leistungsfähigkeit und Ausfallsicherheit durchgesetzt hat. Die vor Jahren noch relevanten Mehrkosten sind heute nicht mehr vorhanden oder vernachlässigbar [4]. Abbildung 2 - Stern Struktur mit Switches [14] 15

16 Vermittlungseinrichtungen sind Router, Switches, Hubs, Bridges und ähnliche Einrichtungen, die definitionsbedingt mindestens 2 logische Links über ein Medium in das Netzwerk haben. Vermittlungseinrichtungen vermitteln Pakete von einem Link zu einem anderen Link. Auf die genaue Funktionsweise und Unterschiede zwischen diesen Vermittlungseinrichtungen soll nur im qualitätsrelevanten Einzelfall eingegangen werden, hervorzuheben ist, dass sie selbst nicht im Netz adressierbar sein müssen. Vermittlungseinrichtungen sind dabei die Zentralenpunkte eines Netzwerks, die die Endgeräte miteinander verbinden Struktur und Hierarchie von Netzwerken Netze sind in Netzwerksegmente (Broadcast Domains) aufgeteilt [8]. Alle Nodes in demselben Segment können direkt über das Ethernet miteinander kommunizieren und nutzen zur Adressierung die MAC Adressen. Alle Nodes, die über Switches miteinander verbunden sind, sind Teilnehmer in derselben Broadcast Domain. Router grenzen zum Beispiel diese Broadcast Domains voneinander ab und vermitteln Pakete in fremde Netzwerksegmente, die für eine lokale Node nicht per MAC adressierbar sind, sondern nur per IP. Netze haben daher durch ihre logische Struktur und Adressierung klar festgelegte Übergangspunkte in andere Netzwerke. Es gilt der Grundsatz, dass die jeweils kleinere Hierarchie administrativ so vom Netzwerk darüber isoliert wird, sodass es keine Störungen verursachen kann. Durch die Kapslung der Pakete in das Transport Protokoll IP ist ein Austausch zwischen den verschiedenen Netzen nahezu problemlos möglich. Durch ihre Zentralität sind diese Übergangspunkte in ein jeweils anderes Netzwerk sehr gut administrierbar und haben oft die Aufgabe, die zwei so miteinander verbundenen Netze logisch zu trennen. So werden zum Beispiel keine lokalen Broadcasts in das andere Netz übertragen. Ihre Zentralität steht dabei nicht im Widerspruch mit Ausfallsicherheit, welche in paketbasierten Netzen durch Redundanz gut sicherzustellen ist. Diese Übergabepunkte eignen sich daher aus zahlreichen Gründen auch hervorragend für administrative Maßnahmen wie Zwangsproxys, Firewalls, Authentication oder Qualitätsmessungen. Heutzutage werden bei dem strukturellen Entwurf und der Gestaltung von Netzwerken Normen berücksichtigt, die in jeweils verschiedenen geographischen Regionen Gültigkeit haben, vom Inhalt jedoch ähnlich sind [9]. - EN (1995): Informationstechnik: Anwendungsneutrale Verkabelungssysteme - ISO/IEC (1995): Generic cabling for customer premises Diese Normen garantieren ein zukunftssicheres Netzwerkdesign mit einer hohen Ausfallsicherheit und Flexibilität. Fehler wirken sich nur lokal aus, jeder angeschlossene Arbeitsplatz hat sein eigenes Kabel. Man spricht bei dieser Vorgehensweise auch von strukturierter Verkabelung, in den Normen wird die Verkabelung in folgende Bereiche geteilt [9]: 16

17 - den Primär- oder Campusbereich für die Verbindung der Gebäude eines Standortes untereinander - den Sekundär- oder Steigbereich für die Verbindung der einzelnen Etagen eines Gebäudes - den Tertiär- oder Horizontalbereich für die Verbindung der Anschlusseinheiten wie die Wand Dose mit dem Etagenverteiler - den Arbeitsplatzbereich für den Anschluss der Endgeräte an die Anschlusseinheiten In allen drei Bereichen der Inhouse-Verkabelung (oft auch Ebenen genannt) können sowohl Verkabelung mit symmetrischen Kupferkabel (Twisted Pair) als auch mit Lichtwellenleiterkabel verwendet werden. Im Campusbereich werden ausschließlich LWL-Kabel und -Komponenten verwendet [9]. Abbildung 3 - Strukturierte Verkabelung - Verbindungen [12] Betrachtet man die daraus entstehende Konsequenz für Qualitätsbetrachtungen in Netzwerken, gibt es einige wenige zentrale Punkte, die sich gut überwachen lassen und die für die Netzwerkqualität in Verbindung von nicht lokalen Netzwerkzugriffen alleinig ausschlaggebend sind. Sind diese zentralen Punkte oder der Dienst, den eine Node nutzen möchte überlastet, ist das Problem zentral am Übergabepunkt vorhanden und muss dort durch Strukturänderungen oder Ausbau gelöst werden. Wichtig ist festzustellen, dass ein Netz verschiedene Transitpunkte haben kann, welche die Verbindung in andere Netzwerke sicherstellt. Dieser Transit ist gut zu administrieren und zu kontrollieren. Verschiedenste Anbieter vermarkten Hardwarelösungen für die unterschiedlichen Bereiche der strukturierten Verkabelung, die jeweils auf die Anforderungen angepasst sind und daher mit möglichst geringen Kosten eine passende Lösung bereitstellen (Exemplarisch Cisco Campus Network for High Availability Design Guide [10]). 17

18 1.2.2 Links, Netztopologie und eingesetzte Medien Ein wichtiges Merkmal für ein Netzwerk ist die Topologie, mit der es aufgebaut ist sowie das eingesetzte Medium. Beide hängen eng zusammen und haben sich über die Zeit sehr verändert [8]. Erste Ethernet Netzwerke waren Bus Systeme mit Coaxial-Kabel, dem so genannten Thick Ethernet. Diese Verbindungen waren Half-Duplex, derselbe Bus (damit dieselbe Collision Domain) wurde von allen Teilnehmern verwendet. Hat ein Teilnehmer etwas gesendet, gab es die Gefahr einer Kollision auf der Leitung, welche durch CDMA/CS (Definiert in von IEEE [3]) erkannt und ausgeglichen wurde. Insgesamt skaliert das Verfahren nicht gut mit der Anzahl von Nodes in einer Collision Domain [4]: Durch den Einsatz von Switches können diese Segmente aufgeteilt werden und einzelne Collision Domains werden gebildet. Dabei spricht man von einer Stern- Topologie, welche es ermöglicht, Netzwerke mit einer größeren Anzahl von Nodes zu betreiben (siehe Abbildung 2). Im Half-Duplex Verfahren konkurriert die Node bei jedem Paket, welches sie schicken möchte, potentiell mit Paketen, die an sie geschickt wurden. Pakete an die Node und von der Node werden auf demselben Medium transportiert. Diese Eigenschaft von Half Duplex führt schon bei geringer Belastung des Links zum Einbruch der Netzwerkqualität. Auch hier wird das Problem durch die mäßige Skalierung von CDMA/CS im Fehlerfall verursacht. Qualität kann für Nodes, die Half Duplex angebunden sind, nicht zugesichert werden und dementsprechend werden heute auch nur noch Full Duplex Verbindungen eingesetzt [4]. Benutzt ein Netz dennoch Half Duplex Verbindungen, so ist bei Qualitätsproblemen ein Umstieg auf Full Duplex zu empfehlen. Aufgrund der enormen Bedeutung von Full Duplex Verbindungen heutzutage finden in der vorliegenden Arbeit vor allem die Stern-Typologien und kabelgebundenen Full Duplex Verbindungen Beachtung. Die in folgenden Kapiteln vorgestellten Messmethoden können auch auf Half Duplex Verbindungen angewendet werden, jedoch sind verlässliche Aussagen aufgrund der möglichen Kollisionen nicht zu treffen. In der strukturierten Verkabelung sind daher Half Duplex allenfalls nur im Tertiär Bereich einsetzbar (siehe Abbildung 3). Durch den Einsatz von Full-Duplex Verbindungen in den Links wird dieses Problem vermieden und der Node steht für Empfang und Versand von Daten jeweils die volle Bandbreite zur Verfügung. Kombiniert man die Stern-Topologie mit Full-Duplex Links, steht jeder Node bis zum Switch immer dediziert die maximal für den Link verfügbare Bandbreite jeweils in beide Richtungen unabhängig zur Verfügung. Ist eine Node über einen 100MBit Full Duplex Link angebunden, kann die Node gleichzeig Daten mit 100MBit empfangen und senden. Sie kann also bis zu 200MBit Netzwerkdaten verarbeiten. Wichtig wird dadurch zudem, dass eine Vermittlungseinheit Daten intern schnell genug 18

19 verarbeiten kann, um möglichst alle von ihr verbundenen Links gleichzeitig mit der maximalen Bandbreite verwalten zu können Vermittlungseinrichtungen Netzwerke können verschiedene Vermittlungseinrichtungen verwenden. Diese haben teilweise nur noch historische Relevanz und werden heute nicht mehr eingesetzt. Im Folgenden werden die wichtigsten kurz vorgestellt Veraltete Vermittlungseinrichtungen Hubs und Repeater Hubs und Repeater senden ein Paket auf allen Links, mit denen sie verbunden sind, weiter. Ausnahme sind die Links, die den Ursprung des Pakets darstellen. Damit teilen sich alle über eine solche Vermittlungseinheit verbundenen Nodes die gesamte verfügbare Bandbreite im Netzwerk durch das CDMA/CS Verfahren. Werden diese Verfahren eingesetzt, so ist eine Qualitätssicherung durch Konfiguration im Netz nicht möglich. Es entstehen Collision Domains, in denen eine garantierte Zusage über die verfügbare Bandbreite nicht mehr getroffen werden kann. Man geht in einer umstrittenen Faustregel von bis zu 60% Einbußen von der Gesamtbandbreite aus, wenn viele Nodes sich eine Collision Domain teilen [4]. Dieser Wert ist jedoch umstritten, andere Untersuchungen wollen einen maximalen Verlust von 10% gemessen haben [4]. Geschichtlich sind Hubs die preiswertesten Vermittlungseinrichtungen, werden jedoch aufgrund der begrenzten Leistungsfähigkeit und Skalierungsprobleme sowie dem starken Preisverfall bezüglich der Anschaffungskosten von Vermittlungseinrichtungen heutzutage nicht mehr eingesetzt [4] Switches und Bridges Switches, beziehungsweise Multiport Bridges, schicken Pakete nur auf Links weiter, von denen sie annehmen, dass sich in dieser Richtung der Adressat eines Pakets befindet. Switches lernen durch so genanntes backtracking der Pakete, die sie vermitteln, an welchem Link welche MAC Adresse erreichbar ist [4]. Dieses lernen geschieht durch das Auswerten der Quell Mac Adressen in den Paketen. Wird daraus entstehende Tabelle zu groß, so wechselt er zur Funktionsweise eines Hubs, wobei Einträge nach gewisser Zeit verfallen. Hat ein Switch noch keinen Link gelernt, an dem eine von einem Paket adressierte MAC zu finden ist, schickt dieser das Paket wie ein HUB an alle seine Verbindungen weiter. Heute können Switches bereits etwa MAC Einträge behalten (Angabe Cisco Datenblatt [11]). Switches beschränken sich heute nicht mehr nur auf Layer 2 im OSI Modell (siehe Abbildung 6) mittlerweile sind entgegen zur Darstellung in Abbildung 6 auch Mischformen von Router und Switch möglich. Switches analysieren dabei die Transportprotokoll IP oder sogar die TCP-Daten, um Switch- Vermittlungsentscheidungen besser treffen zu können. Durch diese zusätzliche Funktion werden viele administrative Aufgaben wie Quality of Service für Dienste oder auch sicherheitsrelevante Aspekte in einem Switch realisierbar, die durch den Mehraufwand infolge des Beachtens von zusätzlichen Regeln entstehen. Abgeleitet von der OSI Schicht, die ein so erweiterter Switch noch mit beachtet, spricht man dann vom Layer 3 Switch oder gar Layer 4,5,6,7 Switch. Grundsätzlich waren Layer 19

20 3 Switches zuerst eine Marketingerfindung, haben aber heutzutage durchaus ihre Berechtigung durch Funktionalität [4]. Weitere Informationen dazu werden im Abschnitt Qualitätsrelevante Features und Methoden von Switches vorgestellt Router Ein Router ist eine Vermittlungseinrichtung, die nicht mehr anhand von MAC Adressen entscheidet, zu welchem Link welches Paket vermittelt werden muss, sondern anhand von IP Zieladressen und Routingtabellen. Damit entscheidet ein Router nicht aufgrund der Sicherungsschicht, wohin ein Paket geht, sondern anhand der Vermittlungsschicht (siehe Abbildung 4). Wie IP Routing funktioniert, soll hier nicht näher erklärt werden, da es keinen neuen direkten Einfluss auf Qualitätsbetrachtungen in den betrachteten lokalen Netzwerken hat. Generell treffen bei Routern ähnliche Qualitätsbetrachtungen wie auch in einem Switch zu; lediglich Vermittlungsentscheidungen sind noch komplexer. Routing in IP Netzen wird in den RFC [12] und [12] beschrieben. 1.3 Adressierung in Netzwerken Alle im Netzwerk vorhandenen Nodes können in demselben Netzwerksegment direkt über ihre MAC im Ethernet adressiert werden. Im vorgestellten Stack hat jede Node mindestens noch eine andere Adresse: eine IP. Eine IP kann über Netzwerksegmente hinaus eindeutig sein. Dabei kann sie global eindeutig sein oder auch für private Netzte vorgesehen sein: [12]. Diese privaten IP Adressen unterscheiden sich von der Adressierung und ihren Eigenschaften nicht von globalen; es wird lediglich davon ausgegangen, dass Router Pakete mit diesen privaten Adressen als Absender aus lokalen Netzen nicht in Netze mit globalen IPs weitergeleiten. Im TCP/IP Stack erfolgt die Adressierung nur über IP Adressen und nicht über MAC Adressen. Möchte eine Node erfahren, welche MAC die Node mit einer bestimmten IP hat, benutzt diese dazu das ARP Protokoll. Dieses Protokoll ermittelt in einem Netzwerksegment per Broadcast, welche MAC eine Node mit einer bestimmten IP hat ( [12]). 1.4 Abgrenzung des Themengebiets In dieser Arbeit werden nur Netze betrachtet, die den Ethernet Standard einsetzen und daher im OSI Modell in der Sicherungsschicht aber auch Bitübertragungsschicht Ethernet einsetzen (siehe Abbildung 4). Dabei sollen Details zu Protokollen und Standards nicht vertieft werden, auf diese wird im speziellen Anwendungsfall verwiesen. Details können in den jeweiligen RFC und IEEE Standards nachgelesen werden. Der Ethernet Standard zeichnet sich vor allem durch seine Flexibilität und möglichen Adaptionen für neue Anwendungsgebiete aus. Diese Stärke hat allerdings zur Folge, dass es eine sehr hohe Anzahl von Standards und Versionen in diesen Standards gibt. Viele davon werden heute nicht mehr verwendet und haben an 20

21 Bedeutung verloren. Diese Arbeit soll sich daher auf moderne Netze beschränken und wird historisch relevante Probleme nicht vertiefen. Ethernet funktioniert technisch in kleinen Netzen ebenso wie auch in sehr großen Netzen mit tausenden Nodes. Prinzipiell gibt es dabei den entscheidenden Unterschied, ob ein lokales Netzwerk auf der Sicherungsschicht administriert und verwaltet wird oder ob die Netzwerkhardware die einkommenden Pakete nach Best Effort weiterleitet. In Firmen oder großen Organisationen kommt meist Technik zum Einsatz, die selbst großen Einfluss auf die Sicherungsschicht hat und also administrierbar ist, um auch hier die Qualität des Netzes direkt beeinflussen zu können. Im Datacenter ist ein Einsatz dieser administrierbaren Komponenten unverzichtbar [4]. In der Praxis haben sich daher verschiedene Ausbaustufen und Größen von Ethernet Netzwerken herausgebildet, die jeweils unterschiedliche Anforderungen erfüllen und unterschiedliche Hardware einsetzen. In kleinen Netzen, wie zum Beispiel zu Hause werden oft nur 1-3 unmanaged Switches eingesetzt, die aufgrund fehlender Kenntnisse beim Anwender mehr oder weniger zufällig miteinander verbunden sind. Maßgaben wie Strukturierte Verkabelung spielen in diesen Netzen keine Rolle. Als Router in das Internet wird oft die vom Provider zur Verfügung gestellte Standardhardware eingesetzt, welche oft Router und Switch in einer Einheit darstellt. Eine Administration findet quasi nicht statt. In mittelgroßen Netzen werden Häuser oder größere Büros vernetzt. Dort findet man meist einen zentralen managed Switch, von dem aus das Ethernet in verschiedene Räume oder direkt an Arbeitsplätze verteilt wird. In den Zimmern selbst sind oft nochmals kleine unmanaged Switches, welche nur die Verteilung im Büro übernehmen. Auch in diesen Netzwerken sind oft bis zu 100 Nodes in einem Netzwerk aktiv. In diesen Netzen gibt es nur selten Netzwerkadministratoren in Vollzeitbeschäftigung, diese Aufgabe wird meist durch Administratoren bearbeitet, die zusätzlich noch völlig andere Aufgabenbereiche betreuen. In großen Netzwerken ist es unverzichtbar, die Strukturierte Verkabelung zu beachten und verschiedene Ebenen einzuführen. In großen Netzwerken kommen fast nur managed Switches zum Einsatz. Das Einbringen von unmanaged Switch durch zum Beispiel Mitarbeiter ist von Netzwerkadministratoren dabei oft nur sehr ungern gesehen und wird oftmals unterbunden. Diese Eingriffe bedeuten immer eine mögliche unberechenbare Störquelle. Für den Betrieb eines großen Netzwerks sind Vollzeit-Netzwerkadministratoren unerlässlich Unmanaged Networks Ist ein Netz nicht in der Sicherungsschicht administrierbar oder wird dort nicht administriert, spricht man von einem unmanaged Network [4]. In diesem Falle können die hier vorgestellten Methoden nur aufzeigen, wie man Qualität bestimmen sowie Schwachstellen erkennen kann. 21

22 Vorrangig sind kleine Netze unmanaged Networks, bei größeren Netzwerken ist es heutzutage üblich, Managed Networks einzusetzen, unter anderem weil auch die dafür notwendige Hardware immer preiswerter geworden ist [8] [9] [4]. Ein nicht administriertes Netz so abzusichern, dass es von Störquellen nicht negativ beeinflusst werden kann, ist nicht möglich. In einem nicht administrierten Netz sind alle Endgeräte (Nodes) darauf angewiesen, dass alle anderen Endgeräte das Netzwerk fair nutzen bzw. nicht absichtlich missbrauchen. Qualität kann also nicht garantiert werden. Diese Einschränkung ist eine direkte Konsequenz aus der Grundeigenschaft des Ethernets, Pakete im Netzwerk ohne Garantie zu vermitteln. Diese Schwäche ist in nicht administrierten Netzen ein Problem und überträgt sich naturgemäß noch stärker auf alle nicht kabelgebundenen Netze, wo ein Saturieren des genutzten Spektrums mit Störsignalen unweigerlich zu einer Störung führt. Nicht kabelgebundene Netzwerke werden in dieser Arbeit daher nicht betrachtet. Grundsätzlich sind die vorgestellten Messmethoden einsetzbar, verlässliche Aussagen sind durch die Schwankungen durch das Medium Luft (z.b. Interferenzen mit anderen Funknetzwerken oder anderen Signalquellen) jedoch nicht möglich. In nicht administrierten Netzen ist die messbare Qualität daher direkt von der eingesetzten Technik, ihren Kenngrößen sowie der momentanen Belastung des Netzes durch (andere) Nodes abhängig Anforderungen an Netzwerkinstallationen Um Qualitätsaussagen zu einem Netzwerk treffen zu können, ist es wichtig, eventuelle Fehlerquellen ausfindig zu machen, bei denen die eingesetzte Technik nicht optimal funktioniert und nun erhöhte Fehlerraten aufweist. In den Betrachtungen dieser Arbeit wird vorausgesetzt, dass die eingesetzte Hardware in den Nodes als Medium oder in Vermittlungseinrichtungen ordnungsgemäß funktioniert. Fehleranalyse von physikalischen Fehlern soll dabei nur eine untergeordnete Rolle spielen und wird nur am Rande betrachtet. Werden die Kennwerte in einem Netzwerk schlechter, kann dies auch immer ein Indiz dafür sein, dass Hardwaredefekte aufgetreten sind. Insgesamt ist es mit den vorgestellten Methoden zur Qualitätsüberwachung problemlos möglich, eine Klasse von Fehlern durch messbaren Qualitätsverlust erkennbar zu machen und eine Problemfrüherkennung kann durch die in der Arbeit vorgestellten Tools und Methoden erreicht werden Eingesetzte Protokolle und Strukturen Netzwerke sind struktur- und protokollbedingt immer in einer Hierarchie aufgebaut. Betrachtet werden Netze, in denen Ethernet und Internet Protokoll V4 (IP) gesprochen wird. Ethernet ist dabei die Sicherungsschicht, IP die Vermittlungsschicht und Protokolle wie UDP oder TCP die Transportschicht. Als Vermittlungs- und Transportschicht kommen heute fast ausschließlich IP und TCP zum Einsatz [9] [4]. Man spricht generell vom so genannten Internet, auch abgeleitet vom IP Protokoll, dem Internet Protocol. Verallgemeinert wird dies mit dem Ausdruck TCP/IP Stack. 22

23 Auf eine Betrachtung von IPV6 wird verzichtet. IPV6 hat keinen relevanten Einfluss auf die Netzwerkqualität in lokalen Netzen. Zudem ist eine große Marktakzeptanz auch 15 Jahre nach Verabschiedung des ersten Standards noch nicht spürbar oder vollständig absehbar. Ein erster Einsatz im Internet ist erkennbar, jedoch sind alle Features wie IPSEC, QOS, Autokonfiguration sind heutzutage auch in IPV4 Netzte zu finden, was eine sofortige Umstellung in lokalen Netzwerken überflüssig macht. Der größte Vorteil von IPV6 liegt im größeren Adressraum (Erweiterung von etwa 4,3 Milliarden auf etwa 340), wodurch eine eindeutige Adressierung eines jeden Geräts weltweit ohne Tricks wie NAT möglich würde. Diese Veränderung von IPV6 wird auch als Sicherheitsrisiko eingestuft und stellt neue Anforderungen an Hardware welche leitungsfähiger sein muss um vergleichbare Performance bei IPV4 und IPV6 zu erreichen. [4] [13] Zusammenfassend kann festgehalten werden, dass in dieser Arbeit Netze betrachtet werden, in denen der OSI Protokoll Stack verwendet wird (siehe Abbildung 4), die sich durch eine Stern-Topologie auszeichnen, kabelgebundene Full-Duplex Verbindungen als Links nutzen und deren Vermittlungseinrichtungen keine Hubs, sondern wie heutzutage üblich Switches berücksichtigen [4]. Netzqualität über das lokale Ethernet Netzwerk hinaus soll in dieser Arbeit nicht vertieft werden. Eine Qualitätsaussage zu einer Verbindung, die von einem lokalen Netzwerk über das Internet in ein anderes lokales Netzwerk geht, soll nur unter Idealbedingungen stattfinden. Qualitätsaussagen dieser Arbeit sind nur zutreffend, wenn eine vom Fremdanbieter gemietete Leitung zu jedem Zeitpunkt die Spezifikation, mit der sie gemietet bzw. ausgemessen wurde, erfüllt. 23

24 2 Wie funktionieren Ethernet/IP Netzwerke In diesem Abschnitt sollen inhaltliche Grundlagen geschaffen werden, die zum Verständnis von Qualitätsbetrachtungen im Ethernet, in dem IP in der Vermittlungsschicht eingesetzt wird, notwendig sind. Ethernet ist ein paketbasiertes Netz, in der Nodes miteinander kommunizieren, indem sie Pakete mit Daten zueinander schicken. Dabei gibt es vom Ethernet als Sicherungsschicht (Abbildung 4) keine Garantie, ob Pakete angekommen sind; diese Information sichert die im OSI Modell 2 Ebenen höher gelegene Transportschicht [4]. Abbildung 4 - Ethernet in den OSI Layern [10] Jede Node wird dabei mit einer MAC Adresse adressiert [4]. Ein Paket (siehe Abbildung 5) enthält dabei jeweils eine MAC Adresse, die den Sender repräsentiert und eine, die den Empfänger repräsentiert. Klassisch reagiert eine Empfänger Node nur auf Pakete, die an sie direkt oder alle Nodes geschickt wurden. In dem Ethernet Paket selbst wird durch den Ethertype identifiziert, welches Transport Protokoll in dem Paket verpackt wurde. Abbildung 5 - Layout der Ethernet Frames - ohne (oben) und mit VLAN Tagging [10] 24

25 Betrachtet man nur ein Ethernet Netzwerksegment für sich, so kann dieses Ethernet auch aus einer Hierarchie von Vermittlungselementen bestehen, jedoch kann jede Node mit jeder anderen Node in demselben Netzwerksegment kommunizieren. Pakete zwischen diesen Nodes sind im Netzwerksegment durch ihre Ziel MAC Adresse zustellbar. 2.1 Wie finden Ethernet Pakete ihren Weg In einem Ethernet ist jede Node eindeutig durch eine MAC adressierbar. Ein Paket hat daher eine MAC als Senderadresse sowie eine MAC als Zieladresse. Nodes erkennen anhand der MAC Zieladresse im Paket, ob ein ankommendes Paket für sie vorgesehen ist. Sie nehmen dabei auf dem Link, der zu ihnen führt, jedes Paket an, das an die MAC Adresse adressiert ist, die sie als ihre MAC Adresse für diesen Link kennen. Im Analysemodus kann man mit bestimmten Treibern oder teilweise spezialisierter Hardware auch dafür sorgen, dass eine Node sämtliche Pakete auf einem Link entgegen nimmt. Dieser promisc mode ist vor allem dann sinnvoll, wenn man ein Netzwerk überwachen oder generell Daten aufzeichnen möchte. Ein Netzwerk funktioniert also bereits, wenn alle Nodes alle Pakete bekommen. Wie bei der Funktionsweise von HUBs beschrieben, erzeugt dies eine unnötige Belastung im Netzwerk, da es für ein Paket zwischen jedem Sender und Empfänger einen jeweils kürzesten Weg gibt. Wird das Netzwerk nicht mehr mit allen Paketen geflutet, spricht man von einem vermittlungsorientiertem Netzwerk. Darin werden die Pakete bewusst von den Vermittlungseinrichtungen, wie zum Beispiel Switch so weitergeleitet, dass sie nicht auf allen Leitungen repliziert werden müssen, sondern nur jeweils auf dem Link gesendet werden, auf dem es sie erreicht. Den Weg, den das Paket dann durch das Netzwerk beschreibt, bezeichnet man als Route. Eine Route geht also von einer Node aus über verschiedene Vermittlungseinrichtungen und Links bis zu der adressierten Ziel Node. Wird eine Ziel Node per MAC adressiert, die sich nicht im Netzwerk befindet, wird das Paket durch das gesamte Netzwerk geleitet, das Netzwerk daher geflutet. Dieser Effekt entsteht daraus, dass Vermittlungseinrichtungen, wie zum Beispiel Switches, entscheiden, auf welchem Link ein Paket versendet werden soll. Das Fluten passiert auch dann in einer Vermittlungseinheit, wenn das Ziel noch nicht bekannt ist oder eine dafür reservierte Broadcast MAC Adresse angegeben wurde. 2.2 Adressierung im Netzwerk Alle Nodes können Broadcasts abschicken, die bedingt durch das Ethernet Protokoll zu allen anderen Nodes in demselben Netzwerksegment bzw. Broadcast Gruppe vermittelt werden müssen. Für diese Broadcasts sind verschiedene Ziel MAC Andressen definiert (z.b. FF:FF:FF:FF:FF:FF: [14]). Sobald eine solche Broadcast Adresse als Zieladresse angegeben wird, wird anzeigt, dass es sich bei dem Paket um ein Broadcast Paket handelt. Vermittlungseinrichtungen müssen 25

26 dieses Paket auf allen Links weiterleiten, die zu demselben Netzwerksegment gehören. Diese Broadcasts werden vom Address Resolution Protocol (ARP, [12]) benutzt, um für eine Node in einem Netzwerksegment die MAC Adresse einer Ziel Node zu bestimmen, die der Node bisher nur durch eine IPV4 Adresse bekannt ist. Das Protokoll sieht vor, dass eine Node sobald sie einen ARP Request für ihre eigene IPV4 Adresse sieht, diesen mit einem ARP Reply zu beantworten. Durch diese direkt gesendete Antwort erfährt die Node die MAC Adresse der Ziel Node. 2.3 Wie finden IP Pakete ihren Weg Durch die Vermittlungseinrichtung Router werden Pakete auch in andere IP Netze als das lokale Netz übermittelt. Pakete aus fremden Netzen kommen am Router an und werden dann vom Router per MAC adressiert an die lokale Node weitergeleitet. Die Nodes finden den Router durch einen ARP Request für seine IP; genauso findet der Router die MAC von Nodes, an die er Pakete vermitteln soll. Will eine Node ein IP Paket verschicken, kann diese aufgrund ihrer IP-Konfiguration selbst errechnen, ob sich die Ziel Node in demselben Netzwerksegment befindet. Adressiert eine Node eine Ziel Node im selben Netzwerksegment, benutzt sie ARP um die MAC der Node zu bestimmen um das Paket dann direkt per MAC zu adressieren. Ist die Ziel Node nicht im lokalen Netzwerksegment, bestimmt die Sender Node die MAC Adresse des, für dieses Zielnetzwerk relevanten Routers, durch seine IP und schickt das Paket dann direkt per MAC adressiert an den Router. Dabei ist im IP Layer weiter die Ziel IP aus dem fremden Netz angegeben, aber die lokalen MAC des Routers als Zieladresse im Ethernet Layer. Ein lokales Netzwerk kann daher keine IP Pakete vermitteln oder bestimmen, zu welcher Node sie im Ethernet Netzwerk gelangen sollen. Dies ist Aufgabe des IP Stacks, wobei Router die Aufgabe der Vermittlung der Pakete über lokale Netzwerkgrenzen hinaus übernehmen. Pakete im Ethernet sind immer direkt durch MAC-Adressen adressiert (schematische Darstellung des Stacks, siehe Abbildung 6). 26

27 Abbildung 6 - Schematische Darstellung des Stack - Phone <-> Switch <-> Router <-> Internet [10] Dieses Funktionsprinzip resultiert darin, dass ein Router ein sehr zentrales und besonders belastetes Element in einem Netzwerk ist. Daher sollte er sehr gut überwacht werden, ausreichend dimensioniert und gut an das Netzwerk angebunden sein [9]. 3 Aktuelle Ethernet Standards Ethernet Standards haben sich in den letzten Jahren rasant entwickelt. Die Bandbreite hat sich dabei von Standard zu Standard verzehnfacht. Schon bei 1000Base-T Ethernet mussten Kompromisse im Standard gemacht werden, damit CDMA/CS auf längeren (100m) Kabelverbindungen mit Cat5e Kabel weiterhin funktioniert [4] [8]. Damit eine Kollision erkannt werden kann, musste der Standard leicht angepasst werden. Dabei wird im Half Duplex Betrieb das Interframe Gap nach jedem Paket erhöht sowie die kleinste Paketgröße von 64Byte auf 512 Byte angehoben. Praktisch wird auch aus diesem Grund 1G nicht im Half Duplex Modus betrieben. Der neue Ethernet Standard für 10G Ethernet sieht eine Half Duplex Anbindung nicht mehr im Standard vor; CDMA/CS oder ein vergleichbares Verfahren wird nicht mehr unterstützt. Eine Übersicht von Ethernet Standards bis 10G findet man in im Anhang An einem Standard kann man die Geschwindigkeit aber auch das verwendete Medium und Steckverbindung ablesen. Als Beispiel beschreibt 100Base-TX 100MBit Ethernet über ein Twistet-Pair Kupfer Kabel und 100Base-FX 100MBit Ethernet über ein Glasfaserkabel. 27

28 Für 40G bzw. 100G Ethernet gibt es noch keinen verabschiedeten Standard, der auf einem Kupferkabel als Medium funktioniert, jedoch wurden im Juli 2010 Standards für eine Anbindung per Lichtwellenleiter ratifiziert als IEEE 802.3ba [3]. 4 Qualität in Ethernet Netzen Definition und Einflussquellen Ist eine Node an ein Netzwerk angebunden, hat sie nur eine Anforderung: Möglichst schnell und zuverlässig Daten mit allen anderen Nodes aus diesem Netzwerk austauschen [9]. Als Qualität gilt daher die Verfügbarkeit des Netzwerks für eine Node. Dabei ist es für eine Node wichtig, das Pakete (Daten), die abgeschickt werden, beim Adressaten ankommen und Pakete, die für die Node bestimmt sind, bei ihr ankommen. Spricht man von Qualität in einem Netzwerk, so betrachtet man daher verschiedene logische Verbindungen durch ein Netzwerk von einer Node über potentiell viele Vermittlungseinrichtungen zu einer anderen Node. Es existiert dementsprechend keine globale Netzwerkqualität. Die Qualität kann sich für jede Node aus dem Netzwerk in jedem Zeitpunkt anders darstellen. Dies ist abhängig davon, mit welcher anderen Node sie Daten austauschen möchte. Es ist jedoch bei diesen logischen Verbindungen nicht ausgeschlossen, dass dabei jedes vom Sender an den Empfänger geschickte Paket einen anderen Weg durch das Netzwerk nimmt. Praktisch ist dies im Ethernet funktionsbedingt in aktuellen Standards nicht der Fall. Die Qualität eines Netzwerks beschreibt daher die allgemeine Verfügbarkeit für alle Nodes, Pakete so über das Netzwerk austauschen zu können, wie es für ihre Anwendung wichtig ist. Ethernet Netzwerke haben drei Hauptmerkmale mit Einfluss auf die Netzwerkqualität: die verfügbare Bandbreite für einen Link, die Latenz für diesen Link sowie die Rate an Paketverlust (Packet Loss) auf diesem Link. Diese Merkmale sind jedoch stark zeitlichen Aspekt gebunden, da sie von der Auslastung abhängig sind. In paketbasierten Netzwerken wie dem Ethernet gibt es keine Garantien dafür, dass ein Paket, welches man ins Netzwerk übermittelt, beim adressierten Empfänger ankommt. Diese Garantie ist auf Netzwerkebene nicht zu treffen und wird erst durch die Transportschicht gegeben, im TCP/IP Stack zum Beispiel. durch das TCP Protokoll. Dabei sichert das jeweilige Transport Protokoll nicht einzelne Pakete, sondern implementiert Mechanismen, die einem Sender und auch Empfänger nach Aufbau einer Verbindung erkennen lassen, wenn Pakete verloren gegangen sind. Paketverluste werden dann direkt von der Transportschicht ausgeglichen. Ist ein Ausgleich nicht mehr möglich, bricht die Verbindung ab. 28

29 Verschiedene Dienste haben unterschiedliche Qualitätsanforderungen. Echtzeitprotokolle sind dabei am anspruchsvollsten und stehen damit bei Betrachtungen zur Optimierung im Mittelpunkt. Für Benutzer eines Netzwerks ist die Qualität zwischen ihm selbst und einem Dienst relevant. Insbesondere ist dabei der Weg interessant, den Pakete von einer Node, mit der der Nutzer arbeitet, zu einer anderen nehmen und welche Qualität auf diesem Weg sichergestellt werden kann. Aus diesem Grund fokussiert sich diese Arbeit auf die Möglichkeit, in diesem Zusammenhang Qualität in Ethernet Netzwerken beurteilen zu können. Jedes Paket durchläuft auf dem Weg durch das Netzwerk meist mehrere Links und dementsprechend auch verschiedene Vermittlungseinrichtungen wie Switches und Router. Jeder Link und jede Vermittlungseinrichtung auf dem Weg zwischen Absender und Empfänger spielen dabei in den Qualitätsbetrachtungen eine wesentliche Rolle, da jedes Element zur Verzögerung eines Pakets beitragen oder für einen Packet Loss verantwortlich sein kann. Ist ein Paket durch einen Defekt im Medium oder einer Störung auf dem Weg durch den Link verändert worden, kann dies durch den CRC Check erkannt werden. Ein defektes Paket wird von einem Switch nicht weiter vermittelt (Sonderfall Cut- Though-Switches), jedoch spätestens von der Empfänger Node ignoriert. Damit äußern sich defekte Pakete im Netzwerk genauso wie verlorene Pakete. Nachdem in den nächsten Abschnitten die 3 Kenngrößen kurz definiert und betrachtet werden, werden verschiedene Protokolle und ihre Relevanz für die Netzwerkqualität beschrieben. Danach wird der theoretische Einfluss auf die Netzwerkqualität von den verschiedenen Vermittlungseinrichtungen in einem Ethernet erläutert. Damit sollen die Grundlagen für die Analyse und Vorstellung von Tools und Messmethoden geschaffen werden, die sich daran anschließt. 4.1 Bandbreite Bandbreite beschreibt die maximale Anzahl von Bits pro Zeiteinheit, die auf einem Link auf dem Verbindungsmedium für den eingesetzten Ethernet Standard verschickt werden können. Daraus resultierend kann eine maximale Anzahl von Paketen mit der maximalen Größe die maximale Bandbreite auf einem Link errechnet werden. Wie in im Abschnitt Aktuelle Ethernet Standards gefordert gibt ein Ethernet Standard die Bandbreite im Namen bereits an. 1000Base-T beschreibt damit 1GBit/s auf einer Kupferkabelverbindung nach dem Standard Cat5e oder besser. Durch das Versenden von kleineren Paketen wird die Nettobandbreite geringer, da jedes Paket laut IEEE mit einer 7 Byte Präambel und einem 1 Byte SDF vorweg verschickt wird. Dazu kommen für jedes Paket 18 Byte Protokolldaten (Zieladresse, Quelladresse, Länge oder Typ sowie abschließend CRC) und abschließend dem Interframe Gap (IFG). Dieser Effekt wird in Abbildung 7 verdeutlicht. 29

30 Abbildung 7 - Bandbreiteneffizienz bei verschiedenen Paketgrößen [4] 4.2 Latenz Latenz beschreibt, wie lange es dauert, bis ein von einer Node oder einer Vermittlungseinrichtung abgeschicktes Paket am anderen Ende sichtbar geworden ist. Latenz kann von Paket zu Paket unterschiedlich sein, die so genannte packet delay variation (PDV) beschreibt diesen Unterschied. Eine hohe PDV ist vor allem bei Multimedia und anderen Echtzeitanwendungen kritisch, weil sich so Pakete überholen können, später als gebraucht oder früher als angenommen beim Empfänger ankommen. Es werden Puffer eingesetzt, die diesen Effekt ausgleichen. Je größer der Puffer ist, desto weniger Echtzeit ist der Datenstrom jedoch präsentierbar [15].Dieser Effekt ist vor allem bei Echtzeitprotokollen wie in der Telefonie (VOIP) am kritischsten und zu vermeiden. 4.3 Paketverluste Paketverluste (Packet Loss) beschreibt, wie viele abgeschickte Pakete nicht an der Ziel Node angekommen sind. Optimal liegt dieser Wert bei 0%; er hängt von der Auslastung des Netzwerk und jeder Vermittlungseinheit in diesem Netzwerk sowie der Auslastung der Ziel Node ab. Ist eine Vermittlungseinrichtung oder ein Link überlastet, gehen Pakete verloren. Dieser Effekt ist prinzipiell gewollt und gewünscht da es die technische Implementierung eines Netzes sehr vereinfacht, wenn diese Packet Loss von höheren Protokollschichten ausgeglichen werden. Die verbindungsorientierten IP Protokolle sind daher darauf eingestellt und benutzen diesen Effekt zur optimalen Auslastung eines Links oder Route durch das Netzwerk. 4.4 Häufig verwendete, qualitätsrelevante Protokolle in Ethernet Netzwerken Protokolle reagieren jeweils unterschiedlich auf verschiedene Kenngrößen. RTP oder auch TCP sind komplexe Protokolle, die in ihren Standardlösungen verschiedenste Szenarien implementieren. Im Folgenden werden ausgewählte Protokolle kurz vorgestellt und Unterschiede im Verhalten deutlich gemacht. Auf Details soll dabei nicht eingegangen werden, es wird jeweils auf die Standards verwiesen UDP Das User Datagram Protocol (UDP) ist ein einfaches unidirektionales verbindungsloses IP-basiertes Protokoll, welches Pakete ohne Flusskontrolle im 30

31 Netzwerk verschickt. ( [12]). Der Sender kann keine Informationen vom Protokoll ableiten, ob der Empfänger das Paket bekommen hat. Sollten durch Überlastung beim Empfänger oder auf dem Weg durch das Netzwerk Pakete verloren gehen, sind diese Daten verloren. Das Protokoll wird vor allem bei Streaming Anwendungen, Spielen und anderen zeitkritischen Anwendungen eingesetzt. Das Protokoll hat den Vorteil, dass im Gegensatz zu TCP das Programm direkt beeinflussen kann, welche Daten im nächsten Schritt verschickt werden sollen. Geraten das Netzwerk, der Sender oder Empfänger ins Stocken, wird nicht versucht, dies zu beheben. Vielmehr gehen Pakete verloren oder werden nicht verarbeitet ICMP Das Internet Control Message Protocol (ICMP) ist mit UDP vergleichbar und dient dem Transport von Fehlermeldungen außerhalb der anderen Protokolle ( [12]). Es wird daher von fast allen Nodes implementiert und wird durch die Eigenschaft interessant, dass eine Node einen ICMP Echo Request mit einem ICMP Echo Replay beantwortet SNMP Simple Network Management Protocol (SNMP) ist auch ein Verbindungsprotokoll, dass UDP ähnelt ( [12]). Ein SNMP Client kann dabei bei einem SNMP-Server SNMP-Werte aus einem über eine Management Information Base (MIB: [12]) definierten Wertebaum lesen und schreiben. Einige Switches können mit SNMP über SNMP-Schreibzugriffe administriert werden. Zudem und mit SNMP-Lesezugriffen verschiedenste Werte, wie zum Beispiel Fehlerzähler oder Paketzähler abgefragt werden. Hersteller implementieren die allgemein definierten MIBs nur teilweise und ergänzen den Baum durch eigene Funktionalität und Werte TCP Das verbindungsorientierte, bidirektionale Transmission Control Protocol (TCP) schafft es durch sehr komplexe Mechanismen, wie zum Beispiel TCP Slow Start, Congestion Avoidance, Fast Retransmit, und Fast Recovery, eine Route von einer Node zu anderen optimal auszulasten. ( [12], [12], [12]). TCP benutzt Informationen über die Round Trip Time (RTT) von Paketen genauso zur optimalen Auslastung wie auch Puffer bei Sender und Empfänger. TCP gleicht Effekte wie fehlerhafte Pakete, Packet Loss oder ähnliches automatisch auf Protokollebene aus RTP Das Real-time Transport Protocol (RTP), welches auch bei VOIP eingesetzt wird, ist dagegen nicht verbindungsorientiert und bringt kein eigenes Transportprotokoll mit ( [12]). In der Praxis wird es in der Regel mit UDP benutzt, um einen Real Time Stream zu übertragen. RTP kann dabei keine Zusicherungen über Latenzen oder Jitter im Netzwerk machen. Vielmehr werden die nötigen Mechanismen zur Verfügung gestellt, um diese Informationen wie Latenz, Jitter und Packet Loss für eine laufende Session sichtbar zu machen. Anwendungen 31

32 können dann Puffer oder gar Codec anpassen, sollten die Leitungswerte nicht mehr den Anforderungen eines bestimmten Codecs genügen Netflow und SFlow Das Netflow Protokoll ( [12]) und das SFlow Protokoll ( sind 2 Protokolle, mit denen die, Verbindungseinrichtungen die Möglichkeit erhalten, Statistiken über ihre Paketflüsse an andere Nodes zu schicken. Beide Protokolle verhalten sich dabei ähnlich wie UDP. Die Protokolle selbst definieren verschiedene Sampling-Optionen, die es möglich machen, auch in einem ausgelasteten Netzwerk statistisch relevante Flussinformationen zentral zu sammeln RMON und SMON RMON und SMON sind SNMP-basierte Protokolle die ähnlich wie Netflow und SFlow ermöglichen, statistische Daten an einer zentralen Stelle im Netzwerk zu sammeln. Jedoch werden bei RMON und SMON die Statistiken von den Vermittlungseinrichtungen nicht aktiv versendet, sondern müssen abgefragt werden. Dazu stellen RMON und SMON MIB-Erweiterungen bereit Protokolle - Zusammenfassung Grundsätzlich passt sich ein Netzwerk nicht den Protokollen an. Vielmehr gibt es für verschiedene Anwendungsgebiete verschiedene Protokolle. Moderne Vermittlungseinheiten (z. B. Router) sind sich jedoch dieser Eigenschaften der Protokolle bewusst und behandeln Pakete unterschiedlich. So werden zum Beispiel UDP Pakete in Vermittlungseinrichtungen eher als TCP Pakete verworfen. Dabei arbeiten sie jedoch nicht gegen die Protokolleigenschaften, sondern versuchen diese zu unterstützen. RTP stellt die höchsten Qualitätsanforderungen an ein Netzwerk. Latenz und Jitter sowie Packet Loss sollten minimal sein. Verbindungseinrichtungen bieten daher, wie später betrachtet wird, verschiedenste Möglichkeiten bestimmte Pakete von bestimmten Protokollen, Anwendungen oder Nodes zu priorisieren. 4.5 Netzwerkelemente und ihr Einfluss auf die Netzwerkqualität In der vorliegenden Arbeit sollen Ethernet Netzwerke betrachtet werden, in denen es nur Links von Nodes zu Verbindungseinrichtungen und zwischen Verbindungseinrichtungen selbst gibt. Diese Einschränkung wurde in im Abschnitt Abgrenzung des Themengebiets getroffen und wird durch das Prinzip der Strukturierten Verkabelung als sinnvolle Einschränkung bestätigt. Die verschiedenen Netzwerkelemente Switches, Nodes und Links haben jeweils einen unterschiedlichen Einfluss auf die Netzwerkqualität. Dieser Abschnitt zeigt somit jeweils die Einflüsse auf und erarbeitet einen Überblick über Möglichkeiten, ein Netz, welches ausgebaut werden soll, sinnvoll zu erweitern. 32

33 Jeder Link hat eine physikalische, aufgrund von Leitungslängen und Standards gegebene Latenz und eine physikalisch und protokollbedingte, oft von Hardware vorgegebene, maximal verfügbare Bandbreite. Die Vermittlungseinrichtungen, aber auch die Nodes, die an der Netzwerkkommunikation teilnehmen, haben selbst durch ihre eingesetzte Hard- und Software Einfluss auf die verfügbare Qualität (siehe Abschnitt Einfluss von Nodes auf die Netzwerkqualität ) Einfluss und Bedeutung von Links Das für einen Link eingesetzte Medium hat große Auswirkungen auf alle drei Hauptfaktoren von Netzwerkqualität: Bandbreite, Latenz und Packet Loss. Wie fehleranfällig die Übertragung auf dem Medium des Links ist, bestimmt die Rate des Packet Loss auf demselben. Wird versucht zu viele Daten in einem Netzwerk zu übertragen, gehen Pakete verloren. Dieser Effekt wird generell als Oversubscription von einem Link bezeichnet. Dabei sollen von einem Sender über einen Link mehr Pakete übertragen werden, als dieser mit dem eingesetzten Standard ermöglichen kann, wobei der Paketverlust nicht im Medium oder Link selbst auftritt. Vielmehr ist es dem Sender nicht möglich alle Pakete, die vermittelt werden sollen, über den Link zu schicken. Die Eignung von einem Link für einen bestimmten Ethernet Standard ist jeweils vom eingesetzten Medium (z.b. Kupfer oder Glasfaser) abhängig. Der eingesetzte Ethernet Standard entscheidet über die maximal verfügbare Bandbreite. Durch die messbare Signallaufzeit von einem Ende des Mediums zum anderen, entsteht die für einen Link jeweils konstante Latenz Kupferkabel als Transportmedium Als am häufigsten eingesetztes Medium kommt heute Twisted-Pair Kupferkabel in lokalen Netzwerken zum Einsatz. Dies wird vor allem durch die einfache Handhabung und Unempfindlichkeit gegen physikalische Kräfte im direkten Vergleich zu Glasfaserkabeln begründet. Ein Kupferkabel unterliegt den Störungen anderer elektromagnetischer Felder, die dazu führen können, dass Bits beim Transport kippen. Liegen Kupferkabel nebeneinander, so kann dies zu Übersprechen(Crosstalk) führen, womit man den Effekt beschreibt, dass eine Kabelader Einfluss auf eine benachbarte Kabelader in demselben Kabelstrang nimmt. Mit Fremdübersprechen (Alientalk) beschreibt man den Effekt auf einem Medium, der durch Außeneinflüsse die Signalqualität verschlechtert. Bei Kupferkabel sind das alle elektromagnetischen Felder in der Nähe eines Kabels, die auch durch benachbarte Kabel oder Stromquellen entstehen können. 33

34 Um diese Effekte zu minimieren, werden die für Ethernet eingesetzten Kabel abgeschirmt, wobei Standards dabei bestimmte Kabelqualitäten definieren; an dieser Stelle sei Cat5 als am weitesten eingesetzten Standard erwähnt [4]. Standards wie Gigabit Ethernet sind erst seit wenigen Jahren für Kupferkabel in der Praxis verfügbar. Die auf einem Kabel einsetzbaren Ethernet Standards sind von Kabelqualitäten abhängig. Gigabit verlangt mindestens nach Cat5e und 10G Ethernet sogar mindestens nach Cat6e [9]. Die Maximallänge hängt vom Standard und Kabel ab, bei 10GBASE-T ist es mit CAT-6 Kabel möglich 10 Gigabit Ethernet über 100m Reichweite anzubieten. Die Beschränkungen der Reichweiten entstehen durch die eingesetzten Frequenzen und Dämpfungen. Anders als beim Glasfaser, beeinflussen sich daher die elektromagnetischen Impulse, die zur Signalübermittlung genutzt werden, in einem Kupferkabel gegenseitig. Das macht dieses Verfahren wesentlich anfälliger für Störungen und Seiteneffekte. Die Reichweite von Kupferkabeln ist ebenfalls durch physikalische Gegebenheiten wie die Dämpfung stark begrenzt. Gigabit Ethernet war lange nicht für Twisted-Pair Verkabelung standardisiert, denn dabei galt es einige Hürden zu überwinden. Damit es möglich wurde, Cat5 Kabel mit akzeptablen Längen für Gigabit Ethernet zu verwenden, wurden neue Übertragungscodierungen entwickelt, alle 8 Adern in einem Kabel genutzt, sowie alle 4 Paare in beide Richtungen gleichzeitig verwendet. Rüstet man ein Netzwerk von 100Mbit auf 1000 Mbit auf, gibt es erweiterte Anforderungen an einen Link, was bedeuten kann, dass eine Verkabelung, die reibungsfrei mit 100MBit funktioniert hat, nun erhöhte Fehlerraten aufweist [4]. Das 100G Ethernet kann im Moment laut IEEE 802.3ba [3] nur mit Glasfaserverbindungen realisiert werden Glasfaser als Transportmedium Glasfaserkabel ist das Medium, mit dem die größten und stabilsten Bandbreiten erreicht werden können. Ethernet Standards sehen schon heute 100G Ethernet über Glasfasern im Standard IEEE 802.3ba [3] vor. Als Signale werden keine elektrischen Impulse verwendet, die sich im Kabel selbst gegenseitig ablenken, sondern Lichtimpulse. Effekte wie Crosstalk oder gar Alientalk treten daher nicht auf, Signale können weiterhin nicht durch äußere elektromagnetische Felder abgelenkt werden. Dieses Medium kann daher an vielen Stellen eingesetzt werden, in denen ein elektrischer Impuls durch äußere Einflüsse gestört werden könnte oder es notwendig ist, lange Strecken ohne aktive Verstärkung zu überbrücken. Durch die Entwicklung in den letzten Jahren sind spezielle Sende- und Empfangseinheiten verfügbar, die auf einer Verbindung testweise 14 TerraBit/s auf einer Länge von 160 Km erreichen können. Diese Bandbreite wird durch verschiedene Multiplexing Verfahren, wie zum Beispiel Frequenz, Zeit aber auch Polarität erreicht und ist so in keinem Ethernet Standard definiert. Die Entfernung von 160 Km wird nicht ohne Verstärkung überwunden. Es werden dabei jedoch 34

35 keine optisch-elektrischen Verstärker mehr eingesetzt, sondern die Lichtimpulse direkt im Trägermedium verstärkt [16]. Einen weiteren wichtigen Faktor stellen die sehr stark gesunkenen Kosten für das Transportmedium Glasfaser dar, was den Einsatz von Glasfaser als Medium interessanter gemacht hat, jedoch im direkten Vergleich mit Kupfer noch immer teurer ist [8] [4]. Für bestimmte Anwendungsfälle kann es preiswerter sein, auch in der Arbeitsplatzverkabelung Glasfaser einzusetzen, wenn man zum Beispiel. Alle aktiven Netzwerkelemente zentral sammelt und zu jedem Endpunkt eine einzelne Faser legt. Dabei ist es wiederum möglich bis zu zentralen, passiven Punkten Fasern gebündelt zu verlegen und diese dort aufzuspalten [9]. Glasfaserverkabelung findet vor allem im Primärbereich der strukturierten Verkabelung Verwendung, in dem Gigabit Bandbreiten über lange Strecken stabil verfügbar sein sollen (siehe Abbildung 3) Bandbreite in Links Wie bereits erwähnt ist die verfügbare Bandbreite für Links ist statisch und nur vom eingesetzten Ethernet Standard abhängig Latenz in Links Latenz entsteht durch die Länge des eingesetzten Mediums für einen Link, also wie lange Signale auf dem Weg durch das Medium benötigen. Diese Vorgabe hat bei Leitungslängen, die über das Verbinden von Punkten in einem Haus hinausgehen, messbare Auswirkungen. Durch einen Link selbst kann keine PDV entstehen, da dort Pakete genau in der Reihenfolge beim Empfänger ankommen, wie sie auch vom Sender abgeschickt wurden. Ein Sender braucht prinzipbedingt eine gewisse Zeit, um Pakete von einem Link zu lesen oder auch auf einen Link zu senden. Diese Bitlaufzeiten sind vom Standard abhängig und in Abbildung 8 dargestellt. Abbildung 8 - Bitzeiten bei verschiedenen Ethernet Geschwindigkeiten [4] Schnellere Ethernet Standards tragen somit dazu bei, Latenz in einem Ethernet zu reduzieren und die Qualität nicht nur durch mehr verfügbare Bandbreite, sondern auch weniger Latenz beim Senden bzw. Empfangen zu verursachen. 35

36 Abbildung 9 - Ethernet Standards - Übersicht technische Werte [4] In der Abbildung 9 werden verschiedene technische Werte dargestellt, insbesondere die Einschränkung der Framegrößen im 1000MBit Bereich. Diese Anpassungen waren nötig um mögliche Kollisionen im Half-Duplex Betrieb mit dem CSMA/CD Verfahren noch erkennen zu können [4] Packet Loss bzw. Fehlerraten in Links Packet Loss selbst wird ab dem 100MBit Ethernet Standard zumindest für Kupferkabel vorgebeugt, wo im Idle Signal dieselbe Frequenz benutzt, wie auch zur Datenübertragung selbst. Damit zeigt eine Link LED für einen Link zuverlässig an, dass Pakete übertragen werden können. Als Vergleich dazu wurde bei 10MBit das Testsignal noch mit 1/10 der Nutzfrequenz übertragen, womit es einfacher zu falschen Anzeigen kommen konnte und diese Fehlerquelle relevanter war [4]. Im Vergleich sind defekte Glasfaserverbindungen nicht so berechenbar und können Pakete durch Verunreinigungen oder physikalischen Beschädigungen verlieren. Die durch fehlerhafte Medien entstehenden Pakete, kommen an einer Node oder Switch an, um dort verworfen zu werden. Für die Transportschicht sind defekte Pakete, in denen die Ethernet CRC Summe nicht stimmt, mit einem Packet Loss gleichzusetzen und nicht von normalen Packet Loss unterscheidbar Einfluss von Nodes auf die Netzwerkqualität Nodes haben direkten Einfluss auf die von ihnen wahrgenommene Netzwerkqualität. Sollten Komponenten in der Node nicht ausreichend dimensioniert sein, kann niemals die maximale Netzwerkqualität und Leistung von dieser Node aus abgerufen werden. Das hat in der Stern-Topologie keinen Einfluss auf das Netzwerk selbst, jedoch auf alle Kommunikation zur oder von der Node. Insbesondere im Serverbereich und Gigabit-Anbindungen sind viele Faktoren in einer Node zu beachten, um die maximal erreichbare Qualität zu ermöglichen [17] Wie werden Pakete in Nodes behandelt Bei der Verarbeitung von einem Paket durchläuft dieses in der Node verschiedene Schichten, die im Folgenden im Detail aufgezeigt werden sollen. Jedes Endgerät implementiert einen so genannten Protocol Stack, durch das ein Paket in den verschiedenen Stufen des OSI Schichtmodells die Node durchläuft. 36

37 Dabei übernimmt abhängig von Schicht und Aufbau der Node dedizierte Hardware oder eine Softwarelösung die Aufgabe Bitübertragungsschicht Netzwerkhardware übernimmt die physikalische Anbindung an ein Ethernet Netzwerk und dabei die notwendige Signalverarbeitung und implementiert Methoden wie CSMA/CD und Autosensing Sicherungsschicht Vom Betriebssystem und Treiber für die Hardware wird die Sicherungsschicht implementiert, wobei die Arbeitsteilung von der eingesetzten Netzwerkhardware und dessen Treiber (Software) abhängig ist. Um Geschwindigkeit zu erhöhen erlauben aktive Netzwerkkarten ein Checksum Offloading, womit die CPU einer Node nicht mehr zum Berechnen von Ethernet CRC Werten belastet wird [18] Vermittlungsschicht und Transportschicht Der TCP/IP Stack wird meist vollständig vom Betriebssystem in Software implementiert. Dieser weißt dabei abhängig vom Betriebssystem große Unterschiede in der wahrnehmbaren Netzwerkqualität auf. Wie viele Ressourcen den Netzwerkoperationen von einem Betriebssystem zugewiesen wurden, ist dabei für die Netzwerkqualität genauso relevant wie die Konfiguration des Stacks und der Umgang mit vielen parallelen Netzwerkoperationen. Heutzutage gibt es die Möglichkeit den TCP/IP Stack auf dedizierte Netzwerkhardware auszulagern. Dies hat vor allem in Lösungen im Bereich von 10G Ethernet oder mehr Relevanz, da sonst die Systemressourcen einer Node in großen Teilen durch die Verarbeitung von Protokollen verwendet werden. Durch TCP Offload Engines, die den gesamten TCP Stack auf eine aktive Netzwerkkarte auslagern, kann die CPU Last, die durch den TCP Stack erzeugt wird, um bis zu 65% reduziert werden und wird damit wieder für Dienste auf dem Server verfügbar [19] Faktoren für die wahrnehmbare Qualität von Nodes Verschiedenste Komponenten Einfluss auf die nutzbare oder wahrnehmbare Netzwerkqualität einer Node. Die Art der Anbindung der Netzwerkhardware an die Node ist dabei genauso relevant wie optimierte Algorithmen in der Vermittlungsschicht oder der Transportschicht. Diese Algorithmen wiederum benötigen bestimmte Betriebsressourcen, die insbesondere in Servern ausreichend vorhanden sein müssen, um die qualitätsrelevanten Kenngrößen nicht zu verschlechtern. Daher ist es wichtig, die CPU ebenso wie den Speicher und die Bus-Bandbreite hin zum Netzwerkgerät nicht zu Unterdimensionieren. Somit ist es eine übliche Vorgehensweise, in Netzwerken die Ressourcenauslastung von Nodes, zumindest aber von Servern, zentral zu überwachen. Im Abschnitt Analyse und Vorstellung von verfügbaren Tools, Protokollen und Methoden wird daher auch kurz darauf eingegangen, mit welchen Mitteln eine Überwachung gelingen kann. Zur 37

38 Einordnung und Einschätzung von verschiedenen Faktoren sollen diese nun kurz aufgezeigt werden. Als wichtige Faktoren für die Performance einer Node sollen folgende Aspekte erwähnt werden: - Eingesetztes Betriebssystem o Algorithmen sind unterschiedlich optimiert. BSD aber auch Linux haben gezeigt, dass sie bei hoher Netzwerklast effektiver als andere Systeme arbeiten. - Filtersoftware auf der Node o Firewalls und andere Komponenten, die direkten Einfluss auf den Netzwerk Stack nehmen (z. B. Filtertreiber), verschlechtern die Netzwerkperformance und Qualität einer Node - Verfügbare Ressourcen o Hauptspeicher und CPU sind relevant für Netzwerkoperationen. Ein Betriebssystem verteilt durch Scheduling Ressourcen auf verschiedene Operationen; unter Last können sich daher insbesondere Echtzeitprotokolleigenschaften kritisch verschlechtern. o Durchs Mores Law ist die verfügbare Rechenkraft in Nodes wie auch Switches entscheidend gestiegen. Damit ist es bei Lastproblemen für die Node einfach, die verfügbare CPU-Kapazität auszubauen. - Qualität der Netzwerkkarte o Preiswerte Netzwerkkarten führen CRC Operationen oft nicht auf der Netzwerkhardware durch, was zusätzlich die CPU einer Node belastet. o Aktive Karten erlauben es, selbst komplexere Operationen wie Filterung in die dafür spezialisierte Hardware auszulagern. - Bus bei der Anbindung der Netzwerkhardware o Teilweise muss sich in einer Node ein Datenbus, wie zum Beispiel der PCI Bus, geteilt werden. Ein 32 Bit PCI Bus hat eine Gesamtbandbreite von 133 Mbyte. Gigabit Ethernet ist daher nicht sinnvoll an diesen Bus anzubinden und Standards wie PCI-X sind erforderlich. o Unterschiedliche Hardware Bus Systeme bedeuten unterschiedliche Latenz sowie unterschiedliche Last für die Datenübertragung auf dem Bus für eine Node. Durch die später vorgestellte Messmethoden und Tools muss es daher möglich sein, diese Einflussmöglichkeiten auf die wahrgenommene Netzwerkqualität für eine Node auf kritische Messwerte zu überwachen um dann reagieren zu können Bandbreite in Nodes Die verfügbare Bandbreite für Nodes ist bei einer im Full Duplex Modus betrieben Stern-Topologie statisch und direkt vom eingesetzten Ethernet Standard abhängig. 38

39 Einschränkungen entstehen wie im Abschnitt bezüglich der Links beschrieben dann, wenn Vermittlungseinrichtungen auf dem Weg zwischen zwei Nodes überlastet sind. Sollte eine Node selbst überlastet sein, kann dies auch direkte Auswirkungen auf die wahrgenommene Bandbreite haben. Soll eine Node beispielsweise Daten von einem Speichermedium über das Netzwerk übertragen, ist dies nur möglich, wenn das Speichermedium diese Daten schnell genug zur Verfügung stellen kann Latenz bei Nodes Die Latenz in Nodes ist wie bereits im vorherigen Abschnitt beschrieben von vielfältigen Faktoren abhängig. Überlastung einer Node kann zu Einbußen in der messbaren Latenz führen, da bei einer Überlastung automatisch weniger Zeit zur Bearbeitung von Netzwerkanfragen bleibt, bzw. diese verzögert werden. Dies hängt besonders stark vom eingesetzten Betriebssystem ab, was in praktische Messungen verdeutlicht werden konnte Packet Loss bzw. Fehlerraten bei Nodes Pakete können dann auf dem Link zur Node verloren gehen, wenn die eingesetzte Netzwerkhardware der Node nicht mehr in der Lage ist, die Pakete anzunehmen und in dafür vorgesehenen Puffern zu speichern. Dies passiert immer dann, wenn die Software in der Node nicht in der Lage ist, alle ankommenden Pakete zu verarbeiten, weil zum Beispiel ein Puffer keine weiteren Daten aufnehmen kann. Bei einer Node kann daher die Überlastung eines angebotenen Dienstes auch zur Störung von anderen auf der Node verfügbaren Diensten führen, weil die zur Verfügung stehenden Ressourcen wie CPU und Speicher von allen Diensten geteilt werden. Durch die richtige Abstimmung und Einrichtung von Diensten können diese Effekte zwar minimiert, jedoch nicht ausgeschlossen werden. Pakete mit falschen CRC entstehen vor allem durch Netzwerkhardwaredefekte. Diese sollten dann ausgetauscht werden, um die Fehlerrate zu minieren Einfluss und Bedeutung von Switches Verbindungseinrichtungen haben in der dargestellten Stern-Topologie den größten Einfluss auf die verfügbare Netzwerkqualität. Als kritischste Komponente müssen sie auch am besten überwacht und analysiert werden. Sollten Performanceprobleme in einem Netzwerk nicht nur bei einer Node auftreten, ist dies ein klares Indiz dafür, dass die Paketvermittlung durch Switches auf dem Weg durch das Netzwerk gestört ist. Latenz für ein Paket in einem Netzwerk entsteht - soweit nicht direkt durch die Hardware in den Nodes oder von dem Leitungsweg selbst - durch das Passieren von Vermittlungseinrichtung auf dem Weg durch das Netzwerk. Faktoren, die diese Latenz beeinflussen, sind sehr vielfältig und von sehr vielen komplex miteinander verknüpften Eigenschaften abhängig die im Folgenden exemplarisch dargestellt werden. 39

40 Historische Entwicklung von Switch-Vermittlungseinrichtungen Da Vermittlungseinrichtungen speziell für die Aufgabe entwickelt wurden, Pakete auf einem Link entgegen zu nehmen und auf anderen wieder zu verschicken, gibt es dabei verschiedenste Optimierungen. Diese Optimierungen erklären auch die Preisunterschiede am Markt und warum man 2011 einen 48 Port Gigabit Switch für 500 Euro aber genauso für Euro und mehr kaufen kann. Teure Hardware ist dabei nicht 100fach besser, implementiert aber viele Features (siehe Qualitätsrelevante Features und Methoden von Switches ), die für eine stabile Performance sowie lückenlosen Überwachung von Leistungsdaten notwendig sind. Oft bieten sehr preiswerte Switche kein Management Interface und sind daher für den Betrieb eines Netzwerk, in dem Qualität überwacht und sichergestellt werden soll, nicht geeignet. Switches haben im Wandel der Zeit verschiedene Generationen erlebt. Hat ein Switch vor wenigen Jahren noch 4ms gebraucht ein Paket zu Switchen, sind es heute weniger als 50 Mikrosekunden. Diese Leistungssteigerung wurde durch die Verwendung immer spezialisierter Hardware erreicht. Wurden anfangs noch CPUs oder ASSPs (Application Specific Standard Products) benutzt, werden nun ASICs (Application Specific Integrated Circuits) bzw. Hybriden eingesetzt [20]. Generell stellen verschiedene Anwendungsbereiche unterschiedliche Anforderungen an Switches. Viele kleine Pakete erzeugen vor allem CPU-Last auf dem Switch, große Pakete Last auf dem internen Bus System und den Paket Queues. Wie bereits anfänglich erwähnt soll Ziel dieser Arbeit sein, Unterschiede und Methoden aufzuzeigen, mit denen eine bewusste Entscheidung für einen Ausbau von Vermittlungseinrichtungen vorgenommen werden kann. Daher sollen einige relevante Unterschiede aufgezeigt werden. Die mittlerweile auf dem Markt verfügbaren Switches sind teilweise so komplex, dass Detailzusammenhänge für die vorliegende Arbeit zu weit führen würden. In dem praktischen Teil der Arbeit wurden Datenblätter von Switches exemplarisch mit messbaren Werten verglichen. Welche auch gezeigt haben das Herstellerangaben realistisch sind und als Entscheidungsgrundlage dienen können Qualitätsrelevante Features und Methoden von Switches Die Funktionsweise eines Switch wurde in der Einleitung skizziert. Hier sollen mögliche Optimierungen und Standards aufgelistet werden, die einen direkten Einfluss auf die Qualität in Netzwerken haben. Eine detaillierte Betrachtung soll aufgrund der hohen Vielfalt nur exemplarisch stattfinden. Auszug von möglichen Technologie bzw. Qualitätsunterschieden in Switches: 40

41 - Switching Method (Store and Forward oder Cut Though) o Bei Cut Though werden nur die ersten Bytes eines Ethernet Pakets gelesen, bis der Switch seine Routing treffen kann. Dann wird das Packet direkt weitergegeben und nicht vollständig gepuffert. In höheren Standards wird die Relevanz von Cut Tough immer geringer, da die Bitlaufzeiten in zum Beispiel 10GBit Ethernet sehr klein sind. - Interne Bus-Struktur und verfügbare Backplane (zentral oder vollvernetzt von jedem Port zu jedem anderen, hybriden zu geringe verfügbare Backplane führt zu Packet Loss im Last Fall) - Queue Strukturen (Global shared Queue für Pakete oder, dedizierte Queues für jeden einzelnen Port) - Unterstützung von QOS und VLAN (durch IEEE_802.1Q [3] definiert) o o VLAN Tagging, welches eine portabhängige Zuordnung in ein virtuelles Netzwerk und daher von anderen VLAN getrennten Broadcast Domain erlaubt Durch das 3 Bit Feld Priority Code Point (PCP) kann eine Node beim Senden von Ethernet Packages eine Priorität angeben, welche der Switch beachten kann aber nicht muss. - Qualität der Hardware, welche die Daten auf das Medium schreibt oder auch von dort liest. - Layer2 Administration und Port/MAC Security Security - Spanning Tree (IEEE 802.1D [3]) o Durch Spanning Tree können Link Redundanzen aufgebaut werden. Im Fehlerfall wird ein anderer Link für dieselbe Verbindung verwendet, ohne Spanning Tree würden doppelte Links durch Broadcast Pakte zu einer Endlosschleife führen. - Etherchannel (IEEE 802.3ad [3]) o Durch redundante Links wird zwischen zwei Teilnehmern kann die verfügbare Bandbreite per Etherchannel erhöht werden. Werden zwei 1GBit Links in einem Etherchannel zusammengefasst, stehen für diesen virtuellen Link, auf dem die Pakete vermittelt werden, bis 2GBit zur Verfügung. - Deeppackage inspection o Kann ein Switch auch Filter oder Routing Entscheidungen aufgrund von Informationen in tiefliegenden Protokollen vornehmen, so spricht man von Deeppackge Inspection oder Layer 7 Switch. Ein Beispiel dafür sind Filesharing oder VOIP Protokoll Filter. 41

42 - Faulttolerancy und Selbstdiagnose o In Switches, die im Primären Bereich eingesetzt werden (strukturierte Verkabelung), ist es wichtig gute Möglichkeiten zur Fehlerdiagnose zu haben und erweiterte Ausfallsicherheit, zum Beispiel durch redundante Netzteile - Hot-swappable transceivers o Switches, die im Primären Bereich eingesetzt werden, sollten austauschbare Empfangseinheiten haben. Damit kann man einen Switch von 1GBit auf 10Gbit durch Austausch der Empfangseinheiten aufrüsten. Auch kann im Falle eines Ausfalls einer Empfangseinheit aufgrund eines Fehlerfalls diese einfach getauscht werden ohne den ganzen Switch zu ersetzen. Dies ist vor allem für hochverfügbare Netzwerke interessant. - Features im Admin Interface o Generell können Switches heute IP Router Funktionalität und mehr, wie zum Beispiel VPN oder Login Server) übernehmen. Daher gibt es verschiedenste Ausbaustufen von Switches mit jeweils angepassten zur Verfügung stehenden CPU und Speicherressourcen. - Netflow /SFlow/Mirror Port/SNMP/Shell Access Unterstützung o Switches unterstützen jeweils nur einige von den möglichen Methoden, die man zum Auslesen von statischen Werten nutzen kann. Bei der Auswahl eines Switch ist darauf zu achten, dass es die gewünschten Protokolle unterstützt. Dabei gibt es für jeden Switch Unterschiede im durch ein Protokoll zur Verfügung gestellten Funktionsumfang. Beispielsweise können nicht auf allen Switchen alle Werte per SNMP ausgelesen oder nicht alle administrativen Funktionen per SNMP verwaltet werden. Der Auszug an möglichen Fähigkeiten eines Switch zeigt die Marktvielfältigkeit und die Möglichkeit, einen Switch den Anforderungen nach beliebig zu skalieren. Oft ist dabei ein Preis-Leistungsoptimum für den jeweiligen Anwendungsfall entscheidend. Wichtig ist es, bei der Switch Auswahl das Datenblatt genau auf die Anforderungen für das Netzwerk zu prüfen und im Falle eines Netzwerkausbaus ausreichend Reserve einzuplanen. Wichtigste Faktoren für die Leistungsfähigkeit sind vor allem dabei Puffergrößen, Backplane Bandbreite, Rechenleistung sowie erweiterte Funktionen wie VLAN, QOS und Monitoring Möglichkeiten. Diese Features sind preislich die, die einen Switch teuer machen, aber auch die, die es einem Administrator ermöglichen, ein Netzwerk so zu administrieren, dass es für alle Teilnehmer die beste Dienstqualität verfügbar macht. Bei managed Switchen ist es üblich, dass die auf dem Switch laufende Software updaten kann. Dabei gilt es zu beachten, dass die Switches mit Versionen dieser Software betrieben werden, die alle Features haben, die für ein Netzwerk gebraucht 42

43 werden und bei vom Hersteller rausgegebenen Updates prüfen, welche Funktionen oder Leistungsdaten sich geändert haben. Dennoch sind preiswerte unmanaged Switches heute so dimensioniert, dass eine Überlastung mit wenigen angeschlossen Geräten nicht ohne weiteres möglich ist. Dies wird auch im Abschnitt Einordung der Kenngrößen und ihrer Bedeutung in einem Ethernet und den praktischen Messungen deutlich. In der Strukturierten Verkabelung ist die Anforderung an die Primärswitches am größten und nimmt dann mit jeder Ebene ab, was Switches in der Primärebene in einem guten Netzwerkdesign am teuersten macht. Zusammenfassend kann gesagt werden, dass es verschiedene Optionen gibt. Für alle gilt jedoch die Maxime, dass unnötig viele Switches und Hops vermieden werden sollten. Generell gilt die Faustregel, nicht mehr als 7 Switches auf dem Weg zwischen 2 Nodes zu haben [4] Bandbreite bei Switches bzw. Switch Ports Die verfügbare Bandbreite an einem Switch Port ist grundsätzlich vom eingesetzten Ethernet Standard abhängig. Da ein Switch eine begrenzte Buskapazität (Backplane) und Puffer haben, ist eine gleichzeitige volle Auslastung aller Ports in beide Richtungen in der Regel nicht möglich. Ein weiterer limitierender Faktor für die erreichbare Netzwerkqualität ist die auf dem Switch verfügbare Rechenleistung. Mit steigender Komplexität des Regelwerks auf dem Switch nimmt die Auslastung zu und im Überlastungsfall die Qualität ab Latenz bei Switches Die Latenz, die durch die Vermittlung in einem Switch entsteht, ist abhängig von der Funktionsweise und Konfiguration des Switch. Generell verschlechtert sich die Latenz beim Vermitteln von Paketen für Switches unter Last. Daher ist es wichtig, einen Switch in Primär- oder auch Sekundärbereichen der Strukturierten Verkabelung nicht unterzudimensionieren. Können Pakete nicht sofort vermittelt werden, werden diese in einen Puffer zwischengespeichert, wodurch sich die Latenz für das betroffene Paket verschlechtert und eine PDV für die Verbindung entsteht. Sollten zentrale Switches überlastet sein, kann es zu großen PDV kommen und das gesamte Netzwerk langsamer werden Packet Loss bzw. Fehlerraten bei Switches In der Regel gibt es auf einem Switch Ports, die höhere Bandbreitenanforderungen haben als andere. Das entsteht dadurch, dass mehrere Nodes Pakete versenden, die auf dem gleichen Link übertragen werden müssen, zum Beispiel in Richtung eines Servers. Dieser Effekt ist gewünscht und in der strukturierten Verkabelung so gewollt. Wie im Abschnitt Einfluss und Bedeutung von Links beschrieben ist die Gefahr für Paket Loss am größten, sollte ein Port an einem Switch oversubscribed sein. Diesem Effekt gilt es dadurch vorzubeugen, indem diese Uplinks oder Server Ports ausreichend dimensioniert sind. Sollte ein schnellerer Ethernet Standard nicht einsetzbar sein, können zum Beispiel Etherchannel eingesetzt werden, um einer 43

44 Node oder einem virtuellem Link mehr Bandbreite zur Verfügung zu stellen. Auch kann es sinnvoll sein, die nutzbare Bandbreite für einzelne Ports zu drosseln, um eine Oversubscription von Uplinks zu verhindern. Der Switch kann dann die zu Verfügung stehende Bandbreite besser an alle Ports verteilen. Moderne managed Switches gleichen diese Effekte automatisch aus. Pakete mit falschen CRC entstehen vor allem durch Hardwaredefekte. Diese sollten dann ausgetauscht werden. Zu beachten ist ebenfalls, dass das Cut Though Switches Prinzip bedingt auch fehlerhafte Pakete weiterleitet, auch hier gilt es durch ausreichendes Monitoring vorzubeugen. 5 Bestimmen von Leistungs- und Qualitätskenngrößen für ein Ethernet Bevor eine Analyse von verfügbaren Tools stattfindet, sollen kurz die theoretischen Möglichkeiten zur Erfassung und Bestimmung von den Kenngrößen näher beleuchtet werden. Qualität in Netzwerken ist von verfügbarer Bandbreite, Latenz und Paketverlusten abhängig. Diese Werte zu bestimmen ist im normalen Betrieb eines Netzwerk nicht immer möglich. In diesem Abschnitt sollen praktikable Wege zu einer Qualitätsbewertung eines Netzwerks aufgezeigt werden. Theoretisch kann die aktuelle Qualität in einem Netzwerk eingeschätzt werden, indem man die Kenngrößen stichprobenartig für jeden Link aufnimmt. Aus diesen Stichproben könnte man eine Netzwerklandkarte erstellen und bekommt so einen Eindruck über die Gesamtqualität, indem auf jedem Link die Kennwerte eingetragen sind. Diese theoretische Messung ist jedoch nur schwer durchführbar. Links zwischen Verbindungseinheiten sind nur schwer durch Tests zu messen, ein Eingriff zwischen die Verbindungseinrichtung ist nicht praktikabel. Diese theoretische Darstellung hätte daher nur wenig praktischen Bezug, will man die Qualität eines Netzwerks dauerhaft - möglichst automatisiert- und auch für große Netzwerke überwachen. Es ist durch die verschieden Betriebssysteme, Administrationsrechte und Zuständigkeiten nicht praktikabel, viele Nodes dauerhaft mit einer Überwachungssoftware zur Bestimmung der Netzwerkqualität zu versehen. In der Praxis nutzt man die Möglichkeit, Indizien für die qualitätsrelevanten Kenngrößen und wenige Stichproben zu sammeln. Aus diesen Indizien und Kenngrößen leitet man ab, wie stark belastet das Netzwerk ist. Dazu werden diese Messwerte in großen Netzwerken automatisch zentral zusammengeführt und ausgewertet. Messwerte und Indizien entstehen dabei vor allen in den Vermittlungseinrichtungen, welche in verschiedenen Zählern bestimmte Kenngrößen erfassen. Ein Switch in einem managed Network sammelt Informationen über die Anzahl der übertragenen Pakete, Datenaufkommen, Fehler und andere Kennzahlen für jeden Port und virtuellem Interface. Aus diesen Indizien kann man die aktuelle Belastung eines Netzwerks schließen und dadurch erkennen, wie viel Bandbreite noch zur Verfügung steht und wo Probleme wie Paketfehler auftreten. 44

45 6 Analyse und Vorstellung von verfügbaren Tools, Protokollen und Methoden Die Arbeit hat das Ziel, Qualität in Netzwerken so zu überwachen, dass Fehler sowie Probleme frühzeitig erkannt werden können. Bevor ein eigenes Tool zur zentralen Überwachung entwickelt wurde, wurden verschiedene Tools analysiert, getestet und auf die Zielstellung hin bewertet. Diese Schritte dienten als Basis der Analyse und Planung des eigenen Tools, um zum einen zu verstehen, welche Aspekte diese Tools bereits abdecken und zum anderen welche neue, noch nicht verfügbare Methoden und Techniken zur Qualitätssicherung und Überwachung in einem neuen Tool angeboten werden können. Untersucht wurde vor allem, wie einfach Tools konfiguriert werden können und wie einfach sie sich in verschiedensten Netzen einsetzen lassen. Folglich werden in diesem Kapitel die Ergebnisse zur Rechercheanalyse und Tests von bereits verfügbaren Tools vorgestellt. Zunächst jedoch sollen verschiedene Methoden und Protokolle vorgestellt werden, die als Grundlage für das Verstehen der Tools benötigt werden. 6.1 Messmethoden und Protokolle Praktisch ist es möglich, an verschiedenen Stellen in einem Netzwerk qualitätsbestimmende Kenngrößen zu ermitteln. Diese unterschiedlichen Paradigmen und die dazu mitunter notwendigen Protokolle sollen nun kurz vorgestellt werden, wobei der Fokus wie im Abschnitt Abgrenzung des Themengebiets dargestellt auf eine zentrale Erfassung ausgerichtet ist Messmethoden und Protokolle für Messungen an zentralen Einrichtungen Zentrale Einrichtungen können Router, Switches oder andere Netzwerkelemente sein. Wichtig ist der Grundgedanke, dass die Ergebnisse der Messungen primär durch passives Erfassen von Kenngrößen erfolgt. Durch die Messungen selbst wird daher kein oder nur ein vernachlässigbarer Einfluss auf das Netzwerk genommen. Die Messwerte können durch Protokolle wie SNMP, Netflow, SFlow und RMon von den Einrichtungen abgefragt werden. Switches bieten heutzutage meist die Möglichkeiten, über SNMP Kennwerte auszulesen, weiterhin sind darüber hinaus Flow Protokolle verbreitet, wie zum Beispiel Netflow und SFlow. Nutzt man die Flow-Schnittstellen, werden vom Switch statistisch relevante Informationen über den aktuellen Datenverkehr im Netzwerk an eine konfigurierte IP geschickt. Es wird jedoch bei Netflow und SFlow nicht sichergestellt, dass alle Pakete, die im Netzwerk über den zentralen Punkt verschickt wurden per Netflow erfasst werden und damit für die Auswertung zur Verfügung stehen. Aufgrund der durch die Erfassung entstandenen Last, benutzen Netflow Protokolle ein Sampling Mechanismus und erfassen nur alle x Pakete, um eine Überlastung zu vermeiden. 45

46 Eine weitere Methode zur Überwachung an einem Switch ist das Einrichten von einem Monitoring oder Mirroring Port. An diesem werden alle Pakete ausgegeben die einen Switch passieren, bzw. alle Pakete, die die im Admin Interface einstellbaren Bedingungen, wie zum Beispiel Filter, erfüllen. Diesen Port und die darauf sichtbaren Pakete kann man dann durch einen Rechner oder ein Analysesystem auswerten lassen. Hier besteht das Risiko, dass durch Oversubscription nicht alle Pakete erfasst werden oder alternativ die Leistung des Switches künstlich reduziert wird. Mirror Ports sollten daher immer vielfach schneller sein als die anderen Links auf einem Switch. Dies ist jedoch bei Gigabit Switches nur eingeschränkt möglich. Oft bieten Switches und Router auch den Zugang über ein Webinterface oder einer Terminal Session (mit SSH oder Telnet an) an. Diese Zugänge dienen primär jedoch der Administration und Wartung und sind daher ungeeignet für eine automatische Überwachung. Spezialisierte Diagnosehardware kann direkt als transparente Bridge ins Netzwerk eingebracht werden und kann ohne Veränderungen der Netzwerkstruktur zur Diagnose und Bestimmung von Kenngrößen verwendet werden. Dazu bieten sich vor allem so genannte Probes an, die transparent in eine Verbindung eingebracht werden und so statistische Erhebungen, aber auch Messungen am durch sie durchgeleiteten Datenaufkommen vornehmen können. Eine Probe wird dabei an einem Link aufgesetzt und ermöglicht so, alle Pakete, die diesen Link passieren, erfassen zu können Prinzipbedingt erhöhen diese Probes die Latenz von Paketen im Netzwerk. Auch an zentralen Vermittlungseinrichtungen wie Router können alle vermittelten Pakete passiv beobachtet werden und so Messungen vorgenommen werden. Dabei bieten sich vor allem Softwarerouter wie Linux an. Für den Fall, dass primär Daten durch das passive Erfassen von Kenngrößen gewonnen werden, bieten sich zentrale Netzwerkelemente auch dafür an, die Netzwerkqualität durch einfache aktive Maßnahmen, wie zum Beispiel Pings zu überwachen. Dazu werden später Tools vorgestellt. Es ist jedoch unüblich und unpraktisch, von einer zentralen Netzwerkeinrichtung in regelmäßigen Abständen die Bandbreite zu vermessen und so das Netz stark zu belasten. Im Abschnitt Netzwerkelemente und ihr Einfluss auf die Netzwerkqualität wurde bereits erläutert, warum regelmäßige Messungen unnötig sind. Im folgenden Abschnitt wird weiter vertieft, warum diese auch mit einem Risiko verbunden sind und welche Anwendungen eventuell sinnvoll sind. Später vorgestellte praktische Untersuchungen haben diese Punkte zusätzlich bestätigt Methoden und Protokolle für Node-zu-Node-Messungen Im Unterschied zum vorher beschriebenen Ansatz werden aktiv Messungen von einer Node zur anderen durchgeführt. Bei dieser Methode werden zur Vermessung Pakete generiert, welche beim Empfänger und/oder Sender analysiert werden. Durch diese Messungen können Kenngrößen wie Latenz und Bandbreite einfach 46

47 bestimmt werden. Zu beachten ist hierbei der direkte Eingriff ins Netzwerk. Durch die Messung selbst wurde das Netzwerk belastet und beeinflusst, was eine Messung im normalen Betrieb unmöglich macht oder sogar selbst dazu beiträgt, dass Probleme entstehen. Auch wird durch eventuell vorhandene Last im Netzwerk die Messung unzuverlässig. Diese Methode ist nur an zentralen Nodes wie Router oder Servern sinnvoll, da der Aufwand zur Konfiguration und Wartung im Vergleich zum Mehrwert bei einem dauerhaften Monitoring zu groß wird. Zur dauerhaften Überwachung bietet es sich an, von einer Node aus periodisch Messungen im Netzwerk vorzunehmen, um so neue Probleme schnell erkennen zu können. Tools, die diese periodischen Messungen automatisieren, werden wie bereits im Abschnitt zuvor angekündigt später vorgestellt und analysiert Messmethoden an einer Node Zur Fehlerdiagnose für eine Node ist es im Einzelfall interessant, Kennwerte durch das passive Auswerten oder Aufzeichnen von Netzwerkdaten direkt an der Node zu bestimmen. Diese Überwachung ist nur an zentralen Nodes wie Router oder Servern sinnvoll, der Konfigurationsaufwand steht in keinem Verhältnis zum Mehrwert bei flächendeckender Installation auf viele Nodes im Netzwerk. Auch sind diese Methoden nicht für eine Überwachung sinnvoll, sondern haben vielmehr ihre Berechtigung beim Einsatz zur Fehlerdiagnose. 6.2 Analyse und Übersicht zu Hard- und Softwaretools In diesem Abschnitt sollen exemplarisch Hardware- und Softwaretools vorgestellt werden, die zur Qualitätsbestimmung oder Sicherung und Überwachung in einem Netzwerk eingesetzt werden können. Dabei soll angemerkt werden, dass diese Recherche nicht nur einen aktuellen Wissensstand repräsentiert, sondern diese Recherche auf die eigene Fragestellung adaptiert wurde und damit die Basis für die Entwicklung des eigenen Tools darstellt. Dazu waren mehrere Prozessschritte notwendig, in denen zuerst eine Marktübersicht von vorhandenen Tools erstellt wurde. Diese wurden dann nach Relevanz und Leistungsumfang sortiert. Im Anschluss daran wurden die Tools vom Autor im Detail getestet, wobei auch bei komplexen Tools diese vollständig installiert sowie für ein Testnetzwerk konfiguriert wurden. Dieser Prozess konnte so einzelne Stärken und Schwächen von Tools aufzeigen und liefert damit wichtige Erkenntnisse für die Entwicklung des eigenen Tools. Schon kurze Recherchen offenbaren einen schier endlosen Markt an Tools und Hardwarelösungen. Die hier vorgestellten Beispiele sollen einen guten Überblick über die Möglichkeiten von Tools und Hardware geben, erheben jedoch keinen Anspruch auf Vollständigkeit. Wie die Analyse der verschiedenen Tools ergeben hat, ist eine automatisierte Überwachung und Fehlerfrüherkennung für mittelgroße und große Netzwerke sehr 47

48 gut mit kostenlos verfügbaren Tools möglich. Auch die Anbindung von verschiedenen Agenten ist oft problemlos möglich. Für sehr detaillierte Analysen empfehlen sich jedoch kommerzielle Speziallösungen. Diese erschließen zwar selten völlig neue technische Möglichkeiten, geben dem Administrator jedoch die Möglichkeit, Probleme und Schwachstellen in einem Netzwerk auch ohne sehr tiefe Fachkenntnisse oder geringerem Zeitaufwand einfacher zu finden und so Vorgänge in einem Netzwerk einfacher nachzuvollziehen. Neben einer Kurzvorstellung der wichtigsten Tools sollen auch die möglichen Einsatzgebiete beschrieben werden. Eine Auswertung von Messungen des Autors und praktischen Erfahrungen werden im Abschnitt Experimentelle Bestimmung von Kenngrößen in der Praxis dargestellt Toolklassen Die Analyse hat gezeigt, dass sich Tools grundsätzlich in 4 verschiedene Klassen einordnen lassen. Jede Klasse von Tools nimmt dabei verschiedene Aufgaben wahr. Gute Tools sind dabei in mehrere Klassen einzuordnen, da sie diese geschickt kombinieren. - Realtime Analyse o Es ist möglich, Probleme oder Messungen in Echtzeit aufzunehmen. Die Tools speichern dabei nicht die für die Messung relevanten Pakete oder Daten, sondern nur bestimmte Werte. - Paketmitschnitte o Sämtliche, für das Tool sichtbare Pakete, werden unter eventueller Berücksichtigung von Filtern archiviert. - Offline Analyse o Aufgezeichnete Paketmitschnitte können mit dem Ziel, verschiedenste Qualitätsaussagen zu treffen, analysiert werden. Ein Beispiel ist die Analyse eines im Paketmittschnitt aufgezeichneten RTP Streams auf PDV und aufgetretenen Packet Loss. - Aktive Messungen o Mit dem Client Server Prinzip schickt eine Node (Client) Testdaten zu einer anderen Node (Server). Der Server trägt dazu bei, Kenngrößen ermitteln zu können. Dazu gehören beispielsweise auch Protokolle wie ICMP. Ohne ICMP Echo Server ist eine Messung mit einem so genannten Ping nicht möglich. - Packet Generierung o Im Unterschied zu aktiven Messungen um Netzwerkkenngrößen zu ermitteln, gibt es Tools, die zur reinen Paketgenerierung genutzt werden können. Durch diese Tools lässt sich Netzwerklast erzeugen und so andere Tools oder das Netzwerk selbst unter bestimmten Bedingungen zu testen. 48

49 6.2.2 Tools für Messungen an einer Node traffic.cgi traffic.cgi ( sind zwei einfache Linux Bash Scripts, die sich als Ausgangspunkt beliebig erweitern lassen und einem Administrator die Grundlagen von dem Round Robin Database Tool (RRDtool: vor allem im Netzwerkanalyseumfeld einführen RRD Tools sind die Grundlage von einem Großteil der in dieser Arbeit vorgestellten Tools. Sie erlauben eine zeitabhängige Serie von Daten aufzunehmen und grafisch darzustellen. Das erste Script (rrd_traffic.pl: ) muss in5-minuten- Intervallen aufgerufen werden (z.b. per unix cron job) und benutzt das Linux Tool ifconfig, um die Summe an gesendeten Bytes für ein Netzwerkinterface eines lokalen Rechners auszulesen. Die gewonnenen Daten werden dann in einer RRD gespeichert. Aus dieser Datenbank werden bei jedem Aufruf für jede Datenquelle 4 Bilder erstellt, welche einen Tagesgraphen, Wochengraphen, Monatsgraphen und einen Jahresgraphen zeigen. Das dazugehörige zweite Script (traffic.cgi: verwendet diese Bilder und liefert eine HTML-Seite zurück. Dieses Tool wurde vom Autor erweitert, um auch Latenzen aufzeichnen zu können. Somit ist es möglich nicht nur die genutzte Bandbreite, sondern auch Latenz von einer Node aus zu überwachen. Dabei werden 2 wichtige Kennwerte aufgezeichnet. In Abbildung 10 ist auf der linken Seite die Traffic-Übersicht für ein Netzwerkinterface in den verschiedenen zeitlichen Auflösungen zu erkennen. Rechts ist die Gesamtübersicht mit Tagesgraphen abgebildet, wobei hier 3 Interfaces und 3 Latenzgraphen sichtbar sind. Auf dem Latenzgraphen kann man einen kurzen Ausfall der Internetverbindung und einen dadurch verursachten Packet Loss erkennen. Im Ergebnis wird deutlich, dass sich das Tool vor allem zur Überwachung von einzelnen Nodes ohne eine zentrale Kontrolleinheit eignet. 49

50 Abbildung 10 - traffic.cgi Node Netzwerkinterface Statistiken sowie Latenzhistogramm Iptraf Iptraf ( ist ein Open Source Linux Netzwerk Monitoring Tool, mit dem der aktuelle Netzwerkverkehr einer Node dargestellt werden kann. Dabei werden TCP Verbindungen zusammengefasst und auch andere statistische Informationen in Echtzeit aus dem Datenverkehr durch Paketanalyse gewonnen. Mithilfe dieses Tools wird an einer Node eine Übersicht über aktuell aktive Verbindungen möglich, wodurch sich das Tool auch zum Einsatz auf Routern anbietet. Bei dem Einsatz auf Nodes bzw. Netzwerk Interfaces, die einen hohen Traffic aufweisen, wird es jedoch ohne Filter durch die Vielzahl von sichtbaren Informationen schnell unübersichtlich. Das Tool ist für eine automatische Überwachung völlig ungeeignet, man kann aber gut zur Fehleranalyse und Ursachenforschung bei aufgetretenen Problemen nutzen. Besonders hilfreich haben sich im praktischen Einsatz des Autors dabei die unterschiedlichsten Statistiken über Protokolle und Pakete erwiesen, die schnell Anomalien sichtbar machen können Tcpdump Tcpdump ( ist ein Open Source Consolen Tool, welches den aktuellen Netzwerkverkehr auf lokalen Netzwerk Interfaces darstellen oder auch aufzeichnen kann. Dazu können beliebig komplexe Filter eingestellt werden. Folglich wird nur noch der für den Betrachter relevante Datenverkehr angezeigt, was eine Analyse im Detail sehr gut zulässt. Insbesondere können mit Tcpdump dadurch Netzwerkprobleme auf der Paketebene analysieren werden. 50

51 Tcpdump ist im Detailgrad ähnlich frei wählbar; ebenfalls kann Datenverkehr durch Filter ausgeblendet werden. Der Nutzer kann aktiv entscheiden, welchen Layer er in welchem Detailgrad sehen möchte. Fundiertes Fachwissen des Benutzers zu Protokollen wird bei Einsatz dieses Tools aufgrund der Komplexität vorausgesetzt. Dieses Tool wurde vom in den eigenen Versuchen zur Untersuchung des SIP Command Channel (Session Initiation Protokoll; ein VOIP Standard) Verkehrs von einem Telefon zum SIP Server verwendet. Durch die Angabe des Parameters v für tcpdump werden die Pakete für die Darstellung bis auf die SIP Ebene aufbereitet. Auch dieses Tool ist zur dauerhaften Sicherung und Überwachung von Netzwerkqualität ungeeignet, vielmehr erlaubt es im Problemfall eine Analyse bis auf die Paketebene. Dabei ist allerdings zu beachten, dass jeweils detaillierte Protokollkenntnisse notwendig sind, um von tcpdump ausgegebenen Informationen verwenden zu können. Eine exemplarische Ausgabe einer SIP Command Channel- Kommunikation kann im Anhang nachgelesen werden Tools zur Node-zur-Node-Messung ICMP Ping Zum Bestimmen der Latenz zwischen zweier Nodes bietet sich das Internet Control Message Protocol (ICMP, RFC 792 [12]) an. ICMP definiert einen Echo Request und einen entsprechenden Echo Reply im Protokoll. Die Protokolldefinition sieht vor, dass der Empfänger in der Antwort das Paket des Senders spiegelt. Als Sender kann man daher mit einem so genannten ping die Latenz zwischen 2 Nodes bestimmen und erhält damit eine wichtige Kenngröße in der wahrgenommenen Netzwerkqualität. Betriebssysteme implementieren fast ausnahmslos das ICMP Protokoll, da es auch zur Kommunikation von Fehlern und Problemen von anderen Protokollen verwendet wird, wie zum Beispiel TCP. Das ICMP Protokoll, speziell der ping, bietet sich daher besonders zur Bestimmung der Latenz zwischen zwei Nodes an, da auch ohne Installation von Software auf der Ziel Node eine automatisierte Messung jederzeit möglich ist. Viele von den noch vorgestellten Tools bedienen sich dieser Grundlage. In den praktischen Messungen und Versuchen spielt diese Eigenschaft des ICMP Protokolls eine essentielle Rolle. So wurden mithilfe von selbst geschriebenen Scripts (die ein ping genutzt haben) die Auswirkungen von verschiedenen Versuchsbedingungen (z. B. Auslastung des Netzes, defektes Kabel) untersucht Perf. IPerf ( muss auf mindestens 2 Nodes installiert sein, um Netzwerke zu vermessen. Dabei wird eine Node als Server (Gegenstelle) und die andere als Client (Auslöser) betrieben. Messungen sind für das TCP und für das UDP Protokoll möglich. Iperf erlaubt es so, die verfügbare Bandbreite zwischen diesen Nodes im TCP und UDP Modus zu 51

52 ermitteln. Ein Bestimmen von Packet Loss, PDV (Jitter) ist protokollbedingt nur im UDP Modus möglich. Als Ergebnis wird die erreichbare Bandbreite dargestellt und im UDP Modus jeweils Packet Loss und PDV. Das Tool iperf ist damit gut geeignet, um Netzwerke unter Last zu testen oder auch Kenngrößen wie Bandbreite, Latenz und Jitter zu bestimmen. Exemplarisch soll hier nun eine Testmessung für UDP in einem Gigabit Netzwerk dargestellt werden: Client: iperf -c t 10 -u -b 1000m Client connecting to , UDP port 5001 Sending 1470 byte datagrams UDP buffer size: 124 KByte (default) [ 3] local port connected with port 5001 [ ID] Interval Transfer Bandwidth [ 3] sec 1.11 GBytes 956 Mbits/sec [ 3] Sent datagrams [ 3] Server Report: [ 3] sec 1.11 GBytes 956 Mbits/sec ms 0/ (0%) Server: r:~# iperf -s -u Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 122 KByte (default) [ 3] local port 5001 connected with port [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 3] sec 1.11 GBytes 956 Mbits/sec ms 0/ (0%) Es wurde im Beispiel eine Bandbreite von 956 Mbit erreicht mit einem Jitter von ms. Packet Loss ist nicht aufgetreten. Weiterhin wurde das Tool auch in den praktischen unter verschiedenen Netzwerkbedingungen verwendet. Insgesamt kann festgehalten werden, dass es sich gut für eine Bestimmung von den gemessenen Kennwerten in einem nicht produktiv genutzten Netzwerk eignet Tools zur Paketgenerierung Packgen Der Open Source Paketgenerator Packgen ( erlaubt es, eine definierte Last mit unterschiedlich parallelen oder aufeinanderfolgenden Paketflüssen zu modellieren und dieses Modell dann im Netzwerk zu testen. Durch die vergleichsweise komplizierte Bedienung ist das Tool nicht zum Ausmessen oder zum dauerhaften Überwachen geeignet. Jedoch kann es komplexe und praxisnahe Bedingungen in einem Netzwerk simulieren, wodurch sich unerwartete Schwachpunkte in einem Netzwerk, wie zum Beispiel durch das 52

53 Einführen von neuen Diensten oder Protokolle, durch vorherige Tests bestimmen lassen. Soll in einem Netzwerk beispielsweise VOIP eingeführt werden, kann mit packgen diese neuartige Last auf dem Netzwerk simuliert werden, ohne VOIP Dienste im Netzwerk eingeführt zu haben. Folgende Auflistung zeigt eine Beispielsimulation: Server: packgen -i listen.yml Tue Sep 13 12:05: : Listening on udp port Tue Sep 13 12:05: : Listening on udp port Tue Sep 13 12:05: : Listening on tcp port Tue Sep 13 12:05: : Listening on tcp port Tue Sep 13 12:07: : Background => Packets received: Packets lost: 0 ( %) Tue Sep 13 12:07: : Voice => Packets received: Packets lost: 1 ( %) Tue Sep 13 12:07: : Video => Packets received: Packets lost: 0 ( %) Tue Sep 13 12:07: : Best Effort => Packets received: Packets lost: 0 ( %) Client: root@test41:~# packgen -i send.yml Tue Sep 13 12:07: : Sending udp packets of 252B to :5000 (Voice) at Kb/s. Tue Sep 13 12:07: : Sending udp packets of 750B to :5001 (Video) at 2.80Mb/s. Tue Sep 13 12:07: : Sending tcp packets of 1024B to :5002 (Best Effort) at 3.20Mb/s. Tue Sep 13 12:07: : Sending tcp packets of 1024B to :5003 (Background) at 3.20Mb/s. Tue Sep 13 12:08: : Sent tcp packets (Background). Tue Sep 13 12:08: : Sent udp packets (Voice). Tue Sep 13 12:08: : Sent udp packets (Video). Tue Sep 13 12:08: : Sent tcp packets (Best Effort). In diesem Beispiel konnten 4 Streams erfolgreich übertragen werden, wobei minimaler Packet Loss im simuliertem Video Stream aufgetreten ist. Insgesamt ist das Tool gut geeignet, um synthetisch generierte und zugleich praxisnahe Paketflüsse in einem Netzwerk zu simulieren. 53

54 Ostinato Ostinato ( ) ist ein Open Source Paket Generator, welcher sich durch gute Bedienbarkeit und Flexibilität auszeichnet. Er wurde dabei an die IXIA Oberflächen angelehnt. Mit Ostinato ist es möglich, sowohl Paketflüsse selber zu erstellen als auch aufgezeichnete Paketflüsse auf einem Netzwerk Interface wiederholt abzuspielen. Zusätzlich gibt es für Ostinato einen Patch ( 10-gbit-traffic-generator-using-pf_ring-and-ostinato/), der es ermöglicht, auch Gigabit Links mit dem Test-Tool zu saturieren. Daher stellt Ostinato eine gute Option dar, wenn Probleme oder Lastsituationen in 10G Netzwerken nachvollzogen werden sollen. Ostinato funktioniert zudem auch dezentral. Es kann daher mit einer Software (drone, Programm ist im Paket mit enthalten) Netzwerkverbindungen einer anderen Node für eine zentrale Kontrolleinheit zur Verfügung stellen. Die Netzwerkverbindung der Kontrolleinheit wird nicht zum Flaschenhals, da Ostinato erst die Informationen, die zur Paketsimulation notwendig sind, auf die drone überträgt und dann in einem zweiten Schritt die Simulation gestartet werden kann. Eine Kontrolleinheit kann verschiedene drones gleichzeitig steuern, wodurch es sehr einfach möglich ist, Node-zu-Node-Verbindungen in allen Aspekten zu simulieren. Abbildung 11 zeigt die Oberfläche von Ostinato, mit der sich die Simulationen zentral kontrollieren lassen. Abbildung 11 - Ostinato Paketgenerator 54

55 Durch die Möglichkeit, bereits gewonnene Mitschnitte wieder auf dem Netzwerk zu testen, ist Ostinato hervorragend geeignet, um aufgetretene Probleme ohne aufwändige Modellierung oder Rekonstruktion nachzuvollziehen. Relevante Mitschnitte könnten so zum Beispiel direkt von Herstellern oder anderen Administratoren zur Verfügung gestellt werden, um ein Netzwerk zu testen. Vom Autor wurde es zum Beispiel zum Testen des selbstentwickelten Tools verwendet, da es sehr einfach ist, paketgenaue Simulationen zu entwerfen Ixia Tools Ixia ( eine börsennotierte Firma, die führend im Bereich des Netzwerk Test Equipments ist und dabei Kunden, wie zum Beispiel Cisco, NTT, Alcatel-Lucent, Ericsson und Juniper betreut [21]. Dem Autor ist es leider nicht gelungen, Ixia-Hardware zum Testen zu bekommen. Daher kann nur theoretische Möglichkeiten dargestellt werden: Ixia bietet verschiedenste modulare Testhardware für Netzwerksysteme an, mit denen selbst modernste Gigabit-Netzwerkhardware an seine Grenzen der Leistungsfähigkeit getestet werden kann. Besondere Eigenschaften (wie zum Beispiel über verschiedene Testhardware synchronisierte Zeit) erlauben im Vergleich zu Softwarelösungen verschiedenste Szenarien sehr detailgetreu zu modellieren und an der Hardware zu testen. Die Datenblätter und Produktinformationen hinterlassen den Eindruck, dass mit Ixia-Tools auch sehr komplexe Szenarien und Strukturen mit hunderten Nodes abgebildet werden können. Im kommerziellen Umfeld sind solche Hardwaretesttools daher bestens geeignet, um genaue Messungen vorzunehmen Tools für zentrale Messungen und Überwachung Smokeping Das Open Source Project Smokeping ( ist hervorragend geeignet, um Netzwerkqualität und Verbindungsqualität zuverlässig von mehreren Messpunkten aus zu überwachen. In einem konfigurierbaren Intervall werden ICMP Ping-Pakete an so genannte Targets verschickt und dabei Latenz, PDV sowie Packet Loss festgehalten. 55

56 Abbildung 12 - Smokeping Übersicht Erfasste Werte können dann als Verlauf genauer durch Graphen analysiert werden. Eine Übersicht ist in Abbildung 12 abgebildet. Es können dafür beliebige Ausschnitte ausgewählt werden, wobei Smokeping die Daten so aufbereitet, das die Graphen aussagekräftig sind, wie zum Beispiel. in Abbildung 13 llustriert. Abbildung 13 - Smokeping: Daten für einen Zeitraum für ein Target im Detail Die große Stärke von Smokeping liegt vor allem im Bereich der verteilten Messungen, wodurch es sehr einfach ist, dieselben Targets auch von einer anderen Node aus zu überwachen (so genannte Slaves), die Daten jedoch an zentraler Stelle zu sammeln. Die gesammelten Werte für ein Target von verschiedenen 56

57 Nodes werden dabei in einer Übersicht in einem Graphen zusammengefasst wie auch schon in Abbildung 12 sichtbar wurde. Smokeping selbst ist nicht auf das Sammeln von Latenzdaten durch IMCP Ping- Pakete beschränkt und kann durch andere so genannte Probes ( erweitert werden. Als Beispiel lässt sich so die Antwortzeit eines Domain Name System (DNS RFC 1034 und RFC 1035 [12]) Servers überwachen. Zusammengefasst kann festgehalten werden, dass Smokeping in den praktischen Tests dass es vergleichsweise einfach zu konfigurieren war und sowohl die Art der Datenerfassung als auch die Präsentation einen guten Einblick und Überblick über die aktuelle Netzwerkqualität bieten Nagios Das Open Source Project Nagios ( soll hier exemplarisch als ein vollautomatisches Monitoring-System vorgestellt werden, das sämtliche Komponenten in einer IT-Infrastruktur überwachen kann. Im Mittelpunkt steht das Überwachen von Messwerten in einem definierten Toleranzbereich. Es bietet sich daher an, die komplette Infrastruktur inklusive der Verbindungselemente und Nodes aus einem Netzwerk per Nagios zu überwachen. Nagios definiert für jeden überwachten Wert (Dienst) 3 Wertebereiche: Normal, Warnung und Kritisch. Jeder Dienst wird darauf etwa alle 5 Minuten überprüft. Tritt eine Veränderung ein, wird durch Nagios Alarm ausgelöst. Ein ausgelöster Alarm kann eine SMS oder eine an den Administrator schicken oder durch erweiterte Konfiguration auch automatisch eine Gegenmaßnahme einleiten. Nagios ist sehr modular aufgebaut und bietet verschiedenste Wege Messwerte zu erfassen und beliebige Aktionen in bestimmten Wertebereichen auszuführen. Durch seine Flexibilität und Robustheit ist Nagios in kleineren Firmen, Rechenzentren, Fabriken, aber auch in Atomkraftwerken im Einsatz, in denen oft tausende Werte überwacht werden. Dazu wurden zahllose Addons für verschiedenste Anwendungsbereiche entwickelt (z.b. Apache, MySql, Ping, Switch Error Rate, Link Geschwindigkeit, Speicher Auslastung), neue Benachrichtigungswege ( neue Oberflächen für eine bessere Übersicht ( (GUIs-and-CLIs)/Web-Interfaces) und Erweiterungen für andere Bereiche der Software. 57

58 Abbildung 14 - Nagios: Netzwerkansicht Nagios erlaubt hierarchische Zusammenhänge von Nodes (Hosts) abzubilden (zum Beispiel siehe Abbildung 14) und beachtet diese Hierarchie auch bei der Eskalation von Fehlerzuständen. Zur Überwachung von Vermittlungseinheiten ist es nötig, diese als Hosts in Nagios einzupflegen, wodurch sie dann beispielsweise mit SNMP Abfragen überwacht werden. Die Erstellung einer funktionierenden Nagios-Konfiguration und Wartung kann sehr komplex und aufwändig sein. Durch seine Flexibilität auch in der Konfiguration ist es einfach, Mehraufwand durch eine falsche Herangehensweise zu erzeugen. Ist eine Infrastruktur eingepflegt, kann ein Administrator sofort erkennen, wo und welche Probleme auftreten und wird darüber auch bei Bedarf sofort informiert. Exemplarisch ist der Arbeit auszugsweise im Anhang eine mit Host Groups arbeitende, selbst erstellte Konfiguration beigefügt, die durch diese Abstraktion erlaubt, ähnliche Nodes einfach mit in die Überwachung durch Nagios aufzunehmen. Nach Entstehung des Tools wurde Nagios kontinuierlich weiterentwickelt, wobei ab 2009 der Hauptentwickler von Nagios eine kommerzielle Version namens Nagios XI ( ) zur Verfügung gestellt hat. Diese Version wurde um einige Features ergänzt (wie z.b. grafische Trendanzeige von Werten) und hat das Ziel, die Konfiguration von Nagios einfacher zu machen. 58

59 Zu diesem Zeitpunkt im Jahre 2009 wurde das Open Source Project Icinga ( ins Leben gerufen, um einer fehlenden Weiterentwicklung am Open Source Nagios Projekt entgegenzuwirken. Icinga ist im direkten Vergleich noch nicht so weit verbreitet wie Nagios ( bietet aber zunehmend eine interessante Alternative dazu, da die Umstellung von Nagios zu Icinga problemlos funktionieren soll. In der Praxis ist Nagios durch seine Flexibilität und Zuverlässigkeit für die Überwachung von Netzwerken unentbehrlich. Dies zeigten praktische Tests des Autors in wiederholtem Maße soltflowd Softflowd ( ist ein Open Source Tool, welches durch das Erfassen aller Pakete auf einem Linux Rechner Interface einen Netflow Stream erzeugt und diesen Netflow an eine beliebige andere Node adressieren kann. Damit ist es möglich, mit einem Linux Router einen Netflow Stream zu erzeugen, der dann mithilfe von anderen Tools (z.b. ntop) an einer beliebigen anderen Node ausgewertet oder archiviert werden kann. Der Stream ist kompatibel zu durch Cisco- Hardware erzeugten Streams und kann daher mit allen Netflow kompatiblen Programmen verwendet werden. Dieses Tool ist primär durch seine Kombination mit anderen Tools, wie zum Beispiel ntop relevant. Weiterhin hat es dem Autor erlaubt, die Funktionsweise von Flow- Protokollen alleinig mit Linux-Rechnern zu untersuchen. Es schafft durch seine Funktionalität einen einfachen Weg auch Linux Router-Verkehrsstatistiken in professionelle Tools einfließen zu lassen. Dies ist sonst nur teurer Hardware, wie zum Beispiel managed Cisco-Switches, vorbehalten Cacti Cacti ( ermöglicht es Messwerte von Nodes oder Vermittlungselementen in Netzwerken kontinuierlich zu erfassen und diese grafisch darzustellen. Dabei bietet Cacti verschiedenste Möglichkeiten Werte zu erfassen. Die Standardmethode, um Werte für Switches zu erfassen, ist SNMP. Es werden fertige Templates angeboten, mit denen die Konfiguration relativ einfach funktioniert. Cacti ist modular und beliebig erweiterbar, Daten können also auch aus anderen Quellen angebunden werden. Beispielsweise ist möglich, Messwerte per Remote Shell auf einer Node zu gewinnen oder direkt über Protokolle, wie zum Beispiel SQL, Daten von einem Dienst zu erfassen. Cacti kann optimal zur Langzeit- und Trenderfassung in Netzwerken eingesetzt werden. Durch die Flexibilität kann es gleichzeitig wichtige Systemressourcen (CPU, Speicher, IO) auf Nodes und auf Vermittlungseinrichtungen erfassen. Diese Flexibilität ermöglicht dem Administrator Trends frühzeitig zu erkennen und dadurch einer eventuellen Überlastung bei Diensten oder Vermittlungseinrichtungen vorzubeugen. 59

60 Cacti bietet von sich aus keine Möglichkeit, bei Überschreiten von bestimmten Toleranzbereichen für einen Messwert automatisch per oder Pager zu informieren. Diese Funktionalität kann aber durch Erweiterung mit vorhandenen Addons nachgerüstet werden. Als Einsatzort eignen sich mittelgroße und große Netzwerke, in denen der Aufwand zur Installation und Wartung abgedeckt werden können. Die Möglichkeit Trends zu erfassen und aktuelle Auslastung in historischen Bezug zu setzen, ist die große Stärke von Cacti. Diese Stärke wird vor allem immer dann interessant, wenn entweder Änderungen am Netzwerk oder an Diensten durchgeführt wurden und Auswirkungen überwacht werden soll. Des Weiteren stellt dieses Tool eine gute Möglichkeit dar, wenn man einen systemweiten Überblick als Planungsgrundlage für Erweiterungen in einem Netzwerk gewinnen möchte. Gleichzeitig ist es durch die Trenderfassung genauso möglich vor der Überlastung von Diensten oder Vermittlungseinrichtungen zu reagieren. Abbildung 15 - Cacti: Überwachung von Switch Port und Switch CPU In Abbildung 15 wird exemplarisch die Überwachung von Switch Ports (3 Bilder, oben) sowie einer Switch CPU (Unten) gezeigt. 60

61 Abbildung 16 - Cacti: Überwachung von Nodes und Diensten In Abbildung 16 werden exemplarisch die Überwachung von Nodes und Dienste gezeigt. Der Load Average einer Linux Node gibt dabei an, wie ausgelastet die verfügbaren Betriebsressourcen, wie zum Beispiel Speicher, CPU und IO in dieser Node sind. In der Abbildung wird ein MySql-Server (Anzahl der auftretenden Commands) und ein Apache Webserver (Anzahl von Anfragen) überwacht. Die Graphen auf der rechten Seite zeigen die unterschiedlichen Auflösungen von Aufzeichnungen. Von oben nach unten werden folgende Auflösungen für den Load Average einer Node dargestellt: stündlich, täglich, wöchentlich und monatlich. Für die Untersuchung in der vorliegenden Arbeit wurde ein vollständiges Cacti- System installiert und Versuche durchgeführt, um die Leistungsfähigkeit des Systems einschätzen zu können. Im Vergleich zu Nagios ist beispielsweis die einfachere Grundkonfiguration aufgefallen, wobei es durch Erfassung von für das Netzwerk speziellen Kennwerten auch schnell kompliziert werden kann. Generell ist Cacti hervorragend zur automatischen Überwachung und Erfassung von historisch relevanten Kennwerten geeignet. Wie in den Abbildungen dargestellt werden diese übersichtlich dargestellt WildPackets Tools WILDPACKETS, INC bietet kommerzielle Netzwerk Monitoring-Tools an. Nach eigenen Aussagen und Recherche sind sie dabei Marktführer auf dem Segment der Netzwerkanalyse und Monitoring für den 10GBit Ethernet Standard [18]. 61

62 Ähnlich der Faktenlage bei Ixia stand dem Autor keine Hardware zum Testen zur Verfügung, sodass sämtliche Informationen über Webcasts und Produktsheets, die der Hersteller veröffentlicht, erschlossen wurden. Durch verschiedene dedizierte Hardwarekomponenten erlauben die Wildpackets Tools sämtlichen Netzwerkverkehr in Echtzeit zu analysieren, zu überwachen und auch zu archivieren. Damit kann eine Analyse, sobald ein Problem aufgetreten ist, sofort anhand der aufgezeichneten Pakete stattfinden, ohne die problemverursachende Situation mühsam nachstellen zu müssen. Es können also die tatsächlich zum Zeitpunkt der Störung vorliegenden Netzwerkpakete nachträglich analysiert werden. Abbildung 17 - Wildpackets Komponentenübersicht Wie Abbildung 17 verdeutlicht, wird die Hardware an zentralen Punkten ins Netzwerk eingesetzt (Timeline oder Omnipliance) bzw. erhält durch die SFlow/Netflow Protokolle ihre Daten (Watchpoint Collector). Es müssen nicht alle Komponenten im Netzwerk eingesetzt werden, bevor eine Analyse möglich ist, jedoch stellen die einzelnen Komponenten gegenseitig gute Ergänzungen dar. Als Beispiel für ein verfügbares Produkt soll Timeline 2 ( ) kurz vorgestellt werden. Es zeichnet sich durch die Fähigkeit aus, ununterbrochen 11GBit Datenverkehr aufzeichnen zu können und kann diesen Datenverkehr dabei zudem in Echtzeit analysieren. Während der Datenverkehr aufgezeichnet wird, ist es weiterhin möglich, vorhandene Archivdaten intuitiv über ein Webinterface zu durchsuchen und so zu analysieren. Eine so hohe Integration ist mit frei verfügbaren Software-Lösungen bisher nicht denkbar. Insbesondere der Übergang zu 10GBit oder 100GBit Netzwerken stellt Hardware und Software vor bisher unbekannte Herausforderungen. Wildpackets hat sich diese Leistungsfähigkeit durch eine unabhängige Partei bestätigen lassen und kann unter folgendem Link nachgelesen 62

63 werden: Line_NetRec.pdf. Abbildung 18 - Wildpackets OmniPeak - VOIP: EchtzeitGesprächsübersicht mit Qualitätsbewertung Im Konzern- und Rechenzentrumumfeld sind Produkte wie Timeline sehr interessant, da sie es schaffen, bestimmte Dienste in Echtzeit zu analysieren. Man kann so aufgetretene Probleme im Nachhinein bis auf die Paketebene untersuchen. Timeline ermöglicht es weiterhin, bis zu 2000 VOIP Datenströme gleichzeitig live zu analysieren und zu bewerten. Dabei werden alle für Qualitätsaussagen kritischen Eigenschaften in Echtzeit bestimmt und auch in einem Webinterface visualisiert, was in Abbildung 18 dargestellt wird. In Kombination mit konfigurierbaren Alarmmechanismen kann so ein Netzwerkadministrator sofort informiert werden, sollte es zu Qualitätsproblemen in Echtzeitprotokollen wie VOIP kommen und kann dementsprechend Maßnahmen einleiten ntop Ntop ( ist ein Open Source Tool, welches den eingehenden Datenverkehr (Traffic) analysiert und Statistiken über ein Webinterface zur Verfügung stellt. Als Quelle für analysierten Traffic kann ein lokales Netzwerkinterface oder eine Netflow Quelle dienen. Die Statistiken können jederzeit über ein Webinterface eingesehen werden, wobei nach verschiedensten Kriterien gefiltert und sortiert werden kann. Ntop erlaubt es daher auch mithilfe eines Open Source Tools schnell Überblick über den im Netzwerk vorkommenden Datenverkehr zu erhalten. Dabei werden nicht die Daten selbst, sondern die Statistiken und Messwerte archiviert. 63

64 Die Untersuchungen im Rahmen der vorliegenden Arbeit haben gezeigt, dass diese Vorgehensweise ressourcenschonend ist. Jedoch hat sie große Nachteile im Vergleich zu kommerziellen Lösungen, wie zum Beispiel Timeline von Wildpackets. Dies ist vor allem der Fall, wenn man entstandene Anomalien oder Probleme zu einem späteren Zeitpunkt nachvollziehen möchte. Generell bietet ntop viele übersichtliche Statistiken zu Nodes und Protokollen, zum Beispiel lassen sich sehr einfach die Nodes mit dem höchsten Bandbreitenbedarf bestimmen Tools zu Analyse von Paketaufzeichnungen In der Open Source Welt hat sich das pcap Dateiformat [22] durchgesetzt. Daher werden hier nur Tools betrachtet, die dieses Format lesen können. Durch Tools wie editcap ( lassen sich jedoch auch andere Aufzeichnungen in das pcap Format umwandeln und damit genauso verwenden Wireshark Wireshark ( ist ein Open Source Tool, welches Pakete von einem Mitschnitt oder von einem Netzwerkinterface analysiert, grafisch darstellt und dabei filtern kann. Es ermöglicht zum Beispiel TCP Verbindungen zu rekonstruieren und die Nutzdaten als Stream zu speichern. Ebenfalls besteht die Möglichkeit, den Sprachdatenstrom bei VOIP als Audiodatei zu sichern. Damit sind auch die größten Stärken von Wireshark beschrieben, welches detaillierte Protokollkenntnisse auf Anwendungsebene hat (über Filter seit Version [23]) und Pakete entsprechend darstellen kann. Dabei werden selbst proprietäre Protokolle wie das Skinny Call Control Protocol (SCCP) von Cisco entschlüsselt und den Paketen ein Funktionsprotokoll zugeordnet. Wireshark wurde in der Arbeit benutzt, um beispielsweise Test Streams für das selbstentwickelte Tool zu erzeugen, die dann mit Ostinato im Netzwerk simuliert wurden tshark Tshark ( ) ist ein Open Source Consol Tool, welches Paketdaten aus pcap Aufzeichnungen oder direkt von einem lokalen Netzwerkinterface analysiert. Es ist Teil des Wireshark-Ökosystems und besitzt grundsätzlich die gleiche Funktionalität wie tcpdump. Tshark ist besonders interessant zur Überwachung der Netzwerkqualität, da es eine Echtzeitanalyse von RTP Streams oder auch anderen Protokollen erlaubt. Folgender Auszug zeigt ein Beispiel, in dem tshark Kenngrößen wie Jitter und Packet Loss sowie andere technische Daten ausgibt: >tshark -z rtp,streams -q host Capturing on eth packets captured 64

65 ========================= RTP Streams ======================== Src IP addr Port Dest IP addr Port SSRC Payload Pkts xCFFF52C3 ITU-T G.711 PCMU x13DFA2D4 ITU-T G.711 PCMU 623 Lost Max Delta(ms) Max Jitter(ms) Mean Jitter(ms) Problems? 0 (0.0%) (0.0%) =========================================================== === Damit ist tshark gut geeignet um qualitative Aussagen über ein Netzwerk unter verschiedenen Realbedingungen geben zu können. Tshark hat mit diesen Eigenschaften eine wichtige Rolle bei der Untersuchung vom Netzwerkverhalten unter Lastbedingungen gespielt. 7 Experimentelle Bestimmung von Kenngrößen in der Praxis Nach der erfolgten Analyse und Vorstellung von verschiedenen Tools soll nun für diesen Teil der Arbeit das Wissen genutzt werden, um Kenngrößen mit Qualitätsrelevanz wie Bandbreite, Latenz und Packet Loss in einem Beispielnetz zu bestimmen. In der Analyse der Tools wurden diese jeweils in mindestens einem Netzwerk installiert und getestet. Wie im Abschnitt Bestimmen von Leistungs- und Qualitätskenngrößen für ein Ethernet ausgeführt ist es jedoch schwierig, bestimmte Kenngrößen wie Bandbreite in einem im produktiven Einsatz befindlichen Netzwerk zu testen. Die vorgestellten Tools dienen daher vor allem zur dauerhaften vollautomatischen Überwachung von Netzwerkqualität. Im Unterschied dazu soll hier Aussagen aus dem Abschnitt Netzwerkelemente und ihr Einfluss auf die Netzwerkqualität in der Praxis bestätigt werden und dazu in einem Testnetzwerk verschiedenste Szenarien nachgestellt werden. Eine Bewertung der Messergebnisse und deren praktische Relevanz wird im nächsten Abschnitt Einordung der Kenngrößen und ihrer Bedeutung in einem Ethernet angeboten. 65

66 7.1 Vorgehensweise Die Testmessungen haben in einem Testnetzwerk mit über 5 Nodes stattgefunden. Dieses wurde mit unterschiedlichen Switch Typen (Gigabit managed, Gigabit unmanaged, 100Mbit unmanaged, 100Mbit managed) und Kabeln aufgebaut (Schema siehe Abbildung 19 um Auswirkunken auf die Netzwerkqualität zu untersuchen. Abbildung 19 Schema Testnetzwerk In dem Netzwerk wurde in jeder Konfiguration die erreichbare Bandbreite, die Latenz unter den Nodes und der Packet Loss gemessen. Diese Messungen wurden jeweils ohne erzeugte Netzwerklast durchgeführt sowie unter 80, 90 und 100% Auslastung von einzelnen Links im Netzwerk. Weiterhin wurden verschiedene Konfigurationen am Netzwerk vorgenommen. Alle Switches sind in der Grundkonfiguration Gigabit unmanaged Switches. Alle Nodes (auch der Server) mit Ausnahme des Telefons verwenden ein Linux Betriebssystem. Das Telefon ist ein Cisco 7940, auf dem Server ist ein Asterisk (IP PBX, installiert. Als VOIP Standard wurde SIP genutzt. Für die Messungen wurden verschiedene schon angesprochene Variationen am Netzwerk durchgeführt, um so verschiedenste Einflüsse wie CPU, Kabel, 66

67 Netzwerkkarte, Betriebssystem und Switch auf die messbare Qualität simulieren zu können. Variationen: - Node Test PC (1. Node) o Diese Node wurde auch mit einem Windows 7 Betriebssystem betrieben - Test Switch (4. Switch) o Für den Switch wurden verschiedene Switches verwendet Ein unmanaged 100MBit Switch Ein unmanaged 1GBit Switch Ein managed 1GBit Switch Ein managed 100Mbit Switch - Für Link 4 und Link 1 wurden verschiedene Netzwerkkabel verwendet o 10m, 50m, 100m, ein Kabel mit defekter Ummantelung und ein Kabel mit sichtbar defektem Stecker auf einer Seite - Die Nodes hatten unterschiedliche Netzwerkkarten und CPUs Messmethoden und Tools: - Zum Bestimmen und Testen der verfügbaren Bandbreite wurde iptraf eingesetzt - Zum Erzeugen von Paketlast von Links wurde ein selbst geschriebenes Tool (traffgen) eingesetzt. Es erlaubt von einer Node zu einer anderen eine bestimmte Paketlast zu erzeugen, ohne den Konfigurationsbedarf von packgen. - Latenz, Packet Loss und PDV wurde jeweils mit ping und tshark (für eine Test VOIP Verbindung) bestimmt. 7.2 Messwerte Auszüge zu den Messungen sind im Angang Messwerte zu finden, da eine ausführliche Auflistung an dieser Stelle den Rahmen auch im Hinblick auf die vorgegebene Zeitenzahl dieser Arbeit sprengen würde. Weiterhin wurden bei den Messungen keine unerwarteten Effekte beobachtet, was im sich anschließenden Fazit genauer ausgeführt wird. 7.3 Fazit Die Messungen haben gezeigt, dass einfache unmanaged Hardware für wenige Nutzer und Nodes zufriedenstellende Netzwerkqualität sicherstellen kann. Die Unterschiede auf der Arbeitsplatzbereichebene sind heute nicht mehr relevant, auch nicht für Realtime Protokolle wie VOIP. Preiswerte Switches zeigen ihre Schwächen klar bei einer Oversubscription von Links, was an dem kleinen Puffer, der für Pakete zur Verfügung steht, liegt. Versuche, Herstellerangaben zu Switches zu verifizieren, konnten nur mit begrenztem Erfolg durchgeführt werden. In den Tests hat sich die Hardware wie in den Datasheets verhalten. Jedoch ist es schwierig Grenzfälle, wie zum Beispiel volle Puffer oder eine Überlastung der Backplane, ohne Simulationshardware zu erzwingen. Bei preiswerteren unmanaged Switches brechen aufgrund kleinerer Puffer bei einer Auslastung des Uplinks (Link4) die Kennwerte messbar ein und es sind höhere Jitter 67

68 und Packet Loss zu beobachten. Wird der Uplink mit durch die Node verursacht, von der aus die Messungen durchgeführt werden, sind diese Einbrüche wiederum nicht mehr so stark zu beobachten. Diesen Effekt kann man damit erklären, dass die Netzwerkkarte nur eine begrenzte Anzahl von Paketen abschicken kann und diese durch Mechanismen im Betriebssystem fair verteilt werden. Dieser Effekt ist nicht überraschend, da insbesondere Dienste wie VOIP im Vergleich zu der zur Verfügung stehenden Bandbreite nur einen sehr kleinen Anteil an der Gesamtbandbreite ausmachen. Wird ein Uplink (Link 4) durch mehrere Nodes saturiert (Node 4, Node 1) bricht eine VOIP-Verbindung von der Node 3 in der Richtung zum Server Node 5 ein, durch Full Duplex ist die Leitung zum Telefon jedoch unberührt. Diese Messungen zeigen klar, dass andere Nodes den Datenverkehr ohne Netzwerkmanagement erheblich stören können. Dies ist ein erwartetes Ergebnis und bestätigt die Theorie. Zusammengefasst verhalten sich unmanaged Switches besonders in Lastszenarien aufgrund einer fehlenden und nicht vorzunehmenden Konfiguration unzureichend. Wird durch die Netzwerkstruktur einer Link Oversubscription vorgebeugt (Link 1,2,3 100Mbit und Link4 1GBit) sind diese Effekte nicht mehr durch die Auslastung von einzelnen Nodes zu messen. Sind im Gegensatz dazu Managed Switches im Einsatz, verhalten sich diese bei großen Paketen sowie in Lastszenarien auch ohne Konfiguration messbar besser. Diese Effekte lassen sich einfach durch dem Datenblatt zu entnehmende größere Bandbreiten in der Switch Backplane und die Größe der Puffer begründen. Kabellängen im lokalen Netzwerk führen zu keinen messbaren Unterschieden. Lediglich bei Verwendung des defekten Kabels wurde von bestimmter Netzwerkhardware kein Link erkannt und der Datenaustausch konnte nicht stattfinden. Wurde ein Link erkannt, konnten keine messbaren Unterschiede festgestellt werden. Auch diese Beobachtung deckt sich mit der Theorie. Den größten Einfluss auf die für eine Node wahrnehmbare Netzwerkqualität hatte die verwendete Netzwerkhardware. Schlechte Netzwerkhardware verursachte teilweise die doppelte RTT und zusätzlich eine höhere CPU Last. Dabei ist ohne weitere Untersuchungen nur möglich zu mutmaßen, ob dies eine nur von Treibern verursachte Differenz darstellt oder ob das Hardwaredesign daran beteiligt ist. Wie aus den Messwerten ersichtlich wird, ist eine Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller im Durchschnitt Faktor 1,5 schneller bei einem ping als ein Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet Controller. Für ein 1472/1500 Byte Ping Paket brachte es die Marvellkarte auf eine Latenz von Millisekunden (mit ms PDV) im Durchschnitt und die Realtek Karte auf 0.462ms (mit ms PDV). Ping und PDV sind jeweils schlechter. Dieses Verhalten deckt sich mit den Erwartungen aus dem Abschnitt Netzwerkelemente und ihr Einfluss auf die Netzwerkqualität. 68

69 Durch das Experiment wurde auch bestätigt, das eine ständige Überwachung der Vermittlungseinrichtungen notwendig ist, will man Überlastszenarien erkennen und reagieren können. Es ist in einem nicht homogenen Netzwerk mit verschiedensten Nodes (unterschiedliche Betriebssysteme und Hardware) nicht möglich, Software zur Messung zu installieren (z. B. auf dem Cisco 7940 Telefon). Lokale Messungen eignen sich daher nur zur einmaligen Vermessung von einem Netzwerk, diese kann jedoch keine Aussagen über die tatsächliche tägliche Auslastung und Belastung eines Netzwerks geben. Vielmehr kann man nach dem Aufbau eines Netzwerks dessen erwartete Kenngrößen verifizieren oder im Fehlerfall durch Messungen Anomalien verifizieren. Es ist durch diese Messungen eben nicht möglich, einfach einen Gesamtüberblick über die Netzwerkauslastung zu bekommen. Jede Messung beeinflusst den schon auf dem Netzwerk stattfindenden Datenaustausch und die Nutzung von Tools wie iptraf stört diesen auch sofort empfindlich für andere Teilnehmer, da das Tool die vorhandene Bandbreite saturiert. Jedoch haben die Messungen wieder die Vorteile einer zentralen Messung bestätigt, in der (wenn Tools einmal konfiguriert sind) einfach ein Gesamteindruck über die aktuelle wie auch historische Belastung des Netzwerk gezeigt werden kann. 7.4 Einordung der Kenngrößen und ihrer Bedeutung in einem Ethernet Teil der experimentellen Bestimmung war es auch, in modernen Netzwerken auftretende Wertebereiche zu bestimmen und ihren Einfluss auf anspruchsvolle Anwendungen (wie VOIP oder Hochgeschwindigkeitsdatentransfers) zu untersuchen. Auch dazu wurden wieder Messungen des Autors vorgenommen. Diese fanden sowohl im Testnetzwerk als auch in dem in der Einleitung erwähnten Wohnheim mit eigener Software statt Relevanz und Einordnung der Kenngröße Bandbreite Bandbreite besitzt wie eingangs erläutert vor allem für Dienste mit hoher Datendichte eine hohe Relevanz. Das Prinzip der Strukturierten Verkabelung setzt voraus, dass ausgehend von der Arbeitsplatzschicht in Richtung Primärer Schicht immer mehr Bandbreite für einen einzelnen Link zur Verfügung steht. Andernfalls kommt es zu immer mehr Oversubscription von Links und das Netz kann zusammenbrechen. Protokolle wie TCP teilen die an den Flaschenhälsen verfügbare Bandbreite automatisch auf alle Verbindungen auf, verbindungslose Protokolle führen jedoch zu einem Kollaps der Netzwerkqualität. PDV und Latenz steigen und der Packet Loss nimmt zu. Für einen Anwender sind heute Bandbreiten von bis zu 1GBit am Arbeitsplatz relevant. Werden Daten schneller mit dem Netzwerk ausgetauscht, sind Festplatten und andere Komponenten in einem Arbeitsrechner damit überfordert [24]. 69

70 Solange das Budget es zulässt, ist es dementsprechend in großen Netzwerken möglich, Links im Primärbereich auf 100GBit zu erweitern. Damit wird die von einer Node empfundene Netzwerkqualität alleinig von der eigenen Leistungsfähigkeit abhängig, da der Primärbereich mit 100GBit ausreichend dimensioniert ist Relevanz und Einordnung von Paketverlusten im Ethernet Paketverlust ist wie in vorangegangenen Abschnitten beschrieben prinzipbedingt und gewollt (siehe dazu Abschnitt Qualität in Ethernet Netzen Definition und Einflussquellen ). Sollte es jedoch zu erhöhtem Packet Loss in einem Ethernet kommen, brechen Übertragungsraten von TCP sofort ein und Echtzeitprotokolle wie RTP und im speziellem VOIP erleiden einem merklichen Qualitätsverlust. 10% Packet Loss (in Richtung Empfänger zu Sender, simuliert mit Linux Iptables) in einem Gigabit Netzwerk haben in Versuchen gezeigt, dass TCP Verbindungen abbrechen und Transferraten von 90MB/s auf weniger als 3 MB/s zusammenbrechen. Bei 1% zufälligem Packet Loss sind es etwa noch 30MB/s Transferrate. Eine mögliche Berechnung ist dazu z.b. unter beschrieben. Der Autor schlägt folgende Formel vor (Rate <= (MSS/RTT)*(1 / sqrt{p})), mit der die theoretische maximale Übertragungsrate von TCP (Rate) anhand von Kenngrößen angenähert werden kann. Dabei wird die Paketgröße (MMS), die Round Trip Time (2x Latenz, RTT) und der prozentuale Paketverlust (p) berechnet werden. Beispielsweise: Rate <= (1460/0,4) *10 was etwa 35,6 Mbyte/s entspricht und nah an dem Praktisch gemessenen Wert liegt, wobei die RTT in der Berechnung mit 0,4 nur angenähert worden ist. Paketverlust ist daher kritisch für die von Nodes empfundene Netzwerkqualität. Erfahrungen im Wohnheim haben gezeigt, dass es bei Hardwarefehlern oft zu unerwartetem Packet Loss kommt. Oft finden sich jedoch Indizien wie Fehlercounter bei Ports oder andere Eigenschaften Relevanz und Einordnung der Kenngröße Latenz sowie PDV Durch den eingesetzten Ethernet Standard entsteht Latenz beim Senden und Empfangen von Paketen (siehe Abbildung 8). In der Praxis sind jedoch für alle betrachteten Protokolle Latenzen kleiner als einer Millisekunde mehr als ausreichend. Interessant werden geringe Latenzen bei Anwendungen wie ISCSI (RFC 3720 [12])und High Performance Computing, bei denen direkt über das Netzwerk die zu verarbeitenden Daten angefordert werden. Bei der Betrachtung von zwei Nodes, die über einen managed Gigabit Switch verbunden sind und Linux als Betriebssystem einsetzen, ist die Latenz unter 0,05 Millisekunden. Dies ist exemplarisch näherungsweise mit einem ping zu bestimmen. ping i c q -s 36 PING ( ) 36(64) bytes of data ping statistics packets transmitted, received, 0% packet loss, time ms rtt min/avg/max/mdev = 0.045/0.115/0.817/0.043 ms 70

71 Dabei wird erkennbar, dass bei einer Paketgröße von 64 Byte die Umlaufzeit (RTT) bei etwa 0.115ms liegt und die PDV prozentual mit 37% relativ hoch ist, jedoch mit 0.022ms in einer sehr kleinen Größenordnung liegt. Diese unterschiedlichen Messwerte kommen durch schon angesprochene Effekte in den Nodes zustande. Bei Zeiten in dieser Dimension ist es relevant, ob die Bearbeitung eines Interrupt in einem Betriebssystem sich auch nur leicht verzögert. Da ein Ping ein Paket hin und her betrachtet, ist die Latenz der Verbindung: Umlaufzeit/2 für eine Verbindung, und daher 0,12/2 ~ 0,5. Ebenfalls ist auch die PDV in etwa zu halbieren, betrachtet man nur eine Wegstrecke (wie z.b. bei VOIP relevant, da Pakete nur eine Strecke zurücklegen). Der prozentuale Anteil bleibt jedoch in etwa gleich. Bei 1500 Byte ist die Umlaufzeit durch die verlängerten Bitzeiten 0.370ms bei gleicher PDV. Wie auch der Packet Loss ist die Latenz ausschlaggebend für die erreichbare Übertragungsrate in einer Verbindung. In lokalen Ethernet Netzwerken kommt sie jedoch nicht in Bereiche, in denen das relevant wäre. Um dies zu verifizieren benutzt man wieder die Formel zur näherungsweisen Berechnung der maximal erreichbaren Übertragungsrate wie im Absatz zuvor. 8 Dauerhafte Qualitätsüberwachung und Früherkennung von Fehlern oder Engpässen In diesem Kapitel werden Erfahrungen aus dem Abschnitt Analyse und Vorstellung von verfügbaren Tools, Protokollen und Methoden verwendet, um zu beschreiben wie mit diesen Tools die Qualität in einem Netzwerk dauerhaft überwacht werden kann und Fehler frühzeitig erkannt werden können. In kleinen Netzen, die meist nicht administriert werden, ist eine Früherkennung von Engpässen und Fehlern schwierig. Sollte es einen zuständigen Administrator geben, hat dieser oft nicht die Expertise oder Zeit die für eine Installation der Wartung von notwendigen Tools. In mittelgroßen und großen Netzwerken ist es jedoch unverzichtbar, eine dauerhafte Überwachung von Basisdaten zu etablieren, um Probleme im Netzwerk zu erkennen und reagieren zu können. Wie aufwändig die automatisierte Überwachung stattfindet, sollte von den Anforderungen an das Netzwerk abhängen. Cacti ist hervorragend geeignet Trends in der Netzwerkauslastung zu erfassen, um so Probleme von Überlastung vorherzusagen und vorzubeugen. Im Einzelfall ist es durch einfache Konfiguration, wie zum Beispiel Etherchannels möglich die Bandbreite an neuralgischen Punkten zu erhöhen und so für eine Entspannung in der Auslastung zu sorgen. Obwohl Smokeping zentral installiert wird, ist es möglich, Messungen vorzunehmen, die Messwerte liefert, die eine von der Node empfundene Netzwerkqualität repräsentiert. Es ist einfach zu installieren und stellt ohne zusätzliche Modifikationen viele Störungen anschaulich dar, die sich eventuell langfristig als große Probleme 71

72 niederschlagen. Alle Nodes in einem Netzwerk, die auf einen Echo Request antworten, können daher mit Smokeping ohne Konfigurationsaufwand an den Nodes selbst zur Überwachung der Netzwerkqualität genutzt werden. Exemplarisch sollen in 2 Abbildungen bestimmte qualitätsrelevante Messungen und ihre Bedeutung illustriert werden. In Abbildung 20 wird dargestellt, dass durch gleichzeitige Messungen desselben Ziels eine Bewertung der verschiedenen Routen durch ein Netzwerk möglich ist. Die Latenz und PDV ist daher nicht von allen Nodes aus gemessen für jede Ziel Node gleich. Diese Informationen liefern wichtige Details zur Diagnose von Fehlern und Problemen in Teilsegmenten des Netzwerks und erlauben eine schnelle Fehlerdiagnose. Abbildung 20 - Smokeping - Node abhängige Messwerte Abbildung 21 - Smokeping - Packet Loss und PDV In Abbildung 21 zeigt sich die auffällige Störung einer Verbindung, in der plötzlich ein enormer Anstieg der Latenz sowie der PDV (Größe der grauen Fläche) zu 72

73 verzeichnen war und teilweise sogar Pakete verloren gegangen sind (Farbe der Linie im Graph, Rot bedeutet Verlust). Das Einrichten von Nagios, so dass es ein gesamtes Netzwerk und seine Vermittlungseinrichtungen überwacht, ist im Vergleich zu einer Konfiguration von Smokeping deutlich aufwändiger. Hat man jedoch kritische Werte wie Fehlerraten an Switch Ports per SNMP überwacht, wird man innerhalb von etwa 5 Minuten, nachdem ein Problem aufgetreten ist, automatisch informiert, sollte dies gewünscht sein. Diese Verzögerung ist abhängig vom Abfrageintervall und kann daher angepasst werden. Als praktisches Resultat bekommt man als Administrator idealerweise sofort eine SMS auf das Handy, wenn eine Verbindung zu einem Server unterbrochen ist oder sogar ein ganzer Switch ausgefallen ist. 9 Ethernet Funktionsweise und Konsequenzen für die Angreifbarkeit und Qualitätssicherung Wie in der Einleitung formuliert, ist es in einem Unmanaged Network aufgrund der Funktionsweise von Ethernet und durch das IP Protokoll implementierte Verfahren nicht möglich, Qualität für alle Nodes zu garantieren und sicherzustellen. Das paketbasierte Ethernet hat wie im Abschnitt Unmanaged Networks dargestellt von Haus aus keinen Mechanismus, der ein Stören oder gar einen Missbrauch verhindern kann und bietet auch keine Möglichkeiten in diese Systematik einzugreifen. Ob ein Paket wirklich von dem Absender kommt, der als Absender im Paket steht, ist nicht feststellbar. Auch ist es nicht möglich, auf Ethernet Ebene Pakete so zu verschicken, dass sie auf dem Weg durch Vermittlungseinrichtungen oder anderen Netzwerkelementen nicht manipuliert werden können. Die Transportschicht kann nur durch Standards und Protokollerweiterungen wie IPSEC oder SSL einzelne Verbindungen sichern da Prinzip bedingt für eine empfangende Node der Inhalt eines Pakets nicht nachprüfbar ist [25]. Insgesamt kann man daher jedes Paket in einem Ethernet ohne weitere Maßnahmen mit einer Postkarte vergleichen, auf deren Postweg jede beliebige Person Informationen hinzufügen oder durchstreichen kann. Es gibt zahllose Angriffs- oder Fehlerszenarien, jeweils mit unterschiedlichen Zielen oder Ursachen. Der Markt hat reagiert und bietet mit Mitteln wie Access Port Security Technologien oder Standards wie IEEE 802.1X [3] Möglichkeiten, mit denen sich der Zugang von Nodes zu einem Netzwerk schon am Switch Port regulieren lässt. Trotz dieser Technologien ist es durch verschiedenste, durch Protokollschwächen begünstige Angriffe möglich, das Netzwerk zu stören. So sind Angriffe, wie zum Beispiel ARP Spoofing, ICMP Redirect Angriffe, IP Spoofing oder Flodding ebenso 73

74 gefährlich für ein Ethernet, wie defekte Netzwerkkarten in Nodes oder ausfallende Vermittlungseinrichtungen, welche Pakete falsch weiterleiten [25]. All diese Effekte können je nach Netzwerkstruktur einen direkten Einfluss auf Qualität wie auch Sicherheit in einem Netzwerk haben. Exemplarisch kann man am ARP erkennen, wodurch das Problempotential begründet wird. Das ARP hat viele designbedingte Schwächen, insbesondere in Unmanaged Netzwerken. Schon einfachste Störeingriffe können daher ganze Netzwerksegmente so beeinflussen, dass kein gezielter Datenaustausch möglich ist. Zum Beispiel kann jede Node jedem ARP Broadcast antworten, aber selbst Antworten ohne vorherige Broadcast Anfrage haben oft praktische Relevanz und werden von bestimmten TCP/IP Stack Implementierungen beachtet. Damit ist es einfach einer Node falsche Informationen über Nodes zum Netzwerk zuzuspielen. Eine Node im Ethernet hat protokollbedingt keine Möglichkeit Aussagen zur Zugehörigkeit von IP und MAC zu bewerten. Gegenmaßnahmen in managed Netzworks bestehen darin, Ports an Switches nicht mehr zu erlauben, Ethernet Pakete mit beliebigen MAC Quelladressen zu verschicken oder auch auf Nodes die MAC Adressen für wichtige Nodes, wie zum Beispiel Router oder Server, fest einzutragen. Weiterhin bietet sich der Ausbau von Monitoring Software an. Ein Beispiel davon wird mit Snort im Abschnitt Eigenentwicklung eines Tools zur zentralen Netzwerküberwachung angesprochen. Verkompliziert werden Diagnose und Erkennung dadurch, dass im ARP nicht die MAC-Adressen aus dem Ethernet Layer Beachtung finden, sondern als Payload im ARP Protokoll noch einmal selbst gesetzt sind. Dabei beachten die wenigsten Implementierungen, wenn es dabei Konsistenzprobleme in den Daten von Ethernet Layer und ARP Layer gibt und verwenden die Daten aus dem ARP Layer bedingungslos. Dieses Beispiel soll exemplarisch aufzeigen, dass Netzwerkqualität wie in der Einleitung beschrieben nur in managed Networks durch administrative Maßnahmen erhöht und zugesichert werden kann. Grundsätzlich sollen die aufgezeigten Schwächen nicht suggerieren, dass es nicht möglich ist, ein qualitativ hochwertiges Netzwerk aufzubauen. Ethernet Standard in Kombination mit dem TCP/IP Protokoll Stack sind sehr gut skalierende und fehlerresistente Standards, in denen jedoch Sicherheitsüberlegungen keine Relevanz beim Design hatten. Ethernet erfüllt bzw. übertrifft daher sogar die an den Standard gesetzten Erwartungen zum Beispiel mit Standards wie 10GBase-T bei weitem [4], kann aber sicherheitsrelevante Änderungen nur schwer implementieren, da sonst die Kompatibilität mit bereits vorhandenen Netzen nicht mehr gegeben ist. Richtet man ein Ethernet ein, so wird dieses meist problemlos und robust funktionieren, wenn man sicherstellen kann, dass es keine Angriffsszenarien gibt. Um dies realisieren zu können, ist es von großer Bedeutung, auch bei der Planung des Ethernet diese Sicherheitskriterien mit in Betracht zu ziehen. Sind die Netze, wie zum Beispiel in Wohnheimen, sehr öffentlich, wird eine Planung für diesen Bereich umso wichtiger, um Probleme im Betriebsfluss zu vermeiden. 74

75 Das später vorgestellte, selbst entwickelte Tool hat die Aufgabe, diese Angriffe so weit wie möglich automatisch zu erkennen und effektiv abzuwehren. Damit soll eine Unterstützung geschaffen werden, die es ermöglicht, Qualität zusichern zu können und damit für die Nutzer eine gesteigerte Privatheit ihrer Daten zu schaffen. 10 Eigenentwicklung eines Tools zur zentralen Netzwerküberwachung 10.1 Motivation und Ziel Die Recherche und Analyse hinsichtlich verfügbarer Tools hat gezeigt, dass Netzwerk Monitoring heute durch Open Source Tools in gutem Maße möglich ist und daher für jedermann verfügbar. Diese Tools werden auch in der Industrie eingesetzt und im Einzelfall durch kommerzielle Lösungen aufgrund ihrer besseren Zugänglichkeit oder Skalierung erweitert. Es besteht daher kein besonderer Bedarf an neuen Netzwerk Tools zur Analyse und Überwachung von Netzwerkqualität. Auch Systeme die Agenten benutzen können sind durch z.b. Smokeping vorhanden. Die vorliegende Arbeit und die praktischen Versuche haben wie im Abschnitt Ethernet Funktionsweise und Konsequenzen für die Angreifbarkeit und Qualitätssicherung beschrieben gezeigt, dass Netzwerksicherheit essentiell für die Qualität in einem Netzwerk ist. Kann man nicht sicherstellen, dass störende Nodes, die entweder durch defekte Hardware oder Bewusst (durch den Anwender verursacht) das Netz belasten, erkannt werden können, ist es schwierig Maßnahmen zu ergreifen, um ein Netz dauerhaft und automatisiert stabil zu halten. Das gilt vor allem in Netzen, in denen eine hohe Fluktuation der Nodes existiert und der Netzwerkadministrator keine Möglichkeit hat, auf alle Nodes einen direkten Einfluss auszuüben. Diesen Aspekt weisen heutzutage viele mittelgroße und große Netzwerke auf, der sich auch durch die immer stärkere Vernetzung von mobilen Geräten und der Zunahme von Laptops am Arbeitsplatz verstärkt. Besonders kritisch und relevant zur Qualitätssicherung sind die zentralen Punkte des Netzwerks, die einen Übergang in andere IP Netze oder auch das Internet gewährleisten. Diese Punkte sind heute oft der Flaschenhals von empfundener Netzwerkqualität und führen bei einem Ausfall oder Überlastung zu einem von dem User so empfundenen Ausfall des Netzwerks. Zur Überwachung eines Netzwerks existiert das frei verfügbare Snort Tool, welches Echtzeit Monitoring mit dem Fokus Intrusion Detektion und Intrusion Prevention gewährleistet und sich selbst als Marktführer und Industriestandard in dem Bereich sieht. Snort muss daher auf einer zentralen Vermittlungseinrichtung installiert werden, vorzugsweise auf dem Default Route Router für das Netzwerk. Snort findet vor allem als IDS und IPS Einsatz und soll dabei Dienste in Firmennetzwerken vor Angriffen schützen. Weiterhin sind freie und kommerzielle Lösungen (z.b. FreeRadius oder AEGIS SecureConnect) verfügbar, welche über PNAC und IEEE 802.1X [3] ein Netzwerk vor Nodes, die nicht im Netzwerk angemeldet sind, schützen. So ist vorgesehen, 75

76 dass in dem Fall, dass eine Node noch nicht per IEEE 802.1X authentifiziert ist, diese nur in einem durch VLAN isolierten Gastnetzwerk kommunizieren kann, in dem es nur eingeschränkte Dienste gibt. Sie ist damit vom Arbeitsnetzwerk in dem sich angemeldete Nodes befinden isoliert. Ist eine Node bzw. der Nutzer der Node im Netzwerk angemeldet, wird das Access VLAN am Switch Port, über den die Node an das Netzwerk angebunden ist, geändert, wobei eine weitere Überwachung durch 802.1x dann nicht vorgesehen ist. Insbesondere in einem mittelgroßen Netzwerk, in dem man den administrativen Aufwand gering und den Zugang zum Netzwerk flexibel halten will, ist diese Lösung ungeeignet und hat sich nicht durchgesetzt. Auch kann IEEE 802.1X keine Auffälligkeiten oder Anomalien, die von einer angemeldeten Node ausgehen, automatisiert feststellen und Gegenmaßnahmen einleiten, wenn diese Maßnahme nicht durch andere Tools, wie zum Beispiel das oben beschriebene Snort ( ergänzt wird. Im speziellen Fall eines Wohnheimnetzwerks sind die beschriebenen Tools ungeeignet, um eine Netzwerkqualität für alle Teilnehmer gewährleisten zu können, die im Rahmen der Netzwerkordnung festgelegt ist. Zusätzlich Restriktionen, wie Accounting von Traffic, Erkennen von Netzwerkanomalien und einfache Administration sind im Vergleich dazu in Firmennetzwerken unüblich und können zudem durch vorhandene Tools nur schwer abgebildet werden. Um beispielsweise in Snort für alle oft wechselnden Nodes eine sichere Arp Spoofing Erkennung abbilden, ergibt sich enormer Administrations- und Konfigurationsbedarf. Weiterhin ist Snort nicht so konzipiert, dass bei auftretenden Problemen Nodes direkt am Switch aus dem Netz genommen werden. Diese Maßnahme ist jedoch vor allem in Netzen, in denen beliebige Nodes eingebracht werden können, äußerst relevant um eine hohe Netzwerkqualität und Sicherheit für alle Nodes zu gewährleisten. Um diese Probleme zu lösen, wurde ein flexibles und sehr modulares Tool entwickelt, welches andere später in dieser Arbeit vorgestellte Paradigmen vertritt, um Sicherheit und Qualität in einem mittelgroßen bzw. großen Netzwerk zu erhöhen, in dem verschiedenste Nodes teilnehmen. Im konkreten Beispiel wurde eine Anwendung entwickelt, die in Wohnheimen Accounting, Nutzerverwaltung sowie Reporting übernehmen kann. Getestet wurde die Software im WH8, Güntzstraße Dresden (Netzwerk Struktur siehe Abbildung 22). 76

77 Abbildung 22 - WH8 Netzwerkelemente [32] Die Software wird auf einem Router installiert und kann so das konfigurierte Regelwerk, welches eine gute Netzwerkqualität für alle Nutzer garantieren soll, überwachen. In den Paradigmen des Tools steht der Nutzer im Vordergrund, daher wird jedem Paket schon vor weiterer Auswertung ein Nutzer zugeordnet. Dies wird gewährleistet durch MAC und IP Lookups. Ziel ist es, beteiligte Nutzer in einem Paket zu bestimmen sowie das Lernen von dynamischen neuen Informationen, soweit es für einen Nutzer zulässig ist. Ein Nutzer kann beliebig viele Nodes in dem Netzwerk betreiben, Regeln können jeweils in einer Gruppe oder für alle Nodes eines Nutzers überwacht werden. Folgende Schwerpunkte wurden bei der Anwendungsentwicklung gesetzt: - Nutzerverwaltung inklusive DHCP Management - Flexibles Accounting zur Abbildung beliebiger Traffic Limitierungen für Teilnehmer oder Teilnehmergruppen - Automatische Switch Administration; störende Nodes sollen ganz aus dem Netzwerk genommen werden können - Datenexport in eine MySql Datenbank zur Integration in eine Website - Layer2 Security auf Paketebene - Erfassen einer Nutzerhistorie - Modulares Design zur Anpassung an andere Netzwerke und Gegebenheiten sowie die Möglichkeit für beliebige Erweiterungen - Einfache Einrichtung: Das Tool soll mit möglichst wenig Konfiguration starten können und alle nötigen Informationen eigenständig aus dem Netzwerk 77