Internet Service Topology: Edge, Transit, Peering und Route Policies

Eine saubere Internet Service Topology ist für Telcos, ISPs und große Netzbetreiber der entscheidende Faktor, ob Internetzugang zuverlässig, performant und wirtschaftlich betrieben werden kann. „Internet“ ist dabei kein einzelner Dienst, sondern eine Kette aus Rollen und Übergabepunkten: Access/BNG oder PE als Eintritt, Internet Edge als Policy- und Sicherheitsgrenze, Transit als globale Erreichbarkeit, Peering als kosten- und performanceoptimierter Traffic-Austausch sowie Route Policies, die bestimmen, welcher Pfad im Normalbetrieb und im Störfall genutzt wird. Wenn diese Bausteine historisch „organisch“ wachsen, entstehen typische Symptome: zu hohe Transitkosten trotz vieler Peeringports, unerklärliche Performance-Schwankungen (weil IPv4/IPv6 oder Regionen unterschiedliche Exits nutzen), große Failure Domains (ein IXP-Fabric-Problem zieht nationale Störungen nach sich), oder Sicherheitsrisiken durch Route Leaks, fehlende Limits und unklare DDoS-Prozesse. Ein professionelles Design behandelt Internet Service Topology als wiederverwendbaren Blueprint: klare Edge-Rollen, definierte Regionen/PoPs, konsistente BGP-Policy (Local Preference, Communities, Filter, Max-Prefix), kontrollierte Failoverpfade, Kapazitäts- und QoS-Profile sowie Telemetry, die Pfadwahl und Portgesundheit messbar macht. Dieser Artikel zeigt, wie Sie Edge, Transit, Peering und Route Policies so kombinieren, dass Wachstum möglich bleibt – ohne Routing-Chaos und ohne OPEX-Explosion.

Die Bausteine der Internet Service Topology: Rollen statt „ein Haufen BGP“

Internet-Topologie funktioniert am besten, wenn Rollen klar getrennt sind. Der Core transportiert, die Edge entscheidet, und Interconnect ist eine eigene Domäne mit eigenen Guardrails. Diese klare Struktur verhindert, dass jede neue Peering-Session den Core „verschmutzt“ oder dass Security-Funktionen unkontrolliert in den Transit wandern.

• Subscriber/Service Ingress: BNG/BRAS, PE oder Service-Edge, wo Kundenverkehr in Richtung Internet übergeben wird.
• Internet Edge: Policy-Grenze zwischen internem Netz und externem Internet; hier greifen Sicherheits- und Steuerungsmechanismen.
• Transit Edge: Übergabe an Upstream-Provider für vollständige Internet-Reachability.
• Peering Edge: Übergabe an IXPs und PNIs für direkte Pfade zu Content- und Partnernetzen.
• Route Policies: Regeln, die Pfadpräferenzen, Filter und Failover definieren.

Leitprinzip: Edge ist Policy Point, Core ist Transport

Je klarer Ihre Internet-Edge als Policy- und Security-Grenze definiert ist, desto stabiler bleibt der Core. Das reduziert den Blast Radius von Interconnect-Änderungen und vereinfacht Betrieb und Audit.

Edge-Design: Internet Edge als eigene Domäne mit klaren Failure Domains

Die Internet Edge ist die Außenkante des Netzes – und damit exponiert. Hier treffen DDoS-Risiko, Routing-Anomalien und kapazitive Hotspots zuerst auf. Deshalb sollte die Edge als eigene Domain geplant werden: mit dedizierten Border-Routern, getrennten Managementpfaden, Control-Plane-Schutz und klarer Redundanz.

• Router-Redundanz: Mindestens zwei Edge-Router pro Standort, idealerweise mit diversen Linecards/Feeds.
• Facility-/Fabric-Diversität: Interconnects nicht an einem einzigen Switch/Fabric bündeln; SRLG-Risiken aktiv reduzieren.
• Regionalisierung: Edge-Knoten pro Region/Metro-Hub, damit Nutzerpfade kurz bleiben und Failure Domains begrenzt sind.
• Kapazitätsreserve: N-1 Headroom, damit Ausfall eines Links/Providers nicht sofort Congestion erzeugt.

Ein typisches Anti-Pattern: „Ein großer Internet-Exit für alles“

Ein zentraler Exit ist einfach, erzeugt aber nationale Failure Domains und Hairpinning. Regionale Edges reduzieren Latenz, Backbone-Last und den Impact einzelner Störungen – vorausgesetzt, Policy und Telemetry sind standardisiert.

Transit: Globale Erreichbarkeit als Fallback- und Sicherheitsanker

Transit liefert vollständige Internet-Reachability und ist damit der verlässlichste Fallback, wenn Peeringpfade ausfallen oder nicht existieren. Gleichzeitig ist Transit kostengetrieben und sollte kontrolliert genutzt werden. Topologisch ist Dual-Transit (mindestens zwei unabhängige Provider) ein Standard, um Provider-Ausfälle und Routing-Anomalien abzufangen.

• Dual-Transit: Zwei unabhängige Transit-Provider, möglichst in unterschiedlichen Facilities/PoPs.
• Regionaler Transit: Transit-Übergaben pro Region reduzieren Hairpinning und verbessern Performance.
• Default vs. Full Table: Je nach Design werden Full Tables am Edge geführt; wichtig sind Limits und stabile RR/Edge-Architektur.
• Security-Mechanismen: Blackholing-Communities, DDoS-Workflows und Route Hygiene sind oft eng mit Transit-Beziehungen gekoppelt.

Transit ist kein „Plan B“, sondern Teil des Stabilitätsdesigns

Selbst peeringlastige Netze brauchen Transit als zuverlässige Basis. Die Kunst ist, Transit so zu dimensionieren und zu priorisieren, dass er im Normalbetrieb nicht unnötig genutzt wird, im Störfall aber trägt.

Peering: IXP und PNI als Topologie-Tool für Kosten und Performance

Peering ist der effektivste Hebel, um Latenz zu reduzieren und Transitkosten zu senken – besonders bei Content- und Cloud-Verkehr. Topologisch unterscheiden sich öffentliche IXPs (viele Peers über eine Fabric) und PNIs (private direkte Verbindungen). Beide sollten als ergänzende Bausteine verstanden werden.

• IXP Peering: Breite Reichweite zu vielen Netzen; erfordert Fabric-Redundanz, saubere L2/MTU-Profile und klare Route-Server/Bilateral-Strategien.
• PNI: Hohe Kontrolle, oft bessere Performance und weniger Shared Congestion; besonders sinnvoll für große Traffic-Partner.
• Regionaler Mix: Peering dort aufbauen, wo Traffic entsteht (Metro-Hubs, Content-Hotspots), nicht nur „zentral“.
• Failure Domains: IXP-Fabrics sind Shared Infrastructure; PNIs können SRLG reduzieren.

Route Server vs. Bilaterals: Betrieb vs. Kontrolle

Route Server vereinfachen die Sessionzahl, ändern aber das Policy- und Troubleshooting-Modell. Bilaterals geben mehr Kontrolle, erhöhen aber OPEX. Ein Hybrid ist häufig ideal: Route Server für Long Tail, bilaterals/PNIs für große Partner.

Route Policies: Die effektive Topologie entsteht durch BGP-Regeln

Die physische Topologie beschreibt, wo Kabel liegen. Die effektive Internet-Topologie entsteht durch Policies: welche Pfade bevorzugt werden, welche Routen überhaupt akzeptiert werden, wie Failover funktioniert und wie Routingfehler begrenzt werden. Ohne Policy-Disziplin wird aus einem Interconnect-Netz schnell ein unübersichtliches Regelwerk.

• Local Preference: Primärinstrument für ausgehende Pfadwahl (typisches Modell: PNI > IXP > Transit).
• Communities: Standardisierte Steuerung für Prepends, Blackholing, Regional-Controls und Partner-spezifische Funktionen.
• Import/Export-Filter: Default-deny als Leitbild; nur erwartete Prefixe zulassen und nur notwendige Prefixe announcen.
• Max-Prefix: Harte Limits, die Route Leaks und Fehlkonfigurationen schnell stoppen.

Ein nützliches Präferenzmodell

$\mathrm{Pref}\left(\mathrm{PNI}\right)>\mathrm{Pref}\left(\mathrm{IXP}\right)>\mathrm{Pref}\left(\mathrm{Transit}\right)$

Dieses Modell ist ein Ausgangspunkt. In der Praxis wird es durch Regionen, Kapazitätsklassen, Partnerbedingungen und Security-Anforderungen ergänzt. Wichtig ist: Es muss konsistent umgesetzt und messbar gemacht werden.

Inbound vs. Outbound Engineering: Was Sie wirklich steuern können

Outbound (Egress) ist intern gut steuerbar, weil Ihre Router entscheiden. Inbound (Ingress) ist schwieriger, weil die Gegenseite entscheidet. Trotzdem gibt es bewährte Techniken, um Inbound-Pfade zu beeinflussen – mit klaren Grenzen.

• Outbound: Local Preference, regionale Exit-Policies, Next-Hop-Steering, ggf. SR-Policies im Backbone.
• Inbound: AS-Path Prepending, selective announcements pro Region/PoP, Communities (wenn vom Transit/Peer unterstützt).
• Scope-Kontrolle: Regionale Announcements vermeiden unnötiges Hairpinning und verbessern Nutzererfahrung.
• Stabilität: Inbound kann bei Ausfällen „kleben“; Monitoring und Failover-Playbooks sind wichtig.

Ein häufiger Fehler: Global announcen, lokal liefern wollen

Wenn Sie überall identisch announcen, werden Inbound-Pfade oft zufällig oder kostengetrieben gewählt. Kontrollierte Regionalisierung ist häufig wirksamer als „mehr Peering“.

Resilienz: Failure Domains, N-1 und kontrollierte Fallbacks

Internet-Topologien scheitern selten als „alles down“. Häufig sind es Teilstörungen: Congestion auf einem IXP-Port, Routing-Anomalien bei einem Transit, flappende Peer-Sessions oder ein defekter Cross-Connect. Ein robustes Design begrenzt die Failure Domain und bietet kontrollierte Ausweichpfade.

• Diversität: Zwei Router, zwei Fabrics, zwei Facilities, zwei Provider – wo sinnvoll.
• Störfallkapazität: N-1 Headroom auf Ports und Uplinks; Upgrade-Trigger aus Telemetry ableiten.
• Kontrolliertes Failover: Transit als Fallback mit klarer Präferenz, nicht als unkontrollierter „Zufallspfad“.
• Failback-Regeln: Hold-down/Hysterese, um Ping-Pong zwischen Pfaden zu vermeiden.

Resilienz ohne Telemetry ist nur Hoffnung

Sie müssen sehen können, wann Pfade umschalten, ob Drops entstehen und ob Congestion lokal oder systemisch ist. Sonst bleibt jede Störung eine Detektivarbeit.

Sicherheit und Route Hygiene: RPKI, Filtering, DDoS und Control-Plane Schutz

Die Internet Edge ist eine Angriffsfläche. Deshalb muss die Topologie Security-by-Design enthalten: strikte Filter, Limits, DDoS-Mechanismen und Control-Plane-Protection. Dabei ist entscheidend, dass Security nicht „nebenbei“ läuft, sondern in die Route Policies und in die Betriebsprozesse eingebettet ist.

• Route Hygiene: Prefix-Filter, AS-Path-Filter (wo sinnvoll), Default-deny, Max-Prefix, Alarmierung.
• RPKI-Validierung: Wo eingesetzt, muss sie betrieblich sauber gemonitort und mit Fallback-Prozessen versehen sein.
• DDoS-Patterns: RTBH/FlowSpec/Scrubbing-Topologien mit klaren Triggern und Failback-Kriterien.
• Control-Plane Schutz: CoPP/Rate-Limits gegen volumetrische Ereignisse und Missbrauch von Routingprotokollen.

Security Domains an der Edge

Peering/Transit sollten in einer eigenen Security Domain laufen: getrennte Managementpfade, Jump-Zones, strikte Zugriffe und klare Auditspuren. Das reduziert Risiko, dass ein Edge-Incident lateral in interne Plattformen wirkt.

Observability: Interconnect als messbare Servicefläche betreiben

Ohne Messbarkeit ist Internet-Engineering ein Ratespiel. Sie benötigen Telemetry, die nicht nur Up/Down zeigt, sondern Qualität und Policy-Wirkung: Latenz, Loss, Jitter, Congestion, Route-Churn und Pfadpräferenzen – pro Region und pro Interconnect.

• Port-/Queue-Telemetry: Auslastung, Drops, Queue-Stats, Microbursts pro Interconnect-Port.
• BGP-Telemetry: Session-Stabilität, Prefix-Counts, Update-Raten, Convergence-Zeiten.
• Path KPIs: Latenz/Loss zu wichtigen Content- und Cloud-Zielen, regional aufgeschlüsselt.
• Policy-Observability: Nachweis, dass Präferenzen wirken (z. B. PNI bevorzugt, Transit Fallback).

Evidence-by-Design: Vorher/Nachher messen

Neue IXPs, PNIs oder Policy-Änderungen sollten immer mit messbaren Effekten verbunden sein: Transit-Reduktion, Latenzverbesserung, weniger Drops, besseres Störfallverhalten. So werden Investitionsentscheidungen und Betriebsänderungen belastbar.

Blueprint-Patterns: Wiederverwendbare Internet-Service-Architekturen

Die meisten Betreiber profitieren von wenigen Standardmustern, die pro Region/PoP wiederholt werden. Diese Muster definieren Routerrollen, Portklassen, Policy-Templates und Failoververhalten. So wird Wachstum planbar und Betrieb konsistent.

• Regional Dual-Edge Pattern: Zwei Edge-Router, IXP + Transit, klare Pref-Logik, N-1 Headroom.
• PNI-Heavy Content Pattern: PNIs zu großen Partnern, IXP für Long Tail, Transit als Fallback.
• Dual-Transit Safety Pattern: Zwei Transit-Provider, strikte Filter/Max-Prefix, DDoS-Mechanismen integriert.
• Multi-Region Exit Pattern: Regionale Announcements, kontrolliertes Cross-Region-Failover, Telemetry-first.

Typische Fehlerbilder und wie man sie vermeidet

• Hoher Transit trotz Peering: Ursache oft falsche Pref/Export-Policy – Lösung: Policy-Review und Pfadmessung.
• IXP-Congestion: Shared Hotspots oder fehlender Headroom – Lösung: Portklassen, Fabric-Diversität, Upgrade-Trigger.
• Route Leaks: Fehlende Filter/Limits – Lösung: Default-deny, Max-Prefix, Guardrails, Change-Governance.
• Regionale Hairpins: Globale Announcements ohne Exit-Strategie – Lösung: regionale Policies und selective announcements.
• Unklare Failover-Pfade: Ausfälle führen zu Chaos – Lösung: getestete Playbooks, Hysterese, N-1 Kapazität.
• IPv6 anders als IPv4: Inkonsistente Policies – Lösung: Policy-Parität, getrennte KPIs pro Stack.

Praktische Leitlinien: Edge, Transit, Peering und Route Policies sauber kombinieren

• Edge als eigene Domain: Dedizierte Routerrollen, Management-Isolation, CoPP und klare Failure Domains.
• Dual-Transit als Basis: Unabhängige Provider, regionale Übergaben, N-1 Headroom.
• Peering strategisch: IXPs für Breite, PNIs für große Partner; regional dort, wo Traffic entsteht.
• Policy standardisieren: Local Pref, Communities, Import/Export-Filter, Max-Prefix als Templates (Policy-as-Code).
• Inbound/Outbound bewusst: Outbound intern steuern, Inbound mit selektiven Announcements und Prepends – stabil halten.
• Resilienz testen: Port-/Provider-Ausfall, IXP-Fabric-Probleme, Failback-Prozesse und Congestion-Tests.
• Security integrieren: Route Hygiene, RPKI-Workflows (wo genutzt), DDoS-Patterns und Auditability.
• Observability verpflichtend: Port/Queue/BGP/Path-KPIs pro Region und Peer, inklusive Change-Korrelation.