🚀 Modul 1: Einführung in NetDevOps
⏱️ Geschätzte Dauer: 90 Minuten
Lernziele: Nach diesem Modul verstehen Sie, was NetDevOps ist, warum es für moderne Netzwerkteams unverzichtbar geworden ist, kennen die Grundlagen von VXLAN/EVPN, wissen was NDFC ist und haben Ihre Lab-Umgebung erkundet.
🤔 Teil 1: Warum NetDevOps? (30 Min)
Die Schmerzpunkte im Netzwerk-Alltag
Bevor wir uns anschauen, was NetDevOps ist, fragen wir uns: Was läuft denn aktuell schief? Hier sind typische Situationen, die wahrscheinlich jeder Netzwerker kennt:
😫 Schmerzpunkt 1: Der "Schneeflocken-Switch"
Sie haben 50 Switches im Rechenzentrum. Theoretisch sind alle gleich konfiguriert.Theoretisch.
In der Praxis hat Klaus vor 3 Jahren auf Switch-17 "kurz was angepasst". Maria hat auf Switch-23 "nur mal schnell" einen Debug-Befehl vergessen zu entfernen. Und auf Switch-42? Keine Ahnung, der läuft halt irgendwie.
→ Jeder Switch ist einzigartig wie eine Schneeflocke. Und genauso fragil.
😫 Schmerzpunkt 2: "Das hat doch letzte Woche noch funktioniert!"
Es ist Montag, 8 Uhr. Das Ticket-System explodiert. "VPN geht nicht." "Applikation XY erreicht Datenbank nicht." "Internet ist langsam."
Was ist passiert? Wer hat am Wochenende etwas geändert? Sie fragen rum. Niemand war es. "Ich hab gar nichts gemacht!"
Drei Stunden später findet jemand in einem Audit-Log: Freitagabend, 23:47, eine ACL wurde angepasst. Von wem? Steht da nicht. Warum? Steht da auch nicht.
→ Änderungen sind nicht nachvollziehbar. Fehlersuche wird zum Ratespiel.
😫 Schmerzpunkt 3: Der Copy-Paste-Marathon
Neues VLAN anlegen. Sollte 5 Minuten dauern, oder?
SSH auf Switch 1. Befehle eintippen. SSH auf Switch 2. Die gleichen Befehle. Switch 3... Switch 4... Bei Switch 27 vertippt man sich. Switch 28... War das jetzt Interface Eth1/1 oder Eth1/11? Nochmal nachschauen...
4 Stunden später: Fertig. Aber sind wirklich alle Switches richtig konfiguriert?Hoffentlich.
→ Manuelle, repetitive Arbeit ist fehleranfällig und frisst Zeit.
😫 Schmerzpunkt 4: "Rollback? Welches Backup?"
Die Änderung ging schief. Der Core-Switch macht Probleme. Chef brüllt. "Mach das rückgängig! Sofort!"
Okay, wo ist das Backup? TFTP-Server? Letztes Backup... vor 47 Tagen. Aber seitdem wurden 23 Änderungen gemacht...
→ Kein zuverlässiges Rollback. Jede Änderung fühlt sich an wie russisches Roulette.
Was ist NetDevOps eigentlich?
NetDevOps = Network + DevOps. Es bringt bewährte Praktiken aus der Software-Entwicklung in die Netzwerkwelt:
- Versionskontrolle: Jede Änderung wird gespeichert, wie bei Word mit "Änderungen nachverfolgen" – nur besser.
- Automatisierung: Maschinen machen die langweilige, repetitive Arbeit.
- Testing: Änderungen werden geprüft, bevor sie auf die Produktion losgelassen werden.
- Kontinuierliche Integration: Kleine, häufige Änderungen statt Big-Bang-Rollouts.
Analogie: Das Restaurant
Stellen Sie sich vor, Sie betreiben ein Restaurant:
🍳 Ohne Rezepte (= Traditionell)
- • Chef kocht aus dem Kopf
- • Jedes Gericht schmeckt anders
- • Wenn Chef krank ist = Chaos
- • Neuer Koch? 6 Monate Einarbeitung
- • "Das Schnitzel war letzte Woche besser!"
📖 Mit Rezeptbuch (= NetDevOps)
- • Jedes Rezept ist dokumentiert
- • Konsistente Qualität, immer
- • Jeder Koch kann jedes Gericht kochen
- • Neuer Koch? Rezeptbuch lesen, loslegen
- • Rezept verbessert? Für alle aktualisiert
Analogie: Die Autofabrik
Oder denken Sie an eine Autofabrik:
Vor dem Fließband (1900): Jedes Auto wurde einzeln von Hand gebaut. Ein Meister und seine Gesellen. 12 Stunden pro Auto. Jedes einzigartig. Teuer.
Nach dem Fließband (Ford, 1913): Standardisierte Schritte. Dokumentierte Prozesse. Jedes Auto ist gleich. 93 Minuten pro Auto. Erschwinglich.
NetDevOps ist das Fließband für Netzwerkkonfiguration. 🏭
Der traditionelle Weg vs. NetDevOps
❌ Traditionell
- • SSH auf jeden Switch einzeln
- • Copy-Paste aus Word-Dokumenten
- • "Das hat Klaus immer so gemacht"
- • Änderungen schwer nachvollziehbar
- • Rollback? Backup von letzter Woche...
- • Testing? "Funktioniert schon..."
- • Dokumentation? In Klausens Kopf
✅ NetDevOps
- • Konfiguration als Code in Git
- • Automatisierte Deployments
- • Dokumentierte, überprüfbare Änderungen
- • Jede Änderung ist nachvollziehbar
- • Rollback per Git-Befehl
- • Automatisierte Validierung
- • Code IST die Dokumentation
📝 Teil 2: Infrastructure as Code (IaC) (15 Min)
Das Herzstück von NetDevOps ist Infrastructure as Code (IaC). Die Idee ist einfach: Statt Konfigurationen manuell über eine CLI oder GUI einzugeben, beschreiben Sie den gewünschten Zustand in Textdateien.
Was bedeutet "als Code"?
Wenn wir sagen "als Code", meinen wir:
- Textdateien: Lesbar, editierbar, durchsuchbar
- Versioniert: In Git gespeichert, jede Änderung nachvollziehbar
- Deklarativ: Sie beschreiben WAS Sie wollen, nicht WIE
- Ausführbar: Ein Tool liest die Datei und setzt sie um
Imperativ vs. Deklarativ
Das ist ein wichtiger Unterschied:
🔧 Imperativ (traditionell)
Sie sagen Schritt für Schritt, WAS zu tun ist:
📋 Deklarativ (IaC)
Sie beschreiben den ZIELZUSTAND:
Das Tool kümmert sich um den Rest.
Vorteile von IaC
✨ Warum IaC Ihr Leben verbessert
- 🔄 Reproduzierbar: Gleicher Code = Gleiches Ergebnis. Immer. Überall.
- 📜 Dokumentiert: Der Code IST die Dokumentation. Keine veralteten Word-Dokumente mehr.
- 🔍 Review-fähig: Kollegen können Änderungen prüfen, BEVOR sie live gehen.
- ⏪ Rollback: Etwas kaputt?
git revertund fertig. - 🧪 Testbar: Syntax-Check, Validierung, Dry-Run – alles automatisch.
- 📈 Skalierbar: 1 Switch oder 1000 – der Aufwand ist der gleiche.
Ein konkretes Beispiel
So sieht Infrastructure as Code für eine VXLAN-Fabric aus:
# Infrastructure as Code - VXLAN Fabric Definition
# Diese Datei beschreibt den ZIELZUSTAND unserer Fabric
fabric:
name: FI-DataCenter-Prod
fabric_type: vxlan_evpn
# BGP-Konfiguration
bgp:
asn: 65001
# Underlay-Netzwerk
underlay:
protocol: ospf
area: 0.0.0.0
network: 10.0.0.0/8
# Spine-Switches
spines:
- name: dc1-spine-1
management_ip: 10.1.1.1
loopback: 10.255.1.1
role: spine
- name: dc1-spine-2
management_ip: 10.1.1.2
loopback: 10.255.1.2
role: spine
# Leaf-Switches
leaves:
- name: dc1-leaf-1
management_ip: 10.1.2.1
loopback: 10.255.2.1
role: leaf
uplinks:
- spine: dc1-spine-1
interface: Eth1/49
- spine: dc1-spine-2
interface: Eth1/50
- name: dc1-leaf-2
management_ip: 10.1.2.2
loopback: 10.255.2.2
role: leaf
uplinks:
- spine: dc1-spine-1
interface: Eth1/49
- spine: dc1-spine-2
interface: Eth1/50
# VRFs und Netzwerke werden in separaten Dateien definiert
# Siehe: networks/ OrdnerDiese Datei ist lesbar, versionierbar und sagt genau, wie die Fabric aussehen soll. Keine Mehrdeutigkeit, keine "das weiß nur Klaus"-Momente.
🌐 Teil 3: VXLAN/EVPN Grundlagen (15 Min)
Bevor wir VXLAN as Code machen, sollten wir verstehen, WAS VXLAN und EVPN eigentlich sind. Keine Sorge, wir halten es verständlich – keine RFC-Rezitation!
Das Problem: VLANs skalieren nicht
Klassische VLANs haben ein Problem: Sie existieren nur auf Layer 2 und sind auf 4096 begrenzt (12 Bit VLAN-ID). In modernen Rechenzentren mit Virtualisierung, Multi-Tenancy und Cloud-Anforderungen reicht das nicht mehr.
🤔 Das VLAN-Dilemma
- • Max. 4096 VLANs (oft weniger nutzbar)
- • Spanning Tree = langsame Konvergenz, blockierte Pfade
- • Layer 2 Broadcast-Domänen werden riesig und langsam
- • Schwer über mehrere Rechenzentren zu spannen
Die Lösung: VXLAN
VXLAN (Virtual Extensible LAN) löst diese Probleme, indem es Layer-2-Frames in UDP-Pakete packt und über ein Layer-3-Netzwerk tunnelt.
📦 VXLAN in einer Minute
- VNI (VXLAN Network Identifier): 24 Bit = 16 Millionen mögliche Netzwerke statt nur 4096
- VTEP (VXLAN Tunnel Endpoint): Der Switch, der die Pakete ein- und auspackt
- Overlay: Das virtuelle Layer-2-Netzwerk, das über allem liegt
- Underlay: Das physische Layer-3-Netzwerk darunter (IP-Routing)
Analogie: Die Post
Stellen Sie sich vor, Sie wollen einen Brief von München nach Hamburg schicken, aber nur innerhalb Ihres Bürogebäudes kommunizieren können (Layer 2):
Ohne VXLAN: Sie müssten eine private Rohrpost von München nach Hamburg bauen. Teuer, unflexibel.
Mit VXLAN: Sie stecken Ihren Brief (Layer-2-Frame) in einen Briefumschlag (UDP-Paket) und schicken ihn per Post (IP-Netzwerk). Am Ziel wird er ausgepackt und zugestellt. Fertig!
Was ist EVPN?
EVPN (Ethernet VPN) ist die "Control Plane" für VXLAN. Es regelt, WER mit WEM reden kann und WO die MAC-Adressen sind.
EVPN = Wie die Switches lernen, welche MAC-Adressen wo sind (Control Plane).
Zusammen bilden sie VXLAN/EVPN – den Standard für moderne Datacenter-Fabrics.
EVPN-Vorteile
- Kein Flooding: Statt Broadcasts zu fluten, tauschen Switches Informationen per BGP aus
- Schnelle Konvergenz: BGP ist schnell und stabil
- Multi-Homing: Ein Server kann an mehrere Switches angeschlossen werden (aktiv/aktiv)
- Layer 2 + Layer 3: EVPN kann beides – MAC-Adressen UND IP-Routen verteilen
VXLAN-Fabric Topologie
🏗️ Spine-Leaf Architektur
┌─────────────┐ ┌─────────────┐
│ SPINE-1 │ │ SPINE-2 │
│ (BGP RR) │ │ (BGP RR) │
└──────┬──────┘ └──────┬──────┘
│ │
┌───────────────┼───────────────────┼───────────────┐
│ │ │ │
┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐ ┌─────┴─────┐
│ LEAF-1 │ │ LEAF-2 │ │ LEAF-3 │ │ LEAF-4 │
│ (VTEP) │ │ (VTEP) │ │ (VTEP) │ │ (VTEP) │
└─────┬─────┘ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘
│ │ │ │
Server Server Server Server
- • Spines: Verbinden alle Leafs, machen nur Routing (kein Storage/Server)
- • Leafs: Hier hängen Server, Storage, Firewalls – die VTEPs
- • Jeder Leaf ist mit jedem Spine verbunden = maximale Redundanz
📊 Teil 4: Nexus Dashboard & NDFC (10 Min)
Jetzt wissen wir, WAS VXLAN/EVPN ist. Aber wie konfiguriert man das auf 50 Switches? Hier kommt Nexus Dashboard ins Spiel.
Was ist Nexus Dashboard?
Nexus Dashboard ist Ciscos zentrale Management-Plattform für Datacenter-Netzwerke. Es ist wie das Cockpit für Ihre gesamte Fabric.
🎛️ Nexus Dashboard im Überblick
- Zentrale Verwaltung: Alle Switches von einer Oberfläche aus
- Fabric Controller (NDFC): Automatisiert VXLAN/EVPN-Deployments
- Insights: Monitoring, Troubleshooting, Compliance-Checks
- Orchestrator: Multi-Site-Verbindung mehrerer Fabrics
Was ist NDFC?
NDFC (Nexus Dashboard Fabric Controller) – früher DCNM (Data Center Network Manager) – ist DIE Komponente für uns. NDFC:
- Kennt alle Switches und deren Verbindungen
- Generiert die komplette VXLAN/EVPN-Konfiguration
- Pushed Configs auf die Switches
- Zeigt den aktuellen Status der Fabric
- Bietet eine REST API für Automatisierung (👈 Das nutzen wir!)
Der Workflow mit NDFC
NDFC ist das Bindeglied zwischen unserem Code und den Switches.
🔬 Teil 5: Praxis-Übungen (15 Min)
Genug Theorie! Zeit, die Hände schmutzig zu machen. In den folgenden Übungen erkunden Sie Ihre Lab-Umgebung.
🧪 Übung 1: Lab-Umgebung erkunden (5 Min)
Ihre Lab-Umgebung besteht aus drei Hauptkomponenten. Öffnen Sie alle drei in separaten Browser-Tabs:
URL: https://code.lab.finanzconsult.de
Login: Ihre Workshop-Credentials→ Hier schreiben und editieren wir unseren Code
URL: https://gitlab.lab.finanzconsult.de
Login: Ihre Workshop-Credentials→ Hier versionieren wir unseren Code und starten Pipelines
URL: https://ndfc.lab.finanzconsult.de
Login: admin / Workshop-Passwort→ Hier sehen wir unsere Fabric und was deployiert wurde
- ☐ VS Code ist offen und zeigt das Projekt
- ☐ GitLab zeigt das Repository
- ☐ NDFC Login funktioniert
🧪 Übung 2: NDFC erkunden (5 Min)
Navigieren Sie durch NDFC und beantworten Sie folgende Fragen:
- Klicken Sie links auf Fabric Controller
- Wählen Sie Fabrics aus dem Menü
- Öffnen Sie die Fabric
FI-Workshop - Schauen Sie sich die Topologie-Ansicht an
- • Wie viele Switches sind in der Fabric?
- • Welche Rolle haben die Switches (Spine/Leaf)?
- • Ist die Fabric aktuell "In-Sync" oder "Out-of-Sync"?
- • Gibt es bereits VRFs oder Networks konfiguriert?
🧪 Übung 3: Gruppendiskussion (5 Min)
Diskutieren Sie mit Ihren Sitznachbarn:
"Welche manuellen, repetitiven Aufgaben machen Sie in Ihrem Netzwerk-Alltag täglich oder wöchentlich?"
Beispiele zum Anstoßen:
- • VLANs anlegen auf mehreren Switches
- • Port-Konfigurationen für neue Server
- • ACL-Änderungen durchführen
- • Backup-Konfigurationen erstellen
- • Dokumentation aktualisieren
Schreiben Sie 2-3 Aufgaben auf, die Sie gerne automatisieren würden. Am Ende des Workshops schauen wir, ob wir dafür Lösungen gefunden haben!
❓ Teil 6: Quiz & Reflexion (5 Min)
Testen Sie Ihr Wissen! Versuchen Sie, die Fragen ohne Zurückblättern zu beantworten.
1. Was bedeutet "NetDevOps"?
Antwort anzeigen
NetDevOps = Network + DevOps. Es bringt Software-Entwicklungspraktiken (Versionskontrolle, Automatisierung, Testing, CI/CD) in die Netzwerkwelt.
2. Was ist der Unterschied zwischen imperativ und deklarativ?
Antwort anzeigen
Imperativ: Schritt-für-Schritt-Anweisungen (WIE etwas gemacht wird).
Deklarativ: Beschreibung des Zielzustands (WAS das Ergebnis sein soll).
3. Wofür steht VNI und wie viele VNIs sind möglich?
Antwort anzeigen
VNI = VXLAN Network Identifier. Mit 24 Bit sind ca. 16 Millionen VNIs möglich (vs. nur 4096 VLANs mit 12 Bit).
4. Was ist ein VTEP?
Antwort anzeigen
VTEP = VXLAN Tunnel Endpoint. Das ist der Switch, der Layer-2-Frames in VXLAN-Pakete ein- und auspackt. In einer Spine-Leaf-Fabric sind die Leafs die VTEPs.
5. Was macht NDFC?
Antwort anzeigen
NDFC (Nexus Dashboard Fabric Controller) ist die zentrale Management-Plattform für VXLAN/EVPN-Fabrics. Es kennt alle Switches, generiert Konfigurationen, pushed sie auf die Geräte und bietet eine REST API für Automatisierung.
🎯 Reflexion
Denken Sie kurz nach: Welcher der vier Schmerzpunkte vom Anfang (Schneeflocken-Switches, fehlende Nachvollziehbarkeit, Copy-Paste-Marathon, kein Rollback) betrifft Sie am meisten? Behalten Sie das im Hinterkopf – am Ende des Workshops sollte genau das gelöst sein!
📋 Zusammenfassung
✅ Das haben Sie in diesem Modul gelernt
- ☑️ Warum NetDevOps: Die Schmerzpunkte traditioneller Netzwerkverwaltung
- ☑️ Was NetDevOps ist: DevOps-Praktiken für Netzwerke (Versionierung, Automatisierung, Testing)
- ☑️ Infrastructure as Code: Deklarative Konfiguration in Textdateien statt manuelle CLI-Befehle
- ☑️ VXLAN/EVPN: Modernes Overlay-Netzwerk für skalierbare Datacenter
- ☑️ Nexus Dashboard & NDFC: Die zentrale Steuerung für Ihre Fabric
- ☑️ Ihre Lab-Umgebung: VS Code, GitLab und NDFC sind einsatzbereit
🔮 Ausblick: Was kommt als Nächstes?
Im nächsten Modul lernen Sie Git kennen – das Rückgrat jeder NetDevOps-Implementierung. Sie werden sehen, wie Sie Änderungen versionieren, nachvollziehen und bei Bedarf zurückrollen können. Keine Angst, es ist einfacher als es aussieht!