Why Network Functions Run on Commodity x86 — and How Fast They Actually Go

Functions such as CGNAT, load balancing and firewalls now run as software on standard x86 servers. Whether that works for an operator depends on packet rate rather than bandwidth, on the datapath the software uses, and on how the function is deployed and upgraded.

A vendor datasheet quotes gigabits per second at large packet sizes. Your network sends a mix that includes small packets, and every packet costs CPU time regardless of its size. This section explains how to size servers for real traffic, which datapath technologies make software fast enough, and how to run network functions virtualization without turning upgrades into outages.

BackgroundWhy operators moved network functions to x86

In 2012 a group of operators published the ETSI paper that started network functions virtualization: replace dedicated appliances with software on standard servers. The argument was cost and speed: standard servers promised a lower price per unit of capacity, they could be reused for other workloads, and new capacity would arrive as a licence key rather than a hardware delivery.

The early worry was performance. That changed once user-space datapaths and modern CPUs made it possible to process tens of millions of packets per second on a single server. Operators now run carrier-grade NAT at terabit scale on x86 servers, as the Tier-1 deployment below shows, so the open questions are about sizing and operations rather than feasibility.

PerformancePerformance: packets, datapaths, benchmarks

Software network functions hit packet-rate limits long before bandwidth limits. Small packets are where they fail.

Each Ethernet frame also carries 20 bytes of preamble and inter-frame gap on the wire. At 64 bytes a 100 GbE port therefore carries 148.81 million packets per second, which leaves about 6.7 nanoseconds per packet. At 1,518 bytes the same port carries only 8.1 million. A server that is comfortable with large packets can fall over when the traffic mix shifts towards small ones.

Packets per second, not bits: sizing network functions

Why the average packet size of your traffic, not the port speed, decides how many servers you need, and how to measure it before you buy.

Datapaths for software networking: DPDK, VPP, XDP and eBPF

DPDK moves packet processing into user space, VPP processes packets in batches to keep CPU caches warm, and XDP runs eBPF programs in the kernel before the network stack. Where each one takes the packet away from the kernel and what that means for throughput, observability and day-to-day operations.

Benchmarking a virtual network function: RFC 2544 and independent tests

Test profiles that reflect real traffic rather than best-case packets, the numbers vendors tend to leave out, and how to read a third-party report such as EANTC's.

DeploymentDeployment and operations

The same function can run on bare metal, in a virtual machine or in a container. The choice changes performance, upgrade procedures and how failures are handled.

Converged or dedicated: the performance cost of all-in-one platforms

What happens to CGNAT throughput when it shares a router or BNG with other functions, and when a dedicated function pays off.

Bare metal, VM or Kubernetes for network functions

SR-IOV, CPU pinning, NUMA placement and huge pages, and which platform suits which traffic level.

Upgrading stateful network functions without downtime

Active/standby pairs with session synchronisation, rolling upgrades in active/active clusters, and how to rehearse a failover before you need it.