# Intent-Based Networking (IBN): Vom ‘Wie’ zum ‘Was’ in der Netzwerksteuerung

TL;DR / Management Summary Klassische Netzwerk-Automatisierung (Artikel 775) sagt dem System exakt, wie es etwas tun soll (imperativ). Intent-Based Networking (IBN) geht einen Schritt weiter: Der Admin definiert nur noch den Geschäftszweck (Intent), z.B. “Webserver XY muss sicher aus dem Internet erreichbar sein”. Das IBN-System berechnet automatisch alle nötigen VLANs, Firewall-Regeln und Routing-Pfade über alle beteiligten Switche und Firewalls hinweg. Ein Senior Admin nutzt IBN zur massiven Reduzierung von menschlichen Fehlern und zur Implementierung von Self-Healing Netzwerken.

# 1. Konzepte des Intent-Based Networking

Die vier Säulen.

Ein IBN-System besteht aus vier funktionalen Phasen:

1. Translation (Übersetzung): Der Admin gibt einen Befehl in natürlicher Sprache oder via High-Level API ein. Das System übersetzt dies in technische Konfigurationen.
2. Activation (Aktivierung): Der Controller rollt die Änderungen auf die Hardware (via SDN/APIs) aus.
3. Assurance (Überwachung): Das System prüft permanent: “Entspricht der Ist-Zustand noch meinem ursprünglichen Intent?”.
4. Remediation (Korrektur): Wenn eine Leitung ausfällt, konfiguriert IBN das Netz automatisch um, um den “Intent” (Erreichbarkeit) weiterhin zu erfüllen.

# 2. Der Unterschied zu SDN

Vom Werkzeug zum Autopiloten.

• SDN (Artikel 738): Bietet die Werkzeuge (Zentrale Kontrolle), erfordert aber weiterhin, dass der Admin die Regeln einzeln schreibt.
• IBN: Nutzt SDN als Ausführungsschicht, fügt aber eine Schicht für Validierung und Business-Logik hinzu. IBN “weiß”, warum eine Regel existiert.

# 3. Deep Dive: Closed-Loop Automation

Das selbstheilende Netz.

Stellen Sie sich vor, eine Backup-Leitung hat plötzlich eine hohe Latenz.

• Traditionell: Das Monitoring schlägt Alarm, der Admin schaltet manuell um.
• IBN (Closed-Loop): Das System erkennt, dass der Intent “VoIP Latenz < 20ms” verletzt wird. Es berechnet einen neuen Pfad via BGP/OSPF und schaltet den Traffic proaktiv um, noch bevor der User eine Störung bemerkt.

# 4. Day-2 Operations: Compliance & Drift Detection

Sicherheit durch Soll-Zustand.

IBN ist der ultimative Compliance-Wächter.

• Aktion: Wenn ein Techniker lokal an einem Switch eine Regel ändert, erkennt das IBN-System den Configuration Drift sofort.
• Reaktion: IBN überschreibt die manuelle Änderung innerhalb von Sekunden wieder mit dem definierten Soll-Zustand (Artikel 532).

# 5. Troubleshooting & “War Stories”

Wenn die KI falsch entscheidet.

# Top 3 Herausforderungen

1. Symptom: “Black-Box Effekt”. Der Admin versteht nicht mehr, warum das System eine bestimmte Route gewählt hat.

   • Lösung: Nutzen Sie IBN-Plattformen mit starker Visualisierung und “Explainable AI”.

2. Symptom: Das System weigert sich, eine Änderung umzusetzen.

   • Ursache: Der neue Intent widerspricht einer globalen Security-Policy (z.B. “Isoliertes Management-VLAN darf niemals Internetzugriff haben”).

3. Symptom: Hohe Lizenzkosten.

   • Fix: Nutzen Sie Open-Source Komponenten (wie GitOps + Ansible + Proxmox API), um ein “Lightweight IBN” selbst aufzubauen.

# “War Story”: Der “Logik-Loop”

Ein Admin definierte zwei Intents: “Minimiere Kosten” und “Maximiere Redundanz”. Das Ereignis: Ein Glasfaserkabel fiel aus. Das Ergebnis: Das IBN-System versuchte, den Traffic auf LTE umzuleiten (Redundanz), stoppte dies aber sofort wieder, da die LTE-Kosten zu hoch waren (Kosten-Intent). Der Traffic flappte 10 Minuten lang, bis der Admin einen der Intents priorisierte. Lehre: Intents brauchen eine klare Hierarchie. Sicherheit und Verfügbarkeit müssen immer über Kostenersparnis stehen.

# 6. Monitoring & Reporting

Der Intent-Status.

# Intent Health Report

Das Dashboard zeigt nicht mehr “Port Up/Down”, sondern:

• Business Application Availability: 100%.
• Policy Compliance: 98% (2 Knoten weichen vom Standard ab).
• Self-Healing Events: 5 Korrekturen in den letzten 24h.

# 7. Fazit & Empfehlung

IBN ist der Endzustand der Netzwerk-Evolution.

• Empfehlung: Starten Sie mit Infrastructure as Code (Artikel 715). Dies ist die Vorstufe zum Intent-Based Networking.
• Wichtig: Ein IBN-System ist nur so gut wie seine Telemetrie. Sorgen Sie für lückenloses Monitoring (Artikel 757/758), damit der Controller die richtigen Entscheidungen treffen kann.

# Anhang: Cheatsheet (IBN vs. Traditionell)

# Referenzen

• Cisco: What is Intent-Based Networking?
• Apstra: Intent-Based Networking for Data Centers
• Gartner: Intent-Based Networking Systems - Market Guide