IPv4 CGNAT port exhaustion at a regional broadband provider
A regional broadband provider serves 50,000 residential subscribers through a Nokia 7750 SR BNG running NAT44. The provider has only eight public IPv4 addresses left for CGNAT and currently uses dynamic NAT with a 1,024-port limit per subscriber. During the 20:00-23:00 peak, conntrack reaches 2.4 million entries and roughly 3% of subscribers receive no-ports-available errors. Gaming and VoIP customers also complain that their public IP and port range change several times per evening, breaking session continuity. The provider cannot buy more IPv4 addresses in the next 12 months. Lawful-intercept and abuse logging require that any public IP and port can be mapped back to a subscriber for at least 180 days. The BNG has 32 GB RAM and two 100G uplinks. The operations team wants a configuration change that improves port availability and stability without replacing hardware.
1. Calculate the available NAT port capacity and assess whether the current 1,024-port-per-subscriber policy can work with eight public IPv4 addresses. State your assumptions.
Read the worked answer
Each public IPv4 address has 65,536 ports. Reserving 0-1023 on each address leaves 64,512 usable ports per address, or 8 x 64,512 = 516,096 ports. The current policy promises 1,024 ports to each of 50,000 subscribers, which would require 51.2 million ports - about 99 times the available pool. Even though only 2.4 million conntrack entries are active at peak (average 48 per subscriber), the pool is exhausted by subscribers that need many simultaneous ports, so 3% see no-port errors. The 1,024 limit is not the root cause; the eight-address pool is. To guarantee 1,024 ports per subscriber you would need about 794 public addresses after reserving low ports. PBA alone cannot create ports.
2. Recommend a configuration and logging approach that improves stability for gaming and VoIP while staying within the existing public IPv4 pool. Be explicit about what cannot be solved without more IPv4.
Read the worked answer
Use PBA with deterministic port blocks only as a stability measure, not as a capacity fix. A practical design is: IPv6 dual-stack for as much traffic as possible; for IPv4, set a PBA block size of 64 ports and allow up to four blocks per subscriber (256 ports maximum), with a dynamic fallback for short bursts. Log block allocations (public IP, port range, subscriber ID, start and end time) rather than every flow; this meets the 180-day mapping requirement with far less data. Pinning gaming and VoIP to a stable first block reduces IP and port churn. However, with 516,096 ports total, even 64-port blocks give only 8,064 concurrent blocks, so not all 50,000 subscribers can hold a block at once. The design must therefore prioritize IPv6 and accept that full 1,024-port service is impossible without more IPv4.
3. What verification and monitoring would you put in place before and after the change?
Read the worked answer
Before the change, baseline conntrack, port-allocation failures, per-subscriber block counts, and PBA log volume. After the change, monitor no-port counters, block churn per subscriber, and latency for gaming and VoIP probes. Alert at 80% pool utilization and at any subscriber exceeding the block cap. Verify lawful-intercept export by querying a known subscriber mapping and checking 180-day retention. Test failover of the BNG and confirm that PBA mappings survive or are rebuilt consistently.