Batfish & Intent Validation: Policies testen, bevor es brennt

Batfish & Intent Validation sind zwei Begriffe, die in modernen Netzwerkteams immer dann relevant werden, wenn aus „kleinen Changes“ plötzlich große Incidents werden. Denn viele Ausfälle entstehen nicht durch Hardwaredefekte, sondern durch unbeabsichtigte Policy-Effekte: Ein Prefix-Filter ist zu strikt, eine Route-Map matcht in der falschen Reihenfolge, eine ACL blockiert Rückverkehr, oder ein NAT-/Firewall-Change erzeugt One-Way-Symptome. Das Fatale: Solche Fehler sind oft erst in Produktion sichtbar, weil klassische Tests nur einzelne Geräte prüfen, nicht aber das Netzwerk als System. Genau hier setzt Batfish an: Batfish analysiert Konfigurationen offline, baut daraus ein formales Modell des Netzwerks und beantwortet Fragen wie „Ist Host A zu Service B erreichbar?“, „Welche Pfade nimmt der Traffic?“, „Welche Policies greifen?“ – bevor irgendetwas in Produktion ausgerollt wird. Intent Validation ergänzt das um die organisatorische Perspektive: Sie definieren, was das Netzwerk beabsichtigt zu tun (Intent), und verifizieren diesen Intent automatisiert bei jedem Change. Dieser Artikel zeigt, wie Sie Policies mit Batfish testen, wie Sie Intent Checks so formulieren, dass sie realen Betrieb schützen, und wie Sie aus Batfish-Abfragen ein robustes Pre-Change Gate bauen, das Changes stoppt, bevor es brennt.

Warum klassische Pre-Checks oft nicht reichen

Viele Teams prüfen vor einem Change „show“ Outputs, Interface-Status, Nachbarschaften und vielleicht ein paar Pings. Das hilft, aber es beantwortet nicht die wichtigsten Systemfragen. Drei typische Lücken führen regelmäßig zu change-induced outages:

• Lokale Sicht statt End-to-End: „BGP ist up“ sagt nichts darüber, ob die richtigen Routen in der FIB landen oder ob Policies den Traffic später blocken.
• Konfig-Lesen ohne Semantik: Menschen lesen ACLs, Route-Maps und Policy-Statements, aber übersehen Reihenfolgen, Defaults, implizite Denies oder Vendor-spezifische Edge Cases.
• Keine Regressionstests: Ein Change wird geprüft, aber es wird nicht systematisch geprüft, ob dadurch andere, bisher funktionierende Pfade brechen.

Intent Validation schließt diese Lücke: Sie testen nicht nur „ob der Change syntaktisch ok ist“, sondern ob das Netzwerk weiterhin die beabsichtigten Eigenschaften erfüllt.

Was Batfish ist und was Batfish nicht ist

Batfish ist ein Open-Source-Tool zur statischen Netzwerk-Analyse. Es liest Konfigurationsdateien verschiedener Hersteller, modelliert daraus Routing- und Forwarding-Verhalten und erlaubt Abfragen, die typischerweise sonst nur durch riskante Tests in Produktion möglich wären. Einstiegspunkte sind die Projektseite batfish.org und der Quellcode auf GitHub.

• Batfish kann: Reachability analysieren, Routing-Policies und Routenpropagation nachvollziehen, Pfade und Next-Hops erklären, Filter- und ACL-Effekte bewerten, Konfig-Anomalien erkennen.
• Batfish kann nicht: echte Laufzeitprobleme wie physische Fehler, transienten Paketverlust, CPU-Overload oder Vendor Bugs in der Data Plane „messen“. Dafür brauchen Sie Telemetrie, Logs und Captures.

Die richtige Einordnung ist entscheidend: Batfish ersetzt nicht Observability, sondern ergänzt sie als Pre-Change-Sicherheitsnetz und als RCA-Beschleuniger bei Policy-Fragen.

Intent Validation im Netzwerk: Von „Wissen“ zu überprüfbaren Aussagen

Intent ist die formalisierte Aussage darüber, was das Netzwerk leisten soll. In der Praxis bedeutet das: Sie übersetzen Betriebsregeln in maschinenprüfbare Tests. Gute Intent Checks sind konkret, geschäftsrelevant und stabil gegenüber harmlosen Änderungen.

• Connectivity Intent: „Subnetz A darf Service B erreichen“, „Branch-User dürfen DNS/NTP/IdP erreichen“.
• Segmentation Intent: „Guest darf nicht ins Corp-Netz“, „Prod und Dev sind strikt getrennt“.
• Routing Intent: „Default Route nur über Edge X“, „keine Transit-Routen zwischen Kunden-VRFs“.
• Security Intent: „Management nur aus Jump-Subnetzen“, „BGP nur mit definierten Peers“.
• Resilience Intent: „Es existieren mindestens zwei disjunkte Pfade“, „kein Single Point of Failure auf der Control Plane“ (soweit aus Konfig ableitbar).

Typische Policy-Probleme, die Batfish früh findet

Wenn Teams Batfish erstmals einsetzen, sind die ersten „Aha“-Momente oft identisch: Der Change wäre fast durchgerutscht, weil er lokal plausibel aussah. Einige typische Fehlerklassen:

• Prefix-Filter zu strikt: Ein Prefix wird nicht mehr importiert oder exportiert; Impact ist selektiv und schwer zu sehen.
• Route-Map-Reihenfolge: Ein früher Match greift, eine spätere Ausnahme ist faktisch tot.
• Asymmetrische Erreichbarkeit: Hinweg geht, Rückweg nicht (Policy/Route-Leak/Default-Route-Effekt).
• ACL-Implizite Denies: Eine neue Regel blockt unerwartet, weil ein „deny any“ am Ende weiterhin gilt.
• VRF/RT/RD-Leaks: Routen landen in falschen VRFs, besonders in MPLS L3VPN oder EVPN-Designs.
• Unbeabsichtigte Transit-Pfade: Ein Netzwerk wird Transit zwischen Zonen, weil Export/Import nicht sauber getrennt ist.

Die Stärke von Batfish ist, dass Sie diese Effekte nicht erraten müssen. Sie lassen sie berechnen und als Abfrageergebnis belegen.

Workflow: Batfish als Pre-Change Gate in GitOps/CI

Der größte Mehrwert entsteht, wenn Batfish nicht „sporadisch“ im Incident genutzt wird, sondern systematisch vor dem Merge/Deploy. Ein praxistauglicher Workflow sieht so aus:

• Konfig als Artefakt: Gerätekonfigurationen liegen versioniert in Git (oder werden aus Templates gerendert und versioniert).
• Batfish Snapshot: Bei jedem Pull Request wird aus dem Branch ein Snapshot gebaut.
• Intent Tests laufen: Reachability-, Segmentation- und Routing-Intents werden automatisch geprüft.
• Gate entscheidet: Bei Fail → Merge/Deploy blocken. Bei Pass → Change darf weiter.
• Report ausgeben: Bei Fail liefert das System nicht nur „Fail“, sondern „welcher Intent, welcher Pfad, welche Policy verursacht es“.

Damit wird Netzwerkbetrieb näher an Softwarepraktiken gebracht: Changes sind kleine Diffs, und Tests entscheiden über Qualität. Als Grundlage für diesen Ansatz eignet sich Versionskontrolle, z. B. über Git.

Praktische Intent Checks: Was Sie testen sollten, bevor es brennt

Ein häufiger Fehler ist, Intent Checks zu groß oder zu klein zu formulieren. Zu groß heißt: ein Test deckt „alles“ ab und ist schwer zu interpretieren. Zu klein heißt: Tests sind so spezifisch, dass sie kaum Schutzwirkung haben. Folgende Check-Kategorien sind in vielen Unternehmen der beste Start:

Golden Paths

• Identity/AAA: Clients erreichen IdP/SSO, RADIUS/TACACS, MDM-Server.
• Core Services: DNS, NTP, DHCP Relay, Logging/SIEM Collector.
• Business-Critical Apps: ERP, CRM, Voice/Video, Remote Access Gateways.

Segmentation Contracts

• Guest Isolation: Guest darf nur ins Internet, nicht zu internen RFC1918-Netzen.
• Prod/Dev Separation: Dev darf nicht in Prod, außer über definierte Jump-Services.
• Management Plane: Netzwerkmanagement nur aus Admin-Subnets erreichbar.

Routing Hygiene

• No Route Leaks: Keine unerwünschten Routen zwischen VRFs oder Security-Zonen.
• Default Route Policy: Default nur dort, wo vorgesehen; keine unkontrollierte Default-Propagation.
• Transit vermeiden: Keine Zone wird Transit für eine andere, außer explizit definiert.

Batfish-Abfragen verstehen: „Warum“ ist wichtiger als „was“

Ein guter Intent-Test liefert im Fehlerfall eine Erklärung, nicht nur ein rotes X. Gerade im Netzwerkbetrieb ist „warum“ entscheidend, weil Sie sonst nicht wissen, ob der Fix ein Rollback oder ein Fix Forward sein sollte. Batfish ist dafür bekannt, Erklärungen zu Pfaden und Policies liefern zu können, was die Debug-Zeit drastisch reduziert.

• Path Explanation: Welche Geräte und Interfaces liegen im Pfad?
• Policy Explanation: Welche ACL/Route-Map/Policy matcht und an welcher Stelle?
• Counterfactual Thinking: Welche minimale Änderung würde den Intent wieder erfüllen (z. B. eine Prefix-List-Exception)?

Intent Validation für Security: „Allow“ ist nicht gleich „erlaubt“

Viele Security-Incidents entstehen durch falsche Annahmen über Policy-Reihenfolgen oder implizite Defaults. Intent Validation schützt hier besonders, weil sie Security-Ziele als Tests ausdrückt. Beispiele:

• Explizite Deny-Ziele testen: „Netz A darf niemals Netz B erreichen“, inklusive Rückweg.
• Edge-Exposure prüfen: „Kein interner Service ist von außen erreichbar“ (außer definierte Public Services).
• Change-Regression: Ein neues NAT-Objekt darf nicht dazu führen, dass ein internes Segment plötzlich Internet-exponiert ist.

Das reduziert „Sicherheitsgefühl“ und ersetzt es durch überprüfbare Aussagen.

Integration mit Containerlab und Labs: Intent + Repro kombinieren

Batfish ist statisch, Containerlab/EVE-NG sind dynamisch. Die Kombination ist besonders stark:

• Batfish findet die Hypothese: „Policy blockt Rückweg“ oder „Route wird nicht importiert“.
• Lab reproduziert Verhalten: Sie bauen eine minimalistische Topologie, die genau diesen Pfad zeigt, und verifizieren mit Traffic.
• Fix validieren: Erst Batfish Intent Tests bestehen lassen, dann Lab-Traffic wiederholen, dann staged rollout.

Damit wird aus einem Incident eine Regression-Suite: Wenn der Bug einmal gefunden wurde, kommt er beim nächsten Change nicht zurück.

Typische Stolperfallen beim Einstieg in Batfish

Batfish liefert nur dann Nutzen, wenn Sie es „richtig“ einsetzen. Diese Stolperfallen sind in der Praxis häufig:

• Zu viele Intents auf einmal: Starten Sie mit 10–30 High-Signal Intents, nicht mit 500.
• Keine klare Source of Truth: Wenn Konfigs nicht versioniert sind, ist der Snapshot chaotisch und Tests werden unzuverlässig.
• Intent ohne Businessbezug: Tests müssen reale Pfade schützen; sonst werden sie ignoriert, sobald sie einmal „nervig“ sind.
• Keine Pflege: Intent Suites müssen mit Architekturänderungen wachsen (neue VRFs, neue Apps, neue Egress-Modelle).
• Nur „Pass/Fail“ ohne Erklärung: Ohne interpretierbare Reports wird ein Gate schnell als Blocker wahrgenommen.

Governance: Wer „besitzt“ den Intent?

Intent Validation ist nicht nur Tooling, sondern Betriebsmodell. Erfolgreich wird es, wenn klar ist, wer Intents definiert, wer sie reviewed und wie Ausnahmen gehandhabt werden.

• Netzwerkteam definiert Golden Paths: Connectivity- und Routing-Intents.
• Security definiert Segmentation: Deny-Intents, Exposure-Intents, Management-Plane-Intents.
• App-Teams liefern kritische Dependencies: Welche Ports/Services sind wirklich nötig, welche sind optional?
• Ausnahmen sind explizit: Ausnahme-Intents werden versioniert, begründet und regelmäßig überprüft.

So entsteht E-E-A-T im Sinne von Betriebspraxis: nachvollziehbare Regeln, reproduzierbare Tests, auditierbare Historie.

Runbook-Baustein: Batfish & Intent Validation in 15 Minuten produktiv nutzbar machen

• Minute 0–3: 10 kritische Pfade auswählen (DNS, IdP, Internet-Egress, zwei Business-Apps, Management). Diese als erste Intent-Liste festhalten.
• Minute 3–6: Konfig-Snapshot definieren (Repo oder Export) und Batfish-Workflow wählen (lokal oder CI). Ziel: reproduzierbarer Snapshot-Name pro Change.
• Minute 6–9: Erste Intent Checks implementieren: Reachability für Golden Paths und mindestens 3 Segmentation-Denies.
• Minute 9–12: Failure-Output testen: absichtlich eine Policy brechen und prüfen, ob Report interpretierbar ist (Pfad/Policy-Erklärung).
• Minute 12–15: Gate definieren: „Fail blockt Merge/Deploy“. Danach schrittweise Suite erweitern (QoS-/Routing-Hygiene, VRF-Leaks, Default-Propagation).

Weiterführende Quellen

• Batfish Projektseite als Einstieg in Konzepte, Use Cases und Setup
• Batfish auf GitHub für Quellcode, Issues und praxisnahe Beispiele
• pybatfish Dokumentation für Abfragen, Automatisierung und Integration in Testpipelines
• Git Dokumentation für versionierte Konfiguration, Reverts und CI-Workflows als Basis für Intent Validation
• Containerlab zur Kombination aus Intent Checks (statisch) und reproduzierbaren Labs (dynamisch) für Regressionstests

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.