© Jan Treger, 123RF.com

Software-Switches bringen Funktionen auf die Gastgeber von Virtualisierungen, wie sie sonst nur echte Hardware bieten kann. Das freie Open Vswitch ist Bestandteil des Mainstream-Kernels, bietet leistungsfähige Komponenten und arbeitet mit vielen Hypervisoren zusammen.

Dank immer leistungsfähigerer Hardware sprießen die virtualisierten IT-Umgebungen auf dem Server oder in der Cloud allerorten. Weil die einzelnen Instanzen auch miteinander kommunizieren, wollen Admins auch in den virtuellen Netzen Regeln setzen, so wie sie es im echten LAN gewohnt sind.

Ein typischer Mechanismus sind Bridges, die schon bei Virtualisierungssoftware auf dem Desktop zum Standardrepertoire gehören. Soll das virtuelle Windows etwa aufs WLAN des Linux-Gastgebers zugreifen, braucht es eine simulierte Netzwerk-Bridge, die der Admin per Mausklick und GUI-Dialog in schicken Menüs auf virtuellen Netzwerk-Devices im Handumdrehen bewerkstelligt.

Wie ein Hub im physischen Netzwerk sind die Software-Bridges aber mit Vorsicht zu genießen, zum Beispiel sieht der virtuelle Gast den kompletten Traffic im Netzwerksegment – ein auf einem Server meist unerwünschtes Feature.

Anders mit virtuellen Switches: Open Vswitch [1] erlaubt es dem Administrator, auf einem Host, der virtuelle Maschinen beherbergt, die verschiedenen virtuellen Netzwerkinterfaces durch einen oder mehrere simulierte Switches miteinander zu vernetzen. Dabei darf er einzelnen Anschlüssen VLANs zuordnen und Spiegelports anlegen. Es ist sogar möglich, mehrere Netzwerkinseln über Layer-3-Tunnel direkt miteinander zu vernetzen (Abbildung 1). Zudem unterstützt Open Vswitch auch Open Flow ([2], siehe Kasten “Open Flow”), kann Netflow-Daten [3] sammeln und an einen Netflow-Collector wie Ntop [4] senden.

Open Flow

Das Protokoll Open Flow gibt Zugriff auf die Forwarding Plane eines Switch oder Routers, also auf die Tabelle, die definiert, wie Pakete (von welchem Quell- zu welchem Ziel-Port) fließen sollen. Dabei ist die Verwaltung dieser Flow vom ausführenden Gerät entkoppelt. Die Idee dabei ist, dass sich so auch Access-Listen über alle Geräte zentral verwalten lassen, das Netzwerk lässt sich steuern.

Mittlerweile haben sich einige namhafte Hersteller bereits auf Open Flow festgelegt, laut der Homepage des Floodlight-Projekts ([2], Abbildung 2) gibt es bereits Geräte von HP, Huawei, Juniper, IBM Brocade und Netgear, die das Protokoll unterstützen.

Abbildung 2: Das Web-GUI für den Floodlight-Controller mit Open Vswitch.

Abbildung 1: Ein typisches Netzwerk, in dem Layer-3-Tunnel nötig sind.

Die Architektur

Open Vswitch besteht aus drei Diensten und einem Kernelmodul. Zwar ist Letzeres nur optional, doch ohne sind die Performance-Einbußen so groß, dass wenig Freude aufkommt. Mit ihm allerdings überrascht der virtuelle Switch: Laut Aussage des Projekts ist das Weiterleiten der Pakete schneller als bei einem Bridgemodul.

Beim Einsatz des Kernelmoduls muss der Admin einige Details beachten: Das Layer-3-Tunneln geht nur mit dem Kernelmodul aus dem Sourcecode des Projekts, nicht mit dem Modul aus dem normalen Kernel. Außerdem darf das Linux-Bridgemodul nicht geladen sein. Für Skripte, die sich auf die Bridge-Utils verlassen, gibt es ein separates Kompatibilitätsmodul, das Aufrufe zum Anlegen und Manipulieren von Bridges abfängt und für Open Vswitch passend übersetzt.

Open Vswitch speichert die Konfigurationen persistent in einer Json-Datenbank, üblicherweise im Verzeichnis »/etc/openswitch« . Als Server für diese Datenbank dient das Programm »ovsdb-server« . Alle Konfigurationsänderungen, die das Hauptwerkzeug »ovs-vsctl« durchführt, landen so direkt in der Datenbank; »ovsdb-client« hilft dabei, die Tabellen für Menschen besser lesbar als im Json-Rohformat zu machen.

Der Prozess »ovs-vswitchd« steuert die virtuellen Switches auf der lokalen Maschine und unterhält die Verbindung zur Konfigurationsdatenbank. Laufen die Switches im Userspace, übernimmt dieser Prozess auch ihre Verwaltung. Mit einem Open-Flow-Controller baut »derovs-vswitchd« die Verbindung auf und tauscht sich über das Open-Flow-Protokoll mit ihm aus.

Ist dagegen kein externer Open-Flow-Controller vorhanden, dann kommt der »ovs-controller« zum Einsatz. Controller müssen nicht auf derselben Maschine wie der »ovs-vswitchd« laufen. Um Redundanz zu schaffen, kann der Admin auch mehrere von ihnen angeben.

Ein einfaches Setup

Die Konfiguration erfolgt mit »ovs-vsctl« . Zunächst bedarf es einer leeren Konfigurationsdatenbank. Haben das nicht bereits die Init-Skripte erledigt, erzeugt

ovsdb-tool create /etc/openvswitch/conf.db /etc/openvswitch/vswitchd/vswitch.ovsschema

die Datenbank. Die folgenden Kommandos legen eine Switch-Instanz an, der der Admin auch gleich zwei Ports hinzufügt:

ovs-vsctl add-br linux-switch0
ovs-vsctl add-port linux-switch0 eth0
ovs-vsctl add-port linux-switch0 tap0
ovs-vsctl add-port linux-switch0 vboxnet0

Im Beispiel legt er einen Switch mit dem Namen »linux-switch0« an – der Name lässt sich frei wählen. Die zweite Zeile fügt das erste Ethernet-Interface des Host hinzu, das noch über keine IP-Adresse verfügen darf. Soll der Host über dieses Interface erreichbar sein, ist die Adresse dem automatisch angelegten Interface »linux-switch0« zuzuweisen. Die dritte und die vierte Zeile kümmern sich um ein TAP- sowie das Host-only-Interface etwa eines Virtualbox-Gastes.

In diesem Aufbau gleicht das physische Ethernet-Interface dem Uplink-Port eines klassischen Switch. Wer dem Vswitch-Interface eine IP-Adresse zuweist, kann ihn darüber von den angeschlossenen virtuellen Hosts erreichen. Will er Ports einem VLAN zuordnen, gibt der Administrator dem »add-port« -Kommando noch den Parameter »tag=VLAN-Id« mit. Die anderen Ports agieren dann als Trunk-Ports [5], liefern also auch die Pakete der VLANs aus, die der Admin aufgespannt hat.

In diesem Fall muss er allerdings auch den physischen Switch, an dem der Host hängt, so konfigurieren, dass er den Port als Trunk-Port akzeptiert und die Daten der verschiedenen VLANs richtig weiterleitet. Sollen alle Ports des virtuellen Switch zu einem VLAN im Rest des Netzwerks gehören, lässt sich alternativ auch auf dem Host ein VLAN-Interface hinzufügen. »vconfig add eth0 VLAN-Id« ) fügt dann »eth0.VLAN-Id« statt »eth0« als Port zum virtuellen Switch hinzu.

Im Zusammenspiel mit anderen Switches empfiehlt es sich, dass Spanning-Tree-Protokoll [6] zur Erkennung von Schleifen im Layer-2-Netz zu aktivieren. Dies konfiguriert der Administrator mit dem Kommando »ovs-vsctl set Bridge linux-switch0 stp_enable=true« . Die »set« -Anweisung manipuliert direkt die Datenbank. In SQL wäre diese Anweisung gleichbedeutend mit »update bridge set stp_enable=true where name=’linux-switch0’« .

Port Mirroring

Zur Fehleranalyse ist es manchmal notwendig, den Traffic auf einem Port mitzuschneiden oder an einen anderen Port weiterzuleiten, um ihn mit einer kommerziellen Probe auszuwerten. Wie physische Switches erlaubt es auch Open Vswitch, einen oder mehrere Ports auf einen anderen zu spiegeln, sodass sich Pakete abgreifen lassen.

Der erste Schritt in der dazu passenden Konfiguration ist das Hinzufügen des Ports zum Switch. Dies erledigt wie oben das »add-port« -Kommando. Nach Anlegen des Mirror kann der Port für nichts anderes mehr dienen, und das Ziel muss ein physisches Interface sein. Das Kommando zum Erzeugen des Mirror ist etwas länglich, da es die dynamisch vergebenen UIDs aus der Konfigurationsdatenbank ausliest, um mit diesen Werten den Spiegel anzulegen.

Das Beispiel aus Listing 1 spiegelt die Interfaces »tap0« und »tap1« auf das Interface »eth1« . Die seltsam anmutenden »–« dienen dem Kommando als Trenner für die Optionen, die Anweisung »select_all=1« gibt an, dass der Spiegel allen Verkehr zwischen den Tap-Schnittstellen übertragen soll.

01  ovs-vsctl -- set Bridge linux-switch0 mirrors=@m -- --id=@tap0 get Port tap0 -- --id=@tap1 get Port tap1 -- --id=@eth1 get Port eth1 -- --id=@m create Mirror name=tapmirror select_all=1 output-port=@eth1

Will er nur bestimmte Richtungen (beispielsweise von »tap0« zu »tap1« ) auswählen, dann kann der Admin die Referenz (mit dem »@« davor) mit den Argumenten »select-srt-port=@tap0 select -dst-port=@tap1« spezifizieren. Mit »ovs-vsctl list Mirror« lassen sich die konfigurierten Spiegel auflisten. Die Anweisung »ovs-vsctl remove Bridge linux-switch0 mirror tapmirror« entfernt den Spiegel wieder.

Tunneln

In größeren Umgebungen kann es notwendig sein, zwei LAN-Inseln über einen Layer-3-Tunnel miteinander zu verbinden. Das lässt sich zwar vermeiden, wenn der Planer das Netzwerk entwirft, bei einer organisch gewachsenen Umgebung wird es trotzdem manchmal notwendig. Open Vswitch kann Pakete über das Generic-Router-Encapsulation-Protokoll (GRE), CAPWAP (das häufig zwischen dummen Basestations und deren Controllern Einsatz findet) oder GRE in IPsec tunneln.

Auf den beiden Hosts in Abbildung 1 existiert jeweils eine Insel eines LAN für virtuelle Maschinen. Die Hosts, die diese Gäste beherbergen, sind im Netz getrennt, sodass Routen notwendig sind, um die Pakete auszutauschen. Die Adressen des aufgeteilten LAN werden dagegen im Netz nicht geroutet. Damit sich die Tunnel aufbauen lassen, muss der Admin das Kernelmodul aus der Open-Vswitch-Distribution verwenden. Das Modul aus dem Kernel selbst bringt im Logfile beim Hinzufügen des Tunnel-Interface die Warnmeldung »address family not supported« .

Zwei Switches, bitte

Auf beiden Seiten muss außerdem ein virtueller Switch existieren, der einen Port und eine Adresse im LAN hat und darüber routet. Auf Host A ist dies 172.18.1.1 und auf Host B 172.19.1.1. Beide Seiten haben »eth0« in diesem Switch als Port zugewiesen, die Routingtabelle ist so konfiguriert, dass die Hosts A und B erreichen. Die Insel-Switches heißen »islandswA« und »islandswB« und verbinden das LAN 10.1.1.0/24. Zum Tunneln dient in diesem Beispiel GRE.

Listing 2 zeigt die Konfiguration für Host A – ebenfalls einfach vom Admin an der Shell eingegeben. Auf Host B konfiguriert er das Ganze spiegelverkehrt (Listing 3). Mit dem Kommando »ovs-vsctl show« lässt sich die vollständige Konfiguration anzeigen. Dabei ist darauf zu achten, dass bei den Switches (in der Open-Vswitch-Terminologie steht dort »Bridge« ) unter dem Controller-Eintrag das Flag »is_connected: true« vorhanden ist – eine simple Erfolgskontrolle für die Konfiguration.

01 # ovs-vsctl set-controller islandswA tcp:172.18.1.1
02 # ovs-vsctl add-port islandswA add-port gre1 -- set Interface gre1 type=gre options:remote_ip=172.19.1.1

01 # ovs-vsctl set-controller islandswB tcp:172.19.1.1
02 # ovs-vsctl add-port islandswA add-port gre1 -- set Interface gre1 type=gre options:remote_ip=172.18.1.1

Netflow

Nach erfolgreicher Konfiguration geht’s an die Integration ins Management. Das ursprünglich von Cisco entwickelte Netflow-Protokoll liefert die für den Admin wichtigen Informationen, welche Netzwerkgeräte miteinander kommunizieren, in einem exportierbaren Format. Seit Version 9 gibt es auch ein RFC (3954, [7]). Open Vswitch spricht Netflow, alternativ auch Sflow [8].

Die exportierten Daten sammelt ein Netflow Collector ein. Er hat in der Regel auch eine Software zum Auswerten dabei, die die Kommunikationszusammenhänge im Netzwerk sichtbar macht. Neben einer ganzen Reihe kommerzieller Kollektoren bietet Ntop zusätzlich zur eigenen Analyse auch die Möglichkeit, als Netflow Collector zu agieren.

Konfiguration

Der Administrator konfiguriert Netflow pro virtuellem Switch. Die Konfiguration erfolgt über längliche Einträge in der Datenbank. Das Kommando aus Listing  4 aktiviert Netflow auf dem Switch »linux-switch0« und schickt die Flow-Daten an einen Collector auf der IP-Adresse 172.16.1.1 und dem Standard-Netflow-Port 2055. Um das Senden der Daten zu deaktivieren, gibt der Administrator das Kommando »ovs-vsctl clear Bridge linux-switch0 netflow« ein.

01 # ovs-vsctl -- set Bridge linux-switch0 netflow=@nf -- --id=@nf create NetFlow  targets=\"172.16.1.1:2055\" active-timeout=30

Virtualisierungen

In der realen Welt müsste der Administrator jetzt nur noch die Netzwerkkabel in die richtigen Ports seines Switch stecken. In der virtuellen Welt funktioniert das ähnlich, doch haben die Hypervisoren ihre Eigenheiten:

Virtualbox und VMware bieten Host-only-Interfaces. Diese tauchen auch auf dem Host auf (sichtbar mit »ifconfig« ) und lassen sich mit dem »add-port« -Kommando einfach einem bestimmten Switch zuweisen. Dabei ist aber darauf zu achten, dass jeder Host sein eigenes Interface bekommt, da sonst innerhalb eines Host-only-Interface die Hosts wieder wie an einem Hub hängen und beispielsweise der Traffic des Nachbarn für alle sichtbar bleibt.

Xen erzeugt typischerweise VIF-Interfaces, die dem Schema »Index_der_Maschine.Index_des_Interface« folgen. Jedoch hängen die Indizes davon ab, in welcher Reihenfolge die Maschinen starten, sodass die Zuordnung zum richtigen virtuellen Switch durchaus schwierig sein kann, zumindest wenn der Admin in der Konfiguration nicht den Parameter »vifname« verwendet.

Xen besitzt auch Skripte, die mit Bridges die Interfaces zu den richtigen Brücken hinzufügen. Auch sieht es Ersatzskripte vor, die der Admin stattdessen verwenden kann, um die Open-Vswitch-Einbindung umzusetzen. Wer den Bridge Compatibility Mode (im Paket »openvswitch-brcompat« ) einsetzt, sorgt dafür, dass Xen gar nichts mehr von Open Vswitch mitbekommt. Dafür müssen aber der Daemon »ovs-brcompatd« gestartet und das passende Kernelmodul geladen sein.

KVM verwendet die virtuellen Tap-Interfaces des Linux-Kernels, die sich recht simpel einbinden lassen. Doch auch hier hat der Admin auf die richtige Reihenfolge zu achten, wofür er beim Start des KVM-Gastes Skripte für das Netzwerk-Interface ausführt, die beim Hoch- und Herunterfahren ablaufen. Die Option »-net« unterstützt dazu die mit Komma angefügten Subparameter »script=« und »downscript=« . Die Skripte erhalten dann die Aufrufe, beispielsweise von »downscript=« , um den Port zum Switch hinzuzufügen oder zu entfernen.

Wer Libvirt zur Verwaltung der VMs verwendet, macht es sich deutlich einfacher. Libvirt unterstützt Open Vswitch bereits seit seiner Version 0.9.11, allerdings sieht der Virt-Manager als grafisches Frontend dafür noch keine Konfigurationsoption vor (Abbildung 3). Ein Texteditor hilft: In der XML-Konfiguration eines Gastes stellt der Admin einfach den Interfacetyp auf »bridge« . Der XML-Block in Listing 5 zeigt die Parameter für den Port.

01 <interface type="bridge">
02   <source bridge="linux-switch'"/>
03   <virtualport type="openvswitch"/>
04 [...]
05 </interface>

Abbildung 3: Mit Libvirt und dem Virt-Manager geht vieles rund um Virtualisierung einfacher, meist sogar per Mausklick. Doch die Konfiguration eines Vswitch ist noch nicht im GUI angekommen.

Sicherheit, Bonding und Link Aggregation

Open Vswitch legt für jeden angelegten Switch ein Interface an. Wer diesen Interfaces IP-Adressen gibt, ermöglicht angeschlossenen Gästen, über diese Interfaces zu routen, sofern IP-Forwarding aktiv ist. Will er das nicht, dann sollte der Admin auf die Konfiguration des Forwarding auf dem Host achten. Natürlich kann er auch über »/proc/sys/net/ipv4/conf/Name_des_Interface/forwarding« explizit einzelne Interfaces ausschließen.

Open Vswitch funktioniert so auch als Layer-3-Switch oder als Router. Auch kann der Admin mit IPtables-Regeln explizit die Kommunikation zwischen einzelnen Ports unterbinden. Mit »ovs-vsctl« kann er sogar QoS-Parameter über Scheduler wie Linux-HTB [9] setzen. Zwar wäre es auch möglich, diese Parameter einfach pro Interface zu bestimmen, besser ist es aber, die Konfiguration über Open Vswitch zu erledigen. Dann sind die Parameter schon beim Start der Open-Vswitch-Dienste vorgegeben.

Open Vswitch räumt auch die Möglichkeit ein, mehrere Interfaces zu einem logischen zusammenzubinden (Bonding, [10]), um durch die Verteilung auf Ports mehr Bandbreite zu erzielen. Das Unterkommando »add-bond bridge bondname Interface1Interface2[…]« erzeugt die Bonds. Handelt es sich um physische Interfaces und soll sich der Verbund auch über den physischen Switch fortpflanzen, an den sie angebunden sind, muss der Admin dies selbst konfigurieren, etwa mit Link Aggregation (LACP, [11]). Open Vswitch erfährt dies beim Anlegen des Bond mit »lacp=active« .

Open Vswitch bietet eine leistungsfähige und komfortable Möglichkeit, virtuelle Systeme in und über die Grenzen der physischen Hosts zu vernetzen. Damit hat der Administrator das Rüstzeug, um auch komplexe Netzwerkdesigns umzusetzen. Das Bridge-Kompatibilitätsmodul erlaubt den nahtlosen Austausch von eventuell bisher verwendeten Linux-Bridges. Net/sFlow und QoS-Mechanismen sind Highend-Features, die derzeit nicht alle physischen Switches besitzen.

Die bei Redaktionsschluss dieses Artikels verfügbare Version 1.7.1 unterstützte leider keine Kernelversion neuer als 3.3 bei Kernelmodulen, die für die fortgeschrittenen Funktionen notwendig sind. Wer die benötigt, braucht noch etwas Geduld, bis die Open-Vswitch-Pakete der Distributoren nachziehen. Auch die Dokumentation des Projekts könnte an einigen Stellen etwas klarer sein, aber eine Onlinesuche fördert in der Regel Konfigurationsbeispiele zu Tage, mit denen der Administrator seine Wünsche umsetzen kann.

Performance

Nicht zu vergessen: Tunnel kosten Performance. In einem Testaufbau ohne Router zwischen den Inseln kam Netperf zum Einsatz, um den Durchsatz zumindest oberflächlich zu messen. In einem Aufbau, der mit dem aus Abbildung 1 vergleichbar ist, erzielte das Szenario 900 MBit/s, die direkte Messung zwischen den beiden Hosts 940 MBit/s. Ein Admin, der das einzusetzen plant, sollte also von knapp 5 Prozent Overhead ausgehen, der aber sicherlich je nach verwendetem Dienst und Protokoll variiert. Außerdem ist Netperf sicherlich nicht für alle Traffic Mixes repräsentativ, eigenes Testen ist daher unabdingbar.