"How many subscribers can it handle?" is the first question every operator asks about a software BNG. The useful answer names the conditions. On the hardware we publish figures for, Netavo reaches interface line rate at IMIX with CGNAT and QoS enabled: up to 200 Gbps and 131 Mpps per server on a 32-core box with 2x100G, and line rate on the 8-core and 16-core classes as well (the performance page has the full table and the method). What follows is what sits behind those figures, the dimensions that actually bound a BNG, so you can size for your own traffic with the same confidence.
Scale is four numbers, not one
A BNG is bounded in four different ways at once, and which one bites first depends entirely on your traffic:
- Throughput: bits and packets per second. The packet rate matters more to the data plane than the advertised bit rate. A link full of small packets is far harder than the same bit rate in large ones, because the cost is largely per-packet.
- Session count: how many concurrent subscribers. This is bounded by memory (each session holds state in shared memory) and by the control plane's ability to track them.
- Session setup rate: connects per second. This rarely shows up in normal operation.
- CGNAT state: if you run carrier NAT, the binding and port-block tables are their own capacity dimension.
A box can be comfortable on three of these and fall over on the fourth. Sizing means finding which one is your limit.
What moves the number
The same hardware delivers wildly different figures depending on the feature mix each packet traverses:
- Packet-size distribution. Small-packet (worst-case) rates can be several times harder than a real-world mix. Know which you are quoting.
- Access model. PPPoE carries encapsulation overhead and, on a plain NIC, needs software fan-out across cores; IPoE does not. (See the notes on PPPoE vs IPoE and on NIC RSS.)
- CGNAT. NAT adds per-packet work and state. On or off is a real difference.
- Shaping and QoS. Per-subscriber rate enforcement costs cycles per packet.
- Tunnelled / encrypted paths. L2TP into an LNS, and especially IPsec, change the picture. Encrypted traffic that has to be punted to the kernel is a different cost class from plain forwarding.
- Cores, clock and NUMA. More worker cores help until the NIC or a shared resource is the limit; clock speed helps per-packet latency; a NUMA misplacement can halve everything. (See the server-hardware note.)
Change any of these and the "subscribers per box" figure moves, which is exactly why a figure quoted without them is not useful.
The moment that actually tests a BNG
Steady state is the easy case. The hard moment is a flap storm: an upstream link blips, every subscriber drops, and then all of them try to reconnect in the same few seconds. Now the limit shifts from forwarding throughput to session setup rate, the capacity of your RADIUS to answer a flood of Access-Requests, and the data plane installing all those sessions at once.
A BNG that forwards a terabit comfortably can still take minutes to bring a large subscriber base back after a mass disconnect if the setup path is the bottleneck. Design and test for the reconnect storm, not just the steady load. It is the scenario that decides how an outage feels to your customers.
What we publish, and how we measure it
Netavo publishes per-server throughput figures with the conditions stated and the method reproducible, on the performance page: interface line rate at IMIX across the entry (8-core / 2x10G), mid (16-core / 2x25G) and high (32-core / 2x100G) classes, up to 200 Gbps and 131 Mpps per server, with CGNAT and QoS on. Every figure names its packet size and feature set, because a throughput number without them cannot be compared.
Two measurements stand behind those claims:
- A per-commit pipeline microbenchmark. Every change records the per-packet cost of the forwarding pipeline, tens of nanoseconds per packet, so a regression that makes each packet a little more expensive is caught before it ships. This is the cost that sets throughput.
- A subscriber-and-traffic generator in the lab. We bring real PPPoE and IPoE sessions up against the box, drive traffic through them, and exercise the awkward cases such as mass reconnect, CGNAT under load and mixed packet sizes.
The benchmark ships in the evaluation build, so the published numbers are claims you can reproduce on your own hardware, not ones you have to take on trust.
The real limits, named plainly
When you push a software BNG until something gives, it is usually one of these:
- NIC packet rate at small packet sizes: the card cannot receive faster.
- A single worker core's per-packet budget: if traffic can't spread across cores (PPPoE on a plain NIC without spray, or one busy L2TP tunnel), one core caps the lot.
- Memory for concurrent session and NAT state.
- RADIUS and the setup path during a reconnect storm.
These limits do not mean the software is slow. A well-built software data plane on the right NIC forwards at line rate. Hardware packet rate, core affinity, memory and the control-plane round-trips are constraints you can plan for.
We put the packet size on every figure we publish. For calibration, the most prominent per-server claim in this market, one terabit, was produced at 1,024-byte packets; at a realistic IMIX mix that is a very different number. Ask any vendor, us included, for the packet size and the small-packet rate behind the headline.
See the figures, then reproduce them
The performance page has the published per-class figures and the exact benchmark protocol. The free evaluation build is the full production build, licensed for up to 50 concurrent subscribers, so you can run that same benchmark on your own hardware and confirm the numbers before you commit. Start at netavobng.com/evaluation; the methodology and design documents are in the manual.