We test vRouters, vFirewalls, vLBs, UPF and other VNFs on KVM and VMware, CNFs on Kubernetes, cloud network services and web portals with the infrastructure in front of them. The bench gives the function a host with the vCPU, memory and NIC profile you specify, loads it from L4-7 engines at 200G+ and L2-3 ports at 100G, and shows what one instance does with virtio and with SR-IOV, how four instances scale, and what a migration or a restart costs in packets. Cloud services are measured over real cloud connections.
When the number is needed
A VNF datasheet quotes throughput on a tuned host with a datapath you may not run. Each moment below asks what the function does on your hosts, with your profile and your neighbours, and ends with a number you can size, accept or sign against.
How many vCPUs and which NIC path a gigabit of your traffic costs. One image, three host profiles, virtio and SR-IOV, your application mix. The result is a table the cloud and the network team size the cluster from.
Gbit/s and pps per vCPU per datapath, 1–2 weeks
The delivered image with the production config on the lab hypervisor, your Kubernetes release or your tenant: throughput, latency and session limits, then migration, restart and a noisy neighbour with traffic running. Measured against your design.
Signed report with pass and fail per case, from 2 weeks
The acceptance cases run again on the new VNF version, the new hypervisor build, the new CNI or the new node pool. What moved, by how much, and whether the design still holds.
Diff per KPI against the last run, 3 business days
What we test
The bench is the same, the traffic and the pass criteria are not. The table is the starting point of the plan; your host profile and your design set the thresholds.
| Class | Numbers in the report | Traffic and config on the bench | Typical size |
|---|---|---|---|
| 01VNF on KVM or VMware | Throughput and latency per vCPU, pps at 64 B, virtio against SR-IOV and DPDK, noisy neighbour impact | Image on the lab hypervisor with your vCPU, NUMA and NIC profile, L2-3 or L4-7 traffic, a loading VM | 2–32 vCPU, 1–40 Gbit/s per instance |
| 02CNF on Kubernetes | Throughput per pod and node, CNI latency, scale-out to N replicas, loss window on drain | Your Helm chart on our cluster or yours, Multus and SR-IOV as configured, L4-7 traffic via ingress | 1–16 replicas, 3–6 nodes |
| 03Cloud network service | Throughput via peering, transit gateways and load balancers, cloud firewall limits, cost per Gbps | Load from the bench over a real cloud connection into your tenant, one profile run in two regions | 1–10 Gbit/s per path |
| 04Cloud VPN or SD-WAN gateway | IPsec throughput per instance size, setup rate, gateway failover time on a lossy link | Gateway in your tenant or on the lab hypervisor, WAN emulator with the delay and loss you set | 10–500 tunnels, 1–10 Gbit/s |
| 05Web portal and the infrastructure in front of it | Requests per second to the first error, response time percentiles, the layer that saturates | User journeys replayed at scale by the L4-7 engines, TLS as in production, counters per layer | 1,000–200,000 concurrent users |
Any vendor and any platform: KVM, VMware, OpenStack, Kubernetes and the public clouds. Named test tools are picked for the setup and listed in the report.
Around the function
A throughput figure for a virtual function only means something with the host named next to it: the cores and the NUMA node it got, the datapath to the NIC, and who else was on the host at the time
vCPU count and pinning, memory and huge pages, NUMA placement, NIC model and queue count come from your platform standard. The bench builds that host, so the function sees what it will see in production.
virtio or OVS on one run, SR-IOV or DPDK on the next, same image and same traffic. The report shows the gap in gigabits and in vCPUs, so the platform choice has a price.
A second workload on the same cores, a live migration, a restart, a pod reschedule, a node drain. Each one timed from the last packet to the first packet back, with the application mix still running.
Typical scenario
An operator moves the branch firewall to a VNF. The datasheet says 20 Gbit/s; the platform team built the host with virtio and the bench measured 6 Gbit/s on the application mix, with two vCPUs at 100 %. The same image on the same host with SR-IOV gave 17 Gbit/s and a 1.4 s loss window on live migration. The report shows both runs with the host settings, and the cluster was sized from the second one.
Composite scenario from projects of this type. Numbers are realistic and not from one client.
What you take away
The report is built for the meeting after the test: the vendor, the platform team and the network team read the same table, with the pass band from the design next to the measured value and the host profile of the run in the header
Each number comes with its evidence: engine statistics, vCPU, NIC and memory counters from the host, captures and the config export of the run
| KPI | Pass band | Measured | Result |
|---|---|---|---|
| Throughput on the app mix, one instance, 8 vCPU | ≥ 15 Gbit/s | 17 Gbit/s | Pass |
| Latency p99 at 10 Gbit/s | ≤ 200 µs | 140 µs | Pass |
| 64-byte frames per vCPU | ≥ 1.5 Mpps | 1.8 Mpps | Pass |
| Scale-out, 1 to 4 instances on one host | ≥ 2.5× | 2.8× | Pass |
| Live migration, loss window | ≤ 2 s | 1.4 s | Pass |
| Noisy neighbour, throughput drop | ≤ 10% | 18% | Pass with a note |
Where it runs
Images and charts come to the lab hypervisor with the host profile you specify, or the bench connects to your tenant or your cluster over a dedicated link; cloud services are loaded over real cloud connections. You watch the run through the portal, with an engineer on every session. The pages below cover the load method, the firewall class and the hosted device option.
How a load run goes, step by step Firewalls and NGFW: the hardware class Hosted DUT: your image stays on the bench RFC 9411: firewall benchmarks
Before the brief
VNFs on KVM, VMware and OpenStack, CNFs on any Kubernetes distribution, services in the public clouds, and web portals with the infrastructure in front of them. vRouters, vFirewalls, load balancers, VPN and SD-WAN gateways, UPF and other mobile-core functions, any vendor. The image, the chart or the tenant access comes from you; the host and the traffic come from the bench.
On yours. vCPU count and pinning, memory, huge pages, NUMA placement, NIC model and the datapath come from your platform standard, and the bench builds that host. A vendor-recommended profile can run next to it, so the gap between the two is a number in the report.
Yes. The bench loads the service over a real cloud connection into your tenant, with emulated servers behind it or your own. Cloud peering, load balancers, cloud firewalls and VPN gateways are measured this way, with the cloud bill of the run next to the throughput.
They are cases in the plan. A second workload loads the same cores on purpose, a live migration, a restart, a pod reschedule or a node drain is triggered with the application mix running, and the report shows the throughput drop and the loss window for each event.
L4-7 engines at 200G and above with TLS and application mixes, L2-3 frames at 100G. A single VNF instance is the limit, not the bench; a cluster of instances is loaded across several ports and the report shows the aggregate and the per-instance figures.
Test plan and quote in 1–3 business days after the brief. A sizing run takes 1–2 weeks, an acceptance run from 2 weeks, a change run 3 business days against the last report. You get the result table with pass and fail per case, the host profile of every run, counters, captures and config exports.
No prices on the site: scope first, then the quote. The vendor and the platform team can sit in on the brief.
Send the shortlist
Name the models and the KPIs that matter. An engineer replies within one business day with a test plan draft and a quote.
Prefer to chat? Message an engineer on WhatsApp
We use what you send only to answer you. See our Privacy Policy.