# SDN: Software Defined Networking – Die Evolution der Netzsteuerung
TL;DR / Management Summary Klassische Netzwerke werden Gerät für Gerät konfiguriert. Software Defined Networking (SDN) ändert dies: Wir trennen die Intelligenz (Control Plane) von der eigentlichen Paketweiterleitung (Data Plane). Ein zentraler Controller steuert das gesamte Netzwerk via Software. Ein Senior Admin nutzt SDN (z.B. in Proxmox via VXLAN/EVPN, Artikel 682), um hunderte virtuelle Netze in Sekunden bereitzustellen, ohne jemals einen physischen Switch manuell anfassen zu müssen.
# 1. Das Drei-Schichten Modell von SDN
Trennung von Macht und Arbeit.
- Application Layer: Programme, die das Netz steuern (z.B. Loadbalancer, Security-Policies).
- Control Layer (SDN Controller): Das “Gehirn”. Er weiß alles über die Topologie und schreibt Befehle an die Switche.
- Infrastructure Layer (Data Plane): Die Switche (physisch oder virtuell). Sie führen nur noch aus (“Paket von Port A zu B”).
# 2. Overlay vs. Underlay
Die virtuelle Welt auf der realen.
SDN arbeitet oft mit zwei Ebenen:
- Underlay: Die physische Hardware (Router, Switche, Glasfaser). Aufgabe: Garantierte IP-Connectivity zwischen allen Knoten.
- Overlay: Die virtuellen Netze (VNets).
- Technik: Pakete werden in VXLAN oder GENEVE Tunnel gekapselt.
- Vorteil: Die VM merkt nicht, dass sie sich in einem virtuellen Tunnel befindet.
# 3. Deep Dive: VXLAN & EVPN
Die Standards des Cloud-RZ.
In modernen Clustern (wie Proxmox) ist VXLAN der Standard.
- VXLAN (Virtual Extensible LAN): Erweitert VLANs von 4.096 auf 16 Millionen IDs.
- EVPN (Ethernet VPN): Der Controller-Mechanismus (basiert auf BGP), der allen Hosts mitteilt, welche VM hinter welcher IP erreichbar ist.
- Nutzen: Live-Migration über Layer-3 Grenzen hinweg (Artikel 672).
# 4. Day-2 Operations: Automatisierung via API
Netzwerk als Code (NaC).
SDN erlaubt es, Netzwerke programmatisch zu erstellen.
- Terraform Integration: Ein Klick im Code erstellt ein neues VLAN, ein Subnetz und die passende Firewall-Regel.
- Vorteil: 100% konsistente Umgebungen für Test und Produktion.
# 5. Troubleshooting & “War Stories”
Wenn die Software die Hardware überholt.
# Top 3 Fehlerbilder
-
Symptom: VMs im Overlay können sich nicht pingen.
- Ursache: MTU-Mismatch. Der SDN-Header macht das Paket zu groß (Artikel 706).
- Lösung: Physische MTU auf 9000 (Jumbo Frames) oder Overlay-MTU auf 1450 senken.
-
Symptom: “BGP Flapping” im EVPN Controller.
- Ursache: Instabile Route im Underlay-Netzwerk.
-
Symptom: Controller-Ausfall führt zu Netz-Stillstand.
- Fix: Nutzen Sie redundante SDN-Controller oder “Headless”-Modi, bei denen die Switche den letzten bekannten Zustand beibehalten.
# “War Story”: Der “Geister”-Traffic im VLAN 1
Ein Admin wollte SDN testen und spannte ein VXLAN über sein Standard-Büronetz (VLAN 1). Das Ereignis: Plötzlich beklagten sich User über langsame Dateitransfers. Die Ursache: Da der Switch kein Hardware-VXLAN-Offloading unterstützte, musste er jedes Paket durch die langsame Haupt-CPU schicken. Der “Software-Overhead” drosselte den Durchsatz von 1 Gbit auf 50 Mbit. Lehre: SDN braucht Hardware, die es versteht (z.B. Mellanox/Intel Karten mit VXLAN Offload). Testen Sie den Durchsatz, bevor Sie das Overlay für alle Workloads freischalten.
# 6. Monitoring & Reporting
Transparenz im Tunnel.
# Flow Monitoring
Nutzen Sie sFlow oder NetFlow (Artikel 586), um in die VXLAN-Tunnel zu schauen.
- KPI:
Tunnel Encapsulation Latency.
# 7. Fazit & Empfehlung
SDN ist die Antwort auf die Komplexität moderner Cloud-Infrastrukturen.
- Empfehlung: Starten Sie mit Proxmox SDN (Artikel 682) für Ihre Testumgebungen.
- Wichtig: Sorgen Sie für ein stabiles, leistungsstarkes Underlay (10G/25G). Ein wackeliges physisches Netz führt zu einem instabilen virtuellen Netz.
# Anhang: Cheatsheet (SDN Glossar)
| Begriff | Bedeutung |
|---|---|
| VTEP | Virtual Tunnel Endpoint (Der Ein/Ausgang des Tunnels) |
| Southbound API | Kommunikation zum Switch (z.B. OpenFlow) |
| Northbound API | Kommunikation zur Applikation (z.B. REST) |
| Isolation | Trennung von Mandanten auf Layer 2 Basis |