Wer entscheidet, wohin ein Paket fließt?
Software-Defined Networking (SDN) trennt in einem Netzwerk die Entscheidung über den Weg eines Pakets vom Weiterleiten selbst. Dadurch steuert ein einziges Programm viele Switches, statt dass jemand jedes Gerät einzeln einrichtet.
Stellen Sie sich ein Rechenzentrum mit 200 Switches vor. Eine neue Regel für den Gastzugang müsste auf jedem Gerät stehen. Mit SDN ändern Sie sie an einer Stelle.
Am Ende dieser Lektion
Notiz
Ich kann sagen, was ein Controller entscheidet und was ein Switch tut.
Schlüsselwörter
| Begriff | Was er bedeutet | Beispiel |
|---|---|---|
| Switch | ein Gerät, das Pakete zwischen Kabeln weiterleitet | |
| Datenebene (Data Plane) | der Teil, der jedes Paket nach den Regeln weiterleitet | |
| Steuerungsebene (Control Plane) | der Teil, der entscheidet, welche Regeln gelten | |
| Controller | ein Programm, das die Regeln für Switches schreibt | |
| Flow | eine einzelne Regel in der Tabelle eines Switches | in_port=1 actions=output:2 |
| OpenFlow | die Sprache, in der Controller und Switch miteinander sprechen |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.
Ein Switch hat zwei verschiedene Aufgaben
Die erste Aufgabe heißt Weiterleiten. Ein Paket kommt an einem Port an, und der Switch schickt es an einem anderen Port wieder hinaus. Das geschieht bei jedem Paket und dauert Bruchteile einer Millisekunde.
Die zweite Aufgabe heißt Entscheiden: Welche Regeln gelten, welcher Weg ist gut, welches Gerät darf mit welchem sprechen? Das ist viel seltener nötig, etwa wenn sich das Netz ändert.
Die beiden Ebenen im Vergleich
| Ebene | Aufgabe | Wie oft | Beispiel |
|---|---|---|---|
| Datenebene | Pakete nach der Tabelle weiterleiten | Bei jedem Paket | Ein Paket von Port 1 an Port 2 senden |
| Steuerungsebene | Regeln und Wege bestimmen | Nur wenn sich etwas ändert | Festlegen, dass Gäste nur den Router erreichen |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.
SDN verlegt die Steuerung in ein Programm
In einem klassischen Switch läuft beides im selben Gehäuse, mit der Software des Herstellers. Jedes Gerät wird einzeln eingerichtet.
SDN trennt die Ebenen. Die Datenebene bleibt im Switch. Die Steuerungsebene zieht in einen Controller um, ein Programm auf einem gewöhnlichen Rechner. Es schreibt Flows in die Tabelle des Switches, und der Switch folgt ihnen. Die Sprache dazwischen heißt OpenFlow.
Warum hat man die Ebenen getrennt?
Es gibt drei Gründe. Erstens liegen alle Regeln an einem Ort, und niemand muss Dutzende Geräte nacheinander ändern. Zweitens ist ein Controller ein normales Programm: Man kann es testen, versionieren und mit Python schreiben.
Drittens spricht jeder Switch mit OpenFlow dieselbe Sprache, egal von welchem Hersteller er kommt. Das Beispiel in der Tabelle rechnet den Unterschied vor.
Beispiel: Gastzugang auf 200 Switches ändern
| Vorgehen | Änderungen nötig | Zeit je Änderung | Gesamtzeit |
|---|---|---|---|
| Jeden Switch einzeln einrichten | 200 | 3 Minuten | 600 Minuten, also 10 Stunden |
| Eine Regel im Controller ändern | 1 | 3 Minuten | 3 Minuten |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.
Im Lab sehen Sie die Datenebene allein
Im Lab läuft Open vSwitch, ein echter Software-Switch. Sie legen einen eigenen Switch namens sw1 an, damit der Switch br0 des Labs unberührt bleibt.
Der Modus secure bedeutet: Der Switch tut nur, was seine Flows erlauben. Ohne Flow verwirft er jedes Paket. Alles läuft in Ihrer eigenen virtuellen Maschine und erreicht kein anderes Netz.
Einen eigenen Switch sw1 anlegen
sudo ovs-vsctl --may-exist add-br sw1 -- set bridge sw1 datapath_type=system protocols=OpenFlow13 fail-mode=secureHier angezeigt, nicht ausgeführt. Erstellen Sie ein kostenloses Konto, um „Ausführen“ zu drücken und ihn im Terminal Ihres eigenen Labs einzugeben.
Den Modus des Switches abfragen
sudo ovs-vsctl get-fail-mode sw1Hier angezeigt, nicht ausgeführt. Erstellen Sie ein kostenloses Konto, um „Ausführen“ zu drücken und ihn im Terminal Ihres eigenen Labs einzugeben.
Hat sw1 einen Controller?
sudo ovs-vsctl get-controller sw1Hier angezeigt, nicht ausgeführt. Erstellen Sie ein kostenloses Konto, um „Ausführen“ zu drücken und ihn im Terminal Ihres eigenen Labs einzugeben.
Flows von sw1 auflisten
sudo ovs-ofctl -O OpenFlow13 --no-stats dump-flows sw1Hier angezeigt, nicht ausgeführt. Erstellen Sie ein kostenloses Konto, um „Ausführen“ zu drücken und ihn im Terminal Ihres eigenen Labs einzugeben.
Ein Paket ohne Flow verfolgen
sudo ovs-appctl ofproto/trace sw1 in_port=1,dl_src=02:00:00:00:00:01,dl_dst=02:00:00:00:00:02 | grep -A1 "^ 0\."Hier angezeigt, nicht ausgeführt. Erstellen Sie ein kostenloses Konto, um „Ausführen“ zu drücken und ihn im Terminal Ihres eigenen Labs einzugeben.
Welche OpenFlow-Versionen spricht er?
ovs-ofctl --versionHier angezeigt, nicht ausgeführt. Erstellen Sie ein kostenloses Konto, um „Ausführen“ zu drücken und ihn im Terminal Ihres eigenen Labs einzugeben.
Tabelle und Regeln in zwanzig Zeilen
# Datenebene: schaut nur in die Tabelle und entscheidet nichts.
tabelle = {}
def weiterleiten(ziel):
if ziel in tabelle:
return "Port " + str(tabelle[ziel])
return "verworfen"
# Steuerungsebene: schreibt die Regeln in die Tabelle.
def controller_schreibt(ziel, port):
tabelle[ziel] = port
print(weiterleiten("drucker"))
controller_schreibt("drucker", 2)
print(weiterleiten("drucker"))
# Schreiben Sie eine zweite Regel für "dozent" und leiten Sie ein Paket dorthin.
Ein häufiger Fehler
Warnung
Viele denken, in SDN laufe jedes Paket durch den Controller. Das wäre viel zu langsam. Der Controller schreibt nur die Regeln, und der Switch leitet danach allein weiter. Nur ein Paket ohne passende Regel wird dem Controller gemeldet.