Replace your legacy Carrier-Grade NAT box with BNGSOFT's XDP CGNAT engine: deploy beside the old appliance, canary a slice of subscribers, shift pools gradually, decommission. No maintenance window. No disconnects. No forklift.
Purpose-built CGNAT appliances delivered the session scale ISPs needed when XDP-class software was not yet an option. Today the calculus has flipped: CapEx refresh cycles hit every three to five years, capacity ceilings are hard-baked into silicon, and every firmware upgrade requires a scheduled maintenance window that disconnects subscribers.
The operational cost is compounding. Appliance vendors charge for throughput tiers, session licences, and feature modules separately. Lawful-intercept log estates grow without bound because the box logs every flow. And when a box reaches end-of-life, the replacement requires re-engineering the traffic path — another flag day.
BNGSOFT's XDP CGNAT runs on commodity x86 with an Intel 40GbE NIC. Because the NAT program lives in the kernel as a pinned eBPF program, software upgrades keep sessions and NAT state alive — future upgrades are not outages. The migration itself is a gradual shift of subscriber IP pools, not a cutover event.
"The replacement BNG passed traffic as soon as the old appliance's pools were withdrawn — subscribers never noticed the swap."
Purpose-built CGNAT silicon hits end-of-life on a vendor schedule, not yours. Each refresh is a six-figure purchase and a project.
Appliance capacity is licensed or silicon-bound. Exceeding it means either dropping sessions or buying the next appliance tier ahead of schedule.
Firmware updates and capacity expansions require planned downtime. Subscribers are disconnected and reconnected, driving support call volume and churn.
Per-flow logging at carrier scale generates millions of records per hour per node. Storage, SIEM ingest, and retention infrastructure costs scale with subscriber growth.
Each phase is independently reversible. If anything looks wrong at any point, withdraw the BNGSOFT pool and all affected subscribers fall back to the appliance path in seconds — with no session disruption to unaffected subscribers.
Single vendor box carries entire public IP pool
Each upgrade requires a maintenance window and subscriber disconnects
Millions of log entries per hour; petabyte retention estates
Next refresh = another six-figure project on the vendor's timeline
BNGSOFT node joins network; old appliance continues unaffected
Assign one small public IP subnet to BNGSOFT; validate with real traffic
Move public IP pools subnet-by-subnet; appliance pool shrinks at each step
Old box powered down; BNGSOFT carries full pool; upgrades are now zero-downtime
BNGSOFT's XDP programs are attached via pinned bpf_link — the kernel continues running the program even if the daemon restarts or is upgraded. NAT state lives in BPF maps in kernel memory, not in the daemon process. This is what makes zero-downtime upgrades structurally guaranteed, not a configuration promise.
Capabilities below are from a live production XDP CGNAT engine, June 2026. Appliance characteristics reflect well-established architectural properties of dedicated CGN hardware.
Endpoint-independent mapping means subscribers' gaming consoles, SIP phones, and P2P clients behave correctly. No more support tickets about broken matchmaking or one-way audio after CGNAT migration.
314 million sessions → ~347,000 port-block allocation records. Each record maps a subscriber's private IP to a public IP:port-range with a timestamp — everything lawful-intercept regulations require, at a fraction of the storage cost.
XDP processes packets before the kernel stack — no conntrack spinlocks, no netfilter chain traversal. The same commodity x86 box that replaces your appliance has headroom for growth.
Current production load is ~3% of table capacity. The same node can absorb significant subscriber growth without any hardware change — scale horizontally by adding nodes, not by buying appliance tiers.
A single port-block record provides everything required for subscriber attribution under data-retention regulations. No per-flow log is needed to answer "who was using public IP 203.x.x.x port 54321 at 14:32 UTC?"
The migration is designed so the risk envelope never expands beyond the subnets already shifted. At any moment, the old appliance is the rollback target — already running, already routing.
| Risk Factor | Traditional Forklift Swap | BNGSOFT Phased Migration |
|---|---|---|
| Subscriber impact | All subscribers disconnected during cutover window; reconnect load spike on RADIUS/DHCP | Zero disconnects at any phase. Subscribers whose pool has not yet migrated are unaffected throughout |
| Rollback | Requires reversing the entire cutover — another maintenance window, another outage | Instant rollback per subnet: readvertise the subnet from the appliance; new connections return to the old path in seconds |
| Canary validation | Not possible — the entire subscriber base moves at once | Start with one small public IP subnet and a handful of subscribers; validate logging, app compatibility, and performance before proceeding |
| Upgrade risk post-migration | Every appliance firmware upgrade requires another maintenance window | Future upgrades are zero-downtime: pinned bpf_link + BPF-map NAT state survives daemon restart — sessions stay alive through software updates |
| NAT state during cutover | All existing NAT sessions terminated; subscribers must re-establish connections | Subscribers not yet migrated retain existing NAT sessions on appliance; migrated subscribers start fresh sessions on XDP path with no disruption |
| Hardware risk | New appliance must be fully validated before go-live — no production traffic until cutover | Commodity x86 hardware validated with real production traffic during canary phase, weeks before full migration |
| IPv4 pool continuity | Same public IPs reused — existing subscriber session state lost mid-block | Public IP subnets move one block at a time; deterministic port-block assignment preserves attribution continuity across the migration |
Port-block allocation logging is not a compliance compromise — it is a structurally better model. Each block maps deterministically to one private IP address with a timestamp, providing everything lawful-intercept and data-retention regulations require at a fraction of the storage cost of per-flow NAT logs.
314 million sessions produced only ~347,000 port-block allocation records on a live production node — roughly 900× fewer log entries than per-connection NAT logging, with no loss of subscriber attribution capability. The same migration that eliminates your appliance CapEx also eliminates most of your log infrastructure OpEx.
When you decommission the appliance, you also decommission the per-flow log pipeline. The port-block model cuts SIEM ingest, log storage, and retention infrastructure costs at the same time as the CapEx saving — the migration pays for itself faster than the typical appliance ROI model assumes.
Every capability below is production-proven on live carrier infrastructure. The migration path is designed around your operational constraints, not ours.
Pinned eBPF programs and in-kernel BPF-map NAT state survive daemon restarts. Subscribers stay connected through upgrades — structurally guaranteed, not a configuration promise.
Each migrated subnet can be returned to the old appliance independently, in seconds, without touching any other subscribers. The old box is always the ready rollback target.
Endpoint-independent mapping from day one of migration. Gaming consoles, VoIP clients, and P2P applications that may have struggled on the appliance work correctly on XDP CGNAT.
Port-block allocation logging replaces per-flow logs. 314 million sessions produced only ~347,000 records — eliminating most of the log storage and SIEM ingest costs that scaled with the appliance.
BNGSOFT operates in front of or behind any existing BNG, router, or edge device. No BNG, no PPPoE, no subscriber sessions required. Completely vendor-agnostic insertion.
Runs on standard x86 with an Intel 40GbE NIC — hardware already available in your network or procured at commodity prices. 8.4 million session capacity per node with room to grow horizontally.
The figures below are from an anonymised production XDP CGNAT engine running live carrier traffic, June 2026. The migration target is identical hardware running the identical engine.
Concurrent sessions in production at carrier subscriber load — ~3% of the 8.4M table capacity.
8.4 million session-table capacity per commodity x86 node. Scale horizontally for larger deployments.
~3% CPU at carrier load. XDP cut CPU from ~23% to ~2.5% vs. kernel-path NAT on comparable nodes.
314 million lifetime sessions produced only ~347,000 port-block allocation records — full lawful-intercept traceability preserved.
131,072 private-IP address capacity per node. ~1.1 port blocks per private IP; ~108 sessions per private IP.
Deterministic port-block assignment and endpoint-independent filtering — carrier-grade app compatibility from day one.
Eliminating the appliance removes CapEx, OpEx, and operational risk at the same time. The phased migration means benefits accrue immediately — you do not wait for decommission day to see the savings.
Commodity x86 hardware replaces the six-figure appliance. Future capacity increases are software-defined and horizontal — add a node, not an appliance tier.
Port-block logging replaces per-flow logging as soon as each subnet migrates. Storage, SIEM ingest, and retention infrastructure costs shrink proportionally, progressively throughout the migration.
The last maintenance window your team plans for CGNAT is the one that never happens. Once on BNGSOFT, future upgrades are software deploys — pinned eBPF programs keep sessions alive.
Full-cone NAT (RFC 4787) eliminates symmetric-NAT app breakage that many appliances introduce. Gaming, VoIP, and P2P work correctly — reducing support tickets from the migration itself.
The same efficient address sharing your appliance provides, at higher session density. ~108 sessions per private IP, ~1.1 port blocks per private IP — conserve your public address pool for longer.
BNGSOFT inserts in front of any existing BNG, router, or edge device from any vendor. Replacing your appliance does not require replacing anything else in your stack.
Talk to BNGSOFT about a phased migration plan for your network. We will walk through your topology, subscriber count, public IP pools, and appliance vendor — and size a proof-of-concept deployment you can validate with real traffic before committing to a single subnet migration.