CGNAT (Carrier-Grade NAT) ist NAT im großen Stil: Viele private IPv4-Clients teilen sich einen begrenzten Pool öffentlicher IPv4-Adressen. In der Praxis ist CGNAT weniger ein „NAT-Feature“ als ein Betriebsprodukt: Skalierung (Sessions/Ports), deterministische Port-Zuteilung, Logging/Compliance und ein Design, das unter Last stabil bleibt. Auf Cisco-Plattformen (typisch IOS XE mit leistungsfähiger Data Plane) sind die wichtigsten Erfolgsfaktoren: saubere Port Allocation Strategien (PBA/DPA), robuste Logging-Mechanismen (idealerweise reduziertes Logging durch deterministische Blöcke) und klare Guardrails gegen Session-Explosionen. Dieser Artikel erklärt die Konzepte und zeigt praxistaugliche Muster.
Was CGNAT von „normalem NAT“ unterscheidet
NAT Overload im Enterprise ist meist „ein Site, eine Public IP“. CGNAT ist „zigtausend Clients, viele Millionen Sessions“. Dadurch werden Ressourcenmanagement, Portknappheit und Logging plötzlich kritisch.
- Skalierung: Session- und Port-Limits sind die Leitplanken
- Portknappheit: 65.535 Ports pro IPv4-Adresse sind schnell aufgebraucht
- Logging: Zuordnung „wer war wann hinter welcher Public IP:Port“
- Operativ: Blacklists, Abuse Handling, Troubleshooting bei NAT-Nebenwirkungen
Grundbegriffe: Pool, Mapping, Session und Port-Ressourcen
CGNAT lebt von Portressourcen. Ein einzelner Public IPv4-Address hat einen Portbereich. Je nach Strategie bekommen Clients Port-Blöcke oder Ports dynamisch. Je deterministischer die Zuteilung, desto einfacher wird Logging und Troubleshooting.
Port-Kapazität (vereinfachtes Modell)
- Usable Ports pro IP sind weniger als 65.535 (System/Reserved Ports)
- PortsPerUser hängt stark vom Nutzerprofil ab (Apps, P2P, Gaming)
Port Allocation Strategien: DPA vs. PBA (und warum das wichtig ist)
Es gibt zwei grundlegende Port-Allocation-Ansätze. Dynamic Port Allocation (DPA) weist Ports „on demand“ zu. Port Block Allocation (PBA) reserviert pro Client einen Portblock. PBA ist in großen Umgebungen oft betrieblich überlegen, weil du Logging und Abuse-Handling vereinfachst.
- DPA: effizient bei variabler Last, aber Logging-Volumen hoch
- PBA: deterministisch, besseres Logging, aber Port-Fragmente möglich
- Hybrid: Baseline-Block + dynamischer Zusatz bei Bedarf
Praxis-Trade-off
- Mehr Determinismus → weniger Logging, bessere Forensik
- Mehr Dynamik → bessere Port-Ausnutzung, aber mehr Records
Port Block Allocation (PBA): Design-Parameter
Wenn du PBA einsetzt, musst du Blockgröße, Reserved Ports und Reuse-Strategie festlegen. Zu kleine Blöcke führen zu häufigem „Block Exhaustion“, zu große Blöcke verschwenden Ports. Ziel ist ein stabiler Mittelweg.
- Blockgröße (z. B. 256/512/1024 Ports pro Subscriber)
- Port-Ranges: Low Ports vermeiden (z. B. <1024 oder <10240)
- Per-Subscriber Limits: Sessions/Rate-Limits als Guardrails
Blockgröße als grobe Rechnung
Logging: Warum CGNAT ohne gutes Logging „nicht betreibbar“ ist
Viele Umgebungen müssen für Abuse/Compliance nachvollziehen können: welcher interne Subscriber war zu einem Zeitpunkt hinter einer Public IP:Port sichtbar. Vollständiges Session-Logging kann aber enorme Datenmengen erzeugen. Deshalb ist die Logging-Strategie ein Kernbestandteil des Designs.
- Session-Logging: loggt jede Session (extrem viel Volumen)
- Mapping/Block-Logging: loggt nur Block-Zuteilungen (deutlich weniger)
- Syslog/Collector: zentrale Sammlung, Zeit-Synchronisation (NTP) Pflicht
Best Practices für Logging
- Deterministische Port-Blöcke, wenn möglich
- UTC/NTP konsistent (sonst Forensik wertlos)
- Log-Retention und Zugriff klar definieren
Skalierung: Die drei Engpässe in CGNAT
In der Praxis limitieren meist nicht CPU-Prozentwerte, sondern drei Ressourcen: NAT State (Sessions), Port-Ressourcen und Data-Plane-Queues/Drops. Skalierbarkeit heißt: Limits kennen, ausnutzen und schützen.
- State Table Capacity (max. Translations/Sessions)
- Port Exhaustion (pro Public IP oder pro Subscriber)
- Data-Plane Drops (ASIC/QFP) bei Burst/DoS-ähnlichen Mustern
Monitoring-Checks
show ip nat statistics
show ip nat translations | count
show interfaces | include drops|error
show platform hardware qfp active statistics drop
Guardrails: Subscriber Limits und Abuse-Resilienz
Ohne Guardrails kann ein einzelner Client (oder Malware) tausende Sessions öffnen und Ports „verstopfen“. Moderne CGNAT-Designs begrenzen Sessions pro Subscriber und drosseln ungewöhnliche Patterns. Das schützt Nutzerqualität und verhindert großflächige Ausfälle.
- Max Sessions pro Subscriber
- Rate Limits für neue Sessions
- Blacklist/Quarantine für auffällige Hosts
Hairpinning, ALGs und Applikations-Nebenwirkungen
CGNAT erzeugt reale Nebenwirkungen: Peer-to-Peer, Gaming, SIP/VoIP, eingehende Verbindungen und manche Protokolle erwarten End-to-End Adressierung. Du brauchst eine klare Entscheidung, was du unterstützt und wie du es kommunizierst.
- Hairpin NAT: interne Clients erreichen interne Services über externe Public IP
- ALGs: können helfen, können aber auch Probleme machen
- Inbound: meist nur via Port-Forwarding/PCP/UPnP (wenn unterstützt)
CGNAT Konfigurations-Pattern auf Cisco (vereinfachtes Beispiel)
Die konkrete CGNAT-Implementierung hängt stark von Plattform und Feature-Set ab. Das folgende Beispiel zeigt das Prinzip: Inside/Outside markieren, Pool definieren, Overload aktivieren und Logging/Timeouts bewusst setzen. Passe Namen, Interfaces und IPs an.
Basic NAT Overload (Pattern)
ip access-list standard NAT_INSIDE
permit 100.64.0.0 0.63.255.255
ip nat pool CGNAT_POOL 203.0.113.64 203.0.113.95 netmask 255.255.255.224
ip nat inside source list NAT_INSIDE pool CGNAT_POOL overload
interface GigabitEthernet0/1
description INSIDE (CGNAT Subscribers)
ip address 100.64.0.1 255.192.0.0
ip nat inside
interface GigabitEthernet0/0
description OUTSIDE (Internet)
ip address 203.0.113.2 255.255.255.0
ip nat outside
Timeouts bewusst setzen (Pattern)
ip nat translation timeout 3600
ip nat translation tcp-timeout 3600
ip nat translation udp-timeout 60
Port-Exhaustion erkennen: Symptome und Debugging
Wenn Ports knapp werden, äußert sich das als „Internet langsam“, „manche Sites gehen nicht“, „Apps reconnecten ständig“. In den Statistiken siehst du hohe Translation Counts, Drops oder Fehlzuweisungen. Dann ist die Frage: fehlen Public IPs, sind Blockgrößen falsch, oder gibt es einen Abuse-Client?
- Translation Count nahe Plattformlimit
- Viele neue Sessions/s, ungewöhnliche Top-Talker
- Fehler bei NAT Allocation oder Drops im Data Plane
Debug Pack
show ip nat statistics
show ip nat translations verbose | include 100.64.
show processes cpu sorted
show platform hardware qfp active statistics drop
Logging-Design im Betrieb: Von „alles loggen“ zu „nur was zählt“
Das Ziel ist, forensisch brauchbar zu sein, ohne dich selbst mit Logs zu erschlagen. In großen Umgebungen ist Mapping/Block-Logging (wenn verfügbar) der beste Kompromiss. Wenn du Session-Logging brauchst, plane Volumen und Pipeline (Collector, Storage, Rotation) professionell.
- Minimale Logfelder: Timestamp, Inside IP:Port, Outside IP:Port, Protocol
- Zeitbasis: NTP, am besten UTC
- Retention: rechtliche/vertragliche Vorgaben beachten
Quick-Runbook: CGNAT Health Check (Betrieb)
Diese Checkliste liefert schnell, ob der CGNAT-Knoten gesund ist und ob Port-/State-Ressourcen kritisch werden.
show ip nat statistics
show ip nat translations | count
show interfaces | include drops|error
show platform hardware qfp active statistics drop
show processes cpu sorted
show logging | include NAT|translation|drop
Konfiguration speichern
Router# copy running-config startup-config
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)
Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.
Was ich (je nach Paket) umsetze
-
Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)
-
Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)
-
Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation
-
Optional Security: Basic ACLs und SSH-Hardening
-
Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)
Sie erhalten
-
✅ Packet Tracer .pkt Datei
-
✅ Saubere Konfigurations-Notizen pro Gerät
-
✅ Verifikations-Checkliste + erwartete Outputs
-
✅ Kurze Dokumentation (wie die Topologie funktioniert)
Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.
Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.












