Automatisiertes BGP Policy Testing: Pre-Deployment Checks für Route-Maps

Automatisiertes BGP Policy Testing verhindert die häufigsten und teuersten Edge-Fehler: Route Leaks durch fehlende Outbound-Filter, falsche LocalPref/Community-Maps, ungewolltes Announcen von „more specifics“ oder das versehentliche Droppen kritischer Prefixes. Gerade Route-Maps sind anfällig, weil Reihenfolge zählt und ein einzelnes „permit“ an der falschen Stelle globale Auswirkungen haben kann. Ein guter Pre-Deployment Check ist daher keine einzelne Prüfung, sondern ein testbarer Vertrag („Policy Contract“): Welche Prefixes dürfen rein/raus, welche Attribute müssen gesetzt werden, was muss immer geblockt werden. Dieses Tutorial zeigt einen praxistauglichen Workflow, wie du Route-Maps vor dem Rollout automatisch validierst – mit On-Box-Checks, golden Outputs und reproduzierbaren Testfällen.

Warum BGP-Policy-Tests anders sind als „Config Linting“

Linting findet Syntaxfehler. Policy-Tests finden Logikfehler. Der Unterschied ist entscheidend: Eine Route-Map kann syntaktisch korrekt sein und trotzdem ein Leak verursachen. Daher testest du immer gegen konkrete Inputs (Prefix/Attributes) und erwartete Outputs (permit/deny, LocalPref, Communities, AS-Path, MED).

• Linting: „Konfig ist gültig“
• Policy-Test: „Konfig macht das Richtige“
• Gold Standard: erwartetes Verhalten als wiederholbarer Test

Policy Contract definieren: Was muss die Route-Map garantieren?

Der schnellste Weg zu stabilen Policies ist ein minimales Regelwerk, das überall gilt. Du definierst Tests in drei Klassen: Allow (muss durch), Deny (darf nie durch), Transform (muss Attribute setzen).

• Allow: owned Prefixes müssen outbound announced werden
• Deny: RFC1918/Bogons dürfen nie outbound erscheinen
• Transform: LocalPref/Communities/Prepend müssen korrekt gesetzt sein

Beispiel-Contract (gedanklich)

$\text{Policy}=\text{AllowList}+\text{DenyList}+\text{AttributeRules}$

Testfall-Design: Kleine Inputs, starke Aussage

Du brauchst keine tausend Prefixes, um Leaks zu verhindern. Ein gutes Testset ist klein, aber „edge-case-lastig“: Default Route, more specifics, RFC1918, ein owned Prefix, ein nicht-owned Prefix, ein kritischer Community-Fall.

• Owned: 203.0.113.0/24 (muss permit)
• Not owned: 8.8.8.0/24 (muss deny)
• RFC1918: 10.0.0.0/8 (muss deny)
• Default: 0.0.0.0/0 (outbound meist deny)
• More specific: 203.0.113.0/25 (wenn nicht erlaubt → deny)

Pre-Deployment Checks On-Box: Das „schnelle“ Testpaket

Auch ohne externe Tools kannst du viel automatisieren, indem du standardisierte Show-Kommandos vor und nach einer Policy-Änderung vergleichst. Das Ziel ist: keine Überraschungen bei advertised-routes und bei Route-Map Matches.

Baseline erfassen (Pre)

show ip bgp summary
show route-map
show ip prefix-list
show ip bgp neighbors <peer> advertised-routes

Policy anwenden ohne Session Reset

clear ip bgp <peer> soft out

Post-Checks

show ip bgp neighbors <peer> advertised-routes
show route-map

Golden Output: advertised-routes als „Policy Snapshot“

Für Enterprise-Edges ist advertised-routes der beste Golden Output: Du siehst exakt, was du nach außen announcest. Ein automatisierter Check vergleicht diesen Output gegen einen erlaubten Sollzustand (oder gegen Regex/Counts), bevor ein Change freigegeben wird.

• Leak-Schutz: keine fremden Prefixes outbound
• Stabilität: Counts und konkrete Prefixes stimmen
• Audit: nachvollziehbarer Diff pro Change

Golden Output Capture

show ip bgp neighbors 203.0.113.1 advertised-routes

Route-Map Unit Tests: Matches und Reihenfolge prüfen

Viele Fehler entstehen durch falsche Reihenfolge oder zu breite Prefix-Lists. Deshalb testest du „Trifft die Route-Map überhaupt den richtigen Sequence-Eintrag?“ mit Counter-Logik: Nach einem controlled re-advertise müssen Trefferzahlen plausibel sein.

Route-Map Hits prüfen

show route-map RM_OUT

Interpretation

• permit 10 sollte Hits auf owned Prefixes zeigen
• deny 100 sollte Hits auf „catch-all“ zeigen (wenn absichtlich so gebaut)
• 0 Hits = Route-Map hängt evtl. nicht am Neighbor oder matcht nicht

Lab/CI Ansatz: Policy Testing mit „synthetischem BGP“

Für echte Automatisierung nutzt du eine Testumgebung (z. B. Containerlab/EVE-NG/GNS3) oder eine CI-Pipeline, die die BGP-Policy auf einer virtuellen IOS-XE/CSR-Instanz lädt, definierte Testprefixes einspeist und die Ergebnisse ausliest (accepted/advertised/attributes). Das ist der robusteste Weg, weil er unabhängig von Produktion ist.

• CI lädt Konfig (Route-Maps, Prefix-Lists)
• Testpeer announced Testprefixes
• CI prüft: permit/deny und gesetzte Attribute

Beispiel: Testprefixes am Testpeer announcen (Konzept)

router bgp 64500
 network 203.0.113.0 mask 255.255.255.0
 network 10.0.0.0 mask 255.0.0.0
 network 0.0.0.0

Attribute-Tests: LocalPref, Communities, AS-Path Prepend verifizieren

Leak-Tests sind nicht genug. In Enterprise-TE müssen Attribute stimmen: LocalPref Governance, Community-Mapping, Prepending für Backup-Links. Diese Checks machst du über show ip bgp <prefix> pro Testprefix.

Attribute pro Prefix prüfen

show ip bgp 203.0.113.0/24
show ip bgp 0.0.0.0
show ip bgp 10.0.0.0/8

Erwartungen (Beispiele)

• Owned Prefix: permit, Communities vorhanden, optional Prepend
• RFC1918: nicht vorhanden oder als denied erkennbar
• Default: nur dann vorhanden, wenn bewusst erlaubt

RPKI/ROV und Max-Prefix als Pre-Deployment Gate

Gute Pre-Deployment Checks schließen Guardrails ein: Wenn RPKI „invalid“ plötzlich steigt oder Max-Prefix nahe an die Schwelle kommt, ist das ein Change-Stopper. Damit verhinderst du, dass Policy-Rollouts einen Storm oder eine Session-Reset-Kaskade auslösen.

• Max-Prefix Headroom prüfen (vor dem Change)
• RPKI invalid-count überwachen (vor/nach Change)
• Refresh seriell ausrollen (nicht alle Peers parallel)

Guardrail Checks

show ip bgp summary
show logging | include MAXPFX|RPKI|BGP
show bgp rpki summary

Change-Safety: Rollback und „Blast Radius“ minimieren

Automatisierte Tests sind am stärksten, wenn sie mit einem sicheren Rollout-Prozess kombiniert sind: kleine Änderungen, klarer Rollback, und erst dann breiter Rollout. Route-Maps sollten als Templates versioniert sein.

• Canary: ein Edge/Peer zuerst
• Rollback: bekannte gute Route-Map-Version
• Post-Checks: advertised-routes Diff muss „expected“ sein

Typische Fehler, die Tests zuverlässig finden

Diese Fehler sind in der Praxis häufig und lassen sich mit dem oben beschriebenen Testset sehr zuverlässig erkennen.

• Outbound Whitelist fehlt → advertised-routes enthält fremde Prefixes
• Prefix-List le/gt falsch → more specifics werden geleakt
• Route-Map Reihenfolge falsch → deny greift zu spät
• send-community fehlt → Provider-TE greift nicht
• LocalPref unerwartet überschrieben → Exit-Pfad ändert sich

Quick-Template: Pre-Deployment Checkliste (Copy & Paste)

Diese Checkliste ist ein minimalistisches Runbook für Changes an Route-Maps am Enterprise Edge.

! Pre
show ip bgp summary
show ip bgp neighbors <peer> advertised-routes
show route-map
show ip prefix-list
show ip community-list
show logging | include MAXPFX|BGP
! Change (Route-Map/Prefix-List anpassen)
! Apply

clear ip bgp  soft out
! Post

show ip bgp neighbors  advertised-routes

show route-map

show ip bgp 

show logging | include BGP|MAXPFX

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.