An abuse report arrives with a public IPv4 address, source port and timestamp. The operational question is which subscriber held that translated endpoint at that time. A NAT table on the running appliance cannot answer a historical question after the connection has expired or the address has been reassigned.
Netavo's integrated CGN provides NAT44 with deterministic port-block allocation. Subscriber traffic uses allocated portions of a public address's port space. Recording ownership of those portions lets an operator answer attribution queries from block history rather than requiring a separate log for every connection.
The useful unit is an allocation interval. It must identify the subscriber, the public address, the port range and when ownership was valid. Deterministic allocation reduces the number of events required; it does not make historical records optional.
Why per-flow logging becomes expensive
Connection logging grows with connection churn. A household can create many flows while remaining on the same broadband session, and each new flow can produce creation and expiry events. Capacity planning then includes event generation, transport, indexing and retention as well as packet forwarding.
A complete per-flow record can answer an attribution query. The difficulty is maintaining completeness and making the lookup reliable at operational scale. Lost events, inconsistent timestamps or missing joins to subscriber accounting can leave a large database unable to establish ownership confidently.
The query also needs the right evidence from the requester. A shared public address alone normally identifies several subscribers. Preserve the source port, timestamp with timezone and transport protocol when available. The precision and uncertainty of the timestamp matter near a reassignment boundary.
Per-flow logs may still serve other investigations. Decide whether the requirement is subscriber attribution, connection metadata or something else before choosing a collection policy. Storing more events does not automatically make the records more useful.
Record ownership of a port range
Netavo allocates port blocks to subscriber bindings. An allocation event associates a public address and contiguous port range with the subscriber and session. Connections within that block do not each require a new ownership event because the block already identifies their subscriber.
For example, if the retained history says a subscriber owned public address 192.0.2.20, ports 2048 through 2559, throughout a particular interval, a report naming port 2300 inside that interval can be matched to the binding. This is an illustrative range, not a claim about the allocator's next choice.
The data plane still maintains connection state for translation. Reducing logging volume does not remove conntrack or turn NAT44 into a stateless forwarding operation. It changes which events must leave the appliance to reconstruct subscriber ownership.
Likewise, deterministic does not mean that a username is permanently tied to a public endpoint. Bindings end, blocks become available again, and a subscriber may obtain additional blocks. History has to capture those changes.
One event per allocation, including extensions
The shorthand “one line per subscriber” needs qualification. Netavo records an Alloc event for each chunk grant and a Dealloc event for each release. A session holding multiple chunks therefore has multiple allocation records. A long-lived subscriber can also have multiple sessions over the retention period.
The records include fields such as subscriber and session identifiers, inside address and VRF, public address, port start and end, timestamp, sequence and generation identifiers. Preserve these fields through the collection pipeline so queries can distinguish allocation history across appliances and restarts.
Generation records matter. A new generation closes the previous generation's ownership context, and recovered bindings are announced again with allocation events. Ignoring that lifecycle can leave apparently open bindings in the index after recovery.
RADIUS accounting is useful for correlating the subscriber session, but its CGN information carries only the first chunk. Use the CGN logger stream as the authoritative history for all allocated chunks, including extensions. Otherwise the busiest subscribers can be precisely the ones whose extra ports are missing from your search.
The block maths is predictable
Netavo's allocation space covers ports 1024 through 65535 inclusive. That provides 64,512 ports per public address. Dividing that space by a fixed chunk size gives a useful upper bound on the available chunks.
usable ports = 65535 - 1024 + 1 = 64512
512-port chunks: 64512 / 512 = 126 chunks per public address
1024-port chunks: 64512 / 1024 = 63 chunks per public address
| Chunk size | Chunks per public address | Planning implication |
|---|---|---|
| 512 ports | 126 | More initial bindings, less space within each chunk |
| 1024 ports | 63 | Fewer initial bindings, more space within each chunk |
These are chunk counts, not guaranteed subscriber counts. A subscriber needing extensions consumes more than one chunk. Quarantine and operational reserves also reduce what is immediately available. Netavo extends a binding on its existing public address, so spare capacity elsewhere in the pool is not always interchangeable with spare chunks on that address.
Larger blocks reduce the number of subscribers that can share an address but give each binding more room before an extension is needed. Smaller blocks improve the initial sharing ratio while making demand distribution more important. Measure real port demand and allocation failures, rather than choosing solely from the maximum arithmetic ratio.
Logging must be configured and monitored
Integrated allocation does not imply enabled traceability export. Netavo has no default CGN logger destination: an empty cgn.logger.drivers configuration produces no exported attribution history. Configure the logging path before admitting subscribers who depend on it.
The logger fan-out uses bounded memory queues and has no durable disk spool. Queue overflow can drop older events, with loss exposed through eventsLost. Syslog is an explicitly best-effort delivery choice. Design monitoring around those limitations and verify how your collector behaves during an outage.
A useful acceptance exercise deliberately interrupts collection, then examines what can and cannot be reconstructed. Alert on lost events and sequence gaps. Preserve raw records as well as an index where your retention design requires them, and test restoring a query from retained data.
Port-block history can support subscriber attribution, but it is not traffic interception or a universal compliance guarantee. Missing allocation events can leave gaps that deterministic maths cannot repair.
Make the lookup a tested procedure
Normalize the reported time and preserve its stated precision. Search for the public address and containing port range, then check that the event history establishes ownership at that time. Resolve the subscriber and session identifiers against the appropriate account history.
Treat boundary cases explicitly. If clock uncertainty overlaps a release and reassignment, report that uncertainty rather than forcing a unique result. Keep appliance identity, generation information and the evidence used for the conclusion with the investigation record.
Before production, create traffic from a known subscriber and record the observed public endpoint. Release the session, allow subsequent allocations, and query the earlier timestamp. Repeat with an extended binding and a controlled restart. That proves substantially more than seeing allocation messages arrive in a collector.
Deterministic CGNAT logging makes retention scale with allocation changes instead of every connection. Its operational value comes from preserving those fewer events accurately and being able to demonstrate the complete ownership interval when a request arrives.
Use the free evaluation, the full production build licensed for up to 50 concurrent subscribers, to test allocation and retrieval. The manual covers CGN configuration and logging options.