Route Leaks verhindern: Wie IP-Planung und Filter zusammenarbeiten

Route Leaks verhindern ist im Telco- und Provider-Umfeld eine Kernaufgabe, weil ein einziger Leak nicht nur den eigenen Betrieb stören kann, sondern im schlimmsten Fall auch andere Netze beeinflusst. Ein „Route Leak“ bedeutet, dass Routen in einen Routing-Kontext gelangen, in den sie nicht gehören – zum Beispiel Kundennetze, die plötzlich ins Internet exportiert werden, interne Management-Prefixe, die bei einem Peer auftauchen, oder VRF-Routen, die unkontrolliert zwischen Mandanten leaken. In der Praxis sind Route Leaks selten „ein einzelner Tippfehler“, sondern fast immer ein Zusammenspiel aus unklarem IP-Plan, zu breiten Filtern, fehlender Default-Deny-Logik und fehlender Governance. Wenn Prefixe nicht sauber nach Rollen (Public, Customer, MGMT, OAM, Services) getrennt sind, werden Filter zwangsläufig generisch („alles 10/8“, „alles aus dem AS“) – und generische Filter sind ein Einfallstor für Leaks. Umgekehrt gilt: Ein gut strukturierter IP-Adressplan ist die beste Grundlage für robuste Filter, weil er klare Containergrenzen schafft, die man technisch durchsetzen kann. Dieser Artikel zeigt praxisnah, wie IP-Planung und Filter zusammenarbeiten, um Route Leaks zu verhindern: Welche Prefix-Container Sie brauchen, wie Sie Import- und Export-Policies bauen, wie Sie VRF-Leaks kontrollieren, welche Rolle Communities spielen, und welche operativen Checks verhindern, dass Leaks überhaupt in die Produktion gelangen.

Was ist ein Route Leak – und welche Arten sind im Provider-Netz typisch?

Route Leak ist ein Oberbegriff für „Routen sind im falschen Kontext sichtbar“. Der Kontext kann ein externer BGP-Nachbar (Transit/Peering), ein interner BGP-Bereich (iBGP/RR), eine VRF oder ein Redistribution-Pfad (IGP ↔ BGP) sein. Für die Prävention ist wichtig, den Leak-Typ zu unterscheiden, weil die Gegenmaßnahmen unterschiedlich sind.

• External Leak (Internet): interne oder kundenbezogene Routen werden an Transits/Peers exportiert, obwohl sie nicht public sein sollen.
• Customer Leak: Provider exportiert fremde Routen an einen Kunden (ungewollter Transit) oder importiert zu breite Kundennetze.
• VRF Leak: Routen wandern zwischen VRFs/Mandanten, weil Leak-Listen zu breit sind oder VRF-Kontexte verwechselt werden.
• Internal Leak: falsche Redistribution oder falsche RR-Policy macht Routen global sichtbar, die nur lokal gedacht sind.
• Summary Leak: ein Summary deckt Bereiche ab, die nicht vollständig geroutet werden, und erzeugt damit Blackholes oder unerwünschte Exporte.

Warum IP-Planung die „erste Firewall“ gegen Route Leaks ist

Filter können nur so gut sein wie die Struktur, auf der sie basieren. Wenn Ihr IP-Adressplan klare Container und Rollenblöcke hat, können Sie Policies präzise formulieren: „Exportiere nur Prefixe aus Public-Containern“ oder „Leake nur diese Shared-Service-Prefixe“. Wenn Ihr Plan dagegen flach ist („10/8 überall“) oder Rollen vermischt (MGMT und Services im gleichen Block), müssen Filter raten. Und „raten“ ist im Routing immer gefährlich.

• Rollenblöcke trennen: Public, Customer, MGMT, OAM, Services, Loopbacks, P2P – jeweils eigene Prefix-Container.
• Scope definieren: Region/PoP/Cluster-Bindung verhindert, dass lokale Netze global exportiert werden.
• VRF-aware Planung: Overlaps sind nur in VRFs erlaubt, nicht „im globalen Netz“.
• Summarisierung geplant: Summaries folgen Containergrenzen, nicht zufälligen Präfixlücken.

IP-Plan-Struktur: Welche Prefix-Container Sie für Leak-sichere Policies brauchen

Ein praxistauglicher Provider-IP-Plan hat Container, die direkt zu Policy-Objekten werden können. Das Ziel ist: Filter und Allow-Lists referenzieren Container, nicht einzelne Prefixe. Das reduziert Fehler und hält Policies klein.

• Public Prefix Container: ausschließlich die Prefixe, die im Internet announced werden dürfen.
• Infrastructure Container: Loopbacks, P2P-Links, Core/Metro-Transport – niemals ins Internet exportieren.
• MGMT/OAM Container: Management und Monitoring – strikt getrennt, besonders leak-gefährlich.
• Service Container: interne Plattformen (DNS/NTP/AAA, DMZ), die nur kontrolliert erreichbar sein sollen.
• Customer Containers: pro VRF/Tenant oder pro Produktklasse, um VRF-Leaks kontrollierbar zu machen.
• Quarantine/Deprecated: Netze, die nicht mehr genutzt werden, aber noch nicht recycelt sind (verhindert „Zombie“-Exporte).

Default-Deny ist Pflicht: Export-Policies in Provider-Netzen

Die wichtigste Regel gegen Route Leaks lautet: Export ist default-deny. Das gilt besonders an ASBRs (Edge-Routern) zu Transits und Peers. Statt „alles exportieren, außer …“ sollten Sie „nichts exportieren, außer …“ umsetzen. Damit wird ein neuer Prefix nicht automatisch öffentlich, nur weil er „irgendwo“ geroutet ist.

• Export-Allow-List: nur Public-Container (und ggf. bewusst definierte Anycast-/Service-Prefixe) dürfen raus.
• Längenfilter: nur sinnvolle Präfixlängen exportieren (z. B. keine zu spezifischen Prefixe ohne Zweck).
• Community-Gates: „announce-to-transit“, „announce-to-peer“, „no-export“ als klare Schalter.
• Blackhole-Mechanismus separat: wenn Sie BGP-Blackholing nutzen, muss es klar getrennt und auditierbar sein.

Import-Policies: Leaks verhindern, bevor sie im Netz sind

Lecks werden oft erst sichtbar, wenn sie bereits im Core propagiert sind. Daher sind Import-Policies die zweite Schutzschicht: Sie begrenzen, was Sie überhaupt annehmen. Das ist bei Kunden, Partnern und auch bei internen Leaks (z. B. falsches Redistribution) relevant.

• Kunden-Import: nur die Prefixe, die der Kunde haben darf (vertraglich/technisch), plus Max-Prefix Limits.
• Peer/Transit-Import: klare Regeln (voller Table oder gefiltert), Hygiene für Communities, Bogon-Filter.
• Next-Hop Validierung: unreachable next-hops oder unerwartete Sources sind Warnsignale für Leaks/Misconfig.
• RPKI (wo eingesetzt): reduziert Hijack/Leak-Risiko, ersetzt aber keine Policy-Struktur.

VRF-Leaks kontrollieren: Allow-List statt „alles 10/8“

In Multi-Tenant-Telco-Services sind Overlapping RFC1918-Netze normal. Leaks zwischen VRFs sind der häufigste Weg, wie Overlaps „krachend“ werden. Die wichtigste Regel lautet: Inter-VRF-Leaks werden als Allow-List geführt – vorzugsweise nach Services, nicht nach großen Adressblöcken.

• Shared Services definieren: DNS/NTP/AAA/Monitoring als klarer Servicekatalog mit eigenen Prefixen.
• Leak-Policy minimal: nur notwendige Prefixe leaken, keine Summaries wie 10.0.0.0/8.
• Policy-Punkt klar: idealerweise über Firewall/Policy-Gateway; Route Leaks allein sind selten „sicher genug“.
• VRF-aware Dokumentation: jedes Prefix hat VRF, Owner, Scope, Status.

Communities als Sicherheitsgurt: Policies zentral steuern

Communities sind im Provider-Alltag ein extrem wirksames Werkzeug, um Routen zu klassifizieren und Policy-Entscheidungen konsistent zu machen. In Leak-Prävention sind Communities besonders nützlich, um „woher kommt diese Route“ und „wo darf sie hin“ in eine maschinenlesbare Form zu gießen.

• Origin-Tags: Kundenrouten, interne Routen, Public-Prefixe bekommen unterschiedliche Communities am Ursprung.
• Export-Tags: „no-export“, „peer-only“, „transit-only“ verhindern unbeabsichtigte Verbreitung.
• Scope-Tags: Region/PoP-Communities helfen, lokale Routen nicht global zu verteilen.
• Hygiene-Regel: externe Communities nicht ungeprüft übernehmen; interne Tags sollten kontrolliert vergeben werden.

Summaries und Null-Routes: Leak-Prävention vs. Blackhole-Risiko

Summaries reduzieren Routingtabellen und können Leaks sogar verhindern, indem sie die Zahl der exportierten Prefixe verringern. Gleichzeitig sind sie eine der häufigsten Quellen für Blackholes, wenn Details nicht konsistent sind. Daher sollte ein Leak-sicheres Design Summaries nur entlang echter Containergrenzen erlauben und Null-Routes bewusst einsetzen.

• Summary nur mit Hierarchie: summarisiere nur, wenn der Block vollständig „dir gehört“ (Public-Container) oder bewusst kontrolliert wird.
• Null-Route als Schutz: verhindert zufälliges Routing in „Lücken“, aber kann blackholen, wenn Detailrouten fehlen.
• Migration-Risiko: bei Renumbering/Umzügen müssen Summary und Details synchron bleiben.
• Audit-Punkt: jede Summary-Änderung ist ein Change mit Preflight-Check.

Operative Schutzmechanismen: Preflight, Monitoring und Drift Detection

Selbst mit gutem IP-Plan und guten Filtern passieren Leaks, wenn Prozesse fehlen. Erfolgreiche Telcos bauen deshalb neben Designregeln auch operative Kontrollen auf, die Leaks früh erkennen oder verhindern.

• Preflight-Checks vor Changes: „Welche Prefixe würden neu exportiert?“ „Welche VRF-Leaks ändern sich?“
• Automatische Overlap-Prüfung: Prefixe und Summaries dürfen sich nicht unbeabsichtigt schneiden (VRF-aware).
• Export-Simulation: prüfen, ob nur Public-Container an Transits/Peers gehen.
• Monitoring auf Anomalien: plötzlicher Prefix-Anstieg, neue Prefix-Längen, unerwartete Origin-AS oder Communities.
• Drift Detection: Config↔Source-of-Truth Abgleich (Policies und Prefix-Container) verhindert „Shadow Rules“.

Typische Leak-Ursachen in der Praxis und wie IP-Planung sie entschärft

• „Alles 10/8“ als Leak-Regel: entsteht, wenn Rollenblöcke nicht getrennt sind → Container-Struktur zwingt zu präzisen Allow-Lists.
• Neue Netze werden automatisch exportiert: „permit any“ Export → Default-Deny und Public-Container verhindern das.
• Kunden werden ungewollt Transit: fehlende no-transit Defaults → Community- und Policy-Standard pro Kundenklasse.
• VRF-Verwechslung: Prefix ohne VRF-Metadaten → VRF-aware IPAM und Naming-Standards reduzieren Fehler.
• Summary deckt fremde Netze ab: fehlende Hierarchie → Summaries nur entlang Containergrenzen, mit Review.

Praxis-Checkliste: Route Leaks verhindern mit IP-Planung und Filtern

• IP-Plan rollenbasiert strukturieren: separate Prefix-Container für Public, Infra, MGMT, OAM, Services, Customer/VRFs.
• Export default-deny: nur Public-Container exportieren, keine catch-all Regeln, Längenfilter bewusst.
• Import kontrollieren: Kunden nur erlaubte Prefixe + Max-Prefix; Peer/Transit Hygiene und Schutzfilter.
• VRF-Leaks als Allow-List: nur definierte Shared Services leaken, keine großen Summaries wie 10/8.
• Communities standardisieren: Origin-, Scope- und Export-Communities mit klarer Semantik und Governance.
• Summaries bewusst einsetzen: nur entlang echter Containergrenzen, Null-Routes mit Vorsicht und Dokumentation.
• Preflight-Checks und Simulation: vor Changes prüfen, welche Prefixe neu exportiert oder geleakt würden.
• Monitoring und Drift Detection: Alarme auf Prefix-Anstieg, neue Längen, unerwartete Exporte; Config↔SoT Abgleich.
• Versionierung: IP-Plan und Policy-Änderungen nachvollziehbar machen, damit Root Cause im Incident schnell erkennbar ist.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.