Edge Topologies: CGNAT, Firewalls, DDoS Scrubbing und Service Chaining

Edge Topologies sind im Telco- und ISP-Umfeld der Ort, an dem Produktlogik auf Netzrealität trifft: Hier werden Kundendienste terminiert, Sicherheitsfunktionen durchgesetzt und Traffic so gesteuert, dass Performance, Verfügbarkeit und Compliance zusammenpassen. Gerade Funktionen wie CGNAT (Carrier-Grade NAT), Firewalls, DDoS Scrubbing und Service Chaining sind nicht nur „Boxen am Rand“, sondern tief in Topologie, Routing, Kapazitätsplanung, Observability und Security Domains eingebettet. Ein schlechtes Edge-Design führt zu klassischen Problemen: NAT wird zum Single Point of Failure, Firewalls werden zu Bottlenecks, DDoS-Mitigation destabilisiert das Routing, oder Service Chains verursachen asymmetrische Pfade, Reordering und schwer erklärbare Drops. Ein professionelles Design dagegen nutzt klare Rollenmodelle (Subscriber Edge, Internet Edge, Security Edge), trennt Failure Domains, reduziert Zustandsflächen im Core und macht Sicherheits- und Servicefunktionen auditierbar. Dieser Artikel zeigt praxisnah, wie Sie Edge-Topologien für CGNAT, Firewalls und DDoS Scrubbing aufbauen und wie Service Chaining so umgesetzt wird, dass Wachstum möglich bleibt – ohne Komplexitäts-Explosion und ohne dass Betriebsteams im Störfall im Dunkeln stehen.

Warum die Edge im Provider-Netz eine eigene Architekturdomäne ist

In klassischen Netzdiagrammen ist die Edge „außen“. In der Praxis ist sie der strategische Mittelpunkt vieler Entscheidungen: Hier endet Kundenspezifik, hier beginnt Internet/Peering, hier greifen Security Policies, hier liegen oft gesetzliche Anforderungen (Logging, LI-Workflows) und hier eskalieren DDoS-Ereignisse zuerst. Deshalb sollte die Edge als eigene Domain geplant werden – mit eigenem Routing-/Policy-Modell, eigenem Kapazitätskonzept und eigenem Security- und Betriebsmodell.

• Stateful Funktionen: CGNAT und Firewalls halten Zustände – das beeinflusst Redundanz und Failover.
• Traffic-Schwerpunkt: Ein großer Teil des Volumens passiert die Edge (Internet, CDN, Cloud).
• Security Boundary: Angriffsfläche und Kontrollpunkte liegen an der Außenkante.
• Service-Logik: Subscriber Policies, Produktprofile, QoS- und Session-Kontrollen werden hier umgesetzt.

Leitprinzip: Core transportiert, Edge entscheidet

Ein robustes Provider-Design hält den Core möglichst „langweilig“ und verschiebt Servicekomplexität an definierte Edge-Knoten. Das reduziert Blast Radius und macht Changes operativ kontrollierbarer.

Rollenmodell der Edge: Subscriber Edge, Internet Edge, Security Edge

Die Edge ist kein monolithischer Block. Erfolgreiche Telcos trennen Rollen – mindestens logisch, häufig auch physisch – damit Skalierung und Security Domains funktionieren. Diese Trennung verhindert, dass eine einzelne Plattform gleichzeitig NAT, Firewall, DDoS und Peering machen muss und damit zum unbeherrschbaren Risikoknoten wird.

• Subscriber Edge: Terminiert Access/BNG/BRAS-nahe Funktionen, Subscriber-Policies, ggf. NAT-nahe Logik.
• Internet Edge: Peering/Transit, Exits, BGP-Policies, Traffic Engineering für Internetpfade.
• Security Edge: DDoS-Erkennung/Abwehr, Scrubbing, Firewalls/Inspection, kontrollierte Service Chains.
• Management & Tooling: Eigene Management-Domain/VRF, Jump-Zones und Auditpfade, getrennt vom Datenpfad.

Warum Rollen die wichtigste Komplexitätsbremse sind

Wenn jede Box alles kann, entstehen Sonderfälle und unklare Failure Domains. Rollenmodelle erlauben Blueprints: gleiche Rolle, gleiche Policies, gleiche Tests – unabhängig von Region oder Hersteller.

CGNAT Topologien: Stateful Skalierung ohne Single Points

CGNAT ist im IPv4-Internet weiterhin ein notwendiger Baustein, besonders im Consumer-Bereich. Technisch ist CGNAT vor allem ein State-Thema: Millionen bis Milliarden von Sessions, Port-Budgets pro Subscriber, Logging/Accounting und oft harte Performanceanforderungen. Topologisch bedeutet das: CGNAT muss horizontal skalieren, resilient sein und darf nicht als zentraler Engpass den gesamten Internetzugang dominieren.

• Zentraler CGNAT-Cluster: Einfacher Betrieb, aber große Failure Domain und potenziell lange Hairpins.
• Regionaler CGNAT: Bessere Latenz und kleinere Failure Domains, aber mehr Betriebskomplexität.
• Distributed CGNAT Pattern: Nähe zum Subscriber Edge; reduziert Backbone-Last, erfordert aber strenge Standardisierung.
• State & Logging: Session-Logs und Port-Allocation müssen mit Compliance und Betrieb harmonieren.

Designregel: CGNAT braucht echte N+1-Redundanz und klare State-Strategie

Weil CGNAT stateful ist, ist Failover nicht trivial. Ein Design muss klären: Was passiert bei Node-Ausfall? Wie schnell werden Sessions neu aufgebaut? Welche Services tolerieren das? Und wie wird verhindert, dass ein Failover sofort Überlast erzeugt?

CGNAT und Routing: Anycast, deterministische Pfade und Symmetrie

Ein Kernproblem in CGNAT-Designs ist Pfadsymmetrie: Viele NAT-Setups benötigen, dass Hin- und Rückverkehr konsistent durch denselben NAT-State läuft. Asymmetrische Pfade können zu Sessionabbrüchen führen. Topologisch werden daher oft deterministische Patterns genutzt, etwa definierte Exit-Punkte oder Anycast-nahe Designs mit klaren Guardrails.

• Symmetrie sichern: Routing-Policies so gestalten, dass Rückverkehr durch denselben CGNAT-Pfad zurückläuft.
• Anycast-Ansätze: Können Skalierung verbessern, erfordern aber strikte Kontrolle, damit State nicht „wandert“.
• ECMP/Hashing beachten: Hashing kann viele Sessions auf wenige Member-Links legen; Telemetry ist Pflicht.
• Failure Domains: Regionale Exits begrenzen Blast Radius bei CGNAT-Events.

Ein häufiges Anti-Pattern: CGNAT zentral, Peering regional

Wenn CGNAT zentral ist, aber Internet-Exits regional verteilt sind, entstehen Hairpins und unvorhersehbare Pfade. Besser ist, CGNAT und Internet-Exit topologisch zu koppeln oder klare Transit-Pfade zwischen beiden zu definieren.

Firewall-Topologien: Perimeter ist nicht gleich Policy

Provider-Firewalls erfüllen sehr unterschiedliche Aufgaben: klassischer Internet-Perimeter, B2B-Partnerzonen, Managementschutz, Service-Edge-Policies oder kundenspezifische Security-Services. Topologisch ist entscheidend, ob Firewalls inline (im Datenpfad) oder als kontrollierter Service-Pfad (Service Chaining) genutzt werden. Inline erhöht Determinismus, kann aber Bottlenecks erzeugen. Service Chaining erhöht Flexibilität, kann aber Komplexität erhöhen.

• Inline Perimeter: Einfach zu verstehen, klarer Pfad, aber Kapazitäts- und Upgrade-Risiko.
• Zonen-Firewalls: Trennen Security Domains (Management, Plattformdienste, Partner, Kunden).
• Security-as-a-Service: Firewalls als optionaler Service pro Kunde/VRF, oft über Service Chaining.
• Stateful vs. Stateless: Stateful Inspection erfordert Symmetrie und beeinflusst ECMP/Failover.

Designregel: Firewalls gehören an definierte Policy Points, nicht überallhin

Ein verteiltes „Firewall überall“-Modell skaliert schlecht. Besser: klare Übergänge zwischen Domains (Policy Points), die standardisiert und überwacht werden.

DDoS Scrubbing: Topologie für Normalbetrieb und Angriffsmodus

DDoS-Abwehr ist nicht nur ein Produkt, sondern ein Betriebsmodus. Im Normalbetrieb soll Traffic möglichst direkt laufen (kurze Pfade, geringe Latenz). Im Angriffsmodus muss Traffic ggf. umgeleitet, gefiltert oder gescrubbt werden – ohne dass das Routing kollabiert oder Kunden unbeabsichtigt offline gehen. Scrubbing-Topologien müssen daher zwei Pfadklassen unterstützen: Normalpfad und Scrubbingpfad, mit klaren Triggern, Kapazitätsreserven und Failback-Regeln.

• Zentrales Scrubbing Center: Einfacher Betrieb, hohe Filterkapazität, aber potenzielle Latenzsteigerung und große Failure Domain.
• Regional Scrubbing: Geringere Latenz und bessere Failure-Domain-Kontrolle, aber höhere Komplexität.
• On-Net vs. Off-Net Scrubbing: On-Net gibt mehr Kontrolle, Off-Net kann schnell skaliert werden, erfordert aber saubere BGP- und GRE/IPsec-Patterns.
• Signalmechanismen: Blackholing, RTBH, FlowSpec oder kontrollierte Route-Umleitung müssen standardisiert sein.

Failback ist genauso wichtig wie Mitigation

Viele Netze schaffen die Umleitung zum Scrubbing, scheitern aber am sauberen Zurückschwenken: Flapping, Restangriffe, unklare Zustände. Ein gutes Design hat klare Kriterien für Aktivierung und Deaktivierung – und Telemetry, die Wirkung und Stabilität belegt.

Service Chaining: Wie man mehrere Funktionen kontrolliert hintereinander schaltet

Service Chaining bedeutet, dass Traffic gezielt durch mehrere Servicefunktionen geführt wird, etwa CGNAT + Firewall + DDoS-Filter oder zusätzliche Services wie Proxy, DPI oder Caching. Topologisch ist die Herausforderung, Pfade deterministisch zu halten und gleichzeitig Skalierung zu ermöglichen. Je mehr stateful Funktionen in einer Kette sind, desto wichtiger werden Symmetrie, Hashing-Kontrolle und Failure-Domain-Design.

• Deterministische Pfade: Der Verkehr muss zuverlässig durch die richtige Kette laufen, ohne „Abkürzungen“.
• Stateful Symmetrie: Rückverkehr muss durch dieselben State-Halter laufen, sonst brechen Sessions.
• Skalierung: Ketten müssen horizontal skalierbar sein, ohne dass jede neue Instanz Policies sprengt.
• Observability: Pro Hop der Kette müssen Drops, Latenz und Queueing sichtbar sein.

Designregel: Ketten kurz halten und Rollen trennen

Jede zusätzliche Funktion erhöht Latenz, State und Fehlerflächen. Deshalb sollten Chains so kurz wie möglich sein und nur dort eingesetzt werden, wo der Mehrwert klar ist. Viele Provider trennen zudem „Mandatory“ Chains (für alle) von „Optional“ Chains (pro Produktklasse).

Topologie-Patterns für Edge Services: Zentral, regional, distributed

Edge-Funktionen können zentralisiert, regionalisiert oder stark verteilt umgesetzt werden. Die Wahl hängt von Traffic-Verteilung, PoP-Struktur, Kosten und Betriebsreife ab. Wichtig ist, ein Pattern konsequent als Blueprint umzusetzen – und nicht pro Region anders zu bauen.

• Zentral Pattern: Wenige große Edges, hohe Effizienz, aber große Failure Domains und potenzielles Hairpinning.
• Regional Pattern: Edge pro Region/Metro-Hub, gute Latenz und Failure-Domain-Kontrolle, mittlere Komplexität.
• Distributed Pattern: Edge sehr nah am Access; beste Latenz, aber höchste Anforderungen an Standardisierung und Automatisierung.

Ein praktisches Auswahlkriterium: Traffic-Schwerpunkte und N-1-Reserven

Wenn ein Großteil des Traffics in wenigen Regionen entsteht, sind regionale Edges oft ideal. Wenn Traffic sehr verteilt ist, steigt der Wert eines Distributed Designs – aber nur, wenn Automatisierung und Observability stark genug sind.

Kapazität, ECMP und Hashing: Edge ist Hotspot-anfällig

Edge-Plattformen sind prädestiniert für Hotspots: viele Flows, wenige große Elephant Flows, LAGs/ECMP, häufige Peaks. Hashing-Strategien und QoS sind daher keine „Core-Themen“, sondern Edge-Pflicht. Ein einzelnes LAG-Mitglied kann überlaufen, obwohl der Bundle frei wirkt. DDoS-Ereignisse können Microbursts erzeugen. CGNAT kann Session-Spitzen erzeugen. Deshalb müssen Kapazitätsplanung und Telemetry auf Member- und Queue-Ebene stattfinden.

• Member-Level Telemetry: Auslastung und Drops pro LAG-Mitglied, nicht nur aggregiert.
• ECMP-Guardrails: Pfadsets stabil halten, Remapping-Spitzen bei Failover einkalkulieren.
• QoS-Topologie: Management/Control und kritische Services schützen, Bulk-Traffic kontrolliert degradieren.
• Störfallreserve: N-1 Kapazität ist Pflicht, sonst wird Failover zur Degradation.

Ein häufiges Missverständnis: „Edge hat genug Bandbreite“

Bandbreite als Summe reicht oft, aber Verteilung und Peakverhalten entscheiden. Ohne Hashing- und Queue-Observability bleiben Hotspots lange unsichtbar und werden erst durch Kundenimpact erkannt.

Security Domains an der Edge: Trennung, Route Hygiene und Control-Plane Schutz

Edge-Funktionen sind exponiert. Deshalb sollten sie in klaren Security Domains betrieben werden: getrennte Managementpfade, kontrollierte Exits, strikte BGP-Filter und Limits, Control-Plane-Policing und definierte DDoS-Runbooks. Gleichzeitig müssen Service Chains verhindern, dass ein kompromittierter Dienst lateral in andere Domains wandert.

• Management Isolation: OOB oder Management-VRF, Jump-Zones, MFA, Session Recording.
• Route Hygiene: Default-deny Import/Export, Max-Prefix, standardisierte Communities.
• Control-Plane Protection: CoPP/Rate-Limits, Schutz der Routing- und Managementprotokolle.
• Domain Boundaries: Klare Übergänge zwischen Kunden, Internet, Security Services und Plattformdiensten.

Edge-Security ist auch Betriebs-Security

Wenn Betriebspfade unklar sind, entstehen Workarounds, die Security unterlaufen. Daher müssen Jump-Zones, Rollenmodelle und Tooling-Zonen Teil des Edge-Blueprints sein, nicht separate Projekte.

Observability: Edge Services müssen „explainable“ sein

Stateful Edge-Funktionen erzeugen Fehlerbilder, die ohne Telemetry nicht sauber zu debuggen sind: NAT-Port-Exhaustion, Session-Table-Pressure, asymmetrische Pfade, Scrubbing-Bypass, intermittierende Drops. Ein professionelles Edge-Design definiert daher eine Mindest-Telemetry: Zustandsmetriken, Queue/Drops, Pfadtransparenz und Ereigniskorrelation.

• CGNAT KPIs: Session-Counts, Port-Allocation, Drop-Reasons, Logging-Pipeline-Health.
• Firewall KPIs: Session-Tables, Rule-Hit-Rates, Drops pro Zone/Policy, CPU/Memory.
• DDoS KPIs: Attack-Detection, Mitigation-Status, Scrubbing-Bypass, Failover/Failback-Events.
• Chain Visibility: Latenz/Loss pro Hop der Kette, inklusive ECMP/LAG-Member-Sicht.

Evidence-by-Design: Edge-Changes müssen messbar sein

Weil Edge-Änderungen hochwirksam sind, sollten Rollouts immer mit Vorher/Nachher-Messungen gekoppelt sein: Latenz, Drops, CPU/State-Headroom, DDoS-Reaktionszeiten und Failoververhalten. Das reduziert Risiko und erleichtert Audit.

Typische Fallstricke und wie man sie vermeidet

• Zentrale Stateful Box als SPOF: CGNAT/Firewall zentral ohne echte Redundanz – Lösung: N+1 Cluster, regionale Patterns, getestete Failover.
• Asymmetrische Service Chains: Rückverkehr läuft vorbei am State – Lösung: deterministische Pfade, Symmetrie-Guardrails, ECMP-Kontrolle.
• Scrubbing ohne klare Trigger: Flapping zwischen Normal und Mitigation – Lösung: definierte Aktivierungs-/Deaktivierungsregeln, Hold-down, Telemetry.
• Hashing/Member-Hotspots: Einzelne Links überlaufen – Lösung: Hashing-Strategien, Member-Telemetry, Kapazitätsklassen.
• Policy-Wildwuchs: Jeder Peer/Service anders – Lösung: Blueprints, Policy-as-Code, Reviews, Wellen-Rollouts.
• Management ungeschützt: Adminzugriff direkt auf Edge – Lösung: Jump-Zones, Management-VRF/OOB, Audit.

Praktische Leitlinien: Edge Topologies robust und skalierbar bauen

• Rollen trennen: Subscriber Edge, Internet Edge, Security Edge – mindestens logisch, idealerweise mit klaren Domains.
• Stateful Funktionen N+1: CGNAT/Firewalls horizontal skalieren, Failover testen, Störfallreserve planen.
• Service Chains kurz halten: Mandatory vs. Optional Chains, klare Pfadregeln, Symmetrie sichern.
• DDoS als Betriebsmodus planen: Normalpfad und Scrubbingpfad, Trigger, Failback, Kapazitätsreserve.
• ECMP/LAG bewusst: Hashing-Entropie, Member-Visibility, Remapping-Spitzen im Failover berücksichtigen.
• Security Domains integrieren: Route Hygiene, Control-Plane-Schutz, Management-Isolation, Jump-Zones.
• Observability verpflichtend: State-, Queue-, Member- und Chain-Telemetry, Event-Korrelation.
• Blueprints standardisieren: Wenige wiederholbare Patterns pro Region/PoP, Policy-as-Code und Wellen-Rollouts.