- Choose a NAT mode that matches your deployment.
- Enter peak users, flows per user, and churn rate.
- Use average duration to convert churn into concurrency.
- Set burst and headroom for expected spikes and safety.
- Review public IP count and bandwidth estimates together.
- Export CSV or PDF for review and documentation.
- Mappings_by_users = PeakUsers × FlowsPerUser
- Mappings_by_rate = NewSessionsPerSecond × AvgDurationSeconds
- BaselineMappings = max(Mappings_by_users, Mappings_by_rate)
- ConcurrentMappings = ceil(BaselineMappings × BurstMultiplier × (1 + Headroom%))
- EffectivePortsPerIP = (65535 − ReservedPorts) × PortUtilization
- PublicIPs = ceil((ConcurrentMappings × PortsPerMapping) / EffectivePortsPerIP) (PAT/CGNAT)
- PublicIPs = ceil(PeakUsers × BurstMultiplier × (1 + Headroom%)) (static)
- BandwidthMbps = (ConcurrentMappings × AvgKbpsPerSession) / 1000
- StateMemoryMB = (ConcurrentMappings × MemKBPerMapping) / 1024
- vCPU ≈ (ConcurrentMappings / 100000) × vCPUper100k × (1 + LoggingOverhead%)
| Scenario | Peak users | Flows/user | New sessions/sec | Avg duration (s) | Concurrent mappings | Public IPs | Bandwidth (Mbps) |
|---|---|---|---|---|---|---|---|
| Remote workforce edge Mode: pat |
1,200 | 55.0 | 450.0 | 80 | 95,040 | 2 | 5,227.20 |
| Regional ISP segment Mode: cgnat |
35,000 | 35.0 | 12,000.0 | 60 | 2,070,250 | 38 | 51,756.25 |
| Static mapping pool Mode: static |
800 | 0.0 | 0.0 | 0 | 0 | 969 | 0.00 |
Translation concurrency drivers
Capacity planning starts with concurrent translations. The calculator compares two drivers: PeakUsers × FlowsPerUser and NewSessionsPerSecond × AvgDurationSeconds. The larger becomes the baseline, then burst and headroom are applied. Example: 2,000 users × 40 flows equals 80,000 mappings, while 800 sessions/sec × 90 seconds equals 72,000. With 1.25 burst and 25% headroom, target concurrency is 125,000 mappings. This protects against flash crowds, scan storms, and uneven application fan-out patterns today.
Port and address planning
Public address sizing depends on usable ports per address. EffectivePortsPerIP = (65,535 − ReservedPorts) × PortUtilization, capturing allocator efficiency and timer loss. With 1,024 reserved ports and 0.85 utilization, each address yields about 54,834 ports. For 125,000 mappings at one port each, PublicIPs ≈ ceil(125,000 / 54,834) = 3. Raise PortsPerMapping for port blocks, deterministic mapping, or multi-port application behaviors. Conservative utilization reduces collision risk during resets and failovers events.
Throughput and bandwidth sizing
Throughput estimation ties translation state to traffic. BandwidthMbps = ConcurrentMappings × AvgKbpsPerSession ÷ 1,000, producing an aggregate peak figure. Using 125,000 mappings at 40 kbps averages roughly 5,000 Mbps, or 5.0 Gbps. Treat this as a planning ceiling, then validate with application mix, upstream shaping, and encryption overhead. For web-heavy profiles, bursts are common, so set headroom near your 95th percentile. Also confirm per-core packet rates, especially on small appliances first.
Resource overhead assumptions
State tables consume memory and CPU. StateMemoryMB = ConcurrentMappings × MemKBPerMapping ÷ 1,024; at 1.0 KB each, 125,000 mappings require about 122 MB for translation entries. vCPU is estimated linearly from mappings per 100k, then adjusted for logging overhead. With 0.60 vCPU per 100k, the base is 0.75 vCPU; enabling detailed logs at 15% overhead raises it near 0.86. Budget extra for HA sync, counters, and security inspection features.
Operational validation controls
Operational limits often dominate theoretical math. Verify platform caps for maximum translations, connection setup rate, and port allocation behavior. Align timers with policy to avoid orphaned mappings or port starvation. Run staged load tests to confirm drop rates, latency, and log throughput. Track utilization and rebaseline quarterly after demand changes. When feasible, expand IPv6 reach to reduce translation dependency and improve traceability. Document assumptions, then revisit after routing or security control updates.
FAQs
A mapping is one active session entry maintained by the translator, typically a 5‑tuple plus timers. The estimate reflects concurrent entries after burst and headroom, not total daily sessions.
Start between 0.75 and 0.90 for dynamic PAT. Lower it when timers are long, session mix is uneven, or you observe port exhaustion during peaks. Increase only after confirming stable reuse and low collision rates.
If your environment has high churn, short sessions, or automated workloads, the NewSessionsPerSecond × Duration driver can exceed user‑based concurrency. Use flow logs to compute session rate and duration per application class, then compare both drivers.
Yes. Static 1:1 mapping assumes one public address per internal endpoint you must expose. The tool therefore sizes public addresses from peak endpoints, burst, and headroom, instead of dividing by available ports.
They are directional. Memory per mapping and vCPU per 100k mappings vary by platform, features, and logging. Use vendor sizing guides and benchmark tests to tune the coefficients, then keep 15–35% operational headroom.
Monitor translation table occupancy, port usage per public address, session setup rate, and drop counters during peak windows. Confirm latency and log ingestion remain stable. If any metric approaches 80–85% sustained, plan expansion or address policy adjustments.