Software Defined Networking
Description
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.
Reviews / Votes
"Software-defined Networks schaffen Flexibilität, wollen allerdings auch richtig aufgesetzt und gepflegt werden. Mit seinem Buch 'Software Defined Networking" führt Konstantin Agouros die Leser in das Thema gekonnt ein. Der Fokus liegt klar auf OpenFlow sowie auf OpenDaylight. Für diese SDN-Lösungen erhalten Admins ein praktisches How-to, das sich aufgrund seiner kompakten Größe auch gut als Nachschlagewerk eignet."Daniel Richey in: it-administrator Dezember 2017, 102
More details
Other editions
Additional editions
Person
Konstantin Agouros
Content
2 - Abbildungsverzeichnis [Seite 10]
3 - Vorwort [Seite 11]
4 - 1 SDN-Theorie [Seite 13]
4.1 - 1.1 Netzwerk Abstrakt [Seite 13]
4.2 - 1.2 Routing-Protokolle [Seite 18]
4.3 - 1.3 ConfigurationManagement [Seite 21]
4.3.1 - 1.3.1 SNMP [Seite 22]
4.3.2 - 1.3.2 NETCONF [Seite 24]
4.4 - 1.4 Overlay-Netzwerke [Seite 29]
4.4.1 - 1.4.1 Overlaymit GRE [Seite 30]
4.4.2 - 1.4.2 Overlaymit VXLAN [Seite 31]
4.4.3 - 1.4.3 MPLS [Seite 33]
4.5 - 1.5 Open vSwitch Database (OVSDB) [Seite 34]
5 - 2 OpenFlow [Seite 38]
5.1 - 2.1 Die Struktur [Seite 38]
5.1.1 - 2.1.1 Ports [Seite 40]
5.1.2 - 2.1.2 Switch-Typen [Seite 42]
5.1.3 - 2.1.3 Anmerkungen zumProtokoll [Seite 42]
5.1.4 - 2.1.4 Flows und Flow-Tabellen [Seite 42]
5.1.4.1 - 2.1.4.1 Matches [Seite 43]
5.1.4.2 - 2.1.4.2 Counter [Seite 44]
5.1.4.3 - 2.1.4.3 Instructions [Seite 48]
5.1.4.4 - 2.1.4.4 Actions Sets und Action Lists [Seite 49]
5.1.4.5 - 2.1.4.5 Actions [Seite 50]
5.1.4.6 - 2.1.4.6 Groups [Seite 52]
5.1.4.7 - 2.1.4.7 Meters [Seite 52]
5.1.4.8 - 2.1.4.8 Queues [Seite 53]
5.2 - 2.2 OpenFlow 1.0 [Seite 53]
5.3 - 2.3 OpenFlow 1.4 und 1.5 [Seite 54]
5.4 - 2.4 Flow Kochbuch [Seite 54]
5.4.1 - 2.4.1 Layer 2 [Seite 55]
5.4.2 - 2.4.2 Routing [Seite 57]
5.4.3 - 2.4.3 Firewalling [Seite 58]
5.4.4 - 2.4.4 Address Translation [Seite 59]
5.5 - 2.5 Fazit [Seite 60]
6 - 3 OpenFlow-Implementierungen [Seite 61]
6.1 - 3.1 Open vSwitch [Seite 61]
6.1.1 - 3.1.1 Grundkonfiguration [Seite 61]
6.1.2 - 3.1.2 STP [Seite 63]
6.1.3 - 3.1.3 VLANs [Seite 63]
6.1.4 - 3.1.4 Bonding/LAG [Seite 64]
6.1.5 - 3.1.5 Overlay-Netze [Seite 65]
6.1.6 - 3.1.6 "Interne Verkabelung" [Seite 65]
6.1.7 - 3.1.7 Verschiedenes [Seite 66]
6.1.8 - 3.1.8 OpenFlow [Seite 68]
6.1.9 - 3.1.9 Mininet [Seite 71]
6.2 - 3.2 PicOS [Seite 76]
6.3 - 3.3 Juniper [Seite 77]
6.4 - 3.4 Arista [Seite 80]
6.5 - 3.5 Zodiac FX [Seite 81]
7 - 4 Project Floodlight [Seite 83]
7.1 - 4.1 Die Installation [Seite 83]
7.2 - 4.2 Die grafische Weboberfläche [Seite 85]
7.3 - 4.3 REST APIs von FloodLight [Seite 86]
7.3.1 - 4.3.1 Static Flow Pusher [Seite 89]
7.3.1.1 - 4.3.1.1 Matches [Seite 90]
7.3.2 - 4.3.2 Instruktionen und Aktionen [Seite 95]
7.3.2.1 - 4.3.2.1 Aktionen [Seite 95]
7.3.3 - 4.3.3 Groups und Meters [Seite 102]
7.4 - 4.4 EigeneModule entwickeln [Seite 102]
7.4.1 - 4.4.1 Die Entwicklungsumgebung [Seite 102]
7.4.2 - 4.4.2 HelloWorld in Floodlight [Seite 103]
7.4.3 - 4.4.3 Die zweite Applikation [Seite 107]
7.4.3.1 - 4.4.3.1 Das REST API [Seite 113]
7.4.4 - 4.4.4 Pakete Lesen und Schreiben [Seite 121]
7.4.4.1 - 4.4.4.1 Pakete Empfangen [Seite 121]
7.4.4.2 - 4.4.4.2 Pakete Senden [Seite 126]
7.4.4.3 - 4.4.4.3 Paketemanipulieren und weiterschicken [Seite 130]
7.4.5 - 4.4.5 Gruppen undMeters [Seite 134]
7.4.5.1 - 4.4.5.1 Gruppen [Seite 134]
7.4.5.2 - 4.4.5.2 Meters [Seite 136]
8 - 5 OpenDaylight [Seite 138]
8.1 - 5.1 Architektur [Seite 138]
8.2 - 5.2 Installation [Seite 139]
8.3 - 5.3 REST-API [Seite 144]
8.3.1 - 5.3.1 Flows für OpenFlow verwalten [Seite 146]
8.3.1.1 - 5.3.1.1 Das Datenmodell [Seite 146]
8.3.1.2 - 5.3.1.2 Filter / Matches [Seite 151]
8.3.1.3 - 5.3.1.3 Instruktionen und Aktionen [Seite 157]
8.3.1.4 - 5.3.1.4 Gruppen [Seite 167]
8.3.1.5 - 5.3.1.5 Meters [Seite 168]
8.3.2 - 5.3.2 BGP- und BGP-FlowSpec steuern [Seite 170]
8.3.2.1 - 5.3.2.1 Einfügen und Löschen einer IPv4-Route [Seite 177]
8.3.2.2 - 5.3.2.2 Einfügen und Löschen einer FlowSpec-Route [Seite 178]
8.4 - 5.4 Eigene Applikationen in OpenDaylight integrieren [Seite 183]
8.4.1 - 5.4.1 Hello World in OpenDaylight [Seite 184]
8.4.2 - 5.4.2 Die zweite Applikation [Seite 191]
8.4.2.1 - 5.4.2.1 Vorbereitende Arbeiten [Seite 191]
8.4.2.2 - 5.4.2.2 Nodes [Seite 197]
8.4.2.3 - 5.4.2.3 Flowverwaltung [Seite 201]
8.4.2.4 - 5.4.2.4 Ein RPC für die Firewall-Regeln [Seite 209]
8.4.2.5 - 5.4.2.5 MDSAL Data Store [Seite 223]
8.4.3 - 5.4.3 Pakete lesen und schreiben [Seite 228]
8.4.3.1 - 5.4.3.1 Pakete empfangen [Seite 229]
8.4.3.2 - 5.4.3.2 Pakete einfügen [Seite 236]
8.4.3.3 - 5.4.3.3 Pakete manipulieren und weiterschicken [Seite 250]
8.4.3.4 - 5.4.3.4 Abschlussbemerkungenzur Applikationsentwicklung [Seite 261]
9 - A Filter und Aktionen bei Open vSwitch [Seite 263]
9.1 - A.1 Matches [Seite 263]
9.2 - A.2 Actions und Instructions [Seite 265]
10 - B Vollständige Klassendefinitionen [Seite 267]
10.1 - B.1 globalfirewall [Seite 267]
10.2 - B.2 FlowManagement [Seite 269]
10.3 - B.3 packetMagic erweiterteVersion [Seite 272]
10.4 - B.4 PacketMagicRestletRoutable erweiterte Version [Seite 274]
10.5 - B.5 packetMagic.java finale Version [Seite 275]
11 - C Glossar [Seite 278]
12 - Literatur [Seite 279]
13 - Stichwortverzeichnis [Seite 280]
