bachelor-diplomarbeit informatik software defined network ... · openflow with opendaylight, but...

Hochschule Luzern Technik & Architektur

Bachelor-Diplomarbeit Informatik

Software Defined Network im EnterpriseLab

Projekt Software Defined Network im EnterpriseLab Schule Hochschule Luzern Technik & Architektur Modul TA.BA_BAA+INF.F1601 Projektteam Bachmann Sandro

Rathausstrasse 15 6280 Hochdorf [email protected] Mathis Hannes Rössligasse 1 6074 Giswil [email protected]

Betreuender Dozent Infanger Peter Hochschule Luzern T&A 6048 Horw

Experte Pfyffer Markus IBM Schweiz AG Vulkanstrasse 106 8010 Zürich

Kunde Joho Bruno Hochschule Luzern T&A 6048 Horw

Bachelor Diplomarbeit der Hochschule Luzern Technik & Architektur

Titel: Software Defined Network im EnterpriseLab

Diplomandin / Diplomand: Hannes Mathis Sandro Bachmann

Studiengang: Informatik

Abschlussjahr: 2016

Dozentin / Dozent: Infanger Peter Hochschule Luzern T&A 6048 Horw

Diplomexpertin / Diplomexperte: Pfyffer Markus IBM Schweiz AG Vulkanstrasse 106 8010 Zürich

Codierung / Klassifizierung der Arbeit

A: Einsicht (Normalfall)

B: Rücksprache (Dauer: Jahr / Jahre)

C: Sperre (Dauer: Jahr / Jahre)

Eingangsvisum Horw, 17. Juni 2016 ______________________ termingerecht (17.06.2016, 16:30 Uhr) verspätet

Hinweis: Diese Ausgabe der Bachelor Diplomarbeit wurde von keinem Dozierenden nachbearbeitet. Veröffentlichungen (auch auszugsweise) sind ohne das Einverständnis der Studiengangleitung der Hochschule Luzern – Technik & Architektur nicht erlaubt.

Verdankung An dieser Stelle möchten wir uns ganz herzlich bei unserem betreuenden Dozenten, Peter Infanger, für seine intensive Unterstützung und seine hilfreichen Ratschläge bedanken. Dank seinen eigenen Anstrengungen im Bereich SDN konnte er uns sehr kompetent Beraten und verstand unsere Probleme und Anliegen. Zudem bedanken wir uns auch bei unserem Ansprechpartner von Brocade, Fabian Freundt, für das Grosszügige zur Verfügung stellen von Hardware und seiner Unterstützung bei Fragen. Selbstständigkeit Hiermit erklären wir, dass wir die vorliegende Arbeit Software Defined Network im EnterpriseLab selbstständig angefertigt und keine anderen als die angegebenen Hilfsmittel verwendet haben. Redlichkeit Sämtliche verwendeten Textausschnitte, Zitate oder Inhalte anderer Verfasser werden in Übereinstimmung mit Art. 25, Abs. 2 URG ausdrücklich als solche gekennzeichnet.

Ort/Datum, Unterschrift _____________________________________________________

Ort/Datum, Unterschrift _____________________________________________________ Copyright © 2016 Hochschule Luzern – Technik & Architektur Alle Rechte vorbehalten. Kein Teil dieser Arbeit darf ohne die schriftliche Genehmigung der Studiengangleitung der Hochschule Luzern – Technik & Architektur in irgendeiner Form reproduziert oder in eine von Maschinen verwendete Sprache übertragen werden.

Abstract The business partner of this bachelor thesis is the EnterpriseLab of the Lucerne School of Engineering and Architecture, a modern lab environment with the aspiration to early adopt new technologies, to serve the requirements of its customers, the researchers and students. The goal of this paper is to give an overview of the current state of the technology about software defined networks with the provided hardware and software from Brocade and HP. Another part is a testbed installation to verify the interoperability between different hardware vendors and also the promises given by the vendors itself. In a third part a concept for the integration of software defined networks in the EnterpriseLab should be provided. During the fulfillment of the given scope of work, the technology based on OpenFlow and OpenDaylight was discovered as a new approach in the network technology with a high potential to solve most of the current problems. To tap the full potential of SDN in such an early market, a deep understandig of the technology is required and also a lot of resources to develop applications that fulfill the business requirements. Cisco ACI and VMware NSX are mature and solid alternatives to OpenFlow with OpenDaylight, but they are working with their own proprietary protocols without the transparency, which is required to learn students the technology of software defined networks. This work gives an indepth view of the OpenFlow protocol and its possiblities. Further some problems and open questions are highlighted in this document, that will show that the technology is still in a development state. Therefore an implementation in the EnterpriseLab ist not recommended as a part of the productiv environment, but for educational purposes in a form of student exercises, SDN is a sensible extension to prepare students for a technology that will have a high impact on the current profession as a network administrator.

Liste der Dokumente

1

Bericht Einführung SDN, OpenFlow, Controller, SDN in der Praxis, Ausblick

2

Testbed Dokumentation Versuchsaufbau, Installationen, Szenarien

3

Projektplanung Projektorganisation, Ziele, Arbeitspakete, Zeitplanung, Meilensteine, Berichte, Risikomanagement, Abschluss

4

Aufgabenstellung BDA Originale Aufgabenstellung der Bachelor Diplomarbeit

Hochschule Luzern Technik & Architektur



Projekt Software Defined Network im EnterpriseLab Dokument Bericht Schule Hochschule Luzern Technik & Architektur Modul TA.BA_BAA+INF.F1601 Projektteam Bachmann Sandro





Änderungsprotokoll Version Datum Autor Beschreibung 0.1 09.03.15 MAH Initialisierung 0.2 11.04.16 MAH Zusammenfügen div. Dokumente 0.3 15.05.16 BAS Anpassungen 0.4 30.05.16 BAS Anpassungen 0.5 01.06.16 MAH Anpassungen 0.6 09.06.16 MAH Open vSwitch hinzugefügt 0.7 13.06.16 BAS Abstract/Schlusswort hinzugefügt 0.8 15.06.16 MAH Quellen aktualisiert 0.9 15.06.16 BAS Rechtschreibekorrektur 1.0 16.06.16 MAH Dokument abgeschlossen

Inhaltsverzeichnis 1 Begriffe und Abkürzungen ..................................................................................................... 1

2 Einführung SDN .......................................................................................................................... 3 2.1 Problematik .................................................................................................................................... 3 2.2 Konzept ............................................................................................................................................. 3 2.3 Änderungen .................................................................................................................................... 5 2.4 Versprechen .................................................................................................................................... 6 2.5 Risiken und Herausforderungen ............................................................................................. 7 2.6 Warum SDN? ................................................................................................................................... 7 2.7 Application-Defined Network .................................................................................................. 9

3 Openflow .................................................................................................................................... 10 3.1 Geschichte ..................................................................................................................................... 10 3.2 Produkthersteller ...................................................................................................................... 10 3.3 Spezifikation ................................................................................................................................ 12 3.4 Anwendungsmöglichkeiten von OpenFlow ...................................................................... 17 3.5 Alternativen zu OpenFlow ...................................................................................................... 20

4 Controller .................................................................................................................................. 21 4.1 Funktionen ................................................................................................................................... 21 4.2 Marktübersicht ........................................................................................................................... 21 4.3 Schnittstellen ............................................................................................................................... 22 4.4 OpenDaylight ............................................................................................................................... 24 4.5 Brocade SDN Controller ........................................................................................................... 25

5 SDN in der Praxis .................................................................................................................... 27 5.1 Erfahrungsbericht Testbed .................................................................................................... 27 5.2 Big Picture .................................................................................................................................... 30 5.3 Anwendungsszenarien ............................................................................................................. 33 5.4 Aufbau einer SDN Applikation .............................................................................................. 35 5.5 Gesamtlösungen ......................................................................................................................... 41 5.6 Integration EnterpriseLab ...................................................................................................... 45

6 Ausblick ...................................................................................................................................... 49 6.1 Aktuelle Stand von Software Defined Network ............................................................... 49 6.2 Offene Problemstellungen ...................................................................................................... 50 6.3 Nachteile SDN mit OpenFlow ................................................................................................. 53 6.4 Empfehlung Stand heute ......................................................................................................... 54

7 Quellenverzeichnis ................................................................................................................ 55

Abbildungsverzeichnis Abbildung 1: Funktionsprinzip von SDN [3] ....................................................................................................................................... 4 Abbildung 2: Verteile und zentrale Control Plane [8] .................................................................................................................... 5 Abbildung 3: zentraler Controller [11] ................................................................................................................................................. 7 Abbildung 4: Vordefinierte Wege [11] .................................................................................................................................................. 8 Abbildung 5: Priorisierung von Flows [11] ......................................................................................................................................... 8 Abbildung 6: OpenFlow Protokoll [15] ............................................................................................................................................... 10 Abbildung 7: Regel mit Header, Actions und Stats [15] .............................................................................................................. 12 Abbildung 8: vRouter .................................................................................................................................................................................. 17 Abbildung 9: Schnittstellen [27] ............................................................................................................................................................ 22 Abbildung 10: Brocade SDN Controller 2.3 ....................................................................................................................................... 25 Abbildung 11: OpenDaylight SDN Controller ................................................................................................................................... 25 Abbildung 12: Brocade Flow Manager ............................................................................................................................................... 25 Abbildung 13: Brocade Flow Optimizer ............................................................................................................................................. 26 Abbildung 14: Topologie Fehlinterpretation ................................................................................................................................... 29 Abbildung 15: Funktionsweise LLDP [29] ......................................................................................................................................... 31 Abbildung 16: Northbound API .............................................................................................................................................................. 35 Abbildung 17: Portstatistik JSON .......................................................................................................................................................... 37 Abbildung 18: SDN Netzwerk überwachen ....................................................................................................................................... 38 Abbildung 19: APIC [38] ........................................................................................................................................................................... 41 Abbildung 20: VMware NSX [43] ........................................................................................................................................................... 42 Abbildung 21: VMware NSX Planes [44] ............................................................................................................................................ 43 Abbildung 22: Integration EnterpriseLab ......................................................................................................................................... 45 Abbildung 23: Unterrichtsübung Szenario 1 .................................................................................................................................... 46 Abbildung 24: Unterrichtsübung Szenario 2 .................................................................................................................................... 47 Abbildung 25: Gartner Hype Cycle [46] .............................................................................................................................................. 49 Abbildung 26: Trend SDN [47] ................................................................................................................................................................ 50 Tabellenverzeichnis Tabelle 1: Begriffsdefinitionen .................................................................................................................................................................. 1 Tabelle 2: Abkürzungsdefinitionen ......................................................................................................................................................... 2 Tabelle 3: OpenFlow Match Fields ........................................................................................................................................................ 14 Tabelle 4: OpenFlow Instructions .......................................................................................................................................................... 15 Tabelle 5: vRouter Packet Host A - Switch ........................................................................................................................................ 17 Tabelle 6: Match Fields .............................................................................................................................................................................. 17 Tabelle 7: Instructions ................................................................................................................................................................................ 18 Tabelle 8: Packet Information ................................................................................................................................................................ 18 Tabelle 9: Match Fields .............................................................................................................................................................................. 18 Tabelle 10: Instructions ............................................................................................................................................................................. 18 Tabelle 11: Marktübersicht [26] ............................................................................................................................................................ 22 Tabelle 12: Anz. Flow Tables ................................................................................................................................................................... 27 Tabelle 13: Rest DELETE Methoden ..................................................................................................................................................... 36 Tabelle 14: Rest GET Methoden .............................................................................................................................................................. 37 Tabelle 15: Brocade SDN Apps ............................................................................................................................................................... 39 Tabelle 16: HP SDN Apps ........................................................................................................................................................................... 39 Tabelle 17: Sonstige SDN Apps ............................................................................................................................................................... 40

Hochschule Luzern Bericht - Begriffe und Abkürzungen Technik & Architektur

1

1 Begriffe und Abkürzungen Begriff Erklärung Hypervisor Anbieter eine abstrahierten Hardware Schicht, für den Betrieb von

virtuellen Maschinen Layer Layer bezeichnet eine Schicht gemäss dem Open Systems

Interconnection Model kurz OSI-Modell Loops Schlaufe Node Knotenpunkt OpenDaylight OpenSource SDN Controller OpenFlow Kommunikationsprotokoll zwischen Netzwerkgeräten und SDN

Controller Policy Richtlinie Raspberry Pi Günstiger Einplatinencomputer Skype for Business

Anwendung von Microsoft für kollaboratives Arbeiten, IP-Telefonie und Videokonferenzen

Traceroute Programm zur Ermittlung von Netzwerkrouten Ubuntu Weitverbreitetes OpenSource Betriebssystem VirtualBox Virtualisierungssoftware von Oracle vRealize Cloud Management Plattform von VMware Wireshark Programm zur Analyse von Netzwerkverkehr auf Paketebene Tabelle 1: Begriffsdefinitionen

Abkürzung Erklärung ACI Application Centric Infrastructure ACL Access Control List ADN Application-Defined Network API Application Programming Interface ARP Address Resolution Protocol BGP Border Gateway Protocol BYOD Bring your own Device CPU Central Processing Unit DDoS Distributed Denial of Service DHCP Dynamic Host Configuration Protocol DLUX OpenDaylight User Interface DMZ Demilitarisierte Zone DNS Domain Name System DSCP Differentiated services code point EIGRP Enhanced Interior Gateway Routing Protocol GUI Graphical User Interface HP Hewlett Packard HTTP Hypertext Transfer Protocol ICMP Internet Control Message Protocol IETF Internet Engineering Task Force IP Internet Protocol JSON JavaScript Object Notation KVM Kernel-based Virtual Machine LLDP Link Layer Discovery Protocol MAC Media Access Control

Hochschule Luzern Bericht - Begriffe und Abkürzungen Technik & Architektur

2

MPLS Multiprotocol Label Switching NetIDE Network Integrated Development Environment NFV Network function virtualization ODL OpenDaylight ONF Open Networking Foundation OSPF Open Shortest Path First QoS Quality of Service REST Representational State Transfer RIP Routing Information Protocol SCP Secure Copy SCTP Stream Control Transmission Protocol SDN Software Defined Network SNMP Simple Network Management Protocol SSH Secure Shell STP Spanning Tree Protocol TCP Transmission Control Protocol TTL Time to Live UDP User Datagram Protocol UI Userinterface URL Uniform Resource Locator VDS vSphere Distributed Switch VLAN Virtual Local Area Network VPN Virtual Private Network VTN Virtual Tenant Network WAN Wide Area Network WLAN Wireless Local Area Network XML Extensible Markup Language Tabelle 2: Abkürzungsdefinitionen

Hochschule Luzern Bericht - Einführung SDN Technik & Architektur

3

2 Einführung SDN

2.1 Problematik Virtualisierung und Cloud-Computing haben die Welt der IT verändert. Daten, Speicherplatz und Anwendungen jeder Art sind in der Cloud jederzeit und von jedem Ort aus abrufbar. Virtualisierung sorgt für die bessere Auslastung von Servern und Computern. Doch in der Praxis hapert es bei einigen Rechenzentren noch gewaltig. Die Netzwerke, dessen grundsätzlichen Strukturen noch aus den frühen 90er Jahren stammen, sind der grossen Datenflut schlichtweg nicht gewachsen und haben oftmals hohe Ausfallzeiten oder zumindest einen grossen Wartungsaufwand. [1] Die wichtigsten Probleme, denen klassische Netzwerke nicht mehr gewachsen sind, sind Folgende: [2]

• Verändertes Nutzerverhalten und grössere Bandbreiten Klassische Netzwerke sind starr und wurden für Client-Server Verbindungen konzipiert, die für eine bestimmte Zeit aufgebaut werden und anschliessend wieder getrennt werden. Moderne Anwendungen greifen gleichzeitig auf verschiedene Server zu, um Dienste zu nutzen. Zudem möchte der Nutzer von überall auf der Welt jederzeit auf Daten und Dienste zugreifen können. Um diese Bedürfnisse zu befriedigen, muss das Netzwerk flexibel werden und fähig sein, sich in Echtzeit an das Nutzerverhalten anzupassen.

• Komplexität und Verwaltbarkeit Die zunehmende Anzahl der Hosts in den, meist historisch gewachsenen, Netzwerken führt zu einer hohen Komplexität bei der Verwaltung. Durch die zunehmende Server-Virtualisierung vervielfacht sich zusätzlich die Anzahl der virtuellen Hosts.

• Abhängigkeit von den Geräteherstellern Hersteller von Switches oder Routern bieten oft zentrale Verwaltungsmöglichkeiten für ihre Geräte an. Diese funktionieren jedoch nicht herstellerübergreifend, wodurch man von einem bestimmten Hersteller, dessen Support und dessen Produktzyklen abhängig ist.

• Skalierungs- und Anpassungsmöglichkeiten Durch «On-Demand» Geschäftsmodelle muss sich das Netzwerk ebenfalls «On-Demand» an die Anforderungen anpassen können.

Software Defined Networking (SDN) will diese Probleme der klassischen Netzwerke nun lösen und verändert das Netzwerk-Management grundlegend.

2.2 Konzept SDN steht für Software Defined Networking und die Idee dahinter ist es, die Intelligenz des Netzwerks von der Hardware zu lösen und an einem zentralen Ort zu verwalten. Es ist sozusagen die Virtualisierung des Netzwerkes. Die sogenannte Control Plane, die Kontrollebene, wird von der Data Plane, also der Ebene, auf der die Daten bewegt werden, losgelöst. Zu dieser Ebene zählen unter anderen auch Switches oder Router. Zur Steuerung des Data Plane verwendet das Control Plane ein Kontrollprotokoll. Oberhalb


4

des Control Plane findet sich dann das Application Plane, auf welchem die Applikationen laufen.

Abbildung 1: Funktionsprinzip von SDN [3]

2.2.1 Application Plane Auf dem Application Plane laufen diejenigen Anwendungen, welche über die Northbound API mit dem Control Plane kommunizieren, um dieser Anweisungen zu geben, wie die Pakete über das Netzwerk geroutet werden sollen.

2.2.2 Control Plane Der Control Plane (Kontrollebene) ist zuständig für die Konfiguration eines Switches bzw. Routers und dieser übernimmt auch das Programmieren der Pfade (Flows), über welche die Daten transportiert werden. In der Kontrollebene wurden bisher komplexe Routingprotokolle wie OSPF, RIP oder BGP benötigt, um die jeweils aktuell besten Routen für jede Adresse zu bestimmen.

2.2.3 Data Plane Wie bereits erwähnt, wird das Routing im Control Plane ausgeführt. Das Switching und die Paketweiterleitung findet im Data Plane (auch Forwarding-Plane genannt) statt. Auf dieser Ebene wird der Datenverkehr im Netzwerkes übertragen. Der Data Plane unterstützt den Datentransfer von und zu den Clients, auf ihm werden die verschiedensten Protokolle abgewickelt und die Konversation mit entfernten Peers verwaltet. [4]


5

2.3 Änderungen Bei Software Definierten Netzwerken hat sich die Netzwerkarchitektur im Gegensatz zu herkömmlichen Netzwerken grundlegend verändert. Die wichtigste Änderung in diesem Bereich ist, dass die Control Plane von der Hardware gelöst wird und an eine zentrale Stelle ausgelagert wird.

2.3.1 Herkömmliche Netzwerke Die wesentlichen Komponenten in klassischen Netzwerken sind Switches und Router. Deren Hauptaufgabe ist es, eingehende Datenpakete, anhand der momentan verfügbaren Informationen, so schnell wie möglich an die richtige Adresse weiterzuleiten. Hierzu können die Netzwerkadministratoren die Geräte nach bestimmten Kriterien konfigurieren. Dies muss jedoch oft von Hand über unkomfortable Managementschnittstellen gemacht werden. Dadurch werden grosse Netze oft unflexibel und pflegeaufwendig. Bei diesen herkömmlichen Netzwerken befindet sich die Control- und Data Plane auf derselben Hardware (z.B. Router, Switch). [5]

2.3.2 Netzwerke mit SDN Der Sinn von SDN ist es, dieses Planes voneinander zu entkoppeln und die Control Plane an einen zentralen Controller zu übergeben. Dieser Controller ist eine Software, welche auf einem Server im Netzwerk läuft. Der Controller kommuniziert über standardisierte Schnittstellen mit Netzwerkkomponenten verschiedenster Hersteller. Er gibt ihnen direkte Anweisungen, wie bestimmte Datenströme individuell zu behandeln sind. Somit kann der Administrator die Vorgaben der Switches in Bezug auf die Priorisierung oder dem Herausfiltern von bestimmten Datenpaketen ändern. Dadurch lässt sich das Netzwerk besser verwalten und ist insgesamt anpassungsfähiger. [6] Eine weitere mit SDN verbundene Idee ist es, dass Applikationen über APIs direkt mit der Kontrollebene kommunizieren und dieser sozusagen ihre Anliegen und Bedürfnisse mitteilen. Dadurch entsteht ein sogenanntes «Application-Defined Network». Dies erlaubt eine weitere Automatisierung, so dass Änderungen in der Applikationslandschaft und das Ausrollen neuer Applikationen und Services theoretisch viel schneller und einfacher vorgenommen werden können als bisher. [7]

Abbildung 2: Verteile und zentrale Control Plane [8]


6

2.4 Versprechen SDN soll die Lösung aller Probleme im Netzwerkbereich sein. So sagen es zumindest die Marketingversprechen. Mit SDN sei das Netzwerk nicht nur skalierbar, flexibel und liesse sich dynamisch an neue Anforderungen anpassen. Es wäre auch die optimale Grundlage für Cloud-Computing und böte die Möglichkeit, das Potenzial von Virtualisierung voll auszuschöpfen. Netzwerke wären planbarer, passten sich schneller an die Anforderungen im Unternehmen an, verursachen weniger Kosten und bräuchten weniger Strom. Ein weiterer Vorteil wäre die Automatisierung: Das Netzwerk wäre einfacher zu verwalten und die Hardware müsste nicht mehr manuell konfiguriert werden, der gesamte Datenverkehr im Netzwerk würde zentral steuerbar. [6] Folgend sind die wichtigsten der angepriesenen Fähigkeiten aufgelistet [9]:

• Beim Controller handelt es sich um kein herstellerspezifisches, geschlossenes System. Netzadministratoren können darauf zugreifen und den Controller programmieren.

• Die eingesetzte Hardware (Switch, Router) ist unabhängig vom Hersteller und

Geräte können beliebig kombiniert werden. Zudem können erhebliche Kosten für die Erneuerung von Switches eingespart werden, da die eigene Software auf den Switches gegebenenfalls aktualisiert oder angepasst werden kann, ohne dass neue Hardware gekauft werden muss.

• Unterschiedliche Netzsysteme lassen sich von einer zentralen Stelle aus steuern, von physischen Switches und Routern bis hin zu virtualisierten Switches, WLAN-Access-Points und WAN-Optimierungssystemen.

• Anwendungen und neue Netzdienste können innerhalb von Stunden

bereitgestellt werden. Derzeit erfordert dies oft mehrere Tage oder gar Monate.

• Bei SDN lassen sich über Einträge in Flow Tables auch Dienste und Eigenschaften konfigurieren, bei denen das in herkömmlichen Netzen nicht mittels Scripts möglich ist, etwa Quality-of-Service-Merkmale und VLAN-Einstellungen.

• Servicedefinitionen müssen nicht mehr auf physikalische Netz-Ports "gemappt"

werden. Das verringert den Konfigurationsaufwand.

• Der Controller vermittelt dem Administrator eine "ganzheitliche" Sicht auf die Anwendungen, Netzelemente und Datenströme (Flows).

• Bandbreite kann dynamisch Anwendungen oder Nutzern zugewiesen werden

und das Netzwerk kann selbstständig Engpässe erkennen und darauf reagieren.

• Auf Attacken von aussen kann schnell und proaktiv reagiert werden (z.B. DDoS).

• Bestehende Geräte wie Firewall oder Flow Optimizer könnten durch den Einsatz von SDN Applikationen abgelöst werden.


7

2.5 Risiken und Herausforderungen SDN erfreut sich momentan grosser Beliebtheit. Jedoch sollte man dabei die Netzwerksicherheit nicht vergessen. Der SDN-Controller kann ein primäres Angriffsziel für Cyberkriminelle sein. Zum einen ist er der zentrale Knoten für den Datenfluss und zum anderen ein einzelner Ausfallpunkt (Single Point of Failure). Sollte ein Angreifer erfolgreich die Kontrolle über einen Controller übernehmen, könnte dieser das gesamte Netzwerk nach Belieben umprogrammieren. Dadurch könnte dieser das Netzwerk lahmlegen, Daten extrahieren oder an einer Stelle speichern, an der sich diese weiter analysieren lassen. [10]

Dasselbe gilt für kompromittierte Applikationen, da diese über APIs direkt mit der Kontrollebene (bzw. dem Controller) kommunizieren können, um diesem ihre Anliegen und Bedürfnisse mitzuteilen. Mit genug Fachwissen über die gutartigen Applikationen, die auf dem Controller laufen, könnte ein Cyberkrimineller das Netzwerk etwas komplett Unerwartetes tun lassen und so Schaden anrichten. [10]

2.6 Warum SDN? Was ist nun der Nutzen, wenn man von einer verteilten Control Plane zu einem zentralisierten umstellt. Der grösste Vorteil hierbei ist sicher, dass die Weiterleitungsentscheidungen global über die gesamte SDN Domäne gemacht werden können anstatt auf jedem Knoten einzeln. Zum Beispiel stelle man sich eine Layer 2 Switching Topologie mit redundanten Pfaden vor. Normalerweise muss hier das Spanning Tree Protokoll schauen, dass keine Loops entstehen da kein einzelner Switch weiss, wie das gesamte Netzwerk aussieht. Wird die Control Plane Funktion nun für alle Switches an einen zentralen Controller ausgelagert, kann dieser Controller das gesamte Netzwerk «sehen» und somit Weiterleitungsentscheidungen an jeden untergeordneten Switch senden, basieren auf den gewünschten End-zu-End Pfaden für jede Destination. [11]

Abbildung 3: zentraler Controller [11] Ein anderer Vorteil eines zentralen Controllers ist, dass wir eine Programmierschnittstelle haben die es anderen Anwendungen ermöglichen, Netzwerkressourcen zu steuern und Weiterleitungsentscheidungen zu beeinflussen. Wird zum Beispiel eine virtuelle Maschine von einem physikalischen Host zu einem


8

anderen verschoben, kann der Controller automatisch instruiert werden, alle nötigen Firewall- oder QoS Richtlinien zusammen mit der virtuellen Maschine zu verschieben. Dadurch entfällt die Notwendigkeit für einen Administrator, statische Netzwerkressourcen neu zu konfigurieren und somit kann das gesamte Netzwerk flüssiger betrieben werden. [11]

Beispiel 1 Ein Controller kann die Flow Table eines OpenFlow fähigen Switches bearbeiten. Dadurch kann man festlegen, welchen Weg der Datenverkehr zwischen zwei Hosts gehen soll. Wenn man möchte, dass alles vom Host X zum Host Y über einem bestimmten Weg gehen soll, erstellt man dazu auf dem Controller einfach einen spezifischen Flow und dieser weisst dann die Switches entsprechend, in dem dort die nötigen Flow Einträge gemacht werden.

Abbildung 4: Vordefinierte Wege [11]

Beispiel 2 Ein anderes Beispiel ist, falls eine Software auf dem Host X wichtige Daten an Host Y senden muss, kann diese Software über die API mit dem Controller kommunizieren und diesem dies mitteilen. Dadurch wird der Controller nun optimalerweise alle Knoten auf diesem Weg durchs Netzwerk anweisen, diesen Flow zu priorisieren und alle anderen Datenströme zu drosseln.

Abbildung 5: Priorisierung von Flows [11]


9

2.7 Application-Defined Network SDN wird oft im Zusammenhang mit «application defined networking» (ADN) erwähnt. Dies ist ein Netzwerkszenario, in welchem Anwendungen die Fähigkeit haben, Netzwerkumgebungen an ihre Bedürfnisse anzupassen, anstatt fixe Ressourcen durch das Netzwerk zugewiesen zu bekommen. Das ADN-Modell stützt sich auf Software Defined Networking, welches die dynamische Verwaltung von Netzwerkressourcen ermöglicht. Solche ADN fähigen Anwendungen können z.B. über die Entwicklungsumgebung NetIDE entwickelt werden.

2.7.1 NetIDE Das Projekt NetIDE zielt darauf ab, eine integrierte Entwicklungsumgebung (IDE) für den Entwicklungsprozess von Anwendungen im Bereich des Software Defined Networkings bereitzustellen, unabhängig vom Hersteller. Das Software Defined Networking Paradigma ermöglicht es Netzwerkgeräten formbar und fernsteuerbar zu sein, durch SDN Controller. Jedoch ist die aktuelle SDN Landschaft sehr fragmentiert. Viele offene und geschlossene Controller wie OpenDaylight, Ryu oder Floodlight existieren. Das portieren von SDN Anwendungen von einer solchen Plattform zu einer andere ist praktisch unmöglich und so müssen die Entwickler von Netzwerkanwendungen ihre Softwarelösungen für jede Plattform neu implementieren. Des Weiteren verwenden verschiedene Netzwerkentwickler verschiedene Lösungen als Control Plane Programmiersprache (z.B. Frenetic, Procera). Dies limitiert stark das Teilen von Code oder auch die Wiederverwendbarkeit. [12] NetIDE wird sich der oben genannten Problematik wie folgt widmen [13]:

• Entwurf einer Methode zur Entwicklung von SDN-Anwendungen. Darin eingeschlossen ist die Anforderungsanalyse, Design, Implementierung, Simulation und Test sowie das Deployment.

• Ermöglichung der plattformunabhängigen Programmierung mit beliebigen Netzwerk-Programmiersprachen. Dazu werden Transformationen spezifiziert, die die Programme in ein einheitliches, plattformunabhängiges Format überführen. Daraus wird schliesslich plattformspezifischer Code generiert, der auf entsprechenden Controllern ausführbar ist.

• Entwicklung einer Network App Engine, die SDN-spezifische Debug-

Informationen und Performance-Evaluationen generiert und zur Verfügung stellt. Garbage Collection im SDN-Kontext gehört ebenfalls zu den Aufgaben dieser Engine

Hochschule Luzern Bericht - Openflow Technik & Architektur

10

3 Openflow OpenFlow ist ein weit verbreitetes, offenes Protokoll, das zur Kommunikation von SDN-fähigen Switches/Router mit den SDN-Controllern verwendet wird. Grundidee ist die Spezifikation von sogenannten “Flow Tables”, welche Pakete anhand von “Matching Rules” bestimmten Flows zuordnen und für diese Flows die weitere Verarbeitung festlegen. Dies kann beispielsweise eine Weiterleitung auf einen bestimmten Ausgangsport, das Verwerfen von Paketen oder die Weiterleitung zum Controller sein. [14]

Abbildung 6: OpenFlow Protokoll [15]

3.1 Geschichte OpenFlow wurde ursprünglich von der Universität Stanford entwickelt und im Jahr 2009 veröffentlicht. Ab Version 1.1 hat die Open Networking Foundation (ONF) die Veröffentlichung und Standardisierung von OpenFlow übernommen. Aktuell ist Version 1.5. Mittlerweile wird OpenFlow von einer Vielzahl von Switch-Herstellern unterstützt, allerdings oft nicht in den aktuellsten Versionen oder nicht mit allen Erweiterungen. [14]

3.2 Produkthersteller Um OpenFlow auf einem Switch/Router verwenden zu können, muss dies auch entsprechend auf dem Betriebssystem implementiert sein. Hierfür stellen verschiedene Hersteller entsprechende Hardware mit dem dafür notwendigen Betriebssystem zur Verfügung. Je nach Gerät werden verschiedene OpenFlow Version unterstützt. Folgende Hersteller bieten entsprechende Hardware an [16]:

• A10 Networks • ADVA Optical Networking • Brocade • Centec Networks • Extreme Networks • Hewlett-Packard • IBM • Infinera • Intune Networks • NEC • Pica8 • Plexxi


11

Da die Anforderungen an die Hardware mittels Abstraktion in Control und Data Plane weniger hoch sind, bieten einige Hersteller sogenannte Bare-Metal Switches an, die dann mit einem entsprechenden Netzwerkbetriebssystem ausgestattet werden können. Folgende Hersteller bieten entsprechende Bare-Metal Switches an:

• Accton • Agema • Alpha Networks • Dell • Edge-Core • Netberg • Penguin • Quanta

Entsprechende Netzwerkbetriebssysteme für die Installation auf einem Bare-Metal Switch sind:

• PicOS • Cumulus Linux • Switch Light • Open Network Linux • Open Switch

Ebenfalls ist es möglich Switches und Router auch als virtuelle Maschinen zu betreiben, hierfür sind folgende Produkte bekannt:

• Open vSwitch • Open Switch • Indigo

3.2.1 Open vSwitch Open vSwitch ist ein virtueller Switch, der als Open Source entwickelt wird und auf dem Openflow-Projekt basiert. Es ist die Standard-Option für die meisten Linux-basierten Hypervisoren. Weil es der Standard für sowohl KVM als auch Xen ist, finden Sie die Technologie praktisch in jeder OpenStack-Installation. Open vSwitch verwendet man auch in VMware NSX-Umgebungen. [17] Open vSwitch hat einen umfassenden Funktionsumfang, der dem physischen Switch nahe kommt. Folgende Funktionen seien exemplarisch genannt [18]:

• Standard 802.1Q VLANs mit Trunk und Access-Ports • Spanning Tree Protocol (STP) nach IEEE 802.1D-1998 • Unterstützung von NetFlow, sFlow, SPAN, RSPAN und GRE-getunnelten Mirror-

Ports • OpenFlow-Unterstützung • NIC-Bonding mit Source-MAC Load Balancing, Active Backup und L4 Hashing • Link Aggregation Control Protocol (LACP) nach IEEE 802.3ad • Tunneling-Protokolle (Ethernet-overGRE, CAPWAP, IPsec, GRE-over-IPsec) • Quality of Service (QoS), Hierarchical Fair Service Curve (HFSC) • Continuous Controls Monitoring (CCM) von Links nach IEEE 802.1ag • IPv6-Support.


12

3.3 Spezifikation Trifft ein Paket in einem Open-Flow-Netzwerk auf einem für Open Flow reservierten Ports ein, untersucht der Switch, wie in der jeweiligen Spezifikation beschrieben, das Header Field (Abbildung 7: Regel mit Header, Actions und Stats). 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. [19]

Abbildung 7: Regel mit Header, Actions und Stats [15]

Als Aktionen kann er das Paket zum Beispiel an einen Port weiterleiten, dessen Header-Feld modifizieren oder es an eine andere Flow Table weiterleiten. 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 [19]. Je nach Hersteller und Konfiguration des Switches, können Pakete, welche keinen passenden Flow Eintrag haben, standardmässig aber auch anders behandelt, z.B. verworfen werden. Es gibt zwei Arten von Flow Einträgen, proaktive und reaktive. Bei proaktiven Flow Einträgen erstellt der Controller für einen Switch in dessen Flow Table einen Eintrag, ohne dass ihn der Switch darum gebeten hat. Bei reaktiven Einträgen empfängt der Switch ein Paket, welches er keinem Flow zuordnen kann und sendet dieses deshalb an den Controller weiter. Dieser erzeugt dann als Reaktion darauf einen passenden Flow Eintrag für das unbekannte Paket und schreibt dieses in die Flow Table des Switches. Hat ein Switch einen Flow Eintrag 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 Einträgen verzögert hingegen der Controller die Weiterleitung durch zusätzliche Kommunikation und das Warten auf Entscheidungen zur Paketbehandlung. [19]


13

3.3.1 Flows Flows werden in der Flow Table abgebildet und beinhalten folgende Komponenten [20]:

Match Fields Priority Counters Instructions Timeouts Cookie Flags

Match Fields: Pakete werden auf basierend auf den hier eingetragenen Kriterien verglichen, wenn die Kriterien übereinstimmen, so wird dieser Flow Table Eintrag für das entsprechende Paket verarbeitet. Priority: Legt fest, mit welcher Priorität dieser Flow Table Eintrag mit dem zu verarbeitenden Paket verglichen wird. Würde also ein Paket die Match Fields Kriterien mehrere Flow Table Einträge erfüllen, so wird nur jener Eintrag verarbeitet, der die höchste Priorität aufweist. Counters: Wird aktualisiert, sobald ein Paket die Match Fields Kriterien erfüllt hat. Instructions: Definiert wie mit dem Paket weiter vorgegangen werden soll. Timeouts: Hierbei wird definiert wie lange ein Flow Table Eintrag in der Flow Table eingetragen sein soll, respektive wann dieser gelöscht werden kann. Cookie: Hat keinen Einfluss auf die Paket Verarbeitung und wird vom SDN Controller gesetzt, modifiziert oder gelöscht. Flags: Je nachdem wie Flows administriert werden, kann über ein Flag beispielsweise definiert werden, das der SDN Controller informiert werden soll, wenn ein Eintrag in der Flow Table vom Switch gelöscht wird, beispielsweise, wenn ein Timeout zutrifft.

3.3.1.1 Match Fields Pakete können auf unterschiedlichste Kriterien überprüft werden. Kriterium Erklärung Beispiel Ingress Port Auf welchem Port kam das Paket

rein? 1/0/1 - Switch Port

Source MAC Wie lautet die Absender MAC Adresse?

b8:27:eb:4c:43:92 mit Maske ff:ff:ff:ff:ff:ff

Destination MAC Wie lautet die adressierte MAC Adresse?

b8:27:eb:4c:43:92 mit Maske ff:ff:ff:ff:ff:ff

VLAN ID Present? Ist das Paket VLAN getaggt? True oder false VLAN ID Welches VLAN wurde im Paket

getaggt? 0-4095

VLAN Priority Wie hoch ist die VLAN Priorität? 0-7 Ethernet Type Welchem Ethernet Type entspricht

das Paket? 0x0800 für IPv4 0x0806 für ARP 0x86DD für IPv6 0x88CC für LLDP 0x8906 für FCoE

Source IP Wie lautet die Absender IP Adresse? 192.168.10.1/32 oder 192.168.10.0/24 für ein Subnetz


14

Destination IP Wie lautet die adressierte IP Adresse?

192.168.10.2/32 oder 192.168.10.0/24 für ein Subnetz

IP Protocol Welchem IP Protokoll entspricht das Paket?

6 für TCP 17 für UDP 132 für SCTP

IP DSCP Mit welcher Priorität ist das Paket klassifiziert?

0 - 63

Source Port Wie lautet der Absender Port? 0-65535 Destination Port Wie lautet der adressierte Port? 0-65535 Tabelle 3: OpenFlow Match Fields

3.3.1.2 Instructions Instruction Erklärung Beispiel Controller Sendet das Paket an den Controller - Drop Verwirft das Paket - Flood Leitet das Paket an alle Ports weiter - Dec NW TTL Verringert die TTL des Pakets - Group Lässt das Paket durch die Group Table

weiterverarbeiten Group 1

Normal Das Paket soll gemäss der normalen Switchkonfiguration (ohne OpenFlow) verarbeitet werden.

-

Output Leitet das Paket an einen gewissen Switch weiter.

1/0/1

Local Leitet das Paket an den lokalen Switch Netzwerk Stack und dessen Management Stack weiter

-

Push VLAN Fügt dem Paket einen VLAN Tag hinzu Ethernet Type 0x8100 oder QinQ 0x88a8 Mit VLAN 0-4095

Pop VLAN Entnimmt dem Paket den VLAN Tag - Push MPLS Fügt dem Pack ein MPLS Label hinzu 0-1048575 Pop MPLS Entnimmt dem Paket das MPLS Label - Set Field Kann diverse Paket Header Felder

ändern wie: • Ethernet Type • Source Mac • Destination Mac • VLAN ID • VLAN Priority • IPv4 Source • IPv4 Destination • IPv6 Source • IPv6 Destination • IP Protocol • IP DSCP • TCP Source • TCP Destination

-


15

• UDP Source • UDP Destination • SCTP Source • SCTP Destination

Tabelle 4: OpenFlow Instructions

3.3.2 Groups Groups werden in der sogenannten Group Table hinterlegt, und beinhalten Einträge mit folgenden Komponenten [20]:

Group Identifier Group Type Counters Action Buckets Group Identifier: Ist ein 32 Bit langer Integer für die eindeutige Identifizierung einer Group. Group Type: Definiert, um welchen Typ der Group es sich bei dieser Group handelt. Counters: Wird aktualisiert, sobald ein Paket von dieser Group verarbeitet wird. Action Buckets: Beinhaltet eine geordnete Liste von Actions, die in dieser Gruppe ausgeführt werden können.

3.3.2.1 Group Types All: Beim Group Type all, werden alle Action Buckets der Gruppe ausgeführt, was beispielsweise für Multicast oder Broadcast eingesetzt werden kann. Dabei wird das zu verarbeitende Paket für jeden Bucket geklont, und entsprechend jedem Action Bucket prozessiert. Select: Beim Group Type select, wird nur ein Action Bucket ausgeführt, welches auf einem durch Switch errechneten Algorithmus entschieden wird, wie beispielsweise Round Robin oder Ähnlichem. Dem Algorithmus kann bereits mit der Gewichtung der Actions Buckets ein weiterer Input zur Verfügung gestellt werden. Indirect: Beim Group Type Indirect existiert nur ein Action Bucket. Dies ermöglicht es, mehreren Flows, die die gleiche Action definiert haben, diese an nur einem Ort zu führen. Falls nun beispielsweise der Output Port von mehreren Flows geändert werden müsste, so ist dies nur auf der Group zu ändern, und nicht in jedem einzelnen Flow. Fast Failover: Beim Group Type Fast Failover wird nur der erste funktionierende Action Bucket ausgeführt. Jeder Action Bucket ist mit einem Port und oder einer Group verbunden, und überprüft deren Funktionalität. Dies ermöglicht es einem Switch, Ports die nicht mehr Funktionieren, nicht mehr zu verwenden und auf den Nächstbesten zu wechseln. Dieser Mechanismus funktioniert ohne, dass der SDN Controller dies feststellen muss.


16

3.3.2.2 Action Buckets Einem Action Bucket können folgende Informationen hinterlegt werden. Je nachdem welchem Group Type sie untergeordnet sind, sind nicht alle Informationen notwendig. Bucket ID: Eindeutige ID für den Action Bucket (1-32) Watch Group: Welche Group überwacht werden soll. Watch Port: Welcher Port überwacht werden soll. Weight: Gewichtung dieses Action Buckets. Actions: Actions die ausgeführt werden sollen. Diese entsprechen den Instructions für Flows, wie Output, Pop VLAN oder Set Field.

3.3.3 Meters Meters werden in der Meter Table geführt. Diese werden Flows zugewiesen und dadurch wird die Implementation von einfachen Quality of Service Operationen ermöglicht, wie die Bandbreitenbeschränkung. In Kombination mit einer portbasierten Queue ermöglicht es die Nutzung von komplexeren Quality of Service Frameworks wie DiffServ. [20]

Meter Identifier Meter Bands Counters Meter Identifier: Eindeutige ID für den Meter, der einem Flow hinterlegt werden kann. Meter Bands: Eine ungeordnete Liste von Meter Bands, welche spezifiziert werden durch die Bandbreite und was dabei geschehen soll. Counters: Wird aktualisiert, sobald ein Paket von diesem Meter verarbeitet wird. Die eigentlichen Meter Bands sind wie folgt aufgebaut:

Band Type Rate Counters Type specific arguments Band Type: Definiert, wie mit einem Paket umgegangen werden soll. Möglich sind zurzeit, dass Pakete verworfen werden oder dass sie eine Differentiated Services Code Point (DSCP) Kennzeichnung erhalten. Rate: Wird vom Meter verwendet um das zutreffende Meter Band auszuwählen. Es wird jenes Meter Band ausgewählt, welches die nächst tiefere Bandbreite aufweist, die im Moment tatsächlich genutzt wird. Counters: Wird aktualisiert, sobald ein Paket von diesem Meter Band verarbeitet wird. Type specific arguments: Hier können weitere Parameter mitgegeben werden, die für die Anwendung des entsprechenden Band Types notwendig sind.


17

3.4 Anwendungsmöglichkeiten von OpenFlow Mit Flows, Meters und Groups können verschiedenste Funktionen in einem herkömmlichen Netzwerk abgebildet werden, die bisher von dedizierter Hardware umgesetzt werden mussten. Im folgenden Kapitel werden einige Funktionen kurz erklärt und wie diese mit OpenFlow umgesetzt werden können.

3.4.1 vRouter Ein Router verbindet mehrere Netzwerke miteinander und leitet Pakete, basierend auf deren IP Adresse und der ihm bekannten Routingtabelle, an das entsprechende Netzwerkinterface. Dabei wird zusätzlich die TTL des Pakets verringert und die MAC Adressen des Ethernet Frames für die Verbindung zum nächsten Hop oder Endknoten gesetzt. An folgendem Beispiel soll die Kommunikation zwischen zwei Hosts in unterschiedlichen Netzwerksegmenten kurz erklärt werden.

Abbildung 8: vRouter

Der Host sendet ein Paket mit folgenden Informationen zum Switch: Source IP 192.168.10.2 Destination IP 192.168.11.2 Source MAC AA:AA:AA:AA:AA:AA Destination MAC AA:AA:AA:AA:AA:A1 TTL 128

Tabelle 5: vRouter Packet Host A - Switch

Der OpenFlow Switch wird dieses Paket nun auf Port 1 entgegennehmen und in seiner Flow Tabelle nach einem entsprechenden Flow suchen. Um die entsprechende Kommunikation sicherstellen zu können, wurde zuvor folgender Flow auf dem Switch hinterlegt:

Match Fields Source IP 192.168.10.0/24 Destination 192.168.11.2/32 Destination MAC AA:AA:AA:AA:AA:A1

Tabelle 6: Match Fields


18

Instructions Set Field Source MAC BB:BB:BB:BB:BB:B1 Set Field Destination MAC BB:BB:BB:BB:BB:BB Dec NW TTL Output Port 2

Tabelle 7: Instructions

Das Paket das vom OpenFlow Switch an Host B gesendet wird beinhaltet nun folgende Informationen:

Source IP 192.168.10.2 Destination IP 192.168.11.2 Source MAC BB:BB:BB:BB:BB:B1 Destination MAC BB:BB:BB:BB:BB:BB TTL 127

Tabelle 8: Packet Information

Für den Rückweg muss ebenfalls ein Flow auf dem OpenFlow Switch definiert werden, welcher wie folgt aussähe:

Match Fields Source IP 192.168.11.0/24 Destination 192.168.10.2/32 Destination MAC BB:BB:BB:BB:BB:B1

Tabelle 9: Match Fields

Instructions Set Field Source MAC AA:AA:AA:AA:AA:A1 Set Field Destination MAC AA:AA:AA:AA:AA:AA Dec NW TTL Output Port 1

Tabelle 10: Instructions

Funktionieren wird dieser Aufbau aber noch nicht, da ein Problem noch nicht gelöst ist, und zwar wie Host A resp. Host B die MAC Adresse des entsprechenden Default Gateways erhalten. Folgende Lösungsmöglichkeiten sind denkbar:

• Es existiert tatsächlich ein Router im Netzwerk, der auf entsprechende ARP Request reagiert und so den Hosts eine MAC Adresse mitteilt, damit ein Ethernet Frame gebildet werden kann.

• Es könnte ein Flow definiert werden, welcher ARP Requests, welche die IP-Adresse von dem Router ermitteln möchten, an den SDN Controller sendet, auf welchem wiederum eine Applikation läuft, die genau diese Pakete verarbeitet und eine entsprechende Antwort generiert. Dies existiert in dieser Form für den OpenDaylight SDN Controller aber noch nicht.

• Auf jedem Host werden statische ARP Einträge erstellt. Abschliessen kann gesagt werden, dass ein vRouter nur mit OpenFlow möglich wäre, dafür aber statische ARP Einträge auf Hosts gemacht werden müssten, was keinesfalls praktikabel wäre oder, dass mit der Verwendung des OpenDaylight SDN Controllers entsprechende Software selber geschrieben werden müsste. Zum jetzigen Zeitpunkt wäre einzig denkbar, dass ein mit OpenFlow umgesetzter Router einen wirklich existierenden Router entlasten könnte, indem die Funktionen des Routers mit OpenFlow umgesetzt werden.


19

Weitere Funktionen, die mit einem reinen OpenFlow Router nicht funktionieren würden, wären ICMP Pakete, die von einem OpenFlow Router nicht beantwortet werden könnten. Somit könnten keine Pings und Traceroute Befehle verwendet werden.

3.4.2 Firewall Eine Firewall beschränkt den Netzwerkverkehr, indem sie basierend auf festgelegten Regeln, die Absender, Zieladresse und Ports beinhalten können, Pakete zulässt oder verwirft. Damit OpenFlow Punkt zu Punkt Verbindungen erstellt werden können, die auf Absender, Zieladresse und Port basieren, kann die Funktion der Firewall durch OpenFlow übernommen werden. Der Nachteil einer Firewall auf OpenFlow Switch Ebene ist, dass diese nur Stateless ist. Das bedeutet jeweils ein Flow ausgehend wie eingehend definiert werden muss und dabei nicht unterschieden werden kann, von wo aus die Verbindung initialisiert wurde. Somit könnten beispielsweise ein Paket eingehend durch die Firewall durchgelassen werden, ohne dass dies von intern angefordert wurde. Damit eine Firewall Stateful mit SDN eingerichtet werden kann, gibt es bereits Ansätze. So wurde ein Paper von Jake Collings und Jun Liu mit dem Titel „An OpenFlow-based Prototype of SDN-Oriented Stateful Hardware Firewalls“ [21] im Jahr 2014 veröffentlicht, wie auch von Hongxin Hu, Wonkyu Han, Gail-Joon Ahn und Ziming Zhao mit dem Titel „FlowGuard: Building Robust Firewalls for Software-Defined Networks“ [22] aus dem Jahr 2014. Des Weiteren hat Google ein Patent im Jahr 2012 eintragen lassen mit dem Titel „Scalable stateful firewall design in openflow based networks“ mit der Veröffentlichungsnummer US8789135 B1.

3.4.3 Load Balancing Die Aufgabe eines Load Balancers die Verteilung von Netzwerk- oder Applikationsverkehr auf mehrere Server, welche die gleichen Services anbieten. Einerseits gibt es die Möglichkeit für einen Service einen Flow einzurichten, welche als Output eine Select Group hinterlegt hat, die wiederum die verschiedenen Server des entsprechenden Service hinterlegt hat. Dies hat den Nachteil, das auf dem Switch für jedes Paket entschieden wird, welcher Server erreicht werden soll, was für TCP Verbindungen nicht anwendbar ist. Andererseits ist es aber denkbar, dass wenn ein Host einen Service nutzen möchte, dessen erstes Paket an den SDN Controller gesendet wird, und danach explizit einen Flow zwischen Host und einem Server der Service definiert. Dass dies möglich ist, haben Hardeep Uppal und Dane Brandon der University of Washington in ihrer Arbeit mit dem Titel „OpenFlow Based Load Balancing“ [23] gezeigt. Dabei wurde in Performance Tests herausgefunden, dass das Ändern der Paket Headerinformationen auf den Switchen noch zu langsam funktioniert, als dass es für den produktiven Betrieb notwendig wäre. Die Masterarbeit von Richard Wang an der Princeton University aus dem 2011 mit dem Titel „OpenFlow-Based Load Balancing gone wild“ [24] hat gezeigt, das Load Balancing auch über mehrere Switches funktionieren, und mit einem minimalen Satz von Flows mit Wildcards, bereits eine gute Lastverteilung erreicht werden kann.

3.4.4 Bandbreitenbeschränkung Mit der Möglichkeit von Meters, die pro Flow definiert werden können, ist es möglich, dass Bandbreiten für einzelne Protokolle, Clients, Server und auch eine Kombination daraus eingerichtet werden können. Da die Bandbreite mittels OpenFlow dynamisch via SDN Controller geändert werden kann, ist es denkbar, dass Applikationen auf dem SDN Controller aufgebaut werden können, die einerseits die aktuelle Bandbreite mittels SNMP, sFlow oder OpenFlow


20

überwachen, und bei hoher Auslastung die Bandbreite von weniger wichtigen Services drosseln können. So ist es denkbar, dass beispielsweise während den Produktivzeiten eines Rechencenterbetriebs, ein Backup durchgeführt werden kann, dessen Bandbreitenbeschränkung regelmässig dem aktuellen Zustand des Netzwerks angepasst werden kann, sodass das Netzwerk immer nahezu 100% ausgelastet sein kann, ohne, dass der produktive Betrieb in irgendeiner Form gestört wird.

3.5 Alternativen zu OpenFlow

3.5.1 Cisco OpFlex OpFlex ist ein sogenanntes Southbound-Protokoll von Cisco, das auf den eigenen „Application Centric Infrastructure“-Produkten (ACI) basiert. Genau wie OpenFlow ist Ciscos OpFlex für die Kommunikation zwischen einem zentralen Controller und Netzwerk-Geräten erschaffen. Der Anwendungsbereich unterscheidet sich allerdings sehr. OpenFlow zentralisiert die Netzwerk-Steuerungsebene auf einem Controller, OpFlex-basiertes SDN zentralisiert lediglich die Policy-Kontrolle. Es baut auf traditionelle und verteilte Netzwerk-Kontrollprotokolle, um die restliche Aufgabe zu erledigen. Mit OpFlex gibt ein Controller Policy- und Konfigurations-Befehle an Netzwerk-Geräte weiter. Durch diese Form der Programmierbarkeit kann die Infrastruktur dynamisch reagieren und sich auf die Anforderungen der Applikationen anpassen. Dieses Protokoll ist für Ciscos ACI von zentraler Bedeutung, da es von proprietären Switches mit verteilter Intelligenz und zentralisierter Policy-Kontrolle abhängt. Andere SDN Strategien gehen einen Weg, der mehr auf Software ausgerichtet ist, wodurch die komplette Steuerungs-Schicht in einem zentralen Controller liegt. Dieser kommuniziert mit dem Netzwerk über einfache, handelsübliche Switches. Cisco will OpFlex für eine Standardisierung bei der Internet Engineering Task Force (IETF) einreichen, somit würde das Protokoll öffentlich zugänglich und liesse sich von der gesamten Branche nutzen. Darüber hinaus arbeitet Cisco an einem Projekt mit dem OpenDaylight-Konsortium, das sich Group Policy Initiative nennt. Die OpFlex-Controller könnten damit die Policy-Kontrolle auf jede Anbieter-Plattform ausweiten, die das Protokoll unterstützt. Midokura und Plexxi beispielsweise sind in diesem Projekt involviert. [25]

Hochschule Luzern Bericht - Controller Technik & Architektur

21

4 Controller

4.1 Funktionen In Software Definierten Netzwerken werden die Pfade durch die Benützung eines Kontrollprotokolls definiert. Wenn ein Client versucht, mit einem anderen Host zu kommunizieren, wird das erste Paket dazu benutzt, um zu entscheiden, ob der Switch selbstständig eine Weiterleitungsentscheidung treffen kann oder ob er den Controller fragen soll, was zu tun ist. Die Kommunikation zwischen dem Switch und dem Controller läuft über das Kontrollprotokoll über einen gesicherten Kanal. Basierend auf seinen Policies, entscheidet der Controller, ob der Datenfluss zugelassen werden soll oder nicht. Sollte der Controller den Datenverkehr zulassen, wird dies in seiner Verbindungstabelle eingetragen. Dadurch kann der Controller den Switches Anweisung geben, welches der beste Pfad für die Daten durchs Netzwerk ist. Die Switches können anschliessen dem Controller mitteilen, ob der Datenfluss noch aktiv ist oder nicht. Der SDN Controller bietet je nach Hersteller unterschiedlichste Funktionen an, die auf das entsprechende Anwendungsgebiet zugeschnitten sind. Die zentrale Funktion eines SDN Controllers ist das zur Verfügung stellen von Schnittstellen. Einerseits benötigt der SDN Controller entsprechende Southbound Interfaces um Geräte wie Switches, Router und weitere SDN-fähigen Geräten entsprechend konfigurieren zu können. Andererseits muss der SDN Controller auch Northbound Interfaces anbieten, damit ein Benutzer sein Netzwerk konfigurieren kann. Zwischen North- und Southbound Interfaces muss der SDN Controller entsprechende Befehle übersetzen, und kann darin entsprechende Kontroll- und Sicherheitsmechanismen einbauen. Je nachdem wie OpenFlow genutzt wird, ist es notwendig, dass der SDN Controller stets zur Verfügung steht, damit das Netzwerk einwandfrei funktioniert. Deshalb sollte es möglich sein, dass der SDN Controller redundant, beispielsweise als Cluster, zur Verfügung gestellt werden kann. Da ein SDN Controller sämtliche Netzwerkkomponenten verwalten kann, kann er mit böswilliger Absicht die komplette Netzwerkinfrastruktur eines Unternehmens lahmlegen. Deshalb ist es zwingend notwendig, dass alle relevanten Northbound APIs durch einen Authentifizierungs- und Authorisierungsmechanismus geschützt sind.

4.2 Marktübersicht Name

Kom

mer

ziel

l

Southbound Protokolle

Ope

nFlo

w

OVS

DB

NET

CON

F

BGP

OPF

lex

Agility J J J J J N Avaya SDN Fx Controller J J J J J N BEEM Controller N J J J N N Big Bloud Fabric J J N N N N Brocade SDN Controller J J J J J N Cisco ACI J N N N N J Cisco Virtual Topology System J N N J N N ContexNet 4.0 J J N N N N


22

Contrail (Juniper) J N J J J N Cyan Planet Operate J J J J J N Ericsson SDN Controller J J J J J N HP VAN SDN Controller J J N J N N Inocybes’s OpenDaylight Distribution J J J J J N Loom N J N J N N NEC ProgrammableFlow Networking Suite J J N N N N NOX N J N N N N NSX Virtual Network Platform J J J J J N Nuage Networks VSP J J J N J N OneController J J J J N N Open Network Operating System N J N N J N OpenContrail N J J J J N OpenDaylight N J J J J N Pox N J J N N N Ryu N J J J J N Sonus NaaS IQ J J N J N N Transcend SDN Transport Controller J N N J N N Trema N J N N N N Tabelle 11: Marktübersicht [26]

4.3 Schnittstellen In SDN gibt es die unterschiedlichsten Schnittstellen und Protokolle, die verwendet werden. Grundsätzlich lassen sich diese aber in zwei Gruppen unterteilen. Davon ausgehend, dass der SDN Controller das zentrale Element einer SDN Architektur bildet, wird die ganze Kommunikation nach unten mit den physikalischen und virtuellen Switches als Southbound Interface bezeichnet. Alles oberhalb des SDN Controllers, die Schnittstelle zu den Applikationen, wird als Northbound Interface bezeichnet.

Abbildung 9: Schnittstellen [27]


23

4.3.1 Northbound Das Northbound Application Programming Interface ist die zentrale Schnittstelle, die es einem Service ermöglicht SDN zu nutzen. Das Ziel der Northbound API ist die Abstraktion des Netzwerks, sodass Applikationsentwickler ihre Anforderungen für die Applikation ans Netzwerk auf einfache Weise über die Schnittstelle übermitteln können und diese dann entsprechend auf dem SDN Controller umgesetzt werden ohne, dass der Entwickler wissen muss, was dies genau für jedes einzelne Netzwerkgerät bedeutet. Einerseits wird das Northbound API für die Plattformen, die zur Automatisierung verwendet werden, eingesetzt, wie Puppet, Chef, SaltStack, Ansible und CFEngine, anderseits auch für Orchestrierungsplattformen wie OpenStack, VMware vCloudDirector oder CloudStack. Eine Herausforderung bezüglich der Northbound API ist deren Standardisierung. Wie in einer Seminararbeit von Christian Fuchs an der Technischen Universität München mit dem Titel «Northbound API Requirements for SDN» [28] beschrieben wird. Darin wurde festgehalten, dass die Anwendungsgebiete von SDN sehr vielseitig sind und dies durch verschiedene Controller Frameworks auf dem SDN Controller ermöglicht wird, welche jeweils über unterschiedliche APIs verfügen. Eine Vielzahl an Akteuren in Forschung, Entwicklung und dem freien Mark, wovon jeder unterschiedliche Interessen, Vorstellungen und Vision über die Zukunft von SDN vertritt, erschwert die Standardisierung enorm. Aktuell ist der von Software geprägt Markt am Northbound Interface sehr dynamisch und verändert sich ständig mit den neuen Anforderungen, was im Widerspruch zu langjährigen Standardisierungsprozessen steht. Eine Standarisierung ist also erst möglich, sobald klar ist wohin die Reise mit SDN geht und jeder beteiligte Akteur das gleiche Verständnis aufweist.

4.3.2 Southbound Das Southbound Interface eines SDN Controller ist jene Schnittstelle, welche die Kommunikation mit Netzwerkgeräten ermöglicht. Typische Southbound Interfaces sind folgende:

• OpenFlow – Kommunikationsprotokoll mit Zugriff auf die Forwarding Plane eines Switches oder Routers über das Netzwerk

• OVSDB – Open vSwitch Database Protokoll für Manipulation von Konfiguration auf Open vSwitches

• OF-Config – OpenFlow Management and Configuration Protocol ermöglicht die Remotekonfiguration von OpenFlow Datapaths

• NETCONF – Network Configuration Protocol ermöglicht die Installation, Manipulation und Löschung von Konfigurationen von Netzwerkgeräten.

• LISP – Locator/ID Separation Protocol ermöglicht die Trennung einer IP Adresse in eine Identität und eine Lokation.

• BGP – Border Gateway Protocol ist ein Routingprotokoll für die Verbindung zwischen mehreren autonomen Systemen, wie unterschiedliche Internetdienstanbieter

• PCEP – Path Computation Element Protocol kann Pfade im Netzwerk berechnen, basierend auf einer kompletten Netzwerkübersicht und der aktuellen Auslastung

• CAPWAP – Control and Provisioning of Wireless Access Points steuert und richtet Access Points zentral ein.

• OPFLEX – Alternative von Cisco zu OpenFlow ermöglicht die Kommunikation zwischen SDN Controller und Switches/Routern basierend auf Policies.


24

• SXP – Security Group Tag Exchange Protocol ist ein Kontrollprotokoll für die Übermittlung von IP-zu-SGT gebunden Informationen über mehrere Netzwerkgeräte, welche keine Möglichkeit haben entsprechende Security Group Tags auf Pakete abzubilden.

• SNMP – Simple Network Management Protocol wird für die zentrale Steuerung und Überwachung von Netzwerkgeräten verwendet.

• USC – Unified Secure Channel ermöglicht einem zentralen Server, die Koordination von verschlüsselter Kommunikation zwischen Endpunkten

• SNBI – Secure Network Bootstrapping Interface ermöglicht eine sichere initiale Kommunikation zwischen SNBI Geräten und Kontrollern, die sich gegenseitig erkennen können, und so die physische Topologie des Netzwerks hervorbringen.

• IoT HTTP/CoAP – Internet of Thing Hypertext Transfer Protocol / Constrained Application Protocol ist ein spezielles Web Transfer Protokoll, welches für eingeschränkte Endgeräte und Netzwerk im Internet of Things Bereich verwendet wird. Es wurde für die machine-to-machine Applikationen wie smart energy und Hausautomation designt.

• LACP – Link Aggregation Control Protocol wird für die Bündelung von physischen Netzwerkverbindungen verwendet.

• PCMM – PacketCable Multimedia ermöglich die Sicherstellung von dynamischem Quality of Service.

• COPS – Common Open Policy Service Protocol ermöglicht den Austauschen von Policy Informationen zwischen einem policy decision point und einen policy enforcement point für die Durchsetzung von Quality of Service

4.4 OpenDaylight Im Jahr 2013 wurde unter dem Namen OpenDaylight ein OpenSource Projekt ins Leben gerufen, mit dem Ziel, Software Defined Network und Network Function Virtualization auf transparente Art zur Verfügung zu stellen. Das Projekt wird durch die Linux Foundation angeführt und kann in seiner Mitgliederliste viele bekannte Firmen aus der Netzwerkbranche verzeichnen. Zu nennen sind dabei Brocade, Cisco, Citrix, HP, IBM, Juniper Networks, Microsoft, NEC, Red Hat und VMware. Die erste Version des OpenDaylight SDN Controllers mit dem Namen Hydrogen wurde im Februar 2014 veröffentlicht. Der OpenDaylight SDN Controller ist heute einer, der am weitesten verbreiteten SDN Controller und zeichnet sich vor allem durch die hohe Anzahl an North- und Southbound APIs aus. Hersteller wie Cisco, Brocade und Huawei nutzen als Basis für ihren SDN Controller den OpenDaylight SDN Controller oder nutzen den OpenDaylight SDN Controller als Teil der Network as a Service Infrastruktur Angebote, wie IBM oder Telstra. Der OpenDaylight SDN Controller ist modular aufgebaut und kommt in seiner Grundinstallation ohne nennenswerte Funktionalität daher. Je nach Anwendungsszenarien können darauf entsprechende Features installiert werden, wie beispielsweise DLUX als WebGUI für die Visualisierung der Netzwerktopology oder OpenFlow für die Kommunikation mit OpenFlow-fähigen Netzwerkgeräten. Insgesamt verfügt der OpenDaylight SDN Controller über mehr als 200 Features, die einzeln installiert werden können. Seit Februar 2016 steht die aktuellste Version mit dem Namen Beryllium des OpenDaylight SDN Controllers zur Verfügung, mit der nächsten Version namens Boron kann gemäss Release Plan im September 2016 gerechnet werden.


25

4.5 Brocade SDN Controller Mit dem Brocade SDN Controller bietet Brocade eine kommerzielle Version des OpenDaylight SDN Controller an. Im Gegensatz zur Installation des OpenDaylight SDN Controllers, steht nach der Installation des Controllers bereits ein minimales Bundle an Features bereit, die für die Anwendung mit der entsprechenden Hardware von Brocade abgestimmt sind. Weitere Features können aber problemlos nachinstalliert werden. Ein weiterer Unterschied zum OpenDaylight SDN Controller kann in der Benutzeroberfläche festgestellt werden, dafür stellt Brocade eine eigene Implementation zur Verfügung. Brocade SDN Controller 2.3 OpenDaylight SDN Controller Beryllium

Abbildung 10: Brocade SDN Controller 2.3

Abbildung 11: OpenDaylight SDN Controller

4.5.1 Brocade Flow Manager Um Flows, Meters und Groups über eine grafische Oberfläche erstellen zu können, bietet Brocade mit dem Brocade Flow Manager ein zusätzliches Feature an, welche nahtlos in die Weboberfläche des Brocade SDN Controller integriert ist.

Abbildung 12: Brocade Flow Manager


26

Grundsätzliche ist die Erstellung, Modifizierung und Löschung von Flows, Meters und Groups auch ohne den Brocade Flow Manager möglich und könnte via Rest API entsprechend umgesetzt werden.

4.5.2 Brocade Flow Optimizer Der Brocade Flow Optimizer ist eine eigenständige Softwarekomponente, die es ermöglicht, Flows intelligent im Software Defined Network basierend auf Richtlinien zu managen. Um dies realisieren zu können, nutzt die Software einerseits die Northbound API des OpenDaylight SDN Controllers und verarbeitet andererseits sFlow Pakete von SDN-fähigen Switches. Somit kann der Brocade Flow Optimizer beispielsweise verwendet werden um grosse Layer-2- Layer-4 Angriffe wie, NTP Reflection, UDP Flooding, DNS Reflection und ICMP Ping Flooding zu erkennen und abzuwehren. Weiter kann der Brocade Flow Optimizer auch dazu benutzt werden, wenn Datenpfade überlastet sind, aktiv einen alternativen Datenpfad für entsprechende Services bereitzustellen, um damit die Verfügbarkeit einzelner Services sicherstellen zu könne.

Abbildung 13: Brocade Flow Optimizer

Hochschule Luzern Bericht - SDN in der Praxis Technik & Architektur

27

5 SDN in der Praxis

5.1 Erfahrungsbericht Testbed Im EnterpriseLab der Hochschule Technik und Architektur wurde mit Netzwerkkomponenten von Brocade und HP einige Test durchgeführt die einerseits die Reife von Software Defined Network wie auch die Interoperabilität beleuchten sollen.

5.1.1 Hardwareunterschiede Zwischen den beiden Herstellern Brocade und HP konnten einige Unterschiede in der Implementierung von OpenFlow festgestellt werden.

5.1.1.1 Flow Tables Die Brocade Switches ICX 6610 und ICX 7450 verfügen beide jeweils über eine einzige Flow Table, im Gegensatz zum HP 5130, welcher bis zu 255 Flow Tables unterstützt. Des Weiteren ist auch die Anzahl Flows in eine Flow Table beschränkt, beim HP 5130 können pro Flow Table bis zu 65635 Flow definiert werden, bei Brocade ICX 7450 sind dies 12288 und beim Brocade ICX 6610 12000 Flows pro Flow Table. Max. Flow Tables Max. Flows/Flow

Table Max Anzahl Flows

Brocade ICX 6610 1 12000 12’000 Brocade ICX 7450 1 12288 12’288 HP 5130 255 65635 16’736’925 Tabelle 12: Anz. Flow Tables

5.1.1.2 Table Miss Rule Jede Flow Table beinhaltet einen Eintrag der festlegt was mit einem Paket geschehen soll, welches auf keinen vordefinierten Flow zutrifft geschehen soll. Brocade ermöglich hierfür folgende Optionen:

• Drop (Default), Pakete werden verworfen. • Send-to-Controller, Pakete werden an den SDN Controller gesendet.

HP verfügt hingegen über folgende Optionen: • Drop (Default), Pakete werden verworfen. • Normal-Output, Pakete werden durch die normale Switch Pipeline verarbeitet.

5.1.1.3 ARP Matching Rule Der Brocade SDN Controller wie auch der OpenDaylight SDN Controller enthalten, für das Handling von ARP Paketen das Feature ARPHandler. Der ARPHandler kann so konfiguriert werden, dass entweder eine Regel auf die OpenFlow Switches geschrieben wird, dass alle ARP Pakete, an alles Ports weitergeleitet werden sollen, oder das alle ARP Pakete an den Controller gesendet werden sollen. Beide Varianten haben Nachteile, denn entweder wird das komplette Netzwerk mit ARP Paketen geflutet, oder die Kommunikation unter den Clients funktioniert nur, wenn der Controller zur Verfügung steht. Um beide eher unpraktischen Varianten zu umgehen, wurde entsprechend in der OpenFlow Spezifikation 1.0 bereits entsprechende Ergänzung vorgenommen [20]:

B.8.4 Match on IP fields in ARP packets The reference implementation can now match on IP fields inside ARP packets. The source and destination protocol address are mapped to the nw_src and nw_dst fields respecitively, and the opcode is mapped to the nw_proto field.

Ein entsprechender Flow kann beispielsweise mit dem Brocade Flow Manager nicht erstellt und deployt werden, über die REST API funktioniert dies und kann auf die Switches von Brocade deployt werden. Der HP 5130 Switch jedoch, kann diesen Flow


28

nicht verarbeiten und gibt als Fehlermeldung die Meldungen: OFPBMC_BAD_PREREQ und OFPET_BAD_MATCH zurück.

5.1.1.4 Einrichtung OpenFlow Brocade und HP unterscheiden sich auch in der Einrichtung von OpenFlow, so wird bei Brocade generell auf dem Switch OpenFlow mit der entsprechenden Version aktiviert und auf jedem Netzwerkinterface entsprechend OpenFlow aufgeschaltet.

openflow enable ofv130 openflow controller ip-address 192.168.1.10 no-ssl port 6633 interface ethernet 1/1/1 openflow enable layer23 interface ethernet 1/1/2 openflow enable layer23

Bei HP hingegen wird eine OpenFlow Instanz basierend auf einem VLAN erstellt und die dazugehörigen Interfaces entsprechend dem VLAN zugeordnet.

openflow instance 2 description HP Switch datapath-id 3 classification vlan 10 controller 1 address ip 192.168.1.10 interface GigabitEthernet1/0/13 port access vlan 10 interface GigabitEthernet1/0/14 port access vlan 10

Auf dem HP Switch können so beispielsweise mehrere logische OpenFlow Switches erstellt werden, die separat administriert werden können.

5.1.2 Interoperabilität Die Interoperabilität zwischen unterschiedlichen Switches von Brocade mit unterschiedlicher Firmware funktioniert einwandfrei, mit der Einschränkung, dass auf dem Brocade ICX 7450 keine IPv4 Source-IP als Matching Kriterium hinterlegt wird. Aber dies sollte in einer nächsten Firmware Version vom Hersteller gepatcht werden können. Hingegen konnte ein gravierendes Problem mit dem HP Switch festgestellt werden, wodurch die Nutzung von OpenFlow stark eingeschränkt ist. Und zwar funktioniert ARP über OpenFlow nicht. Das heisst dass ARP Pakete, die vom SDN Controller an den HP Switch gesendet werden, nicht verarbeitet werden können und der Switch darauf mit der Fehlermeldungen BAD_PORT antwortet. Für die Umgehung dieses Problem, müsste ein Layer 2 Flooding eingerichtet werden, da bereits auch das Einrichten einer ARP Matching Rule nicht funktioniert hat. Eine weitere unpraktische Lösung ist die Hinterlegung von statischen ARP Einträgen auf den entsprechenden Hosts. Als Lösungsversuch wurde auch auf dem HP Switch versucht ein Flow der ARP Pakete an alles Ports flutet zu erstellen, dieser OpenFlow Steuerbefehl wurde vom HP Switch aber fehlinterpretiert und mit der Action Drop hinterlegt. Wenn die zentrale Problematik mit ARP auf dem HP Switch aber ausgeklammert wird, so kann aber gesagt werden, das Flows, Groups wie auch Meters in Kombination zwischen Brocade und HP ohne festgestellte Probleme funktionieren.

5.1.3 Stabilität

5.1.3.1 Hardware Es konnte festgestellt werden, dass auf dem Brocade ICX 7450 nach der Deaktivierung von OpenFlow auf einzelnen Ports, die Aktivierung erst nach einem Neustart des Switches vorgenommen werden konnte.


29

Weiter konnte beobachtet werden, dass bei einem Neustart der Switches, nicht sofort OpenFlow aktiv ist, was dazu führt, dass Pakete direkt durchgereicht werden und dies beim Controller zu einer Fehlinterpretation der Topologie führen kann.

Abbildung 14: Topologie Fehlinterpretation

Auf der Abbildung 14: Topologie Fehlinterpretation ist zu sehen, dass der Host mit der IP Nummer 192.168.10.254 direkt mit dem Switch openflow:3 (HP) verbunden ist und über zwei Links direkt mit Switch openflow:14721744064491552768 (Brocade). In Wirklichkeit ist der Host aber nur mit einen Link ausgestattet, der direkt mit dem Brocade Switch verbunden ist.

5.1.3.2 Controller Beim Controller konnte festgestellt werden, dass dieser nach einem Neustart bis zu 15 Minuten benötigt, bis dieser in voller Funktion zur Verfügung steht, dies konnte sowohl beim OpenDaylight wie auch bei Brocade SDN Controller 2.3 festgestellt werden. Da es beim Controller je nach Konfiguration um einen kritischen Knoten der Netzwerkfunktionalität handelt, darf dieses Problem nicht vernachlässigt werden. Beim Brocade SDN Controller 3.0 wurde hingegen festgestellt, dass diese Zeit minimiert werden konnte und nur noch maximal drei Minuten benötigt, bis alle Funktionen zur Verfügung stehen.

5.1.4 Skalierbarkeit Der OpenDaylight SDN Controller wie auch der Brocade SDN Controller können beide als Cluster zur Verfügung gestellt werden, wodurch ein höherer Skalierungsgrad ermöglicht werden kann. Probleme in der Skalierbarkeit könnten die maximale Anzahl an Flows, die auf einem Switch eingerichtet werden können, sein. Angenommen in einem Rechenzentrum existieren 240 Endknoten in virtueller oder physikalischer Form, alle müssen miteinander über IPv4 kommunizieren können, so müssten für den hin und Rückweg bereits 57360 Flows eingerichtet werden. Wenn man nun bedenkt, dass auch IPv6 notwendig sein muss, wird bereits die doppelte Anzahl benötigt, was im Falle der Brocade Hardware fast zehnmal höher ist als die maximale Anzahl an Flows, die auf einem Switch hinterlegt werden müssen.


30

240(240 − 1)2

= 28′680 𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 28′680 ∗ 2 = 57′360 𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 𝐻𝐻𝑉𝑉𝑉𝑉 𝑉𝑉𝑉𝑉𝑉𝑉 𝑅𝑅ü𝑐𝑐𝑐𝑐𝑐𝑐𝑉𝑉𝑉𝑉

57′360 ∗ 2 = 114′720 𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉𝑉 𝑚𝑚𝑉𝑉𝑚𝑚 𝐼𝐼𝐼𝐼𝐼𝐼4 𝑉𝑉𝑉𝑉𝑉𝑉 𝐼𝐼𝐼𝐼𝐼𝐼6 Um dieses Problem lösen zu können, ist es entweder notwendig die maximale Anzahl an Flows die auf einem Switch hinterlegt werden können zu erhöhen oder mittels intelligenter Formulierung von Flows eine entsprechende Summarization vorzunehmen.

5.2 Big Picture Software Defined Network ist nicht nur OpenFlow und OpenDaylight, dahinter steckt noch viel mehr. In diesem Kapitel soll gezeigt werden, welche bisher noch nicht angesprochenen Protokolle, Services und Netzwerkgeräte ebenfalls in ein komplexes Software Defined Network Gebilde eingebunden sind, noch integriert werden müssen oder auch verschwinden oder überdenkt werden müssen.

5.2.1 Protokolle

5.2.1.1 Address Resolution Protocol (ARP) Das Address Resolution Protocol bildet eine zentrale Rolle im Software Defined Network, denn einerseits nutzt der SDN Controller die in ARP Paketen enthaltenen Informationen um Hosts zu identifizieren, dies bedingt aber das ARP immer über den SDN Controller erfolgen muss, resp. dieser zumindest die ARP Response Pakete erhalten muss. Andererseits muss auch sichergestellt werden, das ARP in SDN funktioniert, sodass überhaupt eine Kommunikation über IP funktionieren kann, solange nämlich ein Host nicht die MAC-Adresse des zu adressierenden Endknoten oder Routers weiss, wird dieser kein IP Paket versenden. Somit kann gesagt werden, dass OpenFlow mit der Möglichkeit von Flows und dessen Header Matching Mechanismus erst vollumfänglich zum Tragen kommt, wenn er Pakete erhält, die er Aufgrund von MAC-Adressierung, IP-Adressierung und Port Adressierung verarbeiten kann.

5.2.1.2 Link Layer Discovery Protocol (LLDP) LLDP wird in einem OpenFlow SDN Netzwerk für Erkennung der Topology verwendet. Mit OpenFlow wurde auf jedem Switch ein Flow hinterlegt, der jegliche LLDP Paket an den Controller sendet. Um nun die Topology des Netzwerks zu erkennen, sendet der Controller an jeden Switch den Befehl, dass er auf jedem OpenFlow aktivierten Port ein LLDP Paket aussenden soll. Wenn nun auf der Gegenseite ein OpenFlow Switch das Paket empfängt, wird dieser das Paket via OpenFlow an den Controller senden, darin enthalten ist dann rohe LLDP Paket, wie auch die OpenFlow Information auf welchem Port der Switch das Paket empfangen hat. In der Arbeit «Efficient Topology Discovery in Software Defined Networks» von Farzaneh Pakzad, Marius Portmann, Wee Lum Tan und Jadwiga Indulska, der University of Queensland [29] ist dies mit folgendem Bild beschrieben:


31

Abbildung 15: Funktionsweise LLDP [29]

Zudem wird in dieser Arbeit ein für den SDN Controller effizienteres Verfahren für die Erkennung der Topologie beschrieben, die den für die Topologie Erkennung erforderlichen CPU Load um 45% senkt. Und zwar wird in diesem Verfahren das LLDP versendete Paket so modifiziert, dass das Feld Port ID TLV mit 0Bit Payload versendet wird und dies wird nur einmal an den Switch gesendet. Auf dem Switch wurde ein OpenFlow Flow definiert, der alle vom Controller kommenden LLDP Paket über alle Ports weitersendet, dabei aber die Absender MAC Adresse des entsprechenden Pakets auf die MAC Adresse des Switch Ports, über das Paket versendet wird, hinterlegt. Das Paket wird nun gemäss dem bekannten Verfahren vom zweiten Switch an den Controller gesendet. Auf dem Controller wurde entsprechend der Packet-In Handler für LLDP Pakete geändert, der nun nur noch die MAC Adresse des Pakets parsen muss, und damit nun weisse, zwischen welchen MAC Adresse und Switch Ports eine Verbindung besteht.

5.2.1.3 Spanning Tree Protocol (STP) Auf OpenFlow aktivierten Ports auf einem OpenFlow Switch ist das Spanning Tree Protocol generell deaktiviert, Loops werde dementsprechend nicht erkannt und auch nicht deaktiviert. Dies ermöglicht zum einen die Nutzung von redundanten Pfaden aus Gründen der Ausfallsicherheit zum anderen kann damit aber generell mehr Bandbreite genutzt werden, da keine Links deaktiviert wurden. Bei der Einrichtung von Flows muss aber darauf geachtet werden, dass keine Loops erstellt werden, die das Netzwerk lahmlegen könnten. So kann es beispielsweise vorkommen, dass mit der Option des proaktiven Flood Modes in der Konfigurationsdatei 54-arphandler.xml des OpenDaylight SDN Controller, auf jedem Switch ein Layer 1 Flow aktiviert wird, der eingehende Pakete an alle Ports weitersendet. In diesem Fall würde das Netzwerk lahmgelegt werden, falls physische Loops erstellt wurden.

5.2.2 Netzwerk Services

5.2.2.1 Domain Name System (DNS) Grundsätzlich kann das bestehende Konzept mit einem DNS Server beibehalten werden, wie bis anhin. Jedoch eignet sich ein Name besser für die Erstellung von Flows als dies IP-Adressen oder gar MAC-Adressen tun. Juha Hokkola, CEO von FusionLayer Inc, beispielsweise sieht in DNS eine grosse Zukunft im Hinblick auf Software Defined Network und Software Defined Data Center und behauptet dabei, dass sich die bekannte


32

DNS Architektur weiterentwickeln muss um den Anforderungen für ein Software Defined Data Center gerecht werden zu könne. Weshalb er eine Checklist mit zwei Punkten erstellt hat:

1) Dynamic DNS Provisioning. As data center workflows are being automated, there will be very little room for command-line prompt or home-grown scripts. Rather, the DNS platform must have an open API that can be used to provision changes, in real-time. Forget the manual management of static DNS entries, that's not for the 10s. [30] 2) DNS Management Automations. To make sure that the integration is kept simple, the DNS platform to which the changes are provisioned must include automation features such as creation of slave zone files (when master is created) and reverse mappings; automated allocation of next available IP address; automated generation of names based on user policies; and data validation to make sure an invalid entry does not take down the DNS service. In other words, the whole nine yards. [30]

5.2.2.2 IP-Adressen Verteilung Für die IP Adressverteilung macht es durchaus Sinn, auf bewährte Methoden wie DHCP zu setzen. Hierfür ist es aber notwendig das entsprechende Flows eingerichtet werden, die eine Kommunikation zwischen DHCP Server und DHCP Client ermöglichen. Ebenfalls denkbar ist die Möglichkeit einen DHCP Server direkt auf dem SDN Controller zu betreiben. Dies wurde im Rahmen des OpenDaylight Forum India 2015 von Vishal Thapar und Faseela K im Vortrag «L3 Enablements of Tenant VMs by DHCP Service in ODL» [31] entsprechend erwähnt. Also Vorteile wurden dabei erwähnt, dass nur Unicast Traffic genutzt wird, und der DHCP Server entsprechend Hochverfügbar und gecluster zur Verfügung gestellt werden. Als klarer Nachteil wird dabei angesehen, dass dies ein weiterer Dienst auf dem SDN Controller ist, welcher Ressourcen benötigt und dieses Setup noch nicht sehr ausgereift ist.

5.2.3 Netzwerk Geräte

5.2.3.1 Router In einem Software Defined Network ist es nicht mehr zwingend notwendig, dass ein physikalischer Router vorhanden sein muss. Die Funktionalität für die Verbindung zweier Netzwerke kann durchaus mit OpenFlow Flows realisiert werden, die durch einen SDN Controller erstellt werden können. Der SDN Controller seinerseits kennt die gesamte Netzwerktopologie und kann entsprechende Flows für eine optimale Verbindung, wie den schnellsten Pfad oder den Pfad mit der höchsten zur Verfügung stehender Bandbreite entsprechend auf dem OpenFlow Switches einrichten.

5.2.3.2 Firewall In Software Defined Networks ist es nicht mehr notwendig eine physikalische Firewall zur Verfügung zu haben. Vielmehr wird das Regelwerk zentral auf dem SDN Controller eingespeist und verteilt auf allen OpenFlow Switches eingespielt. Das Verwerfen und Zulassen von Paketen kann bereits nahe an den Endgeräten geschehen, wodurch bereits viel Netzwerkverkehr gar nie erst den Switch verlässt, der mit den Endknoten verbunden ist. Es kann somit festgehalten werden, dass einerseits die Regeln zentral über den SDN Controller verwaltet werden können, die Funktionalität der Firewall aber dezentral von allen OpenFlow Switches gewährleistet wird.


33

5.3 Anwendungsszenarien Im folgenden Kapitel werden einige Anwendungsszenarien beschrieben, die mit Hilfe von OpenFlow umgesetzt werden können und von einigen Herstellern entsprechend angeboten werden.

5.3.1 Webproxy In vielen Unternehmen wird der Zugang zum Internet über einen Webproxy gesteuert. Damit dies auf allen Geräten funktioniert, müssten entsprechende Proxysettings den entsprechenden Applikationen bekannt gegeben werden. Dies wird in den meisten Fällen in einem Microsoft Umfeld über Group Policies gesteuert. Durch das Aufkommen von Bring Your Own Device und Internet of Things, ist es möglich, dass je nach Gerät das vom User eingesetzt wird, darauf keine Group Policies appliziert werden können und die entsprechenden Settings von Hand eingetragen werden müssen. Wenn das Gerät jedoch unterwegs bei einem Kunden oder zu Hause eine Verbindung mit dem Internet herstellen möchte, so müssen diese Einstellungen wieder rückgängig gemacht werden. Dieses Hin und Her ist für die meisten Nutzer nicht wirklich benutzerfreundlich. Mit den Möglichkeiten von OpenFlow ist möglich den gesamten Webtraffic zentral auf einen Proxyserver umzuleiten, ohne dass auf dem Client eine Einstellung vorgenommen werden muss. Dieses Verfahren wurde in einem Whitepaper von Wedge Network mit dem Titel «Transparent Service Insertion in SDNs Using OpenFlow» [32] beschrieben.

5.3.2 Software Defined WAN Google hat im Jahr 2013 ein Paper mit dem Namen «B4: Experience with a Globally-Deployed Software Defined WAN» [33] veröffentlicht in welchem sie ihre dreijährige Erfahrung mit ihrem globalen Software Defined Network mitgeteilt haben. Die aufgebaute Lösung mit dem Namen B4 verfügt über mehrere einzigartige Charakteristika die mit Hilfe von OpenFlow ermöglicht wurden.

B4 has a number of unique characteristics: i) massive bandwidth requirements deployed to a modest number of sites, ii) elastic traffic demand that seeks to maximize average bandwidth, and iii) full control over the edge servers and network, which enables rate limiting and demand measurement at the edge.

Daraus resultierte eine Netzwerkinfrastruktur, die Folgendes ermöglicht: B4’s centralized traffic engineering service drives links to near 100% utilization, while splitting application flows among multiple paths to balance capacity against application priority/demands.

5.3.3 Quality of Service Durch die Möglichkeit von OpenFlow können beispielsweise auch Flows dynamisch von einer Applikation angefordert werden. Ein Beispiel welches von HP, Extreme Networks und auch Sonus präsentiert wird, ist die Integration von Skype for Business. Wenn eine Telefonverbindung zwischen zwei Personen aufgebaut werden soll, so wird mittels OpenFlow ein Flow eingerichtet, der über genügend Bandbreite verfügt, und so die bestmögliche Qualität für das Telefongespräch sicherstellt. Dieser Flow wird so lange vorhanden sein, wie das Telefongespräch dauert, und wird danach wieder gelöscht.

5.3.4 DDoS Mitigation In einer Präsentation mit dem Namen «Behavioral Security Threat Detection Strategies for Data Center Switches and Routers» [34] von Ramki Krishnan, Dilip Krishnaswamy und Dave Mcdysan wird beschrieben, wie eine DDoS Attacke erkannt und abgewehrt werden kann. So wurde an einem Border Router mit zwei Uplinks ein 1Gbps UDP Flood Traffic injiziert, und mit Hilfe von sFlow Sampling, einer DDoS SDN Applikation und dem


34

SDN Controller konnte dieser Traffic innert 5 Sekunden detektiert und auf 200Mbps gedrosselt werden. In einem weiteren Versuch wurde das Prozedere mit einem virtuellen Switch/Router wiederholt, der regelmässig mit 500Mbps UDP Flood Traffic an einen virtuellen Server versendet hat. Auch diese Attacke konnte innert 400ms erkannt und basierend auf einer vordefinierten Policy auf 50Mbps minimiert werden.


35

5.4 Aufbau einer SDN Applikation

Abbildung 16: Northbound API

Um ein SDN Netzwerk zu verwalten und zu kontrollieren, stellt ein SDN Controller eine sogenannte Northbound API zur Verfügung. Die aktuelle API welche der OpenDaylight Controller anzubieten hat, ist ein RESTful Schnittstellen welche XML oder JSON über HTTP verwendet. RESTful Schnittstellen sind einfach zu bedienen, da sie auf Technologien basieren, mit denen viele Programmierer vertraut sind und welche in vielen Web-Services und Anwendungen verwendet werden. Das Parsen und das Erstellen von JSON oder XML Nachrichten und das Senden oder Empfangen von diesen über HTTP ist unkompliziert und wird von vielen Programmiersprachen unterstützt. Aufgrund der Anfrage-Antwort Arbeitsweise von REST und HTTP, eignet sich diese Schnittstelle jedoch nur zur proaktiven Programmierung von Flows. Leider fehlt die Funktionalität um auf eingehende Ereignisse zu reagieren.

REST REST ist steht für REpresentational State Transfer. Es beschreibt, wie ein System mit einem anderen einen Zustand kommunizieren kann. In unserem Fall wäre es der Zustand von einem Flow (Name, Typ, Quellport, Zielport, usw.) repräsentiert als XML oder JSON Nachricht von einem Client (externe Applikation) zu einem Server (dem Controller). JSON Die JavaScript Object Notation, kurz JSON, ist ein kompaktes Datenformat in einer einfach lesbaren Textform zum Zweck des Datenaustauschs zwischen Anwendungen. [41] XML Die Extensible Markup Language, abgekürzt XML, ist eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von Textdateien. XML wird u. a. für den plattform- und implementationsunabhängigen Austausch von Daten zwischen Computersystemen eingesetzt, insbesondere über das Internet. [42] HTTP Das Hypertext Transfer Protocol (HTTP) ist ein zustandsloses Protokoll zur Übertragung von Daten auf der Anwendungsschicht über ein Rechnernetz. Es wird hauptsächlich eingesetzt, um Webseiten (Hypertext-Dokumente) aus dem World Wide Web in einen Webbrowser zu laden. Es ist jedoch nicht prinzipiell darauf beschränkt und auch als allgemeines Dateiübertragungsprotokoll sehr verbreitet. [43]


36

5.4.1 REST Methoden Folgende REST Methoden werden von OpenDaylight unterstützt. Der Payload kann entweder XML oder JSON sein.

• PUT/POST (Erstellen/Updaten)

Über die PUT Methode können dem Controller Anweisungen gegeben werden. Der Controller speichert diese in seine Datenbank ab sendet die Befehle anschliessend über OpenFlow weiter an die betreffenden Switches. Folgende PUT/POST Möglichkeiten stehen zur Verfügung:

o Flow hinzufügen o Gruppe hinzufügen o Meter hinzufügen

• DELETE (Löschen)

Über DELETE können Informationen und Daten aus dem Controller, bzw. den Nodes gelöscht werden.

Zweck Anfrage Flow löschen (hier Flow 99)

http://10.176.50.11:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:224635992577896/table/0/flow/99

Alle Flows löschen (in Table 0)

http://10.176.50.11:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:224635992577896/table/0/

Meter löschen (hier Meter 1)

http://10.176.50.11:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:224635992577896/meter/1

Group löschen (hier Group 1)

http://10.176.50.11:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:224635992577896/group/1

Alle Flows, Groups, Meters löschen

http://10.176.50.11:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:224635992577896

Tabelle 13: Rest DELETE Methoden

• GET (Lesen)

Über die Northbound API können vom Controller auch Informationen und Statistiken über den Controller selbst oder über OpenFlow Nodes angefordert werden. Die Informationen werden im XML oder JSON Format zurückgeliefert. Die aktuellen Daten über die Nodes holt sich der Controller direkt über seine Southbound API, bzw. über das Protokoll OpenFlow von diesen.

Rückgabe Anfrage Individuelle Flow Statistik (hier für Flow 99)

http://10.176.50.11:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:224635992577896/table/0/flow/99

Gesamte Flow Statistik (für Table 0)

http://10.176.50.11:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:224635992577896/table/0/

Portbeschreibung und Portstatistik (hier für Port 4)

http://10.176.50.11:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:224635992577896/node-connector/openflow:224635992577896:4

http://www.brocade.com/content/html/en/user-guide/SDN-Controller-2.2.0-User-Guide/GUID-A1474244-A326-4687-B593-7E1C77107EC8.html


37

Groupbeschreibung und Groupstatistik (hier für Group 1)

http://10.176.50.11:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:224635992577896/group/1/

Meterconfiguration und Meterstatistik (hier für Meter 1)

http://10.176.50.11:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:224635992577896/meter/1/

Queue Statistik (hier für Port 4)

http://10.176.50.11:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:224635992577896/node-connector/openflow:224635992577896:4/queue/1

Informationen zu einem Node

http://10.176.50.11:8181/restconf/operational/opendaylight-inventory:nodes/node/openflow:224635992577896/

Topologie Datenbank http://10.176.50.11:8181/restconf/operational/network-topology:network-topology/

Inventar Datenbank http://10.176.50.11:8181/restconf/operational/opendaylight-inventory:nodes

Tabelle 14: Rest GET Methoden

Bei der Statistikabfrage für den Port 3 würde unter anderem folgende Rückgabe zurückkommen. Diese zeigt, wie viele Bytes/Pakete dieser Port verarbeitet hat. Anhand dieser Informationen könnte man z.B. den Datendurchsatz in Bytes pro Sekunde berechnen, indem man zwei Abfragen mit kurzem Zeitabstand macht und diese Werte dann vergleicht.

Abbildung 17: Portstatistik JSON

http://www.brocade.com/content/html/en/user-guide/SDN-Controller-2.2.0-User-Guide/GUID-A1474244-A326-4687-B593-7E1C77107EC8.html


38

5.4.2 SDN Netzwerk überwachen und steuern Damit man einen SDN Controller konkret programmieren kann, sind SDN Apps notwendig. Und um ein Netzwerk zu kontrollieren und zu steuern, benötigen dieses Apps jedoch Informationen über das Netzwerk. Diese Informationen können sich die Apps dazu direkt von den einzelnen Nodes holen, über bestehende Protokolle wie z.B. sFlow.

Bei diesem Verfahren wird technisch gesehen das sFlow Sampling-Verfahren verwendet, wobei Informationen von Datenpaketen in Echtzeit an die SDN App gesendet werden. Diese kann die Daten auswerten und visualisieren. Regelwerke, die unerwünschte Daten anzeigen, beschränken, umleiten oder gar blockieren, lassen sich hier erstellen. Zur Durchsetzung dieser Aktionen kommuniziert diese Software mit dem SDN-Controller, der die Anweisungen über eine Schnittstelle entgegennimmt und direkt auf den angemeldeten Nodes mittels des OpenFlow-Protokolls aktiviert (z.B. einen neuen Flow generiert, welcher alle eingehenden Pakete einer bestimmten IP verwirft). [35]

Abbildung 18: SDN Netzwerk überwachen

Dieser Prozess kann mit Schwellwerten so gestaltet werden, dass Regeln bei Über- oder Unterschreitung eines Wertes dynamisch aktiviert oder deaktiviert werden. Die Konfiguration der Switche oder Router ist ebenfalls einfach, da diese sich lediglich am SDN-Controller registrieren müssen und als Ziel ihrer sFlow Daten die SDN App eintragen. Ebenso registriert sich die SDN App bei dem SDN-Controller und anschliessend kann das gesamte Netz überwacht und bei Bedarf konfiguriert werden. [35] Eine mögliche App, die das Netzwerk so überwacht und steuert, ist z.B. der Flow Optimizer von Brocade.

sFlow ist ein Standard zur Überwachung von Rechnernetzen. Es beschreibt einen Mechanismus, den über einen Switch oder Router fliessenden Netzwerkverkehr statistisch zu erfassen und zur Analyse an einen zentralen Server weiterzuschicken. [40]


39

5.4.3 Bestehende SDN Applikationen Alle aufgelisteten Apps sind kommerzielle und somit kostenpflichtige Software. Die meisten davon stehen als zeitlich begrenzte Testversionen zur Verfügung. Brocade (benötigt Brocade SDN Controller) Anwendung Beschreibung Brocade Topology Manager v3.0.0*

Kostenlose SDN-Anwendung, die die gegebene Netzwerktopologie abbildet. So könnten Administratoren eine Liste der Knoten erstellen und einfach nach Nodes suchen.

Brocade Flow Optimizer v1.2.1

Hiermit lässt sich der Netzwerk-Traffic intelligent managen und Netzwerkangriffe pro-aktiv abwehren

Brocade Flow Manager v2.0.0

Dient zum Managen des SDN Netzwerks. Hiermit lassen sich Flows, Paths, Groups und Meters konfigurieren.

Brocade VNF Manager v1.0.1

Brocade VNF Manager ist eine Orchestration-Anwendung für Network Function Virtualization (NFV). Zusammen mit dem Brocade SDN-Controller übernimmt sie das Lebenszyklusmanagement für Virtual Network Functions (VNF).

Tabelle 15: Brocade SDN Apps

HP (benötigt HPE VAN SDN Controller) Anwendung Beschreibung HPE Network Optimizer v1.3.41

Die App stellt die Richtlinien für den gesamten Netzwerkpfad sowie für Quality of Service (QoS) dynamisch über den SDN Controller bereit.

HPE Network Protector v1.3.55

Ermöglicht die automatische Feststellung des Netzwerkzustands und der Sicherheit in Echtzeit über SDN-fähige Netzwerke und bietet einfache Sicherheit für BYOD-Umgebungen.

HPE Network Visualizer v1.1.18

Dient zur dynamischen Erfassung des Datenverkehrs mit detaillierter Netzwerküberwachung in Echtzeit und ermöglicht so eine schnelle Netzwerkdiagnose/-prüfung und schnelle Fehlerbehebung.

Tabelle 16: HP SDN Apps

Sonstige (nicht abschliessend) Anwendung Beschreibung KEMP Virtual LoadMaster v7.1.28

Virtueller Load-Balancer und Verkehrssteuerung in ODL Umgebungen.

TechM Smart Flow Steering v1.2.1

App zum Steuern von Flows in SDN Netzwerken mit dem HP VAN SDN Controller

TechM Server Load Balancer v1.2.1

Load Balancer für HP VAN SDN Controller

Floodlight ACL* Erzwingt ACL (Access Control List) Regeln auf OpenFlow Switches, in dem es die eingehenden Pakete überwacht. Stellt so Firewallfunktionalitäten zur Verfügung.

Flow Maker Deluxe (abgespeckte Version als Freeware verfügbar)*

Bietet die Möglichkeit zum Erstellen und Löschen von Flows direkt aus dem HP SDN-Controller UI. Flows können gespeichert werden, sodass diese im


40

Falle einer Löschung oder eines Neustarts erneut angewendet werden können. Dienste wie Firewall, Proxy oder NAT können direkt auf dem Switch implementiert werden.

Tabelle 17: Sonstige SDN Apps

*Freeware


41

5.5 Gesamtlösungen

5.5.1 Cisco ACI Mit Cisco Application Centric Infrastructure (ACI) bietet Cisco eine eigene vollumfängliche SDN Lösung an. Im Gegensatz zu anderen Anbieter setzt Cisco dabei nicht auf OpenFlow, sondern setzt dabei OpFlex Eine Cisco ACI besteht aus folgenden Komponenten [36] [37]:

• Spine Nodes Spine Nodes sind typischerweise 40Gbit Ethernet Switches aus der Nexus 9000 Serie und sind mit allen Leaf Nodes verbunden. An eine Spine Node werden keine Endgeräte angeschlossen.

• Leaf Nodes Ein Leaf Node, typischerweise ein 10Gbit Ethernet Switch mit 40Gbit Uplink aus der Nexus 9000 Reihe, ist mit allen Spine Nodes über einen 40Gbit Uplink verbunden. Weiter werden sämtliche Endgeräte an den Leaf Nodes angeschlossen, typischerweise über 10Gbit.

• Application Policy Infrastructure Controller (APIC) Der APIC ist das Herzstück von Cisco ACI. Er managt die Spine und Leaf Nodes, appliziert darauf die entsprechenden Application Network Profiles und bietet ein Health Monitoring an. Des Weiteren bietet der APIC eine API mit XML und JSON Unterstützung an, die über ein Command-line interface oder GUI genutzt werden kann.

• Application Network Profile Ein Application Network Profile besteht aus Gruppe von Endgeräten, deren Verbindungen und den Regeln für diese Verbindungen. Daraus resultiert eine logische Repräsentation aller Komponenten einer Applikation und deren Abhängigkeiten untereinander. Diese Application Network Profile werden durch den APIC auf die Hardware abgebildet.

Abbildung 19: APIC [38]


42

Parallel zu Cisco ACI bietet Cisco den Cisco Open SDN Controller an, welcher als kommerzielle Version des OpenDaylight SDN Controllers angesehen werden kann. Dabei wird das OpenFlow Protokoll verwendet und Cisco bietet aus den eigenen Reihen entsprechend kompatible Hardware an.

5.5.2 VMware NSX Um eine Software Defined Network Lösung anbieten zu können, hat VMware im Jahr 2012 die Firma Nicira aufgekauft [39]. Daraus entstand das Produkt VMware NSX. VMware setzt in ihrer NSX Technologie auf die programmierbare Bereitstellung von virtuellen Netzwerken, welche unabhängig von der darunterliegenden Hardware administriert werden können, wie dies bereits von virtuellen Maschinen bekannt ist. Das gesamte Netzwerkmodell kann mit Software erstellt werden, von einfachen bis komplexen Multitier Netzwerken, welches innert Sekunden bereitgestellt werden kann. NSX bietet eine Vielzahl von verwendbaren Netzwerkkomponenten und Services an, wie logische Switches, Routers, Firewalls, Load Balancers, VPN und workload security. Mithilfe dieser Komponenten können isolierte virtuelle Netzwerke erstellt werden. Die Netzwerkvirtualisierung von VMware kann als abstrahierte Schicht oberhalb der physikalischen Netzwerk Hardware angesehen werden und funktioniert mit allen bekannten Hypervisor Plattformen. Die einzige Anforderung an das physikalische Netzwerk ist die zur Verfügung Stellung von IP Transport. Damit auch bestehende VLANs und physikalische Hosts im virtuellen Netzwerk abgebildet werden können, ist der Einsatz des NSX Gateways notwendig. [40] [41] [42]

Abbildung 20: VMware NSX [43]

VMware teilt ihre Technologie nicht nur in eine Data und Control Plane auf, sondern verfügt zusätzlich über die Management Plane.


43

Abbildung 21: VMware NSX Planes [44]

Die Management Plane besteht aus dem NSX Manager, welcher NSX Controller und NSX Edges einrichtet. Des Weiteren sind Installationen von VXLANs, Distributed Routing und Firewall Kernel Modulen auf den unterliegenden ESXi Hosts möglich. Darüber können ebenfalls Konfigurationen am Controller Cluster via REST API und Hosts via message bus vorgenommen werden. Die Control Plane wird repräsentiert durch den NSX Controller, welcher die Netzwerkinformationen an die ESXi Hosts mitteilt. Des NSX Controller wird geclustert auf mindestens drei Nodes zur Verfügung gestellt, um Skalierbarkeit und Hochverfügbarkeit sicherstellen zu können. Die Netzwerkinformationen sind verteilt auf allen Nodes des NSX Controller Clusters vorhanden. Der NSX Controller besteht aus fünf Rollen:

• API Provider • Persistence Server • Logical Manager • Switch Manager • Directory Server

Der API Provider stellt dem NSX Manager die REST API zur Verfügung. Der Persistence Server stellt sicher, dass keine Daten, welche über alle Nodes verteilt vorhanden sind, verloren gehen. Der Logical Manager beschäftigt sich mit der Policyberechnung und der Netzwerktopologie. Der Switch Manager administriert die Hypervisors und verteilt die relevanten Konfigurationen an die entsprechenden Hosts. Der Directory Server kümmert sich um VXLAN und den distributed logical routing Informationen. Die Data Plane besteht aus den NSX vSwitches und NSX Edge Services Gateway. Der NSX vSwitch basiert auf VDS und stellt access-level switching auf dem Hypervisor zur Verfügung


44

Der NSX Edge Services Gateway verbindet die virtuelle und physikalische Infrastruktur miteinander und stellt Dienste wie Routing, VPN, Firewall, DHCP, Layer 2 Bridging und Load Balancing zur Verfügung.

5.5.3 Vergleich Cisco ACI ist stark an den Anforderungen von Applikationen orientiert, und ermöglicht ein dynamisches zur Verfügung stellen des Netzwerks, ist skalierbar und kann programmatisch erstellt werden. Im Gegenteil operiert VMware NSX auf Virtualisierungsebene und ist ins besonders auf die Kommunikation zwischen virtuellen Maschinen ausgelegt und bietet mit virtuellen Routern, Load Balancern und Firewall Services aus dem Bereich von Network Function Virtualization an. Mateja Jovanovic ist Network und SDN Specialist bei Logicalis in Spanien und verfügt über das Cisco CCIE und VMware Network Virtualization Expert VCIX-NV Zertifikat. In seinem Blog [45] hat er die beiden Technologien miteinander verglichen und kann folgende Empfehlungen abgeben: Vorteile NSX:

• Das GUI ist besser und intuitiver und vermittelt das Gefühl, das man das Netzwerk aus Legostücken zusammenbauen kann

• Micro-Segmentation ist einfacher zu verstehen und zu implementieren • Wenn ein Kunde über eine VMware-only Umgebung verfügt, lässt sich NSX mit

Komponenten wie vRealize voll integrieren

Nachteile NSX: • Man benötigt nach wie vor einen Netzwerk Administrator, der sich um das

physikalische Netzwerk kümmert. NSX kümmert sich nur um die Kommunikation auf den Hosts.

• Wenn etwas langsam läuft und sich das Problem auf der Ebene des physikalischen Netzwerks befindet, so ist der Netzwerk Administrator hilflos, da er nur die VXLAN-enkapsulierten Flows sehen kann.

In welchem Fall ist NSX besser als ACI: • Wenn die einzigen Anforderungen die Interne Datacenter Sicherheit und verteilte

Firewall (Micro-Segmentation) sind. • In VMware-only Umgebung mit einer relativ kleinen nicht wechselnden L2/L3

Fabric wäre ACI ein Overkill.

Vorteile ACI: • Es ersetzt das Netzwerk, verbessert die Performance und macht das

Troubleshooting schneller und effizienter. • Das Konzept von Mandanten ist mit der ACI Infrastruktur perfekt umgesetzt.

Applikationen können in der Testumgebung entwickelt und getestet werden und dann einfach in die Produktion verschoben werden. Die Performance wird sich nicht ändern, da die zugrundeliegende Infrastruktur die gleiche bleibt.

• Kann mit jedem Hypervisor verwendet werden. • Cisco bietet einen gut designten Migrationspfad an, um den Wechsel von einer

Standard Data Center Architektur zu ACI zu ermöglichen.

Nachteile ACI: • Die ACI Infrastruktur beinhaltet viele Komponenten und ist komplex


45

• Das GUI ist weit weg von intuitiv • Cisco schafft es nicht, richtig mitteilen zu können, was ACI wirklich ist. Weshalb

man den „Application Talk“ ignorieren soll, ACI lernen soll und für sich selbst herausfinden soll, was ACI wirklich ist.

In welchem Fall ist ACI besser als NSX: • Firmen mit hohen Data Center Anforderungen und vielen Wechsel innerhalb des

Data Centers • Applikationsentwickler Unternehmungen welche schnell Netzwerk Services

anbieten müssen können. • Kleinere Service Provider welche kompetitiver sein müssen, um Wechsel

schneller durchführen zu können. [45] Software Defined Networks mit OpenFlow und OpenDaylight verfügen grundsätzlich über das Potenzial, die positiven Eigenschaften von VMware NSX und Cisco ACI zu vereinen. Jedoch fehlen noch einige Software Komponenten und Vereinfachungen für deren erfolgreiche Anwendung.

5.6 Integration EnterpriseLab Das EnterpriseLab der Hochschule Luzern Technik & Architektur verfügt aktuell über rund 50 physikalische Server, die über fünf Gigabit respektive 10Gigabit Ethernet Switches miteinander verbunden sind. Insgesamt sind über 250 physische Ports auf den Switches verfügbar und das gesamte Netzwerk ist in über 2000 VLANs aufgeteilt. Mit 24 ESX Server sind aktuelle über 770 virtuelle Maschine vorhanden, die jeweils einzelnen VLANs zugeordnet sind, die wiederum meist durch ein /24 Netzwerksegment repräsentiert werden. Die Zuordnung von VLAN zu Netzwerksegment ist hierbei statisch hinterlegt, wodurch für die meisten Bedürfnisse abgedeckt werden können. Als Firewall und Router wird eine physikalische Maschine mit Solaris verwendet, dabei wird für jedes Netzwerksegment resp. VLAN eine eigene Solaris Zone eingerichtet, welche einerseits ein Interface im entsprechenden Netzwerksegment als Router zur Verfügung stellt und andererseits ein Interface in einem Transfernetzwerk hat, über welches sämtliche Zonen miteinander kommunizieren können. Jede Zone verfügt mit ipfilter über eine eigene Firewall Konfiguration.

Abbildung 22: Integration EnterpriseLab


46

Die beschriebene Infrastruktur verfügt über einige Schwachstellen die mithilfe von Software Defined Networks gelöst werden können, auf welche in den folgenden Kapiteln eingegangen wird.

5.6.1 Unterrichtsübungen im EnterpriseLab In vielen Modulen, die von der Hochschule Luzern im Studiengang Informatik angeboten werden, erhalten die Studenten eine eigene Umgebung, in welcher sie eine vordefinierte Übung durchführen sollen. In der folgenden Abbildung kann man sehen, wie eine solche Umgebung technisch realisiert wurde.

Abbildung 23: Unterrichtsübung Szenario 1

Der Student erhält jeweils eine Firewall FWG001-FWG124 und hat dahinter jeweils ein /29 Subnetzwerk, in welchem ihm bis zu fünf Clients/Server betreiben kann. Für jede Gruppe von Studenten steht hierbei jeweils ein eigenes VLAN zur Verfügung. Da maximal 4096 VLANs erstellt werden können, funktioniert diese Lösung nur bis zu einem gewissen Grad. Für solche Unterrichtsübungen konnten 124 VLANs entsprechend reserviert werden, falls nun aber mehr als eine Unterrichtsumgebung für den Unterricht notwendig wäre, so müssten weitere VLANs, die bereits für einen anderen Zweck verwendet werden, entsprechend umorganisiert werden, wenn dies überhaupt möglich ist. Mit der Verwendung von OpenFlow kann vollkommen auf die VLAN Technologie verzichtet werden, indem entsprechende Flows definiert werden, die nur eine Kommunikation zwischen den einzelnen Clients/Servern und der Firewall zulässt. Jedoch wäre ein solches Konzept zum jetzigen Zeitpunkt nur in vernünftiger Zeit realisierbar, wenn Clients/Server und Firewall physisch vorhanden wären und nicht in virtueller Form. Denn OpenDaylight und VMware bieten keine Kompatibilität untereinander an und entsprechende Applikationen, die dynamisch Flows anpassen können, wenn eine virtuelle Maschine von Host System A auf Host System B migriert wird, existieren zum jetzigen Zeitpunkt noch nicht. Denkbar wäre ein solches Konzept zum jetzigen Zeitpunkt nur, wenn beispielsweise auf jedem Hostsystem ein OpenFlow-fähiger Switch installiert ist, wie beispielsweise Open vSwitch und jede virtuelle Maschine mit dem entsprechenden Switch verbunden ist. Als Hostsystem käme hierfür


47

eine Linux Distribution mit installiertem Open vSwitch und KVM als Virtualisierungssoftware in Frage.

Abbildung 24: Unterrichtsübung Szenario 2

Entsprechende Flows, die dabei installierte werden müssten, wären folgende: • Firewall IF int <-> VM 1 • Firewall IF int <-> VM 2 • Firewall IF int <-> VM 3 • Firewall IF ext <-> Internet Router • VM 1 <-> VM 2 • VM 1 <-> VM 3 • VM 2 <-> VM 3

5.6.2 Isolierung von Studentenressourcen Eine weitere Problematik, die das Netzwerkdesign des Enterprise Labs infrage stellt, ist die Isolierung von Studentenressourcen. Zum jetzigen Zeitpunkt werden virtuelle Maschinen, die von Studenten bestellt werden, nicht pro Studenten oder Projekt in einem eigenen Subnetz zur Verfügung gestellt, sondern je nach Zweck, ob diese im internen Netzwerk oder in der DMZ betrieben werden müssen, jeweils in ein bereits bestehendes Netzwerk provisioniert. Somit kann es vorkommen, dass über 100 Studentenmaschinen in der gleichen Broadcast Domäne betrieben und der Zugriff untereinander jeweils über lokale Firewalls eingeschränkt werden muss. Im schlimmsten Fall ist es gar möglich, dass sich Studentenmaschinen untereinander stören, und so gegenseitig den reibungslosen Betrieb beeinträchtigen. Um dies lösen zu können bietet sich Openflow sehr gut an. Wie bereits im vorherigen Kapitel empfohlen müsste jede Ressource eines Studenten mit einem OpenFlow-fähigen Switch verbunden sein, wie Open vSwitch. Damit könnten dann Flows eingerichtet werden, die genau definieren, mit welchen Ressourcen eine Studentenmaschine kommunizieren darf.


48

5.6.3 SDN Übungen im Unterricht Um Studenten die Funktionsweise und die Konzepte von Software Defined Network näher bringen zu können, ist es denkbar, dass im Rahmen des Unterrichts Übungen von Studenten mit Software Defined Network durchgeführt werden können. Grundsätzlich sollte jedem Studenten ein SDN Controller, mehrere OpenFlow Switches und mehrere Hosts zur Verfügung gestellt werden, um die entsprechenden Konzepte von Flows, Groups und Meters verstehen zu können. Denkbar sind hier zum jetzigen Zeitpunkt folgende drei Szenarien. • SDN Übung mit Mininet

Dem Studenten wird in diesem Szenario eine Linuxinstanz zur Verfügung gestellt, auf welcher Mininet und ein SDN Controller zur Verfügung gestellt wird. Mit Mininet kann auf einfache Weise ein virtuelles Netzwerk erstellt werden, welchen Hosts und OpenFlow-fähige Switches beinhaltet, welche jeweils untereinander nach Belieben verbunden werden können. Es ermöglicht ebenfalls die Nutzung von Wireshark, um OpenFlow Pakete analysieren zu können. Mininet verfügt nur über eine geringe Anzahl an Commands, die auf den einzelnen virtuellen Hosts genutzt werden können. Jedoch sollte es ausreichen, um Grundfunktionalitäten von OpenFlow zu verstehen. Vorteil dieses Setups ist die einfache Bereitstellung der Ressourcen für einzelne Studenten.

• SDN Übung mit Open vSwitch

Dem Studenten werden mehrere Open vSwitches, Linux Hosts und ein SDN Controller zur Verfügung gestellt. Damit kann bereits die volle Bandbreite der OpenFlow Spezifikationen ausgetestet werden. Die Bereitstellung einer solchen Umgebung ist aber relativ aufwendig, sollte aber mit Technologien wie Docker, um mehrere Hosts bereitstellen zu können, und der Fähigkeit, dass auf einem System mehrere Open vSwitch Instanzen installiert werden können möglich sein.

• SDN Übung mit HP Switches

Auf dem im Testbed verwendeten HP Switch 5130 ist es möglich mehrere logische OpenFlow Switches zu erzeugen, welche jeweils von unterschiedlichen SDN Controllern gesteuert werden können. In diesem Setup wäre es somit möglich das mehrere Studenten den gleichen Switch verwenden und trotzdem unabhängig voneinander arbeiten könnten. Jeder Student erhält in diesem Fall einen Controller, der auch virtuell zur Verfügung gestellt werden kann und ein oder mehrere logische OpenFlow Switch Instanzen mit mehrere OpenFlow Ports. Diese Ports können dann mit Endgeräten bestückt werden, wie Laborcomputer oder dem Studentennotebook oder auch für die Verbindung zweier logischer Switches genutzt werden. Dieses Setup ist nur mit zusätzlichen finanziellen Mitteln realisierbar, hat aber den Vorteil, dass es für den Studenten auf einfachste Weise möglich ist, die Topologie zu verändern, indem Kabel einfach umgesteckt werden können.

Hochschule Luzern Bericht - Ausblick Technik & Architektur

49

6 Ausblick

6.1 Aktuelle Stand von Software Defined Network Am besten kann der aktuelle Stand von Software Defined Network mithilfe des Gartner Hype Cycles aufgezeigt werden. Gartner ist ein Marktforschungsunternehmen, welches sich auf die Entwicklungen in der Informatikbranche spezialisiert hat. Der vorliegende Hype Cycle ist im Juli 2015 veröffentlicht worden kann wie folgt gelesen werden.

Abbildung 25: Gartner Hype Cycle [46]

Software Defined Networks stehen kurz vor dem Tal der Enttäuschungen, da die Technologie nicht alle Erwartungen erfüllen konnte und die Berichterstattung darüber hat abgenommen. Jedoch stellt Gartner das Plateau der Produktivität in fünf bis zehn Jahren in Aussicht. Bis zu dahin werden die Vorteile von Software Defined Network anerkannt und akzeptiert sein und sich zu einer soliden und reifen Technologie weiterentwickelt haben. Für Network Function Virtualization was sich zum Zeitpunkt der Veröffentlichung des Hype Cycles in voller Fahrt Richtung Tal der Enttäuschungen bewegt hat, wird bereits eine Marktreife in zwei bis fünf Jahren vorausgesagt. Da sich möglicherweise viele Firmen und Institution bereits zu Zeiten des Gipfels der überzogenen Erwartungen mit Software Defined Networks beschäftigt haben, konnte festgestellt werden, was dies an administrativem Aufwand bedeutet, das ganze Netzwerk via Software aufzubauen, zu warten und Änderungen vorzunehmen. Daraus wird man erkannt haben, dass dafür spezielle Applikationen notwendig sind, die im Hype Cycle als SDN Applications aufgeführt sind. Dieser Trend steht kurz vor dem Gipfel der überzogenen Erwartungen, da man sie wohl als Lösungen für alle Probleme, die man zum jetzigen Zeitpunkt noch mit Software Defined Network hat, ansieht. Deshalb ist es nicht verwunderlich das SDN Applications das Plateau der Produktivität zum gleichen Zeitpunkt wie Software Defined Network erreichen werden.


50

Ebenfalls interessant ist der Vergleich von OpenFlow, VMware NSX und Cisco ACI basierend auf Google Trends. Seit 2008 ist das Interesse für OpenFlow stetig gestiegen, bis 2012 der Höhepunkt erreicht wurde, von da an geht der Trend aber deutlich zurück. Bei VMware und Cisco hingegen, welche erst viel später in den SDN Markt eingestiegen sind, ist der Trend bis heute steigend. Dies ist wohl darauf zurückzuführen, dass sowohl VMware wie auch Cisco eine stabile und vollumfängliche Lösung anbieten können, wovon OpenFlow mit OpenDaylight noch nicht über den Entwicklungsstatus hinausgekommen ist.

Abbildung 26: Trend SDN [47]

Basierend auf den Erfahrungen, die innerhalb dieser Arbeit gemacht werden konnten, ist definitiv zu sagen, dass sich Software Defined Network mit OpenFlow und dem OpenDaylight SDN Controller noch immer in der Entwicklung befindet und noch keine Reife aufweist, wie es für eine produktive Nutzung nötig wäre. Selbstverständlich gibt es zum jetzigen Zeitpunkt bereits erfolgreiche Implementationen, wie beispielsweise bei Google oder auch Facebook, dafür muss aber momentan noch sehr viel selbst entwickelt werden, um ein System ausarbeiten zu können, welches für den entsprechenden Verwendungszweck zugeschnitten ist.

6.2 Offene Problemstellungen In der Arbeit konnten einige Probleme und offene Fragestellungen festgestellt werden, weshalb Software Defined Network mit OpenFlow möglicherweise den Durchbruch noch nicht geschafft hat, die erst noch zu lösen, respektive zu klären sind. Einige davon werden in folgenden Kapiteln angesprochen.

6.2.1 Adressierung Ist es mit OpenFlow im internen Netzwerk noch nötig mehrere Subnetzwerke zu definieren, statt sämtliche Geräte in ein 10.0.0.0/8 Netz zu integrieren und nur eine Adresse fürs Routing zu definieren? Denn mit OpenFlow wird die Kommunikation zwischen zwei Endknoten mittels eines Flows sichergestellt, der von Layer 1 bis Layer 4 definiert, was für eine Kommunikation zwischen den beiden Endknoten stattfinden darf. Sind IP-Adressen in OpenFlow überhaupt noch die primären Identifizierungsmerkmale eines Endknotens, oder ist es


51

vielmehr ein DNS Name oder gar die MAC Adresse? Denn OpenFlow ermöglicht das Überschreiben von Source und Destination MAC und IP-Adressen, damit wären neue Ansätze möglich. Interessant wird sicherlich, was namhafte Firmen für Best Practise Ansätze diesbezüglich empfehlen werden.

6.2.2 Protokolle In einem komplett auf OpenFlow laufenden Netzwerk, werden einige etablierte Netzwerkprotokolle nicht mehr benötigt werden, wie beispielsweise das Spanning Tree Protocol oder auch Routing Protokolle wie OPSF, EIGRP und RIP. Das Spanning Tree Protocol verhinderte durch das Erkennen und Deaktivieren von Loops im Netzwerk sogenannte Broadcast Storms. Da in OpenFlow aber mit Flows genau definiert werden kann, auf welchen Netzwerklinks Daten Hin und Her gesendet werden und zwischen zwei Knoten eine Punkt-zu-Punkt Verbindung aufgebaut werden kann, sind physische Loops zulässig. Für Broadcasts kann mithilfe von OpenFlow und dem SDN Controller eine Flutung des gesamten Netzwerks enorm eingeschränkt werden. So können grundsätzlich alle Broadcasts an den SDN Controller gesendet werden, welcher dann das Paket analysiert und nur dem oder den entsprechenden Endknoten zukommen lassen. Im Falle des Address Resolution Protocols kann dies bereits auf Switch Ebene verarbeitet werden. So kann auf dem Switch die angeforderte MAC Adresse einer entsprechenden IP-Adresse eines ARP Pakets ausgelesen werden und das Paket entsprechend nur dem Endknoten zukommen lassen, der darauf auch eine Antwort geben kann und darf. Da der SDN Controller die komplette Topologie kennt und statt Routing Tabellen nur noch Flow Tabellen genutzt werden, die durch den Controller modifiziert und erstellt werden, ist die Nutzung von Routing Protokollen nicht mehr notwendig, die es Netzwerkgeräten ermöglicht haben untereinander Routinginformationen auszutauschen, um Pakete auf möglichst effiziente Weise an das entsprechende Ziel zu übermitteln. Diese Verantwortung wird nun den SDN Controller zugeschrieben, respektive einer Softwarekomponente, die dem SDN Controller die entsprechenden Steuerbefehle übermittelt.

6.2.3 Interoperabilität Grundsätzlich ist anzunehmen, dass OpenFlow standardisiert ist und jeder Hersteller der OpenFlow fähige Geräte anbietet, diesen Standard auch gleich implementiert. Es konnte aber festgestellt werden, dass dem nicht so ist. So können auf dem HP 5130 Switch keine Regeln für das Matchen von ARP Paketen implementiert werden, auf dem Brocade ICX 7150 kein Source IP-Adresse Matching hinterlegt werden und auf dem Brocade ICX 7750 werden keine Meters unterstützt, gemäss der Compatibility Matrix von Brocade. Es kann auch festgestellt werden, dass je nach Firmware Version einige Funktionen implementiert sind und in der nächsten Version nicht mehr. Solche Problematiken machen es einem Entwickler, der den gesamten Funktionsumfang von OpenFlow nutzen möchte, praktisch unmöglich entsprechende Software zu entwickeln, die mit allen OpenFlow Switches funktionieren. Zum jetzigen Zeitpunkt ist nur empfehlenswert, sich einen einzigen Typ von OpenFlow Switch eines Herstellers mit einer entsprechenden Firmware zu beschaffen, der jene Funktionalität zur Verfügung stellt, die man für die Umsetzung des vordefinierten Anwendungsszenarios benötigt.

6.2.4 Customization Mit SDN werden viele unterschiedliche Anwendungsszenarien beworben, was man aber für deren Umsetzung erhält, ist keine vollumfängliche Lösung, sondern eine Sammlung von Application Programming Interfaces auf dem SDN Controller. Damit ist


52

grundsätzlich alles möglich, bedarf aber sehr viel Eigenentwicklung für die korrekte Integration in die eigene Netzwerkinfrastruktur. Mit OpenDaylight werden bereits einige Features angeboten, die sich auf das eine oder andere Anwendungsszenario spezialisiert haben und so die Eigenentwicklung entsprechend mindern könnten. Jedoch benötigt jedes Feature entsprechende Voraussetzung an Southbound Interfaces und die Kompatibilität unter den verschiedenen Features kann nicht gewährleistet werden. Die aktuelle Liste kann hier unter folgendem Link eingesehen werden: https://www.opendaylight.org/opendaylight-features-list Auf den ersten Blick interessant hören sich Group Base Policy und Virtual Tenant Network vielversprechend an. Group Based Policy (GBP) ermöglicht ein applikationszentriertes Policy Modell, um die Konnektivität zwischen einzelnen Applikation sicherstellen zu können, ohne die unterliegende Netzwerkinfrastruktur zu kennen. Dieser Ansatz ist vergleichbar mit Cisco ACI. Interessant dabei ist auch, das vier von fünf Entwicklern davon für Cisco arbeiten. Virtual Tenant Network (VTN) ermöglicht einem Benutzer die Erstellung von virtuellen Layer 2 und Layer 3 Netzwerken, welche dann automatisch auf der unterliegenden Netzwerkinfrastruktur abgebildet werden können. VTN ist mandantenfähig und bietet eine Integration in OpenStack an. Bei beiden Projekten handelt es sich um OpenSource Projekte, die jeweils von fünf Entwicklern unterhalten werden, weshalb von einem produktiven Einsatz abgeraten werden muss.

6.2.5 Adaptierung neuer Standards Wie man am Beispiel von Brocade und auch HP sehen kann, ist die Implementierung des OpenFlow Standards nicht einfach, sonst würde dies auch im vollen Funktionsumfang zur Verfügung stehen. Die aktuellste Version von OpenFlow ist 1.5.1, welche im April 2015 veröffentlicht wurde. Die meisten Switch Hersteller haben aber in ihren aktuellsten Produktreihen noch OpenFlow Version 1.3 implementiert, welche im Juni 2012 veröffentlicht wurde. Weiter bietet auch der OpenDaylight SDN Controller nur eine Kompatibilität mit OpenFlow Version 1.3.x an. Zwischen OpenFlow Version 1.3 und 1.5 wurden im Standard einige neue Features eingebaut, die durchwegs nutzbringend sind. So existiert ein Mechanismus, der das Volllaufen von Flow Tables verhindert, TCP Flags, wie SYN, ACK, FIN können gematcht werden und es stehen mehr Monitoring und Statistikinstrumenten für Flow zur Verfügung, um nur einige Punkte zu nennen. Solche neuen Features können für den Entwickler von SDN Applikation einerseits neue Einsatzszenarien ermöglichen, andererseits können auch robustere, stabilere und auch weniger komplexe Applikationen erstellt werden. Durch den halbjährlich neu erscheinenden OpenDaylight SDN Controller und einen OpenFlow Standard, der alle zwei bis drei Jahre ergänzt wird, wird es dem Entwickler schwergemacht, zu entscheiden, wofür er seine Applikationen erstellen soll und ob dies auch zukunftssicher ist.


53

6.3 Nachteile SDN mit OpenFlow • Sicherheit

Je nach Anwendung von SDN ist es zwingend notwendig, dass der SDN Controller stets zur Verfügung steht. Wenn es einem Angreifer gelingt den SDN Controller ausser Gefecht zu setzen, so steht das gesamt Software Defined Network still und keine Kommunikation ist mehr möglich.

• Kosten Um SDN effektiv nutzen zu können, sind Anschaffungen in neue Hardware notwendig, die OpenFlow unterstützen. Weiter sind je nach dem Lizenzkosten für einen SDN Controller notwendig und auch Lizenzkosten für SDN Applikationen die auf SDN Controller oder auch auf anderen Geräten betrieben werden müssen.

• Integration Die Integration von SDN kann sich für viele Unternehmen relativ schwer gestalten. Jedoch muss SDN nicht von heute auf morgen umgesetzt sein, sondern kann generell auf entsprechender Hardware parallel zum normalen Betrieb aufgeschaltet werden (Hybrid Mode) und kann danach Schritt für Schritt umgesetzt werden. Jedoch stehen zum jetzigen Zeitpunkt noch keine allgemeingültigen Integrationskonzepte bereit.

• Know-how Für die Etablierung und den Betrieb einer SDN Lösung im Unternehmen müssen die entsprechenden Mitarbeiter einerseits Wissen über die Technologie aufbauen, andererseits muss auch die komplette Netzwerkinfrastruktur und die Bedürfnisse jeder Applikation ans Netzwerk bekannt sein.

• Reifegrad Obwohl OpenFlow schon seit über 8 Jahren existiert, befindet man sich noch immer in einem frühen Entwicklungsstadium. Wer zum jetzigen Zeitpunkt SDN mit OpenFlow und OpenDaylight nutzen zu möchte, muss mit Problemen, Kompatibilitätsschwierigkeiten, ändernden Standards, fehlender Stabilität und vor allem sehr viel Zeitaufwand zu Recht kommen.

• Hoher Aufwand Mit einem SDN Controller und OpenFlow fähigen Netzwerkgeräten kann noch lange nicht von SDN gesprochen werden. Vorteile wie dynamisch, voll automatisierte Netzwerkadministration, Netzwerkoptimierung für eine höhere Netzwerkauslastung, schnellere Bereitstellung des Netzwerks, agiles, flexibles und skalierbares Netzwerk und weniger Personalkosten können erst durch Entwicklung von SDN Applikation ermöglicht werden, die Funktionen von OpenFlow voll und ganz ausnutzen.

• Vendor Locking Da die Interoperabilität unter den verschiedenen Netzwerkgeräte Hersteller noch nicht gewährleistet werden kann, müsste man sich dies bezüglich auf einen Hersteller einigen. Meist stellt der Hersteller auch gleichen eine für seine Produkte optimalen SDN Controller bereit. Wenn man nun die entsprechenden SDN Applikationen entwickelt, die auf den SDN Controller zugeschnitten sind, ist man danach immer vom entsprechenden SDN Controller abhängig und somit auch meist von der entsprechenden Hardware. Ein Problem hierbei sind die noch nicht standardisierten Northbound Interfaces, die von Hersteller zu Hersteller unterschiedliche sein können. Mit dem OpenDaylight SDN Controller hat man versucht, diesem Problem entgegen zu wirken, und viele Hersteller nutzen diese auch für ihren kommerziellen SDN Controller, jedoch sind dies noch längst nicht alle.


54

6.4 Empfehlung Stand heute Software Defined Network steckt gemäss heutigem Stand noch immer in den Kinderschuhen. Bereits vor einigen Jahren wurden die entsprechenden Konzepte erarbeitet, konnte aber auf dem kommerziellen Markt nur in Einzelfällen Fuss fassen. Mit VMware NSX und Cisco ACI stehen Alternativen zur OpenFlow und OpenDaylight Implementation auf dem Markt bereit, welche diese Hürde bereits gemeistert haben und zu einem essenziellen Bestandteil in Data Centers geworden sind. Zum jetzigen Zeitpunkt darf man sich nicht von den Erfolgsgeschichten grosser Firmen mit Software Defined Networks blenden lassen, denn dahinter steckt noch sehr viel Aufwand, was für normalgrosse Unternehmen nicht rentabel wäre. Es muss auch ganz klar evaluiert werden, ob Software Defined Networks tatsächlich einen Mehrwert für das entsprechende Unternehmen bieten oder nur „Nice to Have“ sind. Von einer kompletten Implementation von SDN mit OpenFlow und OpenDaylight in einem Unternehmen ist zum jetzigen Zeitpunkt ganz klar abzuraten. Einerseits muss sehr viel Eigenleistung erbracht werden und entsprechende Automatisierungen und schnelleres zur Verfügung stellen des Netzwerks erreichen zu können. Diese Eigenleistung wird insbesondre auf die Ausnutzungen der SDN Controller Northbound API erbracht, welche nicht standarisiert sind und somit von SDN Controller Hersteller zu Hersteller verschieden sein kann. Da es sich bei den SDN Controller Northbound APIs um ziemliche Low Level APIs handelt, die sich am OpenFlow Standard orientieren, ist es durchaus denkbar, dass in den nächsten Jahren Applikationen basierend auf dem SDN Controller erscheinen werden, die ein einfacheres Administrieren des Netzwerks auf einer höheren Ebene zulassen und auf intelligente Weise die Vorteile von OpenFlow vollständig ausnutzen kann, ohne dass der Administrator OpenFlow verstehen muss. Bestrebungen in diese Richtungen sind bereits jetzt mit dem HP SDN Appstore und der hohen Anzahl an OpenDaylight Features feststellbar. Sobald diese Applikationen zur Verfügung stehen, die sämtliche Anforderungen an Software Defined Networks abdecken, auf einfache Weise administrierbar, finanziell erschwinglich sind und die entsprechende Stabilität aufweisen, wird SDN mit OpenFlow und OpenDaylight bereit sein, für eine grossflächige Implementation. Bis dahin aber ist man mit VMware NSX oder Cisco ACI besser bedient, die den notwendigen Reifegrad und Stabilität aufweisen.

Hochschule Luzern Bericht - Quellenverzeichnis Technik & Architektur

55

7 Quellenverzeichnis

[1] „Software-Defined-Networking,“ [Online]. Available: http://software-defined-network.com/uber-sdn. [Zugriff am 25 03 2016].

[2] „Technische Universität München,“ 01 02 2013. [Online]. Available:http://www.net.in.tum.de/fileadmin/TUM/NET/NET-2013-02-1/NET-2013-02-1_09.pdf. [Zugriff am 04 04 2016].

[3] „Paessler,“ [Online]. Available: https://www.de.paessler.com/software-defined-networking.

[4] „ITWissen,“ [Online]. Available:http://www.itwissen.info/definition/lexikon/data-plane.html. [Zugriff am 24 032016].

[5] „Frauenhofer,“ [Online]. Available: https://www.sit.fraunhofer.de/de/orchsec/.[Zugriff am 25 03 2016].

[6] „Brocade.com,“ 01 12 2015. [Online]. Available:http://blogs.brocade.com/t5/Brocade-Deutschland-Blog/Brocade-SDN-Controller-2-0-warum-Open-Source-SDN-im-Netzwerk/ba-p/79421.

[7] „inside-it.ch,“ 11 07 2013. [Online]. Available: http://www.inside-it.ch/articles/34366. [Zugriff am 25 03 2016].

[8] „Hot Hardware,“ 23 06 2013. [Online]. Available:http://hothardware.com/news/intel-reimagines-the-data-center-with-new-avoton-server-architecture-softwaredefined-services. [Zugriff am 25 03 2016].

[9] „TecChannel,“ [Online]. Available:http://www.tecchannel.de/netzwerk/management/2040170/software_defined_networks_flexibles_netzwerk_mit_sdn/index3.html. [Zugriff am 19 03 2016].

[10] „SearchNetworking.de,“ 06 2014. [Online]. Available:http://www.searchnetworking.de/news/2240223892/Security-Schwachstellen-bei-Software-defined-Networking-SDN. [Zugriff am 19 03 2016].

[11] „PacketLife.net,“ 2 05 2013. [Online]. Available:http://packetlife.net/blog/2013/may/2/what-hell-sdn/. [Zugriff am 25 03 2016].

[12] „IEEE Xplore,“ 10 10 2013. [Online]. Available:http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6680567. [Zugriff am 13 06 2016].

[13] „TU Chemnitz,“ 18 09 2015. [Online]. Available: https://www.tu-chemnitz.de/informatik/ST/de/forschung/projects/netide-55fbb90c10bd9.[Zugriff am 13 06 2016].

[14] „Uni Ulm,“ [Online]. Available: https://www.uni-ulm.de/fileadmin/website_uni_ulm/iui.inst.200/files/publikationen/Hock2015.pdf. [Zugriff am 15 03 2016].

[15] „yuba.stanford.edu,“ [Online]. Available:http://yuba.stanford.edu/cs244wiki/index.php/Overview. [Zugriff am 06 042016].

[16] „Open Networking Foundation,“ [Online]. Available:https://www.opennetworking.org/sdn-openflow-products?limitstart=0. [Zugriffam 05 04 2016].

[17] „SearchNetworking.de,“ 12 2014. [Online]. Available:


56

http://www.searchnetworking.de/tipp/So-bauen-Sie-ein-Netzwerk-fuer-den-Test-von-Open-vSwitch-auf. [Zugriff am 07 06 2016].

[18] „Decoit,“ [Online]. Available:https://www.decoit.de/de/artikel.html?file=files/DECOIT/pdf/artikel/NET0413_Virtualisierung.pdf. [Zugriff am 05 06 2016].

[19] „Linux-Magazin,“ [Online]. Available: http://www.linux-magazin.de/Ausgaben/2014/04/Open-Flow/(offset)/4. [Zugriff am 23 04 2016].

[20] Open Networking Foundation, „OpenFlow® Switch Specification 1.3.3,“ 2013.[21] J. L. Jake Collings, „An OpenFlow-based Prototype of SDN-Oriented Stateful

Hardware Firewalls,“ University of North Dakota, 2014.[22] W. H. G.-J. A. Z. Z. Hongxin Hu, „FLOWGUARD Building Robust Firewalls for

Software-Defined Networks,“ Clemson University, Arizona State University, 2014.[23] D. B. Hardeep Uppal, „OpenFlow Based Load Balancing,“ University of Washington.[24] R. Wang, „OpenFlow-Based Load Balancing gone wild,“ Princeton University, 2011. [25] „SearchNetworking.de,“ [Online]. Available:

http://www.searchnetworking.de/news/2240219581/Ciscos-SDN-Protokoll-OpFlex-Konkurrenz-fuer-OpenFlow-und-VMwares-OVSDB. [Zugriff am 05 042016].

[26] „SDXCentral,“ [Online]. Available: https://www.sdxcentral.com/reports/sdn-controllers-report-2015/. [Zugriff am 18 05 2016].

[27] „Technische Universität München,“ 01 08 2014. [Online]. Available:http://www.net.in.tum.de/fileadmin/TUM/NET/NET-2014-08-1/NET-2014-08-1_13.pdf. [Zugriff am 08 06 2016].

[28] C. Fuchs, „Northbound API Requirements for SDN,“ Technische UniversitätMünchen, 2014.

[29] M. P. W. L. T. J. I. Farzaneh Pakzad, „Efficient Topology Discovery in SoftwareDefined Networks,“ University of Queensland, 2014.

[30] „CircleID,“ 18 01 2013. [Online]. Available:http://www.circleid.com/posts/20130118_software_defined_data_centre_needs_dns/. [Zugriff am 25 05 2016].

[31] F. K. Vishal Thapar, „DHCPServiceinODL,“ India, 2015.[32] Wedge Networks, „Wedge Whitepaper - Service Insertion OpenFlow,“ 2012.[33] Google, Inc, „Google_B4_Experience“.[34] D. K. D. M. Ramki Krishnan, „DDos_Mitigation“.[35] „Broade.com,“ 21 12 2015. [Online]. Available:

http://community.brocade.com/t5/Brocade-Deutschland-Blog/Mit-dem-Brocade-Flow-Optimizer-das-gesamte-Potenzial-von-SDN/ba-p/82937. [Zugriff am 02 062016].

[36] Firefly Communications, Cisco ACI Test Drive, 2015.[37] M. P. Lucien Avramov, The Policy Driven Data Center with ACI: Architecture,

Concepts, and Methodology, Indianapolis: Cisco Press, 2015.[38] „Cisco.com,“ 07 11 2013. [Online]. Available: http://gblogs.cisco.com/fr-

datacenter/wp-content/uploads/sites/14/2013/11/ACI-infra.jpg. [Zugriff am 2905 2016].

[39] „vmware.com,“ 23 06 2013. [Online]. Available:


57

http://www.vmware.com/ch/company/news/releases/vmw-nicira-07-23-12.html. [Zugriff am 02 06 2016].

[40] „Network Inferno,“ 2014. [Online]. Available: http://networkinferno.net/nsx-compendium. [Zugriff am 02 06 2016].

[41] VMware, Inc., „VMware-NSX-Datasheet,“ Palo Alto, 2013.[42] „The VMware NSX Network Virtualization Platform,“ VMware, Inc., Palo Alto, 2013. [43] „CCCP Software,“ [Online]. Available: http://www.ccpsoft.de/software/vmware-

nsx/. [Zugriff am 39 05 2016].[44] „CloudFIX,“ 09 10 2014. [Online]. Available:

http://www.cloudfix.nl/2014/10/09/sdn-vmware-nsx-part-1/. [Zugriff am 30 052016].

[45] „SNArchs.com,“ 22 12 2015. [Online]. Available:http://www.snarchs.com/2015/12/sdn-wars-cisco-aci-vs-vmware-nsx.html.[Zugriff am 30 05 2016].

[46] „The Register,“ [Online]. Available:http://www.theregister.co.uk/2015/07/29/sdn_enthusiasm_dives_says_gartner/.[Zugriff am 15 05 2016].

[47] „google.com,“ [Online]. Available: https://www.google.com/trends/. [Zugriff am01 06 2016].

[48] „Wikipedia.com,“ 05 2016. [Online]. Available:https://de.wikipedia.org/wiki/SFlow. [Zugriff am 02 06 2016].

[49] „Wikipedia.com,“ [Online]. Available:https://de.wikipedia.org/wiki/JavaScript_Object_Notation. [Zugriff am 29 052016].

[50] „Wikipedia.com,“ [Online]. Available:https://de.wikipedia.org/wiki/Extensible_Markup_Language. [Zugriff am 29 052016].

[51] „Wikipedia.com,“ [Online]. Available:https://de.wikipedia.org/wiki/Hypertext_Transfer_Protocol. [Zugriff am 29 052016].

Hochschule Luzern

Technik & Architektur



Projekt Software Defined Network im EnterpriseLab Dokument Testbed Dokumentation Schule Hochschule Luzern Technik & Architektur Modul TA.BA_BAA+INF.F1601 Projektteam Bachmann Sandro





Änderungsprotokoll Version Datum Autor Beschreibung 0.1 02.04.16 BAS Initialisierung 0.2 09.05.16 MAH Überarbeitung 0.3 08.06.16 MAH Open vSwitch hinzugefügt 0.4 13.06.16 BAS Übearbeitung 0.5 14.06.16 BAS Ergänzung ARP und LLDP 0.6 15.06.16 BAS Ergänzung Latenztests 1.0 16.06.16 BAS Finalisierung

Inhaltsverzeichnis 1 Begriffe und Abkürzungen ..................................................................................................... 1

2 Installation ................................................................................................................................... 2 2.1 SDN Controller ............................................................................................................................... 2 2.2 Control Plane .................................................................................................................................. 4 2.3 Data Plane ........................................................................................................................................ 5 2.4 Endknoten ....................................................................................................................................... 6

3 Szenarien ...................................................................................................................................... 7 3.1 Kommunikation zweier Endknoten über einen Switch .................................................. 7 3.2 Kommunikation zweier Endknoten über zwei Switches ............................................. 15 3.3 Bandbreitenbeschränkung .................................................................................................... 23 3.4 Flows über Northbound API per RESTCONF managen ................................................. 30 3.5 Eigene SDN Test App schreiben ............................................................................................ 34 3.6 Erweiterung von SDN um Open vSwitch ............................................................................ 35 3.7 Topologieerkennung in Software Defined Networks ................................................... 38 3.8 ARP in Software Defined Networks ..................................................................................... 41 3.9 Latenz in SDN ............................................................................................................................... 47

Abbildungsverzeichnis Abbildung 1: Aufbau Szenario 1 .............................................................................................................................................................. 7 Abbildung 2: L2 Flow Modification Host B – Host A ....................................................................................................................... 8 Abbildung 3: L2 Flow Modification Host A – Host B ....................................................................................................................... 9 Abbildung 4: L3 Flow Modification Host B - Host A ...................................................................................................................... 10 Abbildung 5: L3 Flow Modification Host A - Host B ...................................................................................................................... 11 Abbildung 6: Path Flow Modification Host B - Host A .................................................................................................................. 12 Abbildung 7: Path Flow Modification Host A - Host B.................................................................................................................. 13 Abbildung 8: Versuchsaufbau Szenario 2 .......................................................................................................................................... 15 Abbildung 9: Versuchsaufbau Bandbreitenbeschränkung ........................................................................................................ 23 Abbildung 10: Meter Definition .............................................................................................................................................................. 24 Abbildung 11: Meter Add .......................................................................................................................................................................... 24 Abbildung 12: Änderung der Bandbreite ........................................................................................................................................... 26 Abbildung 13: Meter Modification ........................................................................................................................................................ 26 Abbildung 14: HTTP Meter ....................................................................................................................................................................... 27 Abbildung 15: SCP Meter ........................................................................................................................................................................... 27 Abbildung 16: Postman Authorization ............................................................................................................................................... 30 Abbildung 17: Postman Headers ........................................................................................................................................................... 30 Abbildung 18: Postman Send ................................................................................................................................................................... 31 Abbildung 19: Postman Body .................................................................................................................................................................. 31 Abbildung 20: Postman Resultat auf Switch .................................................................................................................................... 32 Abbildung 21: Flow anzeigen .................................................................................................................................................................. 32 Abbildung 22: Flow löschen ..................................................................................................................................................................... 32 Abbildung 23: Alle Flows löschen .......................................................................................................................................................... 32 Abbildung 24: Gesamte Flow Statistik anzeigen ............................................................................................................................ 32 Abbildung 25: Flow Statistik pro Flow anzeigen ............................................................................................................................ 32 Abbildung 26: Flow Statistik Resultat ................................................................................................................................................. 33 Abbildung 27: SDN Applikation GUI ..................................................................................................................................................... 34 Abbildung 28: Versuchsaufbau mit Open vSwitch ......................................................................................................................... 35 Abbildung 29: Versuchsaufbau Topologie ......................................................................................................................................... 36 Abbildung 30: Open vSwitch Flows ....................................................................................................................................................... 36 Abbildung 31: Open vSwitch Portbelegung ...................................................................................................................................... 36 Abbildung 32: Topologieerkennung ..................................................................................................................................................... 38 Abbildung 33: LLDP Packet OUT ........................................................................................................................................................... 39 Abbildung 34: LLDP Packet IN ............................................................................................................................................................... 39 Abbildung 35: Versuchsaufbau ARP ..................................................................................................................................................... 41 Abbildung 36: ARP Packet IN Host A ................................................................................................................................................... 42 Abbildung 37: ARP Packet OUT Host B ............................................................................................................................................... 42 Abbildung 38: ARP Packet IN Host B ................................................................................................................................................... 43 Abbildung 39: ARP Packet OUT Host A ............................................................................................................................................... 43 Abbildung 40: Hosterkennung ................................................................................................................................................................ 44 Abbildung 41: Redundantes ARP Packet ............................................................................................................................................ 45 Abbildung 42: ARP Flow Modification Error .................................................................................................................................... 46 Abbildung 43: Latenztest .......................................................................................................................................................................... 48

Tabellenverzeichnis Tabelle 1: Begriffsdefinitionen ______________________________________________________________________________________ 1 Tabelle 2: Abkürzungsdefinitionen _________________________________________________________________________________ 1 Tabelle 3: Szenario 1 Data Plane ___________________________________________________________________________________ 7 Tabelle 4: Szenario 1 Control Plane ________________________________________________________________________________ 7 Tabelle 5: Szenario 2 Data Plane _________________________________________________________________________________ 15 Tabelle 6: Szenario 2 Control Plane ______________________________________________________________________________ 15 Tabelle 7: Szenario 2 Redundante Switch Verbindung __________________________________________________________ 17 Tabelle 8: Groups Data Plane _____________________________________________________________________________________ 19 Tabelle 9: Groups Switch Verbindung ____________________________________________________________________________ 19 Tabelle 10: Groups Control Plane _________________________________________________________________________________ 19 Tabelle 11: Bandbreitenbeschränkung Data Plane ______________________________________________________________ 23 Tabelle 12: Bandbreitenbeschränkung Control Plane ___________________________________________________________ 23 Tabelle 13: ARP Versucht Host Setup _____________________________________________________________________________ 41 Tabelle 14: Nachteile ARP Varianten _____________________________________________________________________________ 45 Tabelle 15: Latenztest Ergebnis __________________________________________________________________________________ 48

Hochschule Luzern Testbed Dokumentation - Begriffe und Abkürzungen Technik & Architektur

1

1 Begriffe und Abkürzungen Begriff Erklärung Hypervisor Anbieter eine abstrahierten Hardware Schicht, für den Betrieb von

virtuellen Maschinen Layer Layer bezeichnet eine Schicht gemäss dem Open Systems

Interconnection Model kurz OSI-Modell OpenDaylight OpenSource SDN Controller OpenFlow Kommunikationsprotokoll zwischen Netzwerkgeräten und SDN

Controller Raspberry Pi Günstiger Einplatinencomputer Ubuntu Weitverbreitetes OpenSource Betriebssystem VirtualBox Virtualisierungssoftware von Oracle Wireshark Programm zur Analyse von Netzwerkverkehr auf Paketebene Tabelle 1: Begriffsdefinitionen

Abkürzung Erklärung API Application Programming Interface ARP Address Resolution Protocol GUI Graphical User Interface HP Hewlett Packard HTTP Hypertext Transfer Protocol IP Internet Protocol JSON JavaScript Object Notation LLDP Link Layer Discovery Protocol MAC Media Access Control REST Representational State Transfer SCP Secure Copy SDN Software Defined Network SSH Secure Shell URL Uniform Resource Locator VLAN Virtual Local Area Network XML Extensible Markup Language Tabelle 2: Abkürzungsdefinitionen

Hochschule Luzern Testbed Dokumentation - Installation Technik & Architektur

2

2 Installation

2.1 SDN Controller

2.1.1 Brocade SDN Controller Um den Brocade SDN Controller v3.0.0 auf einem Ubuntu System zu installieren, geht man wie folgt vor. Der Link für den Download des Controllers muss auf der Homepage von Brocade generiert werden.

• Voranforderungen Ubuntu System: sudo apt-get update sudo apt-get install dpkg-dev curl -sL https://deb.nodesource.com/setup_4.x | sudo bash - apt-get install nodej

• Download Brocade SDN Controller

wget «http://esd1.brocade.com/s/software/downloads/Brocade%20SDN%20Controller/Evaluation/SDN-Controller-dist-3.0.0-deb.tar.gz?e=1462541105&h=66c8a2d0bbdeb99d3861f4b198ff6125»

• Umbenennen

mv «SDN-Controller-dist-3.0.0-deb.tar.gz?e=1462541105&h=66c8a2d0bbdeb99d3861f4b198ff6125» «SDN-Controller-dist-3.0.0-deb.tar.gz»

• Entpacken

tar -xvf SDN-Controller-dist-3.0.0-deb.tar.gz

• Installieren sudo SDN-Controller-dist-3.0.0/install

• Packages installieren (sind standardmässig bereits installiert)

z.B: sudo apt-get install brcd-bsc-ext-openflow

• Controller starten sudo service brcd-bsc start sudo service brcd-ui start

Die offizielle Installationsanleitung für den Brocade SDN Controller findet man unter folgendem Link: http://www.brocade.com/content/html/en/sdn-controller/3.0.0/software-installation/index.html


3

2.1.2 OpenDaylight SDN Controller Um den OpenDaylight SDN Controller 0.4.0 Beryllium auf einem Ubuntu System zu installieren, geht man wie folgt vor. Der aktuelle Link für den Download des Controllers kann auf der Seite von OpenDaylight gefunden werden.

• Voranforderungen Ubuntu System: apt-get update apt-get install maven

• Download OpenDayLight Controller wget https://nexus.opendaylight.org/content/groups/public/org/opendaylight/integration/distribution-karaf/0.4.0-Beryllium/distribution-karaf-0.4.0-Beryllium.tar.gz

• Entpacken xzvf distribution-karaf-0.4.0-Beryllium.tar.gz

• Datei verschieben mv distribution-karaf-0.4.0-Beryllium /opt/ cd /opt/distribution-karaf-0.4.0-Beryllium/bin/

• Controller installieren

ln -s /opt/distribution-karaf-0.4.0-Beryllium/bin/karaf-service /etc/init.d/

• Controller starten /etc/init.d/karaf-service start


4

2.2 Control Plane Um OpenFlow nutzen zu können, muss zuerst die Konnektivität zwischen OpenFlow Switches und SDN Controller gewährleistet werden. Die zentrale Role übernimmt hier der Brocade Switch ICX 6610, der sowohl mit dem SDN Controller verbunden ist, wie auch mit allen anderen Switches.

2.2.1 Brocade Für die Control Plane wurde das VLAN 99 auf dem Brocade ICX6610 eingerichtet.

> enable # conf t (config)# vlan 99

Hinzufügen des Interfaces auf welchem der SDN Controller angeschlossen ist: (config-vlan-99)# untagged ethernet 1/1/47

Hinzufügen von Interfaces, welche mit anderen Switches verbunden sind: (config-vlan-99)# tagged ethernet 1/1/44 to 1/1/46

Hinzufügen eines Routing Interfaces (config-vlan-99)# router-interface ve 1

Konfigurieren des Routing Interfaces (config-vif-1)# ip address 192.168.1.1 255.255.255.0

Nun kann OpenFlow auf dem Switch aktiviert werden und die Verbindung zwischen OpenFlow Switch und SDN Controller ist gewährleistet:

(config)# openflow enable ofv130 (config)# openflow controller ip-address 192.168.1.10 no-ssl (config)# openflow default-behavior send-to-controller

Um überprüfen zu können, ob die Verbindung zwischen dem Switch und dem SDN Controller funktioniert, wird folgender Befehl ausgeführt:

>show openflow controller Openflow controller information ------------------------------------------------------------------------- Controller Mode TCP/SSL IP-address Port Status ------------------------------------------------------------------------- 1 (Master) active TCP 192.168.1.10 6633 OPENFLOW_ESTABLISHED

Um nun einen weiteren Brocade Switch mit dem SDN Controller zu verbinden und OpenFlow zu aktivieren sind folgende Schritte notwendig: Zuerst muss eine Patchung zwischen den beiden Switches vorgenommen werden, auf dem bestehenden Switch wird Port 1/1/46 verwendet und auf dem neuen Switch wird der Port 1/1/24 verwendet.

> enable # conf t (config)# vlan 99

Hinzufügen von Interfaces, welche mit anderen Switches verbunden sind: (config-vlan-99)# tagged ethernet 1/1/24

Hinzufügen eines Routing Interfaces (config-vlan-99)# router-interface ve 1

Konfigurieren des Routing Interfaces (config-vif-1)# ip address 192.168.1.5 255.255.255.0

Nun kann OpenFlow auf dem Switch aktiviert werden und die Verbindung zwischen OpenFlow Switch und SDN Controller ist gewährleistet:

(config)# openflow enable ofv130 (config)# openflow controller ip-address 192.168.1.10 no-ssl (config)# openflow default-behavior send-to-controller


5

Mit dem folgenden Befehl kann überprüft werden, ob die Verbindung zum SDN Controller funktioniert:

>show openflow controller Openflow controller information ------------------------------------------------------------------------- Controller Mode TCP/SSL IP-address Port Status ------------------------------------------------------------------------- 1 (Master) active TCP 192.168.1.10 6633 OPENFLOW_ESTABLISHED

2.2.2 HP Um den HP Switch mit der Control Plane und somit auch mit dem SDN Controller zu verbinden sind folgenden Schritte notwendig. Zuerst wird eine Patchung zwischen dem Brocade Switch und dem HP Switch vorgenommen. Hierfür wird auf dem Brocade Switch Port 1/1/45 verwendet und auf dem HP Switch Port 1/0/24. Zuerst wird ein Routing Interface im VLAN 99 eingerichtet:

<sdn-node-03>system-view [sdn-node-03]interface Vlan-interface 99 [sdn-node-03-Vlan-interface99]ip address 192.168.1.3 255.255.255.0

Anschliessend wird Port 1/0/24 dem VLAN hinzugefügt: [sdn-node-03-GigabitEthernet1/0/24] port link-type hybrid [sdn-node-03-GigabitEthernet1/0/24] port hybrid vlan 99 tagged [sdn-node-03-GigabitEthernet1/0/24] port hybrid pvid vlan 99

Nun wird eine OpenFlow Instanz basierend auf dem VLAN 10 erstellt: [sdn-node-03]openflow instance 2 [sdn-node-03-of-inst-2] description HP Switch [sdn-node-03-of-inst-2] datapath-id 3 [sdn-node-03-of-inst-2] classification vlan 10 [sdn-node-03-of-inst-2] controller 1 address ip 192.168.1.10 [sdn-node-03-of-inst-2] active instance

Mit folgendem Befehl kann überprüft werden, ob die Verbindung zum SDN Controller funktioniert:

[sdn-node-03]display openflow instance 2 controller Instance 2 controller information: Reconnect interval: 60 (s) Echo interval : 5 (s) Controller ID : 1 Controller IP address : 192.168.1.10 Controller port : 6633 Controller role : Equal Connect type : TCP Connect state : Established

2.3 Data Plane Um die Data Plane eines Switches definieren zu können, müssen entsprechende Ports für OpenFlow aktiviert werden. In den folgenden zwei Kapiteln wird erklärt, wie dies auf Brocade und HP Switches gewährleistet werden kann.

2.3.1 Brocade Auf einem Brocade Switch wird mit folgendem Befehl ein einzelner Port für OpenFlow freigeschaltet:

>enable #conf t (config)#interface ethernet 1/1/1


6

(config-if-e1000-1/1/1)#openflow enable layer23

2.3.2 HP Auf einem HP Switch muss ein entsprechendes Interface nur dem für OpenFlow aktivierten VLAN zugeordnet werden, was wie folgt umgesetzt werden kann:

<sdn-node-03>system-view [sdn-node-03]interface GigabitEthernet 1/0/1 [sdn-node-03-GigabitEthernet1/0/1]port access vlan 10

2.4 Endknoten Um OpenFlow Konfigurationen testen zu können, sind mehrere Endknoten notwendig. Einerseits wurde eine Maschine mit zwei Interfaces als Firewall/Router eingerichtet, andererseits wurden vier Raspberry Pis eingesetzt.

2.4.1 Firewall Um ein ähnliche Infrastruktur wie in der produktiven Umgebung des Enterprise Labs zur Verfügung zu haben, wurde eine Firewall mit dem Betriebssystem Solaris aufgesetzt. Diese ist über ein Interface mit der produktiven Umgebung des Enterprise Labs verbunden und ist somit vom Hochschule Netzwerk, wie auch via VPN zugänglich. Und zudem ist diese Firewall mit der OpenFlow Data Plane verbunden und fungiert für sämtliche Geräte als Router. Nebst der Standardinstallation wurden folgende Konfigurationen vorgenommen: Konfiguration des Interfaces in die produktive Umgebung:

ipadm create-addr -T static -a 10.176.50.1/24 net2 Definieren des Default Gateways in die produktive Umgebung:

route –p add default 10.176.50.254 Definieren des Interfaces für die Kommunikation mit dem OpenFlow Netzwerk:

ipadm create-addr -t static -a 192.168.10.254/24 net1 Aktivierung von IPv4 forwarding:

routeadm -e ipv4-forwarding -d ipv4-routing -u

2.4.2 Raspberry Pi Als Endknoten wurden nebst der Firewall Raspberry Pis verwendet, welche mit dem Betriebssystem Raspbian ausgestattet sind. Damit diese miteinander kommunizieren können, wurden sie mit statischen IP-Adressen von 192.168.10.1 bis .4 ausgestattet. Um dies sicherstellen zu können, muss einzige die folgende Konfigurationsdatei angepasst werden:

sudo vi /etc/network/interfaces und mit folgenden Informationen bestückt werden. Hier das Beispiel vom Raspberry Pi mit der IP-Adresse 192.168.10.2:

auto eth0 iface eth0 inet static address 192.168.10.2 netmask 255.255.255.0 network 192.168.10.0 broadcast 192.168.10.255 gateway 192.168.10.254

Damit die Änderung sofort wirksam wird, muss folgender Befehl ausgeführt werden: sudo ifdown eth0 && sudo ifup eth0

Hochschule Luzern Testbed Dokumentation - Szenarien Technik & Architektur

7

3 Szenarien

3.1 Kommunikation zweier Endknoten über einen Switch Im folgenden Szenario soll die Kommunikation zweier Endknoten über einen einzelnen Switch realisiert werden.

3.1.1 Aufbau

Abbildung 1: Aufbau Szenario 1

Data Plane Host A Host B IPv4 Adresse 192.168.10.254 192.168.10.1 MAC Adresse 00:1e:68:4a:26:e2 b8:27:eb:4c:43:92 Switch Port 1/1/1 1/1/2 Tabelle 3: Szenario 1 Data Plane

Control Plane SDN Controller Switch BrocadeICX6610-48P

IPv4 Adresse 192.168.1.10 192.168.1.1 MAC Adresse 00:1b:24:2d:be:27 cc:4e:24:3a:3e:3c Tabelle 4: Szenario 1 Control Plane

3.1.2 Konfiguration Auf dem Switch wurden die beiden Interfaces 1/0/1 und 1/0/2 wie folgt konfiguriert:

interface ethernet 1/1/1 no fdp enable no cdp enable no spanning-tree openflow enable layer23 interface ethernet 1/1/2 no fdp enable no cdp enable no spanning-tree openflow enable layer23


8

3.1.3 Testfälle

3.1.3.1 Host zu Host Kommunikation mit Layer 2 Flow Zum jetzigen Zeitpunkt kann Host A mittels einem Ping Host B nicht erreichen. Nun werden folgende beiden Flows mittels SDN Controller definiert.

Flow 1: Switchname: openflow:14721744064491552768 Flowname: HostB-HostA Source MAC: b8:27:eb:4c:43:92 Destination MAC: 00:1e:68:4a:26:e2 Action: Output Port 1/1/1 Flow 2: Switchname: openflow:14721744064491552768 Flowname: HostA-HostB Source MAC: 00:1e:68:4a:26:e2 Destination MAC: b8:27:eb:4c:43:92 Action: Output Port 1/1/2

Mit Wireshark konnten aufgezeichnet werden, wie der SDN Controller die erstellten Flows, auf den Switch überträgt, der Filter dafür lautet wie folgt:

openflow_v4.flowmod.command == 0 Flow 1 von HostB zu Host A sieht wie folgt aus:

Abbildung 2: L2 Flow Modification Host B – Host A

Flow 2 von Host A zu Host B sieht wie folgt aus:


9

Abbildung 3: L2 Flow Modification Host A – Host B

Auf dem Switch kann mit dem Kommando „show openflow flows“ festgestellt werden, ob die Flows in der Flowtabelle eingetragen wurden. Das Ergebnis sieht wie folgt aus.

Flow ID: 22 Priority: 500 Status: Active Rule: In Port: generic Source Mac: 001e.684a.26e2 Destination Mac: b827.eb4c.4392 Source Mac Mask: ffff.ffff.ffff Destination Mac Mask: ffff.ffff.ffff Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2 Flow ID: 23 Priority: 500 Status: Active Rule: In Port: generic Source Mac: b827.eb4c.4392 Destination Mac: 001e.684a.26e2 Source Mac Mask: ffff.ffff.ffff Destination Mac Mask: ffff.ffff.ffff Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1

Aus den erstellten Flows resultiert, dass die beiden Hosts miteinander kommunizieren können.

64 bytes from 192.168.10.1: icmp_seq=4987. time=0.199 ms 64 bytes from 192.168.10.1: icmp_seq=4988. time=0.146 ms 64 bytes from 192.168.10.1: icmp_seq=4989. time=0.211 ms 64 bytes from 192.168.10.1: icmp_seq=4990. time=0.272 ms 64 bytes from 192.168.10.1: icmp_seq=4991. time=0.208 ms 64 bytes from 192.168.10.1: icmp_seq=4992. time=0.225 ms


10

3.1.3.2 Host zu Host Kommunikation mit Layer 3 Flow Zum jetzigen Zeitpunkt kann Host A mittels einem Ping Host B nicht erreichen. Nun werden folgende beiden Flows mittels SDN Controller definiert.

Flow 1: Switchname: openflow:14721744064491552768 Flowname: HostB-HostA Ethernet Type: 2048 Source IP: 192.168.10.1/32 Destination IP: 192.168.10.254/32 Action: Output Port 1/1/1 Flow 2: Switchname: openflow:14721744064491552768 Flowname: HostA-HostB Ethernet Type: 2048 Source IP: 192.168.10.254/32 Destination IP: 192.168.10.1/32 Action: Output Port 1/1/2

Mit Wireshark konnten aufgezeichnet werden, wie der SDN Controller die erstellten Flows, auf den Switch überträgt, der Filter dafür lautet wie folgt:

openflow_v4.flowmod.command == 0 Flow 1 von HostB zu Host A sieht wie folgt aus:

Abbildung 4: L3 Flow Modification Host B - Host A


11


Abbildung 5: L3 Flow Modification Host A - Host B

Auf dem Switch kann mit dem Kommando „show openflow flows“ festgestellt werden, ob die Flows in der Flowtabelle eingetragen wurden. Das Ergebnis sieht wie folgt aus:

Flow ID: 24 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800

Source IP: 192.168.10.1 Subnet IP: 255.255.255.255 Destination IP: 192.168.10.254 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1 Flow ID: 25 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Source IP: 192.168.10.254 Subnet IP: 255.255.255.255 Destination IP: 192.168.10.1 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2


64 bytes from 192.168.10.1: icmp_seq=0. time=0.359 ms 64 bytes from 192.168.10.1: icmp_seq=1. time=0.283 ms 64 bytes from 192.168.10.1: icmp_seq=2. time=0.205 ms


12

64 bytes from 192.168.10.1: icmp_seq=3. time=0.256 ms 64 bytes from 192.168.10.1: icmp_seq=4. time=0.279 ms 64 bytes from 192.168.10.1: icmp_seq=5. time=0.209 ms

3.1.3.3 Host zu Host Kommunikation mit Pfad Es werden zwei Paths zwischen HostA und HostB definiert. Daraus werden dann die entsprechenden Flows generiert, wie dies in Variante 2 von Hand gemacht werden musste. Path 1: Path Name: HostB-HostA Source Node: 192.168.10.1 Destination Node: 192.168.10.254 Path2:

Path Name: HostA-HostB Source Node: 192.168.10.254 Destination Node: 192.168.10.1 Mit Wireshark konnten aufgezeichnet werden, wie der SDN Controller die erstellten Flows, auf den Switch überträgt. Der Filter dafür lautet wie folgt:

openflow_v4.flowmod.command == 0 Flow 1 von Host B zu Host A sieht wie folgt aus:

Abbildung 6: Path Flow Modification Host B - Host A



13

Abbildung 7: Path Flow Modification Host A - Host B

Auf dem Switch kann mit dem Kommando „show openflow flows“ festgestellt werden, ob die Flows in der Flowtabelle eingetragen wurden. Das Ergebnis sieht wie folgt aus:

Flow ID: 26 Priority: 32767 Status: Active Rule: In Port: generic Ether type: 0x800

Source IP: 192.168.10.1 Subnet IP: 255.255.255.255 Destination IP: 192.168.10.254 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1 Flow ID: 27 Priority: 32767 Status: Active Rule: In Port: generic Ether type: 0x800 Source IP: 192.168.10.254 Subnet IP: 255.255.255.255 Destination IP: 192.168.10.1 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2


64 bytes from 192.168.10.1: icmp_seq=329. time=0.180 ms 64 bytes from 192.168.10.1: icmp_seq=330. time=0.270 ms 64 bytes from 192.168.10.1: icmp_seq=331. time=0.272 ms 64 bytes from 192.168.10.1: icmp_seq=332. time=0.222 ms 64 bytes from 192.168.10.1: icmp_seq=333. time=0.263 ms 64 bytes from 192.168.10.1: icmp_seq=334. time=0.287 ms


14

Da bei der Definition eines Pfades nur die IPv4 Adressen der betroffenen Endknoten definiert werden müssen, und nicht die effektiven Ports auf welchen die Endknoten liegen, wäre es denkbar, dass man die Endknoten von einem Port auf einen anderen patchen kann, der Controller dies feststellt und die Flows entsprechend umkonfiguriert. Host B wird nun von Port 1/1/2 auf 1/1/3 umgepatcht. Port 1/1/3 wurde gleich konfiguriert wie Port 1/1/2:

interface ethernet 1/1/3 no fdp enable no cdp enable no spanning-tree openflow enable layer23

Die Vermutung konnte leider nicht bestätigt werden, dass der Controller die Veränderung im Netzwerk feststellen kann und die Flows entsprechend verändert. Die Kommunikation funktioniert nach dem umpatchen somit nicht mehr.

3.1.4 Ergebnis Es gibt mehrere Möglichkeiten um die Kommunikation zwischen zwei Endpunkten zu ermöglichen. Auf Layer2 müssen dem Administratoren die MAC Adressen der beiden Punkte bekannt sein und die Ports auf dem Switch, an welchen die Endpunkte angeschlossen sind. Auf Layer3 müssen dem Administratoren die IP-Adresse und die entsprechenden Switch Ports bekannt sein. Wenn die Kommunikation über einen Pfad ermöglich werden soll, sind nur die IP-Adressen der beiden Endpunkte notwendig. Die Nutzung von Pfäden ist somit die einfachste Möglichkeit für die Realisierung einer Kommunikation, jedoch können, im aufgebauten Setup, Änderungen beim Umpatchen von Endknoten nicht erkannt werden, wodurch die entsprechenden Flows nicht angepasst werden, und somit die Kommunikation nicht mehr möglich ist.


15

3.2 Kommunikation zweier Endknoten über zwei Switches

3.2.1 Aufbau

Abbildung 8: Versuchsaufbau Szenario 2

Data Plane Host A Host B IPv4 Adresse 192.168.10.254 192.168.10.1 MAC Adresse 00:1e:68:4a:26:e2 b8:27:eb:4c:43:92 Switch Port Switch A 1/1/1 Switch B 1/1/1 Switch Verbindung Switch A Switch B Switch Port 1/1/2 1/1/2 MAC Adresse cc:4e:24:3a:3e:3d cc:4e:24:3a:3d:f1 Tabelle 5: Szenario 2 Data Plane

Control Plane

SDN Controller Switch A BrocadeICX6610

Switch B BrocadeICX6610

IPv4 Adresse 192.168.1.10 192.168.1.1 192.168.1.2 MAC Adresse 00:1b:24:2d:be:27 cc:4e:24:3a:3e:3c cc:4e:24:3a:3d:f0 Tabelle 6: Szenario 2 Control Plane

3.2.2 Konfiguration Die Switch Ports wurden wie folgt konfiguriert: Switch A

interface ethernet 1/1/1 no fdp enable no cdp enable no spanning-tree openflow enable layer23 interface ethernet 1/1/2


16

no fdp enable no cdp enable no spanning-tree openflow enable layer23

Switch B interface ethernet 1/1/1 no fdp enable no cdp enable no spanning-tree openflow enable layer23 interface ethernet 1/1/2 no fdp enable no cdp enable no spanning-tree openflow enable layer23

3.2.3 Testfälle

3.2.3.1 Host zu Host Kommunikation ohne Redundanz Für die Kommunikation zwischen zwei Hosts gibt es die bekannten drei Möglichkeiten wie Flows definiert werden können. In diesem Testfall wird nur auf die Definition von Pfäden eingegangen und die daraus generierten Flows untersucht. In der Ausgangslage ist es nicht möglich, eine Verbindung zwischen den beiden Host herzustellen. Um die Kommunikation zu ermöglichen werden zwei Pfade definiert: Path 1:

Path Name: HostA-HostB Source Node: 192.168.10.254 Destination Node: 192.168.10.1

Path 2: Path Name: HostB-HostA Source Node: 192.168.10.1 Destination Node: 192.168.10.254 Der SDN Controller hat daraus folgende vier Flows generiert und den Switches übermittelt: Switch A

Flow ID: 40 Priority: 32767 Status: Active Rule: In Port: generic Ether type: 0x800 Source IP: 192.168.10.254 Subnet IP: 255.255.255.255

Destination IP 192.168.10.1 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2 Flow ID: 41 Priority: 32767 Status: Active Rule: In Port: generic Ether type: 0x800 Source IP: 192.168.10.1 Subnet IP: 255.255.255.255 Destination IP: 192.168.10.254 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1

Switch B


17


Destination IP: 192.168.10.1 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1 Flow ID: 4 Priority: 32767 Status: Active Rule: In Port: generic Ether type: 0x800 Source IP: 192.168.10.1 Subnet IP: 255.255.255.255 Destination IP: 192.168.10.254 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2

Die Kommunikation zwischen Host A und Host B funktioniert nun und kann mit einem Ping von Host A zu Host B bewiesen werden:

64 bytes from 192.168.10.1: icmp_seq=1. time=0.215 ms 64 bytes from 192.168.10.1: icmp_seq=2. time=0.341 ms 64 bytes from 192.168.10.1: icmp_seq=3. time=0.341 ms 64 bytes from 192.168.10.1: icmp_seq=4. time=0.204 ms 64 bytes from 192.168.10.1: icmp_seq=5. time=0.243 ms

3.2.3.2 Host zu Host Kommunikation mit Redundanz Im bestehende Setup vom vorherigen Versuch wird zusätzlich zwischen Switch A und Switch B ein weiterer Link erstellt. Dieser Link soll es dem Netzwerk erlauben im Falle eines Ausfalls des einen Links die Kommunikation trotzdem aufrecht zu erhalten. Die Verbindung wird nun wie folgt aufgebaut. Switch Verbindung Switch A Switch B Link 1 1/1/2 /cc:4e:24:3a:3e:3d 1/1/2 / cc:4e:24:3a:3d:f1 Link 2 1/1/3 /cc:4e:24:3a:3e:3e 1/1/3 / cc:4e:24:3a:3d:f2 Tabelle 7: Szenario 2 Redundante Switch Verbindung

Die Ports werden auf beiden Switches wie folgt konfiguriert: interface ethernet 1/1/3 no fdp enable no cdp enable no spanning-tree openflow enable layer23

Der bestehende Link 1 wird nun deaktiviert, und die Kommunikation funktioniert nicht mehr. Lösungsversuch 1: In der Path Konfiguration konnte eine Option namens „Reoptimize Period“ gesetzt werden, standardmässig ist diese auf 0, womit dies deaktiviert ist. Diese Option wird nun den bestehenden Pfaden auf 3 gesetzt, wodurch sich der Pfad alle 3 Sekunden den kürzesten Pfad sucht. Nachdem der bestehende Link 1 deaktiviert wurde, funktioniert die Kommunikation nicht mehr. Lösungsversuch 2:


18

Möglicherweise muss die Reoptimize Period, bereits bei der Erstellung des Pfads gesetzt werden, damit dies funktioniert. Aus diesem Grund werden alle bestehenden Pfade und Flows gelöscht und die Pfade neu erstellt. Auch bei diesem Lösungsversuch funktioniert die Kommunikation nicht mehr, nachdem der bestehende Link 1 deaktiviert wurde. Lösungsversuch 3: Als dritte Lösungsvariante werden auf den beiden Switches zusätzliche Flows definiert, die als Output Link 1/1/3 haben. Flow Switch A

Flow ID: 44 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Source IP: 192.168.10.254 Subnet IP: 255.255.255.255 Destination IP: 192.168.10.1 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/3

Flow Switch B Flow ID: 7 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Source IP: 192.168.10.1 Subnet IP: 255.255.255.255 Destination IP: 192.168.10.254 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/3

Auch bei diesem Lösungsversuch funktioniert die Kommunikation nicht mehr, nachdem der bestehende Link 1 deaktiviert wurde. Lösungsversuch 4: In der nächsten Lösungsvariante wird ein Flow mit zwei Actions definiert, einerseits soll das Paket über Port 1/1/2 und Port 1/1/3 an den zweiten Switch übermittelt werden. Die Flows sehen auf den Geräten wie folgt aus: Switch A

Flow ID: 55 Priority: 32767 Status: Active Rule: In Port: generic Ether type: 0x800 Source IP: 192.168.10.254 Subnet IP: 255.255.255.255 Destination IP: 192.168.10.1 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2 Out Port: e1/1/3

Switch B Flow ID: 18 Priority: 32767 Status: Active Rule: In Port: generic Ether type: 0x800 Source IP: 192.168.10.1 Subnet IP: 255.255.255.255 Destination IP: 192.168.10.254 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2 Out Port: e1/1/3


19

Daraus ergibt sich folgende Problematik, da nun die Pakete immer über beide Pfade weitergeleitet werden, kommen diese doppelt an und kommen jeweils auch wieder doppelt zurück, wenn beide Links funktionieren.

64 bytes from 192.168.10.1: icmp_seq=887. time=0.348 ms 64 bytes from 192.168.10.1: icmp_seq=887. time=0.410 ms 64 bytes from 192.168.10.1: icmp_seq=887. time=0.452 ms 64 bytes from 192.168.10.1: icmp_seq=887. time=0.497 ms 64 bytes from 192.168.10.1: icmp_seq=888. time=0.236 ms 64 bytes from 192.168.10.1: icmp_seq=888. time=0.300 ms 64 bytes from 192.168.10.1: icmp_seq=888. time=0.343 ms 64 bytes from 192.168.10.1: icmp_seq=888. time=0.388 ms 64 bytes from 192.168.10.1: icmp_seq=889. time=0.309 ms 64 bytes from 192.168.10.1: icmp_seq=889. time=0.339 ms 64 bytes from 192.168.10.1: icmp_seq=889. time=0.363 ms 64 bytes from 192.168.10.1: icmp_seq=889. time=0.383 ms

Es kommen also auf einen Ping Request jeweils 4 Antworten. Wenn nun der eine Link deaktiviert wird (nach dem Paket mit der Sequenznummer 11), funktioniert die Kommunikation und es gibt keine Vervielfachung der Ping Paket mehr:

64 bytes from 192.168.10.1: icmp_seq=11. time=0.249 ms 64 bytes from 192.168.10.1: icmp_seq=11. time=0.336 ms 64 bytes from 192.168.10.1: icmp_seq=11. time=0.378 ms 64 bytes from 192.168.10.1: icmp_seq=11. time=0.421 ms 64 bytes from 192.168.10.1: icmp_seq=12. time=0.282 ms 64 bytes from 192.168.10.1: icmp_seq=13. time=0.293 ms 64 bytes from 192.168.10.1: icmp_seq=14. time=0.203 ms 64 bytes from 192.168.10.1: icmp_seq=15. time=0.224 ms 64 bytes from 192.168.10.1: icmp_seq=16. time=0.280 ms 64 bytes from 192.168.10.1: icmp_seq=17. time=0.187 ms

Lösungsversuch 5: Als fünfter Lösungsversuch wird ein weiteres Feature von Openflow verwendet, namens Groups. Groups bietet die Möglichkeit von Fast-Failover für redundante Pfade und kann, wenn ein Link ausfällt, sofort auf den redundanten Pfad umschalten, die geschieht alles auf dem Switch, ohne dass der Controller dafür eine Änderung an die Switches mitteilen muss. Infolge eines Ausfalls einer der Switches mussten einige Änderungen im Setup vorgenommen werden. Welche wie folgt lauten: Data Plane Host A Host B IPv4 Adresse 192.168.10.254 192.168.10.1 MAC Adresse 00:1e:68:4a:26:e2 b8:27:eb:4c:43:92 Switch Port Switch A 1/1/1 Switch B 1/1/1 Tabelle 8: Groups Data Plane

Switch Verbindung Switch A Switch B Link 1 1/1/10 /cc:4e:24:3a:3e:3d 1/1/10 / cc:4e:24:3a:3d:f1 Link 2 1/1/11 /cc:4e:24:3a:3e:3e 1/1/11 / cc:4e:24:3a:3d:f2 Tabelle 9: Groups Switch Verbindung

Control Plane

SDN Controller Switch A BrocadeICX6610

Switch B BrocadeICX7450

IPv4 Adresse 192.168.1.10 192.168.1.1 192.168.1.5 MAC Adresse 00:1b:24:2d:be:27 cc:4e:24:3a:3e:3c cc:4e:24:8a:1e:60 Tabelle 10: Groups Control Plane


20

Folgende Flows wurden eingerichtet: Switch A : Flow von Switch A zu Switch B

Flow ID: 3 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Destination IP: 192.168.10.1 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Group: 2

Flow zu Host A Flow ID: 8 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Destination IP: 192.168.10.254 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1

Switch B : Flow zu Host B

Flow ID: 3 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Destination IP: 192.168.10.1 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1

Flow Switch B zu Switch A Flow ID: 4 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Destination IP: 192.168.10.254 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Group: 1

Die folgenden beiden Groups wurden eingerichtet Switch A

Group id 2 Transaction id 4292523 Type FAST_FWD Packet Count 2925592 Byte Count 4436084326 Flow Count 1 Number of buckets 2 bucket #1 Watch port 1/1/10 Number of actions 1 action 1: out port: 1/1/10 bucket #2 Watch port 1/1/11 Number of actions 1 action 1: out port: 1/1/11 Forwarding information:


21

LTM Index: 0 Active port: 1/1/10 Switch B

Group id 1 Transaction id 6 Type FAST_FWD Packet Count 425 Byte Count 43030 Flow Count 2 Number of buckets 2 bucket #1 Watch port 1/1/10 Number of actions 1 action 1: out port: 1/1/10 bucket #2 Watch port 1/1/11 Number of actions 1 action 1: out port: 1/1/11 Forwarding information: FF Index: 15360 Active port: 1/1/10

Wie man sehen kann ist auf beiden Switches Port 1/1/10 aktiv. Wenn nun also das Interface 1/1/10 disabled wird, so sollte auf Port 1/1/11 umgeschaltet werden.

SSH@Switch B Router(config-if-e1000-1/1/10)#disable Switch A

Forwarding information: FF Index: 15360 Active port: 1/1/11

Switch B Forwarding information: LTM Index: 0 Active port: 1/1/11

Während der Kappung des Links wurden ein Ping von Host A an Host B ausgeführt, welcher keine Probleme zum Vorschein gebracht hat. Die Deaktivierung hat bei der Sequenznummer 861 stattgefunden:

64 bytes from 192.168.10.2: icmp_seq=857. time=0.264 ms 64 bytes from 192.168.10.2: icmp_seq=858. time=0.175 ms 64 bytes from 192.168.10.2: icmp_seq=859. time=0.246 ms 64 bytes from 192.168.10.2: icmp_seq=860. time=0.245 ms 64 bytes from 192.168.10.2: icmp_seq=861. time=0.181 ms 64 bytes from 192.168.10.2: icmp_seq=862. time=0.282 ms 64 bytes from 192.168.10.2: icmp_seq=863. time=0.305 ms 64 bytes from 192.168.10.2: icmp_seq=864. time=0.232 ms 64 bytes from 192.168.10.2: icmp_seq=865. time=0.282 ms

3.2.4 Ergebnis Um eine Kommunikation über zwei Switches zwischen zwei Host zu ermöglichen, ist die einfachste Möglichkeit die Definition von Pfaden, die dann die entsprechenden Flows erstellen. Der Brocade SDN Controller ist leider nicht fähig, ausgefallene Links selbständig zu erkennen um danach die entsprechenden Flows anzupassen, damit dieser Link nicht mehr verwendet wird. Dazu müsste wohl eine eigene Applikation auf dem SDN Controller geschrieben werden, die dies entsprechend ermöglichen würden. Beim Switchverhalten wurde auch festgestellt, dass immer nur der erste Floweintrag genutzt wird, auch wenn mehrere Flows mit den gleichen Kriterien erstellt wurden.


22

Ein nützliches Instrument für die Nutzung von Redundanten Links sind Group mit dem Fast-Failover Mechanismus, was im Falle von Linkausfällen keinen feststellbaren Einfluss auf die Kommunikation zwischen zwei Hosts hat.


23

3.3 Bandbreitenbeschränkung Im folgenden Szenario soll erarbeitet werden, wie die Bandbreite zwischen zwei Hosts eingeschränkt werden kann. Beispielsweise soll es möglich sein, dass man für einen Filedownload nur eine eingeschränkte Bandbreite zu Verfügung gestellt bekommt.

3.3.1 Aufbau

Abbildung 9: Versuchsaufbau Bandbreitenbeschränkung

Data Plane Host A Host B IPv4 Adresse 192.168.10.254 192.168.10.2 MAC Adresse 00:1e:68:4a:26:e2 b8:27:eb:0f:66:dd Switch Port 1/1/1 1/1/2 Tabelle 11: Bandbreitenbeschränkung Data Plane

Control Plane SDN Controller Switch BrocadeICX6610-48P

IPv4 Adresse 192.168.1.10 192.168.1.1 MAC Adresse 00:1b:24:2d:be:27 cc:4e:24:3a:3e:3c Tabelle 12: Bandbreitenbeschränkung Control Plane

3.3.2 Konfiguration Die beiden Ports wurden auf dem Switch wie folgt konfiguriert:

interface ethernet 1/1/1 no fdp enable no cdp enable no spanning-tree openflow enable layer23 interface ethernet 1/1/2 no fdp enable no cdp enable no spanning-tree openflow enable layer23


24

3.3.3 Testfälle

3.3.3.1 Bandbreiten Beschränkung pro Host Im folgenden Testfall soll von Host B aus ein File via Secure Copy (SCP) von Host A heruntergeladen werden. Hierfür sollen mit Hilfe von OpenFlow Meters die Bandbreite eingeschränkt werden. Auf dem Switch wird ein Meter mit folgenden Informationen definiert.

Abbildung 10: Meter Definition

Das entsprechende OpenFlow Paket konnte mit Wireshark (openflow_v4.metermod.command) aufgezeichnet werden:

Abbildung 11: Meter Add


25

Mit dem Befehl „show openflow meters“ kann dies danach auf dem Switch überprüft werden:

SSH@Switch1-BrocadeICX6610-48P>show openflow meters TOTAL Meters in the system: 1 Meter id: 1 Transaction id: 950335 Meter Flags: KBPS BURST STATS Flow Count: 0 Number of bands: 1 In packet count: -NA- In byte count: 0 Band Type: DROP Rate: 16000 Burst size: 16000 kb In packet band count: -NA- In byte band count: 0

Nun wird einerseits ein Flow definiert um Host A zu erreichen.

Flow ID: 15 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Destination IP: 192.168.10.254 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1

Nun wird ein Flow für Host B eingerichtet und dabei der Meter mit der ID 1 hinterlegt:

Flow ID: 16 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Destination IP: 192.168.10.2 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2 Meter id: 1

Auf Host A (Solaris) wird nun eine 1GB grosse Datei für die Übertragung erstellt:

dd if=/dev/zero of=/test.img count=1024 bs=1048576 Von Host B aus wird nun die Übertragung der Datei via SCP gestartet:

scp [email protected]:/test.img / In der Ausgabe des SCP Kommandos kann nun festgestellt werden, dass die Datei mit einer Bandbreite von 2MB/s heruntergeladen wird:

root@raspberrypi:~# scp [email protected]:/test.img / Password: test.img 7% 77MB 2.0MB/s 07:58 ETA

Während dem Download kann der Meter nun verändert werden, beispielsweise soll die Bandbreite auf 10MB/s erhöht werden.


26

Abbildung 12: Änderung der Bandbreite

Das entsprechende Wireshark Paket sieht dann wie folgt aus:

Abbildung 13: Meter Modification

Auf dem Download kann nun beobachtet werden, dass die Bandbreite angestiegen ist:

root@raspberrypi:~# scp [email protected]:/test.img / Password: test.img 86% 881MB 9.4MB/s 00:15 ETA

3.3.3.2 Bandbreitenbeschränkung pro Service Im folgenden Testfall soll eine Bandbreitenbeschränkung auf unterschiedlichen Services vorgenommen werden. Von Host B aus wird einerseits mit SCP eine Datei heruntergeladen und andererseits mit HTTP. Diesen beiden Services sollen unterschiedliche Bandbreitenbeschränkungen unterliegen.


27

Für HTTP wird ein Meter mit folgenden Informationen erstellt:

Abbildung 14: HTTP Meter

Für SCP wird ein Meter mit folgenden Einstellungen erstellt:

Abbildung 15: SCP Meter


28

Auf dem Switch sehen die beiden Meter wie folgt aus. HTTP Meter:

Meter id: 80 Transaction id: 961029 Meter Flags: KBPS BURST STATS Flow Count: 1 Number of bands: 1 In packet count: -NA- In byte count: 483654194 Band Type: DROP Rate: 32000 Burst size: 32000 kb In packet band count: -NA- In byte band count: 17004636

SSH Meter

Meter id: 22 Transaction id: 960380 Meter Flags: KBPS BURST STATS Flow Count: 1 Number of bands: 1 In packet count: -NA- In byte count: 379854902 Band Type: DROP Rate: 16000 Burst size: 16000 kb In packet band count: -NA- In byte band count: 14263668

Nun werden entsprechende Flows definiert. Einerseits ein Flow für HTTP mit Port 80, welcher auf dem Switch wie folgt aussieht:

Flow ID: 19 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Destination IP: 192.168.10.2 Subnet IP: 255.255.255.255 IP Protocol: 6 IP Protocol Source Port: 80 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2 Meter id: 80

Und andererseits ein Flow für SSH/SCP: Flow ID: 18 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Destination IP: 192.168.10.2 Subnet IP: 255.255.255.255 IP Protocol: 6 IP Protocol Source Port: 22 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2 Meter id: 22


29

Mit Hilfe des wget Befehls wird nun eine Datei von Host B aus, via HTTP vom Webserver von Host A heruntergeladen:

root@raspberrypi:~# wget 192.168.10.254/test2.img --2016-04-07 22:54:04-- http://192.168.10.254/test2.img Connecting to 192.168.10.254:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1073741824 (1.0G) Saving to: ‘test2.img’ test2.img 16%[====> ] 166.69M 3.59MB/s eta 3m 50

Der HTTP Download unterliegt nun einer Bandbreitenbeschränkung von ca. 4MB/s. Parallel dazu wird von Host B aus, eine Datei mittels SCP von Host A heruntergeladen:

root@raspberrypi:~# scp [email protected]:/test.img / test.img 9% 93MB 2.0MB/s 07:38 ETA

Dieser Download unterliegt der Bandbreitenbeschränkung von ca. 2MB/s

3.3.4 Ergebnis Meters bieten ein sehr einfaches Werkzeug an, um die Bandbreitennutzung für einzelne Hosts zu beschränken. Da ein Meter einem Flow zugeordnet wird, ist es möglich, die Bandbreite für einzelne Services explizit einzuschränken.


30

3.4 Flows über Northbound API per RESTCONF managen Es wird empfohlen, dies über das Chrome Postman Plug-In zu machen. Postman ist ein generischer REST Client der im Browser läuft, leicht zu bedienen ist und viel Komfort bietet. Um über Postman Flows in das System einzuspielen, geht man wie folgt vor:

1. Postman von http://www.getpostman.com/ herunterladen und anschliessend installieren.

2. Chrome öffnen, Apps öffnen und Postman auswählen 3. Authorization konfigurieren:

• Basic Auth auswählen • Username und Password ausfüllen (Default admin:admin) • Update Request auswählen

Abbildung 16: Postman Authorization

4. Headers konfigurieren

• Authorization wurde durch den vorherigen Schritt automatisch generiert • Accept: application/xml • Content-type: application/xml

Abbildung 17: Postman Headers

5. SDN Controller URL eintragen im Format: http://<controller-ip>:8181/URI. 6. Eine der folgenden REST auswählen:

• GET • PUT • POST • DELETE

7. Das Body Tab öffnen, raw und XML auswählen und den Body wie gewünscht ausfüllen.

8. Senden klicken


31

Abbildung 18: Postman Send

Flow hinzufügen URL: http://<controller-ip>:8181/restconf/config/opendaylight-inventory:nodes/node/{node-id}/table/{table-id}/flow/{flow-id} Example URL: http://10.176.50.11:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:224635992577896/table/0/flow/125 Methode: PUT Body Anfrage:

Abbildung 19: Postman Body

Hierbei werden alle Pakete, welche als Empfänger die IPv4 Adresse 192.168.11.3 haben, an den Ausgangsport 3 weitergeleitet


32

Abbildung 20: Postman Resultat auf Switch

Weitere Beispiele für Flows finden sich unter: https://wiki.opendaylight.org/view/Editing_OpenDaylight_OpenFlow_Plugin:End_to_End_Flows:Example_Flows Flow anzeigen

- Flow Eintrag mit der ID 125 ausgeben lassen.

Abbildung 21: Flow anzeigen

Flows löschen

- Flow Eintrag mit der ID 125 löschen.

Abbildung 22: Flow löschen

- Alle Flow Einträge löschen.

Abbildung 23: Alle Flows löschen

Flow Statistik

- Gesamte Flow Statistik ausgeben lassen

Abbildung 24: Gesamte Flow Statistik anzeigen

- Flow Statistik für einzelnen Flow ausgeben lassen

Abbildung 25: Flow Statistik pro Flow anzeigen


33

Resultat:

Abbildung 26: Flow Statistik Resultat


34

3.5 Eigene SDN Test App schreiben Im Rahmen der BDA wurde eine kleine Java Anwendung geschrieben, welche über RESTCONF dem Controller über dessen Northbound API Anweisungen geben kann (Flows hinzufügen, Flows löschen, Meter definieren). Die Anwendung ist in Java geschrieben und sendet JSON geparste Nachrichten an den Controller. Alle Informationen sind fix hinterlegt und nicht dynamisch. So besteht die Testumgebung für die Anwendung Fix aus zwei Hosts, einem Brocade Switch und dem Brocade SDN Controller (basiert auf OpenDaylight). Beide Hosts haben eine direkte Verbindung zum Switch.

Abbildung 27: SDN Applikation GUI

Auf dem Switch können 2 Flows hinzugefügt oder gelöscht werden: - Flow 99: Jedes Paket mit der Ziel IP 192.168.11.4 wird an den Port 4

weitergeleitet - Flow 100: Jedes Paket mit der Ziel IP 10.176.50.2 wird an den Port 2

weitergeleitet Dadurch können die zwei Clients miteinander kommunizieren. Zusätzlich kann man dem Flow 99 noch einen Meter mitgeben, mit welchem die Bandbreite für dieses Flow definiert werden kann. Hierzu kann man über einen Slider einen Datendurchsatz von 100 bis 100’000 kb/s festlegen. Diese SDN Testanwendung dient hauptsächlich zu Vorführ- und Testzwecken und wurde nicht ausgiebig getestet.


35

3.6 Erweiterung von SDN um Open vSwitch In der Testumgebung wurde folgende Topologie aufgebaut, um Open vSwitch in Zusammenarbeit mit OpenFlow testen zu können.

Abbildung 28: Versuchsaufbau mit Open vSwitch

Die Installation ist mit ein wenig Knowhow im Bereich Linux und Virtualisierung nicht weiter schwierig. Diese wurde gemäss dieser Anleitung durchgeführt: http://dannykim.me/danny/openflow/57620 Die Testumgebung besteht aus einer virtuellen Maschine auf welcher Ubuntu in der Version 14.04 läuft. Die Ubuntu Maschine dient als Hypervisor. Dazu wurde VirtualBox installiert. Mit VirtualBox wurden drei virtuelle Clients erstellt, auf welchen die Linux Distribution «Damn Small Linux» läuft. Zudem wurde unter Ubuntu auch noch Open vSwitch installiert und konfiguriert.

Nach erfolgreicher Inbetriebnahme der Testumgebung konnte man auf dem SDN Controller alle beteiligten Komponenten sehen. Die Testumgebung besteht zusätzlich noch aus einem Brocade Switch, an welchem zwei weitere Clients angeschlossen sind.


36

Abbildung 29: Versuchsaufbau Topologie

Auf dem Open vSwitch konnten Flows für die Kommunikation unter den VMs problemlos installiert werden und diese konnten anschliessend miteinander Pakete austauschen. • Hier sieht man, die Flows, welche auf dem Open vSwitch eingerichtet sind.

Abbildung 30: Open vSwitch Flows

Eingerichtete Flows (Layer 3): - Pakete mit Ziel IP Adresse 192.168.11.120 an Port 3 ausgeben - Pakete mit Ziel IP Adresse 192.168.11.121 an Port 2 ausgeben - Pakete mit Ziel IP Adresse 192.168.11.122 an Port 4 ausgeben

• Hier sieht man die Portbelegung des Open vSwitch

Abbildung 31: Open vSwitch Portbelegung

An Port 2 hängt 192.168.11.121

An Port 3 hängt 192.168.11.120

An Port 4 hängt 192.168.11.122


37

Leider hat die Kommunikation zwischen den VMs welche am Open vSwitch hängen und den Clients am Brocade Switch trotz richtig konfigurierten Layer 3 Flows nicht funktioniert.


38

3.7 Topologieerkennung in Software Defined Networks Die meisten SDN Controller verfügen über eine Topology Manager, der es einen Administrator ermöglicht, die aktuelle physisch vorhandene Topologie zu begutachten. Doch wie kommt der SDN Controller zu diesen Informationen, bis er sie wie in folgender Abbildung darstellen kann:

Abbildung 32: Topologieerkennung

In der Abbildung sieht man zwei Switches die jeweils über zwei redundante Links mit einem weiteren Switch verbunden sind. Für die Topologieerkennung verwendet der OpenDaylight SDN Controller und somit auch der Brocade SDN Controller das Link Layer Discovery Protocol. Mit Wireshark wurden die entsprechenden Pakete aufgezeichnet, die für die Erkennung der Topologie notwendig sind. Voraussetzung das die Topologieerkennung funktioniert ist, dass auf allen OpenFlow Switch ein Flow hinterlegt ist, der alle LLDP Pakete an den SDN Controller sendet. Diese Flow sieht wie folgt auf dem Switch aus:

Flow ID: 1 Priority: 100 Status: Active Rule: In Port: generic Ether type: 0x88cc Instructions: Apply-Actions Action: FORWARD Out Port: send to controller

In einem vordefinierten Intervall sendet der SDN Controller an alle Switch via OpenFlow das Kommando raus, das zu jedem OpenFlow Port aus ein eigens vordefiniertes LLDP Packet versendet werden soll, was wie folgt aussieht:


39

Abbildung 33: LLDP Packet OUT

Wenn nun an diesem Port ein weiterer OpenFlow Switch angeschlossen ist, wird dieser das Paket gemäss vordefinierter Regel an den SDN Controller senden, was dann wie folgt aussieht:

Abbildung 34: LLDP Packet IN

Aus diesem Paket kann der SDN Controller nun folgende Schlüsse ziehen. Jener Switch, von welche er das Paket erhalten hat, ist auf dem OpenFlow Port mit der ID 11, mit dem Switch openflow:14721744864491552768 verbunden. Da das eigentliche LLDP Frame unterwegs nicht verändert wurde, weiss der SDN Controller auch, dass er dieses spezifische LDAP Frame am Switch openflow:14721744864491552768 über den OpenFlow Port mit der ID 11 versendet


40

hat. Somit weiss der SDN Controller nun zwischen welchen beiden OpenFlow Switches eine Verbindung über welchen Port existiert.


41

3.8 ARP in Software Defined Networks Nebst LLDP steht auf dem Switch auch folgender Flow standardmässig zur Verfügung:

Flow ID: 2 Priority: 1 Status: Active Rule: In Port: generic Ether type: 0x806 Instructions: Apply-Actions Action: FORWARD Out Port: send to controller

Der Ethernet Type 0x806 steht für ARP und sendet gemäss diesem Flow sämtliche ARP Pakete an den SDN Controller. Im folgenden Aufbau soll gezeigt werden, wie ARP Pakete in einer SDN Umgebung mit OpenFlow standardmässig verarbeitet werden.

Abbildung 35: Versuchsaufbau ARP

IP-Adresse MAC Adresse Switch Port Host A 192.168.10.254 00:1e:68:4a:26:e2 1 Host B 192.168.10.2 b8:27:eb:0f:66:dd 2 Tabelle 13: ARP Versucht Host Setup

Host A möchte nun die MAC Adresse von Host B wissen und senden einen ARP Request, welcher vom Switch gemäss vordefiniertem Flow an den SDN Controller versendet wird. Dies Paket kommt beim SDN Controller wie folgt an:


42

Abbildung 36: ARP Packet IN Host A

Der SDN Controller weiss wo sich der entsprechende Host befindet und sendet das ARP Paket an den Switch zurück, wo er das Paket via OpenFlow Port 2 versendet:

Abbildung 37: ARP Packet OUT Host B

Host B beantwortet nun den ARP Request und sendet diesen zurück zum Switch, welcher auch dieses Paket wieder an den SDN Controller versendet:


43

Abbildung 38: ARP Packet IN Host B

Im letzten Schritt wird die ARP Response zurück an Host A gesendet:

Abbildung 39: ARP Packet OUT Host A

Nebst dem Weiterleiten aktualisiert der SDN Controller auch die Topologie um die entsprechenden Hosts:


44

Abbildung 40: Hosterkennung

Wie festgestellt werden konnte, wird mit dieser Prozedur der SDN Controller um weitere Funktionen ergänzt und entsprechend belastet. Weiter ist auch offensichtlich, dass ein Ausfall des SDN Controllers in diesem Fall die gesamte Kommunikation lahmlegen würde. Bereits im OpenFlow Standard 1.0 wurde eine entsprechende Lösung implementiert, wo durch Flows erstellt werden können, die ARP Pakete entsprechend interpretieren können und so ohne den Umweg über den SDN Controller abgearbeitet werden können. Die entsprechenden Flows sehen wie folgt aus, um das zuvor erklärte Beispiel ohne SDN Controller Interaktion gewährleisten zu können. Der Flow für den ARP Request von Host A zu Host B:

Flow ID: 120 Priority: 600 Status: Active Rule: In Port: generic Ether type: 0x806 ARP Target IP: 192.168.10.2 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2

Und der entsprechende Flow zurück zu Host A Flow ID: 121 Priority: 600 Status: Active Rule: In Port: generic Destination Mac: 001e.684a.26e2 Destination Mac Mask: ffff.ffff.ffff Ether type: 0x806 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1

Dadurch, dass der SDN Controller nun die entsprechenden ARP Paket nicht mehr erhält, ist der SDN Controller auch nicht mehr imstande, Auskunft geben zu können, an welchem Port sich ein Endknoten befindet. Um dieses Problem zu umgehen, kann die ARP Response zusätzlich zu Port 1/1/1 auch an den SDN Controller gesendet werden. Der Flow sieht dann entsprechend wie folgt auf dem Switch aus:

Flow ID: 121 Priority: 600 Status: Active Rule: In Port: generic Destination Mac: 001e.684a.26e2 Destination Mac Mask: ffff.ffff.ffff Ether type: 0x806 Instructions: Apply-Actions


45

Action: FORWARD Out Port: e1/1/1 Out Port: send to controller

Die Antwort wird aber dadurch noch ein zweites Mal an den Host A gesendet, was mit Wireshark entsprechend festgestellt werden konnte.

Abbildung 41: Redundantes ARP Packet

Somit kann gesagt werden, dass für die Sicherstellung von ARP mehrere Möglichkeiten bestehen, die alle ihre Nachteile haben: Variante Nachteil SDN Controller • SDN Controller darf nicht ausfallen

• SDN Controller wird mit zusätzlichen Aufgaben belastet, wodurch dessen Performance beeinträchtigt wird

ARP Flow • Der SDN Controller kann in seiner

Topologie keine Endknoten anzeigen ARP Flow mit Response an Controller • Der Host welcher den ARP Request

auslöst erhält die Response doppelt • SDN Controller wird mit zusätzlichen

Aufgaben belastet, wodurch dessen Performance beeinträchtigt wird.

Tabelle 14: Nachteile ARP Varianten

Zusätzlich ist noch zu sagen, dass der ARP Flow nicht mit Hilfe des Brocade Flow Managers gemacht werden kann, weder in Version 2.0 noch 3.0. Der Flow wird bereits auf dem GUI als nicht zulässig erkannt, worauf mit der Fehlermeldung „For matching Layer 2 IPv4 packets, the Ethernet Type must be 2048“ aufmerksam gemacht wird. Via REST und Postman funktioniert dies aber, mit folgenden Informationen:

"match": { "ethernet-match": { "ethernet-type": { "type": "2054"


46

} }, "ipv4-destination": "192.168.10.2/32" },

Das Weitern muss angemerkt werden, dass dies auf den Brocade Switches funktioniert, aber nicht mit dem verwendeten HP Switch. Der HP Switch gibt auf den Flow Mod Command folgende Informationen zurück:

Abbildung 42: ARP Flow Modification Error


47

3.9 Latenz in SDN In diesem Versuch soll verglichen werden, wie sich die Latenzzeiten mit im OpenFlow im Vergleich zum traditionellen Switching mit VLAN verhält. Verwendet wurden hierfür zwei Hosts, deren Latenzzeiten mittels 100 Pings aufgezeichnet wurden. Der Test wurde auf dem Brocade Switch ICX6610 durchgeführt. Vier verschiedenen Varianten wurden getestet.

1) VLAN Die beiden Hosts wurden auf dem Switch dem gleichen VLAN zugewiesen:

vlan 2 by port untagged ethe 1/1/1 to 1/1/2 2) Layer 1 Flow

Es wurden zwei Flows erstellt für den Hin- und Rückweg zwischen den beiden Hosts, basierend auf Layer 1.

Flow ID: 3 Priority: 500 Status: Active Rule: In Port: e1/1/1 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2 Flow ID: 4 Priority: 500 Status: Active Rule: In Port: e1/1/2 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1 3) Layer 2 Flow


Flow ID: 5 Priority: 500 Status: Active Rule: In Port: generic Source Mac: 001e.684a.26e2 Destination Mac: b827.eb0f.66dd Source Mac Mask: ffff.ffff.ffff Destination Mac Mask: ffff.ffff.ffff Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/2 Flow ID: 6 Priority: 500 Status: Active Rule: In Port: generic Source Mac: b827.eb0f.66dd Destination Mac: 001e.684a.26e2 Source Mac Mask: ffff.ffff.ffff Destination Mac Mask: ffff.ffff.ffff Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1 4) Layer 3 Flow



Destination IP: 192.168.10.2 Subnet IP: 255.255.255.255 Instructions: Apply-Actions


48

Action: FORWARD Out Port: e1/1/2 Flow ID: 8 Priority: 500 Status: Active Rule: In Port: generic Ether type: 0x800 Source IP: 192.168.10.2 Subnet IP: 255.255.255.255 Destination IP: 192.168.10.254 Subnet IP: 255.255.255.255 Instructions: Apply-Actions Action: FORWARD Out Port: e1/1/1

3.9.1 Ergebnis Das Ergebnis sieht wie folgt aus.

Abbildung 43: Latenztest

VLAN L1 Flow L2 Flow L3 Flow Mittelwert (ms) 0.25374 0.25244 0.25379 0.26073 Minimum (ms) 0.171 0.169 0.165 0.172 Maximum (ms) 0.382 0.379 0.368 0.372 Median (ms) 0.262 0.264 0.265 0.268 Tabelle 15: Latenztest Ergebnis

Obwohl die Unterschiede minimal sind, kann trotzdem festgehalten werden, L1 Flows sind durchschnittlich am Schnellsten, da die Funktion die der Switch dadurch übernimmt, ein zwei Port Hub darstellt, und er die Pakete nur vom einen an den anderen Port weiterleiten muss. Am Zweischnellsten ist das bekannte Switching mit Hilfe von VLANs und der Layer 2 Flow, dabei wird der Switch an beiden Orten die Destination MAC Adresse des Pakets auslesen und an den entsprechenden Port weiterleiten. Am Langsamsten ist der Layer 3 Flow, da der Switch hier die Source IP Adresse anschauen muss und basierend darauf das Paket an den richtigen Port weitersenden muss. Wenn man aber nur die Median Werte interpretiert, ist zu sagen, dass das traditionelle Switching über VLANs besser ist, als wenn dies mit Flows realisiert wird.

bachelor-diplomarbeit informatik software defined network ... · openflow with opendaylight, but...

Documents