Embed Size (px)
Citation preview
Netzwerkfunktionen in einer SDN-Netzwerk-Simulation
mit Mininet
Fachrichtung: Technische Informatik
Bachelorarbeit
vorgelegt von
Michael Jatiani geb. in Offenbach/Main
Matrikel-Nr.: 970855
Technische Hochschule Mittelhessen
Fachbereich Informationstechnik, Elektrotechnik, und Mechatronik (IEM)
Campus Friedberg
Referent Korreferent
Prof. Dr. rer. nat. Dieter Baums Dipl.-Ing. (FH) Markus Desch, M.Sc.
April 2019
“Don’t let the noise of others’ opinions drown out your own inner
voice.” – Steve Jobs
Für meine Familie
i
Danksagungen
An dieser Stelle bedanke ich mich bei allen, die mich im Studium unterstützt haben und
mich ermutigt haben während der gesamten Zeit.
Als erstes möchte ich meinen Eltern danken, dass sie mich während der gesamten Länge
meines Studiums ermutigt haben und mich unterstützt haben, wann immer es ihnen in der
Macht stand.
Besonderen Dank möchte ich Prof. Dr. Burkhard Kampschulte sagen, der mich am An-
fang meines Studiums der Programmierung näherbrachte und meine Leidenschaft darin
weckte. Zudem bedanke ich mich bei Herrn Prof. Dr. Baums, welcher mir während der
Erstellung dieser Arbeit stets hilfsbereit zu Seite stand, für die konstruktiven Fachgesprä-
che.
Außerdem möchte ich Gabriele und Dr. Judith Erren danken für die Bereiterklärung der
Korrekturlesung dieser Arbeit.
ii
Eidesstattliche Erklärung
Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig angefertigt und keine
anderen als die angegebenen Quellen und Hilfsmittel verwendet habe. Wörtlich übernom-
mene Stellen aus Fremdwerken sind als solche gekennzeichnet.
Usingen,
April 2019
Michael Jatiani
iii
Inhaltsverzeichnis
Danksagungen .................................................................................................................... i
Eidesstattliche Erklärung .................................................................................................. ii
Abbildungsverzeichnis ...................................................................................................... v
Tabellenverzeichnis ......................................................................................................... vi
Einleitung .......................................................................................................................... 1
1.1 Hintergrund ........................................................................................................... 1
1.2 Motivation ............................................................................................................. 2
1.3 Zielsetzung ............................................................................................................ 2
1.4 Aufbau dieser Arbeit ............................................................................................. 3
1.5 Zusammenfassung ................................................................................................. 4
Stand der Technik ............................................................................................................. 5
2.1 Einleitung .............................................................................................................. 5
2.2 Neue Netzwerk Architektur .................................................................................. 5
2.3 Herstellerimplementierung .................................................................................... 6
2.4 Verwandte Arbeiten .............................................................................................. 6
Grundlagen ........................................................................................................................ 7
3.1 Einleitung .............................................................................................................. 7
3.2 Software Defined Networking, SDN .................................................................... 7
3.2.1 Kommunikationspfade des SDN ................................................................. 9
3.3 OpenFlow Protokoll ............................................................................................ 12
3.3.1 OpenFlow Switch ...................................................................................... 13
3.3.2 Flows, Flow Tables und Ports ................................................................... 13
3.3.3 Pipelining unter Verwendung mehrerer Flow Tables................................ 16
3.3.4 Kommunikation zwischen Switch und Controller .................................... 16
3.4 Open vSwitch ...................................................................................................... 18
3.4.1 Open vSwitch Architektur ......................................................................... 19
3.4.2 Kernel Modul ............................................................................................. 20
3.5 Ryu Controller..................................................................................................... 21
3.6 Mininet ................................................................................................................ 22
3.7 Docker ................................................................................................................. 23
Lösung ............................................................................................................................ 24
4.1 Einleitung ............................................................................................................ 24
4.2 Topologie ............................................................................................................ 24
iv
4.3 SDN Komponenten ............................................................................................. 29
4.3.1 Ryu Controller ........................................................................................... 30
4.3.2 Distribution Switches, Controller c1 ......................................................... 31
4.3.3 NAT Switch, Controller c0 ........................................................................ 34
Ergebnisse ....................................................................................................................... 41
5.1 Einleitung ............................................................................................................ 41
5.2 802.1Q VLAN ..................................................................................................... 41
5.3 Flow Table .......................................................................................................... 43
5.3.1 Distribution Switches ................................................................................ 43
5.3.2 NAT Switch ............................................................................................... 46
Zusammenfassung und Ausblick .................................................................................... 51
6.1 Zusammenfassung ............................................................................................... 51
6.2 Ausblick .............................................................................................................. 52
Literatur .......................................................................................................................... 53
v
Abbildungsverzeichnis
Abb. 1: Übersicht der zu implementierenden Topologie .................................................. 3
Abb. 2: Schematisches Grundkonzept der SDN Architektur ........................................... 8
Abb. 3: SDN Kommunikation zwischen Data-, und Control Plane ................................. 9
Abb. 4: SDN-Kommunikation des Controllers ............................................................... 10
Abb. 5: Komplettansicht der Kommunikationspfade innerhalb SDN ............................ 11
Abb. 6: Komponentenansicht eines OpenFlow Switches ............................................... 13
Abb. 7: Pipelining-Beispiel ............................................................................................. 16
Abb. 8: Open vSwitch Module ....................................................................................... 19
Abb. 9: Core Tables des ovs-vswitchd Dienstes von Open vSwitch .............................. 20
Abb. 10: Kernel-Modul ................................................................................................... 21
Abb. 11: Netzwerktopologie der Implementierung im SDN .......................................... 25
Abb. 12: Zuordnung der Controller der SDN-Simulationsumgebung, ohne Hosts ........ 28
Abb. 13: Netzaufbau mit zugeordneten VLAN IDs ....................................................... 29
Abb. 14: Vererbungsstruktur der Controllerklassen ....................................................... 30
Abb. 15: Klassenübersicht von c1 nach PyCharm Modell ............................................. 31
Abb. 16: Pipeline Prozess Distribution Switches ........................................................... 32
Abb. 17: Klassenübersicht von c0 nach PyCharm Modell ............................................. 35
Abb. 18: Pipeline Prozess NAT Switch .......................................................................... 36
Abb. 19: Übersicht NAT Prozess ................................................................................... 38
Abb. 20: Wireshark Capture Ping von h1 zu h5 ............................................................. 41
Abb. 21: Wireshark Capture Ping h1 zu h5 über Distribution Switch s1 Interfaces ...... 42
Abb. 22: Wireshark Capture einer Ping und ARP Anfrage zwischen h1 und h5 ........... 42
Abb. 23: Ping-Anfrage auf das externe Interface des NAT Switches ............................ 47
Abb. 24: NAT Netzwerkkommunikation h1 unter Verwendung von http ..................... 48
Abb. 25: Traffic zwischen internem und externem Netzwerk über tldsw0 .................... 49
vi
Tabellenverzeichnis
Tab. 1: Kernkomponenten eines Flow Entry in einer Flow Table .................................. 13
Tab. 2: Flow Table Parameterübersicht eines OpenFlow Switches ............................... 14
Tab. 3: Übersicht der reservierten Port Namen in OpenFlow ........................................ 15
Tab. 4: OpenFlow Nachrichten Frame ........................................................................... 17
Tab. 5: Teilausschnitt der Nachrichtentypen von OpenFlow 1.4 ................................... 18
Tab. 6: Dispatcher-Eigenschaften des @set_ev_cls Decorator ...................................... 22
Tab. 7: Ausschnitt konfigurierbarer OpenFlow Protokoll, OFP, Events ........................ 22
Tab. 8: Übersicht der verwendeten Systemkomponenten .............................................. 24
Tab. 9: Port-Konfiguration der SDN Switches ............................................................... 29
Tab. 10: Ergebnis "pingall" im Netzwerk ....................................................................... 44
1
Kapitel 1
Einleitung
In dieser Arbeit werden Machbarkeit und Möglichkeiten einer Software-defined Network
Umgebung überprüft. Eine Implementierung auf Basis von SDN bilden Ryu als Control-
ler Framework unter der Verwendung von OpenFlow als verwendetes Protokoll zur Be-
schreibung und Modifizierung von Datenpfaden innerhalb des Netzwerkes und Mininet,
welches eine softwarebasierte, virtuelle Simulation einer Netzwerkumgebung ermöglicht.
Mininet nutzt für die Erzeugung von Switches die Software Open vSwitch. Erste Ele-
mente des umgesetzten Systems werden VLAN Tags sein, unter Verwendung des Stan-
dards 802.1Q. Ferner wird der Aufbau einer NAT Fähigkeit angestrebt. Die erstellte NAT
Funktion wird an einem lokalen, privaten Netzwerk evaluiert.
1.1 Hintergrund
Die verwendeten Standards in der Netzwerktechnik bestehen seit Anfang der 1980er
Jahre. In diesen wurden Protokolle wie TCP, Transmission Control Protocol, IP, Internet
Protocol, ICMP, Internet Control Messaging Protocol und eine Spezifikation von Netz-
werken und Portassoziationen festgelegt, grundlegende Technologien des heutigen Inter-
nets und lokaler Netzwerke. Der heutige Standard des Übertragungsmediums, welcher
sich gegenüber anderen Technologien durchgesetzt hat, ist Ethernet, IEEE 802.3. Diese
Technologie ist eine einfache und kostengünstige Variante der Verbindung mehrerer Teil-
nehmer in einem Netzwerk.
Die Verteilung der Pakete beruht auf unterschiedlichen Techniken. Ethernet verwendet
zur Kommunikation zwischen einzelnen Teilnehmern des Netzwerkes eine MAC, Media
Access Control, Adresse. Diese besteht aus 48 Bit und teilt sich auf zwei Teilbereiche
auf. Die ersten 24 Bit werden zu Herstellern assoziiert, welche diesen Adressbereich er-
worben haben. Der restliche Bereich kann frei von den Herstellern vergeben werden. Eine
MAC ist eindeutig einer NIC, Network Interface Card, zugeordnet. Switche nutzen diese
Adresse, um eine Weiterleitung auf Basis einer Zuordnung zwischen MAC-Adresse und
Port zu ermöglichen. Um Pakete in andere Netzwerke zu vermitteln, werden Router be-
nötigt, welche in beiden Netzwerken eine Verbindung besitzen. Mit dieser Technologie
wird die Entscheidung der Paketweiterleitung in einem kleinen, lokalen Bezug getroffen.
Erweiterte Funktionen für Routing und Switching erfordern umfassendere Logik inner-
halb der Geräte. Dies steigert die Fehleranfälligkeit und erschwert die Konfiguration, da
jedes Gerät innerhalb einer Infrastruktur konfiguriert werden muss.
2
1.2 Motivation
Heutige Anforderungen an die Netzwerktechnik und das Internet steigen: Neue Dienste
entstehen, welche hohe Auslastungen erzeugen und Datendurchsatzraten benötigen. Die
Anforderung an Computersysteme steigt zusätzlich mit der Anzahl der Benutzer eines
Dienstes. Ferner benötigen Rechenzentren wie z.B. CDN, Content Delivery Network, An-
bieter oder Cloud-Computing, Möglichkeiten, dynamisch auf bestimmte Ereignisse rea-
gieren zu können. Maßnahmen können die Verteilung der Last während Auslastungsspit-
zen, Redundanz oder Erweiterung der Dienste beinhalten.
Software Defined Networking bietet eine neue Architektur der Netzwerkumgebung. Der
Ansatz von SDN ist, dass die Steuerungsebene und die Datenebene zu trennen sind. Der-
zeit sind diese beiden Ebenen in einem Gerät vereint. Somit stellt jedes Gerät beide Funk-
tionen bereit. Durch die Programmierbarkeit eines SDN-Controllers kann das Verhalten
des Netzwerkes beeinflusst werden. Somit können Mechanismen wie Load Balancing
und ein dynamisches Verhalten auf Ereignisse erreicht werden. Pakete werden mithilfe
von Kriterien auf eine Übereinstimmung, Match, hin geprüft. Wenn eine Übereinstim-
mung erreicht wird, können innerhalb des Paketes zugehörige Headerparameter verändert
werden. Diese Funktionalität entspricht somit einem Switch und einem Router zugleich.
In der SDN-Architektur wird die Grenze zwischen diesen beiden Typen an Geräten ver-
wässert.
1.3 Zielsetzung
Die Umsetzung einer simulierten Umgebung und die Topologie einer typischen Netz-
werkkonstellation werden als Ziel dieser wissenschaftlichen Arbeit gesehen. Die Topo-
logie ist in Abb. 1 dargestellt. Einzelne Hosts des Netzwerkes werden über Verteilungss-
witches, Distribution Switches, an das Netzwerk angeschlossen. Die Anbindung erfolgt
über Access Ports. Eine Einteilung in logische Virtuelle Netze, VLANs, wird innerhalb
des programmierbaren SDN-Controllers umgesetzt. Die einzelnen Distribution Switches
werden an den Top Level Switch verbunden. Dieser verteilt Pakete zwischen den einzel-
nen Switches, auf Basis der vorhandenen VLANs an den einzelnen Distribution Swichtes.
Zudem stellt der Switch eine Übersetzung von Netzadressen bereit, NAT. Diese wird für
die Kommunikation zwischen den Hosts, welche im internen Netzwerk angebunden sind,
und Geräten im externen Netzwerk benötigt. Diese Unterteilung charakterisiert sich durch
die IP Adresse und die verwendete Subnetzmaske.
Die logische Topologie, wie in Abb. 1 zu sehen, kann die Anbindung einzelner Etagen
charakterisieren. Die Umsetzung und Erarbeitung einer Lösung im SDN-Konzept wird
mit Ryu als Controller angestrebt. Eine Netzwerksimulation dieser Topologie wird mit-
hilfe von Mininet erreicht.
3
Abb. 1: Übersicht der zu implementierenden Topologie; Distribution Switches ermöglichen die Anbindung der einzel-
nen Hosts an ein Netzwerk. Diese Ports werden Access Ports genannt. Verbindungen zwischen den Distribution Swit-
ches und dem Top Level Switch werden als Trunk Ports bezeichnet.
1.4 Aufbau dieser Arbeit
Diese Arbeit ist in logische Abschnitte unterteilt. Zunächst wird der Stand der Technik
aufgezeigt. In diesem Kapitel wird auf aktuelle Implementierungen von SDN-Umgebun-
gen und Systemaspekten eingegangen. Diese beziehen sich auf große Netzwerktechnik-
Hersteller wie Cisco, Juniper und Broadcom. Zudem wird auf verwandte Arbeiten mit
einer SDN-Thematik als neue Architektur eingegangen.
Im darauffolgenden Kapitel werden Grundlagen der SDN-Umgebung und der Aufbau des
Systems erläutert. Diese Grundlagen werden für das Verständnis und die Umsetzung der
Lösung benötigt.
Das Kapitel Lösung geht auf die Implementierung und die Methodik der Lösungsfindung
ein. Zudem werden die Topologie, verwendete Hardware und Softwarekomponenten des
SDN aufgezeigt.
Im Kapitel „Ergebnisse“ wird mithilfe von Netzwerk-Traffic auf die implementierten Re-
geln und Flows der einzelnen Geräte eingegangen. Dazu werden anhand mitgeschnittener
Paketflüsse auf Netzwerkebene die angewendeten Flows erläutert. Ferner wird auf die
angewendeten Pipeline Prozesse eingegangen.
Das letzte Kapitel stellt eine Zusammenfassung dieser Arbeit und einen Ausblick für wei-
tere Arbeiten im SDN-Bereich dar.
4
1.5 Zusammenfassung
Die Arbeit befasst sich mit dem neuen Netzwerkparadigma SDN. In dieser Architektur
werden klassische netzwerktypische Eigenschaften umgesetzt, wie die Unterteilung eines
Netzwerkes in unterschiedliche logische virtuelle Netzwerke, VLANs. Zudem wird die
Implementierung einer Routingfähigkeit, der Network Address Translation, und die Eru-
ierung der Machbarkeit analysiert.
Es wird für die Implementierung eine in der Wirtschaft typische Topologie verwendet.
Die Umsetzung findet in einer virtuellen Umgebung statt, welche rein auf Software ba-
siert. Für die Überprüfung der Umsetzung wird auf anwendungstypische Protokolle und
Abläufe gesetzt.
5
Kapitel 2
Stand der Technik
2.1 Einleitung
Dieses Kapitel beschäftigt sich mit der neuen Architektur Software Defined Networking.
Zunächst wird ein kleiner Überblick erstellt. Zudem werden Lösungen von großen Hard-
ware Herstellern von Netzwerktechnik aufgezeigt. Im Weiteren wird auf Arbeiten einge-
gangen, welche sich mit dem SDN Thema beschäftigen.
2.2 Neue Netzwerk Architektur
In den Anfängen der Computertechnologie repräsentierte eine Maschine einen Computer.
Die Software, welche ausgeführt wurde, lief in diesem Kontext direkt auf der Hardware.
Diese Konstellation wurde zunächst im Serverbereich erweitert und die Technik der Vir-
tualisierung eingeführt. Damit entstand die Möglichkeit, mehrere Betriebssysteme auf ei-
nem Server in einer virtualisierten Umgebung auszuführen. Eine solche Umgebung ver-
setzte Server in die Lage, Dienste auf unterschiedlichen Betriebssystemen zur gleichen
Zeit ausführen.
Dieser Trend wurde weiterentwickelt und bezieht sich zudem auf Clients. Dadurch kön-
nen Clients als Terminals ausgeführt werden, Berechnung von Operationen, Verarbeitung
der Eingaben eines Benutzers und die Ausführung der Programme werden auf Server
ausgelagert. Dies wird mithilfe der Virtualisierung ermöglicht.
Software Defined Networking stellt kein neues Netz oder Protokoll dar. Es beschreibt
eine neue Architektur des bisherigen Netzes. SDN verwendet die Basis der bereits imple-
mentierten Protokolle und versucht ein formbares Netz zu erstellen. Das wird durch kon-
tinuierliches Überwachen der Netzwerklast erreicht. Diese Art der Informationen über
die Auslastung ermöglicht ein dynamisches Eingreifen in das Netzwerk, welches die Ver-
änderung von Verkehrsprofilen zur Folge hat. Zudem können unterschiedliche Netzwerk-
architekturen und Anwendungen im SDN-Zusammenhang erstellt werden. Diese Mög-
lichkeit, kurzfristig und agil auf Ereignisse einzugehen, erschließt die flexible Nutzung
von Ressourcen und eine Sicherstellung der ordnungsgemäßen Funktion des Netzwerkes.
Im Umkehrschluss entstehen Netzwerke, welche gehärtet werden und eine hohe Leis-
tungsfähigkeit erzielen. Zusätzlich kann eine Bereitstellung von virtuellen Netzelementen
in privaten Netzen für die Backbone-Verbindung verschiedener Standorte genutzt und
angepasst werden. Das resultiert in einem Ansatz der IaaS, Infrastructure-as-a-Service.
Dieser Aspekt ist insbesondere für Anbieter von Cloud-Computing und Storage Services
von Bedeutung.
Diese Eigenschaften von SDN resultieren in einem Paradigmenwechsel in der bisherigen
6
Netzwerktechnik. Netzwerkausrüster wie Cisco, Brocade, Broadcom oder Juniper wer-
den bei diesem Ansatz der programmierbaren dynamischen Netzwerkumgebung zur Um-
strukturierung bewegt [1, Kap. Vorwort, 2, S. VII].
2.3 Herstellerimplementierung
Namhafte Hersteller, welche im vorherigen Unterkapitel genannt wurden, entwickeln
eine Art der SDN-Umgebung.
Cisco verfolgt den Ansatz des hybriden SDN. Eigenschaft dieses ist, dass Teilaspekte
eines Netzwerkes in einer SDN-Architektur umgesetzt werden, wie z.B. im Bereich der
WAN, Wide Area Networks oder der Bereitstellung von einer Konnektivität in Netz-
werke, Access. Cisco bietet zudem eine eigene, angepasste, kommerzielle Version des
SDN-Controllers OpenDaylight an mit der Bezeichnung Cisco Open SDN Controller [3,
4].
Juniper verfolgt einen ähnlichen Ansatz für SDN wie Cisco. Die Umsetzung von Teilas-
pekten der Netzwerktechnik wird verfolgt. Juniper entwickelt zudem einen proprietären
SDN Controller, NorthStar Controller. Zur Konfiguration der Geräte kann OpenFlow
zum Einsatz kommen [5, 6].
Brocade, welches ein Unternehmen von Broadcom ist, konzipiert SDN in Datenzentren
als Netzwerkkontrollelement und Optimierung. Das Unternehmen arbeitet mit offenen
Standards und den Institutionen zusammen [7, 8].
2.4 Verwandte Arbeiten
In der Masterarbeit „Implementing SDN in ISP Networks” von Ashwin Ashok Thakare,
April 2018, wird das Thema einer Implementierung des MPLS, Multiprotocol Label Swit-
ching Protokoll, in einer SDN Umgebung behandelt. Diese Arbeit geht auf die Erstellung
und Implementierung eines erweiterten SDN basierten Controllers unter der Verwendung
von Ryu als Controller Framework ein. Diese Untersuchung beschäftigt sich, wie im vor-
herigen Unterkapitel aufgezeigt, mit einer Teilimplementierung von SDN in einem hyb-
riden Netz-Ansatz. Dabei werden Teilaspekte der Netzwerkinfrastruktur in die SDN-Um-
gebung adaptiert.
7
Kapitel 3
Grundlagen
3.1 Einleitung
Für das Verständnis der nachfolgenden Kapitel wird Grundwissen vorausgesetzt. Inner-
halb dieses Kapitels sollen dem Leser Grundlagen vermittelt werden, welche das Ver-
ständnis und die SDN-Architektur näherbringen. Es wird auf Aspekte des OpenFlow Pro-
tokolls eingegangen, eine Erläuterung der Open vSwitch Umgebung und Aspekte der
Virtualisierungssoftware Mininet durchgeführt. Für die Programmierung und Verarbei-
tung der Anfragen der OpenFlow Geräte wird das Ryu Framework genutzt. Dieses basiert
auf Python und wird für die Beschreibung der SDN-Controller verwendet.
3.2 Software Defined Networking, SDN
Die klassische Netzwerktechnik, welche heutzutage im Einsatz ist, gründet auf den An-
fängen der Technik. Neueren Anforderungen an Daten-Netzwerke können diese Systeme
nicht mehr gerecht werden. Mit zunehmender Größe von Firmen-Netzen steigt die Kom-
plexität einer Konfiguration und Wartbarkeit solcher Systeme an. Zusätzlich ist die In-
teroperabilität zwischen verschiedenen Hardware-Herstellern nicht gegeben. Innerhalb
der ASICs, Application Specific Integrated Circuits, der Hersteller werden proprietäre
Protokolle, z.B. EIGRP, Enhanced Interior Routing Protocol, von Cisco genutzt. Solche
Protokolle werden herstellerspezifisch exklusiv nur auf Geräten des eigenen Produktport-
folios implementiert. Dies schließt eine Verwendung von Hardware unterschiedlicher
Hersteller aus, ohne Berücksichtigung von offenen Standards wie OSPF, Open Shortest
Path First [9]. Dieses Protokoll gehört zu der Gruppe der Link-State basierenden Rou-
tingprotokollen.
Software Defined Networking stellt einen Paradigmenwechsel in der Netzwerktechnik
dar. Es bildet eine neue Architektur. Diese ermöglicht eine Erstellung von leistungsfähi-
ger und steuerbaren Netzen. Eine Steuerbarkeit wird erreicht, indem einzelne Geräte in-
nerhalb der Infrastruktur Statusnachrichten an den Controller senden. Mithilfe dieser In-
formationen kann eine komplexe und erweiterte Übersicht des Netzwerkes generiert wer-
den. Eine solche Übersicht wird genutzt, um zum einen eine Qualitätssicherung der Netz-
werke zu erreichen, zum anderen kann eine Infrastruktur dynamisch auf Ereignisse rea-
gieren. Innerhalb eines Datacenters oder eines CDN kann auf Engpässe reagiert werden
und z.B. eine optimierte Lastverteilung auf einzelne Geräte erzielt werden. Services sind
nicht an eine feste IP innerhalb des Netzes gebunden, sondern können zur Vermeidung
sog. Hotspots verteilt werden und parallel auf mehreren Servern offeriert werden. Ferner
wird Paketverlust vermieden und eine Ende-zu-Ende-Qualität sichergestellt. SDN
8
verknüpft einen optimierten Transport mit hoher Verfügbarkeit des Netzes. Diese Eigen-
schaften werden durch die gleichzeitige Bearbeitung der Pakete auf allen Schichten des
TCP/IP Modells erwirkt. Diese Verarbeitung wird ohne ein neu eingeführtes Protokoll
auf Netzebene erreicht [2, S. 1-2]. Durch die Verwendung dieses Protokolls, werden für
die Verarbeitung keine zusätzlichen Ressourcen wie Prozessorzeit oder Hauptspeicher
benötigt.
Ein SDN Switch ist, gegenüber einem klassischen Switch, kein reiner Layer 2 Switch.
Eine klare Trennung zwischen Router und Switch wird in der SDN-Architektur nicht auf-
rechterhalten, da ein SDN Switch die Möglichkeit bereitstellt, Pakete auf unterschiedli-
chen Ebenen zu manipulieren und zu verändern. Zum Beispiel kann ein Switch in einer
SDN-Umgebung gleichzeitig eine Veränderung der IP Adresse, MAC Adresse und an-
wendungsbezogene Daten durchführen.
Abb. 2: Schematisches Grundkonzept der SDN Architektur; Das Grundkonzept von SDN sieht vor, die Weiterleitung
der Daten und deren Entscheidung über eine zutreffende Weiterleitungsregel, z.B. Routing, in strikt unterschiedliche
Ebenen zu unterteilen. Mithilfe dieser Maßnahme, ermöglicht SDN eine hohe Abstraktion und eine Programmierbarkeit
der Netzwerkkomponenten, welche in einer klassischen Umgebung wenig bis nicht möglich ist. Die Steuerungsebene,
Control Plane, wird programmtechnisch beschrieben. Somit kann das Verhalten der jeweiligen Ebene verändert wer-
den. Die Kommunikation zwischen Datenebene und Steuerungsebene erfolgt mithilfe eines bestimmten Protokolls.
Die klassische Architektur implementiert die Steuerungsebene, Control Plane, und Da-
tenebene, Data Plane, kombiniert in einem ASIC. Dadurch steigt innerhalb der einzelnen
vermittelnden Komponenten des Netzwerkes ein erhöhter Aufwand in Hardware. Ein
Router überprüft anhand der Zielparameter, wie z. B. der Ziel-IP Adresse, ankommender
Pakete eine zu verwendende Routingregel. Regeln sind in einer Routingtabelle hinterlegt.
Entgegen diesem Ansatz ist eine strikte Trennung der Ebenen ein integraler Teil der SDN
Architektur, siehe Abb. 2. Die Control Plane entscheidet, welcher Pfad geeignet ist für
die Datenpakete. Dazu können mehrere Eigenschaften unterschiedlicher Layer des Pa-
ketes als Kriterium herangezogen werden. Erhaltene Status-Informationen werden für die
Eruierung herangezogen und ausgewertet. Die Data Plane leitet auf Grundlage der Vor-
gaben der Control Plane die Daten an das gewünschte Ziel [2, S. 3].
9
Für diesen Austausch von Informationen und Regeln zwischen der Data- und der Control
Plane wird das Protokoll OpenFlow eingesetzt. In Abschnitt 3.3 wird auf OpenFlow im
Detail eingegangen. Die zugrunde liegende Architektur des Protokolls ist ein Client Ser-
ver-Verhältnis, welches TCP als Transportprotokoll nutzt. Es kann unverschlüsselt oder
mithilfe von TLS, Transport Layer Security, verschlüsselt werden [10, S. 38].
Der Austausch in Richtung einer Applikation wird mithilfe einer bereitgestellten Schnitt-
stelle des jeweiligen Controller Frameworks ermöglicht.
3.2.1 Kommunikationspfade des SDN
Innerhalb der SDN-Architektur existieren unterschiedliche Kommunikationspfade. Als
Grundlage der Benennung der unterschiedlichen Pfade werden Himmelsrichtungen ge-
nutzt. Diese beziehen sich auf die Architekturstruktur von SDN. Die grundlegendste
Kommunikation für die Netzwerkfunktion erfolgt zwischen den Geräten und dem Con-
troller. In Abb. 3 wird diese illustriert. Ein Austausch von Instruktionen und Status-Para-
metern der Switches erfolgt durch die Verwendung des OpenFlow Protokolls.
Abb. 3: SDN Kommunikation zwischen Data-, und Control Plane in Anlehnung an Abb. 7 [2, S. 7]; Die SDN Switches,
welche innerhalb der Datenebene operieren, bilden die zugrundeliegende Netzstruktur. Die Interaktion zwischen die-
sen Geräten und dem Controller ist standardisiert und erfolgt über das OpenFlow-Protokoll. Durch die Spezifikation,
welche als Open Source gehalten ist, kann eine Hersteller unabhängige Implementierung von Geräten erfolgen. Die
Kommunikation ist essentiell, da sie das Verhalten der Geräte mithilfe von Flows beschreibt. Ein Flow enthält eine
Bedingungs-, Match, und eine Handlungskomponente, Action.
Dieser Austausch von Statusnachrichten und eine Kommunikation zwischen SDN-Con-
troller und im Netzwerk befindlichen Geräten findet über das sog. South Bound Interface
statt. Die Kommunikation bezieht sich dabei ausschließlich auf die Switches und nicht
auf die Hosts innerhalb des Netzwerkes. Das South Bound Interface dient dazu, Vorgaben
10
des Controllers an Switche zu übermitteln und in Flow Tables zu speichern [11, S. 245].
Ein Paket, welchem kein Flow zugeordnet werden kann und welches somit keine Über-
einstimmung findet, kann an einen zugeordneten Controller geschickt werden. Dieser Zu-
sammenhang wird als Table Miss bezeichnet. Das spezifische Verhalten bei einem Table
Miss ist in der jeweiligen Flow Table abgelegt und in Abhängigkeit der Konfiguration
gestaltet. Somit ist eine pauschale Aussage, dass Pakete, welche nicht zugeordnet werden
können, an den Controller gesendet werden, nicht möglich. Ein Paket kann in diesem Fall
verworfen, weitergeleitet oder an die nächste Flow Table weitergeleitet werden. Zudem
kann das Paket auch innerhalb komplexer Topologie an andere Controller geschickt wer-
den, um eine Bearbeitung zu ermöglichen [10, S. 20].
Gegenüber der Interaktion der Geräte über das South Bound Interface wird mithilfe des
North Bound Interfaces eine Schnittstelle zu SDN Applikationen ermöglicht.
Abb. 4: SDN-Kommunikation des Controllers in Anlehnung an Abb. 215 [11, S. 246]; Die Kommunikation zwischen
SDN-Applikationen erfolgt über das North Bound Interface. In Zusammenhang mit Abb. 2 existiert eine API für die
Interaktion mit einem SDN-Controller und einer Applikation auf dem North Bound Interface. Diese variiert je nach
verwendetem Controller.
11
Die Applikationen, welche über das North Bound Interface, siehe Abb. 4, betrieben wer-
den, greifen direkt auf den SDN Controller zu. Ein direktes Zugreifen auf Netzwerkkno-
ten ist durch die Abstraktion für diese Applikationen nicht möglich. Der Zugriff erfolgt
auf ein abstraktes Modell des gesamten Netzwerkes und der darunter liegenden Funktio-
nen. Applikationen wird somit ein tiefes Eingreifen auf das komplette Netzwerkverhalten
gewährt. Das Spektrum umfasst die Netzkapselung, Lastverteilung, Verfügbarkeit und
andere Aspekte. Mit Reports des Controllers zu SDN-Applikationen kann auf unter-
schiedliche Ereignisse reagiert werden [11, S. 211].
Eine komplette Ansicht der Kommunikationspfade der SDN-Architektur wird in Abb. 5
illustriert. Ein Austausch von Daten auf der gleichen Schicht wird als East/West-Kommu-
nikation bezeichnet. Mit der Kopplung von SDN-Controllern auf der Control Plane ist es
möglich, unterschiedliche Domänen mehrerer Betreiber zu koppeln. Große Netzwerke
können zudem unterteilt werden und über die East/West-Schnittstelle gekoppelt werden
[11, S. 209-210]. Innerhalb einer Domäne können mehrere Controller eingesetzt werden.
Abb. 5: Komplettansicht der Kommunikationspfade innerhalb SDN in Anlehnung an Abb. 183 [11, S. 208]; Die Kom-
munikation auf einer selben Ebene wird als East/West-Kommunikation bezeichnet. Eine Verbindung mehrerer
SDN-Controller auf der Control Plane ermöglicht die Kopplung von SDN-Domänen. Somit lassen sich Netze unter-
schiedlicher Anbieter koppeln. Zusätzlich können redundante Controller innerhalb einer Domäne genutzt werden.
Durch eine Verwendung mehrerer Controller in einer Domäne können unterschiedliche
Probleme gelöst werden. Bei einem Ausfall eines Controllers könnten keine Entscheidun-
gen mehr bezüglich der Netzwerkregeln getroffen werden. Dadurch werden keine neuen
Flows mehr an einzelne Netzwerkkomponenten übermittelt. Als einfacherer Ansatz kann
die Funktionalität des Controllers in einem redundanten Controller dupliziert werden. In
Bezug auf die Performance des Netzwerkes, kann es bei einem erhöhten Aufkommen von
Anfragen an einen Controller dazu kommen, dass die Bearbeitung dieser zu
12
Verzögerungen führt. Dies kann mithilfe von Lastverteilung auf mehrere Controller ge-
löst werden. Die Koordination unter den Controllern erfordert jedoch ein erhöhtes Maß
an Aufwand. Ein System kann durch die Verwendung mehrerer Controller zudem gehär-
tet werden. Im Fall, dass ein Versuch gestartet wird, einen Controller zu stören oder außer
Betrieb zu setzen, kann ein anderer Controller die Funktion übernehmen. Zusätzlich kön-
nen Sicherheitsmechanismen implementiert werden, welche ein Aufkommen solch eines
Falles vermindern können. Der Zugriff auf einen Controller wird auf den Zugriff inner-
halb des internen Netzes reglementiert. Dies kann mit einfachen Maßnahmen erzielt wer-
den [11, S. 209].
3.3 OpenFlow Protokoll
OpenFlow stellt einen Standard für die Kommunikation der Netzwerk-Geräte mit dem
Controller innerhalb eines SDN-Netzwerkes dar. Der Standard wird von der OFN [12],
Open Networking Foundation, entwickelt und gewartet. Als Open Source Projekt verfolgt
OpenFlow einen offenen Standard. Somit wird eine unabhängige Lösung erstellt. Dies
erlaubt die Interoperabilität zwischen Herstellern, welche OpenFlow unterstützen, gegen-
über einer proprietären Lösung. Durch OpenFlow wird eine Steuerbarkeit der Datenebene
mithilfe eines Controllers ermöglicht. Die Trennung der Datenebene von der Steuerungs-
ebene wird damit erzielt. Diesen architekturellen Ansatz verfolgt SDN. In diesem Zusam-
menhang werden die Art und das Format der übertragenen Daten genormt. Die Identifi-
kation der genutzten OpenFlow Version während der Initialisierung gegenüber einem
Controller wird mit einem hexadezimalen Wert durchgeführt [13, S. 26].
Die Übertragung von Flows, welche eine Verarbeitung und Lenkung der Pakete be-
schreibt, an Switche des SDN-Netzes erfolgt mit OpenFlow. Die Kommunikation zwi-
schen Controller und Switches findet bidirektional statt. Unter der Verwendung von TCP
als Transportprotokoll auf der Netzwerkebene wird OpenFlow als Server/Client-Proto-
koll ausgeführt. Übertragungen können verschlüsselt als auch unverschlüsselt erfolgen.
Für die Verschlüsselung wird TLS genutzt. Durch eine Verwendung von TCP, im Ge-
gensatz zu UDP, können Mechanismen des Protokolls verwendet werden, welche eine
Sicherstellung einer korrekten Übertragung von Daten gewährleistet. Erkannte Fehler
können gegebenenfalls korrigiert werden. Mithilfe der Sicherungseigenschaften können
fehlerhafte Übertragungen, wiederholte Blöcke oder verlorene Daten wieder angefordert
werden [11, S. 245-246].
13
3.3.1 OpenFlow Switch
Abb. 6: Komponentenansicht eines OpenFlow Switches nach Abb. 2.1 [13, S. 28] und Abb. 182 [11, S. 205]; Struktu-
reller Aufbau eines OpenFlow Switches nach OFN-Spezifikation [10, S. 11]. Der Austausch mit einem oder mehreren
SDN-Controllern erfolgt über den OpenFlow Channel. Über diese Verbindung werden Flows übertragen. Ein Feed-
back erfolgt zudem über diese Verbindung. Ein OpenFlow Switch implementiert eine oder mehrere Flow Tables. Durch
die Nutzung von mehreren Flow Tables wird es ermöglicht, Pipelining innerhalb einer Verarbeitungskette zu verwen-
den. Group Tables beinhalten eine Anzahl von Actions, welche in Action Buckets zusammengefasst sind. Ein normaler
Flow kann auf diese Action Buckets zeigen und somit eine erweiterte Verarbeitungsvariante ermöglichen. Die Meter
Table hingegen, beinhaltet Parameter für QoS und Bandbreitenlimitierung. Metadaten für jede Flow Table werden in
der Meter Table gesichert. Eine Netzwerkinteraktion erfolgt über die Ports.
Der Aufbau eines OpenFlow Switch wird durch mehrere Komponenten gekennzeichnet.
Abb. 6 zeigt eine solche Übersicht dieser. Ein Kommunikationspfad zwischen OpenFlow
Switch und einem SDN-Controller erfolgt über die OpenFlow Channel-Schnittstelle.
Diese empfängt neue Flow-Einträge und Veränderungen an einem oder mehreren Flows.
3.3.2 Flows, Flow Tables und Ports
Ein Flow wird durch sieben Parameter beschrieben. In Tab. 1 werden diese Parameter
aufgezeigt. Diese Felder ermöglichen das Parametrisieren und Beschreiben von Flows.
Match Fields Priority Counters Instructions Timeouts Cookie Flags
Tab. 1: Kernkomponenten eines Flow Entry in einer Flow Table [10, S. 22]; Jeder Flow Entry besteht aus diesen
Komponenten. Der Switch überprüft eintreffende Pakete auf eine Übereinstimmung anhand der Match Fields. Das
Prioritätenfeld bestimmt die zu verwendende Regel, falls ein Paket auf mehrere allgemeine Regeln eine Übereinstim-
mung findet. Der Flow mit der höheren Wertung wird genutzt. Metadaten werden im Feld des Counters gespeichert.
Instruktionen halten dabei die anzuwendenden Veränderungen von Parametern in Paketen bereit. Ein Timeout be-
schreibt einen Zeitpunkt, wann ein Flow gelöscht wird. Cookies unterstützen eine Verwaltung der Flow Entries für den
Controller. Durch Flags kann das Verhalten verändert werden, wie ein Flow verwaltet wird. Ferner kann spezifiziert
werden, was im Fall des Verwerfens eines Flows durchgeführt werden soll.
14
Die nachfolgenden Felder [10, S. 22] werden von einem OpenFlow Switch in Flow
Tables gespeichert. Die Werte haben folgende Bedeutung:
Bezeichnung Eigenschaften
Match Field Dieses Feld beschreibt die Übereinstimmungskriterien für ein Pa-
ket, welches einen Switch erreicht. Die Felder, welche genutzt wer-
den können, erstrecken sich über alle sieben OSI-Schichten.
Ein Paket z.B. kann überprüft werden auf die genutzte Protokollart,
z.B. Ethernet, eine MAC Adresse, eine spezifische IP-Adresse oder
auf ein bestimmtes VLAN.
Priority Die Gewichtung des Flow Entry legt die Rangfolge von Flows fest.
Der erste Flow, welcher die Kriterien erfüllt, wird gewählt. Mithilfe
der Priorität kann die Rangfolge in einer Flow Table verändert wer-
den.
Counters Metadaten wie z.B. die Anzahl der verarbeiteten Pakete und Bytes,
Idle-Time etc.
Instructions Veränderungen der Parameter, welche auf das zutreffende Paket bei
einer Übereinstimmung ausgeführt werden. Sie beinhaltet den Aus-
gangsport, Header Felder und andere Parameter. Eine Weiterleitung
in eine andere Flow Table ermöglicht das Nutzen der Mechanismen
des Pipelinings.
Timeouts Timeouts beschreiben ein Verfallen eines Flows im zeitlichen Zu-
sammenhang. Es existieren zwei Typen von Timeouts:
▪ Idle-Timeout
Ein Idle-Timeout tritt auf, wenn ein Flow in einer be-
stimmten Zeit nicht genutzt wird. Sobald ein Match
auftritt, wird der Timer auf den Wert null zurückge-
setzt.
▪ Hard-Timeout
Ein Hard-Timeout tritt ungeachtet der Idle Zeit ein.
Somit wird ein Flow nach einer bestimmten Zeit für
verfallen erklärt.
Cookie Ein Cookie stellt einen Wert, welcher bei der Bearbeitung von Pa-
keten nicht genutzt wird. Es wird für die Verwaltung der einzelnen
Flows vom Controller verwendet, wenn dies vorgesehen ist.
Flags Veränderung der Art, wie ein Flow verwaltet wird. Das Flag
OFPFF_SEND_FLOW_REM veranlasst einen Switch, das Verwerfen ei-
nes Flows mit diesem Flag an den Controller zu melden.
Tab. 2: Flow Table Parameterübersicht eines OpenFlow Switches;
Mithilfe dieser Felder können einem Flow spezifische Verhaltensweisen zugeordnet wer-
den. Somit lassen sich Pakete modifizieren und weiterleiten. Zudem kann eine Vielzahl
von Header-Feldern eines Paketes modifiziert werden. Es besteht keine Beschränkung
15
auf eine Schicht nach dem OSI-Modell. Die anwendbaren Flow Parameter können zwi-
schen unterschiedlichen Herstellern variieren. Dies ist durch die Implementierung her-
stellerseits bedingt.
Eine Bedingung für Flows ist, dass zwingend ein Ausgangsport, Egressport, angegeben
wird. Dies spezifiziert das OpenFlow-Protokoll [10, S. 80]. Neben reservierten Bezeich-
nungen für Ports werden diese in weitere Kategorien unterteilt. Physische Ports werden
zu einem bestehenden Hardware Interface zugeordnet. Logische Ports bieten einen höhe-
ren Abstraktionsgrad. Diese können für Prozesse wie das Zusammenlegen mehrerer Ver-
bindungen, Link-Aggregation, zu einer logischen Verbindung genutzt werden. Diese
Operation ist nicht direkt mit OpenFlow verbunden und erfolgt auf der Hardware eines
Switches. Somit können Ausgangsports in einem Flow gesetzt und verwendet werden.
Eine Übersicht der von OpenFlow spezifizierten und reservierten Portnamen wird in Tab.
3 erstellt.
Bezeichnung Eigenschaften
Physical Assoziation eines Ports zu einem Hardware Interface.
Logical Höherer Abstraktionsgrad eines Ports.
Verwendung für das nicht OpenFlow System.
Anwendung: z.B. Link-Aggregation
ALL Alle verfügbaren Ports werden für eine Aktion verwendet.
CONTROLLER Port, der Verbindung zum SDN Controller repräsentiert.
TABLE Wird für ein Pipelining Mechanismus verwendet. Goto Table
Anweisung
IN_PORT Ingress Port, an dem das Paket empfangen wurde
UNSET Verwendung bei Gruppeneinträgen um ein Paket zu kennzeich-
nen, welches noch keinem Ausgangsport zugeteilt worden ist.
ANY Repräsentiert eine Wildcard, für welche ein Match auf beliebige
Ports filtert.
NORMAL Setzt eine L2* bzw. L3* Pipeline voraus.
Standardisierte OpenFlow Switches besitzen solch eine Pipeline
nicht.
FLOOD Verwendung aller Ports wie ALL, jedoch unter Berücksichti-
gung der VLAN-IDs.
(Implementationsabhängiges Verhalten)
Tab. 3: Übersicht der reservierten Port Namen in OpenFlow [13, S. 29], [10, S. 15-17]; Ports können innerhalb der
Programmierung mithilfe eines SDN-Controllers, zudem mit Zahlen assoziiert werden. Die Übersicht stellt die Bezie-
hung zwischen der Bezeichnung eines Ports und dessen Eigenschaften her. Die Basis hierzu bietet die OpenFlow-Spe-
zifikation [10, S. 16-17].
* MAC zu Port Assoziation, wie es in klassischen Switchen zu finden sind.
16
3.3.3 Pipelining unter Verwendung mehrerer Flow Tables
Das Pipelining ermöglicht die Aufteilung und logische Trennung einzelner Flows. Es
können Flow Tables, logisch gesehen, Aufgaben zugeordnet werden, welche sich auf die
Bearbeitung eines Teilaspektes der Weiterleitung richten.
Abb. 7: Pipelining-Beispiel, vereinfachte Darstellung; Dieses Beispiel demonstriert die Möglichkeiten, welche reali-
sierbar sind unter Verwendung des Pipeline Mechanismus. Mit Eintreten des Paketes in die Verarbeitungskette werden
unterschiedliche Parameter überprüft und gegebenenfalls verändert.
Durch den Gebrauch von mehreren Flow Tables kann wie in Abb. 7 zu sehen, eine Pipe-
line durch eine logische Trennung bzw. Unterteilung der anzuwendenden Flows erstellt
werden. Das Beispiel in der Abbildung zeigt eine solche. Zunächst trifft ein Paket, wel-
ches bearbeitet wird, an einem OpenFlow Switch ein. Dieses Paket tritt im Ingress Port
in die Pipeline ein. In der ersten Table wird überprüft, ob dieser Traffic verarbeitet wird
oder nicht. Dies kann in Analogie zu bestehenden ACLs, Access Control Lists, gesehen
werden. Als nächsten Schritt in der Verarbeitung könnte eine Network Address Transla-
tion, NAT, erfolgen. Als dritter Schritt wird Traffic, welcher einem Flow zugeordnet wird,
mit einem VLAN-Tag (Virtual Local Area Network) versehen. Als finaler Schritt wird
das verarbeitete Paket über einen Egress-Port auf das Netzwerkmedium übertragen und
übermittelt.
Dieses Beispiel zeigt Möglichkeiten auf, welche mit der Unterstützung einer Flow Table
Pipeline realisierbar sind.
3.3.4 Kommunikation zwischen Switch und Controller
Der Aufbau einer OpenFlow-Verbindung zwischen Switch und einem Controller ist es-
sentiell für das Erhalten von Flows. Eine Initialisierung der TCP-Verbindung erfolgt mit-
hilfe des Drei-Wege-Handschlag, auch Three-Way-Handshake. Wenn eine Verbindung
erfolgreich aufgebaut ist, tauschen Controller und Switch wechselseitig Hello-Nachrich-
ten aus. Diese Art von Nachricht ist eine OpenFlow-spezifizierte Nachricht.
OpenFlow-Nachrichten werden, wie in Tab. 4 gezeigt, aufgebaut. Im Feld der Version
wird die verwendetet OpenFlow-Version vermerkt. Durch die Veränderungen innerhalb
des Protokolls im Laufe der Entwicklung und der Erweiterung der angebotenen
17
Funktionalität sind Inkompatibilitäten entstanden. Aufgrund dieser Gegebenheit und Pro-
grammierbarkeit eines Controllers ist es möglich, zeitgleich mehr als eine Version von
OpenFlow zu unterstützen. Der Typ der Nachricht wird mit einem Zahlenwert festgelegt.
Zudem wird die Länge der Nachricht angegeben. Die Transaction ID ist ein eindeutiger
Wert, welcher für den Austausch der Nachrichten verwendet wird. Dadurch kann eine
Anfrage mit der Antwort assoziiert werden. Im Payload der Nachricht stehen die Nutzda-
ten der Nachricht. Diese Daten beschreiben Parameter eines Flows.
0 7 8 15 16 31
Version Type Message Length
Transaction ID
Payload
Tab. 4: OpenFlow Nachrichten Frame [11, S. 250];
In Tab. 5 ist ein Teilausschnitt der Nachrichtentypen in OpenFlow aufgelistet. Die Kate-
gorie, welche eine Richtung der Nachricht beschreibt, unterteilt sich in folgende Eigen-
schaften [10, S. 38-40] der Initiierung einer Übertragung:
▪ Symmetrisch
Diese Art der Nachrichten erfolgt ohne aktive Anfrage, weder vom Switch noch
Controller. Hello-Nachrichten werden zur Initiierung der Verbindung zwischen
Controller und Switch verwendet. Für das Signalisieren eines Keep Alive hinge-
gen wird Echo verwendet. Echo kann zusätzlich zur Messung der Bandbreite, La-
tenz und einer fortlaufenden Ausführung des Schedulers genutzt werden.
▪ Controller ↦ Switch
Eine aktive Anfrage der Nachricht vom Controller. Dieser Typ von Nachricht
wird für die explizite Anforderung von bestimmten Informationen genutzt. Ein
Switch ist dazu gezwungen, je nach Nachricht eine Antwort auf diese Anfrage zu
senden.
▪ Asynchron
Mitteilungen werden unabhängig von einer expliziten Anfrage des Controllers
von einem Switch versendet. Diese werden als Benachrichtigung eingetretener
Ereignisse verwendet. Eine Auswahl dieser Nachrichtentypen wird in Tab. 5 dar-
gestellt. Ein Switch z.B. nutzt die Nachricht Packet_In, um bei einem Table
Miss einen Controller eine Entscheidung über das Paket treffen zu lassen.
18
Type Name Kategorie | Richtung
0 Hello Symmetrisch
1 Error Symmetrisch
2 Echo_Request Symmetrisch
3 Echo_Reply Symmetrisch
4 Experimenter Symmetrisch
5 Feature_Request Controller ↦ Switch
6 Feature_Reply Controller ↦ Switch
7 GetConfig_Request Controller ↦ Switch
8 GetConfig_Reply Controller ↦ Switch
9 SetConfig Controller ↦ Switch
10 Packet_In Asynchron
11 FlowRemoved Asynchron
12 PortStatus Asynchron
13 PacketOut Controller ↦ Switch
14 FlowMod Controller ↦ Switch
Tab. 5: Teilausschnitt der Nachrichtentypen von OpenFlow 1.4 [11, S. 251];
3.4 Open vSwitch
Open vSwitch implementiert einen Multilayer Switch innerhalb einer Software-Lösung.
Das Projekt zielt auf die Umsetzung einer Lösung, welche in einem Produktionsumfeld
Einsatz findet. Die Funktionen, welche verwendet werden können, entsprechen den heu-
tigen Standards. Als Basis wird die Programmiersprache C genutzt, welche eine platt-
formunabhängige Programmiersprache darstellt. Dadurch kann eine einfache Adaption
auf ein anderes Betriebssystem stattfinden [14]. Open vSwitch findet Anwendung in Vir-
tualisierungsumgebungen, um mehrere VMs über einen Switch zu verbinden statt über
eine Bridge, welche über den Hypervisor laufen würde [15, S. 49].
In der Version 2.11.90 werden folgende Funktionalitäten gestellt [14, 16]:
▪ OpenFlow 1.0 mit Erweiterungen
▪ IEEE 802.1Q, VLAN Modell mit Trunk und Access Port
▪ IEEE 802.1AX-2008 (früher 802.3ad), LACP, Link Aggregation Control Protocol
▪ IEEE 802.1ag Fehlermanagement der Konnektivität
▪ QoS, Quality of Service
▪ Geneve, GRE, VXLAN, STT und LISP tunneling
▪ NetFlow, sFlow®, gespiegelte Ports
▪ NIC Bündelung mit oder ohne LACP für Upstream
▪ Hoher Datendurchsatz und Vermittlung von Paketen unter Verwendung eines
Linux Kernel Modules
19
3.4.1 Open vSwitch Architektur
Open vSwitch setzt sich aus mehreren Modulen zusammen, um das Virtualisieren von
Switches zu ermöglichen. In dieser Architektur verteilen sich Komponenten zwischen
dem User, Userspace, und Kernel, Kernelspace, je nach Kontext. In Abb. 8 ist eine Über-
sicht der Verteilung der Module zu sehen. Um Pakete mit hoher Geschwindigkeit zu ver-
arbeiten und diese in das Netzwerk einzuspeisen, verwendet Open vSwitch ein Modul,
welches im Kernelspace angesiedelt ist.
Abb. 8: Open vSwitch Module in Anlehnung an [17, S. 5]; Übersicht der Architektur von Open vSwitch.
Das ovsdb-server Modul wird für die Konfiguration eines Open vSwitch genutzt. Die
Erfassung der Einstellungen erfolgt auf einer pro Switch Basis. Diese Einstellungen be-
schreiben die Definition der jeweiligen Bridges. Die Einstellungen repräsentieren den
Switch und die erstellten Interfaces und Tunnel. Ferner werden die Adressen der
OVSDB-Datenbank und OpenFlow-Controller gesichert. Einstellungen werden auf ei-
nem persistenten Medium gespeichert, z. B. wie einer Festplatte oder SSD. Dadurch wird
die Konfiguration wiederherstellfähig und kann beim Neustarten des Computers geladen
werden.
Das Modul ovs-vswitchd stellt einen Dienst bereit, welcher eine bestimmte Anzahl an
Switches implementiert. Im Zusammenspiel mit dem OVS Kernel-Modul ermöglicht der
Dienst das Flow basierende Verteilen von Paketen. Einstellungsparameter für einen
Switch bezieht der Dienst von dem ovsdb-server-Modul [16, 18, S. 5].
20
Abb. 9: Core Tables des ovs-vswitchd Dienstes von Open vSwitch [17, S. 8]; Übersicht einzelner Tabellen im Daten-
bankensystem des Open vSwitch. Die Konfiguration der Dienste unter Linux, wird in der Open_vSwitch-Tabelle abge-
legt. Es darf nur ein expliziter Eintrag in dieser Tabelle existieren. Weitere Einstellungen einzelner Komponenten des
Software-Systems werden in anderen Tabellen abgelegt.
Die Core Tabellen des Dienstes sind in Abb. 9 als Übersicht gestaltet. Parameter und
Konfigurationseinstellungen werden in diesen abgelegt. Open_vSwitch stellt die Infor-
mationen für den Dienst bereit. Diese Tabelle beinhaltet explizit nur einen Eintrag. An-
deren Tabellen wie Bridge, Port, Interface und Controller speichern Parameter für die
einzelnen Komponenten. Diese sind benannt wie die korrespondierende Tabelle. Ferner
existieren weitere Tabellen [19].
3.4.2 Kernel Modul
Durch die Unterstützung eines im Kernelspace angesiedelten Moduls wird die Paketver-
arbeitung beschleunigt und performanter gegenüber einer Lösung im Userspace. Open
vSwitch verwendet Module in beiden Kontexten. Wenn ein neues Paket eintrifft, welches
keinen Cache-Treffer im Kernel-Modul erzielt, wird das Paket in den User Space über-
mittelt. Durch dies kann eine Entscheidung getroffen werden, welche Verarbeitung statt-
finden soll. Diese findet im SDN durch einen Controller statt. Die Beschreibung der an-
zuwendenden Regeln wird in Form von Flows durchgeführt. Nach dieser initialen Verar-
beitung wird mithilfe der Flows und dem daraus resultierenden Cache-Eintrag im
Kernel-Modul, die Geschwindigkeit erhöht. Ein Austausch der Informationen der Module
erfolgt über einen Netlink. Der Ablauf des Switchings findet im Kontext des Kernels statt
[17, 13-15].
21
Abb. 10: Kernel-Modul in Anlehnung an [17, S. 13]; Pakete werden für die Entscheidung der Verarbeitung vom Kernel
Space in den User Space transferiert. In diesem kann mithilfe eines SDN-Controllers ein Flow erstellt werden. Dieser
wird in die korrespondierende Flow Table eingetragen und ein Cache-Eintrag im Kernel Modul erstellt. Somit ist es
möglich, nachfolgende Pakete aus einer Verbindung zu verarbeiten und die Geschwindigkeit zu erhöhen.
3.5 Ryu Controller
Der Ryu Controller stellt die Hauptkomponente in einem SDN-Netzwerk dar. Das Soft-
waresystem wird als komponentenbasiertes Software Defined Networking Framework
entwickelt. Ryu wird in der Programmiersprache Python entwickelt unter der Apache 2.0
Lizenz. OpenFlow wird von Version 1.0 bis 1.5 im vollen Umfang unterstützt. Zusätzlich
werden Nicira Extensions unterstützt. Ferner finden weitere Steuerungsprotokolle wie
Netconf oder OF-config Unterstützung in Ryu. Niciria ist eine Firma, welche als Haupt-
entwicklungsschwerpunkt SDN und Virtualisierung von Netzwerkkomponenten hat. Im
Jahre 2012 wurde Nicira von VMware aufgekauft. Unter VMware wird mithilfe dieser
Firma der Ansatz der Infrastruktur als ein Service, IaaS, verfolgt [20, 21].
Für die Entwicklung einer Applikation in diesem Framework werden implementierte Me-
thoden aktiv auf ein Event gebunden. Die Verknüpfung kann zu einer Anzahl von Events
hergestellt werden. Diese werden mit der Python-Funktionalität eines sogenannten De-
korierers, Decorator, umgesetzt. Ein Decorator ist vergleichbar mit einem Funktionspoin-
ter, jedoch auf Basis von Objekten anstelle von Adressen. Durch eine Registrierung der
entwickelten Applikation in der Oberklasse, welche von Ryu bereit gestellt wird, kann
das Framework über die Direktive @set_ev_cls(ofpevent, dispatcher) eine Erweiterung
der bestehenden Methode erwirken. Diese Direktive verweist auf eine Metafunktion und
ermöglicht, dass die entwickelte Methode beim Eintreten eines Events aufgerufen wird
[22, S. 1317, 23, S. 437-438].
Tab. 6 erläutert Eigenschaften der einzelnen Dispatcher und deren Bedeutung. Bei Ein-
treten eines Events wird die mit dem Decorator markierte Methode ausgeführt [24, S. 12].
22
Aushandlungsphase
ryu.controller.handler.
Eigenschaft
HANDSHAKE_DISPATCHER Empfang und Versenden von Hello-Nachrichten
CONFIG_DISPATCHER Versionsaushandlung und Feature Request
MAIN_DISPATCHER Empfang von Switch-feature Nachrichten
DEAD_DISPATCHER Trennung des Knotens oder fehlerbezogenes Ereig-
nis
Tab. 6: Dispatcher-Eigenschaften des @set_ev_cls Decorator [24, S. 12];
Eine Aufteilung der möglichen Events ist durch Ryu ermöglicht. Mit dieser Unterteilung
können zu spezifischen Events einzelne Methoden genutzt werden. Dadurch ist eine Abs-
traktion der einzelnen Funktionalitäten möglich. Die Übersichtlichkeit und Wartbarkeit
des Codes steigen zudem an. In Tab. 7 wird ein Ausschnitt der konfigurierbaren Events
aufgelistet.
Event [ofp_event] Eigenschaft
EventOFPSwitchFeatures Austausch der Konfiguration
z.B. Flows, Pipelining
EventOFPPortStateChange Statusveränderung an einem Switchport
EventOFPPacketIn Eintreffen von Paketen am Controller
EventOFPFlowRemoved Signalisieren des Löschens eines Flows
Tab. 7: Ausschnitt konfigurierbarer OpenFlow Protokoll, OFP, Events;
3.6 Mininet
Mininet [25] ermöglicht eine realistische Simulation von Netzwerken auf einem konven-
tionellen Computer. Die Simulationsumgebung unterstützt Entwickler von Systemen.
Entwickler haben somit die Möglichkeit, Lösungen für neue Anforderungen zu entwi-
ckeln, ohne ein bereits implementiertes und im operativen Zustand befindliches Netzwerk
zu verändern und somit Fehlverhalten hervorzurufen.
Die Simulationsumgebung verwendet eine Funktion des Linux Kernels, welche die Er-
stellung der Abstraktion der Ausführungskontexte ermöglicht. Linux unterstützt seit
Kernel-Version 2.6.29 die Funktion von Netzwerk Namespaces. Kernaspekt dieser
Namespaces stellt die Isolierung und Aufteilung von Netzwerkumgebungen dar. Sie bie-
ten eine zusätzliche Abstraktionsmethode für aufgeteilte Ausführungskontexte. Beson-
derheit dieser Kontexte ist, dass ein Prozess nur auf den Kontext zugreifen kann, in dem
er erstellt worden ist [15, S. 60]. Ein weiterer Aspekt dieser Isolierung besteht darin, dass
eine komplette Virtualisierung eines Betriebssystems, eine virtuelle Maschine, nicht be-
nötigt wird. Das resultiert in einer leichtgewichtigen, prozessbasierenden Virtualisierung.
Ferner kann einem Prozess oder einer Gruppe von Prozessen ein kompletter unabhängiger
Netzwerkstack zugeteilt werden [26, S. 512]. Jeder Namespace beinhaltet zudem
23
eigenständige Routing-Tabellen. Dies ermöglicht die Simulation von einer Vielzahl von
Geräten auf einem Kernel. Ein Host, welcher mithilfe dieser Methode erstellt und simu-
liert wird, repräsentiert das äquivalente Verhalten wie ein klassischer Computer innerhalb
des Netzwerkes. Ein solch erstellter Host kann via SSH, Secure Shell, oder über eine
Xterm Sitzung erreicht werden. Unteranderem kann auf diesem virtuellen Host beliebige
Software ausgeführt werden [27].
Windows hingegen stellt kein ähnliches Feature bereit. Innerhalb einer Entwicklungsum-
gebung, die auf Windows basiert, wird eine vollständige Virtualisierung benötigt, welche
auf einen Linux Kernel setzt. Die Ersteller des Projektes stellen für Windows und alle
modernen Betriebssysteme ein Abbild für eine virtuelle Maschine zur Verfügung [28].
Switches, welche Mininet in der Simulation verwendet, werden mittels Open vSwitch
erstellt. Diese Switches können mithilfe von einer bereitgestellten API, welche in Python
geschrieben ist, als User oder Kernel Mode Switches genutzt werden. Die API stellt eine
Schnittstelle bereit, eigene und veränderte Netzwerkkonstellationen zu erstellen und diese
als ausführbare Scripts abzuspeichern.
3.7 Docker
Docker stellt gegenüber der traditionellen Virtualisierung eine containerbasierte Virtua-
lisierung auf Prozessbasis bereit. Diese bietet die Möglichkeit, dass einzelne Prozesse und
Dienste in einer virtuellen Umgebung ausgeführt werden, um die Virtualisierung einer
kompletten Betriebssystemumgebung zu vermeiden. Die Ausführung von Docker-Con-
tainern wird auf dem gleichen Kernel durchgeführt wie das Supervisor-Betriebssystem.
Dabei stellt Docker eine Lösung dar, welche offene Standards verwendet. Entwickelte
Programme für Docker sind nicht an ein System gebunden. In Docker-Containern werden
benötigte Bibliotheken für die Ausführung der Applikation bereitgehalten. Dies verein-
facht Entwicklung und Verteilung. Die Beschreibung dieser Container findet in Docker
Images statt [29, S. 1].
Für die Entwicklung von SDN Netzwerken kann Docker verwendet werden, um unab-
hängige Teilnetze zu realisieren. Dabei kann eine East/West-Kommunikation zwischen
den Controllern stattfinden.
24
Kapitel 4
Lösung
4.1 Einleitung
Für die Lösungsfindung wird das Verständnis der vorherigen Kapitel vorausgesetzt. In
diesem Kapitel wird die Implementierung der Lösung vorgestellt. Als Ziel wird die Um-
setzung einer typischen Netzwerkanordnung angestrebt. Hosts in dieser Konstellation
werden über Distribution Switches an das Netzwerk angeschlossen. Jeder der Switche
wird mit dem Top Level Switch verbunden. Dieser Switch wird im SDN als Standardga-
teway für die Interaktion mit einem externen Netzwerk verwendet. Außerdem wird eine
VLAN Umgebung erstellt und getestet.
Die Umgebung, in der die Lösung erstellt wurde, ist mit folgenden Komponenten in Soft-
ware und Hardware erstellt worden:
Bezeichnung Version Besonderheiten
Manjaro Linux 18.0.4 „Illyria“ Kernel 4.19.32
OpenFlow 1.5
Open vSwitch 2.10.1
Ryu Controller 4.30 SDN Controller
PyCharm 2019.1 Python DIE
plugable Eth. Adapter USB 3.0 Gigabit Ethernet RJ45
Tab. 8: Übersicht der verwendeten Systemkomponenten für die Erarbeitung dieser Arbeit;
4.2 Topologie
Das Netzwerk, das für die Ausführung implementiert und konfiguriert wird, ist in Abb.
11 zu sehen. Einzelne Teilnehmer in dem Netzwerk werden mithilfe der Distribution
Switches, s1…4, angebunden. Diese Switche bieten den Zugang zur Netzwerkinfrastruk-
tur. Die Bestimmung der VLAN-Parameter werden mit der SDN-Controller-Konfigura-
tion festgelegt. Für die Verbindung in ein externes Netzwerk, in diesem Fall ein lokales
Netzwerk eines anderen Adressraums, wird der Switch tldsw0 mit einer physischen
Schnittstelle erweitert. Dieser Schnittstelle wird unter Linux mithilfe des Terminals eine
IP Adresse im entfernten Netzwerk zugewiesen. Das interne Netzwerk der Simulation
wird mit Mininet erstellt. Für die Adressvergabe wird der Adressraum 10.0.0.0/8 verwen-
det. Jeder Teilnehmer erhält die Information des Standardgateways. In einer SDN-Um-
gebung können, wie in klassischen Netzen, Switches keine IP Adresse direkt zugewiesen
werden. Jedoch kann dies mithilfe der Trennung zwischen Data- und Controlplane
25
programmiertechnisch im Controller erreicht werden. Für den Netzzugang des Standard-
gateways wird die IP Adresse 10.1.1.1/8 und die MAC Adresse 00:00:00:10:10:10 ge-
nutzt. Diese Zuordnung findet rein logisch im programmiertechnischen Controller statt.
Abb. 11: Netzwerktopologie der Implementierung im SDN; Einzelne Teilnehmer werden über die Switche s1…4 ver-
bunden. Verwendete Ports zu den Hosts stellen Access Ports dar. Die individuellen Verbindungen der Distribution
Switches zum Top Level Switch werden als Trunk bezeichnet. Auf diesem können Pakete mehrerer unterschiedlicher
VLANs transportiert werden. Die Nummern an den einzelnen Verbindungen bezeichnen die Identifikation innerhalb
der Datenpfade.
Für die Verwendung der SDN-Umgebung wird eine bestimmte Anzahl an Controllern
benötigt. Die Topologie in Abb. 11 verwendet zwei Controller, um Switche einer logi-
schen Ebene an jeweils einen der vorhandenen Controller anzubinden. Die Kommunika-
tion erfolgt, wie in Kapitel 3.3.4 beschrieben, über eine TCP-Verbindung zwischen Con-
troller und Switch. Aus dieser Gegebenheit folgt, dass jeder Controller auf einem dedi-
zierten Port operiert. Der Quell-Port einer Nachricht kann von jedem Gerät frei gewählt
werden. Controller c0 agiert für s1…4 auf Port 6653 und c1, agiert für tldsw0 auf Port
6654. Die Controller ermöglichen eine Unterteilung und Ausgliederung des Programm-
codes, welcher die Charakteristik der Controlplane beschreibt.
Die Erstellung der Netzwerktopologie wird durch eine Scriptdatei automatisiert. Der In-
halt dieser Datei beschreibt die Verbindung der einzelnen Komponenten zueinander. Ein-
zelne Hosts erhalten eine freie IP Adresse im 10.0.0.0/8 Adressraum. Die Vergabe der IP
Adressen kann automatisch über Mininet erfolgen oder es kann eine manuelle Zuordnung
stattfinden. Die automatische Vergabe der Adressen beginnt mit 10.0.0.1 für Host 1. Die
Adressvergabe wird bis zum letzten Host fortgeführt. Die verwendeten Controller werden
als RemoteController definiert und deklariert. Mininet verwendet ohne eine Spezifizie-
rung des Controllers einen Default Controller. Dieser variiert je nach verfügbaren Con-
trolleren [27]. Die Assoziation dieser wird mithilfe eines Dictionary festgelegt.
26
1. c0 = RemoteController('c0', ip='127.0.0.1:6653') 2. c1 = RemoteController('c1', ip='127.0.0.1:6654') 3. 4. cmap = {'s1': c0, 's2': c0, 's3': c0, 's4': c0, 'tldsw0': c1}
Code 1: Definition, Deklaration und Assoziation der Controller zu den SDN Switches;
Um diese Assoziation zu ermöglichen, siehe Code 2, wird eine neue OVSSwitch Klasse
erstellt. Diese wird über den Mechanismus des Polymorphismus in der Vererbung erstellt.
Durch diese Veränderung der Klasse kann spezifiziert werden, welcher Switch zu wel-
chem Controller zugeordnet wird. In der OVSSwitch-Klasse kann die verwendete Proto-
koll-Version von OpenFlow angegeben werden.
1. class MultiSwitch(OVSSwitch): 2. # Custom Switch() subclass that connects to different controllers 3. def start(self, controllers): 4. self.protocols = "OpenFlow15" 5. return OVSSwitch.start(self, [cmap[self.name]])
Code 2: Überschriebene OVSSwitch-Klasse; Die Überschreibung ermöglicht mit der Assoziation aus Code 1 während
der Erstellung des Switches eine Zuordnung zu einem Controller. Die Spezifizierung des zu verwendenden Open-
Flow-Standards kann zudem hier erfolgen.
Die Erstellung einzelner Hosts erfolgt in der Klasse NetworkTopo. Diese Klasse erstellt
die einzelnen Komponenten der Netzwerkumgebung. Hosts und Switche werden mit der
zugehörigen Methode erstellt. Der Rückgabewert eines Methodenaufrufs stellt das zuge-
hörige Netzwerkgerät dar. Dieser Wert ermöglicht die weitere Verarbeitung der Geräte
im Zusammenhang der Umgebung von Mininet. Die komplette Klasse ist in Code 3 zu
sehen.
1. class NetworkTopo(Topo): 2. 3. def build(self): 4. hosts = [] 5. 6. # Distribution switch controller 7. info(" *** Adding c0 for distribution switches " 8. "localhost@6653 ***\n") 9. c0 = RemoteController('c0', ip="127.0.0.1", port=6653) 10. 11. # NAT Controller 12. info(" *** Adding c1 for nat switch localhost@6654 ***\n") 13. c1 = RemoteController('c1', ip="127.0.0.1", port=6654) 14. 15. # Generate hosts 16. info(" *** Adding hosts ***\n") 17. 18. for i in range(9): 19. hosts.append(self.addHost('h%s' % (i+1), 20. defaultRoute='via 10.1.1.1')) 21. info("h%d " % i)
27
22. 23. # Generate switches 24. info("\n *** Adding switches ***\n") 25. 26. switches = [self.addSwitch('s%d' % i) for i in (1, 2, 3, 4)] 27. 28. # Top level switch as default fake gateway 29. tldsw0 = self.addSwitch("tldsw0") 30. 31. # Connecting the hosts with the switches 32. self.link_hosts_to_switches(hosts=hosts, switch=switches[0],
count=4) 33. self.link_hosts_to_switches(hosts=hosts, switch=switches[1],
count=2, offset=4) 34. self.link_hosts_to_switches(hosts=hosts, switch=switches[2],
count=2, offset=6) 35. 36. self.addLink(switches[3], hosts[8]) 37. 38. # Connect switches with hosts to the fake gw one 39. for i in range(len(switches)): 40. self.addLink(switches[i], tldsw0) 41. 42. # Add links between the switch and each host 43. def link_hosts_to_switches(self, hosts, switch, count, offset=0): 44. for i in range(0, count): 45. self.addLink(switch, hosts[i+offset]) 46. 47. topo = NetworkTopo() 48. net = Mininet(topo=topo, switch=MultiSwitch, build=False, 49. autoSetMacs=True, cleanup=True) 50. 51. for c in [c0, c1]: 52. net.addController(c) 53. 54. net.build() 55. net.start() 56. 57. CLI(net) 58. 59. net.stop() 60.
Code 3: Netzwerkbeschreibung in Mininet; Die Erstellung der Netzwerktopologie erfolgt durch das Erzeugen eines
Objektes der NetworkTopo-Klasse. In Zeile 48 werden die Parameter für Mininet übergeben. Der Parameter "switch"
ermöglicht die Verwendung der angepassten Klasse OVSSwitch. Mit build=False wird die Topologie nicht sofort nach
Aufruf des Befehles erstellt. Für die Vereinfachung während der Entwicklung wird der Parameter autoSetMacs auf
True gesetzt. Dadurch werden die MAC Adressen der einzelnen Hosts vereinfacht und von dem Wert null inkrementiert
mit jeder Iteration der Erstellung eines Hosts.
Die Ausführung des Scriptes erfolgt mit dem Befehl:
1. ~# mn --custom ./network_topo.py
Code 4: Ausführung des Mininet Script;
28
Abb. 12: Zuordnung der Controller der SDN-Simulationsumgebung, ohne Hosts; Die Controller c0 und c1 beeinflussen
die Netzwerksteuerung. Die Trennung der beiden Controller ermöglicht die Unterteilung der Programmierung.
In Abb. 11 wird die Netzwerktopologie ohne SDN-Controller abgebildet. In Verbindung
mit dem Mininet Script wird die Assoziation um SDN-Controller erweitert. In Abb. 12
wird der Zusammenhang der einzelnen SDN Switche abgebildet. Diese sind für die Wei-
terleitung und Verarbeitung der Pakete des Netzwerkes zuständig. Zudem zeigt die Grafik
die Verbindung der Controlplane und der Dataplane. Die Unterteilung der beiden Con-
troller ermöglicht die differenzierte Programmierung der Steuerung einzelner Netzwerk-
geräte. Die Verbindung der Switche zu dem jeweiligen Controller erfolgt über das lokale
Loopback Interface des Computers, welches die Simulation durchführt. Die Konfigura-
tion der Verbindungen wird im Mininet Script festgelegt. Ein SDN-Controller ist nicht
gebunden an einen Computer, auf dem die Simulation durchgeführt wird. Er kann auf
einem anderen Computer ausgeführt werden.
Die Konfiguration der VLAN Parameter findet softwareseitig in der Programmierung der
Controller statt. In Abb. 13 wird die Zuweisung der einzelnen VLAN IDs aufgezeigt. Eine
Auflistung der Port-Konfiguration erfolgt in Tab. 9. Einzelne Hosts können mit Teilneh-
mern des gleichen VLANs Daten austauschen. Eine Unterteilung eines Netzwerkes in
unterschiedliche VLANs teilt zudem die Broadcast-Domäne.
Gerät Port VLAN Typ
S1 1, 2 1 Access
3, 4 2
5 Trunk
S2 1 1 Access
2 2
3 Trunk
S3 1, 2 1 Access
3 Trunk
S4 1 1 Access
29
2 Trunk
Tldsw0 1-4 Trunk
5 Externe Kommunikation
Tab. 9: Port-Konfiguration der SDN Switches;
Abb. 13: Netzaufbau mit zugeordneten VLAN IDs ; Die Übersicht zeigt die Topologie mit zugeordneten VLAN IDs für
jeden Host. Dabei steht Blau für VLAN 1 und Violett für VLAN 2. Pakete werden innerhalb der Switches mit 802.1Q
Headern versehen. Hosts versenden Pakete ausschließlich ohne VLAN Tag.
4.3 SDN Komponenten
Für die Steuerung und Erstellung der Flows für einzelne SDN-Netzelemente werden zwei
Controller verwendet. Durch diese Trennung kann eine Vereinfachung im Programmie-
ren der einzelnen Controller stattfinden. Eintreffende Pakete der Dataplane, die in den
Switches als Table Miss ausgewertet wurden, da sie keinem Flow zugeordnet werden
konnten, lösen Events innerhalb des Ryu Frameworks aus. OpenFlow Events werden von
Ryu verwaltet. Eine Verarbeitung der Events wird mithilfe von Decorator-Funktionen
bereitgestellt. Mit dieser Funktionalität stellt das Framework die Programmierung neuer
Ryu Applikationen bereit. Eine Ryu Applikation stellt dabei einen Controller dar. In die-
ser Klasse werden Verarbeitung und Entscheidungsfindung definiert. Diese Verarbeitung
resultiert in spezifischen Flows für einzelne vermittelnde Instanzen innerhalb des
SDN-Netzwerkes. Flows beschreiben, wie im Grundlagenkapitel erläutert, Pfade durch
das Netzwerk. Im Nachfolgenden werden die verwendeten Controller beschrieben.
30
4.3.1 Ryu Controller
Ein Controller stellt ein zentrales Element in einem SDN-Netzwerk dar. Mit diesem kön-
nen Ablauf, Gestaltung und Kriterien der Verarbeitung von Paketen festgelegt werden.
Die Nutzung mehrerer Controller ermöglicht eine Unterteilung der Verarbeitung von Pa-
keten. Die Zuordnung der einzelnen Geräte zu einem Controller erfolgt auf Basis der
Funktionalität der Geräte. Beide Controller werden als eigenständige Klasse beschrieben
und sind abgeleitet von einer Klasse im Ryu Framework. Dabei wird das Verhalten des
Controllers c0 in der Klasse TLDSRouter beschrieben. Das Verhalten von c1 wird in der
Klasse DstrSwitchCtrl programmiert. Ferner ermöglicht die Vererbung der Oberklasse
RyuApp in eine Controller-Klasse das Bereitstellen von Event-Handler-Methoden für die
Ryu Umgebung.
Abb. 14: Vererbungsstruktur der Controllerklassen; Ein Controller, welcher unter Verwendung des Ryu Frameworks
erstellt wird, stellt eine Spezialisierung der RyuApp Klasse dar. Mithilfe dieses Verfahrens wird ermöglicht, dass ein
entwickelter Controller in den Scheduler von Ryu eingegliedert werden kann. TLDSRouter stellt dabei die Klasse für
c0. Controller c1 wird mithilfe von DstrSwitchCtrl repräsentiert.
Eintreffende Pakete werden in beiden Controllern zunächst auf Teileigenschaften der
Übermittlung überprüft. Die Überprüfung, ob das Paket, welches eintraf, ein Ethernet
Paket ist, stellt sicher, dass ausschließlich Pakete, die diesem Standard entsprechen, ver-
arbeitet werden. Zudem wird überprüft, ob das Paket kein Link Local Discovery Protocol,
LLDP, ist. Sobald eines der Kriterien zutrifft, wird das Paket verworfen. Nach diesem
Schritt werden Pakete je nach Controller und Einsatz in einzelne Komponenten unterteilt
und ausgewertet. Dabei stellt eine Komponente einen Teil des Paketes dar. Die Untertei-
lung erfolgt in den nach dem OSI-Modell bekannten Schichten. Zudem werden Informa-
tionen der Netzwerktopologie gespeichert. Diese enthält z.B. die Verknüpfung zwischen
MAC Adresse und dem Ingress Port sowie, falls das Paket diese Informationen bereit-
stellt, MAC zu IP.
Bereitgestellte Methoden in beiden Controller-Klassen mit dem Suffix handler werden in
das Ryu Framework registriert, um ein bestimmtes Verhalten bei auftretenden Events zu
erzielen. Ein Controller, welcher eine eingehende Verbindung eines Netzgerätes erhält,
stellt an dieses eine Feature Request Anfrage. In dieser erhält der Controller die
31
Leistungsparameter und Daten wie Datapath ID und verfügbare Ports. Diese initiale Kon-
figuration löst das Event EventOFPSwitchFeatures aus. Ferner werden Events behandelt,
welche das Entfernen von Flows innerhalb der Switche betrifft, die Statusänderung von
Ports sowie das Empfangen von Paketen aus Table Miss Events.
4.3.2 Distribution Switches, Controller c1
Die Klasse DstrSwitchCtrl wird für die Implementierung des Controllers c1 verwendet.
Eine Übersicht der Methoden und Feldern ist in Abb. 15 zu sehen. Die Bezeichnung Fel-
der bezieht sich im Kontext von Python nicht auf Arrays, welche aus klassischen Pro-
grammiersprachen wie C++ oder C# bekannt sind, sondern auf Klassenattribute. Hel-
fer-Methoden wie z. B. add_flow ermöglichen ein zentrales Erstellen und Hinzufügen
von Flows.
Abb. 15: Klassenübersicht von c1 nach PyCharm Modell; Methoden mit dem Suffix _handler verarbeiten ausgelöste
Events aus dem Ryu Framework. Der Hauptfokus von Controller c1 liegt in der Methode handle_vlan. Diese verarbeitet
eintreffende Pakete. Die Erstellung von Flows entsteht auf Basis unterschiedlicher Kriterien, welche später erläutert
werden.
Mithilfe der Programmierung des Controllers c1 durch die Klasse DstrSwitchCtrl und
Unterteilung der Flows in unterschiedliche Tabellen kann ein Pipeline Prozess im Switch
erstellt werden, siehe Abb. 16. Die Verarbeitung findet in differenzierten Tabellen statt.
Jedes Paket trifft zunächst auf Flow Table 0. Diese Tabelle dient zur Regulierung des
32
Netzzugriffes. Verbindungen, welche zwischen Hosts des gleichen VLANs hergestellt
werden und durch den gleichen Switch an das Netzwerk angebunden sind, werden in die-
ser Tabelle abgelegt. Pakete, welche über einen Trunk Port versendet werden, erhalten
vor dem Versenden einen VLAN Header, welche die ID beinhaltet.
Abb. 16: Pipeline Prozess Distribution Switches; Die Verarbeitung der Flows erfolgt auf dieser logischen Unterteilung.
Flows die von Paketen, welche von Hosts auf der Access-Seite des Switches eingehen, werden in Table 0 eingegliedert.
Darunter fallen die Erstellung eines VLAN Tags und der direkte Weg der Pakete von Host zu Host auf einem Switch.
Eingehende Pakete des Trunk Ports werden weitergeleitet zu der korrespondierenden Table.
Eintreffende Pakete des Trunk Ports werden anhand der VLAN ID, auch VID genannt,
in die zutreffende Table weitergeleitet. Dort werden Flows hinterlegt, welche die Vertei-
lung der Pakete an die Hosts steuern. Um dieses initiale Verhalten zu erzielen, werden
während dem Konfigurationsprozess zwischen Switch und Controller Flows ausge-
tauscht.
1. ~# ovs-ofctl -O OpenFlow15 dump-flows s1
2. cookie=0x25, …, table=0, …, dl_vlan=1 actions=goto_table:1
3. cookie=0x25, …, table=0, …, dl_vlan=2 actions=goto_table:2
4. cookie=0x00, …, table=0, …, priority=1 actions=CONTROLLER:65535
5. cookie=0x00, …, table=1, …, priority=1,dl_vlan=1
actions=CONTROLLER:65535
6. cookie=0x00, …, table=2, …, priority=1,dl_vlan=2
actions=CONTROLLER:65535
Code 5: Ausgabe der Flow-Abfrage eines Distribution Switches; Gekürzte Ansicht der Ausgabe. Metadaten wurden
entfernt. Übersicht der initialen Flows in einem beliebigen Distribution Switch. Die Anweisungen in Zeile zwei und
drei verweisen auf die Flow Table 1 und 2. Diese verarbeiten eintreffende Pakete des Trunk Ports mit den zugehöri-
gen VIDs. Jede Flow Table hat einen Table Miss Entry, welcher das Paket an den Controller schickt, um eine Anwei-
sung zu erhalten.
Nach dem Austausch der anfänglichen Nachrichten im OpenFlow Prozess werden grund-
legende Flows für die Ausführung der Pipeline hinzugefügt. In Code 5 ist die Ausgabe
nach der Abfrage der enthaltenen Flows eines Distribution Switches aufgeführt. Pakete,
welche mit einem VLAN Tag eintreffen, werden in die korrespondierende Flow Table
weitergeleitet. Dies wird mit den Einträgen in Zeile zwei und drei erzielt. In jeder Table
ist ein Flow für den Fall eines Table Miss hinterlegt.
Distribution Switche verarbeiten eintreffende Pakete auf Basis der VLAN Tags. Die Ver-
arbeitung von Paketen, welche über den jeweiligen Trunk Port empfangen werden, erfolgt
33
durch die Auswertung des enthaltenen 802.1Q VLAN Header. Dieser wird bei der Erstel-
lung in einen Ethernet Frame nach Standard 802.3 gegliedert. Die zusätzlichen Informa-
tionen beschreiben die Priorität, CFI und die VLAN ID. Durch die hinzugefügten Infor-
mationen kann eine Entscheidung innerhalb des Controllers getroffen werden. Die Kon-
figuration der assoziierten Ports zu einem spezifischen VLAN ID wird in beide Controller
mit einer Variablen gespeichert. Während der Initialisierung der Controller-Klasse wird
die Variable deklariert und definiert. Durch einen unterschiedlichen Aufbau und Verwen-
dung der Controller variiert der Aufbau der Variablen. In c1, welcher für s1…4 zuständig
ist, wird die Datapath ID zusätzlich gesichert. Diese identifiziert einzelne Geräte in der
Netzwerkstruktur. Dabei stellt jede ID einen eindeutigen Wert dar. Diese Struktur wird
in Code 6 dargestellt.
1. def __init__(self, *args, **kwargs): 2. ... 3. self.vlan_port_config = {1: {1: 1, 2: 1, 3: 2, 4: 2}, 4. 2: {1: 1, 2: 2}, 5. 3: {1: 1, 2: 1}, 6. 4: {1: 1} 7. } 8. 9. self.trunk_ports = {1: 5, 2: 3, 3: 3, 4: 2} 10. ...
Code 6: VLAN Konfiguration Controller c1; Das Dictionary stellt die Information für die Datapath ID 1…4 dar. Dabei
stellt das innere Dictionary, welches der ID zugeordnet ist, die Assoziation zwischen Port und VLAN ID her. Eine
Zuweisung der Trunk Ports kann vereinfacht abgespeichert werden. Die Übersicht der Konfiguration ist in Tab. 9
tabellarisch und in Abb. 13 topologisch dargestellt.
Auf Basis dieser Informationen ist die Findung einer Entscheidung möglich. Durch die
Unterteilung des Netzwerkes in Virtual Local Area Networks wird eine logische Unter-
teilung des Netzwerkes möglich. Jedes eindeutige VLAN ist an eine eindeutige gegebene
ID gebunden. Die Unterteilung teilt zudem die Broadcast-Domäne auf. Dadurch wird eine
einzige große Broadcast-Domäne in kleinere unterteilt.
Für die Erstellung der Flows für die Switche s1…4 werden mehrere Kriterien ausgewer-
tet. Distribution Switche haben zwei Hauptkriterien zur Unterscheidung von eintreffen-
den Paketen. Einzelne Teilnehmer, Hosts, des Netzes sind an den Access Ports der Dis-
tribution Layer Switches angeschlossen. Somit werden Pakete, welche einen VLAN Tag
besitzen und über diese Ports empfangen werden, nicht verarbeitet. Die Erweiterung des
Ethernet Frames um die Funktion IEEE 802.1Q ist Switchen vorbehalten. Eine Nichtein-
haltung dieser Reglung kann die Kompromittierung der einzelnen Netzwerke zur Folge
haben.
Durch einen Host, welcher ein Ziel innerhalb desselben VLAN kontaktieren möchte und
dieses Ziel an dem identischen Switch zu finden ist, wird die Erstellung eines direkten
Flows ausgeführt. Durch eine direkte Verbindung wird die Erstellung eines VLAN-Hea-
ders nicht benötigt. Um dieses Verhalten zu erreichen, wertet der Controller Verbin-
dungsinformationen aus, welche durch die Sammlung von Informationen der Topologie
erhalten wurden. Dieser direkte Flow wird an den Switch übermittelt, um eine direkte
34
Verarbeitung der Pakete zu ermöglichen. Diese Flows werden in Table 0 gespeichert. Die
Match-Kriterien für diesen Flow sind: Ziel und Quell MAC Adresse sowie Ingress Port.
Action: Egress Port.
Falls das Ziel nicht auf dem gleichen Switch liegt und über den Trunk Port erreichbar ist,
wird ein Paket durch einen VLAN-Header erweitert. In diesem wird die VID der Quelle
eingetragen und an den darüber liegenden tldsw0 Switch geleitet. Dieser verteilt das Paket
gemäß dem Ziel und der VID weiter. Ein Flow wird in diesem Fall nur erstellt, wenn es
sich nicht um einen Broadcast handelt. Diese Flows werden, wie auf den Kriterien des
vorherigen Flows, in Table 0 eingetragen. Match: Ziel MAC und Ingress Port. Action:
PushVLAN, VID = Quell VID und Egress Port = Trunk Port
Wenn sich keine Information aus den gesammelten Topologie-Daten extrahieren lässt,
wird das Paket auf allen zugeordneten Ports des Switches verteilt. Zudem wird das Paket
über den Trunk Port mit dazugehörigem VLAN-Header geschickt. In diesem Zusammen-
hang wird kein Flow erstellt.
Daten-Pakete, welche über einen Trunk Port erhalten werden, müssen einen VLAN
Frame besitzen. Wenn festgestellt wird, dass das Paket keinen VLAN Tag beinhaltet,
erfolgt keine Bearbeitung des Paketes und wird verworfen. Mit der Ziel MAC Adresse
wird versucht, einen Egress Port zu finden. Falls ein geeigneter Port gefunden wird, muss
zusätzlich die VID abgeglichen werden, welche in der Konfiguration hinterlegt ist. Sind
diese Kriterien erfüllt, wird ein Flow erstellt. Dieser wird in der zugehörigen Table n
abgelegt, wobei n die korrespondierende VID darstellt.
Match: VID, Ziel MAC. Action: PopVLAN, Egress Port = Access Port
Im Falle, dass kein Port gefunden werden konnte, wird das Paket auf alle geeigneten Ports
am Switch verteilt. Als Bedingung besteht eine äquivalent konfigurierte VID des Ports.
In diesem Zusammenhang wird kein Flow erstellt.
Das Hinzufügen der Flows in unterschiedlichen Flow Tables ermöglicht die Bearbeitung
der Pakete in einer Pipeline. Diese ist für jeden Switch der Distribution-Schicht identisch.
4.3.3 NAT Switch, Controller c0
Die Steuerung für den Switch tldsw0 erfordert eine erweiterte Verarbeitung der Pakete.
Durch eine NAT-Funktion des Switches werden Antworten auf ARP-Anfragen auf das
Standardgateway des einzelnen Hosts erforderlich. Ohne die Antwort, welche die MAC
Adresse des Gateways beinhaltet, kann keine Kommunikation zwischen diesen Geräten
stattfinden. Durch diese Bedingung wird die Verarbeitung von ARP-Paketen benötigt.
Für diese Funktionalität werden mehrere Methoden verwendet. Eine Überprüfung eines
ARP-Paketes findet in arp_packet_handler statt. Wenn die Bedingung zutrifft, dass das
Paket ein ARP Request ist und an die IP des Standard Gateway, 10.1.1.1, gerichtet ist,
wird ein Flow zudem installiert mit add_arp_flow_default_gw. Die komplette Übersicht
der Klasse kann Abb. 17 entnommen werden.
35
Abb. 17: Klassenübersicht von c0 nach PyCharm Modell; Für die erweiterte Funktionalität des NAT Switches werden
unterschiedliche Helfermethoden erstellt. Damit können die Wiederholung und Fehleranfälligkeit von Programm Code
verringert werden. Um eine NAT-Funktion bereit zu stellen, muss auf ARP-Pakete mit einem Request an die Standard-
gateway IP geantwortet werden. Zusätzlich wird auf Pinganfragen reagiert und eine Antwort gesendet.
36
Der Prozess der Pipeline, siehe Abb. 18, wird, gegenüber der Pipeline für Distribution
Switches, um eine Flow Table erweitert. Diese Flow Table speichert Flows ab, welche
für die Übersetzung der Netzwerk-Adressen verwendet werden. Die Verarbeitung und
Verteilung jener Pakete, welche über einen der Trunk Ports eintreffen, werden über Flows
gesteuert. Die Einteilung der Flows erfolgt auf Grundlage der VID des jeweiligen Pa-
ketes.
Abb. 18: Pipeline Prozess NAT Switch; Der Pipeline-Prozess wird um eine Flow Table erweitert. Eine Erweiterung
der Pipeline um eine dritte Flow Table ermöglicht eine Einteilung der NAT zugehörigen Flows. In dieser Table werden
Regeln festgelegt, welche die Übersetzung der Adressen realisieren.
Um die NAT-Funktion zu implementieren und diese in den Pipeline Prozess einzuglie-
dern, werden mehrere neue Flows bei der Initialisierung des Switches übermittelt. Im
Abschnitt Code 7 werden diese neuen Flows aufgezeigt. Im Gegensatz zu den Distribu-
tion Switches, welche Hosts an das Netzwerk anbinden, werden Pakete ohne VLAN Tag
nicht bearbeitet und direkt verworfen. Somit findet keine Table Miss Event statt.
1. ~# ovs-ofctl -O OpenFlow15 dump-flows tldsw0
2. …, table=0, …, dl_vlan=1 actions=goto_table:1
3. …, table=0, …, dl_vlan=2 actions=goto_table:2
4. …, table=0, …, priority=3,in_port=enp0s20f0u4u2 actions=goto_table:3
5. …, table=1, …, priority=1,dl_vlan=1 actions=CONTROLLER:65535
6. …, table=2, …, priority=1,dl_vlan=2 actions=CONTROLLER:65535
7. …, table=3, …, priority=1,arp actions=CONTROLLER:65535
8. …, table=3, …, priority=1,icmp, nw_dst=192.168.2.200, icmp_type=8
actions=CONTROLLER:65535
Code 7: Ausgabe der Flow-Abfrage des NAT Switch; Gekürzte Ausgabe, Verzicht auf Metadaten. Die grundlegende
Unterteilung der Verarbeitung von VLAN-Paketen erfolgt wie in einem Distribution Switch. Traffic, welcher auf dem
Port eintrifft, welches im externen Netzwerk liegt, wird direkt in die NAT Table weitergeleitet. Damit wird die Trennung
zwischen internem und externem Traffic bewirkt. Die Bezeichnung des Ports in Zeile vier variiert je nach Distribution
oder Gerät.
Nach einem Austausch von Informationen zwischen Controller und Switch sind in den
Flow Tables von tldsw0 Einträge für die Verarbeitung von Paketen vorhanden. Diese be-
ziehen sich auf die Erstellung der Pipeline. Die Flows, welche in Zeile zwei und drei
beschrieben werden, leiten Pakete mit zugehöriger VID in die korrespondierende Table
weiter. Durch die Gegebenheit, dass Pakete von Hosts innerhalb des internen Netzes aus-
schließlich mit VLAN Tag den Switch erreichen, wird Traffic ohne diesen verworfen. In
37
Zeile vier wird der Traffic, welcher über den NAT-Port eintrifft, in die NAT Flow Table
übermittelt. Dieser Port variiert in der Bezeichnung je nach Linux Distribution und Na-
mensgebung. In der NAT Table werden ARP-Pakete an den Controller weitergeleitet und
ausgewertet. Das Ziel ist, ein Abbild der Topologie außerhalb des internen Netzes aufzu-
bauen. Die gesammelten Daten ermöglichen das Erstellen von Paketen.
Hosts, welche Daten mit Teilnehmern außerhalb des eigenen Netzes austauschen wollen,
senden die Anfragen an das Standardgateway. Diese Information wird in der Konfigura-
tion des Hosts hinterlegt. Um Ethernet-Pakete senden zu können, wird die MAC Adresse
des Zieles im gleichen Subnetz benötigt. Die initiale Anfrage eines Hosts wird direkt be-
antwortet. Der installierte Flow für die Beantwortung des ARP Request wird universal
beschrieben. Dadurch wird pro VLAN für die Beantwortung nur ein Flow benötigt.
1. ~# ovs-ofctl -O OpenFlow15 dump-flows tldsw0
2. cookie=0x20, duration=7085.960s, table=1, n_packets=11, n_bytes=506,
idle_age=1243, priority=32,
arp,dl_vlan=1,arp_tpa=10.1.1.1,arp_op=1
actions=move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],
set_field:00:00:00:10:10:10->eth_src,
move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],
set_field:10.1.1.1->arp_spa,
move:NXM_NX_ARP_SHA[0..31]->NXM_NX_ARP_THA[0..31],
set_field:00:00:00:10:10:10->arp_sha,
set_field:2->arp_op,set_field:10.1.1.1->arp_spa,IN_PORT
Code 8: Abfrage der Flows in tldsw0 gekürzt; Die Ausgabe stellt den Flow für eine Beantwortung von ARP-Anfragen
an das Standardgateway im VLAN eins dar. Der Match des Flows, gelb markiert, trifft bei ARP-Anfragen an das Stan-
dardgateway zu. Für die Erstellung der Antwort, werden die Werte in den Quelladressfeldern auf die Zieladressfelder
kopiert, grün markiert. Nach der Kopierung des Wertes wird der Quellwert auf die für das Standardgateway zutreffen-
den Werte gesetzt, blau markiert. Als Egress Port wird der Port genutzt, an dem das Paket angekommen ist.
Die Abfrage in Code 8 zeigt einen solchen Flow für die VLAN-Pakete mit dem Wert von
eins der VID, gelb markiert. Für das Beantworten des ARP-Paketes wird in der Antwort
die Quell MAC Adresse an der Anfrage kopiert, grün markiert, und in das Feld der Ziel
MAC Adresse kopiert. Dies erfolgt für die angefragte IP Adresse ebenso. Die Felder für
die jeweiligen Quell-Adressen werden nach dem Kopieren auf die Werte des Gateways
gesetzt. Anderenfalls würden die neu gesetzten Werte, welche das Standardgateway re-
präsentieren übernommen und kopiert anstelle der gewünschten aus der Anfrage. Diese
Werte werden für die Erstellung der Antwort benötigt. Der Egress Port wird zudem als
IN_PORT bezeichnet. Durch diesen Flow kann für jede Anfrage in VLAN eins die Be-
antwortung durchgeführt, ohne Anfrage an den Controller für eine Entscheidung.
Der Prozess, um eine Network Address Translation durchzuführen, ist in Abb. 19 illus-
triert. Ein Host, welcher ein Paket an eine Netzwerkinstanz außerhalb des eigenen Netzes
senden möchte, sendet diese Anfragen an das Standardgateway. Die Anfrage wird nur auf
Basis des Ethernet Frames an das Gateway gesendet. Das IP Paket und Transport Paket
sind logisch davon getrennt, da diese Funktionen auf höheren Ebenen des OSI-Modells
liegen. Erhält der Switch dieses Paket, wird eine Übersetzung angestoßen. Dabei wird die
38
Quell-IP sowie der Quell-Port der Ausgangsnachricht durch die IP Adresse des Gateways
und einen freien Port getauscht. Um diese Operation nur als vermittelnde Instanz durch-
zuführen, assoziiert das Gateway den ursprünglichen Port mit dem übersetzten Port und
der IP. Dieser Zusammenhang wird abgespeichert, um die Kommunikation bidirektional
durchführen zu können.
Abb. 19: Übersicht NAT Prozess; Ein Paket, welches an ein Netzwerk außerhalb des Host Netzwerkes gerichtet ist,
wird an das Standardgateway gesendet (1). Unter Verwendung des IPv4 Standards wird mithilfe von NAT die Über-
setzung von mehreren internen IP Adressen zu einer externen IP gewährleistet. Dies erfolgt mithilfe der Übersetzung
von Ports und der IP. Eine durchgeführte Übersetzung wird in einer Assoziationsmatrix abgelegt. Mit dieser kann eine
eindeutige Assoziation der einzelnen Kommunikationskanäle gewährleistet werden. Ferner kann mit diesem System
eine Vielzahl von Hosts in das externe Netzwerk kommunizieren. Wird eine Antwort auf das Paket, welches übersetz
wurde, erhalten, erfolgt die Rückübersetzung in das interne Netzwerk (2). In diesem Schritt wird die ursprüngliche
Quell IP und Port in das Paket gesetzt.
Die Umsetzung in die Bearbeitung mit Flows und SDN erforderte eine erweiterte Prüfung
und Verarbeitung der Informationen, welche die Pakete bereitstellen. Hosts des internen
Netzwerkes, 10.0.0.0/8, können Anfragen in andere Netze stellen. Basierend auf dem
VLAN Tag des jeweiligen Paketes wird über einen der Flows aus Zeile zwei und drei,
siehe Code 7 die passende Flow Table ausgewählt. In dieser wird, ohne das Bestehen
anderer Flows, welche einen Match erzielen, das Paket an den Controller weitergeleitet.
Die Verarbeitung der Pakete durch den Controller resultiert in drei Flows. Diese drei
Flows werden nach einer erfolgreichen Verarbeitung gleichzeitig hinzugefügt. Dabei
wird ein Flow für den Ingress des jeweiligen Paketes mit einer VID verwendet. Dieser
entfernt das VLAN Tag und leitet das Paket in die NAT Flow Table weiter. Das Krite-
rium, welches die Anwendung des Flows zur Folge hat, besteht aus der dazugehörigen
VID sowie Quell MAC und Ziel IP des Paketes, siehe Code 9.
39
1. ~# ovs-ofctl -O OpenFlow15 dump-flows tldsw0
2. cookie=0x15, duration=52.149s, table=1, n_packets=6, n_bytes=579,
idle_timeout=60, send_flow_rem idle_age=2, priority=5,
ip,in_port=1,dl_vlan=1,dl_src=00:00:00:00:00:01,nw_dst=192.168.2.38
actions=pop_vlan,goto_table:3
Code 9: Ausgabe der Flows in Flow Table eins tldsw0 gekürzt; Flow für die Weiterleitung in die NAT Flow Table.
Dieser Flow entfernt den VLAN Header und leitet das Paket in die Flow Table drei weiter. In diesem Fall wird von h1
zu einem Gerät im 192.168.2.0/24 Netz eine Anfrage an einen Webserver ausgeführt.
Die letzten beiden Flows werden in der NAT Flow Table abgespeichert. Diese beiden
beschreibt die Modifikation des Paketes. Mit dieser wird die NAT Funktion realisiert. Ein
Flow wird für das Paket, welches aus der VLAN Flow Table übermittelt wird, genutzt. In
diesem wird der Wechsel der Quell-IP und Port durchgeführt. In Code 9 bis Code 11 wird
ein Beispiel einer Kommunikation zwischen h1, 10.0.0.1, und einem Webserver,
192.168.2.38, gezeigt.
1. ~# ovs-ofctl -O OpenFlow15 dump-flows tldsw0
2. cookie=0x15, duration=52.149s, table=3, n_packets=6, n_bytes=579,
idle_timeout=61, send_flow_rem idle_age=51, priority=5,
tcp,dl_src=00:00:00:00:00:01,nw_dst=192.168.2.38,tp_src=9422,tp_dst=80
actions=
set_field:8c:ae:4c:e9:c5:c7->eth_src,
set_field:00:25:bc:e6:d7:7a->eth_dst,dec_ttl,
set_field:192.168.2.200->ip_src,set_field:49151->tcp_src,output:5
Code 10: Flow für den Austausch der IP und Port für die Weiterleitung;
Der Austausch der Quell-IP und Port wird in Code 10 aufgeführt. Ein Match dieses Flows
trifft bei diesem Austausch von Paketen über TCP statt. Eine weitere Spezifikation des
Flows erfolgt auf Basis der IP und Port für Quelle und Ziel. Durch diese detaillierte De-
finierung wird ein Kommunikationskanal eindeutig beschrieben. Eine Ausgabe des Pa-
ketes erfolgt über den spezifizierten NAT Port. Zudem wird die TTL dekrementiert um
eins.
1. ~# ovs-ofctl -O OpenFlow15 dump-flows tldsw0
2. cookie=0x15, duration=52.149s, table=3, n_packets=8, n_bytes=889,
idle_timeout=62, send_flow_rem idle_age=51, priority=5,
tcp,nw_src=192.168.2.38,nw_dst=192.168.2.200,tp_src=80,tp_dst=49151
actions=
dec_ttl,
set_field:00:00:00:10:10:10->eth_src,
set_field:00:00:00:00:00:01->eth_dst,
push_vlan:0x8100,set_field:4097->vlan_vid,
set_field:10.0.0.1->ip_dst,set_field:9422->tcp_dst,output:1
Code 11: Flow für das Rückübersetzen der Parameter IP und Port des Paketes; Dieser Flow verändert die IP, Port
und die MAC Adresse. Durch diese Veränderung kann der Host die Pakete zuordnen. In Code 10 wird die Veränderung
des Portes und der IP aufgezeigt. Zudem wird das Frame um einen VLAN Frame mit der zugehörigen VID erweitert.
40
Code 11 zeigt die Rückübersetzung des Traffic zu den ursprünglichen Werten des Pa-
ketes. Zudem wird ein VLAN Tag hinzugefügt und über den Port, an dem das Paket in
den Switch eingetreten ist, gesendet.
41
Kapitel 5
Ergebnisse
5.1 Einleitung
Nach den Kapiteln 3 „Grundlagen“ und 4 „Lösung“, welche Methodik, Topologie und
Flow Bildung erörtern, werden in diesem Kapitel die Ergebnisse aufgezeigt, welche mit
SDN erzielt worden sind. Dazu gehört die Implementierung von IEEE 802.1Q VLAN,
die Übersetzung von Netzwerkadressen mit NAT und grundlegende Mechanismen wie
ARP und ICMP Ping Anfragen.
5.2 802.1Q VLAN
Von Hosts gesendete Pakete werden in Distribution Switches um einen VLAN-Header
erweitert. Diese Erweiterung der Pakete erfolgt beim Austreten über einen Trunk Port.
Die Übermittlung von Paketen zwischen der Distribution Ebene und dem Top Level
Switch findet mit 802.1Q erweiterten Paketen statt. Jedes Paket, welches nicht mit einem
VLAN Frame empfangen wird, wird durch den Top Level Switch verworfen. Dies betrifft
jedoch nicht Frames, welche von außen, nach einer Erstellung von NAT Flows, an diesem
Interface empfangen werden.
Die Kommunikation von Host h1 zu h5, welche sich im gleichen VLAN befinden, wird
in Abb. 20 aus der Sicht von h1 dargestellt. Die Implementierung sieht vor, dass ein Host
keinerlei Pakete mit einem 802.1Q Header erhält.
Abb. 20: Wireshark Capture Ping von h1 zu h5; Sicht des Hosts auf die Ping Anfrage. Der Host erhält Pakete aus-
schließlich ohne 802.1Q Frame.
Die Entfernung des Headers erfolgt vor der Übermittlung zu einem Host, in diesem Fall
h1. Für diesen Prozess wird über einen Flow der Befehl für das Entfernen des Headers
definiert und das Paket verändert.
42
Die Übermittlung der Ping Pakete wird in Abb. 21 aufgezeigt. Zunächst tritt ein Paket an
einem Access Port, s1-eth1, von Switch s1 ein (5). Das empfangene Paket stellt eine
ICMP Ping Anfrage dar. Das Paket wird mithilfe eines Flows modifiziert und erhält einen
VLAN Tag (7). Der Ausgangsport entspricht dem Trunk Port auf Switch s1, s1-eth5. Auf
diesem Port wird die Antwort auf die Anfrage erhalten (8). Zur Übermittlung an den Host
wird der 802.1Q Header entfernt und über das Interface s1-eth1 an den Host geleitet. Das
Entfernen und Hinzufügen des Headers kann der Spalte 802.1Q entnommen werden.
Abb. 21: Wireshark Capture Ping h1 zu h5 über Distribution Switch s1 Interfaces; Das Hinzufügen und Entfernen der
VLAN Header erfolgt durch die Distribution Switches.
Die Verteilung der Pakete an unterschiedliche Distribution Switches erfolgt über tldsw0,
den NAT Switch. In Abb. 22 wird zu der ICMP Ping Anfrage der initiale ARP Request
gezeigt. Dieser wird für die Abfrage der physischen MAC Adresse benötigt, wenn der
Host nur die logische IP Adresse kennt.
Abb. 22: Wireshark Capture einer Ping und ARP Anfrage zwischen h1 und h5; Durch das Mitlesen von Paketen auf
mehreren Interfaces werden Pakete doppelt angezeigt. Die Auflistung erfolgt im zeitlichen Zusammenhang. Dadurch
ist der erste Eintrag der Ingress des Paketes in den Switch und der zweite der Egress.
Die Auflistung der Pakete in Abb. 22 zeigt den Eingang und Ausgang der Pakete. Durch
diese spezielle Auflistung werden Pakete doppelt gezeigt, wobei der erste Eintrag den
Eingang des Paketes aufzeigt und der zweite Eintrag den Ausgang des Paketes. Zunächst
wird die Ping Anfrage empfangen (3) auf Port tldsw0-eth1. Anhand der Spalte 802.1Q ist
ersichtlich, dass das Paket die VID eins trägt. Das Ziel der Anfrage ist erreichbar durch
tldsw0-eth2. Somit wird die Weiterleitung durchgeführt (8). Eine Antwort der Anfrage
wird über den Port, an dem die Anfrage in den Switch einging, übermittelt (4).
43
5.3 Flow Table
Flow Tables stellen im SDN eine zentrale Rolle für eine dynamische Beschreibung und
Lenkung der Pfade innerhalb von Netzwerken. In den nachfolgenden Unterpunkten des
Kapitels wird auf die erstellten Flows eingegangen und werden diese erläutert.
5.3.1 Distribution Switches
Die Hauptaufgabe der Distribution Switche ist, wie in 4.2 Topologie beschrieben, die
Anbindung von Hosts an das Netzwerk. Die Konfiguration und Assoziation zwischen den
Ports und dem zugeordneten VLAN Tags wird durch den Ryu Controller erzielt. Dieser
übermittelt die Flows für die Steuerung. Mit dem Befehl pingall, Code 12, in der Mininet
CLI wird ein Ping auf jeden Host von jedem ausgeführt. Dadurch kann eine Evaluierung
der VLAN Umsetzung stattfinden. Das Ergebnis des Pings wird in Code 12 als Termi-
nal-Ausgabe und in Tab. 10 aufgearbeitet visualisiert.
1. mininet> pingall
2. *** Ping: testing ping reachability
3. h1 -> h2 X X h5 X h7 h8 h9
4. h2 -> h1 X X h5 X h7 h8 h9
5. h3 -> X X h4 X h6 X X X
6. h4 -> X X h3 X h6 X X X
7. h5 -> h1 h2 X X X h7 h8 h9
8. h6 -> X X h3 h4 X X X X
9. h7 -> h1 h2 X X h5 X h8 h9
10. h8 -> h1 h2 X X h5 X h7 h9
11. h9 -> h1 h2 X X h5 X h7 h8
12. *** Results: 50% dropped (36/72 received)
Code 12: Terminal Ausgabe des pingall Befehl in der Mininet CLI;
Ziel
Quelle h1 h2 h3 h4 h5 h6 h7 h8 h9
h1 - ✓ - - ✓ - ✓ ✓ ✓
h2 ✓ - - - ✓ - ✓ ✓ ✓
h3 - - - ✓ - ✓ - - -
h4 - - ✓ - - ✓ - - -
h5 ✓ ✓ - - - - ✓ ✓ ✓
h6 - - ✓ ✓ ✓ - - - -
h7 ✓ ✓ - - ✓ - - ✓ ✓
h8 ✓ ✓ - - - - - - -
h9 ✓ ✓ - - ✓ - ✓ ✓ -
44
Tab. 10: Ergebnis "pingall" im Netzwerk; Werte der Hauptdiagonale, grau gekennzeichnet, sind außer Acht gelassen,
da es sich um den gleichen Host handelt. Übersicht der einzelnen Ping Ergebnisse.
Das Ergebnis zeigt im Zusammenhang mit Tab. 9: Port-Konfiguration der SDN Switches,
dass die Umsetzung und Erreichbarkeit der einzelnen Teilnehmer des Netzes auf die kon-
figurierte VLAN Bereiche beschränkt ist.
Durch die Ausführung des Befehles pingall werden Ping Anfragen über das Netzwerk
gesendet. Dies führt dazu, dass Table Miss Events ausgelöst werden. Als Resultat werden
Anfragen an den Controller gestellt, welcher auf der Basis der Konfiguration Flows für
die Bearbeitung auf den Switches erstellt. In Code 13 ist die Ausgabe der Flow Tables
von s1 zu sehen. Die Verarbeitung erfolgt nach dem Pipeline Prozess, welcher in Kapitel
4.3.2 erörtert wurde. Dabei werden direkt verbundene Hosts ohne ein Hinzufügen eines
VLAN Headers direkt übermittelt (Zeile 14f.). Pakete, welche für Hosts adressiert sind,
die welche sich nicht direkt am Switch befinden, erhalten einen VLAN Tag und werden
über den Trunk Port des Switches weitergeleitet (ab Zeile vier bis 13). Ferner werden
Pakete, welche über einen Trunk Port empfangen werden, an Hosts nach dem Entfernen
des VLAN Headers weitergeleitet (Flow Table 1: Zeile 17-19, Flow Table 2: 20f.).
1. ~# ovs-ofctl -O OpenFlow15 dump-flows s1
2. …, table=0, …, idle_age=1, dl_vlan=1 actions=goto_table:1
3. …, table=0, …, dl_vlan=2 actions=goto_table:2
4. …, table=0, …, send_flow_rem idle_age=50, priority=21,
in_port="s1-eth1",dl_dst=00:00:00:00:00:05
actions=push_vlan:0x8100,set_field:4097->vlan_vid,output:"s1-eth5"
5. …, table=0, …, idle_timeout=60, send_flow_rem, …, priority=21,
in_port="s1-eth2",dl_dst=00:00:00:00:00:05
actions=push_vlan:0x8100,set_field:4097->vlan_vid,output:"s1-eth5"
6. …, table=0, …, idle_timeout=60, send_flow_rem idle_age=23,
priority=21,
in_port="s1-eth2",dl_dst=00:00:00:00:00:07
actions=push_vlan:0x8100,set_field:4097->vlan_vid,output:"s1-eth5"
7. …, table=0, …, idle_timeout=60, send_flow_rem idle_age=35,
priority=21,
in_port="s1-eth3",dl_dst=00:00:00:00:00:06
actions=push_vlan:0x8100,set_field:4098->vlan_vid,output:"s1-eth5"
8. …, table=0, …, idle_timeout=60, send_flow_rem idle_age=40,
priority=21,
in_port="s1-eth4",dl_dst=00:00:00:00:00:06
actions=push_vlan:0x8100,set_field:4098->vlan_vid,output:"s1-eth5"
9. …, table=0, …, idle_timeout=60, send_flow_rem idle_age=23,
priority=21,
in_port="s1-eth1",dl_dst=00:00:00:00:00:07
actions=push_vlan:0x8100,set_field:4097->vlan_vid,output:"s1-eth5"
10. …, table=0, …, idle_timeout=60, send_flow_rem idle_age=14,
priority=21,
in_port="s1-eth1",dl_dst=00:00:00:00:00:08
actions=push_vlan:0x8100,set_field:4097->vlan_vid,output:"s1-eth5"
45
11. …, table=0, …, idle_timeout=60, send_flow_rem, …, priority=21,
in_port="s1-eth2",dl_dst=00:00:00:00:00:08
actions=push_vlan:0x8100,set_field:4097->vlan_vid,output:"s1-eth5"
12. …, table=0, …, idle_timeout=60, send_flow_rem, …, priority=21,
in_port="s1-eth1",dl_dst=00:00:00:00:00:09
actions=push_vlan:0x8100,set_field:4097->vlan_vid,output:"s1-eth5"
13. …, table=0, …, idle_timeout=60, send_flow_rem, …, priority=21,
in_port="s1-eth2",dl_dst=00:00:00:00:00:09
actions=push_vlan:0x8100,set_field:4097->vlan_vid,output:"s1-eth5"
14. …, table=0, …, idle_timeout=60, send_flow_rem, …, priority=16,
in_port="s1-eth1",dl_src=00:00:00:00:00:01, dl_dst=00:00:00:00:00:02
actions=output:"s1-eth2"
15. …, table=0, …, idle_timeout=60, send_flow_rem, …, priority=16,
in_port="s1-eth2",dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:01
actions=output:"s1-eth1"
16. …, table=0, …, priority=1 actions=CONTROLLER:65535
17. …, table=1, …, idle_timeout=60, send_flow_rem, …, priority=21,
dl_vlan=1,dl_dst=00:00:00:00:00:01
actions=pop_vlan,output:"s1-eth1"
18. …, table=1, …, idle_timeout=60, send_flow_rem, …, priority=21,
dl_vlan=1,dl_dst=00:00:00:00:00:02
actions=pop_vlan,output:"s1-eth2"
19. …, table=1, …, priority=1,dl_vlan=1 actions=CONTROLLER:65535
20. …, table=2, …, idle_timeout=60, send_flow_rem idle_age=35,
priority=21,dl_vlan=2,dl_dst=00:00:00:00:00:03
actions=pop_vlan,output:"s1-eth3"
21. …, table=2, …, idle_timeout=60, send_flow_rem priority=21,
dl_vlan=2,dl_dst=00:00:00:00:00:04
actions=pop_vlan,output:"s1-eth4"
22. …, table=2, …, priority=1,dl_vlan=2 actions=CONTROLLER:65535
Code 13: Ausgabe der Flow Tables von s1 nach einem vollen Topologie Ping; Die Flows werden in die Pipeline Ta-
bellen abgelegt. In Table 0 werden Flows für den Netzzugang abgelegt. Dies umfasst die direkte Kommunikation zwi-
schen Hosts, welche im gleichen VLAN sind, und die Bearbeitung für das Senden über den Trunk Port des Switches.
Korrespondierend zu der Konfiguration, wird die VID zum VLAN Header hinzugefügt. Ferner werden Pakete, die über
den Trunk Port empfangen wurden, in der zugehörigen Flow Table verändert und über die Access Ports an den Host
weitergeleitet.
Zusätzlich wird die Bearbeitungsgeschwindigkeit durch die Verwendung von Flows er-
höht. Dies zeigt sich durch die Reduktion der Dauer für einen Ping zwischen h1 und h5,
siehe Code 14.
1. mininet> h1 ping h2
2. PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
3. 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=20.8 ms
4. 64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.390 ms
5. 64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.130 ms
6. 64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.073 ms
7. …
8. --- 10.0.0.2 ping statistics ---
9. 8 packets transmitted, 8 received, 0% packet loss, time 88ms
46
10. rtt min/avg/max/mdev = 0.067/2.746/20.822/6.832 ms
Code 14: Ausgabe Ping zwischen h1 und h2; Reduktion der benötigten Zeit der Anfragen nach Hinzufügen der Flows
und der Verarbeitung im Kernel Modul von Open vSwitch
5.3.2 NAT Switch
Der NAT Switch, tldsw0, ist für die Verteilung der Pakete zwischen den einzelnen Dis-
tribution Switches zuständig. Die Übermittlung an einen spezifischen Port wird durch die
Auswertung der enthaltenen VLAN ID des Paketes ermöglicht. Für die Erstellung eines
Flows wird die Ziel MAC Adresse mit den gesammelten Informationen der Topologie
verglichen. Anhand dieser wird der Ziel-Port gewählt mit einer zusätzlichen Überprüfung
der Quell VID und der konfigurierten VLAN IDs an diesem Port. Ist die Quell VID kor-
respondierend mit der Konfiguration kann die Verteilung der Pakete erfolgen. Die Aus-
gabe der Flow Tables ist in Code 15 dargestellt. Dabei werden die Flows für die jeweilige
VLAN ID in der Table der gleichen ID dargestellt. Ferner werden diese Flows ausschließ-
lich auf Paketen des internen Traffics angewendet.
1. …, table=0, …, dl_vlan=1 actions=goto_table:1
2. …, table=0, …, dl_vlan=2 actions=goto_table:2
3. …, table=1, …, idle_timeout=120, …, priority=21,
dl_dst=00:00:00:00:00:01 actions=output:"tldsw0-eth1"
4. …, table=1, …, idle_timeout=120, …, priority=21,
dl_dst=00:00:00:00:00:05 actions=output:"tldsw0-eth2"
5. …, table=1, …, idle_timeout=120, …, priority=21,
dl_dst=00:00:00:00:00:07 actions=output:"tldsw0-eth3"
6. …, table=1, …, idle_timeout=120, …, priority=21,
dl_dst=00:00:00:00:00:08 actions=output:"tldsw0-eth3"
7. …, table=1, …, idle_timeout=120, …, priority=21,
dl_dst=00:00:00:00:00:09 actions=output:"tldsw0-eth4"
8. …, table=1, …, idle_timeout=120, …, priority=21,
dl_dst=00:00:00:00:00:02 actions=output:"tldsw0-eth1"
9. …, table=1, …, priority=1,dl_vlan=1 actions=CONTROLLER:65535
10. …, table=2, idle_timeout=120, …, priority=21,
dl_dst=00:00:00:00:00:03 actions=output:"tldsw0-eth1"
11. …, table=2, idle_timeout=120, …, priority=21,
dl_dst=00:00:00:00:00:06 actions=output:"tldsw0-eth2"
12. …, table=2, idle_timeout=120, …, priority=21,
dl_dst=00:00:00:00:00:04 actions=output:"tldsw0-eth1"
13. …, table=2, idle_age=0, priority=1,dl_vlan=2 actions=CONTROLLER:65535
14. …, table=3, idle_age=0, priority=1,arp actions=CONTROLLER:65535
15. …, table=3, idle_age=4104, priority=1, icmp,nw_dst=192.168.2.200,
icmp_type=8 actions=CONTROLLER:65535
Code 15: Ausgabe der Flow Tables von tldsw0 nach Topologie Ping; Flow Tables nach der Ausführung des Komman-
dos pingall. Blau markierte Einträge stehen für Flows des ersten VLANs, grün markierte für Flows des zweiten VLANs.
47
Für eine Kommunikation außerhalb eines Netzes, in dem der Host sich befindet, wird
eine Anfrage an das Standardgateway gestellt. Hierfür benötigt der Teilnehmer des Net-
zes eine MAC Adresse, an die dieser die Anfrage stellt. Hierzu wird ein Flow für die
Antwort der ARP-Anfragen pro VLAN, nach einmaliger Anfrage eines Hosts, als Flow
abgespeichert. Der Flow gestaltet sich gegenüber anderen, für die NAT Übersetzung Spe-
zifischen, allgemein. In Code 16 wird dieser für das erste VLAN gezeigt (Zeile 5). Ein
Eintrag für das zweite VLAN wird das Übereinstimmungskriterium auf zwei gesetzt.
1. ~# ovs-ofctl -O OpenFlow15 dump-flows tldsw0
2. …, table=0, dl_vlan=1 actions=goto_table:1
3. …, table=0, dl_vlan=2 actions=goto_table:2
4. …, table=0, …, priority=3,in_port=5 actions=goto_table:3
5. …, table=1, …, priority=32,arp,dl_vlan=1,
arp_tpa=10.1.1.1,arp_op=1
actions=
move:NXM_OF_ETH_SRC[]->NXM_OF_ETH_DST[],
set_field:00:00:00:10:10:10->eth_src,
move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],
set_field:10.1.1.1->arp_spa,
move:NXM_NX_ARP_SHA[0..31]->NXM_NX_ARP_THA[0..31],
set_field:00:00:00:10:10:10->arp_sha,set_field:2->arp_op,
set_field:10.1.1.1->arp_spa,IN_PORT
6. …, table=1, …, priority=1,dl_vlan=1 actions=CONTROLLER:65535
7. …, table=2, …, priority=1,dl_vlan=2 actions=CONTROLLER:65535
8.
9. cookie=0x0, duration=963.358s, table=3, n_packets=11091,
n_bytes=687642, idle_age=0, priority=1,arp actions=CONTROLLER:65535
10. cookie=0x0, duration=963.357s, table=3, n_packets=3, n_bytes=300,
idle_age=4104, priority=1,icmp,nw_dst=192.168.2.200,icmp_type=8
actions=CONTROLLER:65535
Code 16: Ausgabe der Flows nach ARP Request an das Standardgateway; Der Flow, der eine Erstellung von Antworten
auf ARP-Anfragen des Standardgateways ist blau markiert. Actions, welche ein 'move' Befehl vor der eigentlichen
Aktion stehen haben, kopieren Werte des empfangenen Paketes in das neu erstellte oder weiterzuleitende Paket.
Mit der Beantwortung der ARP-Anfragen von Hosts wird es ermöglicht, dass Clients Pa-
kete an das Standardgateway adressieren. Für die Überprüfung, dass das Interface des
NAT Switches, welches in das externe Netz eingebunden ist, erreichbar ist, wird eine
Ping-Anfrage gestartet. In Abb. 23 wird ein erfolgreiches Ping Ergebnis gezeigt.
Abb. 23: Ping-Anfrage auf das externe Interface des NAT Switches;
48
Das Ergebnis der NAT Funktion wird mit einem wget Kommando im Linux Terminal
validiert. Unter der Verwendung des Kommandos wird eine http get Anfrage erstellt.
Diese Anfrage wird im Nachfolgenden genutzt, um die Erstellung und Bedeutung der
erstellen Flows zu erläutern. Mit Host h1 wird der Befehl „wget 192.168.2.38“ abgesetzt.
Nach dem Absetzen des Befehls werden Pakete auf der Netzwerkschicht an das Standard-
gateway adressiert. Eine http Verbindung verwendet zur Übermittlung von Daten als
Transportprotokoll TCP. Das erste Paket des Threeway Handshakes geht dabei verloren
und wird erneut übermittelt. Dieses Verhalten ist durch die Verarbeitung des Paketes und
der resultierenden Flow-Erstellung bedingt. Die Adressierung an das Standardgateway ist
in Abb. 24 durch die Markierung des ersten Frames ersichtlich. Die Abbildung stellt die
Pakete dar, welche von h1 gesendet und empfangen werden.
Abb. 24: NAT Netzwerkkommunikation h1 unter Verwendung von http; Clientsicht auf den Ablauf einer TCP Kommu-
nikation unter Verwendung des Anwendungsprotokolls http. Die Anfrage wird an einen Server außerhalb des Quell-
netzes gestellt. Somit wird eine vermittelnde Instanz nötig.
Abb. 25 zeigt den Traffic, welcher den NAT Switch passiert. Eine Netzwerkübersetzung
wird dabei durchgeführt. Pakete des internen Netzwerkes werden über tldsw0-eth1 emp-
fangen. Das initiale Paket, welches den Threeway Handshake initiiert, löst in dem Fall,
dass kein Flow vorhanden ist, ein Table Miss Event aus. Während der Verarbeitung des
Paketes werden zudem drei Flows erstellt, welche die Übersetzung innerhalb des Swit-
ches ermöglichen.
49
Abb. 25: Traffic zwischen internem und externem Netzwerk über tldsw0; "Routersicht" auf den Ablauf der TCP Kom-
munikation aus Abb. 24. Der Traffic wurde von tldsw0 aus aufgenommen. Ein Austausch der IP und Port der ursprüng-
lichen Nachricht (15) durch einen freien Port und der IP (18) des externen Interfaces wird ein NAT Prozess.
Die NAT ersetzt die Quell IP und Port zu der IP, welche die NIC im externen Netzwerk
zugeteilt bekommen hat. Für die Ersetzung des ursprünglichen Portes wird eine Tabelle
intern des Controllers gepflegt, welche die Verwendeten dokumentiert. Wie in Abb. 25
zu sehen, wurde die Ursprungs IP (15), 10.0.0.1, zur IP (18) des externen Interfaces,
192.168.2.200, übersetzt. Ferner wird der Quell-Port von 54992 auf den Wert 49151 ge-
setzt. Die Übermittlung des veränderten Paketes erfolgt über das externe Interface (18).
Die Rückübersetzung der Antwort (19) erfolgt mit der Ersetzung der IP und Port (35)
durch die ursprünglichen Informationen des Sockets (15). Ferner wird für die Verteilung
in das interne Netz ein VLAN Header hinzugefügt mit der VID, mit dem das initiale Paket
empfangen wurde.
Diese Aktionen werden, durch die Entscheidung des Controllers über eine Verwendung
der genutzten Parameter für die Übermittlung und den Pipelineprozess innerhalb des
Switches, durch Flows beschrieben und unterstützt. Für die Verarbeitung im Pipelinepro-
zess werden für jede Verbindung in das externe Netzwerk drei Flows erstellt.
Die anschließende Ausgabe der Flow Tables, Code 17, lässt diese Flows erkennen. Für
die Verarbeitung und Übersetzung des Paketes in ein externes Netzwerk wird zunächst
der VLAN Header entfernt. Eine weitere Veränderung der Parameter erfolgt in der NAT
Table. Dazu wird das Paket nach dem Entfernen an Table drei übermittelt. Der gelb mar-
kierte Flow in Code 17 führt diese Aktionen durch. Ein Austausch der Header Parameter,
welche für die Übersetzung in das externe Netz benötigt werden, wird mit dem blau mar-
kierten Flow durchgeführt. Dieser tauscht die Quell IP und Port aus und übermittelt das
Paket in das Netz über das NAT Interface. Antworten aus dieser Übersetzung benötigen
zudem ein Einsetzen der Ursprungswerte aus der Nachricht. Ohne diese Veränderung
könnte der Host diese Daten zu keiner Applikation zuordnen. Diese Rückübersetzung
erfolgt mit dem grün markierten Flow.
50
1. ~# ovs-ofctl -O OpenFlow15 dump-flows tldsw0
2. …, table=0, …, dl_vlan=1 actions=goto_table:1
3. …, table=0, …, dl_vlan=2 actions=goto_table:2
4. …, table=0, …, priority=3,in_port=5 actions=goto_table:3
5. …, table=1, …, priority=32,arp,dl_vlan=1,arp_tpa=10.1.1.1,arp_op=1
actions=move:NXM_OF_ETH_SRC[]-
>NXM_OF_ETH_DST[],set_field:00:00:00:10:10:10-
>eth_src,move:NXM_OF_ARP_SPA[]->NXM_OF_ARP_TPA[],set_field:10.1.1.1-
>arp_spa,move:NXM_NX_ARP_SHA[0..31]-
>NXM_NX_ARP_THA[0..31],set_field:00:00:00:10:10:10-
>arp_sha,set_field:2->arp_op,set_field:10.1.1.1->arp_spa,IN_PORT
6. …, table=1, …, priority=6,icmp,dl_vlan=1,nw_dst=10.1.1.1,icmp_type=8
actions=move:NXM_OF_ETH_SRC[]-
>NXM_OF_ETH_DST[],set_field:00:00:00:10:10:10-
>eth_src,move:NXM_OF_IP_SRC[]->NXM_OF_IP_DST[],set_field:10.1.1.1-
>ip_src,set_field:0->icmp_type,IN_PORT
7. …, table=1, …, idle_timeout=60, send_flow_rem, priority=5,
ip,in_port=1,dl_vlan=1,dl_src=00:00:00:00:00:01,nw_dst=192.168.2.38
actions=pop_vlan,goto_table:3
8. …, table=1, …, priority=1,dl_vlan=1 actions=CONTROLLER:65535
9. …, table=2, …, priority=1,dl_vlan=2 actions=CONTROLLER:65535
10. …, table=3, …, idle_timeout=61, send_flow_rem, priority=5,
tcp,dl_src=00:00:00:00:00:01,nw_dst=192.168.2.38,tp_src=54992,
tp_dst=80 actions=
set_field:8c:ae:4c:e9:c5:c7->eth_src,
set_field:00:25:bc:e6:d7:7a->eth_dst,
dec_ttl,set_field:192.168.2.200->ip_src,
set_field:49151->tcp_src,output:5
11. …, table=3, …, idle_timeout=62, send_flow_rem, priority=5,
tcp,nw_src=192.168.2.38,nw_dst=192.168.2.200,tp_src=80,tp_dst=49151
actions=dec_ttl,set_field:00:00:00:10:10:10-
>eth_src,set_field:00:00:00:00:00:01-
>eth_dst,push_vlan:0x8100,set_field:4097->vlan_vid,set_field:10.0.0.1-
>ip_dst,set_field:54992->tcp_dst,output:1
12. …, table=3, …, priority=1,arp actions=CONTROLLER:65535
13. …, table=3, …, priority=1,icmp,nw_dst=192.168.2.200,icmp_type=8
actions=CONTROLLER:65535
Code 17: Ausgabe der Flow Tables von tldsw0 nach TCP Kommunikation; Eine Entfernung des VLAN Tags vor der
weiteren Verarbeitung des Paketes findet in der zugehörigen Flow Table statt. Der Flow für diese Operation ist in Gelb
markiert. Ohne VLAN Header wird das Paket an die NAT Table übergeben. In dieser werden die Flows für den Über-
setzungsprozess abgelegt. Der Flow, welcher in Blau markiert ist, ermöglicht die Übersetzung für den Egress der
Pakete, wohingegen der grüne Flow die Rückübersetzung durchführt.
Durch Erstellung der Flows wird die Kommunikation aus Abb. 24 und Abb. 25 ermög-
licht. Dadurch kann ein Host des internen Netzwerkes Ziele des externen Netzes erreichen
und Daten austauschen.
51
Kapitel 6
Zusammenfassung und Ausblick
6.1 Zusammenfassung
Die bisherige starre Umsetzung in der Netzwerktechnik wird durch eine neue, program-
mierbare und dynamische Architektur erweitert. SDN stellt ein neues architekturelles Pa-
radigma dar, welches hoch performante und dynamische Netze ermöglicht. In heutiger
Zeit erscheinen häufig Nachrichten bezüglich Cloud-Computing, Social Media und vie-
lem mehr. Diese Aufgaben erfordern neue Möglichkeiten in der Netzwerktechnik.
Im Rahmen dieser Arbeit wurde gezeigt, dass eine grundlegende Funktion wie die logi-
sche Unterteilung eines großen Netzwerkes in kleinere Netze mithilfe von VLANs mög-
lich ist. Die Vermittlung und Modifizierungen an Paketen ermöglichen einen Eingriff in
das Netzwerk, welcher in bisheriger Form nicht möglich ist. Dies ist möglich durch die
Aufteilung der Data- und Controlplane. Zusätzlich wird ein Steuerungsprotokoll, Open-
Flow in diesem Fall, dazu verwendet, um eine Beschreibung und programmsteuerbare
Modifizierung der Pfade innerhalb des Netzwerkes zu erreichen.
Zudem zeigt die Aufteilung der Controller, dass die Unterteilung in unterschiedliche Be-
reiche eine logische Trennung ermöglicht. Dadurch wird es möglich, dass Controller in
ihrer Komplexität aufzuteilen und Code zu erstellen, welcher sich durch eine höhere
Wartbarkeit und Wiederverwertbarkeit auszeichnet.
Ferner ist die Umsetzung eines Pipelineprozesses innerhalb der Geräte eine erweiterte
Funktion, welche sich durch eine logische Aufteilung von Teilaspekten der Weiterleitung
von Paketen hervorhebt, implementiert worden. Durch eine Aufteilung der Weiterleitung
ist es möglich, dass größere und komplexere Regeln in mehrere weniger komplexe Ver-
arbeitungsschritte aufgeteilt werden können. Die Aufteilung einer Verarbeitung kann
Fehleranfälligkeiten größerer Flows reduzieren.
Unter Verwendung einer Pipeline ist in dieser Arbeit die Umsetzung einer NAT Funktion
durchgeführt worden. Einzelne Aspekte der Verarbeitung sind in unterschiedliche Flow
Tables verteilt worden. Die Verarbeitung innerhalb des vermittelnden Switches ist unter-
teilt in die Verarbeitung interner Pakete zwischen den einzelnen Hosts und Paketen, wel-
che über die Netzwerkgrenze gesendet werden.
Abschließend lässt sich sagen, dass in den nächsten Jahren ein Paradigmenwechsel in der
Netzwerktechnik ansteht. Die Programmierbarkeit eines Netzes, welche durch SDN ge-
schaffen wird, ermöglicht eine Umsetzung von Netzen, welche gehärtet und robuster sind
als bisherige Lösungen. Durch die Verwendung von redundanten Controllern wird ein
Single Point of Failure vermieden.
52
6.2 Ausblick
Diese Arbeit zeigt, dass eine Implementierung netzwerktypischer Funktionen wie VLAN
und NAT im SDN möglich ist. Dabei werden jedoch nicht alle Aspekte heutiger Netz-
werke berücksichtigt. Der Kern dieser Arbeit bezieht sich im Wesentlichen auf die South-
bound Interaktion der Dataplane und deren Manipulation unter Verwendung von Open-
Flow. Eine Verwendung der Northbound Kommunikation zwischen Applikationsebene
und Controllerebene ermöglicht eine direkte Interaktion und Einflussnahme auf den SDN
Controller und somit auf die Netzwerkpfade. Daraus können weitere Faktoren wie QoS,
Loadbalancing und Mechaniken zur Kanalbündelung beeinflusst werden, um auf dyna-
mische Veränderungen innerhalb des Netzwerkes zu reagieren.
Ein großer Punkt einer weiteren Arbeit ist die dynamische Konfigurierbarkeit der Con-
troller. Verwendete Parameter für die Beschreibung der VLAN Eigenschaften sind fest
konfiguriert und müssen im Falle einer Rekonfiguration im Quellcode direkt verändert
werden. Dazu zählt die Erstellung von neuen VLANs und die Assoziation des spezifi-
schen VLANs zu einem Port. In der Software Defined Networking Architektur ist die
Verwendung von Representational State Transfer, REST, ein Bestandteil der Interaktion
zwischen den Softwarekomponenten. Die Implementierung einer Schnittstelle in den
Controller, unter Verwendung von REST, kann eine dynamische Konfiguration ermögli-
chen. Eine exemplarische Implementierung kann in den von Ryu bereitgestellten Klassen
nachvollzogen werden. REST stellt ein Programmierparadigma dar, welches in verteilten
Systemen Verwendung findet, z.B. in der Webtechnologie.
Unter der Verwendung von Docker und dem Mechanismus der Virtualisierung kann eine
Implementierung von Teilnetzen realisiert werden, mit der die Kopplung von SDN Do-
mänen untersucht werden kann. Die Kopplung beschreibt die Kommunikation der Data-
plane unter der East/West Kommunikation der SDN Controller in den unterschiedlichen
Domänen.
Ferner können weitere elementare Netzwerkkomponenten wie eine DHCP, DNS und er-
weiterte Routing Protokolle integriert werden.
53
Literatur
[1] K. Agouros, Software Defined Networking: SDN-Praxis mit Controllern und
OpenFlow®. Berlin, Boston: De Gruyter; De Gruyter Oldenbourg, 2017.
[2] G. Siegmund, SDN - Software-defined Networking: Software-defined Networking :
neue Anforderungen und Netzarchitekturen für performante Netze. Berlin,
Offenbach: VDE VERLAG GMBH, 2018.
[3] Cisco, Cisco Open SDN Controller. [Online] Verfügbar unter:
https://www.cisco.com/c/en/us/products/cloud-systems-management/open-sdn-
controller/index.html?dtid=osscdc000283. Zugriff am: Apr. 11 2019.
[4] Software-Defined Networking (SDN). [Online] Verfügbar unter:
https://www.cisco.com/c/de_de/solutions/software-defined-
networking/overview.html. Zugriff am: Apr. 11 2019.
[5] Software-Defined Networking (SDN) - Juniper Networks. [Online] Verfügbar unter:
https://www.juniper.net/us/en/products-services/sdn/. Zugriff am: Apr. 11 2019.
[6] J. Networks, NorthStar Controller. [Online] Verfügbar unter:
https://www.juniper.net/assets/us/en/local/pdf/datasheets/1000494-en.pdf. Zugriff
am: Apr. 11 2019.
[7] Broadcom, OpenNSL. [Online] Verfügbar unter:
https://www.broadcom.com/products/ethernet-connectivity/software/opennsl/.
Zugriff am: Apr. 11 2019.
[8] Broadcom, Software-Defined Networking (SDN) | Data Center Networking |
Applications | Broadcom. [Online] Verfügbar unter:
https://www.broadcom.com/applications/data-center/software-defined-networking/.
Zugriff am: Apr. 11 2019.
[9] Internet Egineer Task Force - IETF, RFC 2328 - OSPF Version 2. [Online]
Verfügbar unter: https://tools.ietf.org/pdf/rfc2328.pdf. Zugriff am: Apr. 02 2019.
[10] OpenFlow Switch Specification Version 1.5.1, 2015.
[11] G. Siegmund, SDN - Software-defined Networking // SDN: Software-defined
Networking : neue Anforderungen und Netzarchitekturen für performante Netze.
Berlin, Offenbach: VDE VERLAG GMBH, 2018.
[12] Open Networking Foundation, Open Networking Foundation is an operator led
consortium leveraging SDN, NFV and Cloud technologies to transform operator
networks and business models. [Online] Verfügbar unter:
https://www.opennetworking.org/. Zugriff am: Apr. 03 2019.
[13] „2. OpenFlow“ in Software Defined Networking, K. Agouros, Hg., Berlin, Boston:
De Gruyter, 2016.
[14] Linux Foundation, Open vSwitch. [Online] Verfügbar unter:
https://github.com/openvswitch/ovs. Zugriff am: Apr. 07 2019.
54
[15] „3. OpenFlow-Implementierungen“ in Software Defined Networking, K. Agouros,
Hg., Berlin, Boston: De Gruyter, 2016.
[16] Linux Foundation, What Is Open vSwitch? — Open vSwitch 2.11.90
documentation. [Online] Verfügbar unter:
http://docs.openvswitch.org/en/latest/intro/what-is-ovs/#overview. Zugriff am: Apr.
07 2019.
[17] J. Pettit und E. Lopez, OpenStack: OVS Deep Dive. [Online] Verfügbar unter:
https://www.openvswitch.org/support/slides/OpenStack-131107.pdf. Zugriff am:
Apr. 07 2019.
[18] Linux Foundation, Open vSwitch. [Online] Verfügbar unter:
https://buildmedia.readthedocs.org/media/pdf/openvswitch/latest/openvswitch.pdf.
Zugriff am: Apr. 02 2019.
[19] Linux Foundation, Open vSwitch Manual: ovs-vswitchd.conf.db(5). Linux
Foundation.
[20] VMware, VMware & Nicira: Software-Defined Networking Support. [Online]
Verfügbar unter: https://www.vmware.com/support/acquisitions/nicira.html.
Zugriff am: Apr. 09 2019.
[21] VMware NSX : Network Virtualization and Security Platform. [Online] Verfügbar
unter: https://www.vmware.com/products/nsx.html. Zugriff am: Apr. 09 2019.
[22] M. Lutz, Learning Python: Powerful Object-Oriented Programming. Sebastopol:
O'Reilly Media; O'Reilly Media, Inc, USA, 2013.
[23] J. Ernesti und P. Kaiser, Hg., Python 3: Das umfassende Handbuch, 4. Aufl. Bonn:
Rheinwerk Verlag GmbH, 2017.
[24] ryu development team, ryu Documentation: Release 4.30. [Online] Verfügbar
unter: https://media.readthedocs.org/pdf/ryu/latest/ryu.pdf.
[25] Mininet Team, Github Mininet Source. [Online] Verfügbar unter:
https://github.com/mininet/mininet. Zugriff am: Apr. 02 2019.
[26] R. Rosen und R. Rosen, Linux Kernel Networking: Implementation and Theory //
Linux Kernel networking: Implementation and theory. Berkeley, Calif.: Apress,
2014.
[27] B. Lantz, N. Handigol, B. Heller und V. Jeyakum, Mininet Wiki. [Online]
Verfügbar unter: https://github.com/mininet/mininet/wiki/Introduction-to-Mininet.
Zugriff am: Apr. 03 2019.
[28] Mininet Team, Download/Get Started with Mininet - Mininet. [Online] Verfügbar
unter: http://mininet.org/download/. Zugriff am: Apr. 02 2019.
[29] D. Vohra, Pro Docker. California: Apress; Distributed to the Book trade worldwide
by Springer Science+Business Media, 2016.
