Running CGNAT: Sizing, Logging, and Everything Subscribers Complain About

Running CGNAT in production comes down to three decisions: how many ports each subscriber gets, how you log translations so you can answer a lawful request, and what you do about the applications that break when subscribers share a public IPv4 address.

Get the first one wrong and heavy users run out of ports at peak hour. Get the second wrong and you store terabytes of logs nobody can search. Get the third wrong and your support line fills up with gamers and people who can no longer reach their home cameras. This section collects the numbers, configurations and support scripts that ISP engineers use to make those decisions, with a link to the full guide for each topic.

SizingPort allocation and subscribers per address

Every subscriber behind CGNAT gets a slice of the 64,512 usable ports on a shared public address. The size of that slice decides three things at once: how many subscribers fit on one address, how often a heavy user hits the ceiling, and how many log records you write.

A browser tab can open dozens of connections, a game console keeps several long sessions alive, and a home with ten devices adds them all up. That is why the right number of ports per subscriber comes from your own traffic, not from a vendor default. Measure peak sessions per subscriber first, then pick a block size with headroom for the busiest five percent of users.

Inside addresses come from the shared address space 100.64.0.0/10, reserved for exactly this purpose by RFC 6598. With port block allocation the CGNAT writes one log line when it hands a block to a subscriber, instead of one line per session.

How many subscribers can be behind one IPv4 address

Divide 64,512 by the ports you give each subscriber and you get the ceiling: 126 subscribers with 512-port blocks, 63 with 1,024-port blocks. The practical number is lower, because some users need a second block and some applications need more ports than others. The guide walks through the arithmetic and the traffic patterns that push it up or down.

Port allocation and sizing: ports per subscriber, port blocks, session table

How to pick a block size, when to allow a second block, how large the session table must be, and which counters warn you about port exhaustion before subscribers notice it.

CGNAT sizing calculator

Enter the number of subscribers, ports per subscriber and peak sessions, and get the number of public addresses, the session table size and the memory you need.

LoggingLogging and compliance

When an address is shared, a lawful request has to arrive with three details to identify a subscriber: the public IP address, the port and the exact time. The logging method you choose decides how much data you keep to answer it.

Per-session logging answers any question but produces the most data by far. Port block allocation cuts the volume sharply, because a block stays with a subscriber for hours while sessions last seconds or minutes, and each record still points to exactly one subscriber. Deterministic NAT goes further and removes per-session logs altogether, at the price of a fixed, smaller port range for each subscriber.

CGNAT logging and compliance: log volume, deterministic NAT, retention

How the three methods compare on storage and on how quickly you can answer a request, how long to keep the data, and which export to use: Syslog (RFC 5424), NetFlow v9, IPFIX (RFC 7011) or RADIUS Accounting.

TroubleshootingWhat breaks for subscribers

Most CGNAT tickets come from a short list of applications that expect an inbound connection or a stable public address: online games, peer-to-peer apps, VPN servers at home, IP cameras and some VoIP setups. The operator can fix a good part of this in the CGNAT configuration; the rest needs a clear answer from support.

What breaks behind CGNAT: gaming NAT type, P2P, inbound VPN, CCTV, SIP

Why a console reports Strict NAT, why a home camera stops being reachable from outside, and which of these problems endpoint-independent mapping and filtering (RFC 4787) solve on the CGNAT side.

Port forwarding alternatives for CGNAT subscribers

STUN and ICE for peer-to-peer apps, Port Control Protocol (RFC 6887) for devices that can request a port, static port blocks and an opt-out public address for customers who need inbound access. What each option solves and what it costs the operator.

Double NAT, NAT444 and hairpinning

A subscriber router behind a CGNAT means two layers of translation, often called NAT444. When that is harmless, when it breaks applications, and why two subscribers on the same CGNAT need hairpinning (required by RFC 4787) to reach each other through their public addresses.

Do we still need ALGs in CGNAT

Application-level gateways rewrite addresses inside FTP, SIP and DNS traffic. Which of them still matter on a modern network, which ones break more than they fix, and how to decide per protocol.

DeploymentDeploying and choosing a CGNAT

Where the CGNAT sits in the network decides how traffic reaches it and what happens when it fails. The choice of product decides how many servers you need and how you will handle logging and upgrades. Delivering IPv4 over an IPv6 access network with DS-Lite or MAP is covered in IPv6 Transition.

CGNAT deployment topologies: inline, on a stick, BNG and CMTS integration

Common placements, how traffic is steered to the CGNAT and back, and Active/Standby versus Active/Active (N+1) designs that keep sessions alive when a node fails.

How to choose a CGNAT

Throughput and sessions per server, logging options, high availability, compliance with RFC 6888 and the licensing model: the criteria that separate CGNAT products in practice, and the questions to ask every vendor.

CGNAT disadvantages and myths

Which complaints about CGNAT hold up, which are out of date, and what to do about the ones that are real: shared IP reputation, inbound access and the cost of logging.

How widely CGNAT is deployed

Measurements of CGNAT use by region and by network type, updated as new data appears.