February 21, 2026

CGNAT Exhaustion: Symptome, Telemetrie und schnelle Recovery

CGNAT Exhaustion ist eines der typischen „schleichenden“ Störungsbilder in Access- und Edge-Netzen: Zunächst melden einzelne Kunden „bestimmte Apps gehen nicht“, kurze Zeit später steigen Fehlerraten bei Web, Gaming und VoIP, und am Ende sieht es aus wie ein großflächiger Internet-Ausfall – obwohl Backbone und Peering gesund sind. Der Kern ist fast immer derselbe: Ein Carrier-Grade NAT (CGNAT) kann keine neuen Übersetzungen mehr anlegen, weil Ressourcen erschöpft sind. Das kann eine Erschöpfung von öffentlichen IPv4-Adressen, Ports pro Subscriber, NAT-Session-Tables, Speicherkapazität oder CPU/Control-Plane sein. Das tückische daran: Bestehende Sessions laufen teilweise weiter, während neue Verbindungen scheitern. Dadurch entsteht ein „Patchwork“ aus funktionierenden und nicht funktionierenden Diensten, das ohne passende Telemetrie schwer zuzuordnen ist. Wer CGNAT betreibt, muss deshalb klare Symptome kennen, Telemetrie als Frühwarnsystem etablieren und eine schnelle Recovery-Strategie haben, die nicht in einen Second Outage kippt. Dieser Artikel erklärt CGNAT Exhaustion praxisnah: typische Failure Modes, verlässliche Messmethoden, Alarmierung, Diagnose-Runbook und schnelle Mitigation, die im NOC in Minuten umsetzbar ist.

Table of Contents

Was bei CGNAT „exhausted“ sein kann

CGNAT ist nicht nur „NAT“, sondern ein Bündel aus Ressourcentöpfen. Je nach Implementierung (Stateful NAT44, NAPT, Port-Block-Allocation, NAT Logging, Deterministic NAT) können unterschiedliche Limits zuerst reißen. Operativ ist es wichtig, die häufigsten Engpässe zu unterscheiden:

Port Exhaustion pro Subscriber: Ein Kunde hat sein Portbudget aufgebraucht (häufig bei P2P, sehr vielen parallelen Sessions oder fehlerhaftem Client-Verhalten).
Global Port Pool Exhaustion: Öffentliche IPv4-Adressen oder Port-Pools sind global erschöpft (z. B. zu wenig Public IPs für die Peak-Last).
NAT Session Table Exhaustion: Die maximale Anzahl gleichzeitiger NAT-States ist erreicht (Memory/TCAM/Session-Table-Limit).
Logging/Accounting Backpressure: NAT-Logging oder Lawful Intercept/Accounting ist überlastet, wodurch Sessions nicht mehr sauber angelegt werden.
CPU/Control Plane Saturation: Der CGNAT kann zwar theoretisch Sessions, aber praktisch nicht mehr schnell genug neue States anlegen (DoS-ähnliche Effekte).

Als technische Basis ist NAT in RFC 3022 beschrieben. Für CGN-typische Betriebsrealitäten ist RFC 6264 (Anforderungen und Empfehlungen für Carrier-Grade NAT) hilfreich, weil es genau die Skalierungs- und Logging-Aspekte adressiert, die in der Praxis zu Exhaustion führen.

Symptome: So erkennt man CGNAT Exhaustion aus Kundensicht

CGNAT Exhaustion äußert sich selten als „alles down“. Typischer sind selektive, schwer nachvollziehbare Effekte. Diese Symptome treten besonders häufig auf:

Neue Verbindungen scheitern: Webseiten laden nicht oder nur nach mehrfachen Versuchen, App-Login hängt, neue Downloads starten nicht.
Bestehende Sessions laufen weiter: ein laufender Stream läuft, aber neue Videos starten nicht; ein Voice-Call bleibt bestehen, neue Calls schlagen fehl.
„Manche Apps gehen, manche nicht“: Dienste mit vielen parallelen Verbindungen (Browser-Tabs, Messaging, Game-Launchers) sind stärker betroffen.
Gaming/VoIP besonders sichtbar: NAT-Typ ändert sich, Matchmaking bricht, STUN/TURN-Sessions scheitern, eingehende Verbindungen sind problematisch.
IPv6 als „Workaround“: Kunden mit funktionierendem IPv6 berichten, dass manche Dienste über IPv6 ok sind, über IPv4 aber nicht.

Wichtig: Diese Symptome können auch durch DNS, Peering-Congestion oder Paketloss entstehen. Der Unterschied bei CGNAT Exhaustion ist, dass der Fehler sehr stark mit „New Connection Rate“ korreliert und oft in Wellen an Peak-Zeiten auftritt.

Symptome: So sieht CGNAT Exhaustion in Telemetrie und Logs aus

Im NOC sollten Sie nicht auf Kundentickets warten. Gute CGNAT Telemetrie liefert eindeutige Signale, bevor es eskaliert. Typische Kennzahlen und Log-Indizien:

Port Allocation Failures: Fehlerzähler für „no ports available“, „port allocation failed“, „block exhausted“.
Session Creation Failures: „NAT table full“, „resource limit reached“, „cannot allocate state“.
Peak Concurrent Sessions: Annäherung an ein hartes Session-Limit (Memory/Session table).
High New Session Rate: plötzlich stark steigende NAT-Creation-Rate (kann legitimer Peak oder DoS/Attack sein).
Logging Queue Backlog: NAT-Logs stauen sich, Export/Collector-Latenz steigt, Drops im Logging-Pfad.
CPU/Drop Indikatoren: CPU-Spikes, Control-plane drops, CoPP hits, erhöhte Processing-Latenz bei Session-Setup.

Die häufigsten Root Causes für CGNAT Exhaustion

Exhaustion ist fast immer eine Kombination aus Kapazitätsplanung und Traffic-Mustern. Die folgenden Ursachen sind in Provider-Umgebungen besonders häufig.

Root Cause 1: Portbudget pro Subscriber zu klein oder falsch verteilt

Viele CGNAT-Setups arbeiten mit einem Portbudget pro Subscriber (z. B. Port-Block-Allocation). Ist das Budget zu klein, kann ein einzelner Haushalt mit mehreren Geräten, Browsern, Apps und Hintergrunddiensten in Spitzenzeiten Ports erschöpfen – auch ohne „Missbrauch“.

Indiz: nur ein Teil der Kunden betroffen, typischerweise Heavy-User; pro-subscriber Port-Usage erreicht Max.
Risikofaktor: kurze NAT-Timeouts und aggressive Retries erhöhen die Anzahl gleichzeitig aktiver NAT-States.

Root Cause 2: Zu wenig öffentliche IPv4-Kapazität für Peak

Wenn der globale Pool an Public IPv4-Adressen zu klein ist, geraten Port-Pools in Peak-Zeiten unter Druck. Häufig ist das nicht konstant, sondern tritt nur in Abendspitzen oder bei besonderen Events auf.

Indiz: globaler Portpool-Exhaustion steigt zeitgleich mit Peak-Usage; viele Kunden gleichzeitig betroffen.
Risikofaktor: Traffic Engineering oder Failover verschiebt Kundenpopulationen auf weniger NAT-Instanzen.

Root Cause 3: NAT-State-Table oder Memory-Limit erreicht

NAT ist stateful. Wenn zu viele Sessions gleichzeitig existieren, füllt sich die Table, und neue Sessions können nicht mehr angelegt werden. Das passiert oft, wenn NAT-Timeouts zu lang sind oder wenn bestimmte Apps sehr viele parallele Verbindungen öffnen.

Indiz: Concurrent Sessions nahe Maximum, Creation Failures steigen, CPU/Memory Pressure sichtbar.
Risikofaktor: Logging/Accounting blockiert Ressourcen (Backpressure), wodurch effektive Kapazität sinkt.

Root Cause 4: Logging/Collector wird zum Bottleneck

In vielen Jurisdiktionen sind NAT-Logs notwendig (z. B. Zuordnung public IP:port ↔ subscriber). Wenn Export/Collector/Storage nicht skaliert, kann die CGNAT-Plattform entweder Logs droppen oder in einen Modus geraten, der Session-Creation beeinträchtigt (implementierungsabhängig).

Indiz: Logging Queue Backlog steigt, Export Drops, Session Creation verzögert oder fehlschlägt.
Risikofaktor: Mass-Reconnect-Events (PPPoE/DHCP) erzeugen eine Logging-Lawine.

Root Cause 5: DoS-ähnliche Patterns oder fehlerhafte Kundenendgeräte

Ein Teil der Exhaustion-Fälle sind kein „zu wenig Kapazität“, sondern ein anormales Verhalten: Malware, P2P-Stürme, fehlerhafte CPE-Firmware oder Apps, die massiv neue Sessions öffnen. Das kann lokal (ein Segment) oder breit (Botnet) auftreten.

Indiz: New Session Rate springt stark, verteilt auf viele Quellen oder konzentriert auf bestimmte Prefixe/BNGs.
Risikofaktor: zu kurze NAT-Timeouts erzeugen zusätzlich Retries und Session-Churn.

Telemetrie: Pflichtmetriken für ein belastbares CGNAT Monitoring

Damit Sie CGNAT Exhaustion früh erkennen, sollten Sie nicht nur „NAT up“ überwachen, sondern Kapazitäts- und Qualitätsmetriken. Diese Liste ist eine praxistaugliche Mindestanforderung:

Active NAT Sessions: aktuell aktive States (gesamt und pro Instance/Blade).
Session Creation Rate: neue NAT-States pro Sekunde (gesamt und pro Subscriber-Kohorte).
Port Allocation Usage: genutzte Ports pro Public IP, pro Pool, und pro Subscriber (falls verfügbar).
Allocation Failures: Zähler für „no ports“, „no resources“, „table full“.
Logging Health: Export Queue, Drops, Collector RTT/Latenz, Storage Saturation.
CPU/Memory/Dataplane Drops: Resource Pressure und Drops auf Fast-Path/Slow-Path.
Service SLIs: synthetische Tests über IPv4 (HTTP/TLS/DNS), getrennt von IPv6, um „IPv4-only“ Impact zu sehen.

Auslastung als Anteil am Limit (MathML)

$Utilization = \frac{Resource_used}{Resource_\max}$

Praktisch: Alarme sollten nicht erst bei 100% kommen. Für CGNAT sind Warnschwellen typischerweise früher sinnvoll, weil sich Exhaustion schnell selbst verstärkt (Retries, Reconnects, mehr Sessions).

Diagnose-Runbook: CGNAT Exhaustion schnell bestätigen

Ein effektives Runbook beantwortet zuerst die Frage: Ist es wirklich CGNAT? Danach: Welche Ressource ist exhausted? Und zuletzt: Wie stabilisieren wir ohne Second Outage?

Schritt 1: Impact-Muster prüfen

Nur IPv4 betroffen? Wenn IPv6 ok ist, ist CGNAT ein starker Kandidat.
New Connections scheitern? Bestehende Sessions laufen, neue schlagen fehl – typisch für Port/State Exhaustion.
Region/BNG-Korrelation? Betrifft es nur bestimmte BNGs/PoPs (z. B. ein NAT-Pool) oder global?

Schritt 2: Ressourcen-Topf identifizieren

Ports: Port Allocation Failures hoch? Ports pro Public IP nahe Maximum?
State Table: Active Sessions nahe Limit? „table full“ Indizien?
Logging: Logging-Backlog oder Export-Drops zeitgleich mit Failures?
CPU: CPU/processing latency hoch, obwohl Limits nicht hart erreicht sind?

Schritt 3: Korrelation mit Trigger-Events

Mass-Reconnect: PPPoE/DHCP Reauth-Wellen können NAT-Last sprengen.
Failover/Traffic Shift: NAT-Pools wurden durch Routing/HA verschoben (mehr Kunden auf weniger Instanzen).
Attack/Anomalie: ungewöhnliche New Session Rate, auffällige Quell-Subnetze, DDoS-Indizien.

Schnelle Recovery: Mitigation, die im Incident funktioniert

Wenn CGNAT Exhaustion aktiv ist, zählt Stabilisierung. Die folgenden Maßnahmen sind typische „First Response“-Optionen, die Sie als Runbook vorbereitet haben sollten. Wichtig: Nicht jede Maßnahme passt zu jeder Ursache; deshalb zuerst den Ressourcentopf bestimmen.

Recovery 1: Kapazität sofort erhöhen oder Last umverteilen

Mehr Public IPv4/Port Pools: zusätzliche Adressen/Portbereiche aktivieren (wenn verfügbar).
Scale-out: weitere CGNAT-Instanzen/Blades zuschalten oder Traffic auf zusätzliche Cluster verteilen.
Traffic Steering: BNG/Policy so ändern, dass Kundenpopulationen verteilt werden (stufenweise, mit Monitoring).

Operativ wichtig: Lastverschiebungen müssen schrittweise erfolgen, um Mikrobursts, Queue Drops und den Second Outage zu vermeiden.

Recovery 2: Session-Churn reduzieren, damit das System „atmen“ kann

Rate-Limiting für neue Sessions: Begrenzen, wie viele neue NAT-States pro Sekunde angelegt werden.
Backoff fördern: Wenn möglich, Retries dämpfen (auf CPE/BNG/Service-Ebene je nach Architektur).
Hotspot-Subscribers isolieren: Heavy-User mit extremem Portverbrauch identifizieren und temporär drosseln (nur mit klaren Policies).

Recovery 3: Logging stabilisieren

Collector skalieren: zusätzliche Collector-Kapazität, Storage-IO entlasten.
Export-Pipeline prüfen: Drops/Queue Backlog reduzieren, Netzwerkpfad zum Collector stabilisieren.
Kontrollierte Degradation: Falls Ihre Compliance es zulässt, Logging-Last reduzieren (z. B. Sampling) – nur mit klarer Governance.

Recovery 4: Kontrollierter State-Abbau als Notmaßnahme

In extremen Situationen wird versucht, NAT-State zu reduzieren, um wieder handlungsfähig zu werden. Das ist riskant, weil es aktive Sessions kappt und Kundenimpact erzeugt. Wenn es unvermeidbar ist, muss es kontrolliert und segmentiert passieren.

Stufenweise: nicht „global flush“, sondern segmentweise (z. B. einzelner Pool/BNG-Kohorte).
Mit Rate-Limits: sonst folgt unmittelbar eine Reconnect-Welle, die erneut exhausted.
Mit Probes: end-to-end SLIs beobachten, bevor die nächste Stufe folgt.

Mitigation nach der Stabilisierung: Wie Sie den Second Outage vermeiden

Nach erfolgreicher Recovery ist die Versuchung groß, alle Notbremsen sofort zu lösen. Genau dann entsteht der Second Outage: Traffic und Session-Creation springen zurück, Pools laufen erneut voll. Ein sicherer Ablauf:

Stabilitätsfenster definieren: z. B. 15–30 Minuten ohne Allocation Failures und mit stabilen SLIs.
Schrittweise Rücknahme: Rate-Limits graduell erhöhen und nach jeder Stufe beobachten.
Peak-Faktor berücksichtigen: Rücknahme nicht kurz vor erwarteten Abendpeaks durchführen.

Langfristige Prävention: Damit CGNAT nicht regelmäßig exhausted

Exhaustion ist oft ein Symptom dafür, dass Kapazitätsplanung, Policies und Observability nicht zusammenpassen. Langfristig helfen vor allem diese Maßnahmen:

Port-Budget-Engineering: pro Subscriber realistische Portbudgets und Fairness-Mechanismen, mit Telemetrie über Heavy-User.
Kapazitätsmodell pro Peak: nicht nur Durchschnitt, sondern Peak Concurrent Sessions und Peak New Session Rate dimensionieren.
IPv6-Strategie: IPv6-Enablement reduziert IPv4/CGNAT-Druck und verbessert Kundenerlebnis, wenn Dual Stack sauber betrieben wird.
Logging-Architektur skalieren: Collector, Storage und Export-Pipelines als kritische Infrastruktur behandeln.
Drills und Failover-Tests: gezielt testen, was passiert, wenn ein NAT-Cluster ausfällt und Traffic umgelenkt wird.

Evidence Pack: Pflichtdaten für RCA, Vendor- und Management-Reports

Zeitlinie (UTC): Beginn, Peak, Mitigation, Stabilisierung, Ende.
Ressourcenstatus: Ports used/max, active sessions used/max, allocation failures, logging backlog.
Traffic- und Session-Raten: new session rate, per-subscriber port usage (Top-N), retry/retransmit Indizien.
Topologie-Events: Failover/TE-Änderungen, BNG Reauth-Wellen, Backbone Congestion.
Kundensicht: SLI-Verläufe (IPv4 getrennt), Ticket-Volume, regionale Verteilung.

Outbound-Ressourcen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.