Open-Source-Netzwerkzukunft: Der Floodlight-OpenFlow-Controller

© aurielaki, 123RF

Leitstandstechnik

Die Schlagworte Netzwerkvirtualisierung und Software Defined Networking (SDN) markieren einen Paradigmenwechsel im Bereich der Kommunikationsnetze. Der Weg führt zu einem ganzheitlichen Netzwerkkonzept, für das mit Floodlight eine vielversprechende Open-Source-Software zur Verfügung steht.
Der ADMIN 05/13 wirft einen Blick auf die frei verfügbaren Cloud-Frameworks von Eucalyptus über OpenNebula bis OpenStack. Gute Aussichten für skalierbare ... (mehr)

Heutige Kommunikationsnetze basieren in weiten Teilen auf den einfachen, ursprünglichen Mechanismen von Ethernet und TCP/IP. Durch dessen Erfolg und das dadurch bedingte enorme Wachstum der Netze wurden jedoch immer komplexere Kontrollmöglichkeiten wie VLANs, ACLs, Firewalls und Deep Packet Inspection notwendig. Dabei implementiert eine Vielzahl von heterogenen Netzwerk-Appliances (Firewalls, Load Balancer, IDS, Optimierer und so weiter – kurz sogenannte Middleboxes) jeweils ihren eigenen proprietären Kontroll-Stack sowie ein zumeist herstellerabhängiges Management-Interface in Form eines CLI, einer Weboberfläche oder eines Management-Protokolls. Die Kommunikation untereinander erfolgt dezentral über immer komplexere Protokolle wie Spanning Tree, Shortest Path Bridging, Border Gateway oder ähnliches.

Jede zusätzliche Komponente erhöht somit die Komplexität und erschwert ein integriertes Netzwerkmanagement. Die Folgen sind häufig eine geringe Netzauslastung, schlechte Verwaltbarkeit, mangelnde Kontrollmöglichkeiten in netzübergreifenden Konfigurationen und ein Vendor-Lock-in.

Ausweg OpenFlow

Einen Ausweg aus diesem Dilemma versprechen Software Defined Networks (SDNs) und OpenFlow. OpenFlow ist ein von der Open Networking Foundation (ONF) standardisiertes Protokoll, das die komplexen Details einer schnellen und effizienten Switching-Architektur abstrahiert und einem externen Controller direkt zur Verfügung stellt. Mit OpenFlow steht heute für Netzwerkkomponenten eine offene Kontrollschnittstelle zur Verfügung, die mittlerweile von allen namhaften Herstellern hardwareseitig implementiert wird. Darüber hinaus gibt es einige Implementierungen in Form von Software-Switches, die den Einsatz in virtualisierten Rechenzentren erlauben.

OpenFlow ermöglicht auch die im Konzept von Software Defined Networking geforderte Trennung von Daten- und Kontrollpfad. Das macht eine Netzwerkarchitektur möglich, in der eine zentrale Kontrollinstanz – der SDN-Controller – eine Vielzahl von OpenFlow-fähigen Netzwerkkomponenten steuert und eine netzwerkweite Sichtweise etwa auf Datenflüsse, Kontroll- und Sicherheitsinformationen wie VLANs oder ACLs besitzt. Der SDN-Controller selbst kann aus Gründen der Ausfallsicherheit oder zum Load Balancing verteilt sein.

Das OpenFlow-Protokoll erlaubt eine einheitliche, direkte Kontrolle der Infrastruktur. Die Notwendigkeit eines komplexen und komplizierten Netzwerkmanagements entfällt in weiten Teilen. Dies erhöht die Flexibilität und überwindet ganz nebenbei die Notwendigkeit, sich auf einen einzigen Hardwarehersteller festlegen zu müssen. Darüber hinaus besteht mit OpenFlow die Möglichkeit zur Entwicklung eigener Netzwerkanwendungen und damit einer besseren Integration des Netzwerks in ein Gesamtsystem mit Servern und Storage. Gleichzeitig erhofft man sich eine deutliche Senkung der Kosten. Abbildung 1 zeigt die Unterschiede zwischen einem klassisch-konservativen Netzwerk und einem SDN-Netzwerk.

Abbildung 1: Der Unterschied zwischen einem klassisch-konservativen Netzwerk mit verteilten, heterogenen und vertikal integrierten Netzwerkkomponenten und einem SDN-Netzwerk mittels OpenFlow.

Regeln steuern Pakete

Die OpenFlow-API arbeitet mit einfachen Primitives zur Behandlung von Netzwerkpaketen sowie zur Abfrage und Auswertung von Statistiken. Auf der Grundlage von Matching-Regeln zum Erkennen identischer Header-Informationen erlaubt OpenFlow das Zusammenfassen von Paketen zu sogenannten Flows. Diesen Flows kann eine Priorität sowie eine Aktion zugewiesen werden. Eine einfache OpenFlow-Regel könnte wie folgt ausschauen:

match="dl_type=ip, nw_type=tcp,tp_dst_port=80", action="output=2",priority="10"

Diese Regel besagt, dass alle IP-Pakete mit TCP-Zielport 80 an Port 2 weitergeleitet werden sollen. Treffen mehrere Regeln auf ein Paket zu, bestimmt die Priorität, welche vorrangig angewendet wird.

In den einfachen Primitives des OpenFlow-Protokolls zeigt sich seine große Flexibilität. Gleichzeitig stellen sie eine Herausforderung dar. So ermöglicht OpenFlow zwar die Programmierung eines SDN-Netzwerks, macht sie jedoch nicht unbedingt einfach.

Ein Netzwerk nur über OpenFlow-Primitives zu managen, wäre so, als würde man Software ausschließlich in Maschinencode entwickeln.

Deshalb kommt dem SDN-Controller eine wichtige Bedeutung zu. Er übernimmt die zentrale Aufgabe der Kommunikation mit den OpenFlow-Switches und der Abstraktion von der OpenFlow-API. Statt mit komplizierten OpenFlow-Primitives lassen sich SDN-Netze damit durch höhere Befehle der Art "Installiere einen Datenpfad von A nach B" oder "Verwerfe alle Pakete an Host X" steuern. Der Controller löst eventuell auftretende Konflikte, übersetzt die Befehle in OpenFlow-Primitives und installiert diese dann auf die entsprechenden Switche.

Auf Basis dieser Abstraktionen lassen sich dann die eigentlichen Netzwerk-Applikationen wie MAC-Learning, Spanning Tree oder Routing-Protokolle realisieren. Auch völlig neue Ideen wie Multipath Switching, BYOD-Anwendungen oder eine zentrale ACL-Konfiguration sind relativ schnell implementiert. Ausgeführt werden die Applikationen auf dem Controller wie in heutigen Betriebssystemen. Im SDN-Jargon spricht man daher auch von einem Netzwerkbetriebssystem.

Noch stehen sowohl die Entwicklung von SDN-Controllern wie auch die Suche nach den richtigen OpenFlow-Abstraktionen am Anfang und sind Teil intensiver Forschungsaktivitäten. Kann man jedoch mit einigen Einschränkungen leben, so steht mit dem Floodlight-OpenFlow-SDN-Controller bereits eine vielversprechende Open-Source-Software zur Verfügung.

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite