We test campus and data-center switches, edge and core routers, EVPN-VXLAN fabrics, white-box switches and virtual routers on the CloudLAB L2-3 bench: 1G, 10G and 100G ports, RFC 2544 and RFC 2889 for forwarding, emulated BGP, OSPF, IS-IS and EVPN neighbours with up to 1M routes for scale, and link, peer and node failures with traffic running. A run takes from 2 weeks and ends with a report that holds forwarding rate and latency per frame size, the route and MAC limits where the box stops, the loss window per failure in milliseconds, and the config export of the run. Test plan and quote in 1–3 business days.
When the number is needed
A datasheet gives the forwarding rate of an empty box with default timers. Each moment below asks what the box does with your routes, your policy and your failures, and each gets its own scope. The cases stay the same, so the shortlist result, the acceptance result and the post-upgrade result compare.
Every candidate runs the same forwarding, scale and convergence cases on the same ports with the same emulated neighbours. Vendors see the plan before the first packet and the results after the last.
Ranked table per KPI, scale limit per model, 3–4 weeks for 3 boxes
The delivered boxes with the production config: routing policy, timers, BFD, ECMP, ACLs and QoS from your export. Measured against your design, with your route table and your failure list, before the first production packet.
Signed report with pass and fail per case, config exports, from 2 weeks
The acceptance cases run again on the new release, the new line card or the new route policy. What moved, by how much, and whether the box still clears the design. Production stays up; we test the spare or the lab pair.
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 design and your route table set the thresholds.
| Device class | Numbers in the report | Traffic and config on the bench | Typical size |
|---|---|---|---|
| 01Campus access and aggregation switch | RFC 2544 rate and latency per frame size, RFC 2889 full mesh, MAC table limit, STP and LACP failover | Frames on every port at once, VLANs and Q-in-Q as configured, a link and a stack member taken down | 24–48 ports, 1G and 10G, 100G uplinks |
| 02Data-center leaf and spine, EVPN-VXLAN | EVPN route and VTEP scale, hosts per leaf, ECMP balance, convergence on spine and uplink loss | Emulated VTEPs and hosts, route types 2 and 5 from your snapshot, one leaf and one spine failed | 32–64 ports, 100G |
| 03Edge and core router | Routes in FIB, convergence on link and peer loss, forwarding at 10G to 100G with a full table | Emulated BGP, OSPF and IS-IS peers, up to 1M routes, your policy, timers and BFD, failures in turn | 8–32 ports, 10G and 100G |
| 04Virtual router | The same KPIs per instance size, forwarding per core, behaviour when the host is loaded | Image on the bench hypervisor or in your tenant, the same neighbours and failures as hardware | 1–20 Gbps per instance |
| 05White-box switch with SONiC or another open NOS | Feature checklist against the RFP, forwarding and scale as for leaves, NOS upgrade behaviour | Your NOS build and config, the same emulated fabric as the leaf class, the upgrade run with traffic | 32 ports, 100G |
Any vendor, physical or virtual, including white-box hardware with an open NOS. Named test tools are picked for the setup and listed in the report.
Around the box
A forwarding number only means something with the right things around the device: the route table it will carry, the policy it will apply, and the failures it has to survive. All three are on the bench at once.
Route count and prefix mix from your table snapshot, MAC and host counts per VLAN or VTEP, neighbour count per protocol. The bench emulates them, so the box sees its own future, not a lab default.
Routing policy, timers, BFD, ECMP and hashing, ACLs and QoS from your export. The report shows which line each loss window or scale limit traces back to.
Link down, peer lost, supervisor switchover, NOS upgrade. Each one with the full table loaded and traffic on every port, timed from the last packet to the first packet back.
Typical scenario
An operator hands over a new core router pair for acceptance. The datasheet says 2M routes and sub-50 ms convergence. With the production config, 1M BGP routes and traffic on every port, a link failure stops traffic for 1.9 s against a design of 500 ms. The run log points at BFD left off on one peer group and default hold timers on the other. The vendor and the operator tune BFD and switch on prefix-independent convergence on day 8, the rerun gives 180 ms, and forwarding at 100G holds 92% of line rate at 64 bytes and 100% from 128 bytes with the full table loaded. The pair goes into the cutover on a signed report, and the same cases run again after the next release in 3 days.
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 integrator and your network team read the same table, with the pass band from the design next to the measured value
Each number comes with its evidence: generator statistics, FIB and CPU counters from the box, captures and the config export of the run
| KPI | Pass band | Measured | Result |
|---|---|---|---|
| Forwarding at 100G, 64 bytes, full table | ≥ 90% | 92% | Pass |
| Latency at 100G, 1518 bytes | ≤ 10 µs | 6.8 µs | Pass |
| BGP routes held in FIB | ≥ 1M | 1.2M | Pass |
| Link failure, loss window | ≤ 500 ms | 180 ms | Pass |
| Peer loss with BFD, loss window | ≤ 1 s | 0.9 s | Pass |
| ECMP balance across 4 uplinks | ≤ 10% | 14% | Pass with a note |
Where it runs
Boxes ship to CloudLAB or we connect the bench to your lab; virtual routers run on the bench hypervisor or in your tenant, and you watch the run through the portal. The bench has 1G, 10G and 100G ports and emulates hundreds of BGP, OSPF, IS-IS and EVPN neighbours with up to 1M routes and thousands of hosts. The method is RFC 2544 and RFC 2889 for forwarding, and written cases you sign off for scale, convergence and policy.
How a load run goes, step by step RFC 2544: throughput, latency, loss RFC 2889: switch benchmarks Protocol conformance: BGP, OSPF, EVPN
Before the brief
Any vendor and any form factor: campus and data-center switches, edge and core routers, EVPN-VXLAN leaf and spine, white-box hardware with SONiC or another open NOS, and virtual routers. We need the models, the port plan and an export of the config; the rest is in the plan.
Yes. Routing policy, timers, BFD, ECMP, ACLs and QoS come from an anonymised export; the route table and the host counts come from your snapshot. A vendor-default run can be added as a second baseline so you see what the config costs.
Hundreds of BGP, OSPF and IS-IS neighbours, up to 1M routes, thousands of EVPN hosts and VTEPs, on 1G to 100G ports. A larger table or more sessions is agreed per setup and written into the plan before the quote.
Label-switched paths, SR-MPLS and SRv6 are emulated on the bench the same way as plain BGP and IS-IS: neighbours, labels and traffic, then the failures. IPv6 and dual-stack run in every case by default, not as a separate option.
Yes. Boxes go into the CloudLAB rack with KVM and console access and return after the run. For a network that is already racked we connect the bench to your lab over a dedicated link and test a spare or the lab pair.
Test plan and quote in 1–3 business days after the brief. A run takes from 2 weeks for one device role and 3–4 weeks for a shortlist of 3 models or a leaf-spine pod. The report holds the result table, forwarding and latency per frame size, convergence logs, FIB and CPU counters, captures and config exports, and the rerun of fixed items is part of the plan.
No prices on the site: scope first, then the quote. The vendor and the integrator 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.