BGP Route Leaks verhindern: Filter-Strategie für Enterprise Edge

Ein BGP Route Leak ist einer der teuersten Enterprise-Fehler am Internet-Edge: Plötzlich werden fremde Prefixes weiterannonseriert, Traffic wird über dein Netz gezogen oder du „vergiftest“ Routing-Entscheidungen im Upstream. Das kann zu massiven Ausfällen führen – intern und extern – und ist oft ein reiner Konfigurationsfehler (fehlender Outbound-Filter, falsches Redistribution-Match, „permit any“ in der Route-Map). Die gute Nachricht: Route Leaks lassen sich mit einer klaren Filter-Strategie fast vollständig verhindern. Dieses Tutorial zeigt eine praxistaugliche Enterprise-Edge-Baseline mit Whitelists, Guardrails und Verifikation.

Was ein Route Leak ist (und wie es typischerweise passiert)

Ein Leak bedeutet: Du announcest Prefixes, die du nicht announcen darfst oder nicht announcen willst. Meist passiert das durch fehlende Outbound-Whitelist oder durch unkontrollierte Redistribution ins BGP.

• Outbound Leak: du sendest zu viele Prefixes an den Provider
• Transit Leak: du leitest Routen von Provider A an Provider B weiter
• Internal Leak: du exportierst interne/VRF Routen unbeabsichtigt

Filter-Strategie: Drei Schutzschichten am Enterprise Edge

Ein robustes Leak-Design ist redundant: Whitelist + Limits + klare Redistribution. Jede Schicht kann die anderen Fehler auffangen.

• Schicht 1: Outbound Whitelist (nur „owned“ Prefixes)
• Schicht 2: Inbound Hygiene (Bogons/Private, Max-Prefix)
• Schicht 3: Redistribution kontrollieren (Tagging/Filtering)

Schicht 1: Outbound Whitelist – die wichtigste Regel

Outbound ist dein größtes Risiko. Die Baseline lautet: Nur Prefixes announcen, die dir gehören (oder die du explizit im Auftrag announcest). Alles andere wird hart gedroppt. Das erreichst du mit Prefix-Lists + Route-Map Default-Deny.

Owned Prefixes whitelisten

ip prefix-list PL_OWNED seq 10 permit 203.0.113.0/24
ip prefix-list PL_OWNED seq 20 permit 198.51.100.0/24
ip prefix-list PL_ANY seq 5 permit 0.0.0.0/0 le 32

Outbound Route-Map: permit owned, deny rest

route-map RM_OUT permit 10
 match ip address prefix-list PL_OWNED
route-map RM_OUT deny 100

match ip address prefix-list PL_ANY

Am Neighbor anwenden

router bgp 65000
 neighbor 203.0.113.1 remote-as 64500
 neighbor 203.0.113.1 route-map RM_OUT out

Schicht 2: Inbound Hygiene – damit du keinen Müll weiterträgst

Inbound Filter verhindern nicht direkt Outbound Leaks, aber sie reduzieren Risiko bei Fehlkonfigurationen und schützen dein Netz vor „schlechten“ Routen. Dazu zählen RFC1918/Bogons und vor allem Max-Prefix, um Explosionen abzufangen.

• Bogons/Private Ranges inbound verwerfen (je nach Peering)
• Max-Prefix pro Provider setzen (Warnschwelle + Restart)
• Optional: RPKI/ROV invalid droppen (zusätzliche Sicherheit)

Max-Prefix (Standard-Guardrail)

router bgp 65000
 neighbor 203.0.113.1 maximum-prefix 100000 90 restart 5

Inbound Route-Map (Beispiel: RPKI invalid deny + LocalPref)

route-map RM_IN deny 5
 match rpki invalid
route-map RM_IN permit 10

set local-preference 200

Schicht 3: Redistribution kontrollieren – der häufigste Leak-Trigger

Viele Leaks kommen nicht aus dem Neighbor, sondern aus dem eigenen Router: jemand redistributet „connected“ oder „static“ ohne Filter ins BGP. Deshalb gilt: Redistribution nur mit Whitelist, Tagging und klarer Ownership.

Whitelist für Redistribution

ip prefix-list PL_REDIST_TO_BGP seq 10 permit 203.0.113.0/24
ip prefix-list PL_REDIST_TO_BGP seq 20 permit 198.51.100.0/24
ip prefix-list PL_REDIST_TO_BGP seq 100 deny 0.0.0.0/0 le 32

Route-Map mit Tagging

route-map RM_REDIST_TO_BGP permit 10
 match ip address prefix-list PL_REDIST_TO_BGP
 set tag 65001

Redistribution nur kontrolliert aktivieren

router bgp 65000
 redistribute connected route-map RM_REDIST_TO_BGP
 redistribute static route-map RM_REDIST_TO_BGP

Multi-Homing Spezialfall: Transit Leaks verhindern

Mit zwei Providern ist der gefährlichste Leak: du akzeptierst Full Table von Provider A und announcest sie (absichtlich oder unabsichtlich) an Provider B. Outbound Whitelist verhindert das zuverlässig – unabhängig davon, wie groß dein Inbound ist.

• Outbound Whitelist ist Pflicht bei Multi-Homing
• Keine „permit any“ Route-Maps outbound
• Communities/LocalPref sind TE, aber kein Leak-Schutz

Maximale Prefix-Länge und „More Specifics“ kontrollieren

Viele Leaks entstehen durch zu viele spezifische Prefixes (z. B. /32) aus Automation oder Fehlkonfiguration. Definiere daher erlaubte Prefix-Längen. Das gilt outbound (was du announcest) und inbound (was du akzeptierst), abhängig von deinem Vertrag/Use-Case.

Outbound nur bis /24 erlauben (Beispiel)

ip prefix-list PL_OWNED seq 10 permit 203.0.113.0/24
ip prefix-list PL_OWNED seq 20 deny 203.0.113.0/24 le 32

Operational Guardrails: Logging, Monitoring, Change-Disziplin

Filter schützen nur, wenn du erkennst, dass sie greifen. Deshalb sind Monitoring und Change-Prozesse Teil der Leak-Strategie: Route-Counts beobachten, Ankündigungen regelmäßig prüfen und jede BGP-Änderung mit Pre-/Post-Checks ausrollen.

• Route-Counts pro Peer (received/advertised) überwachen
• Syslog auf Policy-Events/Max-Prefix Trigger
• Pre/Post: advertised-routes prüfen

Verifikation: Was du nach jedem Change prüfst

show ip bgp summary
show ip bgp neighbors 203.0.113.1 advertised-routes
show ip bgp neighbors 203.0.113.1 received-routes
show route-map
show ip prefix-list

„Leak Drill“: Route Leak sicher testen (ohne Internet zu gefährden)

Wenn du testen willst, ob deine Schutzmechanismen funktionieren, tue das kontrolliert: in einem Lab, mit Test-Neighbor oder mit Communities, die der Provider nicht exportiert. In Produktion testest du primär über Counts und „advertised-routes“ – nicht durch absichtliches Leaken.

• Lab/Peering-Test: kontrollierter Neighbor
• Produktion: nur Sichtprüfung (advertised-routes) + Counts
• Rollback: Route-Map/Prefix-List sofort zurück

Typische Pitfalls: Warum Leaks trotz „Filter“ passieren

Leaky Konfigurationen entstehen oft durch fehlende Anwendung am Neighbor oder durch eine Route-Map, die unerwartet „permit“ trifft. Deshalb ist die Reihenfolge und die explizite Deny-Regel entscheidend.

• Route-Map nicht am Neighbor angewendet
• Prefix-List matcht breiter als gedacht (le/gt falsch)
• Route-Map Reihenfolge: deny kommt zu spät
• Redistribution ohne route-map (default erlaubt zu viel)

Quick-Template: Sichere Enterprise Edge Baseline (2 Provider)

Dieses Template verhindert Transit Leaks zuverlässig über Outbound Whitelist und ergänzt Max-Prefix. Passe Prefixes, Limits und Peers an.

ip prefix-list PL_ANY seq 5 permit 0.0.0.0/0 le 32
ip prefix-list PL_OWNED seq 10 permit 203.0.113.0/24
ip prefix-list PL_OWNED seq 20 permit 198.51.100.0/24
route-map RM_OUT permit 10

match ip address prefix-list PL_OWNED

route-map RM_OUT deny 100

match ip address prefix-list PL_ANY
router bgp 65000

neighbor 203.0.113.1 remote-as 64500

neighbor 198.51.100.1 remote-as 64501

neighbor 203.0.113.1 route-map RM_OUT out

neighbor 198.51.100.1 route-map RM_OUT out

neighbor 203.0.113.1 maximum-prefix 100000 90 restart 5

neighbor 198.51.100.1 maximum-prefix 100000 90 restart 5

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.