Performance · method and figures
Up to 200 Gbps per box, with the features on.
Figures you can reproduce, not round up. Headline benchmarks in this market are usually run at large packet sizes, with subscriber features disabled, and with little method disclosed. Netavo states its method, quotes figures at IMIX with QoS and CGNAT enabled, and ships the same build so you can reproduce them on your own hardware.
Stated basis. Every figure carries the CPU, NIC, traffic profile and session count it was produced under, and whether it is a rig measurement or derived from the per-packet benchmark. No headline figure without its basis beside it.
IMIX beside every large-packet figure. A 1500-byte result on its own overstates real-world capacity. Both figures, bidirectional.
Features on. Headline figures assume QoS and CGNAT enabled at full session scale, the configuration you would operate. Bare forwarding appears only as a secondary line.
Reproducible. The same per-commit benchmark that produces these figures is in the evaluation build. Run it on your own hardware and check them.
For calibration: the most prominent per-server throughput claim in this market — one terabit — was produced at 1,024-byte packets in a co-branded laboratory test. Results of that kind are standard industry practice, and they are why operators discount vendor benchmarks.
We would rather publish a figure you can reproduce than a larger one you cannot. Every figure in the table below states its basis and meets rules R1–R4.
| Reference hardware | Subscribers | Throughput, both ways | Packet rate at IMIX | QoS + CGNAT | Data-plane cores |
|---|---|---|---|---|---|
| entry · 8-core / 2×10G | 5,000 | line rate — 20 Gbps | 13 Mpps | enabled | ~1 fwd · ~3 with CGNAT |
| mid · 16-core / 2×25G | 25,000 | line rate — 50 Gbps | 33 Mpps | enabled | ~3 fwd · ~6 with CGNAT |
| high · 32-core / 2×100G | 100,000 | line rate — 200 Gbps | 131 Mpps | enabled | ~9 fwd · ~24 with CGNAT |
IMIX and 1500-byte traffic both reach interface line rate on every configuration above: the per-packet pipeline cost leaves packet-rate headroom at IMIX, so the interface is the limit, not the CPU. Core counts are derived from the per-commit x86-64 pipeline benchmark — 31–55 ns/packet for forwarding and 46–178 ns/packet for CGNAT under 50k-session and 1M-flow working sets — at IMIX line-rate packet rates (≈362-byte average frame), with margin for NIC and driver overhead; CGNAT figures assume every subscriber translated. Reproduce them with the benchmark in the evaluation build. Want your hardware class represented? Tell us what you run.
The same counters the benchmark protocol records — visible live on any deployment, including the evaluation build.
Platform · Hardware support
Runs on the servers you already buy.
Netavo BNG deploys on standard x86-64 servers — Intel Xeon or AMD EPYC — with two packet I/O paths: a DPDK path for full performance on validated network adapters, and a compatibility path that runs on virtually any adapter, including virtual machines. Same software, same configuration, either path.
The appliance reports its own inventory — CPU, memory, NICs and the active data-plane I/O path.
Performance path — DPDK
Kernel-bypass poll-mode I/O on validated adapters, with dedicated data-plane cores and hugepage memory. The path for production deployments at 10G and above.
Validated NICs · IOMMU/VT-d · hugepages
Compatibility path — AF_XDP
High-performance kernel I/O on virtually any adapter, with zero-copy operation on supported families. The path for labs, evaluations, small sites and VM roles — no special BIOS configuration required.
Any standard server NIC · zero-copy on supported families
The appliance reports its own inventory — CPU, memory, adapters and the active I/O path.
Any modern x86-64 processor. Production deployments run on server platforms — Intel Xeon or AMD EPYC — where ECC memory, PCIe lane count and NIC options fit the role. There is no per-core licensing, so core count is purely an engineering choice.
Desktop-class processors (Intel Core, AMD Ryzen) run the software identically and are well suited to labs, evaluations and small sites; for production we recommend server platforms for ECC and platform reliability rather than for any software requirement.
Data-plane workers scale with cores: sizing guidance ships with the benchmark protocol, including a per-core scaling curve so unlisted hardware can be sized by calculation rather than guesswork.
| Performance path | Compatibility path | |
|---|---|---|
| CPU | x86-64 · 8+ cores recommended | x86-64 · 4+ cores |
| Memory | 32 GB+ · hugepages reserved | 8–16 GB · hugepages optional |
| Firmware | VT-d / IOMMU enabled | standard settings |
| Storage | SSD · 100 GB+ | SSD · 50 GB+ |
| Adapter family | Path | Notes |
|---|---|---|
| Intel 700 series (X710 / XL710) | DPDK — performance | 10G / 40G · the validated production path, in service on our own network |
| Intel 800 series (E810) | DPDK or AF_XDP zero-copy | 25G / 100G · on DPDK with Intel's DDP package, PPPoE and L2TP are hashed in hardware |
| Intel 500 series (X520/X550) | AF_XDP zero-copy | 10G · widely available second-hand, well suited to evaluations |
| NVIDIA ConnectX (mlx5) | AF_XDP zero-copy | 25G+ |
| Commodity adapters (1G/2.5G) | AF_XDP copy mode | labs and small sites · no special configuration |
| virtio (virtual machine) | AF_XDP | VM deployments — see below |
The validated-hardware list is published with each release and grows with the benchmark programme; deployment telemetry (aggregate hardware inventory only) tells us which platforms to validate next.
Smaller roles run as a virtual machine on the compatibility path — the L2TP LNS role is fully supported on a plain VM, reusing the complete control plane with no separate build. Evaluations and labs commonly start this way before moving to bare metal.
Bare metal on the DPDK path remains the recommendation wherever headline throughput matters: the performance page's benchmark protocol applies to bare metal, and published figures will state the platform explicitly.
A production LNS role on a virtual machine — identical software and configuration to bare metal.
From our engineering notes
How far does a software BNG scale? Sessions, throughput and the real limits
Netavo reaches interface line rate at IMIX on commodity x86. What actually bounds a software BNG, and the numbers behind the claim.
ReadDPDK, AF_XDP or the kernel: data-plane choices for a software BNG
How packets get from the NIC to the forwarding code decides a software BNG's throughput. Here are the three approaches, what each costs, and when to use them.
ReadWhat is a vBNG? Virtual BNG, software BNG and CUPS compared
A vBNG runs the broadband network gateway as software on x86, often in a VM. Here is what the term covers, how it differs from CUPS, and when a VM is the right home.
ReadWhy PPPoE throughput pins to one CPU core, and how the BNG spreads it
NIC RSS can't see inside PPPoE or a single L2TP tunnel, so every session lands on one core. Here's the software-spray dispatch that fixes it, and the hardware path that avoids it.
ReadSpecifying a server for a software BNG: NICs, NUMA and core pinning
The NIC, the NUMA layout and how you pin cores matter more than headline core count. A practical guide to sizing a box for subscriber termination.
ReadBenchmark it on your own hardware.
The evaluation build is the production build. Deploy it on your own x86 hardware, drive it with your traffic generator, and compare your results with ours.