Transcript of Open Daylight, german introduction
- 1. Software Defined Networking (SDN) mit OpenDaylight
BETEILIGTE PERSONEN FH Joanneum- Informationsmanagement JG 2013:
SCHLGL 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. INHALT Beteiligte
Personen.......................................................................................................................................1
Beschreibung/Zielsetzung.............................................................................................................................1
1 Software Defined Networking
..............................................................................................................3
1.1 Begriffe und Erklrung
..................................................................................................................3
1.2 Layer und Northbound/Southbound APIs
....................................................................................4
1.3 Vorteile von
SDN...........................................................................................................................5
1.4 Mgliche Nachteile von
SDN-Lsungen........................................................................................5
1.5
NFV................................................................................................................................................6
1.6 NFV + SDN
.....................................................................................................................................6
2 Praxisanwendung von
OpenDaylight....................................................................................................7
2.1
Allgemeines...................................................................................................................................7
2.2 Funktionalitt 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 Oberflche 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
Resmee..............................................................................................................................................27
5
Quellenverzeichnis..............................................................................................................................29
5.1 Literatur/Onlinequellen
..............................................................................................................29
5.2 Bildquellen
..................................................................................................................................31
- 3. Abbildung 2: Layerdarstellung [2] 1 SOFTWARE DEFINED
NETWORKING 1.1 BEGRIFFE UND ERKLRUNG Der Begriff "Software-Defined
Networking" wurde 2009 von Kate Greene geprgt, und somit ein recht
neuer Ansatz in der Netzwerktechnik. Software-Defined Networking
(oder abgekrzt: SDN) ist ein Ansatz zum Bau von
Computernetzwerk-Gerten und Software. In herkmmlichen Netzwerken
befand sich die Logik, welche fr die Paketweiterleitung zustndig
ist direkt in den Gerten (Control Plane z.B. Statische Routen,
benachbarte Gerte, Informationen von Routingprotokollen). Abhngig
von diesen Informationen werden die Pakete dann ber die Data Plane
(Datenleitungen im herkmmlichen Sinn) versendet. Abbildung 1: SDN
Konzept [1] Bei SDN Lsungen wird die Data Plane und Control Plane
voneinander getrennt. Somit knnen die Pakete zentral von einem
Controller gesteuert werden. Diese Controller bieten
Programmierschnittstellen (APIs) um andere Programmen/Applikationen
an den Controller anbinden zu knnen. Dadurch ist es mglich sehr
individuelle Softwarelsungen fr die Netzwerksteuerung zu erstellen
oder auch das Einbinden von Netzwerkfunktionen in jede beliebige
Applikation. Des Weiteren ermglicht SDN Netzwerkadministratoren,
das Netzwerk einfacher zu verwalten, indem die unteren
Funktionsebenen in virtuelle Services abstrahiert werden. Die
Hardware
- 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 mssen. Eine
weitere Strke von SDNs sind die vielen APIs. Wie viele davon
angeboten werden hngt vom SDN Produkt ab. Eine Voraussetzung fr 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. Dafr 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 lsst 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
enthlt. Der SDN Controller im Control Layer kommuniziert mit den
Gerten im darunterliegenden Infrastructure Layer ber sogenannte
Southbound APIs (sdliche Schnittstellen = nach unten, vom
Controller aus gesehen; Kommunikationsweg zu einem Gert das
hierarchisch darunterliegt). Wie oben erwhnt 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
knnen selbstgeschriebene Programme sein die das Netzwerk steuern
oder konfigurieren knnen oder auch andere Anwendungen die ber
sogenannte Northbound APIs (Norden= nach oben, vom Controller aus;
hhere 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. 1.3 VORTEILE VON SDN Direkte Programmierbarkeit Der
Netzwerkfluss kann individuell beeinflusst werden und direkt
anprogrammiert werden. Flexibilitt Da die Flusskontrolle
einheitlich und sehr schnell fr alle Gerte gendert werden, da sie
abstrahiert ist und als Ganzes gendert werden kann. Zentrale
Verwaltung Die Netzwerklogik (die Intelligenz) kann zentral fr alle
Gerte verwaltet werden, sie liegt im SDN- Controller, dadurch erhlt
man mehr bersicht ber alle Regeln und Einstellungen der einzelnen
Devices. Es ist mglich eine riesige Anzahl von Gerten mit wenig
Aufwand zu konfigurieren. Programmatische Konfiguration In SDN
Netzwerken ist es mglich auf den SDN-Controller automatische SDN
Programme auszufhren, die z.B. Einstellungen fr gewisse Devices
ausrollen etc Kosten/Zeitersparnis Durch die zentrale Verwaltung
kann Zeit gespart werden, weil man nicht jedes Gert einzeln
konfigurieren muss, bzw. keine Entfernungen zurcklegen muss um die
Gerte zu erreichen. Es lsst 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 Lsungen Es gibt Open Source SDN
Controller und auch viele offene Standards werden benutzt
(OpenFlow) Modularitt In SDN Netzwerken lassen sich viele Vorgnge,
wie z.B. das Konfigurieren von Gerten, als Funktionen auslagern.
Diese Module knnen dann per Software in verschiedenen
Anwendungsfllen 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 MGLICHE NACHTEILE VON
SDN-LSUNGEN Durch die starke Zentralisierung der Netzwerklogik und
Regeln auf einen oder mehreren SDN Controllern verringert man die
Angriffsflche fr Attacken zwar erheblich, jedoch hngt dann das
ganze Netzwerk von diesen Controllern ab. Diese mssen 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
Gerte keine passenden Southbound-APIs untersttzen, da der SDN
Gedanke und die darin benutzten Protokolle recht neu sind. In der
Praxis werden aber gerne noch Gerte
- 6. eingesetzt die durchaus lter als 10 Jahre sind und zu dieser
Zeit das SDN Konzept erst im Anfangsstadium war. Viele moderne
Netzwerkgerte untersttzen z.B. das OpenFlow Protokoll, jedoch knnen
die Anschaffungskosten moderner Router/Switches recht hoch werden,
je nach Netzwerkgre. 1.5 NFV NFV ist ein ganz neues Konzept im
Netzwerkbereich. Konkret wurde das Konzept erstmals in einem White
Paper 2012 behandelt. NFV steht fr Network Functions
Virtualisation. NFV soll die Virtualisierung von ganzen
Netzwerkfunktionen ermglichen. Damit knnte man z.B. Firewalls,
Load-Balancer und Intrusion Detection-Devices vollstndig
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 knnen
und als Softwareschnittstelle fungieren, sind ideale Komponenten fr
um hochflexible Netzwerke aufbauen zu knnen. Netzwerke knnen mit
virtuellen Gerten sehr dynamisch und flexibel erweitert werden, die
Steuerung der neu erstellten virtuellen Netzwerkgerte bernimmt
der
- 7. SDN Controller. Diese Anforderungen werden sehr oft bei
neuen Cloud Technologien verwendet und haben groes
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 frdern und eine solide Basis fr NFV-Komponenten zu
bieten. Am 8. April 2013 wurde die Grndung des Projektes von der
Linux Foundation angekndigt. Viele Firmen untersttzen das Projekt:
Abbildung 5: Platinum Partner [4] Dies sind nur die Platinum
Member(Hauptpartner/Untersttzer des Projektes), es gibt jedoch noch
viele andere Partnerschaften. Die aktuelle/stabile Version des
Projektes ist OpenDaylight Helium, der nchste geplante Release soll
Lithium heien. Im folgenden Kapitel wird die Funktionalitt von
OpenDaylight erklrt.
- 8. 2.2 FUNKTIONALITT UND AUFBAU Mit OpenDaylight kann ein
Anwender/in selber einen SDN Controller erstellen und damit auf die
Control Plane der Netzwerkgerte zugreifen und somit den
Netzwerkverkehr zentral steuern und Gerte zentral verwalten.
Vorausgesetzt die Hardware Komponenten untersttzen ein Protokoll,
das fr eine SDN Controlleransteuerung geeignet ist. OpenFlow ist
ein sehr gut geeigneter Standard fr solche Anwendungen, jedoch
mssen die Gerte dafr OpenFlow Enabled sein um mit dem Controller
kommunizieren zu knnen (siehe Grafik). Des Weiteren werden viele
andere Protokolle untersttzt. In der Controller Komponente
befindenden sich einige integrierte Basisfunktionen (Topologie
Manager, Switch Manager, Stats Manager) und sind ohne weiteren
Installationsaufwand und Programmieraufwand zugnglich. Diese werden
in einem spteren Kapitel noch genau vorgestellt. Ganz oben in der
Grafik sind die Northbound APIs abgebildet, sie sind fr die
Kommunikation mit hierarchisch hhere Objekte zustndig. Z.B. DLUX,
eine grafische Oberflche. Abbildung 6: OpenDaylight Schema [5]
- 9. 2.3 HARDWARE UND SOFTWARE REQUIREMENTS Die OpenDaylight
Software ist Linux-basierend, man bentigt dazu also ein Linux
Betriebssystem und das JDK 1.7+ (Java Developement Kit), auch Maven
wird bentigt um die Controllerapplikation zu builden. OpenDaylight
Controller sind nichts anderes als Java Programme und laufen in
einer Java VM. Fr Testzwecke eignet sich eine virtuelle Maschine
mit einer gngigen Linux Distribution sehr gut (VirtualBox,
VmWarePlayer). Auf der VM kann dann der OpenDaylight Controller
installiert und gestartet werden. Die virtuelle Maschine sollte
jedoch gengend Arbeitsspeicher zur Verfgung 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 fr ein
virtuelle Lsung. Um ein bungsnetzwerk mit Hosts und Hubs/Switches
vollkommen zu simulieren bzw. virtualisieren zu knnen bentigten 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 luft
sehr viel Arbeitsspeicher bentigt. Wir empfehlen hier 4GB+
Arbeitsspeicher zuzuweisen. Testszenario:
- 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 knnen IP Adressen/MAC Adressen konfiguriert
werden. Abbildung 7: Mininet [6] 2.5 MAVEN Wie bereits erwhnt sind
OpenDaylight SDN-Controller Java Programme, um diese verwalten und
erstellen zu knnen wird Maven bentigt. Typisch fr Maven ist, dass
Projekte eine pom.xml Datei enthalten, in der Informationen ber das
Softwareprojekt enthalten.
- 11. 2.6 PRAXISTEIL: EINRICHTEN EINES SDNCONTROLLERS Es gibt
zwei Mglichkeiten fr einen SDN-Konrolleraufbau: Komplettes
manuelles Zusammensetzen der bentigten Komponenten: Auswahl einer
Linux Distribution, Installieren der OpenDaylight Software mit den
gewnschten Features, bentigte APIs und Bibliotheken manuell
auswhlen und downloaden, Eventuell Netzwerkvirtualisierungssoftware
installieren (Mininet etc..) , Softwareentwicklungsumgebung (z.B.
Eclipse), Maven fr den Controllerbuild, JDK downloaden
Vorgefertigte VMs fr Test- und Entwicklerzwecke benutzten: Es gibt
fr Tutorial und Testzwecke bereits vorgefertigte Virtuelle
Maschinen, die man fr Entwicklungs- und Probeszenarien verwenden
kann. Wir entschieden uns fr eine vorgefertigte VM und fr 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 erwhnt grozgig gewhlt werden und vor dem Starten der
Maschine konfiguriert werden.
- 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. Danach wird es Zeit ein Testnetzwerk mit dem Programm
Mininet zu simulieren. Dazu wird eine Terminalkonsole geffnet 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 whlten 3 --fanout=2: erstellt zweo Hosts an jedem Eckpunkt
--switch ovsk,prtocols=OpenFlow13: Gertetyp fr Switches, Open
vSwitch, erstellt virtuelle Switches die OpenFlow 1.3 verstehen
--controller remote: gibt an, dass ein Controller die Gerte
verwaltet, wir benutzen den OpenDaylight Controller dafr Mit
Mininet lassen sich auch sehr schnell viele andere
Netzwerktopologien simulieren. Auch die Hosts knnen nach Bedarf
konfiguriert werden (MAC, IP). Desweitern verfgt 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. Nach dem Erstellen testeten wir das Netzwerk mit dem Ping
Befehl. In Mininet kann man mit dem Befehl ping 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 Gerte, die auf Anweisungen/Regeln eines
Controllers warten. Man muss ihnen noch beibringen wie sie sich
verhalten sollen. Jedes Verhalten der Netzwerkgerte 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 fr die Forwarding
Plane bereitstellten:
- 15. Hier nun die Darstellung mit ODL Controller Abbildung 9:
Mininet mit ODL Controller [7] Als nchstes 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 fr 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 luft),
danach startet man das von Maven erstellte Java Programm, dies ist
dann der SDN Controller fr das Netzwerk. Praktisch ist, dass in der
Testmaschine die Entwicklungsumgebung Eclipse mitinstalliert ist,
man kann das Java Projekt und den Code darin komfortabel verndern
und betrachten. Auf den Code wird im nchsten Hauptkapitel noch
genauer eingegangen. Mit dem Befehl mvn install nsu sucht Maven im
aktuellen Verzeichnis (Das OpenDaylight Verzeichnis) nach Projekten
die zu Java Anwendung zusammengefgt werden knnen. Das sogennante
builden startet:
- 16. Am Ende sollte eine Meldung BUILD SUCCESS das erfolgreiche
Builden der Controlleranwendung besttigen. Jetzt wird der
Controller gestartet.
- 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 luft nun.
Oben kann man nun erkennen, dass der Controller Gerte 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 fr das Webinterface
zustndig ist.
- 18. Mit dem Befehl printnodes werden alle Netzwerkgerte
angezeigt, die mit dem Controller verbunden sind: Hier sieht man
nun sieben verbundene Gerte. Jetzt wird es Zeit fr einen weiteren
Ping Test, man wechselt wieder zurck 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 luft. Der Controller enthlt den Code/Regeln fr den
Netzwerkfluss. Ein weiterer Test wurde durchgefhrt: Bei beiden
Tests kann man erkennen, dass der 1. Ping signifikant lnger dauert
als die anderen. Der Grund dafr ist, dass die Gerte 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 erklren. Anmerkung: Auf der virtuellen Linux
Maschine luft eine virtuelle Java Maschine (SDN Controller) und
parallel dazu wird ein ganzes Netzwerk virtualisiert. Hier kommt es
gelegentlich zu Performance Problemen beim Testen.
- 19. 2.7 GRAFISCHE OBERFLCHE DES OPENDAYLIGHT CONTROLLERS Der
ODL Controller bietet auch eine grafische Oberflche an, diese luft
auf einem Webserver auf Port 8080. Man kann mit folgender Adresse
die Oberflche im Browser ffnen: http://localhost:8080 Die Standard
Login Daten sind: Username: admin Passwort: admin Als nchstes
sollte sich eine grafische Oberflche ffnen. Man sieht im
Hauptbildschirm die Netzwerktopologie, leider ist eine automatische
Anordnung der Elemente noch nicht implementiert und man muss die
Gerte manuell anordnen. Die grafische Oberflche ist recht simpel
aufgebaut und einige Grundeinstellungen knnen vorgenommen werden,
jedoch werden komplexere Regeln/Anweisungen direkt im Projektordner
des SDN Controllers mit Java programmiert. Fr einfache
Einstellungen ist die grafische Oberflche sehr wohl geeignet.
- 20. Gesamtbersicht GUI: Links befindet sich die Liste mit allen
Netzwerkgerten, die mit dem Controller verbunden sind. Mit einem
Doppeklick kann man sie auch umbenennen, fr eine bessere bersicht.
Das Fenster im linken unteren Ecke ist fr statischen Routen
reserviert, hier kann der/die Anwender/in statischen Routen fr die
Gerte eintragen. Detailaufnahme Topologie:
- 21. Im Fenster unterhalb des Topologie Bereichs befindet sich
Informationen ber das aktuell ausgewhlte Objekt in der Topologie
Karte. 2.8 EINE FLUSSREGEL (FLOW RULE) MIT DER GUI ERSTELLEN Um die
grafische Oberflche zu testen, werden wir eine Flussregel fr ein
Gert erstellen, diese dann installieren und anschlieend mit
Ping-Befehlen testen. Geplant ist eine Regel am Switch OF13|1
(oberster Switch im Tree), die dafr sorgt, dass keine Datenpakete
am Switch vorbeigelassen werden. Somit knnen 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 ttigen sind. Neben dem Namen der
Flussregel, muss hier der node, also das Gert auf dem die Regel
wirken soll, und anschlieend der Input Port ausgewhlt werden. Am
Ende des Fensters wird unter Actions ausgewht, was die Regel
ausfhren soll. In unserem Fall wollen wir, dass alle Pakete
verworfen werden, also ist hier Drop auszuwhlen. Anschlieend wird
unter Save Flow die Flussregel gespeichert. Nun schliet sich das
Fenster und wir sehen auf der linken Seite, dass die Flussregel
erscheint. Diese kann jetzt ausgewhlt werden und wird durch das
Klicken auf Install Flow im Fenster unter der Topologiefrafik
angewandt.
- 22. Um die Flussregel nun zu testen, probieren wir nun einfach
einen Ping von Host 1 auf Host 8 aus. Anschlieend 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. 3 PROGRAMMCODE DES HUB/L2 MAC LEARNING SWITCH Hier wird
kurz auf den Programmcode eingegangen, den wir fr unseren SDN
Controller verwendeten. Am Anfang werden die bentigten Imports
gemacht, danach Grundvariablen definiert. Die folgenden Funktionen
sind fr 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. 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 mac_to_port = new HashMap(); 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. } 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 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 fr das erhalten von Paketen berschrieben, Was
soll ich bei einem incoming Packet tun? public PacketResult
receiveDataPacket(RawPacket inPkt) { if (inPkt == null) { //hier
wird geprft 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
verknpft // (in die MAC Table aufnehmen, siehe Funktion learnSource
// MAC) knowDestinationMAC(formattedPak); // Hier wird dann die
Ziel MAC mit dem richtigen Zielport // verknfpt, 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. // 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 fr 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)
verknpft 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 fr eine bestimmte MAC zurckgegeben, //
die Funktion liefer null zurck, 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 actions = new
ArrayList(); 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. 4 RESMEE Grundstzlich 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 Oberfche, diese ist jedoch mehr ein kleines Feature und
keine richtige Oberflche mit vielen Funktionen. Wir haben es auch
sehr lstig empfunden, das OpenDaylight nicht mit der neuesten Java
Version funktioniert, wir hatten nmlich eine Linux Maschinen
manuell zusammengestellt (mit der neuesten Java Version-JDK) und
danach funktionierte der Controller nicht. Wir mussten ein
Downgrade durchfhren 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
auerdem 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 groe Netzwerke
virtualisieren, die auch sehr leicht zu konfigurieren sind (IP,
MAC). Aber ab einer gewissen Gre bentigt man auch wieder mehr
Arbeitsspeicher, man sollte es bei 3-5 Knoten und 5-15 Hosts
belassen, wenn man nicht gerade High-End Gerte 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 fr Netzwerkgerte. Es ist mglich
jedes Netzwerkgert 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 mglich andere Applikation mit integrieren, also
eine sehr mchtige Lsung. Wir sehen aber genau bei diesen Punkten
ein groes Problem, durch das vollstndige Individualisieren der
Netzwerkfunktion mit eigenen Programmcode kann es zu groen
Sicherheitsproblemen kommen, allein schon durch die Tatsache, dass
z.B. ein Admin einfach nicht alle Sicherheitslcken programmatisch
eliminiert, weil es fast unmglich ist an alle Eventualitten zu
denken. Auerdem, wenn die SDN Controller ausfallen, funktioniert
das gesamte Netzwerk nicht mehr, auch wenn ein Hacker den
Controller bernimmt, hat er Vollzugriff auf Alles. Fr
Unterrichtszwecke wrde sich ein OpenDaylight Szenario unserer
Meinung nach sehr gut eignen, vor allem fr IMA Studenten ab dem 4.
Semester. Man bentigt so ziemlich genau all jene Dinge, die man im
Studiengang gelernt hat. Grundlagen Linux: SADML Java Kenntnisse fr
den Controllercode: SWENGA, SWENGB Netzwerkkentnisse/Protokolle:
HVSYS, Netzwerkfcher Ein Problem wre aber die unserer Meinung nach
die sehr instabile Arbeitsumgebung, weil das Produkt noch nicht
ausgereift ist. Die aktuelle Version ist fr ein nicht kommerzielles
Projekt schon recht weit, aber man sollte weiter Entwicklungen
abwarten. Die Technologie ist sehr vielversprechend!
- 28. Wir finden es sehr gut, dass man wirklich jedes
Netzwerkgert selber programmieren kann, sehen jedoch auch die
mglichen Sicherheitsrisiken. Wir sind der Meinung, Firmen sollten
SDN Lsungen mit Vorsicht einsetzen, am besten nur in isolierten
Netzwerkbereichen, vielleicht nur in internen Umgebungen.
- 29. 5 QUELLENVERZEICHNIS 5.1 LITERATUR/ONLINEQUELLEN Hier sind
die Quellen kapitelweise aufgefhrt, die Inhalte wurden teilweise
mit eigenen Wissen ergnzt. Englische Texte wurden sinngem bersetzt.
Kapitel oder Bilder ohne Quellenangaben wurden vollstndig selbst
erfasst oder erstellt. Software Defined Networking: Begriffe und
Erklrung: 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.
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. 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