BNGsoft Carrier-Grade NAT  ·  XDP Data Plane

Standalone CGNAT
carrier NAT in the data plane.

Drop-in carrier-grade CGNAT for any network. Line-rate translation at the XDP hook, ~900× less logging than per-flow NAT, and no dedicated appliance — runs on commodity x86 with an Intel 40GbE NIC.

252k+ Concurrent NAT sessions
~3% CPU on a 48-core node at carrier load
~900× Fewer log records vs. per-flow NAT
Zero New hardware — commodity x86 + Intel NIC
The IPv4 Problem

CGNAT is no longer optional — but the options are expensive.

IPv4 exhaustion forces every ISP to deploy CGNAT sooner or later. A single public IP now serves dozens or hundreds of subscribers, with private addresses drawn from RFC 6598 100.64.0.0/10 space. The question is not whether to deploy CGNAT, but how.

Today's options are both painful. Dedicated CGNAT appliances from major vendors cost six figures, lock you into proprietary hardware, and require lead times measured in months. Linux/nftables masquerade is free but runs per-packet through the full kernel netfilter stack — conntrack grows without bound, logging explodes at carrier volume, and symmetric NAT breaks gaming, VoIP, and P2P applications your subscribers depend on.

There is a third way: the same XDP-based CGNAT engine that powers full BNG deployments, packaged as a standalone translator that drops in front of or behind any vendor's BNG or router — no BNG, no PPPoE, no subscriber sessions required.

"A private range, a public pool, and a port-block size — that is the entire configuration. Everything else is automatic."

Why the status quo fails
1

Appliance CapEx & lock-in

Purpose-built CGNAT hardware costs six figures upfront. Vendor lock-in makes upgrades painful and capacity scaling slow.

2

Linux/nftables at carrier scale

Per-flow conntrack runs in the kernel netfilter path on every packet. Spinlock contention degrades under high session rates. CPU climbs steeply with subscriber count.

3

Log record explosion

Per-flow NAT logging at CGNAT volume generates millions of records per hour. Storage and SIEM costs scale with subscriber base.

4

Symmetric NAT breaks apps

nftables masquerade produces symmetric NAT. Full-cone-dependent applications — online gaming, VoIP, some P2P — break or degrade significantly.

How It Works

Translation at the driver — before the kernel stack sees a single packet.

Configure a private CGNAT range (e.g. 100.64.0.0/10 or 100.100.100.0/24), a public IP pool (e.g. 203.232.123.0/27), a port-block size, and a NAT type. The engine auto-populates its translation tables from the private range — any traffic arriving from that range is translated at line rate in XDP before entering the kernel.

Approach A Linux nftables NAT

NIC Driver (kernel)

Packet arrives, DMA to kernel memory

Netfilter / iptables hooks

PREROUTING → FORWARD → POSTROUTING chain traversal

nf_conntrack lookup

Per-flow entry allocation, spinlock contention under load

masquerade / SNAT

Symmetric NAT — new external port per flow, no determinism

Kernel routing → egress

Full stack traversal before the packet leaves the host

High per-packet CPU  ·  Symmetric NAT  ·  Per-flow logging
Approach B BNGSOFT XDP CGNAT

NIC Driver (Intel 40GbE)

Packet arrives via DMA

XDP CGNAT hook

Runs at driver level — kernel stack is never entered

BPF-managed NAT table

Port-block lookup in BPF map — no per-flow conntrack, no spinlocks

Port-block SNAT (full-cone)

Deterministic block assigned per private IP — endpoint-independent mapping

XDP_TX / XDP_REDIRECT

Packet forwarded at line rate — no kernel stack traversal

~3% CPU  ·  Full-cone NAT  ·  ~900× less logging
cgnat-only.conf  —  complete configuration
Private network (RFC 6598 space)
private_range100.100.100.0/24
Public IP pool
public_pool203.232.123.0/27
NAT behaviour
port_range1024–65535
block_size512
nat_typefull-cone
hairpinenabled
algenabled

Result — auto-populated at startup
private_ips_capacity131,072 addresses
port_blocks_pool31,248 blocks
session_table_capacity8.4 million sessions

No BNG, no PPPoE/IPoE, no subscriber sessions, no external sync daemon. The standalone CGNAT translator operates independently in front of or behind any vendor's BNG, router, or edge device.

Performance Comparison

Five metrics. One clear winner.

XDP CGNAT figures are from a live production node; the ~23% kernel-path CPU is our own measured pre-XDP baseline. The remaining Linux/nftables bars are qualitative — relative ordering from well-understood architectural characteristics, not a controlled benchmark.

Per-packet CPU overhead
Linux nftables NAT ~23% (kernel path)
XDP CGNAT ~3% CPU (48-core, carrier load)
~3%

Moving NAT into XDP cut CPU from ~23% to ~2.5% on comparable nodes. Per-packet translation overhead is measured in nanoseconds.

Log records generated
Linux nftables (per-flow) 1 record per flow (illustrative)
XDP CGNAT (port-block) ~900× fewer — 1 log per port block
<1%

314 million sessions produced only ~347,000 port-block allocation log records — ~900× reduction in log volume while preserving lawful-intercept compliance.

Max concurrent sessions (capacity)
Linux nftables (conntrack) Kernel conntrack limited (illustrative)
XDP CGNAT 8.4 million sessions
8,400,000 sessions

8.4 million session-table capacity per node; 131,072 private-IP capacity. Scale horizontally for larger deployments.

Forwarding latency added
Linux nftables NAT Full kernel stack traversal (illustrative)
XDP CGNAT Line rate — nanoseconds per packet
ns

XDP processes packets before the kernel network stack — no socket buffers, no iptables traversal, no scheduling overhead.

NAT behaviour — application compatibility
Linux nftables Symmetric NAT — breaks full-cone-dependent apps (gaming, VoIP, P2P)
XDP CGNAT Full-cone (endpoint-independent) NAT — gaming, VoIP, and P2P work correctly

nftables masquerade allocates a new external port per flow with no endpoint-independent mapping guarantee. The XDP CGNAT engine provides deterministic port-block assignment and supports endpoint-independent filtering, enabling full-cone behaviour that carrier subscribers expect.

Capability Comparison

Capability matrix: nftables NAT vs. CGNAT-only (XDP).

nftables masquerade is a solid solution for SOHO and edge NAT — it was not designed for carrier CGNAT at scale. The table below reflects well-established architectural characteristics of each approach.

Capability Linux nftables NAT CGNAT-only (XDP)
Data path Kernel netfilter — full stack traversal per packet (PREROUTING, FORWARD, POSTROUTING) XDP hook at driver level — kernel stack bypassed entirely for translated traffic
Per-packet CPU High — scales with packet rate; netfilter overhead plus conntrack lock contention at carrier volume ~3% on a 48-core node at carrier load; per-packet overhead in nanoseconds; XDP cut CPU from ~23% to ~2.5% on comparable nodes
Session scale Kernel conntrack table; contention and memory pressure at millions of flows 8.4 million session-table capacity; 131,072 private-IP capacity per node; 252,000+ concurrent sessions demonstrated in production
NAT behaviour Symmetric  masquerade allocates a new external port per flow; no endpoint-independent mapping — breaks gaming, VoIP, P2P Full-cone  endpoint-independent mapping (RFC 4787 compliant); deterministic port-block per private IP — carrier-grade app compatibility
Logging One log record per connection/flow — generates millions of records/hour at carrier scale; high storage and SIEM cost ~900× fewer records: 314 million sessions → ~347,000 port-block allocation logs; block↔subscriber mapping satisfies lawful-intercept/data-retention requirements
Port allocation Dynamic per-flow; no determinism; difficult subscriber attribution without per-flow logs Deterministic port-block allocation (~1.1 blocks per private IP; 31,248-block pool at ~8% utilisation); subscriber attributable from block alone
ALG support Via kernel nf_nat helpers (FTP, SIP, H.323 etc.) Built-in ALG — FTP, SIP, and related protocols handled in XDP path
Hairpin NAT Supported via hairpin masquerade rules Native hairpin — subscribers reach each other via the public IP without leaving the CGNAT node
Hardware / appliance Runs on any Linux x86 server; no special NIC required for basic operation Commodity x86 + Intel 40GbE NIC — no new hardware required; replaces a dedicated CGNAT appliance at a fraction of the cost
Drop-in compatibility Runs inline on existing Linux server; integration with existing routing varies Standalone translator — inserts in front of or behind any vendor's BNG, router, or edge device; no BNG, PPPoE, or subscriber sessions required
Configuration nftables ruleset; conntrack helper modules; per-rule logging configuration Private range + public pool + port range + block size + NAT type — tables auto-populated at startup from the configured private range
The Logging Win

314 million sessions. ~347,000 log records.

Port-block allocation logging is not a compromise on compliance — it is a smarter model. Each port block maps deterministically to one private IP address and a precise allocation timestamp, providing everything lawful-intercept and data-retention regulations require at a fraction of the storage cost.

~900×

314 million sessions logged as only ~347,000 port-block allocation records — roughly 900× fewer log entries than per-connection NAT logging, with no loss of subscriber attribution capability. The port block encodes the private IP, the public IP:port-range, and the allocation timestamp in a single compact record.

314M Sessions handled (lifetime production node)
~347k Port-block allocation log records generated
~108 Sessions per private IP; ~1.1 port-blocks per private IP

Per-flow NAT logging at CGNAT volume can produce tens of millions of records per day per node. Port-block allocation logging generates the same subscriber-attribution information in a table that is roughly 900× smaller — dramatically reducing storage, SIEM ingest costs, and log retention infrastructure.

What You Get

Carrier-grade CGNAT — without the carrier price tag.

The standalone CGNAT translator packages the full XDP NAT engine as a self-contained drop-in box. Every capability is production-proven on live networks.

IPv4 Conservation

100+ private IPs share a single public IP. ~108 sessions per private IP, ~1.1 port-blocks per private IP — efficient utilisation of your public address pool.

Full-Cone NAT

Endpoint-independent mapping (RFC 4787). Gaming consoles, VoIP SIP clients, and P2P applications work correctly — no broken matchmaking, no one-way audio.

Deterministic Port Blocks

Each private IP receives a deterministically assigned port block. Subscriber attribution for any logged connection requires only the port block record — no per-flow logging needed.

ALG + Hairpin

Application-layer gateway handles FTP, SIP, H.323, and related protocols. Hairpin NAT lets subscribers reach each other via the shared public IP without leaving the CGNAT node.

Drop-in, Any Vendor

Operates in front of or behind any BNG, router, or edge device. No integration required beyond configuring the private range and public pool — completely vendor-agnostic.

Commodity Hardware

Runs on standard x86 servers with an Intel 40GbE NIC — the same hardware already in your network. No proprietary CGNAT appliance, no vendor lock-in, no six-figure CapEx.

Production Evidence

Production-proven numbers — same engine, same XDP core.

The figures below are from an anonymised production CGNAT engine on live carrier infrastructure, June 2026. The standalone box runs the identical XDP engine.

Production CGNAT engine — live, June 2026
Concurrent Sessions 252k+

Active NAT sessions

Concurrent sessions in production at carrier subscriber load.

Session Table Capacity 8.4M

Maximum session capacity

Total session-table capacity per node — current utilisation is ~3% of maximum.

Private IP Capacity 131k

Private IPs per node

131,072 private-IP address capacity per standalone CGNAT node.

Lifetime Sessions 314M

Sessions handled

314 million NAT sessions processed over the engine's lifetime on this production node.

Packets Translated 1.7B

1.7 billion packets

Packets translated by the XDP engine in production — zero kernel-stack traversal.

CPU Utilisation ~3%

CPU at carrier load

~3% CPU on a 48-core node at carrier load; XDP cut CPU from ~23% to ~2.5% vs. kernel-path NAT on comparable nodes.

Port-block pool: 31,248 blocks at ~8% utilisation

~1.1 port blocks per private IP; ~108 concurrent sessions per private IP. The port-block model keeps the translation table compact while supporting high per-subscriber session counts — deterministic, auditable, and compliant.

Business Value

Extend IPv4 life. Eliminate appliance CapEx. Shrink your log estate.

A commodity x86 server running BNGSOFT XDP CGNAT delivers carrier-grade address sharing, full-cone NAT, and port-block logging — replacing proprietary appliances and reducing operational costs across the board.

IPv4 Strategy

Defer IPv4 address purchases

100+ private IPs per public IP extends your existing address pool substantially, deferring costly IPv4 address acquisitions and giving time for IPv6 transition at a sustainable pace.

CapEx Reduction

Replace a dedicated CGNAT appliance

A standalone CGNAT box built on commodity x86 hardware eliminates six-figure CGNAT appliance costs and vendor lock-in. Use hardware you already own or procure at commodity prices.

OpEx Reduction

~900× less log infrastructure

Port-block logging replaces per-flow logging. 314 million sessions produced only ~347,000 log records — dramatically reducing storage, SIEM ingest volumes, and log retention infrastructure costs.

Performance

Carrier scale at line-rate latency

~3% CPU at carrier load on a 48-core node. XDP processes packets in nanoseconds before the kernel stack — no bottleneck as subscriber count grows, no conntrack spinlock contention.

Subscriber Experience

Full-cone NAT — apps just work

Endpoint-independent NAT eliminates symmetric-NAT app breakage. Gaming, VoIP, and P2P applications work correctly, reducing support tickets and subscriber churn from CGNAT-related issues.

Vendor Freedom

Zero vendor lock-in

The standalone CGNAT box inserts in front of any existing BNG, router, or edge device from any vendor. No forklift upgrade, no proprietary integration, no renegotiated contracts.

Get Started

Ready to add carrier-grade CGNAT to your network?

Talk to BNGSOFT about a standalone CGNAT deployment. We'll walk through your network topology, address pool, and subscriber scale — and have you running a proof of concept on your own hardware.

Commodity x86 + Intel 40GbE
Drop-in beside any vendor BNG or router
8.4M session capacity per node
Full-cone NAT — RFC 4787
Lawful-intercept compliant logging
BNGSOFT — XDP Carrier-Grade NAT Figures from a live production CGNAT engine, June 2026. Linux/nftables NAT qualitative bars are illustrative. All trademarks are property of their respective owners.