© Tono Balaguer, 123RF.com

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.

Software Defined Networking (SDN) degradiert herkömmliche Netzwerkhardware (etwa Switches und Router) mit all ihren integrierten Features zu dummen Wachposten mit einer ausgelagerten zentralen Software als Kommandostelle, dem Controller (Abbildung 1). Möglich macht das ein neues Protokoll namens Open Flow [1], das mittlerweile auffallend viele proprietäre und freie SDN-Projekte implementieren.

Abbildung 1: Ein Open-Flow-fähiger Switch mit Anbindung an den Controller.

Zwei Ebenen

Open Flow ist nicht nur ein technisches Modell, sondern spezifiziert auch das eben erwähnte Prinzip. Und es ist zugleich der Name des Kommunikationsprotokolls, über das der Controller und die realen und virtuellen Switches, Hubs und Router miteinander reden. Nicht zuletzt verwaltet Open Flow die Regeln für die Paketweiterleitungen.

Die Grundidee besteht darin, Hardware einzusetzen, die Pakete weiterleitet, jedoch abgesehen von der Open-Flow-Schnittstelle keinerlei weitere Intelligenz mitbringt. Diese Trennung von Daten- und Kontrollebene (Data Plane und Control Plane) reduziert die Gerätekosten deutlich, denn die Software-seitige Implementierung der diversen Protokolle für den Betrieb eines Geräts in einer Layer-2-Domain (Bridged/Switched Network) geht ins Geld. Diese Kosten entfallen beim Open-Flow-Einsatz komplett.

Zudem muss der Admin die Geräte nicht mehr einzeln vorkonfigurieren: Da die gesamte Intelligenz im Controller steckt, muss er den Schreibtisch nicht mehr verlassen, sondern steuert das Netzwerk von einem zentralen Punkt aus.

Alt gegen neu

SDN erleichtert zudem die Arbeit der Techniker im Network Operation Center (NOC), die sich in Firmen um den Netzwerkbetrieb kümmern. Ein defektes Gerät tauschen sie ohne weitere Eingriffe in die Gerätekonfiguration aus: Nach dem Einbau und dem Patchen der Kabel erkennt der Controller dank Open Flow das neue Gerät und bindet es in das aktive Netzwerk ein.

Während Hubs und Repeater den eher historischen Ansatz verfolgen, Pakete auf allen Ports mit einem aufbereiteten Übertragungspegel weiterzuleiten, agieren Switches etwas intelligenter. Sie legen sich intern Tabellen an, mit deren Hilfe sie den jeweiligen MAC-Adressen Ports zuordnen. Dadurch verschicken sie Pakete zielgerichtet und reduzieren zugleich die Netzlast und den Stromverbrauch. Lediglich Pakete mit einer Broadcast-Adresse senden die Switches an alle Ports. Sie sind nötig, um etwa die IP-Adressen von Hosts aufzulösen, das Stichwort lautet hier Adress Resolution Protocol (Arp).

Im Kontrast dazu verfolgt Open Flow ein “Flow”-basiertes Weiterleitungskonzept. Indem der Controller das Netzwerk in seiner Gesamtheit betrachtet, kann er für bestimmte Pakete eine Art Ende-zu-Ende-Verbindung über mehrere Switches hinweg aufsetzen. Den Pakettyp macht er zum Beispiel am Transportprotokoll fest und leitet TCP-Webtraffic mit Zielport 80 stets über Route A zum Ziel.

Sobald der Controller die Signatur erkennt, weist er die beteiligten Switches im Netzwerk an, ihre Forwarding-Einträge entsprechend zu setzen. Der Admin instruiert also nicht mehr selbst die lokalen Switches, sondern stellt über den Controller fein granulierte Regeln für das gesamte, lernfähige Netzwerk auf.

Schnelle Specs

Die Entwicklung der Open-Flow-Spezifikation hat seit ihrer ersten Vorstellung 2008 ziemlich an Fahrt aufgenommen. Allein zwischen der Testsuite 0.8.1 vom Juni 2008 und der Spezifikation in Version 1.0 vom Dezember 2009 haben die Macher sieben Updates veröffentlicht. Bis zum heutigen Tag kamen acht weitere Iterationen hinzu, die aktuelle Version trägt die Nummer 1.4.

Tabellenkalkulationen

In der Praxis ist Version 1.0 der Spezifikation am weitesten verbreitet. Ihr API implementieren die Entwickler und Hersteller in den kommerziellen und freien Switches sowie den Controllern. Ihre Weiterleitungslogik besteht im Wesentlichen aus einer Flow Table, die wiederum diverse Flow Entries enthält (Abbildung 2). Letztere bringen einen Header mit, der in mehreren Feldern ein Identifikationsmuster versammelt, das der Paketerkennung dient (Matching Pattern).

Abbildung 2: Über ihre Einträge, die Flow Entries, reguliert die Flow Table den Datenstrom.

Daneben definieren die Flow Entries auf Pakete anwendbare Aktionen und haben eine Zählerfunktion (Counter) im Gepäck. Version 1.1 führte dann mehrere Flow Tables ein, weswegen Kenner hier von einer Pipeline sprechen. Die Version ergänzte zudem zusätzliche Header Fields, anhand derer die Switches Pakete identifizieren, etwa für MPLS (Multiprotocol Label Switching) und IPv6.

Die Spezifikationen sind teils sehr umfangreich, weil sie ausführliche Erklärungen zu den Flow-Entry-Strukturen, dem Aufbau der Flow Tables, den möglichen Aktionen und den Zählfeldern liefern. Interessierte finden alle Dokumente frei verfügbar auf der Webseite der Open Networking Foundation [2]. Klar ist, dass sowohl die Zahl der Features als auch die Möglichkeiten zur internen Steuerung mit jeder Versionsnummer wachsen.

Wachposten

Trifft ein Paket in einem Open-Flow-Netzwerk auf einem der für Open Flow reservierten Ports ein, untersucht der Switch, wie in der jeweiligen Spezifikation beschrieben, das Header Field (Abbildung 3). Er vergleicht dessen Bits mit den Einträgen in seiner Flow Table, die als Einträge auch Wildcards verwenden darf. Im Trefferfall führt der Switch die in den Flow Entries definierten Aktionen aus und aktualisiert zum Schluss den Counter.

Abbildung 3: Schema der Header Fields aus der Open-Flow-Spezifikation 1.0.

Als Aktionen kann er das Paket zum Beispiel an einen Port weiterleiten, dessen Header-Feld modifizieren oder es an eine andere Flow Table forwarden. Findet sich der Eintrag im Header-Feld hingegen nicht in der Flow Table wieder, kapselt der Switch das Paket und sendet es an den Controller, der dann entscheidet, wie er damit verfährt. Entweder leitet er es direkt weiter oder er weist die Switches an, den Flow-Eintrag in ihrer Flow Table zu ergänzen, damit sie Pakete mit diesem Header künftig nach einem bestimmten Muster behandeln.

Der Controller kennt zwei Arten von Flow Entries, proaktive und reaktive. Proaktiv heißt, dass der Controller den Switch anweist, einen Flow-Eintrag für eine bestimmte Flow Table zu setzen, ohne dass der Switch darum gebeten hat. Reaktiv ist der Vorgang, wenn der Switch auf ein Datenpaket stößt, dessen Header-Feld-Einträge nicht in seiner Flow Table vorkommen. Er kapselt es dann, sendet es an den Controller und der erzeugt als Reaktion einen passenden Flow-Eintrag für das unbekannte Paket.

Hat ein Switch einen Flow Entry erst einmal gesetzt, winkt er die zum Flow gehörenden Pakete einfach durch. Dies verringert die Reaktionszeit, weil es den Umweg über den Controller einspart. Bremsend wirkt, dass die Hardware nicht alle Aktionen der Flow-Einträge kennt. Führt aber eine Software diese Aktionen aus, verlangsamt dies den Prozess. Bei reaktiven Flow Entries verzögert hingegen der Controller die Weiterleitung durch zusätzliche Kommunikation und das Warten auf Entscheidungen zur Paketbehandlung.

Hardware

Open Flow hat sich als SDN-Konzept bis zum Produktiveinsatz entwickelt, die dedizierten Switches, die Open Flow unterstützen, bezeichnen sich als Open Flow Enabled. Es handelt sich um Hybrid-Switches, die neben ihrer herkömmlichen Switch-Funktionalität und den damit verbundenen Protokollen, etwa dem Link Local Discovery Protocol (LLDP), auch eine Open-Flow-Konfiguration anbieten. Um sie zu nutzen, muss der Netzwerker abhängig vom Herstellermodell verschiedene Konfigurationen an der Open-Flow-Instanz auf dem Switch vornehmen. Dies bedeutet meist, dass er die entsprechenden Ports oder VLANs in den Open-Flow-Modus versetzt, damit ein externer Controller die Switches instruiert.

Zurzeit beschränkt sich der Einsatz von Open Flow auf den Bereich klassischer Switches für Datenpakete (Data Path). Für optische Netze, die Lichtwellen weiterleiten (Light Path), gibt es Open-Flow-ähnliche Technologien. Forscher arbeiten seit einiger Zeit daran, Open Flow aber auch in diesem Bereich zu etablieren, um eine übergreifende und einheitliche Managementebene für Netzwerktechnologien zu schaffen.

Volle Kontrolle

Es gibt diverse Controller für Open-Flow-Netzwerke. Sie dienen in der Regel als Plattform für so genannte Netzwerkapplikationen (Apps). Die Controller implementieren das zur Spezifikation kompatible Open-Flow-Protokoll und kümmern sich um die Kommunikation mit den Switches.

Als Plattform ermöglichen sie es den App-Entwicklern zugleich, sich voll und ganz auf das Implementieren der Apps zu konzentrieren (Abbildung 4). Dazu bieten die Controller meist ein API für eine geläufige Programmiersprache an. Die Apps leiten eingehende Pakete an alle Ports weiter und dienen so als virtuelle Hubs. Oder sie routen gezielt Pakete auf Basis von MAC-Adressen und fungieren als Bridges und Switches.

Abbildung 4: Die Open-Flow-Controller dienen häufig als Plattform für Netzwerk-Applikationen.

Die meisten Controller bringen ein paar Basismodule mit. Die erwähnte Switch-Anwendung dient Entwicklern zugleich als Fallbeispiel, um eigene Apps zu entwerfen. Für viele weitere Anwendungen müssen konventionelle Netzwerke spezielle Geräte einsetzen, etwa für Router, Firewalls oder Load Balancer.

Nox

Einer der ersten Open-Flow-Controller heißt Nox [3], steht unter der GPLv3 und wird seit 2008 entwickelt. Er folgt einem Modulkonzept mit einem C++- und Python-API und dient als Beispiel (Hub, Switch), um Entwicklern zu zeigen, wie sie das API zum Entwerfen von Netzwerkanwendungen nutzen.

Floodlight

Der Floodlight-Controller [4] ist hingegen etwas neuer und setzt auf die plattformübergreifende Programmiersprache Java. Auch Floodlight bringt einige Apps mit und verfolgt ein Modul- und App-basiertes Konzept. Die Standardversion liefert zum Beispiel ein Modul mit, das eine zusätzliche REST-Schnittstelle zum aktiven Setzen statischer Flows anbietet. So wie Nox steht auch Floodlight unter einer Open-Source-Lizenz, in diesem Fall unter der von Apache.

Frenetic

Frenetic [5] ist ein Projekt der Princeton University, das die LGPLv3 verwendet. Die Netzwerk-Programmiersprache läuft als Anwendung auf dem Nox-Controller, verwendet ein eigenständiges Runtime Environment und spricht wahlweise Ocaml oder Python.

Frenetic bringt eine weitere Abstraktionsschicht zur App-Entwicklung ins Spiel, die es erlaubt, die Menge an Sourcecode zu reduzieren und anwendungsorientierten Quellcode zu schreiben. Dieser lässt sich modular in Funktionen kapseln und wiederverwenden. Während der C++-Quellcode für einen Repeater beispielsweise um die 100 Codezeilen umfasst, erledigt Frenetic die Implementierung mit weniger als zehn Zeilen Code.

Open Flow und Mininet

Wie SDN mit Open Flow funktioniert, lässt sich am besten an den folgenden drei praktischen Beispielen zeigen. Das im Schwerpunkt vorgestellte Mininet [6] liefert eine passende Umgebung zum Testen und Evaluieren solcher Netze.

Die Heft-DVD bringt fertige Virtualbox-Images mit, als Typ stellt der Anwender »Linux« ein und wählt die passende Architektur aus. Als »Disk-Image« dient die entpackte VMDK-Datei. Bevor er die VM startet, sollte er jedoch die Einstellung für den Netzwerkadapter auf »Netzwerkbrücke« stellen, um die VM auch extern über das LAN zu erreichen.

Hat der Nutzer die VM gestartet und sich angemeldet (Benutzername und Passwort lauten »mininet« ), findet er die idealerweise per DHCP zugewiesene IP-Adresse heraus, indem er »ifconfig« eintippt. Über sie erreicht er die VM nun via SSH von einem externen Host aus. Weitere Mininet-Parameter verrät »man mn« .

Level 1: Hin und zurück

Im ersten Szenario erzeugt der Admin ein Netzwerk, das aus zwei Hosts besteht, die ein Switch verbindet (Listing 1). Er verzichtet auf den Controller, um die Flow Entries manuell zu setzen. Um zu prüfen, ob die Verbindung steht, schickt Host 1 nun über das CLI von Mininet einen Ping an Host 2:

01 mininet@mininet-vm:~$ sudo mn --topo single,2 --mac --switch ovsk --controller remote
02 *** Creating network
03 *** Adding controller
04 Unable to contact the remote controller at 127.0.0.1:6633
05 *** Adding hosts:
06 h1 h2
07 *** Adding switches:
08 s1
09 *** Adding links:
10 (h1, s1) (h2, s1)
11 *** Configuring hosts
12 h1 h2
13 *** Starting controller
14 *** Starting 1 switches
15 s1

mininet> h1 ping -c 4 h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of  data.From 10.0.0.1 icmp_seq=1 Destination Host Unreachable[...]

Der Versuch schlägt allerdings fehl, weil der Switch ohne Flow Entries und ohne Controller zunächst keine Pakete weiterleitet. Die Abwesenheit der letzten beiden zeigt:

mininet@mininet-vm:~$ dpctl dump-flows tcp:127.0.0.1:6634
stats_reply (xid=0x6929ef28): flags=none  type=1(flow)

Das hier verwendete Tool »dpctl« setzt nun einen Flow-Eintrag, der die an Port 1 des Switch ankommenden Pakete an Port 2 weiterreicht:

mininet@mininet-vm:~$ dpctl add-flowtcp:127.0.0.1:6634 in_port=1,actions=output:2

Wieder nichts: Der zweite Ping-Test schlägt auch fehl, da der Switch zwar Pakete an Host 2 weiterleitet, Letzterer aber nicht antwortet.

Setzt der Netzwerker mit »dpctl« in Form eines weiteren Flow Entry jedoch ein Forwarding von Port 2 auf Port 1, wird das Ergebnis positiv: Beide Hosts tauschen sich ungehindert über den Switch aus, so lange der Idle-Timeout nicht dazwischenfunkt (Listing 2).

01 mininet@mininet-vm:~$ dpctl dump-flows tcp:127.0.0.1:6634
02 stats_reply (xid=0x9565ff66): flags=none type=1(flow)
03   cookie=0, duration_sec=39s, duration_nsec=436000000s, table_id=0, priority=32768, n_packets=12, n_bytes=728, idle_timeout=60,hard_timeout=0,in_port=1,actions=output:2
04   cookie=0, duration_sec=13s, duration_nsec=466000000s, table_id=0, priority=32768, n_packets=6, n_bytes=476, idle_timeout=60,hard_timeout=0,in_port=2,actions=output:1

Level 2: Wo bleibt Arp?

Szenario 2 verwendet einen identischen Netzaufbau wie in Szenario 1, schickt den initialen Befehl allerdings so ab, dass Open Vswitch als eingebauter Controller zum Zuge kommt:

mininet@mininet-vm:~$ sudo mn --topo single,2 --switch ovsk --controller ovsc

Der Verbindungstest mit »ping« ist sofort erfolgreich, die Flow Table zeigt drei Flow-Einträge (Listing 3).

01 mininet@mininet-vm:~$ dpctl dump-flows tcp:127.0.0.1:6634
02 stats_reply (xid=0xf857cb47): flags=none type=1(flow)
03   cookie=0, duration_sec=3s, duration_nsec=981000000s, table_id=0, priority=0, n_packets=4, n_bytes=392, idle_timeout=60,hard_timeout=0,icmp,in_port=1,dl_vlan=0xffff,dl_src=00:00:00:00:00:01,dl_dst=00:00:00:00:00:02,nw_src=10.0.0.1,nw_dst=10.0.0.2,nw_tos=0x00,icmp_type=8,icmp_code=0,actions=output:2
04   cookie=0, duration_sec=3s, duration_nsec=980000000s, table_id=0, priority=0, n_packets=4, n_bytes=392, idle_timeout=60,hard_timeout=0,icmp,in_port=2,dl_vlan=0xffff,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01,nw_src=10.0.0.2,nw_dst=10.0.0.1,nw_tos=0x00,icmp_type=0,icmp_code=0,actions=output:1
05   cookie=0, duration_sec=3s, duration_nsec=981000000s, table_id=0, priority=0, n_packets=1, n_bytes=42, idle_timeout=60,hard_timeout=0,arp,in_port=2,dl_vlan=0xffff,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01,nw_src=10.0.0.2,nw_dst=10.0.0.1,nw_proto=2,actions=output:1
06

Neben dem Arp-Reply sind jeweils zwei ICMP-Requests und -Replies zu sehen, die aus dem vom Ping erzeugten Flow-Eintrag stammen. Allerdings stellt sich die Frage, was mit dem Arp-Request passiert ist, der üblicherweise als Broadcast übers Netzwerk geht. Indem der Netzwerker den Control Channel, der Switch und Controller verbindet, per Tcpdump oder Wireshark mitschneidet, kann er feststellen, dass der Controller die Arp-Requests direkt weiterleiten lässt, was keinen Flow Entry benötigt.

Wer Wireshark mit dem Open-Flow-Dissector nutzt, der Teil des Mininet-Image ist, kann sehr übersichtlich die gesamte Kommunikation des Open-Flow-Controllers einsehen und analysieren. Abbildung 5 zeigt als Beispiel den Handshake zwischen Controller und Switch sowie den »Features Reply« des Switch, der dem Controller signalisiert, welche Open-Flow-Aktionen er unterstützt.

Abbildung 5: Mit Wireshark lässt sich die Kommunikation zwischen Controller und Switches prima mitlesen.

Level 3: Baumartige

Im dritten und letzten Szenario erzeugt Mininet ein Netzwerk mit Baumtopologie (Abbildung 6), bei dem jeweils drei Hosts an den Switches S2 bis S4 hängen. Die drei Switches stöpselt Mininet dann an einen Aggregations-Switch (S1). Hierbei handelt es sich um eine übliche Topologie für Netzwerke in Firmen oder auch Rechenzentren. Diesmal legt der Admin einen Remote-Controller fest, weist ihm eine IP-Adresse und einen Open-Flow-Standard-Controller-Port zu:

Abbildung 6: Floodlight erkennt die Baumstruktur des Testnetzwerks automatisch und bildet sie auch grafisch ab.

mininet@mininet-vm:~$ sudo mn --topo  tree,depth=2,fanout=3 --mac --switch ovsk--controller=remote,ip=Controller-IP,port=6633

Als Konsequenz kann der Admin nun einen beliebigen Rechner im lokalem Netzwerk auswählen, auf dem er zum Beispiel Floodlight in der Basiskonfiguration startet:

java -jar floodlight.jar

Ist Mininet online, erkennt Floodlight anhand der Konsolenausgaben unter anderem sowohl die Verbindungen zu den Switches als auch die Topologie. Über die Eingabe von

http://Controller-IP:8080/ui/index.html

ruft der Admin dann das Web-UI von Floodlight auf und lässt sich alle erkannten Switches und Hosts anzeigen – über den Reiter »Topology« auch grafisch. Die Grafik in Abbildung 6 ist zwar eher funktional als ansehnlich, genügt jedoch, um einen Überblick zu erhalten.

Resümee

Dank Open Flow betrachtet der Admin sein Netzwerk nicht mehr als eine Ansammlung diverser Einzelgeräte, die lokal arbeiten und Pakete nach je eigenen Regeln weiterleiten, sondern als großes Ganzes, mit den Netzwerkgeräten als fernsteuerbaren Schleusen. Das öffnet eine Tür für neue Ideen. Als wohl verbreitetste SDN-Manifestation, die auch in kommerziellen Produkten zum Einsatz kommt, sorgt Open Flow für frischen Wind im Bereich der Virtualisierung und der Flexibilität von Netzwerken und leistet Geburtshilfe für zahlreiche darauf aufsetzende Anwendungen.

Die Technologie hat das Potenzial, Netzwerklösungen an der Basis zu verändern, und erfordert ein neues Verständnis dafür, was eine Netzwerkinfrastruktur leisten kann. Open Flow behebt viele der Probleme, die Netzwerke seit der ersten technischen Realisierung des Ethernet mit sich herumschleppen. Es führt die Evolution in einem Bereich ein, in dem seit Jahren Workarounds dominieren, um die grundlegenden Techniken kompatibel zu halten.

Wie so häufig, ist jedoch nicht alles Gold, was glänzt. Zu den offenen Fragen gehört, wie Admins Open Flow grundsätzlich in Produktivumgebungen einsetzen können und wie es sich als Ersatz zu den konventionellen Netzwerken macht – besonders in Rechenzentren oder großen Firmennetzwerken. Das streift die Frage, wie sich die Kontrollebene in solchen Kontexten skalieren und strukturell organisieren lässt.

Ein konkretes Problem besteht darin, dass die Hardware verschiedene Open-Flow-Aktionen zurzeit nur mangelhaft unterstützt. Nicht zuletzt bereiten die immer neuen Versionen der Spezifikation den Firmware- und Controller-Hersteller beim Implementieren der neuen Features Kopfschmerzen.

Der Autor

Marc Körner arbeitet als wissenschaftlicher Mitarbeiter am CIT der TU Berlin. Er beschäftigt sich seit über drei Jahren mit Open Flow und schreibt momentan an seiner Dissertation. Die setzt sich mit der Integration von Open-Flow-Anwendungen in Rechenzentren auseinander.