Der schlechteste Ort, um eine Änderung an einem Netz auszuprobieren, ist das Netz selbst. Eine falsche Regel kann ein ganzes Gebäude vom Internet abschneiden. Ein eigenes Testnetz aus echten Switches, Kabeln und Servern aufzubauen, ist dagegen teuer und langsam.
Mininet gibt darauf eine überraschend einfache Antwort: das Netz in einem einzigen Rechner aufbauen. Und zwar nicht als Spielzeugsimulation, sondern mit Switch-Software, die auch in echten Netzen läuft, mit einem echten Controller und mit jedem Programm, das der Rechner ausführen kann.
Ein virtueller Server ist eigentlich ein Prozess
Jeder „Server“ in Mininet ist ein gewöhnlicher Prozess des Betriebssystems. Dass er sich wie ein eigener Rechner verhält, verdankt er einer Linux-Funktion namens Netzwerk-Namensraum.
Netzwerk-Namensraum Ein Prozess mit eigenem Netz
Ein Prozess in einem Netzwerk-Namensraum sieht nur die Netzwerkschnittstellen, die ihm zugewiesen wurden, seine eigene Adresstabelle und seine eigenen Routing-Regeln. Von den Netzeinstellungen draußen weiß er nichts. Zwei Prozesse können auf demselben Rechner laufen und aus Sicht des Netzes trotzdem wie zwei getrennte Maschinen wirken.
Das lässt sich leicht beobachten. Listet man die Schnittstellen eines virtuellen Servers auf, erscheinen nur zwei: seine virtuelle Netzwerkkarte und seine eigene Loopback-Schnittstelle. Das Hauptsystem sieht diese virtuelle Karte nicht. Der Switch dagegen läuft standardmäßig im Haupt-Namensraum; in seinem Fenster erscheinen alle Schnittstellen des Rechners, einschließlich der Verbindung nach außen.
Getrennt ist aber nur das Netz. Listet man die Prozesse eines virtuellen Servers auf, erhält man genau dieselbe Liste wie im Fenster des Switches. Auch die Dateien sind gemeinsam. Das ist kein Mangel, sondern der Reiz der Sache: Jedes Programm, das auf dem Rechner läuft, läuft auch auf einem virtuellen Server. Auf dem einen einen kleinen Webserver zu starten und die Seite vom anderen herunterzuladen, ist dasselbe wie zwischen zwei echten Maschinen.
Ein Netz mit einem Befehl
Das kleinste Netz startet ganz ohne Optionen: ein Switch, zwei Server und ein Controller. Also vier getrennte Prozesse auf dem Rechner.
Für Größeres gibt es fertige Muster. single hängt beliebig viele Server an einen Switch, sternförmig. linear reiht Switches wie eine Kette aneinander und schließt an jeden einen Server an. tree baut einen Baum aus Wurzel, Ästen und Blättern. Reicht keines davon, beschreibt man Switches, Server und Verbindungen einzeln in einer Python-Datei und zeichnet seinen eigenen Aufbau.
Am schnellsten prüft man mit pingall, ob das Netz wirklich funktioniert: Jeder Server pingt jeden anderen an, und das Ergebnis passt in eine Zeile.
Das Gespräch auf der Leitung belauschen
Weil der Verkehr im virtuellen Netz echter Verkehr ist, kann Wireshark ihn mitschneiden. Bei aktivem OpenFlow-Filter genügt ein erster Ping von einem Server zum anderen, und das Gespräch zwischen Switch und Controller erscheint auf dem Bildschirm.
Zuerst schickt der sendende Server eine ARP-Anfrage an alle, um die Hardwareadresse des anderen zu erfahren. Der Switch weiß nicht, was er mit diesem Paket tun soll, und fragt den Controller. Der Controller weist ihn an, das Paket über alle Ports zu verteilen. Kommt die Antwort zurück, läuft auch sie über den Controller, der diesmal eine Regel in den Switch schreibt. Dann nimmt der eigentliche Ping denselben Weg.
Wiederholt man denselben Ping, sinkt die Zeit unter hundert Mikrosekunden. Die Regeln stehen jetzt in der Tabelle des Switches; es entsteht kein Steuerverkehr mehr, und die Pakete laufen direkt durch.
Der erste Ping ist eine Frage, der zweite eine Gewohnheit. Der Unterschied ist eine einzige Zeile in der Tabelle des Switches.
Die Verzögerung von Hand einstellen
Virtuelle Kabel sind nicht unendlich schnell; man kann sie beliebig einstellen. Jede Verbindung kann eine Bandbreite und eine Verzögerung bekommen. Das erledigt das Linux-Werkzeug zur Verkehrssteuerung: Es hält Pakete die angegebene Zeit zurück und lässt sie die angegebene Rate nicht überschreiten.
Bekommt jede Verbindung 10 Millisekunden Verzögerung, sollte ein Ping zwischen zwei Servern etwa 40 Millisekunden dauern. Die Rechnung ist einfach: Die Anfrage überquert zwei Verbindungen, vom Server zum Switch und vom Switch zum anderen Server, und die Antwort dieselben zwei auf dem Rückweg. Vier Überquerungen, je 10 Millisekunden.
Dieselbe Logik gilt für gemischte Aufbauten. In einem Aufbau des Labors ist nur eine Verbindung auf 10 Megabit und 50 Millisekunden eingestellt, und einer der Server ist auf zwanzig Prozent des Prozessors begrenzt. Ein Ping über diese Verbindung sollte um die 100 Millisekunden dauern: Die Anfrage überquert die langsame Verbindung einmal auf dem Hinweg, die Antwort einmal auf dem Rückweg. Die Prozessorgrenze bremst dagegen rechenintensive Programme, nicht etwas so Leichtes wie einen Ping.
Einen Ausfall erzeugen, ohne ein Kabel zu ziehen
Um in einem echten Netz ein gerissenes Kabel zu testen, muss man das Kabel ziehen. In Mininet genügt ein einziger Befehl: Die Verbindung zwischen einem Switch und einem Server wird abgeschaltet, und beide Enden des virtuellen Kabels fallen zugleich aus.
In diesem Moment schickt der Switch dem Controller eine Nachricht, dass sich der Zustand eines seiner Ports geändert hat. Wird die Verbindung wieder hochgefahren, kommt dieselbe Meldung erneut. Wie ein Netz auf einen Ausfall reagiert, lässt sich so untersuchen, ohne Hardware anzufassen, und beliebig oft wiederholen.
Lesbare Adressen Ein kleines Detail mit großer Wirkung
Bei jedem Start vergibt Mininet zufällige Hardwareadressen wie f6:9d:5a:7f:41:42 an die virtuellen Netzwerkkarten. Da sie sich bei jedem Neuaufbau ändern, ist im mitgeschnittenen Verkehr schwer zu verfolgen, welches Paket von welchem Server stammt. Eine einzige Option verwandelt sie in fortlaufende, zur IP-Adresse passende Werte wie 00:00:00:00:00:01: Der Server mit 10.0.0.1 bekommt eine Hardwareadresse, die auf 01 endet.
Was kann ein Laptop nicht zeigen?
Die Stärke von Mininet liegt darin, wie getreu es die Logik eines Netzes nachbildet. Dieselbe Switch-Software, dieselben OpenFlow-Nachrichten, dieselben Programme. Ein in Mininet entwickelter Controller lässt sich unverändert an echte OpenFlow-Switches anschließen.
Was es nicht zeigen kann, ist die Hardware selbst. Alle virtuellen Server und Switches teilen sich denselben Prozessor; wächst das Netz oder wird der Verkehr schwer, wird der Rechner zum Engpass. Verzögerungen stammen aus den gewählten Einstellungen, nicht aus der Physik eines Kabels. Die Zahlen hier beschreiben, wie sich ein Netz verhält, nicht, wie schnell es ist.
Worauf beruht dieser Beitrag?
Der Beitrag stützt sich auf die erste Laborübung aus dem Kurs zu softwaredefinierten Netzen, den Zhipeng Wang im Masterstudiengang Computer and Network Systems an der Université d'Évry Paris-Saclay besucht. Die Ping-Zeit und die Adressbeispiele stammen aus dem Laborblatt; die Werte von 40 und 100 Millisekunden sind aus den dort angegebenen Verbindungseinstellungen berechnet.
- Lantz, Heller, McKeown, A Network in a Laptop: Rapid Prototyping for Software-Defined Networks, HotNets, 2010.
- McKeown u. a., OpenFlow: Enabling Innovation in Campus Networks, ACM SIGCOMM Computer Communication Review, 2008.
- Pfaff u. a., The Design and Implementation of Open vSwitch, NSDI, 2015.
- Hemminger, Network Emulation with NetEm, linux.conf.au, 2005.
- Linux man-pages, network_namespaces(7).
Zhipeng Wang
Studiert Computernetzwerksysteme in Paris-Saclay, Schwerpunkt Systeme und Netzwerke. Spricht Chinesisch, Französisch und Englisch.
Alle Beiträge ansehen
