BGP Route Leaks erkennen: Prefix Filter, Max-Prefix und Hygiene Checks

BGP Route Leaks erkennen ist eine der wichtigsten Disziplinen im Betrieb von WAN- und Internet-Edge-Netzen, weil ein einziger Leak innerhalb von Sekunden massive Auswirkungen haben kann: unerwartete Umwege über teure Transits, Blackholing durch falsche Defaults, Überlastung von Firewalls/Edges, oder im schlimmsten Fall globale Erreichbarkeitsprobleme, wenn versehentlich fremde Präfixe weiterpropagiert werden. Das Tückische: Eine BGP-Session kann dabei völlig „gesund“ aussehen (Established, stabile Timer), während im Hintergrund die falschen Routen verteilt werden. Genau deshalb braucht es Hygiene Checks, die nicht erst im Incident greifen, sondern dauerhaft als Sicherheitsnetz laufen: Prefix Filter (Inbound und Outbound), Max-Prefix Limits mit sinnvollen Warnschwellen, sowie saubere Routing-Policy-Governance (Communities, Route-Maps, Templates, Change-Kontrolle). In diesem Artikel lernen Sie, wie BGP Route Leaks typischerweise entstehen, wie Sie sie schnell erkennen und beweisen, welche Filter- und Limit-Strategien sich in der Praxis bewährt haben und wie Sie eine robuste Baseline aufbauen, damit ein Leak nicht zum Großereignis wird.

Was ist ein BGP Route Leak – und warum es operativ so gefährlich ist

Ein BGP Route Leak liegt vereinfacht vor, wenn ein Router Präfixe an einen Peer ankündigt, die er nicht ankündigen sollte. Das kann versehentlich passieren (Policy-Fehler, falsches Template, fehlender Filter) oder als Folge einer Kettenreaktion (Redistribution, VRF-Leak, Default-Leak). Das Gefährliche ist weniger das einzelne Präfix, sondern die Skalierung: Wenn ein Leak tausende oder hunderttausende Routen umfasst, überlastet das Control Plane, triggert Max-Prefix, führt zu Session Resets und kann dadurch sekundäre Ausfälle erzeugen.

• Inbound Leak: Sie akzeptieren zu viele oder falsche Routen von einem Peer (z. B. ein Kunde sendet Full Table).
• Outbound Leak: Sie announcen zu viele oder falsche Routen zu einem Peer (z. B. Sie leaken interne Präfixe ins Internet).
• Transitive Leaks: Sie nehmen Routen von Peer A an und propagieren sie ungewollt zu Peer B (klassischer „Kunde wird Transit“ oder „Peer wird Transit“).

Für das BGP-Grundverhalten (Sessions, UPDATEs, Attribute, Decision Process) ist RFC 4271 die zentrale Referenz.

Typische Ursachen: Wie Route Leaks in der Praxis wirklich entstehen

Route Leaks sind selten „mysteriös“. Fast immer gibt es eine konkrete Ursache, die sich in wiederkehrende Klassen einordnen lässt. Wer diese Klassen kennt, findet im Incident schneller die richtige Stelle.

Fehlende oder zu breite Prefix-Filter

• Inbound: Ein Kunde oder Partner sendet plötzlich mehr Präfixe als vereinbart, und Ihr Router akzeptiert alles.
• Outbound: Ein Router announct „alles, was er kennt“, weil eine Route-Map zu generisch ist oder ein Default-Statement fehlt.

Policy-Drift durch Templates und Automatisierung

• Template nicht angewendet: Ein neuer Peer bekommt keine Filter, weil ein Automationsschritt fehlschlägt.
• Falsches Template: Ein Customer-Peer wird wie ein Transit-Peer behandelt (oder umgekehrt).
• Unbeabsichtigte Änderung: Ein „kleiner“ Change an einer Community-Policy wirkt plötzlich auf viele Peers.

Redistribution und VRF-Leaks

• IGP → BGP Leak: Interne Routen werden in BGP redistribuiert und anschließend nach außen announced.
• VRF → Global Leak: Routen aus einem isolierten Tenant-/Kunden-VRF landen in der globalen Tabelle.
• Default-Leak: Ein Default wird in eine Domäne injiziert, in der er nicht sein darf, und zieht Traffic in ein Blackhole.

Fehlerhafte Community-Logik

• Communities entfernt: Ein Transit/Upstream erwartet Communities zur Steuerung (z. B. NO_EXPORT), die plötzlich fehlen.
• Falsche Communities gesetzt: Routen werden unerwartet weiterverteilt, weil sie als „exportable“ markiert werden.
• Community-Matching zu breit: Eine Regel matcht „alles“ und setzt Attribute, die Leaks begünstigen.

Route Reflection / iBGP Propagation

• RR-Policy Fehler: Ein Route Reflector spiegelt Routen in eine Region, die sie nicht sehen darf.
• AFI/SAFI Mismatch: IPv6 oder VPNv4 wird unerwartet in einen Peer exportiert.

Früherkennung: Welche Signale zeigen einen Route Leak zuverlässig an

Route Leaks fallen selten zuerst durch „Ping geht nicht“ auf. Häufig sind es Control-Plane-Signale, die Sekunden bis Minuten früher anschlagen. Genau hier sollte Ihre Observability ansetzen.

• Sprunghafter Anstieg der empfangenen Routen: „Received Prefixes“ steigt stark innerhalb kurzer Zeit.
• Max-Prefix Warnungen: Warnschwellen werden überschritten, bevor die Session hart geschlossen wird.
• CPU/Memory Peaks auf Edge/RR: BGP-Processing, RIB-to-FIB Updates, Route Refresh Aktivitäten.
• Viele Updates pro Sekunde: ungewöhnlich hohe Update-Raten oder dauerhafte Churn.
• Änderung des Pfadverhaltens: Traffic nimmt unerwartete Exits (LocalPref/AS-PATH kippt), Latenz steigt.
• Session Resets in Kaskade: Max-Prefix oder Ressourcen führen zu mehreren Peer-Resets nacheinander.

Operative Faustregel: Wenn „prefix count“ und „update rate“ gleichzeitig hochgehen, ist ein Leak oder eine massive Routing-Änderung sehr wahrscheinlich. Dann zählt Zeit: erst eindämmen, dann sauber forensisch analysieren.

Beweiskette im Incident: So lokalisieren Sie die Leak-Quelle

Ein Route Leak lässt sich schnell eingrenzen, wenn Sie konsequent eine Beweiskette aufbauen. Ziel ist nicht, sofort den perfekten Fix zu bauen, sondern in Minuten zu klären: Kommt das Leak von einem Peer, aus dem eigenen iBGP/IGP, oder aus einem VRF/Redistribution-Pfad?

Schritt 1: Umfang und Richtung bestimmen

• Ist der Leak inbound (wir bekommen zu viel) oder outbound (wir senden zu viel)?
• Betrifft es einen Peer oder mehrere?
• Ist es Full Table, Default oder eine spezifische Präfixgruppe?

Schritt 2: „First Seen“-Beobachtung nutzen

• Welcher Router/Peer hat die Routen zuerst gesehen?
• Ist es ein Customer Edge, ein Route Reflector oder ein Internet Edge?
• Erlaubt Ihre Telemetrie „Top-N new prefixes“ oder „new best paths“?

Schritt 3: AS-PATH und Next-Hop Muster prüfen

• AS-PATH plötzlich extrem kurz oder „leer“? (Verdacht auf Default oder falsch generierte Origination)
• Viele Präfixe mit identischem Next Hop aus einer Richtung? (Hinweis auf einen einzelnen Leak-Injector)
• Unerwartete private ASNs, ungewöhnliche Communities, falsche Origin Codes?

Schritt 4: iBGP/Redistribution isolieren

• Erscheinen die geleakten Präfixe als „locally originated“ oder als „learned“?
• Gibt es eine Redistribution-Regel, die „alles“ in BGP injiziert?
• Gibt es VRF Import/Export Targets, die Routen plötzlich freigeben?

Schritt 5: Eindämmen mit Low-Risk Mitigation

• Wenn Leak eindeutig von einem Peer kommt: Inbound Filter schärfen oder Peer temporär dämpfen (z. B. Policy deny, ggf. Session down als Notmaßnahme).
• Wenn Leak von eigener Policy kommt: Outbound Filter sofort fixen oder Announcement stoppen (temporär), um externe Auswirkungen zu minimieren.
• Wenn Control Plane bedroht ist: Max-Prefix greifen lassen oder Warnschwellen nutzen und gezielt isolieren, statt global alles neu zu starten.

Prefix Filter: Der wichtigste Schutz gegen Route Leaks

Prefix Filter sind die wirksamste Hygiene-Maßnahme gegen Leaks, weil sie die Menge und Art der akzeptierten/gesendeten Routen direkt begrenzen. Dabei gilt eine wichtige Unterscheidung: Inbound Filter schützen Sie vor fremden Fehlern. Outbound Filter schützen andere vor Ihren Fehlern und sind damit ein zentraler Bestandteil von Netzverantwortung.

Inbound Prefix Filtering: „Was darf dieser Peer mir geben?“

• Kunden: nur die Präfixe, die der Kunde besitzt oder vertraglich angekündigt hat
• Peers: nur die Präfixe, die Sie laut Peering erwarten (häufig breit, aber dennoch policy-basiert)
• Transits: typischerweise sehr viele Präfixe, aber mit klaren Sicherheitsregeln (RPKI, bogon filtering, max-prefix)

Outbound Prefix Filtering: „Was darf ich an diesen Peer announcen?“

• Kunden: meist Default oder ausgewählte Routen (je nach Service), nie fremde Kunden als Transit ohne Design
• Peers: nur eigene und Kundenpräfixe (je nach Policy), niemals Full Table ohne Vertrag
• Transits: nur eigene und Kundenpräfixe, keine internen Infrastrukturpräfixe (Management, Loopbacks, private Netze)

Hygiene-Check: Bogons, Private Space, „Never Announce“

Ein häufig unterschätzter Schutz ist eine explizite „Never Announce“-Liste: RFC1918, Link-Local, Dokumentationsnetze, interne Loopbacks und Management-Netze dürfen niemals nach außen. Das ist keine „optional Policy“, sondern Basishygiene. Eine Übersicht zu privaten IPv4-Netzen liefert RFC 1918.

Max-Prefix: Schutznetz gegen Full-Table-Unfälle und Leaks

Max-Prefix Limits sind die „Airbags“ im BGP-Betrieb. Sie verhindern, dass ein Peer Ihnen unendlich viele Routen injiziert oder dass ein Policy-Fehler Ihre Control Plane überrollt. Richtig eingesetzt bestehen Max-Prefix Limits aus drei Elementen: realistischem Grenzwert, Warnschwelle und klarer Incident-Response.

Warum Max-Prefix nicht nur „eine Zahl“ ist

• Zu niedrig: unnötige Session Resets bei normalen Routing-Wachstumsphasen oder bei Wartungen
• Zu hoch: Schutzwirkung gering, Control Plane kann bereits leiden, bevor Max-Prefix greift
• Ohne Warnschwelle: erste Sichtbarkeit ist ein harter Reset – das ist operativ zu spät

Praxis: sinnvolle Grenzwerte ableiten

• Kundenpeers: Grenzwert basierend auf vertraglich erwarteten Präfixen + definierter Puffer
• Peers: Grenzwert basierend auf historischen Counts + Wachstumsmarge
• Transits: Grenzwert nahe Full Table + Puffer; Warnschwelle für plötzliche Sprünge

Max-Prefix als Leak-Indikator

Wenn Max-Prefix triggert, ist die erste Frage selten „Limit erhöhen“, sondern „Warum sind plötzlich so viele Präfixe da?“. In der Praxis ist Max-Prefix häufig der zuverlässigste Hinweis auf einen beginnenden Leak, bevor Nutzer überhaupt etwas merken.

Hygiene Checks: Die täglichen/wochentäglichen Kontrollen, die Leaks verhindern

Route Leaks lassen sich stark reduzieren, wenn Sie wiederkehrende Hygiene Checks etablieren. Diese Checks sind bewusst simpel, aber hochwirksam, weil sie Drift und unerwartete Änderungen sichtbar machen.

Check 1: Route Counts pro Peer als Baseline

• Empfangene und gesendete Prefix Counts pro Peer (Trend + Perzentile)
• Alarm bei sprunghaften Änderungen (z. B. +20% in 5 Minuten)
• Vergleich über Standorte/Edges, um Anycast/ECMP-Effekte zu erkennen

Check 2: Top-N neue Präfixe und „unerwartete“ Routen

• Neue Präfixe nach Change-Fenstern überprüfen
• Präfixe außerhalb des eigenen IPAM-/RIR-Inventars markieren
• Unerwartete Default-Origination erkennen (0.0.0.0/0 oder ::/0)

Check 3: Community- und Policy-Sanity

• Wird NO_EXPORT/NO_ADVERTISE korrekt gesetzt/erhalten?
• Werden „blackhole“-Communities nur gezielt genutzt?
• Werden Communities unerwartet entfernt (z. B. an Route Reflectors)?

Check 4: RPKI/ROV und Präfix-Validierung (wenn im Design)

RPKI-basierte Route Origin Validation (ROV) ist nicht die Lösung für alle Leaks, aber ein sehr starker Zusatzschutz gegen falsche Origination. Wenn Ihr Netz RPKI nutzt, sollten Invalid/NotFound-Raten in die Hygiene Checks. Für einen Einstieg in RPKI/ROV ist die Dokumentation von RIPE NCC zu RPKI eine gute externe Referenz.

Check 5: Change-Governance und Peer-Templates

• Peer-Templates statt „handcrafted configs“ pro Peer
• Automatische Validierung: Prefix-Lists/Route-Maps vorhanden, Max-Prefix gesetzt, Logging aktiv
• Pre-Change Simulation: erwartete Prefix Counts und Policy-Impact (auch grob) dokumentieren

Route Leak Musterkatalog: Schnelle Zuordnung im Incident

Die folgenden Muster helfen, innerhalb weniger Minuten von Symptomen zur wahrscheinlichsten Ursache zu kommen.

Plötzlich „Full Table“ von einem Kunden

• Indiz: Received Prefixes bei Kundenpeer explodiert
• Wahrscheinliche Ursache: Kunde hat Transit falsch konfiguriert oder redistributed Default/IGP in eBGP
• Mitigation: Inbound Prefix-Filter + Max-Prefix greift, Session ggf. isolieren

Interne Netze tauchen im Upstream auf

• Indiz: Private/Management-Präfixe werden outbound announced
• Wahrscheinliche Ursache: Outbound Policy zu breit, Redistribution falsch, VRF-Leak
• Mitigation: Never-Announce Filter sofort schärfen, Announcements zurückziehen

Default Route wird unerwartet verteilt

• Indiz: 0.0.0.0/0 oder ::/0 erscheint bei Peers, die ihn nicht bekommen sollen
• Wahrscheinliche Ursache: Default-Origination Template falsch, Community-Trigger fehlerhaft
• Mitigation: Outbound Default strikt kontrollieren, Communities/Route-Maps prüfen

Routes „springen“ zwischen Exits, Traffic wird teuer/langsam

• Indiz: LocalPref/AS-PATH/MED Änderung, Exit wechselt
• Wahrscheinliche Ursache: Policy-Change oder Leak, der neue „bessere“ Pfade vortäuscht
• Mitigation: Policy revert oder temporäre Stabilisierung (z. B. LocalPref fixieren), dann Root Cause

Runbook-Baustein: BGP Route Leaks in 15 Minuten erkennen und eindämmen

• Minute 0–3: Scope klären: Welche Peers, welche Route Counts, welcher Zeitpunkt? Inbound vs. Outbound Leak entscheiden.
• Minute 3–6: Quantifizieren: Prefix Count Sprung, Update Rate, Top-N neue Präfixe, Default vorhanden?
• Minute 6–9: Quelle lokalisieren: „first seen“ Router/Peer, AS-PATH/Next-Hop Muster, Communities/Origin prüfen.
• Minute 9–12: Mitigation: Inbound Prefix-Filter/Max-Prefix nutzen oder Outbound Announcements stoppen; Control Plane schützen, kein globales „clear all“.
• Minute 12–15: Fix-Richtung: Policy/Template korrigieren, Redistribution/VRF-Leak schließen, Hygiene Checks aktualisieren; danach Verifikation über stabile Prefix Counts und erwartete Announcements.

Stabile Baselines: So wird Leak-Prävention zum Standardbetrieb

• Vertragliche Präfixlisten: pro Kunde/Peer dokumentiert und in Prefix-Lists gegossen
• Never-Announce Listen: RFC1918/Management/Loopbacks grundsätzlich outbound blocken
• Max-Prefix mit Warnschwelle: nicht als „Strafe“, sondern als Frühwarnsystem
• Peer-Templates und Drift-Checks: gleiche Hygiene auf jedem Peer, automatisiert validiert
• Dashboards: Prefix Counts, Update Rates, invalid/filtered counts, session resets, CoPP drops
• Change-Prozess: Policy-Änderungen versioniert, reviewt, mit Rollback und erwarteter Wirkung

Weiterführende Quellen für Standards und Praxis

• RFC 4271 für BGP-4 Grundlagen und Route Processing
• RFC 1997 für BGP Communities (wichtig für Policy-Hygiene)
• RFC 2385 für TCP MD5 Signatures (Sitzungssicherheit als Baseline)
• RFC 1918 für private IPv4-Adressräume (Never-Announce Hygiene)
• RIPE NCC RPKI Dokumentation als praxisnaher Einstieg in RPKI/ROV zur Leak-Reduktion
• RFC Editor als zentrale Quelle für Protokollstandards

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.