A software BNG runs on a standard x86 server, but "standard" does not mean "any". The parts that decide whether it forwards at line rate are the NIC, the NUMA layout and how you pin cores. Getting those right matters far more than buying the biggest CPU on the list.
The NIC is the most important choice
For a production data plane the NIC must be supported by a DPDK poll-mode driver. That is the gating requirement; everything else is tuning.
Within the supported set, the card you pick changes what the BNG can do in hardware:
| NIC family | Status | PPPoE / L2TP RSS in hardware |
|---|---|---|
| Intel X710 (i40e) | Solid reference NIC | No, outer-tuple only |
| Intel E810 (ice) + DDP package | Preferred for PPPoE-heavy edges | Yes, hashes PPPoE and L2TPv2 inner sessions |
| Intel 82599 (ixgbe) | Works | No, outer IP/TCP/UDP only |
The distinction matters because NIC RSS on a plain card cannot spread PPPoE frames or the sessions inside one L2TP tunnel across receive queues, so they pin to one core. A software BNG can redistribute that traffic in software (Netavo does), so an X710 is usable; but if you terminate a lot of PPPoE and want the fan-out done in hardware with no dispatcher core spent on it, an E810 with the right DDP package is the card to buy. Match the port speed to your uplink (10/25/40/100G) and make sure the card has multiple queues to spread traffic across.
Cores: count them by role, then isolate them
The data plane does not use cores the way a general application does. Forwarding runs in a tight poll loop, one worker per receive queue, each worker owning one core for as long as the process runs. So you budget cores by role:
- Data-plane workers: one per NIC receive queue you want to drive.
- The dispatcher: on a card that can't hash PPPoE/L2TP, one worker also fans that traffic out to the others; budget for it.
- Control plane and OS: the .NET control plane, routing daemon, management and the kernel need their own cores, kept away from the data path.
Then isolate the data-plane cores so the scheduler never preempts them (isolcpus at boot, plus the BNG's own core map). A worker core that gets descheduled mid-burst drops packets. Past a certain count, clock speed buys you more than extra cores do: per-packet work is largely serial on a worker, so a faster core forwards more than two slower ones.
NUMA: keep the NIC, memory and cores together
On any multi-socket server the single most damaging mistake is spreading the data plane across NUMA nodes. A NIC is attached to one socket's PCIe lanes. If the worker polling that NIC runs on the other socket, every packet and every buffer access crosses the inter-socket interconnect, and throughput collapses.
The NIC, its hugepage memory and the worker cores that drive it must all live on the same NUMA node. On a two-socket box, find which socket the NIC is on and pin the whole data plane there; allocate hugepages on that node. A single-socket server sidesteps the problem entirely, which is why many BNG builds are single-socket.
Memory and hugepages
The data plane maps its packet buffers into hugepages, allocated per NUMA node. A few gigabytes of hugepages is typical, but that memory must be on the right node. The rest of system RAM serves the control plane and OS normally.
Netavo exposes the placement directly in config:
"dataPlane": {
"lcoreMap": "2,3,4,5",
"socketMem": "4096"
}
The core map lists the physical cores the data-plane workers run on (here cores 2–5, which you would have isolated at boot), and socketMem sizes the hugepage allocation per socket. Pin the workers onto cores that sit on the NIC's NUMA node and you have the NUMA rule enforced in one line.
Storage, host and redundancy
The data plane is CPU- and NIC-bound, not disk-bound, so storage is modest: a RAID-1 pair for the OS and logs is plenty. For a constrained site a compact 1U server with a few isolated cores and a 10G NIC does real work; for a larger edge you scale up cores and move to 25/100G, keeping the NUMA discipline. Dual power supplies and out-of-band management (iLO/iDRAC) are worth having for anything you cannot easily visit.
Honest edges
- Don't over-buy cores if the NIC is your limit. If you are driving a single 10G port, a large core count sits idle; spend on clock speed and the right NIC instead.
- Validate NUMA placement after you build. It is easy to get a worker on the wrong node; confirm it rather than assume the BIOS laid things out the way you expected.
- Check the DDP story before relying on hardware PPPoE RSS. An E810 without its DDP package loaded falls back to plain RSS, and the BNG falls back to software spray. Nothing breaks, but you did not get the hardware path you paid for. Confirm it from the startup log.
Size it against real traffic
The free evaluation build is the production build; bring it up on candidate hardware, pin it per the rules above, and measure before you commit a bill of materials. Start at netavobng.com/evaluation; the hardware and deployment guidance is in the manual.