Software Defined Networking (SDN) mit
OpenDaylight
BETEILIGTE PERSONEN
FH Joanneum- Informationsmanagement JG 2013:
 SCHL...
INHALT
Beteiligte Personen...................................................................................................
Abbildung 2: Layerdarstellung [2]
1 SOFTWARE DEFINED NETWORKING
1.1 BEGRIFFE UND ERKLÄRUNG
Der Begriff "Software-Defined N...
muss also nicht mehr manuell konfiguriert werden. SDN gibt den Netzwerkadministratoren eine
programmierbare, zentrale Steu...
1.3 VORTEILE VON SDN
 Direkte Programmierbarkeit
Der Netzwerkfluss kann individuell beeinflusst werden und direkt „anprog...
eingesetzt die durchaus älter als 10 Jahre sind und zu dieser Zeit das SDN Konzept erst im Anfangsstadium
war. Viele moder...
SDN Controller. Diese Anforderungen werden sehr oft bei neuen Cloud Technologien verwendet und
haben großes Zukunftspotent...
2.2 FUNKTIONALITÄT UND AUFBAU
Mit OpenDaylight kann ein Anwender/in selber einen SDN Controller erstellen und damit auf di...
2.3 HARDWARE UND SOFTWARE REQUIREMENTS
Die OpenDaylight Software ist Linux-basierend, man benötigt dazu also ein Linux Bet...
2.4 MININET
Mit Mininet lassen sich ganze Netzwerke mit vielen Hosts, Switches und Hubs mit einem einzigen Befehl
erzeugen...
2.6 PRAXISTEIL: EINRICHTEN EINES SDNCONTROLLERS
Es gibt zwei Möglichkeiten für einen SDN-Konrolleraufbau:
 Komplettes man...
Nach dem richtige konfigurieren kann die VM
gestartet werden, die Ubuntu Maschine sollte nun
laufen und ein Firefox Fenste...
Danach wird es Zeit ein Testnetzwerk mit dem Programm Mininet zu simulieren. Dazu wird eine
Terminalkonsole geöffnet und f...
Nach dem Erstellen testeten wir das Netzwerk mit dem Ping Befehl. In Mininet kann man mit dem
Befehl „<hostname> ping <hos...
Hier nun die Darstellung mit ODL Controller
Abbildung 9: Mininet mit ODL Controller [7]
Als nächstes wird der Controller g...
Am Ende sollte eine Meldung „BUILD SUCCESS“ das erfolgreiche Builden der Controlleranwendung
bestätigen. Jetzt wird der Co...
Maven hat im Projektverzeichnis des HUB/L2 Switch eine run.sh Datei erstellt, mit dieser Datei kann der
Controller gestart...
Mit dem Befehl „printnodes“ werden alle Netzwerkgeräte angezeigt, die mit dem Controller verbunden
sind:
Hier sieht man nu...
2.7 GRAFISCHE OBERFLÄCHE DES OPENDAYLIGHT CONTROLLERS
Der ODL Controller bietet auch eine grafische Oberfläche an, diese l...
Gesamtübersicht GUI:
Links befindet sich die Liste mit allen
Netzwerkgeräten, die mit dem Controller
verbunden sind. Mit e...
Im Fenster unterhalb des Topologie Bereichs befindet sich Informationen über das aktuell ausgewählte
Objekt in der Topolog...
Um die Flussregel nun zu testen, probieren wir nun einfach einen Ping von Host 1 auf Host 8 aus.
Anschließend ein Ping von...
3 PROGRAMMCODE DES HUB/L2 MAC LEARNING SWITCH
Hier wird kurz auf den Programmcode eingegangen, den wir für unseren SDN Con...
import org.opendaylight.controller.sal.action.Flood;
import org.opendaylight.controller.sal.match.Match;
import org.openda...
}
void destroy() {
}
void start() {
logger.info("Started");
}
void stop() {
logger.info("Stopped");
}
private void floodPa...
// und somit versendet
this.dataPacketService.transmitDataPacket(inPkt);
}
}
return PacketResult.CONSUME;
}
private void l...
4 RESÜMEE
Grundsätzlich ist die Idee von SDN-Netzwerken sehr gut, jedoch der aktuelle Status der Software
(OpenDaylight) i...
Wir finden es sehr gut, dass man wirklich jedes Netzwerkgerät selber programmieren kann, sehen jedoch
auch die möglichen S...
5 QUELLENVERZEICHNIS
5.1 LITERATUR/ONLINEQUELLEN
Hier sind die Quellen kapitelweise aufgeführt, die Inhalte wurden teilwei...
https://www.opennetworking.org/images/stories/downloads/sdn-resources/solution-briefs/sb-sdn-nvf-
solution.pdf
OpenDayligh...
5.2 BILDQUELLEN
[1] http://blogs.cisco.com/ciscoit/sdn-101-what-it-is-why-it-matters-and-how-to-do-it
[2] https://www.open...
Nächste SlideShare
Wird geladen in …5
×

Open Daylight, german introduction

305 Aufrufe

Veröffentlicht am

Diese Dokument ist eine Einführung in das Thema Software Defined Networking, im speziellen geht es um die SDN Lösung OpenDaylight, ein Übungsszenario wird aufgebaut und die dahinterliegente Technik erklärt; This is german a introduction to SDN Controller, especially to OpenDaylight

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
305
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
5
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Open Daylight, german introduction

  1. 1. Software Defined Networking (SDN) mit OpenDaylight BETEILIGTE PERSONEN FH Joanneum- Informationsmanagement JG 2013:  SCHLÖGL Ferdinand  JANUSCH Micheal  URCH Stephan BESCHREIBUNG/ZIELSETZUNG Software Defined Networking (SDN) wurde als neuer Ansatz zu Aufbau und Management von Computernetzen konzipiert. OpenDaylight ist einer der ersten umfassenden Implementierungskonzepte auf Open Source-Basis. In dieser Arbeit soll das Konzept von SDNs und Network Function Virtualization (NFV) anhand von OpenDaylight dargestellt werden und der Stand der Implementierung an einem Prototyp praktisch erprobt werden.
  2. 2. INHALT Beteiligte Personen.......................................................................................................................................1 Beschreibung/Zielsetzung.............................................................................................................................1 1 Software Defined Networking ..............................................................................................................3 1.1 Begriffe und Erklärung ..................................................................................................................3 1.2 Layer und Northbound/Southbound APIs ....................................................................................4 1.3 Vorteile von SDN...........................................................................................................................5 1.4 Mögliche Nachteile von SDN-Lösungen........................................................................................5 1.5 NFV................................................................................................................................................6 1.6 NFV + SDN .....................................................................................................................................6 2 Praxisanwendung von OpenDaylight....................................................................................................7 2.1 Allgemeines...................................................................................................................................7 2.2 Funktionalität und Aufbau............................................................................................................8 2.3 Hardware und Software Requirements........................................................................................9 2.4 Mininet........................................................................................................................................10 2.5 Maven .........................................................................................................................................10 2.6 Praxisteil: Einrichten eines SDN Controllers ...............................................................................11 2.7 Grafische Oberfläche des OpenDaylight Controllers..................................................................19 2.8 Eine Flussregel (Flow rule) mit der GUI erstellen........................................................................21 3 Programmcode des HUB/L2 MAC learning Switch .............................................................................23 4 Resümee..............................................................................................................................................27 5 Quellenverzeichnis..............................................................................................................................29 5.1 Literatur/Onlinequellen ..............................................................................................................29 5.2 Bildquellen ..................................................................................................................................31
  3. 3. Abbildung 2: Layerdarstellung [2] 1 SOFTWARE DEFINED NETWORKING 1.1 BEGRIFFE UND ERKLÄRUNG Der Begriff "Software-Defined Networking" wurde 2009 von Kate Greene geprägt, und somit ein recht neuer Ansatz in der Netzwerktechnik. Software-Defined Networking (oder abgekürzt: SDN) ist ein Ansatz zum Bau von Computernetzwerk-Geräten und Software. In herkömmlichen Netzwerken befand sich die Logik, welche für die Paketweiterleitung zuständig ist direkt in den Geräten (Control Plane z.B. Statische Routen, benachbarte Geräte, Informationen von Routingprotokollen…). Abhängig von diesen Informationen werden die Pakete dann über die Data Plane (Datenleitungen im herkömmlichen Sinn) versendet. Abbildung 1: SDN Konzept [1] Bei SDN Lösungen wird die Data Plane und Control Plane voneinander getrennt. Somit können die Pakete zentral von einem „Controller“ gesteuert werden. Diese Controller bieten Programmierschnittstellen (APIs) um andere Programmen/Applikationen an den Controller anbinden zu können. Dadurch ist es möglich sehr individuelle Softwarelösungen für die Netzwerksteuerung zu erstellen oder auch das Einbinden von Netzwerkfunktionen in jede beliebige Applikation. Des Weiteren ermöglicht SDN Netzwerkadministratoren, das Netzwerk einfacher zu verwalten, indem die unteren Funktionsebenen in virtuelle Services abstrahiert werden. Die Hardware
  4. 4. muss also nicht mehr manuell konfiguriert werden. SDN gibt den Netzwerkadministratoren eine programmierbare, zentrale Steuerung des Netzwerkverkehrs, ohne manuellen Zugriff auf die einzelnen physischen Netzwerkkomponenten vornehmen zu müssen. Eine weitere Stärke von SDNs sind die vielen APIs. Wie viele davon angeboten werden hängt vom SDN Produkt ab. Eine Voraussetzung für SDN ist ein Kommunikationskanal zwischen Data Plane und Control Plane, damit der Datenfluss in der Data Plane auch die „Anweisungen“ über die Control Plane bekommt. Dafür gibt es verschiedene Protokolle, ein weitverbreitetes Protokoll ist das OpenFlow Protokoll. OpenFlow wird auch in OpenDaylight verwendet. 1.2 LAYER UND NORTHBOUND/SOUTHBOUND APIS Ein SDN Netzwerk lässt sich schematisch in drei Layer/Komponenten aufteilen, der Infrastructure Layer, der Control Layer und der Application Layer. Im Control Layer befindet sich der SDN Controller, der die Logik und Regeln des Netzwerkes enthält. Der SDN Controller im Control Layer kommuniziert mit den Geräten im darunterliegenden Infrastructure Layer über sogenannte „Southbound APIs“ (südliche Schnittstellen = nach unten, vom Controller aus gesehen; Kommunikationsweg zu einem Gerät das hierarchisch darunterliegt). Wie oben erwähnt ist OpenFlow eine vebreitete Southbound-API, es gibt aber noch andere Kommunikationsprotokolle wie z.B. NETCONF, OVSDB, LISP, BGP, SNMP (auch sehr verbreitete Southbound-Schnittstelle). Über dem Control Layer befindet sich der Application Layer, in diesem werden die Applikation dargestellt, die mit dem Controller kommunizieren. Das können selbstgeschriebene Programme sein die das Netzwerk steuern oder konfigurieren können oder auch andere Anwendungen die über sogenannte Northbound APIs (Norden= nach oben, vom Controller aus; höhere Anwendungsschicht) kommunizieren. Beispielsweise die Rest Api mit welche man dann mit Python, Java, C… Anwendungen interagieren kann. Abbildung 3:Layer und N/S-APIs
  5. 5. 1.3 VORTEILE VON SDN  Direkte Programmierbarkeit Der Netzwerkfluss kann individuell beeinflusst werden und direkt „anprogrammiert“ werden.  Flexibilität Da die Flusskontrolle einheitlich und sehr schnell für alle Geräte geändert werden, da sie abstrahiert ist und als Ganzes geändert werden kann.  Zentrale Verwaltung Die Netzwerklogik (die Intelligenz) kann zentral für alle Geräte verwaltet werden, sie liegt im SDN- Controller, dadurch erhält man mehr Übersicht über alle Regeln und Einstellungen der einzelnen Devices. Es ist möglich eine riesige Anzahl von Geräten mit wenig Aufwand zu konfigurieren.  Programmatische Konfiguration In SDN Netzwerken ist es möglich auf den SDN-Controller automatische SDN Programme auszuführen, die z.B. Einstellungen für gewisse Devices ausrollen etc…  Kosten/Zeitersparnis Durch die zentrale Verwaltung kann Zeit gespart werden, weil man nicht jedes Gerät einzeln konfigurieren muss, bzw. keine Entfernungen zurücklegen muss um die Geräte zu erreichen. Es lässt sich alles am Controller konfigurieren.  Monitoring Auch das Überwachen und Aufzeichnen wird dadurch leichter, der Controller kann den Gesamten Traffic des Netzwerkes zentral überwachen.  Quelloffene Lösungen Es gibt Open Source SDN Controller und auch viele offene Standards werden benutzt (OpenFlow)  Modularität In SDN Netzwerken lassen sich viele Vorgänge, wie z.B. das Konfigurieren von Geräten, als Funktionen auslagern. Diese Module können dann per Software in verschiedenen Anwendungsfällen immer aufgerufen werden.  Sicherheit Durch die zentrale Verwaltung von allen Netzwerkregeln (Routen, Firewall settings,…) hat man erheblich mehr Übersicht über bereits implementierte Sicherheitsregeln. 1.4 MÖGLICHE NACHTEILE VON SDN-LÖSUNGEN Durch die starke Zentralisierung der Netzwerklogik und Regeln auf einen oder mehreren SDN Controllern verringert man die Angriffsfläche für Attacken zwar erheblich, jedoch hängt dann das ganze Netzwerk von diesen Controllern ab. Diese müssen ausfallsicher konzipiert werden, des Weiteren muss fremdes Zugreifen und Einwirken verhindert werden, da sonst die Sicherheit des gesamten Netzwerkes in Gefahr ist. Ein weiterer Nachteil ist, dass viele Geräte keine passenden Southbound-APIs unterstützen, da der SDN Gedanke und die darin benutzten Protokolle recht neu sind. In der Praxis werden aber gerne noch Geräte
  6. 6. eingesetzt die durchaus älter als 10 Jahre sind und zu dieser Zeit das SDN Konzept erst im Anfangsstadium war. Viele moderne Netzwerkgeräte unterstützen z.B. das OpenFlow Protokoll, jedoch können die Anschaffungskosten moderner Router/Switches recht hoch werden, je nach Netzwerkgröße. 1.5 NFV NFV ist ein ganz neues Konzept im Netzwerkbereich. Konkret wurde das Konzept erstmals in einem White Paper 2012 behandelt. NFV steht für „Network Functions Virtualisation“. NFV soll die Virtualisierung von ganzen Netzwerkfunktionen ermöglichen. Damit könnte man z.B. Firewalls, Load-Balancer und Intrusion Detection-Devices vollständig virtualisieren. Abbildung 4: NFV Prinzip [4] Damit lassen sich sehr flexible Netzwerke aufbauen und man kann dadurch Geld sparen 1.6 NFV + SDN Virtualisierte Netzwerkkomponenten (NFV) in Kombination mit SDN Controllern, die die gesamte Netzwerklogik steuern können und als Softwareschnittstelle fungieren, sind ideale Komponenten für um hochflexible Netzwerke aufbauen zu können. Netzwerke können mit virtuellen Geräten sehr dynamisch und flexibel erweitert werden, die Steuerung der neu erstellten virtuellen Netzwerkgeräte übernimmt der
  7. 7. SDN Controller. Diese Anforderungen werden sehr oft bei neuen Cloud Technologien verwendet und haben großes Zukunftspotential. 2 PRAXISANWENDUNG VON OPENDAYLIGHT 2.1 ALLGEMEINES Das OpenDaylight Projekt ist ein quelloffenes Projekt der „Linux Foundation“. Ziel des Projektes ist es den Einsatz von SDN Netzwerken zu fördern und eine solide Basis für NFV-Komponenten zu bieten. Am 8. April 2013 wurde die Gründung des Projektes von der Linux Foundation angekündigt. Viele Firmen unterstützen das Projekt: Abbildung 5: Platinum Partner [4] Dies sind nur die Platinum Member(Hauptpartner/Unterstützer des Projektes), es gibt jedoch noch viele andere Partnerschaften. Die aktuelle/stabile Version des Projektes ist „OpenDaylight Helium“, der nächste geplante Release soll „Lithium“ heißen. Im folgenden Kapitel wird die Funktionalität von OpenDaylight erklärt.
  8. 8. 2.2 FUNKTIONALITÄT UND AUFBAU Mit OpenDaylight kann ein Anwender/in selber einen SDN Controller erstellen und damit auf die Control Plane der Netzwerkgeräte zugreifen und somit den Netzwerkverkehr zentral steuern und Geräte zentral verwalten. Vorausgesetzt die Hardware Komponenten unterstützen ein Protokoll, das für eine SDN Controlleransteuerung geeignet ist. OpenFlow ist ein sehr gut geeigneter Standard für solche Anwendungen, jedoch müssen die Geräte dafür „OpenFlow Enabled“ sein um mit dem Controller kommunizieren zu können (siehe Grafik). Des Weiteren werden viele andere Protokolle unterstützt. In der Controller Komponente befindenden sich einige integrierte Basisfunktionen (Topologie Manager, Switch Manager, Stats Manager…) und sind ohne weiteren Installationsaufwand und Programmieraufwand zugänglich. Diese werden in einem späteren Kapitel noch genau vorgestellt. Ganz oben in der Grafik sind die Northbound APIs abgebildet, sie sind für die Kommunikation mit hierarchisch „höhere“ Objekte zuständig. Z.B. DLUX, eine grafische Oberfläche. Abbildung 6: OpenDaylight Schema [5]
  9. 9. 2.3 HARDWARE UND SOFTWARE REQUIREMENTS Die OpenDaylight Software ist Linux-basierend, man benötigt dazu also ein Linux Betriebssystem und das JDK 1.7+ (Java Developement Kit), auch Maven wird benötigt um die Controllerapplikation zu „builden“. OpenDaylight Controller sind nichts anderes als Java Programme und laufen in einer Java VM. Für Testzwecke eignet sich eine virtuelle Maschine mit einer gängigen Linux Distribution sehr gut (VirtualBox, VmWarePlayer…). Auf der VM kann dann der OpenDaylight Controller installiert und gestartet werden. Die virtuelle Maschine sollte jedoch genügend Arbeitsspeicher zur Verfügung haben, da der Controller im Betrieb sehr rechenintensiv ist, vor allem wenn mehrere Virtualisierungschichten (Linux Virtualisierung, Java Virtual Machine) dazwischen liegen. Die Hardware die man verwendet muss „OpenFlow-enabled“ sein. Die uns angebotenen 2911-Router von Cisco sind nicht OpenFlow-enabled, also entschieden wir uns für ein virtuelle Lösung. Um ein Übungsnetzwerk mit Hosts und Hubs/Switches vollkommen zu simulieren bzw. virtualisieren zu können benötigten wir dazu eine geeignete Software, das Linux Programm „Mininet“. Wir machten jedoch die Erfahrung, dass eine virtuelle Linux Maschine, die ein Netzwerk virtualisiert und auf der ein SDN Controller läuft sehr viel Arbeitsspeicher benötigt. Wir empfehlen hier 4GB+ Arbeitsspeicher zuzuweisen. Testszenario:
  10. 10. 2.4 MININET Mit Mininet lassen sich ganze Netzwerke mit vielen Hosts, Switches und Hubs mit einem einzigen Befehl erzeugen. Das Pingen und Erzeugen von Traffic kann über das Programm simuliert werden, des Weiteren können IP Adressen/MAC Adressen konfiguriert werden. Abbildung 7: Mininet [6] 2.5 MAVEN Wie bereits erwähnt sind OpenDaylight SDN-Controller Java Programme, um diese verwalten und erstellen zu können wird Maven benötigt. Typisch für Maven ist, dass Projekte eine pom.xml Datei enthalten, in der Informationen über das Softwareprojekt enthalten.
  11. 11. 2.6 PRAXISTEIL: EINRICHTEN EINES SDNCONTROLLERS Es gibt zwei Möglichkeiten für einen SDN-Konrolleraufbau:  Komplettes manuelles Zusammensetzen der benötigten Komponenten: Auswahl einer Linux Distribution, Installieren der OpenDaylight Software mit den gewünschten Features, benötigte APIs und Bibliotheken manuell auswählen und downloaden, Eventuell Netzwerkvirtualisierungssoftware installieren (Mininet etc..) , Softwareentwicklungsumgebung (z.B. Eclipse), Maven für den Controllerbuild, JDK downloaden  Vorgefertigte VMs für Test- und Entwicklerzwecke benutzten: Es gibt für Tutorial und Testzwecke bereits vorgefertigte Virtuelle Maschinen, die man für Entwicklungs- und Probeszenarien verwenden kann. Wir entschieden uns für eine vorgefertigte VM und für die Virtualisierungssoftware „Virtual Box“: http://sdnhub.org/tutorials/sdn-tutorial-vm/ https://www.virtualbox.org/ Nach dem Download und der Installation von Virtualbox kann man die VM in Virtualbox einbinden: Das Importieren kann eine Weile dauern Danach sollte ein Fenster mit den Hardware-Spezifikationen erscheinen, diese sollten wie oben bereits erwähnt großzügig gewählt werden und vor dem Starten der Maschine konfiguriert werden.
  12. 12. Nach dem richtige konfigurieren kann die VM gestartet werden, die Ubuntu Maschine sollte nun laufen und ein Firefox Fenster mit einer SDN Startseite sollte erscheinen:
  13. 13. Danach wird es Zeit ein Testnetzwerk mit dem Programm Mininet zu simulieren. Dazu wird eine Terminalkonsole geöffnet und folgender Befehl verwendet: sudo mn: startet das Programm Mininet im Superuser Modus --topo tree: erstellt eine Netzwerk-Baumtopologie --depth=3: gibt die Tiefe des Netzwerkes an, wir wählten 3 --fanout=2: erstellt zweo Hosts an jedem Eckpunkt --switch ovsk,prtocols=OpenFlow13: Gerätetyp für Switches, Open vSwitch, erstellt virtuelle Switches die OpenFlow 1.3 verstehen --controller remote: gibt an, dass ein Controller die Geräte verwaltet, wir benutzen den OpenDaylight Controller dafür Mit Mininet lassen sich auch sehr schnell viele andere Netzwerktopologien simulieren. Auch die Hosts können nach Bedarf konfiguriert werden (MAC, IP). Desweitern verfügt Mininet über eine Python API. Hier wird Minnet sehr gut beschrieben: http://conferences.sigcomm.org/sigcomm/2014/doc/slides/mininet-intro.pdf Nach dem Eingeben des Befehls sollte sich das virtualisierte Netzwerk aufbauen, man kann beobachten wie Hosts und Nodes erstellt werden:
  14. 14. Nach dem Erstellen testeten wir das Netzwerk mit dem Ping Befehl. In Mininet kann man mit dem Befehl „<hostname> ping <hostname>“ Pings simulieren: Es gibt keine Verbindung zwischen den Hosts weil es in diesem Netzwerk noch keinen Controller gibt, der das Netzwerk verwaltet, die virtuellen „Switches“ sind in Wirklichkeit eigentlich noch keine Switches, sondern nur leere Geräte, die auf Anweisungen/Regeln eines Controllers warten. Man muss ihnen noch „beibringen“ wie sie sich verhalten sollen. Jedes Verhalten der Netzwerkgeräte wird in SDN Netzwerke vom Controller gesteuert. Abbildung 8: Mininet ohne ODL Controller [7] Ohne Controller existiert lediglich eine „Forwarding Plane“, auch „Data Plane“. Diese Forwarding Plane ist ohne Logik funktionlos. Der Controller wird dann die Logik für die Forwarding Plane bereitstellten:
  15. 15. Hier nun die Darstellung mit ODL Controller Abbildung 9: Mininet mit ODL Controller [7] Als nächstes wird der Controller gestartet, dazu muss man ein weiteres Terminal öffnen und in das OpenDaylight Verzeichnis wechseln, hier befinden sich die verschiedenen ODL-Projekte (OpenDaylight Projekte). In der Testmaschine befindet sich ein Projekt für einen HUB/L2 learning Switch. Um den Controller mit diesem Code laufen zu lassen muss zuerst mit Maven das Java Programm erstellt werden (der SDN Controller ist eine Java Anwendung, die in einer JavaVM läuft), danach startet man das von Maven erstellte Java Programm, dies ist dann der SDN Controller für das Netzwerk. Praktisch ist, dass in der Testmaschine die Entwicklungsumgebung Eclipse mitinstalliert ist, man kann das Java Projekt und den Code darin komfortabel verändern und betrachten. Auf den Code wird im nächsten Hauptkapitel noch genauer eingegangen. Mit dem Befehl „mvn install –nsu“ sucht Maven im aktuellen Verzeichnis (Das OpenDaylight Verzeichnis) nach Projekten die zu Java Anwendung zusammengefügt werden können. Das sogennante „builden“ startet:
  16. 16. Am Ende sollte eine Meldung „BUILD SUCCESS“ das erfolgreiche Builden der Controlleranwendung bestätigen. Jetzt wird der Controller gestartet.
  17. 17. Maven hat im Projektverzeichnis des HUB/L2 Switch eine run.sh Datei erstellt, mit dieser Datei kann der Controller gestartet werden. Dazu wird in das Verzeichnis gewechselt und mit ./run.sh der Controller gestartet: Der SDN Controller läuft nun. Oben kann man nun erkennen, dass der Controller Geräte gefunden hat, das sind die virtuellen Netzwerk-Nodes die zuvor im Mininet virtuell erstellt worden sind. Mit dem command „ss“ lassen sich auch die Bundles anzeigen, welche im Controller aktiv sind. Darunter sollte sich auch unser HUB/L2 Swtich Bundle befinden, auch ein Tomcat Sever befindet sich darunter, der für das Webinterface zuständig ist.
  18. 18. Mit dem Befehl „printnodes“ werden alle Netzwerkgeräte angezeigt, die mit dem Controller verbunden sind: Hier sieht man nun sieben verbundene Geräte. Jetzt wird es Zeit für einen weiteren Ping Test, man wechselt wieder zurück in das Mininet Terminal und testet mit „hX ping hX“ die Verbindung: Getestet wird die Verbindung zwischen Host 1 und Host 2. Diesmal funktioniert der Test, weil ein Controller läuft. Der Controller enthält den Code/Regeln für den Netzwerkfluss. Ein weiterer Test wurde durchgeführt: Bei beiden Tests kann man erkennen, dass der 1. Ping signifikant länger dauert als die anderen. Der Grund dafür ist, dass die Geräte beim ersten Ping die MAC-Tabellen aufbauen. Beim zweiten Paket kann man bei beiden Tests erkennen, dass die Antwortzeit stark gesunken ist. Die Schwankungen und nicht ganz realen Werte lassen sich durch die Virtualisierung erklären. Anmerkung: Auf der virtuellen Linux Maschine läuft eine virtuelle Java Maschine (SDN Controller) und parallel dazu wird ein ganzes Netzwerk virtualisiert. Hier kommt es gelegentlich zu Performance Problemen beim Testen.
  19. 19. 2.7 GRAFISCHE OBERFLÄCHE DES OPENDAYLIGHT CONTROLLERS Der ODL Controller bietet auch eine grafische Oberfläche an, diese läuft auf einem Webserver auf Port 8080. Man kann mit folgender Adresse die Oberfläche im Browser öffnen: http://localhost:8080 Die Standard Login Daten sind: Username: admin Passwort: admin Als nächstes sollte sich eine grafische Oberfläche öffnen. Man sieht im Hauptbildschirm die Netzwerktopologie, leider ist eine automatische Anordnung der Elemente noch nicht implementiert und man muss die Geräte manuell anordnen. Die grafische Oberfläche ist recht simpel aufgebaut und einige Grundeinstellungen können vorgenommen werden, jedoch werden komplexere Regeln/Anweisungen direkt im Projektordner des SDN Controllers mit Java programmiert. Für einfache Einstellungen ist die grafische Oberfläche sehr wohl geeignet.
  20. 20. Gesamtübersicht GUI: Links befindet sich die Liste mit allen Netzwerkgeräten, die mit dem Controller verbunden sind. Mit einem Doppeklick kann man sie auch umbenennen, für eine bessere Übersicht. Das Fenster im linken unteren Ecke ist für statischen Routen reserviert, hier kann der/die Anwender/in statischen Routen für die Geräte eintragen. Detailaufnahme Topologie:
  21. 21. Im Fenster unterhalb des Topologie Bereichs befindet sich Informationen über das aktuell ausgewählte Objekt in der Topologie Karte. 2.8 EINE FLUSSREGEL (FLOW RULE) MIT DER GUI ERSTELLEN Um die grafische Oberfläche zu testen, werden wir eine Flussregel für ein Gerät erstellen, diese dann installieren und anschließend mit Ping-Befehlen testen. Geplant ist eine Regel am Switch OF13|1 (oberster Switch im Tree), die dafür sorgt, dass keine Datenpakete am Switch vorbeigelassen werden. Somit können Hosts 10.0.0.1 bis 10.0.0.4 keinen der Hosts 10.0.0.5 bis 10.0.0.8 erreichen und umgekehrt. Die Flussregel wird erstellt indem man links auf den Button „Add Flow Entry“ klickt. Danach öffnet sich ein Fenster, in dem weiter Einstellungen zu tätigen sind. Neben dem Namen der Flussregel, muss hier der „node“, also das Gerät auf dem die Regel wirken soll, und anschließend der Input Port ausgewählt werden. Am Ende des Fensters wird unter „Actions“ ausgewäht, was die Regel ausführen soll. In unserem Fall wollen wir, dass alle Pakete verworfen werden, also ist hier „Drop“ auszuwählen. Anschließend wird unter „Save Flow“ die Flussregel gespeichert. Nun schließt sich das Fenster und wir sehen auf der linken Seite, dass die Flussregel erscheint. Diese kann jetzt ausgewählt werden und wird durch das Klicken auf „Install Flow“ im Fenster unter der Topologiefrafik angewandt.
  22. 22. Um die Flussregel nun zu testen, probieren wir nun einfach einen Ping von Host 1 auf Host 8 aus. Anschließend ein Ping von Host 1 auf Host 4. Da die Flussregel auf den Switch OF 13|1 wirkt, darf der erste Ping (Host 1 auf Host 8) nicht funktionieren. Der zweite jedoch (Host 1 auf Host 4), soll wie gewohnt ablaufen. h1 kann h8 nicht pingen h1 kann h4 pingen
  23. 23. 3 PROGRAMMCODE DES HUB/L2 MAC LEARNING SWITCH Hier wird kurz auf den Programmcode eingegangen, den wir für unseren SDN Controller verwendeten. Am Anfang werden die benötigten Imports gemacht, danach Grundvariablen definiert. Die folgenden Funktionen sind für den Dependency Manager. Die eigentliche Hauptlogik des Switches/HUBs ist fett markiert und wird genauer betrachtet (siehe rote Kommentare //). /* * Copyright (C) 2014 SDN Hub Licensed under the GNU GENERAL PUBLIC LICENSE, Version 3. You may not use this file except in compliance with this License. You may obtain a copy of the License at http://www.gnu.org/licenses/gpl-3.0.txt Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * */ package org.opendaylight.tutorial.tutorial_L2_forwarding.internal; import java.net.InetAddress; import java.net.UnknownHostException; import java.util.List; import java.util.ArrayList; import java.util.Collections; import java.util.HashSet; import java.util.Set; import java.lang.String; import java.util.Map; import java.util.HashMap; import java.util.Timer; import java.util.TimerTask; import java.util.concurrent.ConcurrentHashMap; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.osgi.framework.Bundle; import org.osgi.framework.BundleContext; import org.osgi.framework.BundleException; import org.osgi.framework.FrameworkUtil; import org.opendaylight.controller.sal.core.ConstructionException; import org.opendaylight.controller.sal.core.Node; import org.opendaylight.controller.sal.core.NodeConnector; import org.opendaylight.controller.sal.flowprogrammer.IFlowProgrammerService; import org.opendaylight.controller.sal.flowprogrammer.Flow; import org.opendaylight.controller.sal.packet.ARP; import org.opendaylight.controller.sal.packet.BitBufferHelper; import org.opendaylight.controller.sal.packet.Ethernet; import org.opendaylight.controller.sal.packet.ICMP; import org.opendaylight.controller.sal.packet.IDataPacketService; import org.opendaylight.controller.sal.packet.IListenDataPacket; import org.opendaylight.controller.sal.packet.Packet; import org.opendaylight.controller.sal.packet.PacketResult; import org.opendaylight.controller.sal.packet.RawPacket; import org.opendaylight.controller.sal.action.Action; import org.opendaylight.controller.sal.action.Output;
  24. 24. import org.opendaylight.controller.sal.action.Flood; import org.opendaylight.controller.sal.match.Match; import org.opendaylight.controller.sal.match.MatchType; import org.opendaylight.controller.sal.match.MatchField; import org.opendaylight.controller.sal.utils.EtherTypes; import org.opendaylight.controller.sal.utils.Status; import org.opendaylight.controller.sal.utils.NetUtils; import org.opendaylight.controller.switchmanager.ISwitchManager; import org.opendaylight.controller.switchmanager.Subnet; public class TutorialL2Forwarding implements IListenDataPacket { private static final Logger logger = LoggerFactory .getLogger(TutorialL2Forwarding.class); private ISwitchManager switchManager = null; private IFlowProgrammerService programmer = null; private IDataPacketService dataPacketService = null; private Map<Long, NodeConnector> mac_to_port = new HashMap<Long, NodeConnector>(); private String function = "switch"; void setDataPacketService(IDataPacketService s) { this.dataPacketService = s; } void unsetDataPacketService(IDataPacketService s) { if (this.dataPacketService == s) { this.dataPacketService = null; } } public void setFlowProgrammerService(IFlowProgrammerService s) { this.programmer = s; } public void unsetFlowProgrammerService(IFlowProgrammerService s) { if (this.programmer == s) { this.programmer = null; } } void setSwitchManager(ISwitchManager s) { logger.debug("SwitchManager set"); this.switchManager = s; } void unsetSwitchManager(ISwitchManager s) { if (this.switchManager == s) { logger.debug("SwitchManager removed!"); this.switchManager = null; } } void init() { logger.info("Initialized"); // Disabling the SimpleForwarding and ARPHandler bundle to not conflict with this one BundleContext bundleContext = FrameworkUtil.getBundle(this.getClass()).getBundleContext(); for(Bundle bundle : bundleContext.getBundles()) { if (bundle.getSymbolicName().contains("simpleforwarding")) { try { bundle.uninstall(); } catch (BundleException e) { logger.error("Exception in Bundle uninstall "+bundle.getSymbolicName(), e); } } }
  25. 25. } void destroy() { } void start() { logger.info("Started"); } void stop() { logger.info("Stopped"); } private void floodPacket(RawPacket inPkt) { NodeConnector incoming_connector = inPkt.getIncomingNodeConnector(); Node incoming_node = incoming_connector.getNode(); Set<NodeConnector> nodeConnectors = this.switchManager.getUpNodeConnectors(incoming_node); for (NodeConnector p : nodeConnectors) { if (!p.equals(incoming_connector)) { try { RawPacket destPkt = new RawPacket(inPkt); destPkt.setOutgoingNodeConnector(p); this.dataPacketService.transmitDataPacket(destPkt); } catch (ConstructionException e2) { continue; } } } } @Override // Hier wird die Funktion für das erhalten von Paketen überschrieben, Was soll ich bei einem incoming Packet tun? public PacketResult receiveDataPacket(RawPacket inPkt) { if (inPkt == null) { //hier wird geprüft ob das incoming Packet null ist, um NullPointerExceptions zu vermeiden return PacketResult.IGNORED; } NodeConnector incoming_connector = inPkt.getIncomingNodeConnector(); // Hub implementation, man kann mit der functions Variabel den Switch auch auf einen einfachen HUB umstellen if (function.equals("hub")) { floodPacket(inPkt); // dann “flooded” er einfach alle Pakete an alle Ports, floodPacket() } else { Packet formattedPak = this.dataPacketService.decodeDataPacket(inPkt); //wenn er nicht im HUB Mode ist, if (!(formattedPak instanceof Ethernet)) { // wird das Packet decodiert/zerlegt return PacketResult.IGNORED; } learnSourceMAC(formattedPak, incoming_connector); // und danach vom zerlegten Packet (formattedPak) die NodeConnector outgoing_connector = // Source MAC Adresse gelernt und mit dem Port verknüpft // (in die MAC Table aufnehmen, siehe Funktion „learnSource // MAC“) knowDestinationMAC(formattedPak); // Hier wird dann die Ziel MAC mit dem richtigen Zielport // verknüfpt, das Packet kann jetzt dahin weitergeleitet // werden if (outgoing_connector == null) { // falls es hier aber zu einen “Nullpointer” kommt, kennt der floodPacket(inPkt); // Switch das Ziel noch nicht und flooded das Packet } else { // (broadcasten) if (!programFlow(formattedPak, incoming_connector, outgoing_connector)) { return PacketResult.IGNORED; } inPkt.setOutgoingNodeConnector(outgoing_connector); // falls es zu keinen Nullpointer kam, kennt der Switch // das Ziel und das Packet wird nun an den Outgoing // Connector (Port mit der Destination MAC) weitergeleitet
  26. 26. // und somit versendet this.dataPacketService.transmitDataPacket(inPkt); } } return PacketResult.CONSUME; } private void learnSourceMAC(Packet formattedPak, NodeConnector incoming_connector) { byte[] srcMAC = ((Ethernet)formattedPak).getSourceMACAddress(); long srcMAC_val = BitBufferHelper.toNumber(srcMAC); this.mac_to_port.put(srcMAC_val, incoming_connector); } // Hier ist die Funktion für das Lernen der MAC Adresse, zuerst wird das zerlegte Packet (formattedPak) // mit .getSourceMACAddress() angesprochen, diese wird dann als byte Folge gespeichert und nachher in ein // Variable des Typs long umgewandelt, danach wird sie mit dem icoming Port in einer Hashmap ( globale Variable // mac_to_port, sozusagen die MAC Table) verknüpft private NodeConnector knowDestinationMAC(Packet formattedPak) { byte[] dstMAC = ((Ethernet)formattedPak).getDestinationMACAddress(); long dstMAC_val = BitBufferHelper.toNumber(dstMAC); return this.mac_to_port.get(dstMAC_val) ; } // In der knowDestinationMAC Funktion wird der Ziel Port für eine bestimmte MAC zurückgegeben, // die Funktion liefer null zurück, wenn dieser nicht bekannt ist, im Code oben wird in so einem Fall // dann gebroadcastet (siehe if (outgoing_connector == null)) private boolean programFlow(Packet formattedPak, NodeConnector incoming_connector, NodeConnector outgoing_connector) { byte[] dstMAC = ((Ethernet)formattedPak).getDestinationMACAddress(); Match match = new Match(); match.setField( new MatchField(MatchType.IN_PORT, incoming_connector) ); match.setField( new MatchField(MatchType.DL_DST, dstMAC.clone()) ); List<Action> actions = new ArrayList<Action>(); actions.add(new Output(outgoing_connector)); Flow f = new Flow(match, actions); f.setIdleTimeout((short)5); // Modify the flow on the network node Node incoming_node = incoming_connector.getNode(); Status status = programmer.addFlow(incoming_node, f); if (!status.isSuccess()) { logger.warn("SDN Plugin failed to program the flow: {}. The failure is: {}", f, status.getDescription()); return false; } else { return true; } } }
  27. 27. 4 RESÜMEE Grundsätzlich ist die Idee von SDN-Netzwerken sehr gut, jedoch der aktuelle Status der Software (OpenDaylight) ist noch sehr weit von einer „Marktreife“ entfernt. Es gibt zwar eine grafische Oberfäche, diese ist jedoch mehr ein kleines „Feature“ und keine richtige Oberfläche mit vielen Funktionen. Wir haben es auch sehr lästig empfunden, das OpenDaylight nicht mit der neuesten Java Version funktioniert, wir hatten nämlich eine Linux Maschinen manuell zusammengestellt (mit der neuesten Java Version-JDK) und danach funktionierte der Controller nicht. Wir mussten ein Downgrade durchführen und hatten dabei keinen Erfolg, da es bei Linux keine so komfortable Softwareverwaltung wie bei Windows gibt. Daher mussten wir die Maschine neu aufsetzen. Aufgefallen ist uns außerdem der „Hardwarehunger“ des Controllers, zugegeben wir virtualisierten ein ganzes Netzwerk nebenbei, jedoch sollte eine virtuelle Maschinen mit einem OpenDaylight Controller mindestens 4GB Arbeitsspeicher haben. Mit mininet machten wir gute Erfahrungen, mit diesem Programm ist es enorm einfach Netzwerke zu simulieren. Mit einem Befehl lassen sich große Netzwerke virtualisieren, die auch sehr leicht zu konfigurieren sind (IP, MAC). Aber ab einer gewissen Größe benötigt man auch wieder mehr Arbeitsspeicher, man sollte es bei 3-5 Knoten und 5-15 Hosts belassen, wenn man nicht gerade High-End Geräte besitzt. Nun zum Controller, die Logik der Controller sind in Java geschrieben, der Code ist eigentlich auch nicht schwer zu verstehen, jedoch findet man wenig Literatur und Sourcecodes für Netzwerkgeräte. Es ist möglich jedes Netzwerkgerät komplett manuell zu programmieren (Alles, die Logik, die Funktionen, das Verhalten, Sicherheitsregeln). Man kann z.B. eingehende Pakete bis zu Layer 2 zerlegen und dann programmatische Anweisungen geben, was mit dem Paket passieren soll. Auch ist es möglich andere Applikation mit integrieren, also eine sehr „mächtige“ Lösung. Wir sehen aber genau bei diesen Punkten ein großes Problem, durch das vollständige Individualisieren der Netzwerkfunktion mit eigenen Programmcode kann es zu großen Sicherheitsproblemen kommen, allein schon durch die Tatsache, dass z.B. ein Admin einfach nicht alle Sicherheitslücken programmatisch „eliminiert“, weil es fast unmöglich ist an alle Eventualitäten zu denken. Außerdem, wenn die SDN Controller ausfallen, funktioniert das gesamte Netzwerk nicht mehr, auch wenn ein Hacker den Controller übernimmt, hat er Vollzugriff auf Alles. Für Unterrichtszwecke würde sich ein OpenDaylight Szenario unserer Meinung nach sehr gut eignen, vor allem für IMA Studenten ab dem 4. Semester. Man benötigt so ziemlich genau all jene Dinge, die man im Studiengang gelernt hat.  Grundlagen Linux: SADML  Java Kenntnisse für den Controllercode: SWENGA, SWENGB  Netzwerkkentnisse/Protokolle: HVSYS, Netzwerkfächer Ein Problem wäre aber die unserer Meinung nach die sehr instabile Arbeitsumgebung, weil das Produkt noch nicht ausgereift ist. Die aktuelle Version ist für ein nicht kommerzielles Projekt schon recht weit, aber man sollte weiter Entwicklungen abwarten. Die Technologie ist sehr vielversprechend!
  28. 28. Wir finden es sehr gut, dass man wirklich jedes Netzwerkgerät selber programmieren kann, sehen jedoch auch die möglichen Sicherheitsrisiken. Wir sind der Meinung, Firmen sollten SDN Lösungen mit Vorsicht einsetzen, am besten nur in isolierten Netzwerkbereichen, vielleicht nur in internen Umgebungen.
  29. 29. 5 QUELLENVERZEICHNIS 5.1 LITERATUR/ONLINEQUELLEN Hier sind die Quellen kapitelweise aufgeführt, die Inhalte wurden teilweise mit eigenen Wissen ergänzt. Englische Texte wurden sinngemäß übersetzt. Kapitel oder Bilder ohne Quellenangaben wurden vollständig selbst erfasst oder erstellt. Software Defined Networking: Begriffe und Erklärung: http://en.wikipedia.org/wiki/Software-defined_networking http://de.wikipedia.org/wiki/Software-defined_networking https://www.opennetworking.org/sdn-resources/sdn-definition Layer und North/Southbound API: http://networkstatic.net/the-northbound-api-2/ Vorteile von SDN: https://www.opennetworking.org/sdn-resources/sdn-definition NFV: https://www.opennetworking.org/images/stories/downloads/sdn-resources/solution-briefs/sb-sdn-nvf- solution.pdf NFV + SDN: https://www.sdxcentral.com/sdn-nfv-use-cases/data-center-optimization/ http://en.wikipedia.org/wiki/Network_functions_virtualization#Relationship_to_SDN http://www.opendaylight.org/resources/about-sdn-and-nfv
  30. 30. https://www.opennetworking.org/images/stories/downloads/sdn-resources/solution-briefs/sb-sdn-nvf- solution.pdf OpenDaylight: Allgemeines: http://www.opendaylight.org/project/members http://www.opendaylight.org/project/about http://en.wikipedia.org/wiki/OpenDaylight_Project https://wiki.opendaylight.org/view/Simultaneous_Release:Helium_Release_Plan Hardware und Software Requirements: https://wiki.opendaylight.org/view/Installing_OpenDaylight Mininet: http://mininet.org/ Maven: http://de.wikipedia.org/wiki/Apache_Maven
  31. 31. 5.2 BILDQUELLEN [1] http://blogs.cisco.com/ciscoit/sdn-101-what-it-is-why-it-matters-and-how-to-do-it [2] https://www.opennetworking.org/sdn-resources/sdn-definition [3] http://networkstatic.net/the-northbound-api-2/ [4] http://www.opendaylight.org/project/members [5] http://www.opendaylight.org/sites/www.opendaylight.org/files/pages/images/odp_diagram_helium.jp g [6] http://mininet.org/ [7] https://www.youtube.com/watch?v=TnVON_3bM08

×