"vBNG" appears in tenders, analyst reports and vendor datasheets, and it rarely means quite the same thing twice. Sometimes it means a BNG in a virtual machine. Sometimes it means any BNG that is software rather than a chassis. Sometimes it is used for a disaggregated BNG with the control plane in a data centre. Those are different architectures with different costs and failure modes, so it is worth separating them before comparing products.
What a BNG does
A BNG (broadband network gateway) is the router at the edge of a broadband network where subscribers are terminated. It brings up each subscriber's session, whether PPPoE, IPoE or an L2TP session handed over by a wholesale provider; authenticates it against RADIUS; assigns addresses; enforces the subscriber's speed and policy; sends accounting; and routes the traffic onward, often through CGNAT. Traditionally that function lived in a dedicated chassis with line cards, such as an ASR 9000, a 7750 or an MX.
What "vBNG" means
A vBNG (virtual BNG) is the same subscriber-termination function delivered as software running on general-purpose x86 servers instead of a vendor chassis. Within that, three deployment models get the label:
| Model | What runs where | Main attraction | Main cost |
|---|---|---|---|
| Software BNG on bare metal | The BNG owns a whole x86 server and its NICs | Highest throughput on commodity hardware | A dedicated box per BNG |
| BNG in a virtual machine | The BNG runs as a VM on a shared hypervisor | Uses existing virtualisation estate; quick to stand up | The hypervisor sits in the packet path |
| Disaggregated BNG (CUPS) | Control plane centrally, user planes near the access | Shared control capacity across many sites | A distributed system with its own interfaces and failure modes |
All three replace proprietary hardware with software, which is where most of the commercial interest comes from: capacity becomes a server purchase rather than a line-card purchase, and the operator chooses the hardware. They differ in how much performance they get from that hardware and in how much operational complexity they add.
Bare metal or a VM: the data path decides
A BNG forwards every subscriber packet, so the question that matters is how packets get from the NIC to the forwarding code. On bare metal a software BNG can use kernel-bypass I/O such as DPDK, with dedicated cores polling a validated NIC. In a VM, the packets also have to cross the hypervisor's virtual networking, and the guest typically sees a virtual adapter such as virtio.
Netavo BNG has two packet I/O paths and the same software and configuration on both:
- The performance path (DPDK) runs on bare metal with validated adapters, dedicated data-plane cores, hugepages and IOMMU enabled. It is the path for production deployments at 10G and above.
- The compatibility path (AF_XDP) runs on virtually any adapter, including a VM's virtio, with no hugepages, IOMMU or special BIOS settings required. It is the path for labs, evaluations, small sites and VM roles.
That gives a practical answer to "is Netavo a vBNG?". It is a software BNG that runs on bare metal for line-rate roles and runs as a virtual machine for smaller ones. The L2TP LNS role is fully supported on a plain VM, reusing the complete control plane with no separate build, and evaluations and smaller fixed-wireless or ISP sites commonly start on a VM. Moving from the compatibility path to the performance path is a configuration and hardware step, not a product migration or a new licence.
We do not publish throughput figures for VM deployments. Our benchmark protocol applies to bare metal, and published figures state the platform explicitly; until a configuration appears with measured results, we make no throughput claim for it. If headline throughput matters, plan on bare metal. The trade-offs between the I/O paths are covered in DPDK, AF_XDP or the kernel.
A virtual BNG is not the same as CUPS
The most common confusion is between a vBNG and a disaggregated BNG using control and user plane separation (CUPS). Running a BNG in a VM changes where the software runs. CUPS changes how the BNG is built: the control plane and the user planes are deployed independently, possibly at different sites, and talk over a defined interface. The Broadband Forum's TR-459 family addresses that architecture.
A vBNG can be a complete appliance in a VM, with no CUPS involved, and a CUPS user plane can run on bare metal. Netavo runs its control plane and data plane as separate processes on one appliance, sharing memory. It is not a disaggregated BNG or CUPS product and does not implement TR-459. Whether splitting the planes pays off is a separate decision, worked through in disaggregated BNG and CUPS.
What to check before you put a BNG in a VM
- Packet rate, not bandwidth. Small packets cost the hypervisor and the guest as much per packet as large ones. Test with a realistic packet mix, not a single large-packet stream.
- Core spreading for PPPoE and L2TP. NIC receive-side scaling does not see inside PPPoE or a single L2TP tunnel, and a virtual NIC is no better. Confirm the BNG redistributes that traffic across cores in software, as Netavo does, or one vCPU saturates while the rest idle. See why PPPoE throughput pins to one CPU core.
- What the VM shares. A BNG on an oversubscribed host competes with its neighbours for CPU and the virtual switch. Size and pin it as you would any latency-sensitive workload.
- Failure behaviour. A hypervisor migration or host failure is a BNG failure as far as subscribers are concerned. Decide what survives which failure, as you would for a physical box; the options are in BNG high availability.
Choosing
- Use a VM for an LNS handling smaller wholesale hand-offs, a small or fixed-wireless site, a lab, or an evaluation, especially where you already run a virtualisation estate.
- Use bare metal for the main subscriber edge wherever throughput matters, on the DPDK path with a validated NIC.
- Consider CUPS only when independent placement of control and user planes solves a measurable problem for a large fleet, and you are ready to own the distributed system that comes with it.
"vBNG" describes where the software runs, not how well it forwards. Ask any vendor which I/O path, which NIC and which platform a throughput figure was measured on.
Start on a VM
The free evaluation build is the full production build, licensed for up to 50 concurrent subscribers, and runs on a plain virtual machine on the compatibility path. Bring up a test PPPoE or IPoE line, or an L2TP tunnel, on hardware you already have, then move to bare metal when you need the performance path. Start at netavobng.com/evaluation; hardware and VM requirements are in the manual.
FAQ
What is a vBNG?
A vBNG (virtual broadband network gateway) is a BNG delivered as software on general-purpose x86 servers rather than a vendor chassis. It terminates subscriber sessions (PPPoE, IPoE or L2TP), authenticates them against RADIUS, assigns addresses, enforces policy and routes their traffic. The term is used for software BNGs on bare metal, BNGs in a virtual machine, and sometimes disaggregated (CUPS) designs.
What is the difference between a vBNG and a disaggregated (CUPS) BNG?
A vBNG describes where the software runs: on x86, often in a virtual machine. CUPS describes how the BNG is built: its control plane and user planes are deployed independently and talk over a defined interface, as in the Broadband Forum's TR-459 family. A vBNG can be a complete appliance with no CUPS at all.
Can Netavo BNG run as a virtual machine?
Yes. Netavo BNG runs in a VM on its AF_XDP compatibility path, using virtio adapters with no hugepages or IOMMU required. The L2TP LNS role is fully supported on a plain VM, and evaluations and smaller sites commonly start that way. Bare metal on the DPDK path is recommended wherever headline throughput matters.
Is Netavo BNG a CUPS product?
No. Netavo runs its control plane and data plane as separate processes on a single appliance. It is not a disaggregated BNG or CUPS product and does not implement TR-459.