1. Netzwerkanalyse
Im ersten Termin des Praktikums werden erste Erfahrungen mit einem Kommunikationsnetz gesammelt. Es soll eine Netzwerkanalyse im Internet mit dem Programm iperf durchgeführt werden. Um auf das Netzwerk zuzugreifen, verwendet iperf den Datagram- oder den Stream-Dienst des Internets.
Sowohl bei Datagrammen als auch bei Streams werden Daten (engl. Payload) in Paketen zusammengefasst und mit einem Paket-Kopf (engl. Header) und einem Paket-Ende (engl. Trailer) versehen. Im Header sind Informationen z.B. über den Empfänger und der Größe des Pakets enthalten. Im Trailer sind meistens Informationen enthalten, mit denen erkannt wird, ob Fehler im Paket enthalten sind.
Der Unterschied zwischen Datagram- und Stream-Dienst besteht darin, dass beim Stream-Dienst dafür gesorgt wird, dass die Daten korrekt und in der richtigen Reihenfolge beim Empfänger eintreffen. Beim Datagramm-Dienst ist dies nicht der Fall. Datagramme können schon mal verloren gehen oder in der falschen Reihenfolge empfangen werden. Intern wird im Internet beim Stream-Dienst TCP und beim Daragramm-Dienst UDP verwendet. TCP steht für "Transmission Control Protocol" und UDP bedeutet "User Datagram Protocol". Vielleicht habt ihr diese Worte schon einmal gehört. Nach diesem kurzen Umweg, kommen wir nun zur Bescheibung der Aufgabe zurück:
Ein iperf-Client sendet Pakete mit einer eingestellten Rate zu einem iperf-Server, der die Pakete empfängt und die Anzahl der verloren gegangenen Pakete, sowie den Datendurchsatz des Paketstroms in Bit/s misst. Die genaue Verwendung des Programms iperf ist dem Aufruf „iperf -h
Ziel dieses Termins ist es, ein Gefühl über das Verhalten von Netzwerken zu bekommen. Zu diesem Zweck werden Daten mit unterschiedlichen Senderaten übertragen in einem Netzwerk übertragen. Im Netzwerk treten leider Fehler auf. Die Auswirkungen der Fehler werden näher beobachtet.
An einem einfachen Beispiel soll gezeigt werden, wie man mit iperf eine Leistungsmessung durchführen kann.
Ein DSL (Digital Subscriber Line) Router ist in vielen Heim-Netzwerken die zentrale Komponente, der den Zugang zum Internet bereit stellt. Der DSL Router ist meistens mit einem WLAN (Wireless Local Area Network) und einem Ethernet-Switch ausgestattet.
Wenn Areale nicht mit dem WLAN abgedeckt werden können, ist die Powerline-Technologie eine kostengünstige Alternative. Mit einem Powerline-Anschluss, wird eine Datenübertragung über das Starkstromnetzwerk durchgeführt. Hierdurch werden Kosten durch eine teuere zusätzliche Verkabelung gespart. Die Powerline-Adapter werden in die Steckdose gesteckt und besitzen einen Ethernet-Anschluss. Ein Adapter wird an den Ethernet-Switch des DSL Router angeschlossen und mit dem Stromnetz verbunden. Über das Stromnetz kommuniziert ein weiterer Powerline-Adapter an den ein beliebiger Rechner angeschlossen werden kann. Der Rechner wird mit dem Ethernet-Anschluss des Powerline-Adapters verbunden.
Es soll nun der Durchsatz zwischen einem Laptop, der am WLAN angeschossen ist, und einem Laptop ermittelt werden, der über Powerline angeschlossen ist. Das Heim-Netzwerk ist in Abb. 1.1 dargestellt.
Abbildung 1.1 : Typisches Heimnetzwerk mit DSL Router
Auf dem Laptop, der am WLAN angeschlossen ist, wird der iperf Client gestartet. Er sendet UDP Pakete, die über das WLAN übertragen werden, dann über den Switch des DSL Router geleitet werden und schließlich über die Powerline-Adapter zum iperf Server gelangen. Der iperf Server empfängt die Pakete und ermittelt die Anzahl der Paketverluste und den Durchsatz.
Abbildung 1.2 : Durchsatzmessung im Heim Netzwerk
Das Ergebnis der Messung ist in Abb. 1.2 dargestellt. Der iperf Client hat die Senderate von 0 bis 210MBit/s variiert. Dies ist an der "blauen" Kurve zu erkennen. Ab etwa 180 MBit/s flacht die Kurve ab. Ich Ursache hierfür ist darin zu suchen, das die obere Grenze der Kapazität des WLAN erreicht ist. Bei einer Senderate von mehr als ca. 180 MBit/s können nicht alle Pakete gesendet werden. Der iperf Client erkennt dies und reduziert automatisch die Senderate.
Die gesendeten Pakete erreichen den DSL Router und gelangen über den internen Ethernet-Switch zum Powerline-Adapter. Die Kapazität der Übertragungsstrecke zwischen den beiden Powerline-Adaptoren ist leider sehr viel kleiner als die Kapazität des WLAN. Die Folge davon ist, dass sehr viele Pakete verloren gehen, weil der Powerline-Adapter es nicht schafft die Flut von Paketen weiterzuleiten, die er vom DSL Router erhält. Dies ist anschaulich in der "grünen" Kurve dargestellt: Die Paketverlustrate steigt bei einer sehr geringen Senderate des iperf Client enorm an. Als Folge gelangen nur wenige Pakete zum iperf Server. Die Anzahl der empfangene Pakete ist in der "violetten" Kurve dargestellt und entspricht dem Durchsatz (engl. Throughput) der Übertragungsstrecke, der etwa 30 MBit/s ist.
Obwohl die Hersteller des WLAN und der Powerline-Adaptoren, Bitraten von bis zu ca. 1GBit/s dem Kunden versprechen, sieht man, dass nicht einmal ein Bruchteil der Kapazität erreicht wird.
1.1 Einführungsaufgabe
Wenn die Netzwerkanalyse in einem realen Netzwerk durchgeführt wird, dann treten manchmal Schwierigkeiten auf. Zum Beispiel werden mindestens zwei Rechner benötigt. Einen für den iperf-Client und einen für den Iperf-Server.
Es ist auch nicht immer ist gewährleistet, dass Zugriff auf beide Rechner besteht: Es wäre zwar schön einen Rechner mit iperf in Moskau, Peking oder Washington zu haben, aber leider hat man dort meistens keinen Zugriff auf einen Rechner. Es gibt zwar ein Netzwerk von frei zugänglichen iperf Server, aber die Verfügbarkeit ist meistens sehr gering. Deshalb verwenden wir ein fiktives Netzwerk.
Im Abb. 1-3 skizzierten Szenario ermittelt nun den Durchsatz bei Verwendung eines Stream-Dienstes (TCP-Dienst) und eines Datagram-Dienstes (UDP-Dienst). Unter Verwendung des Datagram-Dienstes variiert bitte die Senderate von 1 MBit/s bis 1 GBit/s. Protokolliert auch die Paketverlustrate. Das Ergebnis weicht in einigen Punkten vom Ergebnis im oben angeführten Beispiel ab. Warum ist das so und warum ist der TCP Durchsatz so viel größer als der von UDP?
Ein kleiner Hinweis.
TCP: Beachtet den Unterschied der Puffergrößen von UDP und TCP.
Verbindet den ersten Rechner mit dem WLAN und startet dort den iperf Server. Den zweiten Rechner verbindet ihr mit dem Ethernet-Switch des DSL Router und startet dort den iperf Client. Nun könnt ihr die Messung durchführen. Das Programm iperf erhaltet ihr unter dieser Adresse iperf. iperf ist für alle gängigen Betriebssysteme erhältlich.
Freiwillige Zusatz-Aufgabe:
1.2 Simulation eines Netzwerkes
Wann immer ihr eine Verbindung mit einem entfernten Prozess/ Dienst über das Internet herstellt, besteht diese Verbindung in der Regel nicht aus einem direkten physikalischen Pfad, sondern aus vielen Teilabschnitten (siehe Abb. 1.4). Zwischen den Teilabschnitten, auch Verbindundungen (engl. Links) genannt, befinden sich Netzwerkknoten (engl. Router). An einigen Netzwerkknoten sind Endsysteme (z. B. Rechner) angeschlossen. Jeder dieser Links kann durch seine maximale Kapazität C und Verzögerungszeit 
modelliert werden. So wird daher bspw. die Übertragungsgeschwindigkeit oder der Durchsatz durch den Link mit der geringsten Kapazität C (Bottleneck) begrenzt.
Ein solches Verhalten könnt ihr nun simulieren. Zu diesem Zweck gibt es die Möglichkeit, Datenpakete zu „bremsen (d. h. die Bandreite zu senken)“, zu „verzögern“ oder zu „verwerfen“. Durch die Bremse simuliert ihr einen Bottleneck mit einer Bandbreite B. In jedem Netzwerkknoten wird ein Paket eine statistischen Zeit verzögert. Paketverluste entstehen hauptsächlich – aber nicht ausschließlich – durch überlaufende Puffer vor dem Bottleneck. Abb. 1.5 zeigt ein solches Netzwerkmodell: Die Verzögerer simulieren die Verzögerungszeit, die benötigt wird, um ein Paket über das Bottleneck zu übertragen. Zusätzlich simuliert er alle Verzögerungen, die ein Paket in jedem der Netzwerknoten erfährt. Beachtet, dass die Verzögerungszeit statistisch bestimmt wird und für jedes Paket unterschiedlich ist. Ist kein Verzögerer vorhanden, der ein Paket verarbeiten kann, so ist es verloren und kann dem Empfänger nicht zugestellt werden.
1.3 Simulation eines Netzwerkes mit TC
Um das Verhalten von Paketen in Netzwerken zu simulieren, verwenden wir die Netzfilter-Komponente des Linux-Betriebssystemkerns. Die Netzfilter-Komponente (kurz: Netfilter) ist dazu gedacht, Pakete, die über das Netzwerk gesendet oder empfangen werden sollen, bestimmten Regeln zu unterwerfen. Wie ihr sicherlich richtig vermutet, basieren die Firewalls des Linux-Betriebssystems auf Netfilter. Neben den üblichen Methoden von Firewalls, wie etwa dem Vernichten von Paketen, kann Netfilter noch etwas mehr: Mit Netfilter kommt das sogenannte Traffic Control (kurz: TC) zum Einsatz. Hierdurch kann der Datenstrom – in unserem Fall ein Strom von Paketen – mit einer Vielzahl für diesen Datenstrom charakteristischer Parameter modifiziert werden (beispielsweise die Parameter aus Abschnitt 1.2). Um die Netfilter-Einstellungen des Traffic Control im Betriebssystemkern zu kontrollieren (einrichten und löschen von Traffic Shaper), wird das Programm “tc” (Traffic Control) verwendet. tc modifiziert dabei die Einstellungen im Kernel und unterstützt die folgenden Verfahren:
- Shaping (Verzögerung von zu sendenden Daten): In manchen Fällen ist es sinnvoll, einen sehr gleichmäßigen Datenstrom zu senden. Der Datenstrom wird so modifiziert, dass zwischen den Daten Pausen mit konstanter zeitlicher Dauer eingefügt werden. Dies wird Leaky-Bucket (deutsch: tropfender Eimer) genannt. Eine andere Möglichkeit besteht darin, die Datenmenge zu begrenzen: Ist ein vorgegebenes Kontingent an Daten gesendet worden, dann muss zunächst eine Pause eingefügt werden bis weitere Daten gesendet werden. Ein solches Verfahren wird Token-Bucket genannt. Beide Verfahren dienen dazu, den Zugriff auf ein Netz zu beschränken, um Überlastsituationen zu vermeiden. Steigt die Datenmenge während der Pausen zu stark an und können diese nicht mehr vom Shaper gespeichert werden, so werden sie verworfen.
- Scheduling (zur Priorisierung von bestimmtem Daten): Wie im richtigen Leben gibt es einfache Kreditkarten und es gibt goldene Kreditkarten. Außer, dass die goldenen Kreditkarten im Preis teurer sind, haben sie für den Besitzer einige Vorteile. So ist es auch in den Netzwerken! Einige Daten werden in den Netzwerkknoten bevorzugt behandelt, also priorisiert. Die Gründe hierfür können vielschichtig sein: Einige Daten sind sehr anfällig gegen zu große Verzögerungszeiten. Dies sind insbesondere multimediale Daten, wie etwa Video-, Audio- oder Sprachdaten. Wer hat nicht schon einmal ein ruckelndes Video gesehen? Diese Daten können deshalb priorisiert werden. Eine andere Priorisierung erfolgt über den Preis, den ein Kunde bereit ist, für einen Kommunikationsdienst zu bezahlen. In diesem Fall erfolgt eine absichtliche Ungleichbehandlung von Datenströmen. Wenn jedoch das Augenmerk auf Fairness gerichtet ist, können Datenströme, die zu hohe Anforderungen haben absichtlich “gebremst” werden.
- Policing (zur Einhaltung einer definierten Bandbreite werden eingehende Pakete verworfen): Neben dem aktiven Formen eines zu senden Datenstroms wird auch das Policing (überwachen) von Datenströmen verwendet. Es soll ähnlich dem Shaping gewährleisten, dass Datenströme gewisse Parameter, wie etwa die Bandbreite, einhalten. Auch hier werden Leaky- und Token-Buckets verwendet.
Mit den oben genannten Mechanismen ist es für die Entwickler von Netfilter naheliegend gewesen, die Verfahren für die Simulation oder Emulationen von Netzwerken zu verwenden. tc bietet hierfür das Add-on “netem (Network Emulation)” an. Es erlaubt u. a. die Einstellung von Paketverzögerungen, Vertauschungs-, Duplizierungs- und Verlustraten von Paketen. Beispielsweise sorgt der Befehl
tc qdisc add dev lo root netem delay 10ms 5ms loss 5.1 reorder 10.0
dafür, dass im Looback-Interface ein Traffic Shaper installiert wird, der dafür sorgt, dass Daten im Mittel um 10 ms mit einer Varianz von 5 ms verzögert werden. Zusätzlich werden 5.1% der Daten vernichtet und 10% der Daten in ihrer Reihenfolge vertauscht. Um den Traffic Shaper von der Loopback-Schnittelle wieder zu entfernen, verwenden Sie den Befehl:
tc qdisc del dev lo root
Ergänzend zu dieser kleinen Beschreibung, die Ihnen das grundlegende Verhalten von tc näher bringen soll, bietet es sich dringend an, weitere Lektüre zu lesen. Sie finden diese über den „man tc“- Befehl des Linux-Betriebssystems oder auch im Internet. Neben der man-Page des LINUX-Betriebssystems ist das TC-How-to eine gute Möglichkeit tc kennenzulernen.
1.4 Aufgabe
Nachdem ihr nun alle wesentlichen Komponenten zur Lösung der Aufgabe kennengelernt habt, kann nun eine Leistungsuntersuchung an einem simulierten Netzwerk durchgeführt werden. Zu diesem Zweck führt die folgenden Schritte durch:
- Konfiguriert den Traffic Shaper der Loopback-Schnittstelle mit der IP-Adresse 127.0.0.1. Zur Konfiguration des Traffic Shapers erhält jede Gruppe individuelle Parameter für Verzögerungszeit, Verlustrate, Verdopplungen etc. Diese Parameter erhaltet ihr, wenn die ISIS-Aufgabe „Netzwerkanalyse“ gestarten wird.
- Startet den Iperf-Server und setzt ihn in den UDP-Modus. Vergesst nicht, einen Port anzugeben.
- Startet nun den Client im UDP Modus und übertragt 40MB an Daten mit einer Senderate von 1Mbit/s.
- Notiert alle Parameter und Ausgaben von iperf und tc (unter anderem den erzielten Durchsatz, die mittlere Verzögerungszeit, die Anzahl der Pakete mit vertauschter Reihenfolge (Out-of-Order), sowie die Verlustrate).
- Wiederholt das Experiment mit den folgenden Senderaten: 2Mbit/s, 5Mbit/s, 10Mbit/s, 20Mbit/s, 100Mbit/s, 200Mbit/s und 600Mbit/s.
- Stellt die Ergebnisse grafisch dar.
- Führt denselben Versuch im TCP-Modus durch. Beachtet, dass TCP die Senderate automatisch anpasst. Deshalb ist eine Einstellung nicht nötig.
- Vergesst anschließend nicht, den Traffic Shaper für die Loopback-Schnittstelle zu entfernen.
- Interpretiert die Ergebnisse.