Use case · CG-NAT
Address subscribers from private space and translate them to a small public block with carrier-grade NAT44. Allocation is deterministic — each subscriber gets a contiguous port block — so a handful of public addresses serves thousands of lines and one log record, not one per flow, maps a public port back to a subscriber.
Subscribers are addressed from shared private space (100.64.0.0/10 or RFC 1918). A CG-NAT IP group owns a small public block, and each subscriber is handed a contiguous range of ports from it — a port block — up to a configured per-subscriber cap. The inside pool is never announced.
Mapping and filtering are endpoint-independent (EIM/EIF) with hairpinning, so inbound connection reuse, STUN and peer-to-peer work the way subscribers expect. Chunk size, per-subscriber port cap, binding and quarantine timeouts and the setup rate are all configurable.
It runs integrated on the BNG, or as a standalone netavo-cgn appliance that takes routed subscriber traffic from other BNGs and translates it. Same data plane and same deterministic logging either way.
The CG-NAT overview — IP groups, public pools, active bindings and refusal counters.
A cgn IP group names the public addresses and the port-block granularity (chunkSize) and per-subscriber ceiling (portCap). maxBindings and maxFlows size the tables; the logger ships a record per port-block allocation over syslog or Azure Service Bus.
Because allocation is deterministic and block-based, the audit trail is one record per subscriber per block, not per flow — the traceability regulators ask for, without the volume of per-flow logging.
A /28 of public space (16 addresses) behind one group, blocks of 512 ports to 2048 per subscriber.
Group health at a glance — active bindings against capacity, and the refusal counters that show if the pool or rate is tight.
One subscriber's binding: a contiguous public port range, resolved from a public port in a single lookup.
Deterministic port blocks mean a public address and port map back to a subscriber from a single log line, not a search through per-flow records.
Endpoint-independent mapping and filtering with hairpinning keep STUN, peer-to-peer and inbound connection reuse working behind the NAT.
Run it on the BNG that terminates the subscribers, or as a separate netavo-cgn appliance fed by other BNGs. Same configuration, same logging.
Binding and flow tables are sized in the config and bounded by memory; there is no per-subscriber or per-flow licence to buy.
Start a free evaluation and translate a test subscriber, or read the CG-NAT guide for pool sizing, logging and the standalone role.