Route Leak: Detection über Prefix Count und Monitoring

Ein Route Leak ist einer der gefährlichsten Fehler im Internet-Routing, weil er „leise“ starten und in Minuten global eskalieren kann: Plötzlich werden Routen in die falsche Richtung propagiert, Traffic nimmt unerwartete Pfade, Latenz steigt, Congestion verschiebt sich, und im schlimmsten Fall entsteht ein großflächiger Outage durch Überlast oder Blackholing. Operativ ist das Problem tückisch, weil die BGP-Session dabei oft stabil bleibt. Es gibt kein klares „Link down“, sondern eine schleichende Veränderung der Routing-Wahrheit. Genau deshalb ist Route-Leak-Detection über Prefix Count und Monitoring so wirkungsvoll: Wenn Sie wissen, wie viele Präfixe ein Peer normalerweise sendet und wie sich diese Zahl typischerweise verhält, können Sie Leaks sehr früh erkennen – oft bevor Kunden Impact melden. Eine saubere Prefix-Count-Überwachung ersetzt keine inhaltliche Filterung (RPKI/IRR, Prefix-Listen), aber sie ist ein extrem praktischer Frühindikator und eine zuverlässige „Guardrail“ gegen Fehlkonfigurationen, Automationsfehler und Missverständnisse bei Peering-Policies. Dieser Leitfaden zeigt praxisnah, wie Route Leaks entstehen, welche Prefix-Count-Signaturen typisch sind, wie man Schwellenwerte sinnvoll setzt, wie man False Positives minimiert und wie man Prefix Count mit weiteren Monitoring-Signalen kombiniert, um einen Leak nicht nur zu erkennen, sondern auch schnell zu lokalisieren und zu stoppen.

Was ist ein Route Leak und warum ist es operativ so kritisch?

Unter einem Route Leak versteht man vereinfacht: Routen werden an einen Nachbarn angekündigt, für den sie nicht bestimmt sind. Das kann verschiedene Formen annehmen, etwa wenn ein Kunde (Customer) plötzlich Transit-Routen an einen Provider oder an einen Peer weitergibt, oder wenn ein Peer-Routing in Richtung eines anderen Peers „durchgereicht“ wird. In BGP ist das gefährlich, weil die Policy-Logik (wer darf was an wen announcen) entscheidend ist – und weil BGP nicht automatisch erkennt, ob eine Route „logisch unzulässig“ ist. BGP verteilt das, was man ihm gibt, sofern Filter und Policies es erlauben. Grundlagen zu BGP finden sich in RFC 4271; der Begriff „Route Leak“ wird in operativen Best Practices und RFCs zur Policy-Absicherung diskutiert, etwa im Kontext von Roles und Leaking in RFC 9234 (Route Leak Prevention and Detection Using Roles in BGP).

• Warum kritisch: Route Leaks verschieben Traffic großflächig und unvorhersehbar.
• Warum schwer zu debuggen: Sessions sind oft „up“, und die Auswirkungen zeigen sich verteilt (Latenz/Überlast an anderer Stelle).
• Warum Prefix Count hilft: Ein Leak erzeugt häufig einen sprunghaften Anstieg oder einen untypischen Verlauf der akzeptierten/empfangenen Präfixanzahl.

Typische Ursachen für Route Leaks

In der Praxis entstehen Route Leaks selten durch „BGP ist kaputt“, sondern durch menschliche oder automatisierte Policy-Fehler. Die häufigsten Ursachenklassen sind:

• Fehlende oder falsche Import-/Export-Filter: Prefix-Listen, Route-Maps/Policies sind zu breit oder falsch zugewiesen.
• Rollentausch in Templates: Ein Customer-Template wird wie ein Peer-Template angewendet (oder umgekehrt).
• Automationsfehler: falsche Objektzuordnung, falsche Community-Setzung, falscher „apply“-Scope.
• Redistribution/Leak zwischen VRFs: interne Leaks führen zu externen Leaks, wenn Policies nicht trennen.
• Max-Prefix/Schutzmechanismen falsch konfiguriert: Limits fehlen oder sind so hoch, dass sie keinen Schutz bieten.
• Missverständnisse beim Peering: „Wir announcen euch nur unsere Kunden“ vs. „wir announcen euch alles, was wir haben“.

Warum Prefix Count als Frühindikator so gut funktioniert

Ein Route Leak verändert typischerweise nicht ein einzelnes Präfix, sondern eine große Menge an Routen, die plötzlich „durchgereicht“ wird. Das ist gerade bei Customer-Leaks häufig: Ein Kunde beginnt, Transit-Routen zu announcen, die er von einem Upstream lernt. Für den Provider sieht das aus wie „auf einmal kommen viel mehr Präfixe aus dieser Session“. Selbst wenn die Routes technisch valide sind, sind sie policy-widrig. Prefix Count greift hier als schnelle Abweichungserkennung.

• Skaleneffekt: Leaks sind häufig massenhaft – die Präfixanzahl springt.
• Unabhängig vom Traffic: Auch wenn noch kein Traffic verschoben wurde, ist die Route-Menge bereits sichtbar.
• Einfach messbar: BGP liefert klare Zähler: received/accepted/advertised prefixes.

Welche Prefix Counts Sie wirklich überwachen sollten

Prefix Count ist nicht gleich Prefix Count. Für operativ belastbare Detection sollten Sie die Zähler trennen – denn ein Leak kann sich in „received“ zeigen, aber durch Filter nicht in „accepted“. Oder umgekehrt: Filter fehlen, dadurch wird alles akzeptiert, aber „advertised“ steigt erst nach Policy-Propagation.

• Received Prefixes: Anzahl der vom Nachbarn empfangenen Präfixe (pre-policy).
• Accepted/Installed Prefixes: Anzahl der nach Policy akzeptierten Präfixe (post-policy), ggf. im Loc-RIB.
• Advertised Prefixes: Anzahl der an den Nachbarn angekündigten Präfixe (wichtig, um „wir leaken nach außen“ zu erkennen).
• Withdraw Rate: Anzahl Withdraws pro Zeitfenster (Leak kann auch massenhaft Withdraws erzeugen).

Grundformel: Abweichung und Schwellwert

Damit Prefix Count nicht zu Alarmrauschen führt, brauchen Sie eine definierte Abweichungslogik. Eine einfache, gut kommunizierbare Heuristik ist der Vergleich „aktueller Wert vs. Baseline“ (z. B. gleitender Durchschnitt oder Median) mit prozentualem und absolutem Schwellwert.

Delta und relative Abweichung (MathML)

$\Delta P=P\_\mathrm{current}-P\_\mathrm{baseline}$
$\mathrm{RelDev}=\frac{\mathrm{|\Delta P|}}{P\_\mathrm{baseline}}$

Operativ bewährt sich eine kombinierte Schwelle, damit kleine Sessions nicht „überreagieren“ und große Sessions nicht „durchrutschen“.

Kombinierte Alarmbedingung (MathML)

$\mathrm{Alert}\Leftarrow \mathrm{|\Delta P|}\ge P\_\mathrm{abs}\wedge \mathrm{RelDev}\ge P\_\mathrm{rel}$

Baselines richtig bauen: Damit Prefix Count nicht „schreit“

Eine gute Baseline ist der Unterschied zwischen einem nützlichen Alarm und permanentem Noise. In Peering-Umgebungen schwanken Prefix Counts normal, etwa durch Upstream-Events, Traffic Engineering, Policy-Updates oder Routenflaps. Ziel ist nicht, jede Veränderung zu alarmieren, sondern untypische, riskante Veränderungen.

• Median statt Mittelwert: Der Median ist robuster gegen Ausreißer (z. B. kurzfristige Route-Stürme).
• Gleitendes Zeitfenster: z. B. 7 Tage oder 30 Tage – abhängig davon, wie stabil das Peer-Routing ist.
• Separat nach Session-Typ: Customer vs. Peer vs. Transit haben unterschiedliche Normalwerte.
• Warm-up bei neuen Sessions: Neue Peerings brauchen erst eine Lernphase, bevor harte Alarme sinnvoll sind.

Route-Leak-Signaturen im Prefix Count

Ein Route Leak hat oft ein typisches „Fingerprint“-Verhalten. Diese Muster helfen, schnell die richtige Hypothese zu wählen.

Signatur 1: Plötzlicher, großer Sprung nach oben bei einem Customer

• Typisch: Customer announct plötzlich (fast) Full Table oder große Teile davon.
• Prefix-Count-Muster: received und accepted steigen in kurzer Zeit stark an.
• Interpretation: Sehr hoher Leak-Verdacht, besonders wenn Customer historisch nur wenige Präfixe hatte.

Signatur 2: Received steigt, accepted bleibt gleich

• Typisch: Der Nachbar sendet zu viel, aber Ihre Filter blocken korrekt.
• Prefix-Count-Muster: received springt, accepted stabil.
• Interpretation: Kein unmittelbarer Leak in Ihr Netz, aber ein starker Hinweis, dass der Nachbar ein Problem hat (Eskalationsfall).

Signatur 3: Advertised Prefixes steigen unerwartet

• Typisch: Ihr Router leakt Routen nach außen (Fehler in Export-Policy, Route-Leak zwischen VRFs, falsches Community-Handling).
• Prefix-Count-Muster: advertised steigt bei einem Peer/Transit deutlich über die Baseline.
• Interpretation: Hochkritisch, da Sie selbst zum Leak-Quelle werden können.

Signatur 4: Massives „Up/Down“ (Churn) ohne dauerhafte Änderung

• Typisch: Route Oscillation, instabile Upstream-Policy, fehlerhafte Session, oder Schutzmechanismen wie Max-Prefix greifen und resetten.
• Prefix-Count-Muster: Prefix Count pendelt stark, Withdraw Rate hoch.
• Interpretation: Gefahr für Konvergenz, CPU-Spikes, potenzieller Vorläufer eines Leak-Ereignisses.

Monitoring-Design: Prefix Count allein reicht nicht

Prefix Count ist ein hervorragender Frühindikator, aber für eine robuste Detection sollten Sie ihn mit weiteren Signalen kombinieren. Das reduziert False Positives und beschleunigt die Ursachenanalyse.

• Max-Prefix-Events: ob Thresholds oder Hard Limits ausgelöst wurden (Schutz vs. Symptom).
• Update/Withdraw Rate: massenhaft Updates/Withdraws sind ein Zeichen für Instabilität oder Leak-Propagation.
• AS-PATH-Statistik: ungewöhnliche neue ASNs in der Learned-Set (z. B. plötzlich viele Transits aus einem Customer).
• Community-Muster: fehlen erwartete Communities (z. B. „no-export“), oder erscheinen neue Communities, die Policy verändern.
• Traffic-Shift-Indikatoren: NetFlow/IPFIX oder Interface-Auslastung an Peering-Ports, um Impact zu bestätigen.

Praktisches Alerting: Schwellenwerte nach Peering-Rolle

Ein ISP/NOC profitiert davon, unterschiedliche Alarmprofile pro Session-Typ zu definieren. Ein Customer sollte meist nur „seine“ Präfixe senden; ein Transit sendet sehr viele. Ein Peer liegt dazwischen.

• Customer Sessions: sehr strenge absolute und relative Limits; kleine Baseline, starke Sensitivität.
• Peer Sessions: moderate Limits; Baseline kann schwanken, aber große Sprünge sind verdächtig.
• Transit Sessions: eher auf relative Veränderungen und Churn (Update/Withdraw Rate) achten; absolute Zahl ist groß, kleine Schwankungen sind normal.

Route Leak Detection mit Prefix Count in der Praxis: Step-by-Step

Wenn ein Prefix-Count-Alarm auslöst, sollte das NOC nicht improvisieren. Ein standardisierter Ablauf verhindert Fehler und verkürzt die Zeit bis zur Mitigation.

Schritt: Alarm klassifizieren

• Welche Richtung? received, accepted oder advertised?
• Welche Session-Rolle? Customer/Peer/Transit?
• Welche Größenordnung? absoluter Sprung vs. prozentuale Abweichung vs. Churn.

Schritt: Quick-Triage „Leak wahrscheinlich?“

• Customer received/accepted stark gestiegen: Leak sehr wahrscheinlich.
• Received hoch, accepted stabil: Leak wird lokal gefiltert, aber Peer/Customer ist defekt.
• Advertised hoch: Leak aus Ihrem Netz heraus wahrscheinlich (Export-Policy prüfen).

Schritt: Beweise sammeln (Evidence Pack light)

• Prefix Count Before/After: Zeitreihe (mind. 30–60 Minuten) und Baseline (7–30 Tage).
• Top-N neue Präfixe: Beispiele, die neu gelernt/advertised wurden (ohne komplette Tabellen zu exportieren).
• Top-N neue AS-PATHs: welche neuen ASNs erscheinen plötzlich?
• Update/Withdraw Rate: ob es ein Storm ist oder ein stabiler Leak.
• Traffic Impact: erste Indizien (Auslastung, Latenz, Loss) an relevanten Ports.

Schritt: Mitigation priorisieren

Bei Route Leaks zählt Zeit. Die Mitigation hängt von Rolle und Risiko ab. Typischerweise gilt: lieber kontrolliert begrenzen als „alles neu bauen“.

• Customer Leak: striktere Ingress-Filter aktivieren, Max-Prefix heruntersetzen, Session ggf. kontrolliert dämpfen.
• Peer Leak: kurzfristig defensive Filter, Peer informieren, ggf. temporäre Präfixbegrenzung.
• Eigener Export Leak: Export-Policy sofort korrigieren oder Advertisement temporär stoppen; danach Re-Validation.

Schritt: Post-Mitigation-Validation

• Prefix Count normalisiert: zurück im Baseline-Band (nicht nur „ein bisschen besser“).
• Churn sinkt: Update/Withdraw Rate stabilisiert sich.
• Traffic normalisiert: Auslastung und Latenz/ Loss kehren zu Normalwerten zurück.
• Stabilitätsfenster: definierte Beobachtungszeit ohne erneute Peaks.

False Positives vermeiden: Häufige legitime Gründe für Prefix-Count-Änderungen

Nicht jede Prefix-Count-Abweichung ist ein Leak. Damit Monitoring glaubwürdig bleibt, sollten Sie bekannte legitime Ursachen in der Alarmierungslogik berücksichtigen.

• Planned Maintenance beim Peer/Transit: Umroutung kann Prefix Visibility oder Best-Path-Auswahl verändern.
• Policy-Rollout (beidseitig): neue Communities, neue Filters, RPKI-Deployment können accepted counts verändern.
• Session Reset/Graceful Restart: kurzfristige Drops/Spikes in Count und Churn (siehe RFC 4724).
• Deaggregation Events: DDoS-Mitigation kann Präfixe temporär deaggregieren (mehr spezifische Routen).

Best Practices: Prefix Count als Guardrail im Routing-Policy-Design

Prefix Count sollte nicht nur „Monitoring“ sein, sondern als Bestandteil eines sicheren Betriebsmodells verstanden werden. Besonders wirksam sind:

• Max-Prefix mit Threshold: frühe Warnschwelle (z. B. 80–90% der erwarteten Maximalzahl) und harte Grenze für Notfälle.
• Rollenkonzept pro Session: Customer/Peer/Transit-Templates mit klaren Export-/Import-Policies (siehe RFC 9234).
• RPKI-Validierung: Invalids droppen oder depräferieren, um falsche Announcements zu reduzieren; als operativer Rahmen ist MANRS eine sinnvolle Quelle für Best Practices.
• IRR-basierte Filter: zusätzliche Policy-Sicherheit, wenn gepflegt und automatisiert.
• Drift-Detection: Alarm, wenn Policies/Templates von Standard abweichen (Automation-Fehler früh erkennen).

Monitoring-Checkliste: Route Leak Detection über Prefix Count (einsatzbereit)

• Pro Session erfassen: received, accepted, advertised Prefix Count als Zeitreihe.
• Baselines definieren: Median/Perzentile pro Rolle (Customer/Peer/Transit) und pro Adresse (v4/v6 getrennt).
• Schwellen kombinieren: absolute + relative Abweichung, plus Churn-Trigger (Update/Withdraw Rate).
• Top-N Beispiele sichern: neue Präfixe und neue AS-PATHs automatisch als Incident-Anhang.
• Max-Prefix nutzen: Threshold-Alarm und Hard-Limit, mit klaren Runbook-Schritten.
• Correlation: Auslastung/Queue Drops an Peering-Ports, um Impact zu bestätigen.
• Auditierbarkeit: Wer hat wann Policy geändert? Prefix-Count-Events mit Change-Timeline korrelieren.

Evidence Pack für RCAs und Peer-Eskalationen

• Zeitfenster (UTC): Start, Peak, Mitigation, Stabilitätsfenster.
• Session-Identität: Peer-ASN, Session (v4/v6), Rolle (Customer/Peer/Transit), Interface/LAG.
• Prefix Count Graphs: received/accepted/advertised before/after, inklusive Baseline.
• Churn-Daten: Update/Withdraw Rate, ob Storm oder stabiler Leak.
• Beispiele: Top neue Präfixe, Top neue AS-PATHs, auffällige Communities.
• Impact: Traffic-Shift, Auslastung, Latenz/Loss-Indizien, ggf. betroffene Kundenreports.
• Actions: welche Filter/Max-Prefix/Policy wurden geändert, und welche Messwerte normalisierten sich.

Outbound-Ressourcen

• RFC 4271 (BGP-4)
• RFC 9234 (Route Leak Prevention and Detection Using Roles in BGP)
• RFC 7606 (BGP Error Handling – relevant für Update-Fehler und Stabilität)
• RFC 4724 (Graceful Restart Mechanism for BGP)
• MANRS (Operational Best Practices für Routing-Sicherheit)

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.