Intent-Based Networking: Was es ist (und was es nicht ist)

Intent-Based Networking: Was es ist (und was es nicht ist) beschreibt einen Ansatz, bei dem Netzwerke nicht mehr primär über gerätespezifische Konfigurationen und manuelle Einzelschritte betrieben werden, sondern über eine höhere Beschreibungsebene: die „Intention“ oder Absicht. Statt „auf Switch A VLAN 120 anlegen, Trunk auf Port X, ACL auf Interface Y“ lautet die Formulierung eher: „Diese Applikation soll von diesen Clients erreichbar sein, mit dieser Segmentierung, dieser Quality of Service und dieser Sicherheitsrichtlinie.“ Das Netzwerk übersetzt diese Absicht automatisiert in konkrete Konfigurationen und überprüft anschließend, ob der gewünschte Zustand tatsächlich erreicht wurde. Damit wird Intent-Based Networking (IBN) oft als nächster Reifegrad nach Netzwerkautomatisierung, Infrastructure as Code und NetDevOps verstanden. Gleichzeitig ist der Begriff stark marketinggeladen und wird in der Praxis sehr unterschiedlich verwendet: Manche Anbieter nennen bereits einen GUI-Controller „intent-based“, während andere darunter ein geschlossenes System aus Modellierung, Übersetzung, Telemetrie und kontinuierlicher Verifikation verstehen. Dieser Beitrag ordnet Intent-Based Networking ein, erklärt die Kernbausteine und zeigt, woran Sie erkennen, ob ein IBN-Ansatz in Ihrer Umgebung tatsächlich Mehrwert liefert – und wo die Grenzen liegen.

Was „Intent“ im Netzwerk eigentlich bedeutet

Mit „Intent“ ist eine fachliche, technologiearme Beschreibung des gewünschten Netzwerkverhaltens gemeint. Diese Beschreibung ist idealerweise unabhängig von konkreten Geräten, Vendor-spezifischer Syntax und einzelnen Topologie-Details. Intent ist damit näher an der Sprache von Services, Risiken und Betriebszielen als an „CLI-Commands“. Typische Intent-Aussagen sind beispielsweise:

• „Service A darf Service B über Port 443 erreichen, aber sonst keine Ziele in der Data-Zone.“
• „Gäste dürfen nur ins Internet, nicht ins interne Netz.“
• „Voice-Traffic muss Ende-zu-Ende priorisiert werden; Paketverlust < 0,5 %, Jitter unter Zielwert.“
• „Standort X erhält eine neue VRF mit diesem Prefix-Block; keine Overlaps; Telemetrie muss aktiv sein.“
• „BGP-Peerings müssen Prefix Filter und Max-Prefix erzwingen.“

Der entscheidende Punkt: Intent ist nicht einfach „Konfiguration in YAML statt CLI“. Intent bedeutet, dass eine fachliche Absicht in ein Zielmodell überführt wird, aus dem das System deterministisch und überprüfbar eine konkrete Implementierung ableitet.

Was Intent-Based Networking nicht ist

IBN wird häufig mit bestehenden Konzepten verwechselt. Eine klare Abgrenzung hilft, unrealistische Erwartungen zu vermeiden.

• IBN ist nicht gleich Automatisierung: Automatisierung kann auch nur „Schritt A dann B“ sein. Intent benötigt zusätzlich ein Modell des gewünschten Zustands und eine Verifikation, ob dieser Zustand erreicht wurde.
• IBN ist nicht nur ein Controller: Ein zentraler Controller kann hilfreich sein, aber ohne Intent-Modell, Constraints und geschlossene Feedbackschleife bleibt es zentralisiertes Management.
• IBN ist nicht „Self-Healing“ per Magie: Selbstheilung setzt sehr klare Policies, zuverlässige Telemetrie, sichere Remediation-Mechanismen und definierte Sicherheitsnetze voraus.
• IBN ist nicht „kein Netzwerkwissen mehr nötig“: Gute Intents erfordern Verständnis von Segmentierung, Routing, Security, Failure Domains und Betriebsrisiken.
• IBN ist nicht zwangsläufig vendor-neutral: Viele IBN-Ansätze sind eng an eine Plattform oder Modellwelt gekoppelt, auch wenn die Intent-Ebene abstrakt wirkt.

Wenn ein Produkt „intent-based“ nennt, aber letztlich nur Templates ausrollt, ohne kontinuierliche Validierung und ohne klare Trennung zwischen Intent und Implementierung, handelt es sich eher um Automation und Policy Management als um IBN im engeren Sinn.

Die Kernbausteine von Intent-Based Networking

Ein tragfähiger IBN-Ansatz besteht in der Praxis aus mehreren Schichten, die gemeinsam einen geschlossenen Regelkreis bilden. Je mehr dieser Bausteine konsistent umgesetzt sind, desto näher sind Sie an echtem Intent-Based Networking.

Intent-Modell und Datenmodell

Im Zentrum steht ein Modell, das beschreibt, welche Objekte es gibt und wie sie zusammenhängen: Standorte, Rollen, Zonen, VRFs, Applikationen, Policies, QoS-Klassen, Identitäten. Dieses Modell ist idealerweise stabiler als die darunterliegenden Geräte-Details. Häufig wird dafür eine modellbasierte Beschreibung genutzt, etwa über YANG-Modelle (YANG ist ein weit verbreiteter Modellierungsstandard) oder über herstellerspezifische Abstraktionen. Einen Einstieg in YANG als Konzept bietet die Spezifikation auf RFC 7950.

Übersetzung (Compilation) in konkrete Implementierung

Das System muss den Intent in konkrete Konfigurationen übersetzen: VLANs, ACLs, Routing-Policies, Security Groups, Controller-Policies, Gerätekonfigs. Hier entscheidet sich, ob IBN wirklich Mehrwert bringt. Gute Übersetzer berücksichtigen:

• Topologie und Failure Domains (z. B. N-1, Redundanzpfade)
• Gerätefähigkeiten und Plattformunterschiede
• Konflikte zwischen Policies (z. B. überlappende Segmentierungsregeln)
• Standards und Guardrails (z. B. „BGP ohne Prefix Filter ist verboten“)

Ein praktischer Hinweis: Je stärker die Übersetzung modellbasiert ist (Objekte statt Text), desto besser lassen sich Änderungen reviewen und validieren.

Closed Loop Verification: Beobachten und verifizieren

Intent ist wertlos, wenn niemand überprüft, ob er erfüllt ist. IBN setzt deshalb auf kontinuierliche Verifikation: Telemetrie, Zustandsabfragen und Tests belegen, ob das gewünschte Verhalten tatsächlich erreicht wurde. Das ist der Schritt, der IBN von „Automation“ unterscheidet. Typische Verifikationen sind:

• Policy Verification: Ist Segmentierung wie beabsichtigt durchgesetzt (Can/Can’t-Tests)?
• Routing Verification: Sind Peerings stabil, stimmen Prefix Counts, greifen Filter?
• Service Verification: Erreichen synthetische Probes die Dienste mit erwarteter Latenz und Fehlerquote?
• Compliance Verification: Sind Baselines (NTP, Logging, CoPP) aktiv?

Verifikation verlangt saubere Observability. OpenTelemetry ist zwar primär aus der Applikationswelt bekannt, liefert aber ein gutes Bild davon, wie sich Metriken, Logs und Traces als Signale nutzen lassen: OpenTelemetry.

Guardrails und Policy-as-Code

IBN muss verhindern, dass „Intent“ gefährliche Zustände erzeugt. Dafür braucht es Guardrails: feste Regeln, welche Intents zulässig sind und welche nicht. Beispiele:

• Keine „any-any“ Segmentierungsfreigaben in Produktion ohne Sonderprozess
• Pflicht für BGP-Sicherheitsmechanismen wie Prefix Filter und Max-Prefix
• Pflicht-Tags (Owner, Purpose, Review-Date) für sicherheitsrelevante Policies
• Scope-Limits für Rollouts (Canary, Wellen) und Stop-Kriterien bei Fehlern

Guardrails sind kein optionales Extra, sondern essenziell, weil IBN Änderungen beschleunigt. Ohne Leitplanken steigt der potenzielle „Blast Radius“ von Fehlern.

Remediation Loops: Von der Diagnose zur kontrollierten Korrektur

Wenn Verifikation feststellt, dass der Intent nicht erfüllt ist, stellt sich die Frage: Was passiert dann? Reife Systeme bieten Remediation Loops: Tickets, PRs oder automatisierte Korrekturen, abhängig vom Risiko. Gute Remediation ist abgestuft: Low-Risk-Baselines können automatisch korrigiert werden, High-Risk-Änderungen gehen über Review und Wartungsfenster.

Warum IBN für viele Teams attraktiv ist

Intent-Based Networking adressiert echte Probleme, die mit wachsender Netzkomplexität zunehmen. Typische Mehrwerte sind:

• Weniger manuelle Übersetzung: Teams definieren die Absicht; das System generiert die Umsetzung.
• Konsistenz und Standardisierung: Baselines werden als Teil des Modells erzwungen, nicht als „Best Effort“.
• Schnellere Änderungen: Standard-Intents wie „neuer Standort“ oder „neue VRF“ lassen sich wiederholbar ausrollen.
• Bessere Auditierbarkeit: Entscheidungen sind nachvollziehbar (Warum ist eine Policy so?), inklusive Genehmigungen.
• Kontinuierliche Compliance: Nicht nur punktuelle Audits, sondern laufende Überprüfung von Standards.

IBN ist damit eng verwandt mit NetDevOps und Infrastructure as Code. Der Unterschied ist die stärkere Formulierungsebene (Intent) und die integrierte Verifikation als Systembestandteil.

IBN in der Praxis: Typische Einsatzfelder

IBN ist nicht für jeden Netzbereich gleich reif. In manchen Domänen ist der Nutzen besonders hoch, weil sich Intents gut standardisieren lassen.

Campus und WLAN

Campus- und WLAN-Umgebungen profitieren häufig, weil Nutzerrollen, Geräteklassen (Corporate, Guest, IoT) und Zugriffsrichtlinien wiederkehrend sind. Intents wie „Guest nur Internet“ oder „IoT nur zu Controller-Service“ lassen sich relativ stabil modellieren. In diesem Kontext spielt Identität (NAC/802.1X) eine große Rolle und wird oft direkt in Policy-Modelle integriert.

Datacenter-Segmentierung und East-West-Policies

Im Datacenter sind Segmentierungsintents („App darf Data nur auf Port X“) besonders wertvoll, weil sie die laterale Bewegung begrenzen und Security by Design unterstützen. Gleichzeitig ist die Umsetzung komplex, weil es mehrere Enforcement-Punkte geben kann (Distributed Firewall, zentrale Firewalls, Kubernetes Policies). IBN kann hier helfen, wenn das Modell klar ist und Verifikation robust implementiert ist.

WAN/SD-WAN und Standort-Onboarding

Ein klassischer IBN-Use Case ist „neuer Standort“: Adresse, VRFs, WAN-Policy, QoS, Telemetrie, Security-Profile. Wenn diese Bausteine standardisiert sind, kann ein Intent einen großen Teil der Umsetzung automatisiert erzeugen.

Routing-Standards und Sicherheitsbaselines

Auch wenn Routing sehr detailreich ist, sind Sicherheitsbaselines gut standardisierbar: Prefix Filter, Max-Prefix, RPKI-Policies, CoPP-Profile. IBN kann diese Standards als Guardrails erzwingen und Drift automatisch sichtbar machen. Als Best-Practice-Rahmen für Routing Security wird häufig MANRS genannt: MANRS.

Woran Sie echten IBN-Reifegrad erkennen

Da „Intent-Based“ oft als Marketingbegriff genutzt wird, helfen klare Kriterien, um Substanz von Etikett zu trennen. Ein IBN-Ansatz ist in der Praxis umso reifer, je mehr der folgenden Punkte erfüllt sind:

• Klare Intent-Sprache: Intents sind fachlich formuliert und nicht nur „CLI in anderer Form“.
• Stabiles Datenmodell: Objekte und Beziehungen sind konsistent (Sites, Roles, VRFs, Policies).
• Deterministische Übersetzung: Aus Intent entsteht reproduzierbar eine konkrete Implementierung, inkl. Diffs.
• Closed Loop Verification: System prüft kontinuierlich, ob Intent erfüllt ist, und zeigt Abweichungen verständlich.
• Guardrails: Riskante Intents werden verhindert oder brauchen explizite Genehmigungen.
• Remediation-Prozess: Abweichungen führen zu Tickets/PRs/Automationen mit Audit-Trail, nicht zu „stiller Drift“.

Wenn hingegen nur ein zentrales UI existiert, das Konfigurationen verteilt, aber keine laufende Verifikation und keine robusten Constraints bietet, handelt es sich eher um zentrale Orchestrierung als um Intent-Based Networking.

Herausforderungen und Grenzen: Wo IBN schwierig bleibt

IBN klingt oft nach „Ende der Komplexität“, aber in der Realität verlagert sich Komplexität: von Geräten in Modelle, Datenqualität und Prozesse. Häufige Herausforderungen sind:

• Modellgrenzen: Nicht jedes Feature ist modelliert oder herstellerneutral abbildbar; Spezialfunktionen bleiben Ausnahmen.
• Datenqualität: Falsche Standortdaten oder IP-Pläne führen zu falscher Implementierung – schnell und flächig.
• Heterogenität: Multi-Vendor-Umgebungen erhöhen den Übersetzungsaufwand, weil Fähigkeiten variieren.
• Verifikation ist schwer: „Ist Policy erfüllt?“ erfordert oft mehr als Statusabfragen; echte Tests sind notwendig.
• Organisationsdesign: Ownership, Change-Prozesse, Rezertifizierung und Ausnahmehandling müssen mitwachsen.
• False Positives: Verifikationen können fälschlich „nicht compliant“ melden, wenn Signale unvollständig sind.

Ein wichtiger Punkt: IBN funktioniert am besten, wenn die Organisation bereit ist, Standards zu definieren und Ausnahmen strikt zu managen. Ohne Governance wird IBN zu einem weiteren Tool, das Drift nur schneller erzeugt.

IBN und NetDevOps: Wie es zusammenpasst

IBN ist kein Ersatz für Git, CI/CD oder IaC, sondern ergänzt diese Konzepte. Ein robustes Betriebsmodell kombiniert:

• Source of Truth für Intent-Daten (z. B. IPAM/Inventory wie NetBox)
• Git als Audit- und Review-Schicht für Intent-Änderungen und Policies
• CI für Validierung und Guardrails (Schema, Policy-as-Code, Diff-Risikoanalyse)
• CD für kontrollierte Ausrollung (Canary/Wellen, Wartungsfenster, Stop-Kriterien)
• Verification als Pflichtschritt (Post-Checks, Service-Probes, Compliance)

In diesem Setup ist IBN die Ebene, die die „fachliche Absicht“ strukturiert und konsistent macht. NetDevOps ist das Betriebsmodell, das diese Absicht sicher in Produktion bringt und über den Lebenszyklus hinweg stabil hält.

Beispiele für gut formulierbare Intents

Damit Intent nicht abstrakt bleibt, helfen Beispiele, die fachlich formuliert sind und trotzdem umsetzbar bleiben:

• Segmentierungsintent: „Workloads mit Tag app=crm dürfen nur zu data=crm-db auf TCP/5432; sonst deny.“
• Access-Intent: „Corporate Devices compliant erhalten role=employee; non-compliant erhalten quarantine mit Remediation-Zielen.“
• Routing-Intent: „Alle Internet-Edges erzwingen Inbound Prefix Filter und Max-Prefix; RPKI invalid wird gedroppt.“
• Observability-Intent: „Alle Core-Router exportieren Streaming Telemetry an Collector A und Syslog an SIEM B; NTP muss in Toleranz sein.“
• Standort-Intent: „Standort DE-BER-07 erhält WAN-Profil Gold, VRF corp und iot, Prefix-Block X, QoS-Profil Voice/Video aktiv.“

Solche Intents funktionieren gut, weil sie auf stabilen Objekten (Tags, Rollen, Profile) basieren. Sie vermeiden Detailfixierung auf einzelne Ports oder Interfaces, wo möglich, und lassen sich über Modelle und Templates konsistent ausrollen.

Ein pragmatischer Einstieg in Intent-Based Networking

Viele Teams scheitern, wenn sie IBN als „Big Bang“ einführen wollen. Ein pragmatischer Weg ist, mit klaren, wiederholbaren Bereichen zu starten und die Verifikationsschleife früh zu etablieren:

• Start mit Baselines: NTP, Logging, Management-Access, Telemetrieprofile als Intent-Policies.
• Standard-Services: „Neuer Standort“, „Neue VRF“, „Neuer BGP Peer“ als Servicekatalog mit festen Guardrails.
• Verifikation zuerst: Compliance Checks und Service-Probes als Pflicht, bevor Auto-Remediation kommt.
• Ausnahmeprozess: Owner, Begründung, Ablaufdatum – sonst wächst Sonderlogik unbegrenzt.
• Iterative Erweiterung: Segmentierung und QoS schrittweise hinzufügen, statt alles gleichzeitig zu modellieren.

So entsteht IBN als Evolution: erst klare Intents für wiederkehrende Muster, dann stärkere Abstraktion, dann zunehmend geschlossenere Remediation Loops.

Typische Missverständnisse und Anti-Patterns

• „Intent ersetzt Architektur“: Ohne Zonenmodell, Trust Boundaries und klare Standards wird Intent beliebig. Besser: Security-by-Design zuerst, Intent darauf aufbauen.
• „IBN ist nur GUI“: Wenn Änderungen nicht versioniert, getestet und verifiziert werden, bleibt es manuelles Management in anderer Form.
• „Auto-Fix überall“: Automatische Remediation ohne Risikoklassifizierung erzeugt Ausfälle. Besser: Remediation Ladder mit Low-/High-Risk-Trennung.
• „Wir modellieren alles“: Vollständige Modellierung ist selten realistisch. Besser: Kernmodelle stabil halten, Spezialfälle isolieren und rezertifizieren.
• „Datenqualität kommt später“: Schlechte Daten ruinieren IBN. Besser: Validierung, Pflichtfelder, Guardrails von Anfang an.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.