Telco Blueprint “Internet Edge”: Peering, Transit und DDoS-Integration

Ein Telco Blueprint „Internet Edge“ beschreibt die Referenzarchitektur für den Übergang zwischen dem eigenen Carrier-Netz und dem öffentlichen Internet – inklusive Peering, Transit und einer integrierten DDoS-Abwehr. Genau an dieser Kante entscheidet sich, ob Internetdienste zuverlässig, performant und sicher sind: Routing-Policies beeinflussen Latenz und Kosten, Guardrails verhindern Leaks und Loops, und DDoS-Mechanismen müssen so eingebunden sein, dass sie im Ernstfall automatisch greifen, ohne legitimen Traffic zu zerstören. Gleichzeitig ist der Internet Edge ein Hotspot für Komplexität: viele externe Nachbarn, häufige Policy-Änderungen, unterschiedliche technische und vertragliche Anforderungen (IXP-RS, PNIs, Transit-Provider), sowie ein permanenter Spagat zwischen „offen genug für Reichweite“ und „geschlossen genug für Sicherheit“. Ein professioneller Blueprint reduziert diese Komplexität durch klare Rollen, Domänengrenzen und standardisierte Verträge: Welche Komponenten gehören in die Edge-Domäne? Wie werden Sessions aufgebaut? Welche Communities und LocalPref-Modelle gelten? Wo wird gefiltert (RPKI/IRR, Prefix-Listen), wo werden Limits gesetzt (Max-Prefix), und wie werden Notfallmechanismen (RTBH, FlowSpec, Scrubbing Centers, Anycast) topologisch sauber integriert? Dieser Artikel liefert ein praxistaugliches Referenzdesign für den Telco Internet Edge mit Peering, Transit und DDoS-Integration – inklusive Operations-Bausteinen (Monitoring, Alarmierung, Change-Methodik, Rollback) und messbaren Erfolgsmetriken.

Zielsetzung und Prinzipien des Internet-Edge-Blueprints

Der Internet Edge ist nicht einfach „ein paar BGP-Sessions“. Er ist eine eigenständige Service-Domäne mit klaren Sicherheits- und Verfügbarkeitsanforderungen. Das Blueprint-Ziel ist, Edge-Designs wiederverwendbar zu machen: gleiche Rollen, gleiche Policy-Logik, gleiche Guardrails und gleiche Betriebsprozesse – unabhängig davon, ob Sie in Berlin, Frankfurt oder Hamburg peeren.

• Stabilität: Keine Leaks, keine Loops, kontrollierte Updates, berechenbares Failover.
• Performance: Niedrige Latenz durch sinnvolles Peering, stabile Ingress/ Egress-Pfade, ECMP-fähige Uplinks.
• Kostensteuerung: Peering vor Transit (wo sinnvoll), Traffic Engineering nach Kosten- und Qualitätskriterien.
• Sicherheit: Strikte Filter, Control-Plane Protection, DDoS-Abwehr als integraler Bestandteil.
• Operability: Standardisierte Changes, klare Wartungsdomänen, schnelle Fehlereingrenzung.

Leitprinzip: Edge ist „policy-rich“, Core ist „transport-boring“

Der Edge trifft Entscheidungen (Policies), der Core transportiert. Wer Policy in den Core zieht, erhöht Blast Radius und erschwert Migration, Interop und Betrieb.

Rollenmodell: Welche Komponenten gehören in den Internet Edge?

Ein sauberes Rollenmodell schafft Struktur und ermöglicht Templates. In vielen Telco-Designs sind mindestens drei Rollen sinnvoll: Edge Router (eBGP nach außen), Core-Uplinks (Transport ins Backbone) und Security/DDoS-Komponenten (Scrubbing, RTBH/FlowSpec, ggf. Firewalls für bestimmte Dienste). Zusätzlich können Route-Server am IXP als „externe Steuerinstanz“ betrachtet werden, die eigene Regeln benötigt.

• Edge Router (ER): eBGP zu Peers/Transits/PNIs, Policy Enforcement, Limits, Monitoring der Sessions.
• Backbone Uplinks (Core Facing): iBGP oder eBGP ins eigene Netz, klare Handover-Policies, ECMP und Fast Failover.
• IXP-Integration: Route Server Sessions (RS) und bilaterale Sessions (PNI/Direct Peering) getrennt behandelbar.
• DDoS/Scrubbing (optional, aber empfohlen): Scrubbing Centers, RTBH/FlowSpec Controller, Traffic Steering Mechanismen.
• Management/Telemetry: Separierte Managementpfade, Jump-Zones, Telemetry Pipelines mit Backpressure.

Anti-Pattern: „Alles auf einem Edge-Router“

Wenn ER, DDoS-Policy, Monitoring-Collector und komplexe Services auf einem Gerät zusammenlaufen, steigt das Risiko von Ressourcenengpässen und großen Failure Domains. Der Blueprint sollte bewusst trennen.

Referenztopologie: Multi-Edge pro PoP, diverse Uplinks, klare Failure Domains

Ein Internet Edge muss Ausfälle verkraften: Router-Ausfall, Link-Ausfall, IXP-Probleme, Transit-Probleme, DDoS-Ereignisse. Deshalb ist das Standardpattern „mindestens zwei Edge Router pro PoP“, mit diversen Uplinks in Richtung Core und – wo möglich – diverse physische Anbindungen an IXPs und Transits. Zusätzlich sollten PoPs selbst als Failure Domains betrachtet werden: ein einzelner PoP darf nicht die komplette Internet-Erreichbarkeit gefährden.

• Dual Edge Router: ER-A und ER-B, getrennte Linecards/PSUs/Racks, idealerweise getrennte Fabric-Domänen.
• Diverse Core-Uplinks: Je ER mindestens zwei Uplinks in verschiedene Core-Knoten/PoP-Cluster.
• IXP-Design: Redundante Cross-Connects, getrennte Switches, getrennte LAGs – keine Single-Patch-Panel-Falle.
• Regionale Verteilung: Mehrere Edge-PoPs, um Latenz zu senken und Region-Ausfälle abzufangen.

Designregel: Physische Diversität ist Teil des Blueprints

Policy-Redundanz hilft nicht, wenn beide Links in derselben Trasse liegen oder am selben IXP-Switch hängen. SRLGs und Facility-Risiken sollten als Pflichtattribute dokumentiert sein.

Peering-Blueprint: IXP, Route Server und PNIs

Peering ist der Hebel für Performance und Kosten. Der Blueprint sollte unterscheiden zwischen Route-Server-Peering am IXP und bilateralen PNIs. Route-Server liefern Reichweite und einfache Anbindung, aber weniger Kontrolle über einzelne Pfade. PNIs liefern Kontrolle und oft bessere Performance für große Content-Partner, erhöhen aber Betriebsaufwand. Beides kann koexistieren, wenn Policies klar sind.

• IXP Route Server (RS): Standardisierte Sessions, strikte Import-/Export-Filter, klare Communities für RS-Steuerung.
• Bilateral Peering: Direkte Sessions zu großen Netzwerken/Content, granularere Policy, separate Max-Prefix/Thresholds.
• Peering Policy: LocalPref-Modell, Backup-Strategien (Failover zu Transit), Outage-Handling.
• Traffic Engineering: Inbound beeinflussen (AS-Path Prepends, Communities), Outbound über LocalPref/Policy.

Anti-Pattern: RS und Bilateral ohne klare Prioritäten

Wenn RS- und bilaterale Routen gleich priorisiert sind, entsteht Pfadflapping oder ineffiziente Nutzung. Ein Blueprint sollte ein deterministisches Preference-Modell definieren.

Transit-Blueprint: Resilienz, Kostensteuerung und Guardrails

Transit ist die Sicherheitsleine für Reichweite. Er muss redundant sein, sauber gefiltert und kostentechnisch kontrollierbar. Der Blueprint sollte definieren, wie viele Transitprovider minimal erforderlich sind, wie sie regional verteilt sind, und wie im Fehlerfall umgeschaltet wird, ohne dass der Edge instabil wird.

• Multi-Transit: Mindestens zwei Transitprovider, idealerweise mit diverser physischer Anbindung und getrennten PoPs.
• Preference-Modell: Peering bevorzugt, Transit als Fallback – aber mit Ausnahmen für Qualitäts-/SLA-Ziele.
• Max-Prefix und Limits: Harte Limits plus Warnschwellen, pro Provider und pro Address Family (IPv4/IPv6).
• Route Filtering: Default-deny, nur erwartete Routen akzeptieren, klare Behandlung von Default Route (falls genutzt).

Designregel: Transit ist nicht gleich „alles nehmen“

Ein Provider, der „einfach alles“ akzeptiert, wird anfällig für Leaks und Instabilität. Filtering und Max-Prefix sind Pflicht, nicht optional.

BGP-Blueprint am Internet Edge: Policy-Vertrag, Communities und Leak-Prevention

Am Internet Edge ist BGP die zentrale Steuer- und Schutzebene. Der Blueprint sollte ein klares Community-Schema und ein Preference-Modell definieren: welche Routenklassen werden bevorzugt, wie werden Blackholes signalisiert, wie wird Prepending umgesetzt, und wie werden regionale Steuerungen abgebildet. Ebenso wichtig sind Guardrails: Export-Whitelists, No-Transit-Regeln, AS-PATH-Filter, Max-Prefix und konsequente Default-deny-Haltung.

• Community Contract: Standardisierte Communities für LocalPref-Steuerung, No-Export, Blackhole, Prepend, Region-Tags.
• Export-Whitelist: Nur autorisierte Aggregate werden nach außen exportiert; keine internen Infrastrukturprefixe.
• No-Transit: Peering darf nicht zu Transit werden; strikte Exportregeln zwischen Peer-Typen.
• Max-Prefix: Session-Limits und Alarmierung, inklusive Runbook für automatische oder manuelle Schutzreaktionen.
• Graceful Handling: Dämpfung/Flap-Resistenz durch Hold-downs und klare Timerprofile (konservativ, getestet).

Anti-Pattern: Policies als Copy-Paste pro PoP

Ohne zentralen Policy-Vertrag entsteht Drift. Der Blueprint sollte Policies aus Rollen/Peer-Typen ableiten und per Templates/Intent Validation erzwingen.

DDoS-Integration: Scrubbing Centers, Anycast und Traffic Steering

DDoS ist am Internet Edge nicht nur ein Security-Thema, sondern ein Topologie- und Policy-Thema. Ein Blueprint muss definieren, wie Angriffstraffic erkannt, umgelenkt, bereinigt und zurückgeführt wird – und wie dabei legitimer Traffic möglichst wenig beeinträchtigt wird. Typische Muster sind Scrubbing Centers (zentral oder regional), Anycast-basierte Services, sowie BGP-basierte Mitigationsmechanismen wie RTBH oder FlowSpec.

• Scrubbing Centers: Dedizierte Standorte mit hoher Kapazität; regional verteilt reduziert Latenz und DCI-Hairpinning.
• Traffic Steering: BGP Communities/Policies zur Umlenkung ins Scrubbing; klare Rückführung nach Ende der Mitigation.
• RTBH/FlowSpec: Schnelle Blackhole- oder Filterregeln, streng begrenzt und nur aus autorisierten Quellen zulässig.
• Anycast Services: DNS/Cache/Ingress Anycast kann Resilienz erhöhen, muss aber mit Health-Gates und DDoS-Handling abgestimmt sein.

Designregel: Mitigation darf nicht zum eigenen Outage werden

DDoS-Maßnahmen müssen „safe by default“ sein: begrenzter Scope, klare Autorisierung, Ablaufzeiten und Monitoring, damit Fehlkonfigurationen nicht legitimen Traffic großflächig blockieren.

DDoS-Guardrails: Autorisierung, Scope, Expiry und Containment

Die gefährlichsten DDoS-Fehler sind nicht Angriffe, sondern falsche Mitigations. Ein Internet-Edge-Blueprint sollte deshalb Guardrails definieren, die Missbrauch und Fehlbedienung verhindern. Dazu gehören autorisierte Quellen für Blackhole/FlowSpec, strikte Scope-Regeln, automatische Ablaufzeiten und regionale Containment-Mechanismen.

• Authorized Sources: Nur bestimmte Systeme/Teams dürfen Mitigations auslösen (z. B. DDoS Controller, SOC).
• Scope Control: Regeln gelten nur für betroffene Prefixe/Flows, nicht global; Whitelists für kritische Ziele.
• Expiry: Mitigations laufen automatisch aus, wenn sie nicht aktiv bestätigt werden.
• Containment: Regionale Begrenzung, damit lokale Events nicht das gesamte Netz beeinflussen.

Anti-Pattern: FlowSpec/RTBH ohne Change- und Audit-Logik

Mitigation ohne nachvollziehbare Historie erschwert Forensik und erhöht das Risiko wiederholter Fehlkonfigurationen. Der Blueprint sollte Auditability als Pflicht festlegen.

QoS- und Kapazitäts-Blueprint: Edge als Engpass kontrollieren

Internet Edge ist häufig ein Kapazitätsbrennpunkt: viele 100G/400G-Links, hohe PPS-Raten, DDoS-Peaks und Trafficspitzen durch Events. Der Blueprint sollte Kapazitätsplanung als Headroom-Strategie definieren und QoS dort einsetzen, wo Engpässe entstehen: Transitlinks, IXP-Uplinks, DCI-Pfade zu Scrubbing Centers.

• Headroom: N-1 Planung pro PoP und pro Provider; DDoS-Szenarien als eigenes Budget.
• Queueing an Engpässen: Policing/Queueing an Provider-Edges, Schutz kritischer Control-Plane/Management-Flows.
• ECMP/LAG-Imbalance: Member-Auslastung überwachen, Hashing-Strategien konsistent halten.
• Degraded Mode: Bei Ausfällen oder Angriffen definierte Prioritäten (z. B. Kundenservices vor Bulk).

Designregel: DDoS ist ein Kapazitätsfall, kein Ausnahmefall

Wenn DDoS nur als „Security Event“ betrachtet wird, fehlt oft das Kapazitätsbudget. Der Blueprint sollte DDoS als Lastfall in Headroom- und QoS-Planung integrieren.

MTU und Transportpfade: Scrubbing und DCI ohne Blackholes

Wenn Traffic ins Scrubbing umgeleitet wird, durchläuft er oft andere Pfade als im Normalbetrieb, inklusive DCI-Links und Overlays. MTU-Probleme treten dann selektiv auf. Ein Blueprint muss deshalb MTU-End-to-End definieren, PMTUD/ICMP-Handling absichern und Tests für Normal- und Mitigation-Pfade etablieren.

• MTU-Standards: Mindest-MTU pro Linkklasse (IXP, Transit, DCI, Core Uplink), inkl. Overhead.
• PMTUD/ICMP: Blackhole Prevention durch saubere Behandlung von ICMP und ggf. MSS-Strategien.
• Mitigation-Pfade testen: MTU und Latenz nicht nur im Normalpfad, sondern im Scrubbing-Pfad validieren.
• Failover berücksichtigen: MTU muss auch bei N-1 noch passen, nicht nur bei idealer Topologie.

Anti-Pattern: MTU nur im Normalbetrieb prüfen

Viele Incidents passieren erst bei Umlenkung oder Failover. Der Blueprint sollte Tests explizit für DDoS- und Failoverpfade fordern.

Ops-Blueprint: Monitoring, Alarmierung und Troubleshooting ohne Noise

Internet Edge Betrieb braucht High-Signal Observability. Die wichtigsten Signale sind BGP-Health (Sessions, Prefix-Counts, Updates), Traffic- und Engpasssignale (Portauslastung, Drops, Imbalance) und DDoS-Signale (Scrubbing Aktivität, Mitigation States). Der Blueprint sollte definieren, welche KPIs Pflicht sind und wie Alerts korreliert werden.

• Pflichtmetriken: BGP Session State, Prefix-Counts, Max-Prefix Near-Threshold, Update-Raten, CPU/Memory.
• Traffic KPIs: Ingress/Egress pro Peer/IXP/Transit, per-member LAG-Auslastung, Queue-Drops.
• DDoS KPIs: Mitigation aktiv, Scrubbing Throughput, Drop/Allow Ratios, Steering-Events, Expiry-States.
• High-Signal Alerts: „Prefix Spike + Max-Prefix near + CPU rise“ oder „IXP link down + traffic shift + drops“.

Designregel: Alerts müssen den Kontext liefern

Ein Alarm ohne Kontext erzeugt Noise. Der Blueprint sollte Alerts mit Topologie-Labels (PoP, Rolle, Peer-Typ, Linkklasse) und Runbook-Verweisen standardisieren.

Ops-Blueprint: Change-Methodik, Canary, Wellen und Rollback

Am Internet Edge sind Changes riskant, weil sie global wirken können. Ein Blueprint muss deshalb progressive Rollouts erzwingen: Canary-PoPs, kleine Wellen, objektive Stop/Go-Kriterien und getestete Rollbacks. Zusätzlich sollten Policy-Änderungen durch Intent Validation geprüft werden: kein Leak, Max-Prefix gesetzt, Export-Whitelist aktiv, DDoS-Guardrails intakt.

• Canary-PoPs: Repräsentative Standorte mit realer Last, aber begrenztem Blast Radius.
• Stop/Go Gates: SLOs (Loss/RTT), Prefix-Counts, Update-Raten, Drops, DDoS-Steering-Stabilität.
• Rollback: Reversibel geplante Policies (Communities/LocalPref), klare Rückkehrpfade, keine One-Way Changes.
• Evidence-by-Design: Expected vs. Observed dokumentieren, Testreports und Diffs versionieren.

Anti-Pattern: Policy-Change ohne Simulation der Wirkung

Ein Diff zeigt nicht, welche Prefixe nach dem Change exportiert würden. Der Blueprint sollte Pre-Change-Tests auf Policy-Output verpflichtend machen.

Standardisierte Dokumentation und Source of Truth

Internet Edge ist nur dann skalierbar, wenn Daten konsistent sind: Peer-Daten, ASN, Session-IDs, Linkklassen, Communities, Max-Prefix Werte, Scrubbing-Pfade. Der Blueprint sollte eine Multi-Layer-Dokumentation und eine Source-of-Truth-Strategie definieren, damit Betrieb und Automatisierung auf derselben Wahrheit basieren.

• L1: Cross-Connects, SRLG, IXP-Fabric-Anbindung, diverse Uplinks.
• L2: VLAN/LAG-Design am IXP, Port-Channels, Member-Visibility.
• L3/BGP: Neighbor-Inventar, Policy-Typen, Communities, Max-Prefix, Export-Whitelists.
• Services/DDoS: Mitigation-Workflows, Scrubbing-Routen, autorisierte Quellen, Expiry-Mechanik.

Designregel: Eine Datenquelle pro Attribut

Peering-Daten in zehn Wikis führen zu Drift. Der Blueprint sollte definieren, wo Peer-Daten gepflegt werden und wie sie in Templates/Policies einfließen.

Erfolgsmetriken für den Internet Edge Blueprint

Ein Referenzdesign muss messbar besser werden: stabiler, günstiger, schneller, sicherer. Die KPIs sollten Performance, Stabilität, Security und Operability abdecken.

• Performance: p95/p99 Latenz zu Referenzzielen/Content, Loss, Jitter, Pfadstabilität.
• Kosten: Transit-Quote vs. Peering-Quote, Cost-per-GB, Anteil über PNIs, effiziente Auslastung.
• Stabilität: BGP Flap-Rate, Prefix-Spikes, Max-Prefix Events, MTTR bei Edge-Incidents.
• DDoS: Time-to-Mitigation, False Positive Rate, Scrubbing Headroom, Mitigation Drift/Expiry Compliance.
• Operability: Change-Failure-Rate, Rollback-Rate, Drift-Events zwischen SoT und Konfiguration.

Praktische Leitlinien: Telco Blueprint „Internet Edge“ sofort anwendbar machen

• Rollen und Kanten definieren: Edge Router, Core-Uplinks, IXP/Transit-Klassen, DDoS-Domäne als separate Service-Edge.
• Dual-Edge pro PoP: Diverse Uplinks, SRLG-Disziplin, klare Wartungsdomänen; Edge-PoPs regional verteilen.
• Peering standardisieren: RS vs. bilateral trennen, Preference-Modell festlegen, Communities konsistent halten.
• Transit robust bauen: Multi-Transit, Max-Prefix, Default-deny Filtering, definierte Failover-Logik.
• Guardrails verpflichtend: Export-Whitelist, No-Transit, Max-Prefix, CoPP, klare Policy-Contracts.
• DDoS integrieren: Scrubbing Centers (regional, wenn möglich), Steering-Mechaniken, RTBH/FlowSpec nur autorisiert und mit Expiry.
• Kapazität als Headroom-Plan: N-1 pro PoP/Provider, DDoS als Lastfall, ECMP/LAG-Imbalance messen.
• MTU/Failover testen: Normal- und Mitigation-Pfade, PMTUD/MSS, Blackhole Prevention.
• Observability-by-Design: Pflichtmetriken, High-Signal Alerts, Runbooks, Topologie-Labels (PoP/Peer-Typ/Linkklasse).
• Change-Methodik erzwingen: Canary, Wellen, Stop/Go Gates, getesteter Rollback, Intent Validation für Policy-Wirkung vor jedem Change.