We test branch CPEs, hubs, cloud gateways and the underlay services behind them on the CloudLAB bench: two or three underlays per site through WAN emulators that add delay, jitter, loss and shaping per link, IPsec tunnels and application traffic from emulated branches, and the brownouts a datasheet never mentions. The report shows how fast the policy moves an application off a bad path, how many tunnels and sessions a hub holds, and what TCP really gets over the overlay.
When the number is needed
A slide shows a failover in one second on two clean links. Each moment below asks what the CPE does with your applications, your underlays and the half-broken path, and ends in a number the project can sign.
Every candidate runs the same steering, failover, QoS and tunnel-scale cases on the same impaired links with the same emulated branches. Vendors see the plan before the first packet and get the same report.
Ranked table per KPI, scale ceiling per platform, 3–4 weeks for 3 platforms
The delivered CPEs and hubs with the production policy: application classes, SLA probes, thresholds, QoS, breakout rules and tunnel settings from your export. Measured against your design on the underlays you will actually buy.
Signed report with pass and fail per case, policy export, from 2 weeks
The acceptance cases run again on the new release, the new underlay or the new application policy. What moved, by how much, and whether the branch still clears the design. Repeatable from the same bench profile.
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 application list and your underlay contracts set the thresholds.
| Device class | Numbers in the report | Traffic and config on the bench | Typical size |
|---|---|---|---|
| 01Branch CPE | IPsec throughput per packet size, steering time on loss, jitter and link down, QoS under congestion | Two or three underlays via WAN emulators, voice, video and SaaS-like flows, your policy and probes | 100 Mbps to 1 Gbps per branch, 2–3 underlays |
| 02Hub and data-center gateway | Tunnels held, new connections per second, throughput with all active, convergence on hub loss | Emulated branches with IPsec and overlay routes, traffic on every tunnel, one hub taken down live | 1–10 Gbps per hub, tunnel count from your design |
| 03Cloud gateway, vCPE | The same KPIs per instance size, throughput per core, behaviour when the host is loaded | Image on the bench hypervisor or in your tenant, the same branches and impairments as hardware | 200 Mbps to 5 Gbps per instance |
| 04Controller and orchestrator | Policy push time to all sites, re-admission after controller loss, data plane while it is down | Controller on the bench or in your tenant, emulated sites joining, policy pushes under traffic | Hundreds to thousands of sites |
| 05Underlay Ethernet or Internet service | Y.1564 per service: CIR, EIR, delay, jitter, loss; RFC 6349 TCP throughput over the path | Generator and a loopback or second unit at the far end, 15 min to 24 h runs, TCP per window size | 10 Mbps to 10 Gbps per service |
Any SD-WAN vendor, physical or virtual, including a vendor you are leaving. Named test tools are picked for the setup and listed in the report.
Around the box
A failover number only means something with the right things around the device: the applications it will steer, the underlays it will see with their real delay and loss, and the half-broken path that production will hand it on a Tuesday afternoon
Each link goes through a WAN emulator with the delay, jitter, loss and shaping of the contract or the measured path. A brownout is a change in those numbers, not a cable pulled.
Application classes, SLA probe intervals and thresholds, QoS queues, breakout and tunnel settings from your export. The report shows which line each slow move or dropped class traces back to.
Emulated users behind the CPE and emulated branches behind the hub, voice and video flows scored per second, the brownout and the cut timed from the last good second to the first good second after the move
Typical scenario
An enterprise hands over its branch platform for acceptance before 300 sites migrate. The vendor slide shows failover in under a second. With the production policy and a clean cable pull it does. With 2 % loss and 40 ms jitter on the MPLS path, the probes keep reporting the link as up and voice stays on it for 90 seconds. Tuning probe interval, loss threshold and the jitter rule brings the move to 3 seconds on day 4; the hub tunnel ceiling and the DIA breakout rules are measured on the same bench 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 carrier and your network team read the same table, with the pass band from the design next to the measured value per path and per application
Each number comes with its evidence: per-second application scores, tunnel and session counters from the box, emulator settings per link, captures and the policy export of the run
| KPI | Pass band | Measured | Result |
|---|---|---|---|
| Voice steering on MPLS brownout | ≤ 5 s | 3 s | Pass |
| Voice steering on link down | ≤ 1 s | 0.6 s | Pass |
| IPsec throughput, 1 Gbps branch, 1400 B | ≥ 900 Mbps | 940 Mbps | Pass |
| Tunnels held per hub, traffic on all | ≥ design count | design + 20 % | Pass |
| TCP throughput over the overlay, RFC 6349 | ≥ 85 % of line | 91 % | Pass |
| Voice MOS under 3:1 congestion | ≥ 4.0 | 3.9 | Pass with a note |
Where it runs
CPEs and hubs ship to the CloudLAB rack in Armenia or we connect the bench to your lab; virtual gateways run on the bench hypervisor or in your tenant, and you watch the run through the portal with an engineer on every session. The links are 1G to 100G with a WAN emulator on each, so a brownout is a setting, not a search for a bad cable.
How a load run goes, step by step Routing and switching: the boxes behind the WAN RFC 6349: TCP throughput over a real path Y.1564: Ethernet service activation
Before the brief
Any vendor and any form factor: branch appliances, hub and data-center gateways, virtual CPEs on the bench hypervisor or in your cloud tenant, and the controller that drives them. Classic WAN routers with IPsec and policy routing run the same cases. The plan names the test tool behind each number; there is no single default vendor.
Every underlay on the bench passes through a WAN emulator that sets delay, jitter, loss, reordering and bandwidth per direction. A brownout is a scripted change of those numbers at a known second, so the steering time is measured from the first bad second to the first good second after the move, and the same brownout repeats for every platform and every rerun.
Yes. Application classes, SLA probes, thresholds, QoS and breakout rules come from an anonymised export; the traffic is built from your application list, with voice and video scored per second and SaaS-like flows over TLS. A vendor-default run can sit next to it, so the gap between the slide and your policy is a number.
As many as the design needs, on 1G to 100G ports: emulated branches with IPsec tunnels and overlay routes toward the hub, with traffic on every tunnel. The site count and a multi-hub design are agreed per setup and written into the plan before the quote.
The underlay is measured on its own: ITU-T Y.1564 per service against the contract, RFC 6349 for TCP throughput and buffer delay over the path. With those numbers next to the steering times the report says whether a slow failover is the policy, the box or the link.
Test plan and quote in 1–3 business days after the brief. A run takes from 2 weeks for one branch class and a hub, 3–4 weeks for a shortlist of 3 platforms. The report holds every case with its pass band, the measured value, the emulator settings and the policy export, plus a one-page summary per platform.
No prices on the site: scope first, then the quote. The vendor and the carrier 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.