Intent Validation: Topologie und Policies vor Changes testen

Intent Validation ist im Telco- und Provider-Umfeld einer der effektivsten Hebel, um Change Risk zu senken, Ausfälle zu vermeiden und Netzqualität messbar zu stabilisieren. Während klassische Netzwerkänderungen oft auf „Konfig korrekt, also wird es schon passen“ beruhen, prüft Intent Validation etwas anderes: Ob die Absicht (Intent) hinter einer Änderung nachweislich erfüllt wird – bevor die Änderung in Produktion geht. In großen Topologien sind die teuersten Incidents selten Syntaxfehler. Häufiger sind es semantische Fehler: Ein BGP-Export ist zu breit, eine Community wirkt anders als gedacht, ein QoS-Profil verschiebt Drops in eine kritische Klasse, oder eine MTU-Änderung erzeugt selektive Blackholes. Genau diese Fehler sind mit Intent Validation sichtbar, weil sie Topologie- und Policy-Kontext einbezieht: Rollen (Core/Edge/PE/BNG), Linkklassen (DCI, IXP, Transit), Failure Domains (PoP, Region, SRLG), sowie Servicepfade (L3VPN, Internet, DDoS, Mobile Backhaul). Intent Validation verbindet dabei Source-of-Truth-Daten (z. B. NetBox/CMDB) mit Tests, die vor dem Deploy laufen: Policy-Checks, Reachability-Checks, Konvergenz- und Kapazitätschecks, Compliance-Checks und Sicherheitsguardrails. Das Ergebnis ist eine objektive Go/No-Go-Entscheidung, die nicht von Bauchgefühl abhängt, sondern von nachweisbaren Kriterien. Dieser Artikel zeigt, wie Sie Intent Validation aufbauen, welche Arten von Intents sinnvoll sind, wie Topologie und Policies in Pre-Change-Tests zusammenwirken und wie Sie eine Validierungspipeline gestalten, die in Telco-Netzen realistisch, skalierbar und auditierbar ist.

Was Intent Validation wirklich bedeutet

Intent Validation ist die systematische Prüfung, ob ein gewünschter Zielzustand (Intent) nach einer Änderung weiterhin gilt. Der Intent ist dabei nicht „Konfiguration X“, sondern eine überprüfbare Aussage über das Netz, zum Beispiel: „Keine internen Prefixe werden nach außen exportiert“, „Alle PoPs behalten mindestens zwei unabhängige Pfade zum Core“, oder „Retail-Internet hält p99-Latenz unter einem definierten Budget im N-1-Fall“. Intent Validation ersetzt keine Tests im Labor, aber sie ergänzt sie durch konkrete, automatisierte Kontrollen, die direkt an Ihrem Datenmodell (Topologie) und Ihren Policies (Routing, Security, QoS) ansetzen.

• Intent ist semantisch: Es beschreibt Wirkung, nicht Syntax.
• Validation ist objektiv: Sie basiert auf Regeln, nicht auf Meinungen.
• Topologie ist Kontext: Ohne Rollen und Failure Domains sind viele Aussagen nicht prüfbar.
• Policy ist der Hebel: Routing- und Security-Policies erzeugen die meisten „unerwarteten“ Effekte.

Leitprinzip: „Konfig korrekt“ ist nicht gleich „Netz korrekt“

Ein Change kann syntaktisch korrekt sein und trotzdem einen Incident auslösen, weil er Pfade, Prioritäten oder Filterregeln semantisch verändert. Intent Validation zielt genau auf diese Lücke.

Warum Pre-Change-Testing in Telco-Topologien so schwer ist

Telco-Netze sind groß, redundant und dynamisch. ECMP verteilt Flows, Traffic Engineering steuert Pfade, und Interconnect-Policies interagieren mit externen Systemen. Zusätzlich sind Fehlerbilder oft partiell: nur IPv6, nur große Pakete, nur ein bestimmter Content-Partner, oder nur eine Region im Failover. Genau das macht „wir testen kurz auf einem Gerät“ unzureichend. Intent Validation hilft, weil sie nicht jedes Paket simuliert, sondern die wichtigsten invarianten Regeln prüft: Was darf niemals passieren? Was muss immer gelten?

• Failure Domains: Ein Change kann im N-1 plötzlich kritische Engpässe erzeugen.
• Inter-Domain Effekte: BGP-Leaks oder falsche Communities wirken über Peers/Transits.
• Stateful Services: CGNAT/Firewalls/BNG reagieren empfindlich auf Asymmetrie und Pfadwechsel.
• MTU/QoS: Overhead und Queueing sind typische Ursachen selektiver Störungen.

Designregel: Pre-Change-Checks müssen topologie- und servicebewusst sein

Ein Test, der nur „BGP up“ prüft, ist zu grob. Ein guter Test prüft, ob die BGP-Session die richtigen Routen in der richtigen Richtung mit den richtigen Policies trägt – und ob Services dadurch weiterhin korrekt funktionieren.

Intent-Kategorien: Welche Aussagen sich sinnvoll validieren lassen

Intent Validation wird am effektivsten, wenn Intents in Kategorien gegliedert werden. So können Sie priorisieren: Sicherheitsintents und Guardrails zuerst, dann Routing-/Reachability-Intents, dann Performance-Intents. Jede Kategorie hat typische Datenquellen und typische Mess-/Prüfmethoden.

• Security & Compliance Intents: Segmentierung, Exportfilter, Management-Zugänge, CoPP, DDoS-Mechaniken.
• Routing Intents: Reachability, Pfadpräferenz, keine Leaks, korrekte RR-Hierarchie, Max-Prefix.
• Topology Intents: Redundanz, SRLG-Diversität, keine Single Points, Maintenance-Domains eingehalten.
• Service Intents: VRF-Isolation, SLOs, Anycast-Verhalten, Service Chains und Symmetrie.
• Operational Intents: Observability vorhanden, Telemetry-Labels korrekt, Runbooks und Rollback möglich.

Ein guter Intent ist falsifizierbar

„Netz ist resilient“ ist kein Intent. „Alle PoPs haben zwei diverse Uplinks in unterschiedliche SRLGs“ ist falsifizierbar und damit validierbar.

Topologie als Input: Warum Source of Truth die Grundlage ist

Intent Validation braucht ein Datenmodell, das beschreibt, wie das Netz aufgebaut sein soll: Sites, Rollen, Links, Circuits, VRFs, Peers, Linkklassen, SRLGs, Wartungsdomänen. Diese Daten kommen typischerweise aus einer Source of Truth (z. B. NetBox/CMDB). Ohne SoT werden Tests entweder ungenau oder manuell gepflegt – und damit wieder driftanfällig.

• Rollenmodell: Core/Edge/PE/BNG/Service-Edge, damit Policies rollenbasiert geprüft werden können.
• Linkklassen: DCI/IXP/Transit/WAN, um Guardrails pro Kante zu definieren.
• Failure Domains: Region/PoP/SRLG, um Redundanz und Wartungsgrenzen zu validieren.
• Servicekanten: Wo endet ein Service? Welche Knoten sind Ingress/Processing/Egress?

Designregel: Datenvertrag vor Testvertrag

Bevor Sie Regeln schreiben, legen Sie fest, welche SoT-Felder Pflicht sind (z. B. Circuit-ID, SRLG, Role, VRF-ID). Sonst testen Sie gegen unvollständige Realität.

Policy als Input: Was genau vor Changes geprüft werden sollte

Die meisten kritischen Effekte entstehen durch Policies: BGP Import/Export, Communities, LocalPref, Prefix-Filter, QoS-Klassen, CoPP, DDoS-Steering. Intent Validation übersetzt diese Policies in prüfbare Erwartungen. Das erfordert nicht, alle Vendor-CLIs zu verstehen, sondern das Ergebnis der Policywirkung zu prüfen: Welche Routen werden angenommen? Welche werden exportiert? Welche Prioritäten gelten?

• Export-Whitelist: Nur autorisierte Aggregate verlassen das AS; keine internen Infrastrukturprefixe nach außen.
• No-Transit: Peering darf nicht zu Transit werden; Kundenrouten dürfen nicht unkontrolliert weitergegeben werden.
• Max-Prefix: Schutz gegen Prefix Explosion; Grenzwerte pro Peer-Typ und Region.
• Community Contract: Einheitliche Bedeutung von Communities (blackhole, prepend, region-tag).
• QoS Contract: DSCP-Klassen, Marking/Queuing/Policing an definierten Engpässen, Failover-Profil.

Anti-Pattern: Policy-Tests nur auf Konfig-Diffs basieren

Ein Diff sagt, was sich ändert, aber nicht, was es bewirkt. Intent Validation muss die Wirkung prüfen: z. B. „Welche Prefixe würden nach dem Change exportiert?“

Pre-Change Validations: Der praktische Werkzeugkasten

In der Praxis besteht Intent Validation aus mehreren Testtypen, die zusammen eine belastbare Go/No-Go-Entscheidung ermöglichen. Entscheidend ist, dass Tests schnell genug sind, um in CI/CD oder Change-Workflows zu laufen, und aussagekräftig genug, um reale Risiken zu stoppen.

• Static Analysis: Daten- und Policy-Regeln prüfen, ohne das Netz zu berühren (z. B. Namensschema, Pflichtfelder, verbotene Exporte).
• Graph Checks: Topologie als Graph: Redundanz, SRLG-Diversität, Reachability bei Link-/Node-Ausfall (modelliert).
• Config Rendering Checks: Template-Render validieren (Schema, Syntax), aber zusätzlich „Policy Output“ prüfen.
• Emulation/Lab Tests: Für komplexe Änderungen: repräsentative Topologie-Teile nachbauen und Convergence/TE prüfen.
• Pre-Prod Canary Simulation: Auswahl einer Canary Domain und definierte Messpläne für den nächsten Schritt.

Designregel: Schnell + tief statt langsam + perfekt

Ein Validierungsset, das in Minuten läuft und 80% der gefährlichsten Fehler stoppt, ist in Telco-Change-Prozessen oft wertvoller als ein perfekter Test, der Stunden dauert und deshalb nicht genutzt wird.

Topologie-Checks: Redundanz, SRLG und Maintenance Domains validieren

Topologie-Intents sind ideal für Graph-basierte Validierung. Sie prüfen, ob die Struktur des Netzes Ihren Designprinzipien entspricht: Dual-Homing, diverse Pfade, keine Single Points, und Wartungsgrenzen, die Rolling Upgrades ermöglichen. Gerade in Provider-Netzen sind SRLG-Checks ein entscheidender Unterschied zwischen „scheinbar redundant“ und „wirklich redundant“.

• Dual-Uplink Intent: Jede Edge-Site hat mindestens zwei Uplinks zu unterschiedlichen Aggregationsknoten.
• SRLG Intent: Redundante Links dürfen keine gemeinsamen Trassen-/Facility-Risiken teilen.
• Maintenance Domain Intent: Eine Wartungseinheit darf nicht beide Redundanzseiten gleichzeitig treffen.
• DCI Intent: Region-Paare haben mindestens N-1 Pfade, und Failover erzeugt kein unkontrolliertes Hairpinning.

Ein einfacher Redundanz-Check als Logik

$\mathrm{Redundant}=\mathrm{Paths}\ge 2\wedge \mathrm{SRLG\_Disjoint}=\mathrm{true}$

Das Konzept ist simpel: mindestens zwei Pfade und keine gemeinsamen Risiken. In der Praxis wird das über SoT-Attribute und Graph-Analyse umgesetzt.

Routing-Checks: Leaks, Loops und Präferenzregeln vorab stoppen

Routing-Intents sind häufig die wertvollsten, weil sie hochriskante Incidents verhindern: Route Leaks, falsche Präferenzregeln, inkonsistente RR-Distribution und unerwartete Anycast-Pfadänderungen. Hier ist Intent Validation besonders effektiv, wenn Sie Peer-Typen und Policies im Datenmodell sauber hinterlegt haben.

• Leak-Guardrail: Kein Export von Full Table an Peers, kein Export interner Prefixe an externe Nachbarn.
• Preference-Intent: PNI > IXP > Transit (oder Ihr Modell) gilt netzweit konsistent.
• RR-Intent: Jeder Client hat mindestens zwei RR-Peers in getrennten Failure Domains; keine globale Partition durch einen RR-Ausfall.
• Max-Prefix Intent: Alle externen Sessions haben Limits und Warnschwellen; Runbooks referenzierbar.

Anti-Pattern: „Wir merken Leaks im Monitoring“

Ein Leak kann in Minuten globalen Schaden anrichten. Intent Validation muss solche Fehler vor dem Change stoppen, nicht erst danach alarmieren.

Service-Checks: VRF-Isolation, Anycast und Service Chains validieren

Services sind die Ebene, die Kunden erleben. Intent Validation muss deshalb Servicepfade berücksichtigen: Welche VRF ist betroffen? Wo liegen Servicekanten (PE, BNG, CGNAT, Firewall)? Welche Anycast-Prefixe werden genutzt? Welche Pfadsymmetrie ist für stateful Funktionen nötig? Gerade bei Multi-Tenant-Umgebungen verhindert Service-Intent Validation teure Isolation-Fehler.

• VRF-Isolation Intent: Keine unerlaubten Route Leaks zwischen Wholesale/Retail/Enterprise.
• Anycast Intent: Anycast-Prefixe werden nur aus gesunden PoPs announced; Health-Gates definiert.
• Service Chain Intent: Traffic bleibt symmetrisch durch stateful Middleboxes; Failoverpfade respektieren die Kette.
• QoS Service Intent: Kritische Klassen behalten Mindestbudgets auch im Failover (WAN/DCI/Interconnect).

Designregel: Service-Intents müssen topologisch scoped sein

Ein VRF-Intent gilt vielleicht nur für eine Region oder für bestimmte Servicekanten. Intent Validation sollte diese Scopes explizit modellieren, statt pauschal „für alles“ zu testen.

Security-Checks: Guardrails als verpflichtende Pre-Change-Gates

In Telco-Topologien entstehen viele Sicherheitsprobleme durch Drift oder „kleine“ Änderungen: ein zu offenes Management-ACL, fehlende CoPP-Profile, unkontrollierte FlowSpec-Distribution, oder ein neuer Interconnect ohne no-transit-Policy. Security-Intents sind deshalb ideale Gates: Sie sind meist klar definierbar, maschinenprüfbar und hochwirksam.

• Management Intent: Gerätezugang nur über Jump-Zones, keine offenen Managementports auf untrusted Interfaces.
• CoPP Intent: Rollenbasierte CoPP-Profile aktiv, Control-Plane-Protokolle priorisiert, untrusted ICMP begrenzt.
• DDoS Intent: RTBH/FlowSpec nur aus autorisierten Quellen, mit Scope/Expiry und Exportfiltern.
• Interconnect Intent: Default-deny Import/Export, RPKI/IRR-Strategie (falls genutzt) konsistent, Max-Prefix aktiv.

Anti-Pattern: Security als „separates Projekt“

Wenn Security-Checks nicht in derselben Pipeline wie Netzwerkchanges laufen, entstehen Lücken. Intent Validation macht Security zu einem Standardgate, nicht zu einem Sonderprozess.

Pipeline-Design: CI/CD für Netzwerkchanges ohne „Overhead-Explosion“

Eine Intent-Validation-Pipeline muss in den Betrieb passen. Wenn sie zu langsam oder zu kompliziert ist, wird sie umgangen. Ein bewährtes Muster ist eine abgestufte Pipeline: schnelle statische Checks bei jedem Commit, tiefere Topologie-/Policy-Checks bei Merge, und zusätzliche Canary-Gates vor großflächigem Rollout. Entscheidend sind klare Stop/Go-Kriterien und ein standardisiertes Reporting.

• Stage 1 (Fast): Datenvertrag, Naming, Syntax, verbotene Muster, minimale Policy-Checks.
• Stage 2 (Deep): Graph-Redundanz, Export-/Import-Wirkung, VRF-Isolation, Max-Prefix, RR-Health.
• Stage 3 (Release): Canary-Auswahl, Rollout-Plan nach Maintenance Domains, Rollback-Readiness.
• Stage 4 (Post): Post-Checks und SLO-Gates, Drift-Detection, Evidence-Archivierung.

Designregel: Jede Stage braucht ein klares Ergebnisformat

Ein Validator muss erklären, was verletzt ist, wo (Scope), und wie kritisch es ist. Sonst entsteht Frust statt Qualität. Ein standardisiertes „Fail Reason“-Schema ist Gold wert.

Governance: Ownership, Ausnahmeprozesse und „Ablaufdaten“ für Sonderfälle

Intent Validation funktioniert nur mit Governance. Sonst wird jeder zweite Change zum „Exception“, und die Pipeline verliert Wirkung. Bewährt ist ein zweistufiges Modell: Standard-Changes folgen Blueprints und müssen alle Intents erfüllen. Ausnahmen sind möglich, aber sie benötigen Review, dokumentierte Begründung, und ein Ablaufdatum (damit Komplexität nicht dauerhaft wächst).

• Owner pro Intent: Routing-Intents (Core/Interconnect), Service-Intents (Service Owner), Security-Intents (Security Engineering).
• Exception Workflow: Wer darf einen Intent temporär lockern? Wie wird das auditiert?
• Expiry: Ausnahmen laufen aus und müssen aktiv erneuert werden, sonst werden sie zurückgebaut.
• Review Rhythm: Regelmäßige Checks, ob Intents noch zur aktuellen Topologie passen (Wachstum, neue Regionen).

Anti-Pattern: „Nur dieses eine Mal“ ohne Rückführung

Temporäre Ausnahmen werden in Netzen oft dauerhaft. Intent Validation sollte Ausnahmen sichtbar machen und mit Ablaufdaten erzwingen, dass sie wieder bereinigt werden.

Typische Intent-Beispiele, die sofort Nutzen bringen

• Kein Route Leak: Export nur aus Whitelist; keine internen Prefixe nach außen.
• Max-Prefix überall: Jede externe BGP-Session hat Limits und Warnschwellen, per Peer-Typ.
• Dual-Homing pro PoP: Jeder PoP hat zwei diverse Uplinks zu verschiedenen Aggregationsknoten/SRLGs.
• MTU-End-to-End: Overlays/Labels berücksichtigt; kein Pfad unter Minimum-MTU in Serviceketten.
• QoS-Failover-Profil: Backup-Link oder N-1 hat definierte Prioritäten; Bulk wird gedrosselt.
• RR-Redundanz: Jeder Client hat zwei RRs in getrennten Failure Domains; keine Single-RR-Region.
• Management-Zugriff: Management nur via Jump-Zone; keine offenen Managementports auf untrusted Interfaces.

Typische Fallstricke und wie man sie vermeidet

• Intents zu vage: Lösung: falsifizierbare Regeln mit Scope, Schwellenwerten und klaren Datenfeldern.
• SoT unvollständig: Lösung: Pflichtfelder/Definition of Done, Validierung vor Render/Deploy.
• Zu viele Regeln auf einmal: Lösung: in Stufen einführen (Security & Leak-Guardrails zuerst), dann erweitern.
• Pipeline zu langsam: Lösung: schnelle Checks early, tiefe Checks bei Merge/Release, Caching und Domänenscoping.
• Ausnahmen werden Standard: Lösung: Exception Workflow mit Ablaufdatum und Review.
• Nur Konfig geprüft, nicht Wirkung: Lösung: Policy-Output prüfen (exportierte Prefixe, Präferenzen, VRF-Isolation).
• Kein Post-Check: Lösung: Evidence-by-Design: Post-Checks und SLO-Gates als Abschlussbedingung.

Praktische Leitlinien: Topologie und Policies vor Changes testen

• Mit einem Datenvertrag starten: Source of Truth definieren, Pflichtfelder festlegen, Ownership klären.
• Intents kategorisieren: Security/Guardrails zuerst, dann Routing/Topology, dann Services/Performance.
• Topologie als Graph nutzen: Redundanz, SRLG-Diversität und Maintenance Domains automatisch validieren.
• Policy-Wirkung prüfen: Export-/Import-Ergebnis, Communities, Präferenzen, Max-Prefix, VRF-Isolation.
• Pipeline abgestuft bauen: Fast Checks bei jedem Commit, Deep Checks vor Release, Canary-Gates vor Wellen.
• Go/No-Go objektiv machen: Klare Schwellen, klare Fehlermeldungen, standardisiertes Reporting.
• Ausnahmen kontrollieren: Review, Audit, Ablaufdatum; Sonderfälle dürfen Komplexität nicht dauerhaft erhöhen.
• Evidence-by-Design liefern: Expected vs. Observed dokumentieren, Post-Checks und SLO-Gates als Abschluss.
• Regelmäßig nachschärfen: Nach Incidents und großen Topologieänderungen Intents erweitern und Blueprints verbessern.