Open Source im professionellen Einsatz
Linux-Magazin 04/2014
© imagebavarias, 123RF.com

© imagebavarias, 123RF.com

Testbett für SDN

Sandkastenspiele

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.

713

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.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 3 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Mininet 2.2.0 mit Cluster-Support

    Mit Mininet lassen sich realistische virtuelle Netzwerke in einer virtuellen Maschine oder Cloud-Umgebung aufsetzen. Nun ist Version 2.2.0 erschienen.

  • Open Flow

    Dümmere Netzwerkhardware schafft klügere Netze? Bei Open Flow jedenfalls geht diese Rechnung auf und erspart dem Admin einige Arbeit, indem er den Datenfluss zentral von einem Punkt aus steuert.

  • Zodiac FX

    Weil White-Label-Switches mit Picos für das Heimlabor fast unerschwinglich sind, trat Northbound Networks mit einer Kickstarter-Kampagne an, um diese Lücke zu schließen – heraus kam der Zodiac FX.

  • Open Daylight

    An den Grundlagen kommender SDN-Produkte arbeiten namhafte Unternehmen gemeinsam im Open-Source-Projekt Open Daylight. Im Februar 2014 erblickte dessen erste Code Release das Tageslicht.

  • Onos

    Onos ist als Projekt zwar jünger als Open Daylight, mausert sich aber zu einer ernst zu nehmenden Konkurrenz im SDN-Bereich. Das Linux-Magazin inspiziert das Reich des Netzwerk-Betriebssystems.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.