© imagebavarias, 123RF.com

Dank Mininet konstruiert Philip Wette seine SDN-Topologien zunächst im Sandkasten, bevor er sie auf eine ziemlich erwachsene Rechnerfarm loslässt. Namespaces im Kernel machen es möglich.

Mit einem einfachen Software-Update für den Open-Flow-Controller ändert ein Netzwerk-Admin oft das komplette Verhalten eines Open-Flow-organisierten Netzwerks [1]. Das Update kann er selbst schreiben, schließlich stehen die meisten Controller unter Open-Source-Lizenzen. Doch wie findet er heraus, ob seine Controller-Erweiterung auch mit der Topologie des Produktivnetzwerks harmoniert? Dumm wäre es, wenn er sie aktiviert und plötzlich das Routing oder die Firewall Amok laufen. Will er das Update zunächst ausgiebig in einer kontrollierten Umgebung testen, stößt er schnell auf Mininet [2].

Sandkasten für Netzwerker

Mininet braucht nur ein einziges Linux-System, um ein Netzwerk zu emulieren, das bei Bedarf Hunderte von virtuellen Switches und Hosts entfaltet. Es bildet also ein komplettes Netzwerk mitsamt angeschlossenen Computern auf einem Rechner ab, wobei die Hardware des Hosts über die maximale Anzahl an Switches und virtuellen Hosts bestimmt. Über einen Open-Flow-Controller kontrolliert und steuert der Admin dieses Testnetz dann nach Gutdünken. Doch das ist nicht alles: Die emulierten Hosts führen jedes unmodifizierte Linux-Programm aus. So prüft der Betreiber ohne Aufwand, ob und wie sich das veränderte Netzwerk auf einzelne Programme auswirkt, die in ihm laufen.

Mininet testet aber nicht nur neue Routing- und Forwarding-Regeln auf Herz und Nieren. Will ein Admin die Topologie eines realen Netzwerks verändern, kann er die Folgen bereits im Vorfeld über Mininet emulieren oder er verwendet es, um neue Netze noch in der Planungsphase zu evaluieren.

Griff in die Trickkiste

Damit Mininet die große Zahl an virtuellen Switches und Hosts auf einem physikalischen Rechner nachbildet, nutzt es einige ausgefeilte Technologien, die der Linux-Kernel bereits seit einiger Zeit anbietet. Beispielsweise verzichtet Mininet auf eine vollständige Virtualisierung und emuliert virtuelle Switches und Hosts als einfache Prozesse auf einem gemeinsamen Hostsystem.

Weil sich diese Prozesse aber wie individuelle, miteinander vernetzte Geräte verhalten sollen, muss der Kernel sie voneinander trennen. Hierbei machen sich die mit Version 2.2.24 eingeführten Network Namespaces [3] nützlich. Sie ermöglichen es, Prozesse mit individuellen Netzwerkschnittstellen sowie eigenen Routing- und Arp-Tabellen auszustatten. Jeder Prozess verfügt über einen eigenen Netzwerkkontext, die Kommunikation wickeln zwei Prozesse über die ihnen zugeordneten virtuellen Netzwerkschnittstellen ab.

Prozesse reden allerdings nur direkt miteinander, wenn zwischen ihren Netzwerkschnittstellen eine Art virtuelles Kabel existiert. Das setzt Mininet mit den so genannten Veth Pairs um, die den Paketaustausch zwischen zwei Schnittstellen erlauben.

Abbildung 1 illustriert, wie es der Kernel über die Network Namespaces ermöglicht, einen Rechner mit einem Netzwerk auszustatten, das über zahlreiche Schnittstellen verfügt. In dem dargestellten Beispiel hängen die zwei virtuellen Hosts H1 und H2 an einem gemeinsamen Switch S1. Bash-Prozesse emulieren jeweils H1 und H2, der Switch S1 läuft im Root Namespace, in dem auch der Linux-Kernel operiert. H1 und H2 bringen jeweils eigene Network Namespaces und eigene Netzwerkschnittstellen mit, »h1-eth0« beziehungsweise »h2-eth0« .

Abbildung 1: Mininet nutzt die Network Namespaces im Kernel, um auf einem Host voneinander separierte virtuelle Hosts und Switches anzulegen.

Der Switch S1 verfügt nur über zwei Ports, »s1-eth0« und »s1-eth1« , die ihn über Veth Pair mit den entsprechenden Schnittstellen der Hosts verbinden. Die Kommunikation zwischen H1 und H2 erfolgt somit ausschließlich über S1.

Ein Softwareswitch spielt den Paketvermittler zwischen den Schnittstellen »s1-eth0« und »s1-eth1« . Er läuft im Root Namespace, verwendet die physikalische Schnittstelle »eth0« und wartet auf Befehle des Open-Flow-Controllers, die ihn über das Open-Flow-Protokoll erreichen. Der Controller läuft meist außerhalb des Mininet-Hosts, oft auch auf anderen Maschinen im Netzwerk.

Mininet bringt jedoch auch selbst Controller mit, die sich über das Installationsskript einspielen lassen: Nox [4], den Open-Vswitch-Controller [5] sowie den Referenz-Controller von Open Flow 1.0 [6]. Die drei laufen auf derselben physikalischen Maschine wie Mininet, reden über das lokale Loopback Device mit dem Switch und lassen sich über das Mininet-CLI starten.

Um den emulierten Kabeln bestimmte Eigenschaften zuzuweisen, instruiert Mininet das im Linux-Kernel verankerte Traffic-Shaping-Werkzeug »tc« (Traffic Control, [7]). Das Tool reguliert neben der maximalen Datenrate eines jeden emulierten Links zusätzlich dessen Paketfehlerrate und Latenz. Daneben legt der Admin über »tc« das Buffering-Verhalten der Netzwerkschnittstellen fest. Dies bestimmt darüber, wie die Schnittstellen in einer Überlastsituation mit Paketen umgehen. Hier kommen neben einem einfachen First-in-first-out-Verfahren (Fifo) auch komplexere Techniken wie Random Early Detection (RED) zum Einsatz.

Open-Flow-Versionen

Generell kommt Mininet mit verschiedenen Softwareswitches zurecht, die wiederum zu unterschiedlichen Versionen von Open Flow kompatibel sind. Die aktuelle Mininet-Version 2.1 liefert in der Standardinstallation native Unterstützung für den Referenzswitch von Open Flow 1.0 [6], den Indigo Virtual Switch [8] sowie für Open Vswitch [9]. Die Referenzimplementierung ist ein reines Userspace-Programm, während die beiden anderen als Kernelmodule laufen und daher eine wesentlich höhere Performance bei geringerem Forwarding Delay erzielen (Tabelle 1).

Alle drei Switches implementieren Open Flow 1.0. Wer mit der neuen Version Open Flow 1.3.x[10] experimentieren möchte, kann den Referenzswitch gegen die Variante von Open Flow 1.3 (»ofsoftswitch13« ) austauschen. Dies klappt am einfachsten, wenn der Admin Mininet mit

# mininet/util/install.sh -n3fx

installiert. Dank der Option liefert der Netzwerkemulator eine zu Open Flow 1.3 kompatible Version von Nox aus.

Interaktion mit Mininet

Mininet bietet ein umfangreiches Python-API [11] an, über das der Admin das gesamte Verhalten jeder einzelnen Komponente steuert. Er kann darüber die Topologie des Netzes bestimmen, beliebige Prozesse auf Hosts starten, dynamisch die Parameter einer Netzwerkschnittstelle verändern und Ports von Switches während der Emulation ab- und wieder einschalten. Um das Verhalten eines Netzwerks in einem dynamischen Umfeld zu beobachten, ermöglicht es Mininet sogar, während einer laufenden Emulation zusätzliche Switches, Hosts und Netzwerkschnittstellen zu ergänzen.

Eine Besonderheit von Mininet ist der erwähnte interaktive Kommandozeilenmodus (CLI-Modus). In ihm setzt der Benutzer während einer laufenden Emulation Befehle auf Hosts ab. Zusätzlich erlaubt er es, Python-Code einzutippen und auszuführen, der etwa die Topologie des Netzes interaktiv verändert.

Um zu prüfen, ob der verwendete Open-Flow-Controller mit dynamisch auftauchenden Rechnern zurecht kommt, soll das folgende Beispiel ein bestehendes Netz um einen Host »H3« erweitern:

# py net.addHost("H3")
<Host H3: pid=1165>

Im nächsten Schritt verkabelt der Betreiber den Host mit S1

# py net.addLink(net.get("S1"), net.get("H3"))<mininet.link.Link object at 0x13e1c90>

und aktiviert die neue Schnittstelle von S1. Dafür muss er zunächst den Namen der neuen Schnittstelle herausfinden. Dies geschieht mit:

# py net.get("S1").intfList()
[<Intf lo>, <Intf s1-eth1>, <Intf s1-eth2>, <Intf s1-eth3>]

Mit dem Wissen, dass der Name »s1-eth3« lautet, darf der Mininet-Betreiber die Schnittstelle nun aktivieren:

# py net.get("S1").attach("s1-eth3")

Abschließend muss der Admin noch die IP-Adresse von H3 konfigurieren:

# py net.get('H3').cmd("ifconfig h3-eth0  10.0.0.3")

Ein Ping-Test prüft zum Schluss, ob der Host H1 den neuen Host H3 erreicht. Wie Abbildung 2 zeigt, ist der Test erfolgreich. Eine ausführliche Demonstration der Mininet-Fähigkeiten zeigt der Open-Flow-Artikel in diesem Schwerpunkt.

Abbildung 2: Dank des Python-API lässt sich Mininet mit einer Handvoll Befehle um neue Hosts erweitern, die der Admin auch gleich konfiguriert.

Fazit

Mininet eignet sich hervorragend, um automatische Netzwerkexperimente unter realitätsnahen Bedingungen umzusetzen. Der CLI-Modus macht es zu einem handlichen Werkzeug für Rapid-Prototyping-Entwicklungen von Controller-Erweiterungen, zudem gibt es mit Mini Edit (Abbildung 3) auch ein GUI zum Anlegen von Netzwerken [12].

Abbildung 3: Wer will, kann sein Testnetz auch mit Hilfe einer grafischen Oberfläche entwerfen, die Software heißt Mini Edit.

Weil Mininet aber auf nur einem Rechner läuft, ist seine Leistungsfähigkeit begrenzt. Auf einem i7-Prozessor mit 3,2 GHz Taktrate schafft Mininet zum Beispiel einen Gesamtdatendurchsatz von höchstens 2,3 GBit pro Sekunde. Wer ein Netz mit höherem Datenaufkommen emulieren möchte, kann auf mein Projekt Maxinet [13] zurückgreifen, das Mininet auf mehrere physikalische Rechner verteilt.

Der Autor

Philip Wette ist Doktorand an der Universität Paderborn. Im Rahmen des Sonderforschungsbereiches 901 untersucht er die Rekonfiguration von Netzwerktopologien durch Overlay-Netze.