Software Defined Networking (SDN) stellt einen ziemlichen Paradigmenwechsel im Netzwerkumfeld da. Heutige Netzwerke werden nach wie vor relativ statisch konfiguriert. Es gibt dynamische Routingprotokolle die dafür geschaffen wurden, Ausfälle zu erkennen und den Verkehr dann über andere Wege zu leiten. Den richtigen Lösungsweg zu finden, stellt sich aber teilweilse sehr komplex dar.

Außerdem werden die Geräte (Router, Switche, Firewalls) in der Regel einzeln konfiguriert. Einen neuen Datenpfad zu schaffen, erfordert daher von den Administratoren viele einzelne Arbeitsschritte, ein Fehler in einem dieser Schritte (z.B. ein Tippfehler in einer IP-Adresse) und der ganze Pfad funktioniert nicht.

Netzwerkgeräte haben in der Regel eine sogenannte Control Plane, welche die Steuerung übernimmt (welche Daten sollen wo lang fließen) und die Data Plane in welcher (häufig mit Hardwarebeschleunigung) aufgrund der Regeln der Control Plane die eigentlichen Daten fließen. Jedes Netzwerkgerät besitzt in der Regel eine eigene Control Plane und muss deswegen einzeln konfiguriert werden.

Die Idee hinter SDN ist nun, die Control Plane zu zentralisieren. Erst Konzepte stammen so etwa aus dem Jahr 2005 aus den USA. Ein zentraler Controller kann wesentlich „intelligentere“ Entscheidungen treffen, da er den Zustand des Gesamtnetzwerkes kennt. Über ein Steuerprotokoll kann er dann den Geräten Anweisungen geben, welche Pakete über welchen Pfad weiterzuleiten sind.

Damit sind wesentlich komplexere Entscheidungen möglich und auch das schnelle Umleiten von Verkehr ist möglich.

Das momentan marktführende Protokoll heißt OpenFlow und und wird von der Open Networking Foundation weiterentwickelt. Das wirklich interessante dabei ist, das in den neueren OpenFlow Versionen die Trennung der ISO-Schichten 2 – 4 eigentlich aufgeweicht wird und auch dies dazu beiträgt, dass durch komplexere Entscheidungen möglich sind.

Die Controller erlauben es, eigene Programme über ein Programmier-Interface einzuklinken und damit kann sich der Netzwerkadministrator vom statischen Netzwerk der Vergangenheit verabschieden und das Netzwerk wirklich programmieren.

Das Buch soll nach einer Einführung in die Theorie, die sich aber auf ein Kapitel SDN allgemein (viele Hersteller verkaufen unter SDN nur eine leicht flexiblere Konfigurierbarkeit Ihrer Komponenten) und einem Kapitel, welches den OpenFlow Standard erklärt (in seinen verschiedenen Versionen) dem Leser das Thema praktisch näherbringen. Dazu wird gezeigt, wie nur durch das „einschieben“ von Flows Regeln auf OpenFlow fähige Geräte gebracht werden können. Ein Kapitel wird sich mit den Möglichkeiten bzw. Limitierungen tatsächlich OpenFlow fähiger Geräte beschäftigen. Und schließlich führen wir in die APIs der beiden Controller Floodlight und OpenDayLight ein, damit der Leser danach seine eigenen Ideen mit diesen APIs umsetzen kann, um das eigene Netzwerk zu Programmieren.

Konstantin Agouros

Kaufen Sie hier:

Horizontale Tabs

Blick ins Buch

Inhaltsverzeichnis

Inhalt	7
Abbildungsverzeichnis	10
Vorwort	11
1 SDN-Theorie	13
1.1 Netzwerk Abstrakt	13
1.2 Routing-Protokolle	18
1.3 ConfigurationManagement	21
1.3.1 SNMP	22
1.3.2 NETCONF	24
1.4 Overlay-Netzwerke	29
1.4.1 Overlaymit GRE	30
1.4.2 Overlaymit VXLAN	31
1.4.3 MPLS	33
1.5 Open vSwitch Database (OVSDB)	34
2 OpenFlow	38
2.1 Die Struktur	38
2.1.1 Ports	40
2.1.2 Switch-Typen	42
2.1.3 Anmerkungen zumProtokoll	42
2.1.4 Flows und Flow-Tabellen	42
2.1.4.1 Matches	43
2.1.4.2 Counter	44
2.1.4.3 Instructions	48
2.1.4.4 Actions Sets und Action Lists	49
2.1.4.5 Actions	50
2.1.4.6 Groups	52
2.1.4.7 Meters	52
2.1.4.8 Queues	53
2.2 OpenFlow 1.0	53
2.3 OpenFlow 1.4 und 1.5	54
2.4 Flow Kochbuch	54
2.4.1 Layer 2	55
2.4.2 Routing	57
2.4.3 Firewalling	58
2.4.4 Address Translation	59
2.5 Fazit	60
3 OpenFlow-Implementierungen	61
3.1 Open vSwitch	61
3.1.1 Grundkonfiguration	61
3.1.2 STP	63
3.1.3 VLANs	63
3.1.4 Bonding/LAG	64
3.1.5 Overlay-Netze	65
3.1.6 „Interne Verkabelung“	65
3.1.7 Verschiedenes	66
3.1.8 OpenFlow	68
3.1.9 Mininet	71
3.2 PicOS	76
3.3 Juniper	77
3.4 Arista	80
3.5 Zodiac FX	81
4 Project Floodlight	83
4.1 Die Installation	83
4.2 Die grafische Weboberfläche	85
4.3 REST APIs von FloodLight	86
4.3.1 Static Flow Pusher	89
4.3.1.1 Matches	90
4.3.2 Instruktionen und Aktionen	95
4.3.2.1 Aktionen	95
4.3.3 Groups und Meters	102
4.4 EigeneModule entwickeln	102
4.4.1 Die Entwicklungsumgebung	102
4.4.2 HelloWorld in Floodlight	103
4.4.3 Die zweite Applikation	107
4.4.3.1 Das REST API	113
4.4.4 Pakete Lesen und Schreiben	121
4.4.4.1 Pakete Empfangen	121
4.4.4.2 Pakete Senden	126
4.4.4.3 Paketemanipulieren und weiterschicken	130
4.4.5 Gruppen undMeters	134
4.4.5.1 Gruppen	134
4.4.5.2 Meters	136
5 OpenDaylight	138
5.1 Architektur	138
5.2 Installation	139
5.3 REST-API	144
5.3.1 Flows für OpenFlow verwalten	146
5.3.1.1 Das Datenmodell	146
5.3.1.2 Filter / Matches	151
5.3.1.3 Instruktionen und Aktionen	157
5.3.1.4 Gruppen	167
5.3.1.5 Meters	168
5.3.2 BGP- und BGP-FlowSpec steuern	170
5.3.2.1 Einfügen und Löschen einer IPv4-Route	177
5.3.2.2 Einfügen und Löschen einer FlowSpec-Route	178
5.4 Eigene Applikationen in OpenDaylight integrieren	183
5.4.1 Hello World in OpenDaylight	184
5.4.2 Die zweite Applikation	191
5.4.2.1 Vorbereitende Arbeiten	191
5.4.2.2 Nodes	197
5.4.2.3 Flowverwaltung	201
5.4.2.4 Ein RPC für die Firewall-Regeln	209
5.4.2.5 MDSAL Data Store	223
5.4.3 Pakete lesen und schreiben	228
5.4.3.1 Pakete empfangen	229
5.4.3.2 Pakete einfügen	236
5.4.3.3 Pakete manipulieren und weiterschicken	250
5.4.3.4 Abschlussbemerkungenzur Applikationsentwicklung	261
A Filter und Aktionen bei Open vSwitch	263
A.1 Matches	263
A.2 Actions und Instructions	265
B Vollständige Klassendefinitionen	267
B.1 globalfirewall	267
B.2 FlowManagement	269
B.3 packetMagic erweiterteVersion	272
B.4 PacketMagicRestletRoutable erweiterte Version	274
B.5 packetMagic.java finale Version	275
C Glossar	278
Literatur	279
Stichwortverzeichnis	280