CGNAT und Adressplanung: Logging, Pools und Kapazität richtig designen

CGNAT und Adressplanung sind im Telco-Umfeld ein Paket: Wer Carrier-Grade NAT betreibt, entscheidet nicht nur über eine technische Funktion, sondern über Betriebsfähigkeit, Compliance, Kapazität und Kundenerlebnis. CGNAT löst das akute Problem der IPv4-Adressknappheit, indem viele Kunden sich wenige öffentliche IPv4-Adressen teilen. Gleichzeitig verschiebt sich die Komplexität: Statt „eine öffentliche IP pro Anschluss“ müssen Sie NAT-States, Port-Ressourcen, Pool-Strukturen, Redundanzpfade und vor allem Logging so designen, dass sie in Spitzenlasten funktionieren und im Incident oder bei Compliance-Anfragen beweisbar sind. In der Praxis scheitern CGNAT-Projekte selten an der Grundidee, sondern an Details: zu klein dimensionierte Pools, unklare Port-Policies, zu hohe Sessiondichte pro öffentlicher IP, fehlende Korrelation zwischen DHCP/BNG/NAT-Logs, oder Logging-Pipelines, die bei Mass-Events kollabieren. Dieser Artikel zeigt praxisnah, wie Sie CGNAT-Adressplanung richtig aufsetzen – mit einem klaren Blick auf Logging, Pool-Design und Kapazität, inklusive typischer Stolperfallen und Best Practices, die den Betrieb langfristig stabil halten.

Warum CGNAT-Design immer aus drei Disziplinen besteht

CGNAT ist nicht nur „NAT aktivieren“. Ein produktionsreifes Design muss drei Bereiche gleichzeitig beherrschen: Pools (welche Adressen werden wo genutzt), Kapazität (Sessions, Ports, Throughput, Redundanz) und Logging (Nachvollziehbarkeit und Support). Wenn einer dieser Bereiche schwach ist, wird CGNAT zum Incident-Treiber.

• Pools: klare Trennung zwischen Kundenseite (privat/Shared Address Space) und öffentlicher NAT-Seite.
• Kapazität: NAT-States, Port-Verbrauch und Peak-Events müssen auch bei Störungen stabil bleiben.
• Logging: Korrelation und Retention müssen funktionieren, sonst wird Troubleshooting und Compliance teuer.

Grundlagen: Was bei CGNAT wirklich „knapp“ ist – Ports und States

Bei CGNAT ist nicht nur die Anzahl öffentlicher IPv4-Adressen relevant, sondern die Ressource Port und der NAT-State. Eine öffentliche IPv4-Adresse hat effektiv rund 65.535 Ports (praktisch weniger durch Reserven und Systembereiche). Die Frage ist: Wie viele Kunden teilen sich eine öffentliche IP, und wie viele Ports/Sessions braucht ein Kunde in der Spitze?

• Port-Dichte: viele parallele Anwendungen (Streaming, Gaming, Videokonferenzen) erzeugen viele gleichzeitige Sessions.
• State-Tabellen: NAT-Geräte müssen große Tabellen halten; Timeouts beeinflussen State-Größe stark.
• Fairness: ohne Port-Policy kann ein einzelner Anschluss viele Ressourcen verbrauchen.

Einfaches Kapazitätsdenken für Ports

Wenn eine öffentliche IP grob P nutzbare Ports bereitstellt und Sie pro Kunde einen Port-Block von B Ports reservieren, dann können Sie näherungsweise $P/B$ Kunden auf diese öffentliche IP legen. Das ist eine starke Vereinfachung, hilft aber, die Größenordnung zu verstehen und Port-Policy-Diskussionen zu objektivieren.

Pool-Design: Öffentliche Pools, Shared Pools und Scope nach Region/BNG

Ein CGNAT-Pool-Design muss skalierbar und betrieblich klar sein. Der größte Fehler ist ein „globaler Pool“, aus dem alle Regionen schöpfen. Das erschwert Kapazitätsplanung, Failover-Design und Logging-Korrelation. Besser ist ein Container-Modell: Region → PoP/BNG-Cluster → Pool.

• Öffentliche NAT-Pools: öffentliche IPv4-Adressen, typischerweise nach Region/PoP segmentiert.
• Subscriber-/Shared Address Pools: Kundenseite (privat oder shared), ebenfalls nach BNG/Cluster strukturiert.
• Serviceklassen: Residential vs. Business vs. IoT – getrennte Pools, weil Nutzungsprofile und SLAs differieren.
• Quarantäne/Reserve: Reserven für Migrationen, Wartungsfenster und DDoS/Abuse-Sonderfälle.

Best Practice: Pool-Scope so wählen, dass Blast Radius klein bleibt

Wenn ein NAT-Cluster oder eine Region Probleme hat, soll der Effekt nicht das gesamte Netz treffen. Regionale Pools und klare BNG-Zuordnung begrenzen den Impact und erleichtern Incident Response.

Port-Policy: Dynamic NAT vs. Port-Block Allocation

Ein zentrales CGNAT-Design-Element ist die Port-Vergabestrategie. Vereinfacht gibt es zwei Denkweisen: dynamische Portvergabe (Ports werden je Session zugeteilt) oder Port-Block Allocation (PBA), bei der ein Kunde einen Portblock erhält. Beide Ansätze haben Vor- und Nachteile, insbesondere für Logging und Support.

• Dynamische Portvergabe: hohe Ausnutzung, aber Logging kann sehr umfangreich werden, weil viele Einzelbindungen entstehen.
• Port-Block Allocation: stabilere Zuordnung und oft vereinfachtes Logging/Korrelation, aber potenziell geringere Ausnutzung, wenn Blocks zu groß gewählt sind.
• Hybrid: Baseline-Block pro Kunde, zusätzlich dynamische Erweiterungen bei Bedarf (kontrolliert).

Kapazitätsplanung: Sessions, Timeouts, Throughput, Peak Events

Kapazität ist mehrdimensional. Es reicht nicht, „genug öffentliche IPs“ zu haben. Sie müssen NAT-State, CPU/ASIC-Kapazität, Speicher, Logging-Throughput und Redundanz berücksichtigen. Besonders kritisch sind Peak Events: Stromausfälle, BNG-Reboots oder CPE-Firmware-Rollouts können Session-Stürme auslösen.

• Sessions pro Kunde: typischerweise stark variabel; Planung sollte Peak und P95/P99 berücksichtigen.
• Timeouts: aggressivere Timeouts reduzieren State-Größe, können aber bestimmte Anwendungen beeinträchtigen.
• Durchsatz: NAT kann zum Bottleneck werden, wenn Hardware nicht ausreichend dimensioniert ist.
• Redundanz: N+1-Design: Bei Ausfall eines Nodes müssen verbleibende Nodes Peak tragen können.
• Mass-Reconnect: nach Ausfall kommen viele Kunden gleichzeitig zurück – Session- und Logging-Spikes sind real.

Warum Timeouts eine Stellschraube mit Nebenwirkungen sind

Kürzere Timeouts reduzieren die NAT-State-Tabellen und damit Speicher/CPU-Last. Zu kurze Timeouts können aber Long-Lived-Verbindungen (z. B. bestimmte VPNs oder Idle-Verbindungen) negativ beeinflussen. Best Practice ist, Timeouts differenziert nach Protokoll/State zu setzen und Änderungen mit Messdaten zu begleiten.

Logging: Ohne belastbare Korrelation wird CGNAT betriebsblind

CGNAT verändert die Supportrealität: Eine öffentliche IP identifiziert nicht mehr eindeutig einen Kunden. Sie benötigen Logs, die eine eindeutige Zuordnung von (öffentliche IP, Port, Zeit) zu (Kundenidentifier) ermöglichen. In Telco-Umgebungen ist „Kundenidentifier“ typischerweise mehr als eine IP: DHCP-Lease-Informationen, BNG-Session-IDs, Option 82 (Access Circuit), PPPoE-Session (falls relevant) oder Subscriber-ID.

• NAT-Logs: Zuordnung von Private/Subscriber-IP und Port zu Public-IP und Port, inkl. Zeitstempel.
• BNG/Session-Logs: welcher Subscriber war wann aktiv, auf welchem Access, mit welcher IP.
• DHCP-Logs: Lease-Historie, MAC/Client-ID, Circuit-ID/Remote-ID (Option 82), Zeitstempel.
• Korrelation: diese Logquellen müssen über gemeinsame Schlüssel zusammengeführt werden (Zeitfenster, Session-ID, Subscriber-ID).

Logging-Design: Volumen, Retention und Performance

In CGNAT-Umgebungen kann Logging schnell zum größten Datenproduzenten werden. Wenn das Logging-System unter Last dropt, verlieren Sie Nachvollziehbarkeit genau dann, wenn Sie sie am dringendsten brauchen (Peak Events, Abuse-Fälle, Incidents). Deshalb muss Logging wie ein Produktionssystem dimensioniert werden.

• Volumenabschätzung: Events pro Sekunde (EPS) in Peak-Szenarien und durchschnittliche Eventgröße bestimmen.
• Retention: Aufbewahrungsdauer und Zugriffspfade definieren (operativ vs. Compliance).
• Pipeline-Resilienz: Buffering, Backpressure, Queueing, Drop-Policies – damit Peaks nicht alles zerstören.
• Zeit-Synchronisation: konsistente Zeitbasis (NTP) ist Pflicht, sonst scheitert Korrelation.

Best Practice: Logging als „Tiered Storage“ denken

Operative Logs (für schnelle Troubleshooting-Abfragen) und Langzeit-Archive (für Compliance) müssen nicht dieselben Systeme und Performanceanforderungen haben. Ein zweistufiges Modell reduziert Kosten und erhöht Stabilität.

Adressplanung auf der Kundenseite: Shared Address Space sauber strukturieren

Viele Telcos nutzen für Kunden hinter CGNAT einen privaten oder shared Adressraum. Kritisch ist, dass diese Bereiche nicht „wild“ verteilt werden. Sie sollten pro Region/BNG-Cluster definierte Subscriber-Pools haben, die in IPAM gepflegt sind, damit Pools nicht kollidieren und Failover planbar bleibt.

• BNG-gebundene Pools: Subscriber-Pool an BNG/Cluster koppeln, damit Sessions und Logging konsistent sind.
• Lease- und Session-Design: DHCP-Lease-Zeiten und Session-Lifetimes beeinflussen Pool-Auslastung.
• Reserveblöcke: Migrationen oder Cluster-Erweiterungen brauchen freie Bereiche, sonst entstehen Quer-Vergaben.

Redundanz und Failover: Was bei CGNAT besonders gefährlich ist

Failover in NAT-Umgebungen ist anspruchsvoll, weil NAT zustandsbehaftet ist. Bei einem Node-Ausfall gehen States verloren, Sessions brechen, und Clients bauen neu auf. Das ist akzeptabel, solange das Design es erwartet und die verbleibende Kapazität reicht. Gefährlich wird es, wenn Failover zu Pool-/Port-Verwechslungen oder inkonsistentem Logging führt.

• N+1 Kapazität: verbleibende Nodes müssen Peak tragen können.
• Deterministische Zuordnung: Subscriber → NAT-Pool/Port-Policy möglichst stabil, damit Verhalten im Incident erklärbar bleibt.
• Logging-Kontinuität: Failover darf nicht zu „Log-Löchern“ führen; Buffering und Monitoring sind Pflicht.
• Abuse und Reputation: bei geteilter öffentlicher IP müssen Sperrungen fein steuerbar sein (z. B. pro Portblock/Subscriber), sonst treffen Maßnahmen Unbeteiligte.

Security und Abuse: geteilte IPv4 bedeutet geteilte Verantwortung

CGNAT verändert die Außenwirkung: Viele Kunden teilen wenige öffentliche IPs. Dadurch steigt das Risiko, dass Abuse, Spam oder DDoS-Feedback ganze IPs betreffen, obwohl nur einzelne Kunden verantwortlich sind. Ein gutes Design kombiniert Port-Policy, Rate-Limits und klare Prozesse.

• Fairness-Controls: Limits für Sessions/Ports pro Subscriber verhindern, dass einzelne Anschlüsse Ressourcen dominieren.
• Rate Limiting: schützt NAT- und Logging-Infrastruktur vor Flooding.
• Abuse-Prozesse: Blacklisting granular gestalten, z. B. pro Subscriber/Portblock statt pauschal pro öffentlicher IP.
• Transparenz für Support: NOC braucht Tools, um schnell zu korrelieren und zu reagieren.

Operationalisierung: IPAM, Namenskonventionen und Pflichtfelder

CGNAT ist besonders anfällig für „Schattenkonfigurationen“, weil Pools und Policies oft parallel wachsen. Deshalb sollte jede Pool- und Policy-Änderung IPAM-geführt sein. Der Schlüssel ist ein Pflichtfeldsatz: Scope, Owner, Pool-Role, NAT-Policy, Logging-Route, Lifecycle.

• Pflichtfelder NAT-Pool: Region/PoP/Cluster, Owner, Status, öffentliche Prefixe, Reserve, Policy-Referenz.
• Pflichtfelder Subscriber-Pool: BNG/VRF-Zuordnung, DHCP/Session-Policy, Lease-Parameter.
• Lifecycle: planned/active/deprecated/retired, Quarantäne vor Wiederverwendung.
• Monitoring-KPIs: Port-Auslastung, Session-Auslastung, Drops/Errors, Logging-EPS, Queue-Füllstände.

Typische Stolperfallen bei CGNAT und wie Sie sie vermeiden

• Zu kleine NAT-Pools: Port-Exhaustion und Sessiondrops – Pool und Port-Policy anhand Peak-Last dimensionieren.
• Logging-Pipeline bricht bei Peaks: Buffering/Backpressure fehlt – Logging wie Produktionssystem dimensionieren.
• Keine saubere Korrelation: DHCP/BNG/NAT nicht verknüpft – gemeinsame Identifier und Zeitbasis definieren.
• Unklare Port-Policy: unfairer Verbrauch – Limits und ggf. Port-Block-Modelle einführen.
• Failover ohne N+1: verbleibende Nodes überlasten – Redundanzkapazität einplanen.
• Abuse trifft Unbeteiligte: IP-basiertes Blocken ohne Granularität – Prozesse und Controls pro Subscriber etablieren.

Praxis-Checkliste: CGNAT mit Logging, Pools und Kapazität richtig designen

• Pool-Struktur festlegen: öffentliche NAT-Pools und Subscriber-Pools nach Region/PoP/BNG-Cluster trennen, Reserven einplanen.
• Port-Policy definieren: dynamisch vs. Port-Block (oder hybrid), Fairness- und Limitregeln festlegen.
• Kapazität dimensionieren: Sessions, Ports, Throughput, Timeouts und N+1-Redundanz anhand Peak-Szenarien planen.
• Logging-Architektur bauen: NAT-Logs + BNG-Session + DHCP-Leases korrelierbar, Zeitbasis konsistent, Retention geregelt.
• Peak Events testen: Mass-Reconnect, Failover, Logging-Spikes, Abuse-Szenarien regelmäßig simulieren.
• Security einbauen: Rate Limits, Session-Limits, Abuse-Prozesse, Monitoring für Port-Exhaustion.
• IPAM verpflichtend: Pools, Policies, Scope, Owner, Lifecycle als Pflichtdaten; keine Vergaben außerhalb des Systems.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.