Inter-Domain Routing Failures sind im Provider-Umfeld ein wiederkehrendes Risiko, weil sie selten als „alles ist down“ auftreten, sondern als schwer zu greifende Teilstörungen: Traffic nimmt unerwartete Umwege, einzelne Ziele sind nur aus bestimmten Regionen erreichbar, Latenz steigt sprunghaft, oder Interconnect-Ports laufen plötzlich voll. Die häufigsten Ursachen sind Route Leaks (ungewollte Weitergabe von Präfixen), BGP-Loops (Fehlkonfigurationen oder Policy-Ketten, die Pfade kreisförmig machen) und fehlende Guardrails, die solche Fehler früh stoppen könnten. Gerade in Telco-Topologien mit vielen Peers, mehreren Transit-Providern, IXPs, PNIs und komplexen Kundenbeziehungen ist „BGP funktioniert schon“ kein Designprinzip. Ein professionelles Inter-Domain-Design behandelt Routing-Hygiene als topologisches Thema: Wo liegen klare Domänengrenzen (Edge, Interconnect, Kundenzone, Core)? Welche Failure Domains dürfen ein Leak auslösen, und welche dürfen ihn niemals weitertragen? Wie werden Policies und Filter so gestaltet, dass ein Fehler lokal bleibt und nicht das gesamte Netz oder sogar das Internet beeinflusst? Dieser Artikel zeigt, wie Sie Inter-Domain Routing Failures verstehen, wie Leaks und Loops entstehen und wie Sie sie mit topologischen Guardrails vermeiden: durch saubere Peering- und Transit-Designs, strikte Import/Export-Policies, Max-Prefix- und Dampening-Strategien, standardisierte Communities, klare RR-Hierarchien sowie Observability, die Anomalien früh erkennt.
Was sind Inter-Domain Routing Failures und warum sind sie so gefährlich?
Inter-Domain Routing beschreibt in der Praxis das Routing zwischen autonomen Systemen (AS) – typischerweise mit BGP. Ein Failure liegt vor, wenn Routen unerwartet verbreitet, verändert oder bevorzugt werden. Gefährlich ist dabei weniger der einzelne Fehler als seine Reichweite: Ein Leak, der aus einer Kundenbeziehung in Transit- oder Peering-Beziehungen „durchrutscht“, kann globalen Traffic umleiten. Ein Loop kann Traffic im Kreis schicken oder Pfade so verlängern, dass Services „degradieren“, ohne offensichtlich auszufallen.
- Route Leak: Präfixe werden an Nachbarn announced, die sie nicht bekommen dürfen (klassisch: Kundenrouten an Peer/Transit weitergeben).
- Policy Leak: Communities/LocalPref werden falsch gesetzt, sodass falsche Exits bevorzugt werden.
- Route Loop: Pfade ergeben logisch einen Kreis oder erzeugen persistenten Pfadwechsel/Oszillation.
- Prefix Explosion: Unerwartet viele Routen werden importiert (z. B. Full Table in einem Edge ohne Limits) und belasten Control Plane.
Leitprinzip: Der Schaden entsteht durch Weiterverbreitung
Ein Fehler ist fast immer lokal. Ein Incident wird er, wenn der Fehler über Domänengrenzen hinweg propagiert. Deshalb ist „topologisch begrenzen“ oft der wichtigste Schutz.
Warum Leaks entstehen: Geschäftsbeziehungen und BGP-Policies
Die meisten Route Leaks sind keine „BGP-Bugs“, sondern Policy-Fehler. In Interconnect-Topologien gibt es typische Beziehungstypen: Customer, Peer und Provider (Transit). Diese Beziehungen definieren, was importiert und exportiert wird. Wenn diese Logik nicht konsequent umgesetzt ist – oder wenn Konfigurationen über Jahre inkonsistent gewachsen sind – entstehen Leaks fast zwangsläufig.
- Customer-to-Provider Leak: Ein Kunde announct zu viele/unerwartete Präfixe; der Provider filtert nicht streng genug.
- Peer-to-Provider Leak: Routen eines Peers werden fälschlich an Transit weitergegeben.
- Provider-to-Peer Leak: Full Table wird an IXP/Peer geleakt, was Traffic umleiten kann.
- Internal-to-External Leak: Interne Infrastrukturpräfixe (Loopbacks, Mgmt) werden extern announced.
Designregel: Beziehungstyp ist die Policy-Quelle
Eine saubere Policy beginnt mit einer eindeutigen Klassifikation: Jeder BGP-Neighbor ist Customer, Peer oder Provider. Daraus werden automatisch Import/Export-Regeln abgeleitet. „Sonderfälle“ sollten selten sein und dokumentiert werden.
Loops und Oszillation: Wie „Kreise“ im Routing entstehen
BGP verhindert Loops primär über AS_PATH: Ein AS akzeptiert normalerweise keine Route, in deren AS_PATH es selbst vorkommt. Trotzdem können „Loop-artige“ Effekte auftreten: Routing-Oszillation durch widersprüchliche Policies, Route Reflection-Fehler, inkonsistente MED/LocalPref-Strategien, oder Forwarding-Loops durch inkonsistente Next-Hop-Informationen und IGP/BGP-Interaktion.
- Policy-Oszillation: Änderungen in LocalPref/MED/Communities führen zu ständig wechselnden Best Paths.
- RR/Cluster-Fehler: Route Reflector Topologien verteilen Routen inkonsistent, Clients sehen unterschiedliche Wahrheiten.
- IGP/BGP Mismatch: Next-Hop ist erreichbar, aber Pfadwahl erzeugt suboptimale oder kreisende Weiterleitung (besonders bei TE/Anycast).
- Asymmetrie in Service Chains: Traffic läuft hin über Pfad A, zurück über Pfad B und bricht bei stateful Middleboxes (wirkt wie Loop/Blackhole).
Ein praktisches Warnsignal
Wenn Latenz, Path-Trace und BGP-Events gleichzeitig „flattern“, liegt die Ursache oft in Policy-Oszillation oder in inkonsistenter Route Distribution (RR/Hierarchie). Das ist nicht nur ein Routing-, sondern ein Topologieproblem.
Topologische Guardrails: Domänengrenzen und Failure Domains bewusst schneiden
Die effektivsten Guardrails entstehen durch Topologie: Sie trennen Interconnect (Peering/Transit), Customer Edge, Core und Management-Domänen so, dass ein Fehler nicht automatisch überall sichtbar wird. Das bedeutet: Interconnect-Router sind eigene Rollen, Kundenzonen sind isoliert, und das Core bleibt policyarm. Gleichzeitig definieren Sie Failure Domains: Ein Fehler in einem PoP soll nicht direkt die gesamte Region oder alle Regionen beeinflussen.
- Interconnect/Edge als eigene Domain: Peering und Transit werden auf dedizierten Edge-Routern terminiert, nicht auf Core-Routern.
- Customer Edge Isolation: Kundenpeering wird logisch/physisch getrennt, z. B. via VRFs oder separaten Edge-Knoten.
- Core als Transport: Der Core trägt Labels/Forwarding, aber trifft keine Interconnect-Policy-Entscheidungen.
- Regionalisierung: Regionen/PoPs als Containment: Ein Leak in Region A darf nicht automatisch Region B beeinflussen.
Designregel: Weniger Stellen, an denen man „falsch exportieren“ kann
Je weniger Geräte Routen extern announcen dürfen, desto geringer die Leak-Fläche. Ein klares Rollenmodell (Interconnect Edge) reduziert Risiko und OPEX.
Import/Export-Policies: Default-deny als Standard
Im Inter-Domain-Routing ist „allow all“ fast immer falsch. Ein robustes Design nutzt Default-deny: Ohne explizite Erlaubnis wird nichts importiert und nichts exportiert. Praktisch heißt das: Prefix-Listen, AS-PATH-Filter, Communities und klare Policy-Templates pro Neighbor-Typ. Für Telcos ist außerdem wichtig, dass Policies wiederverwendbar und auditiert sind (Policy-as-Code).
- Import Filter: Erlauben nur erwartete Präfixe, erwartete ASNs oder erwartete Routenklassen; alles andere wird verworfen.
- Export Filter: Announcen nur autorisierte Aggregate/Customersets; keine internen Infrastrukturpräfixe.
- Community Hygiene: Standardisierte Communities, die Bedeutung und Wirkung klar definieren (z. B. no-export, blackhole, prepends).
- LocalPref-Policy: Klare Präferenzhierarchie (z. B. PNI > IXP > Transit) und Ausnahmen dokumentiert.
Anti-Pattern: „Wir filtern später, wenn es Probleme gibt“
Inter-Domain-Routing verzeiht Fehler schlecht. Ohne strikte Filter wird ein Leak oft erst bemerkt, wenn bereits Kundenimpact oder öffentliche Effekte auftreten.
Max-Prefix, Rate Limits und „Blast Radius“ für die Control Plane
Selbst mit Filterung können unerwartete Ereignisse auftreten: ein Peer sendet plötzlich zu viele Prefixe, ein Kunde leakt Full Table, oder ein Route Server liefert mehr als erwartet. Max-Prefix-Limits sind ein mechanischer Guardrail, der die Control Plane schützt. Ergänzend helfen Rate Limits und Schutzmechanismen gegen Update-Stürme.
- Max-Prefix pro Session: Harte Obergrenzen, mit sinnvollen Warnschwellen (Warning/Shutdown) und klaren Runbooks.
- Prefix-Count-Baselines: Erwartete Prefixbereiche pro Peer/Transit; Abweichungen alarmieren.
- Update Rate Monitoring: BGP-Update/Withdraw-Raten als Frühindikator für Instabilität.
- Control-Plane Protection: CoPP/Policing für Routing-Traffic, damit DDoS oder Fehlkonfigs nicht die CPU killen.
Designregel: Protect the control plane, oder alles wird „komisch“
Viele Inter-Domain Incidents beginnen als Control-Plane-Problem und werden dann als Datenebenenproblem sichtbar. Max-Prefix und Update-Guardrails verhindern Eskalation.
RPKI, IRR und Prefix-Authorisierung: Hygiene gegen falsche Origin-Ankündigungen
Ein zentraler Leak-Typ ist die falsche Origin-Ankündigung: Präfixe werden mit einem falschen Origin-AS bekannt gemacht. Technische Hygiene setzt hier an: IRR-basierte Filter (Route Objects) und RPKI-basierte Validierung helfen, unerlaubte Origins zu blocken. Wichtig ist die topologische Integration: Validierung gehört an die Interconnect Edge, nicht „irgendwo“ im Core.
- Origin-Validation: RPKI-Validierung in der Import-Policy, um invalid Origins zu verwerfen oder zu de-priorisieren.
- IRR-basierte Prefix-Listen: Automatisierte Erzeugung von erlaubten Prefix-Sets pro Customer/Peer (mit Governance).
- Exception Handling: Definierte Prozesse für legitime Sonderfälle, damit Filter nicht ausgehöhlt werden.
- Auditability: Nachweis, welche Routen wann akzeptiert/verworfen wurden (wichtig für Betrieb und Compliance).
Hinweis zur Praxis
Wichtig ist weniger, ob Sie „RPKI überall“ einsetzen, sondern dass die gewählte Strategie konsistent und betrieblich sauber ist: Monitoring, Fallback-Regeln und klare Runbooks verhindern Überraschungen.
Route Server, IXP und Peering-Skalierung: Guardrails im Shared-Fabric-Umfeld
IXPs und Route Server erleichtern Peering, erhöhen aber die Komplexität der Policy-Kette: Sie erhalten Routen über eine Shared Fabric, oft mit vielen Peers gleichzeitig. Das erfordert klare Trennung zwischen Route-Server-Peering und bilateralem Peering, sowie strikte Import/Export-Regeln. Topologisch ist außerdem Fabric-Redundanz wichtig, damit ein IXP-Problem nicht zu einem großflächigen Failover mit Congestion führt.
- RS vs. Bilateral: Route Server für Long Tail, bilateral/PNI für große Partner – mit separaten Policy-Templates.
- Scope-Kontrolle: Nur die Routen akzeptieren, die zum Peering-Modell passen; no-transit sicherstellen.
- IXP-Failure Domains: Ports und Fabrics diversifizieren, um Failover kontrolliert zu halten.
- Peering-Observability: Flow-Mix, ASN-Top-Talkers, Prefix-Counts pro RS/Peer, um Anomalien früh zu sehen.
Anti-Pattern: Route Server als „Policy-Abkürzung“
Ein Route Server reduziert Sessions, ersetzt aber nicht Ihre Verantwortung für Filter, no-transit-Policies und Prefix-Guardrails. Gerade dort passieren Leaks, wenn Standards fehlen.
RR-Topologie und Inter-Domain Hygiene: Wie iBGP Fehler extern eskalieren
Viele Inter-Domain Failures beginnen intern: RR-Cluster verteilen Routen inkonsistent, interne Policies setzen Communities falsch, oder Prefix-Filter sind in einer Region anders als in einer anderen. Wenn solche internen Fehler dann auf Interconnect-Edges wirken, werden sie extern sichtbar. Deshalb braucht es saubere RR-Hierarchien, klare Failure Domains und konsistente Policy-Distribution.
- Hierarchische RRs: Regionale RR-Cluster, darüber eine kontrollierte Aggregation; begrenzt Blast Radius.
- Policy-Konsistenz: Einheitliche Communities und Exportregeln in allen Regionen; Drift vermeiden (Templates).
- Route Leaks intern erkennen: Prefix-Count-Anomalien, unerwartete Next-Hops, ungewöhnliche Community-Sets.
- Containment: Interconnect-Edge filtert auch interne Quellen (z. B. nur erlaubte Aggregate exportieren).
Designregel: Exporte dürfen nie „aus Versehen“ passieren
Auch wenn intern etwas falsch läuft, muss die Interconnect-Edge verhindern, dass es nach außen gelangt. Das ist der letzte Schutzring.
Observability: Leaks und Loops früh erkennen, bevor Kunden es merken
Guardrails sind besser, wenn sie messbar sind. Observability für Inter-Domain Routing umfasst nicht nur BGP-Session-Up/Down, sondern Qualitäts- und Anomaliesignale: Prefix-Counts, Update-Raten, Best-Path-Änderungen, Traffic-Mix (Flows) und Path-KPIs (Latenz/Loss zu Referenzzielen). Damit erkennen Sie, ob ein Leak Traffic umleitet, oder ob ein Loop/Oszillation pfadseitig eskaliert.
- Prefix-Count Monitoring: Erwartete Werte pro Peer/Transit; Abweichungen alarmieren und korrelieren.
- Route-Change Rate: Withdraw/Update-Spikes als Indikator für Instabilität oder Policy-Fehler.
- Traffic Visibility: Flow/IPFIX nach ASN/Peer/Linkklasse, um unerwartete Trafficverschiebungen zu sehen.
- Path KPIs: p95/p99 RTT und Loss zu wichtigen Zielen; „degraded“ statt „down“ erkennen.
High-Signal Alerting statt Alarmflut
Ein BGP-Reset ist nicht automatisch ein Incident. High-Signal entsteht, wenn Routing-Anomalien mit SLO-Impact zusammenfallen: z. B. Prefix-Count-Anomalie plus Latenz-/Loss-Spike plus Transit-Traffic-Spike.
Operational Guardrails: Change Risk reduzieren, bevor Leaks entstehen
Viele Leaks passieren bei Changes: neue Peers, neue Communities, neue Filter, Migrationen. Deshalb sollten Interconnect-Änderungen grundsätzlich canaryed und progressiv ausgerollt werden. Zusätzlich helfen Pre-Checks (Policy-Validation), Post-Checks (Prefix-Counts) und ein getesteter Rollback.
- Canary Links: Neue Policies zuerst auf einem begrenzten Interconnect-Scope testen (z. B. ein PoP oder ein Portbundle).
- Progressive Rollout: Regionweise Wellen mit Go/No-Go Gates basierend auf SLIs.
- Policy-as-Code: Versionierung, Reviews, automatisierte Tests für Filter/Communities/Max-Prefix.
- Rollback-Readiness: Klare Kriterien und schnelle Reversibilität, bevor die nächste Welle startet.
Designregel: Jeder Interconnect-Change braucht einen Messplan
Wenn nicht klar ist, welche KPIs „grün“ bleiben müssen (Prefix-Counts, Traffic-Mix, SLOs), wird ein Change zur Mutprobe statt zu Engineering.
Typische Failure-Szenarien und welche topologischen Maßnahmen helfen
- Kunde leakt Full Table: Max-Prefix, IRR/RPKI-Filter, Customer Edge Isolation, schnelle Session-Shutdown-Runbooks.
- Peer/RS leakt unerwartete Routen: Default-deny Import, Prefix-Count Baselines, no-transit Export-Policies.
- Transit-Fehlankündigung lenkt Traffic um: Multi-Transit, Policy-Controls, Path-KPIs und Traffic-Mix Monitoring.
- RR-Partition führt zu inkonsistenten Exports: RR-Hierarchie, Region-Containment, Export-Whitelist an Interconnect-Edges.
- Policy-Change erzeugt Oszillation: Hysterese/Timers, staged Policy-Änderungen, progressive Rollouts, Beobachtungsfenster.
Praktische Leitlinien: Guardrails topologisch vermeiden statt „später löschen“
- Rollen trennen: Interconnect/Edge als eigene Domain, Core als Transport, Customer Edge isolieren.
- Default-deny Policies: Import/Export nur explizit erlauben, keine „wildcards“ ohne Scope.
- Mechanische Limits: Max-Prefix, Update-Rate Monitoring, Control-Plane Protection als Pflicht.
- Authorisierung: RPKI/IRR-basierte Filter (wo sinnvoll) plus klare Exception-Prozesse.
- IXP/RS diszipliniert: RS/Bilateral trennen, no-transit sicherstellen, Fabric-Redundanz einplanen.
- RR-Hierarchie und Konsistenz: Regionale RRs, konsistente Communities/Policies, Drift vermeiden.
- Observability ausbauen: Prefix-Counts, Route-Churn, Flow-Mix und Path KPIs korrelieren; High-Signal Alerts.
- Change Risk reduzieren: Canary, progressive Rollouts, Policy-as-Code, Rollback-Readiness.
- Failure Workshops: Leaks/Loops als Szenarien regelmäßig durchspielen, Expected vs. Observed dokumentieren.