Virtuelle Switche mit Open vSwitch

Schneller Verteiler

Open vSwitch implementiert in Software einen Netzwerk-Switch, der die meisten im Rechenzentrum nützlichen Funktionen bereitstellt. Damit lassen sich virtuelle Maschinen ohne großen Aufwand zu virtuellen Netzen verschalten. Für komplexe Anwendungen von Software-defined Network-ing unterstützt die Software auch das OpenFlow-Protokoll.
IT-Administrator startet mit einem Blick in die Zukunft in das neue Jahr. So dreht sich der Heftschwerpunkt der Januar-Ausgabe um das Thema 'Future Networks'. ... (mehr)

Virtuelle Umgebungen sind mittlerweile in Unternehmen eher der Standard als die Ausnahme. Virtuelle Maschinen kommunizieren nicht nur mit der Außenwelt, sondern auch untereinander. Deshalb müssen sich virtuelle Netzwerkanschlüsse genauso verschalten lassen, wie dies bei physischen Servern möglich ist. Und zwar ohne Merkwürdigkeiten wie in den ersten Generationen des Cisco Nexus, bei denen der Admin zur Verbindung zweier VMs von außen ein Netzwerkkabel auf den Host stecken musste. Open vSwitch [1] als Teil des Linux-Kernels ist dabei mittlerweile der Standard, der beispielsweise bei OpenStack ohne zusätzliche Module für das Networking zuständig ist.

Open vSwitch implementiert einen vollwertigen Switch, der die meisten im Rechenzentrum üblichen Funktionen bereitstellt. Das beinhaltet die Zuordnung von Ports zu VLANs (auch mit Tagging), Spiegelports, Portgruppen zur Redundanz (inklusive LACP-Unterstützung) und QoS. Dabei ist es Open vSwitch egal, ob es sich um physische oder virtuelle Ports handelt.

Virtuelle Umgebungen arbeiten häufig mit Overlay-Netzwerken, um virtuelle Maschinen zusammenzuschalten, die zwar auf verschiedenen Hosts laufen, aber in einem LAN-Segment laufen sollen. Open vSwitch unterstützt dabei alle offenen Protokolle, die zum Einpacken der Layer 2 Pakete verwendet werden, von GRE über das momentan führende VXLAN bis zum brandneuen GENEVE, wobei es immer davon abhängt, ob der Kernel das jeweilige Protokoll auch unterstützt. Schließlich unterstützt Open vSwitch auch noch NetFlow, IPFIX und sFlow zum Sammeln von Flowdaten und das OpenFlow-Protokoll (siehe Kasten "OpenFlow").

Open vSwitch-Architektur

Open vSwitch besteht aus dem ovs-vswitchd, der die Konfigurationskommandos annimmt und an die umsetzende Einheit (in der Regel das Kernelmodul) weiterleitet, und dem ovsdb-server, der die Konfigurationen persistent speichert. Bevor es Open vSwitch gab, konnte der Administrator nur mittels des Bridgemoduls VMs untereinander beziehungsweise mit der Außenwelt verbinden. Daher können das Open vSwitch-Modul und das Bridge-Modul nicht gleichzeitig geladen sein. Da in der Vergangenheit viele Skripte von Virtualisierungslösungen nur das Bridgemodul und seine Werkzeuge unterstützten, gibt es in älteren Kernelversionen noch ein Kompatibilitätsmodul, das die Aufrufe an das Bridgemodul abfängt und in Open vSwitch umsetzt.

Open vSwitch speichert die Konfigurationen persistent in einer JSON-Datenbank, die sich üblicherweise im Verzeichnis "/etc/openswitch" befindet. Als Server für diese Datenbank dient das Programm ovsdb-server. Konfigurationsänderungen, die mit dem Hauptwerkzeug »ovs-vsctl« durchgeführt werden, werden auch direkt in diese Datenbank eingetragen. Das Werkzeug »ovsdb-client« formatiert die Tabellen besser lesbar als in der rohen JSON-Form. Der Server läuft zwar in der Regel auf demselben Server wie die Switche, muss das aber nicht tun. Das Kommunikationsprotokoll für den Zugriff auf die Datenbank ist im RFC 7047 beschrieben. Es gibt auch Hardware-Switche, die dieses Protokoll zur Konfiguration unterstützen. Dies wird meist von Virtualisierungslösungen genutzt, damit sich der Administrator die manuelle Konfiguration an der Netzwerkausrüstung, die zur virtuellen Umgebung passt, sparen kann.

Der Prozess »ovs-vswitchd« übernimmt die Kontrolle und Verwaltung der virtuellen Switche auf der lokalen Maschine. Dieser Prozess unterhält auch die Verbindung zur Konfigurationsdatenbank. Sollen die Switche im Userspace laufen, so ist dies auch die Aufgabe dieses Prozesses. Sonst steuert er das Kernelmodul. Wird ein OpenFlow-Controller verwendet, baut der ovs-vswitchd die Verbindung dorthin auf und tauscht sich über das OpenFlow-Protokoll mit diesem aus. Gesteuert wird der vswitchd mit dem Kommandozeilenwerkzeug »ovs-vsctl« .

OpenFlow

OpenFlow wird häufig synonym mit Software-defined Networking (SDN) genannt. Dies ist technisch sicherlich nicht korrekt, aber OpenFlow ist die momentan führende Technologie, um den SDN-Gedanken auch praktisch umzusetzen. SDN beschreibt eine Technologie, bei der die Control- und die Dataplane eines Netzwerkgerätes getrennt werden. Die Controlplane, die die Steuerung übernimmt, wird dabei durch einen zentralen Controller ersetzt, der der Dataplane Anweisungen erteilt.OpenFlow ist ein Protokoll, das Zugriff auf die Dataplane eines Switches oder Routers erlaubt. Der Controller verwendet dieses Protokoll, um Flowregeln auf das Gerät zu schieben und um vom Gerät Informationen über die Traffic Statistiken sowie über neue Flows zu erhalten. Ein Flow beschreibt dabei eine Verbindung, die auf einem Port des Gerätes hinein und aus einem anderen hinausgeht. Je nach unterstützter Version des Standards kann der Flow MAC-Adressen, IP-Adressen, TCP- oder UDP-Ports und weitere Informationen als Filter enthalten. Eine Flow-Regel mit den Filtern kann dann eine Aktion auslösen. Dies kann bedeutet, dass ein Paket verworfen wird, auf einen bestimmtem Port weitergeschickt oder sogar manipuliert wird. So kann der Administrator Adressen oder Ports ändern oder sogar das Paket mit einem VLAN Tag versehen. Erscheint ein Paket am Gerät, zu dem es keine passende Flow-Regel gibt, wird es an den Controller geleitet, der dann mit einem beliebig komplexen Programm entscheiden kann, was mit dem Paket geschehen soll. Das Ergebnis der Entscheidung wird als Flow wieder zurückgeschickt.

Eine einfache Konfiguration

Bevor es losgehen kann, müssen Sie eine leere Konfigurationsdatenbank erzeugen. In der Regel erledigen dies die Init-Skripte, wenn es die Datenbank noch nicht gibt. In der Praxis mussten wir allerdings die Datenbank ein paar Mal reinitialisieren. Die Datenbank legt dann das folgende Kommando an:

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

»ovsdb-tool« sollten Sie auch verwenden, wenn Open vSwitch aktualisiert wurde und Änderungen an der Konfiguration zu einem Hängen führen. Die Option "convert" bringt die Datenbank nach einer Änderung des Formates auf den neuen Stand. Die folgenden Befehle legen eine Switchinstanz mit zwei Ports an:

# ovs-vsctl add-br switch0
# ovs-vsctl add-port switch0 eth0
# ovs-vsctl add-port switch0 tap0

Dem erfahrenen Leser fällt die Ähnlichkeit der Optionen mit dem brctl-Kommando zur Konfiguration von Linux-Bridges auf. Das Beispiel legt einen Switch mit dem Namen "switch0" an. Das Anlegen mit "add-br" sorgt dafür, dass danach ein Interface gleichen Namens existiert. Die angeschlossenen Interfaces sollten keine eigenen IP-Adressen besitzen. Ist es beabsichtigt, dass ein Host für virtuelle Maschinen mit diesen kommunizieren können soll, ist das implizit angelegte switch0-Interface das richtige. Über den Switching-Mechanismus kann der Host im Beispiel auch über das physische Netzwerk mit der Außenwelt kommunizieren. Das an­geschlossene eth0-Interface dient als Uplink-Port des virtuellen Switches.

Wie jeder bessere Switch unterstützt auch Open vSwitch VLANs. Um einen Port im Sinne eines Access-Ports (aller Traffic auf diesem Port gehört zum entsprechenden VLAN) zu konfigurieren, fügen Sie die Option "tag=ID" hinzu. Ohne zusätzliche Anweisungen sind dann alle Ports ohne einen Tag Trunk Ports, die alle VLANs mit dem entsprechenden Tag weiterleiten. Im Falle des obigen Beispiels müssten auf dem physischen Port am Switch, an dem eth0 angeschlossen ist, alle VLANs konfiguriert sein, die den anderen Ports von switch0 zugeordnet wurden. Es ist jedoch möglich, dies mit dem Befehl »ovs-vsctl set port eth0 trunks=Liste von VLANIds« einzuschränken. Die Liste trennen Sie dabei mit Kommata. Es ist auch möglich, nachträglich einen Port einem VLAN zuzuordnen. Dies lässt sich mit dem Kommando »ovs-vsctl set port portname tag=andere ID« erreichen. Die set-Kommandos manipulieren die Konfigurationsdatenbank direkt.

Linux unterstützt auch VLANs. Ist das 8021q-Modul geladen, erzeugt das Kommando »vconfig add eth0 vlanid« (oder das ip-Kommando) ein tagged VLAN-Interface. Das daraus entstehende Interface "eth0.vlanid" läßt sich wie jedes andere Interface als Port zu einem vswitch hinzufügen. Dieses Vorgehen verkompliziert die Administration, da sie an mehreren Stellen stattfindet. Ein Szenario, das aber sinnvoll sein kann, ist, wenn der Linuxrechner über eth0 normal erreichbar sein soll, aber eth0.1000 an einem vswitch hängen soll (vlan1000 ist am Switchport des Linuxrechners getaggt konfiguriert). Je nach Distribution ist es nicht ganz trivial, die IP-Adresse auf die Switch-Bridge zu bringen (die Reihenfolge, wann Open vSwitch und das Netzwerk gestartet werden, kommt sich da möglicherweise ins Gehege).

Im Zusammenspiel mit anderen Switchen empfiehlt es sich, dass Spanning Tree-Protokoll zur Erkennung von Schleifen im Layer-2 Netz zu aktivieren. Dies konfiguriert das Kommando »ovs-vsctl set Bridge switch0 stp_enable=true.«

Der Unterschied zwischen Switch und Hub ist, dass auf einem Switchport nur noch der dafür bestimmte Traffic ankommt. Ein tcpdump auf einem an einem Switchport angeschlossenen Linux-Rechner zeigt neben Broadcasts nur den relevanten Verkehr. Zur Fehlersuche benötigen Administratoren aber immer wieder Mitschnitte. Da die Switche dies in der Regel selber nicht können, bieten viele die Möglichkeit, einen Portmirror zu konfigurieren.

Um dem oben konfigurierten Switch einen Spiegelport zuzuordnen, fügen Sie im ersten Schritt einen neuen Port hinzu, auf den der Verkehr gespiegelt wird. Hier bietet sich ein neues tap-Interface (tap1) an. Dieses kann dann entweder mit einem Aufruf des add-port-Kommandos oder nachträglich mittels »set« zum Spiegelport gemacht werden.

Das Anlegen des Mirrors verwendet die dynamisch vergebenen UIDs aus der OVSDB, daher müssen Sie diese in der Kommandozeile, die den Spiegel anlegt, erst einmal auslesen und dann gleich wiederverwenden. Mit "--" als Argument für ovs-vsctl werden Kommandos angegeben, die direkt mit der Datenbank arbeiten. Dies führt zu folgender etwas längeren Zeile (im Beispiel werden die Interfaces tap0 und eth1 auf das Interface tap1 gespiegelt).

# ovs-vsctl -- set Bridge switch0 mirrors=@m \ -- --id=@tap0 get Port tap0 \ -- --id=@eth0 get Port eth0 \ -- --id=@tap1 get Port tap1 \ -- --id=@m create Mirror name=tapmirror select_all=1 output-port=@tap1

Die Anweisung »select_all=1« gibt an, dass der Spiegel allen Verkehr zwischen den tap-Schnittstellen übertragen soll. Sollen nur bestimmte Richtungen (zum Beispiel von tap0 zu eth0) ausgewählt werden, kann die Referenz (mit dem @ davor) mit den Argumenten »select-srt-port=@tap0 select-dst-port=@eth1« genutzt werden. Damit können Sie recht fein abgestuft filtern, welcher Traffic auf dem Zielinterface sichtbar werden soll.

Mit »ovs-vsctl list Mirror« lassen sich die konfigurierten Spiegel auflisten. Die Anweisung »ovs-vsctl remove Bridge switch0 mirror tapmirror« entfernt den Spiegel .

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023