Site icon bintorosoft.com

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

Red Snapper

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.

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

Policy-Drift durch Templates und Automatisierung

Redistribution und VRF-Leaks

Fehlerhafte Community-Logik

Route Reflection / iBGP Propagation

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.

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

Schritt 2: „First Seen“-Beobachtung nutzen

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

Schritt 4: iBGP/Redistribution isolieren

Schritt 5: Eindämmen mit Low-Risk Mitigation

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?“

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

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

Praxis: sinnvolle Grenzwerte ableiten

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

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

Check 3: Community- und Policy-Sanity

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

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

Interne Netze tauchen im Upstream auf

Default Route wird unerwartet verteilt

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

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

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

Weiterführende Quellen für Standards und Praxis

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:

Lieferumfang:

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.

 

Exit mobile version