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

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 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. 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. 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. Am Ende sollte eine Meldung „BUILD SUCCESS“ das erfolgreiche Builden der Controlleranwendung
bestätigen. 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 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. 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. 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. 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. 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. 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. 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. 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. }
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. // 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. 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. 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. 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. 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