Operators, vendors, integrators, banks: four questions for one bench
TEST4NET tests network and security devices on CloudLAB for 4 kinds of buyers. An operator arrives with a tender and 3 boxes. A vendor arrives with a datasheet that has to hold up in front of a customer. An integrator needs proof before the rollout. A bank needs the upgrade checked before the change window. Traffic, generators and the report format stay the same; the question, the thresholds and the document you take back differ. Test plan and quote in 1–3 business days.
Telecom operators
Three boxes in the tender, one goes into the core. The run picks it.
A carrier buys for 5–7 years and runs the box under its own routes, policy and failures. The datasheet covers none of that. We run the shortlist under the same traffic and the same table, then repeat the cases on the delivered unit with the production config.
Vendor comparison in the tender
2–3 models, one traffic profile, RFC 2544 and RFC 2889 plus your routing or session scale. The models sit side by side in one table that the tender committee reads without an engineer in the room.
Pre-deployment acceptance
The delivered box with your config, your route table and your failure list: link down, peer down, supervisor switchover with traffic running. Pass and fail per case against the thresholds from the plan.
Change validation
New release, new line card, a changed policy: the acceptance cases run again and the report shows the diff per KPI. 3 business days for a rerun on a known setup.
Network and security vendors
A number measured by a third party beats the same number on your datasheet
Buyers have learned to discount vendor claims. A report from an independent bench, with the method, the traffic profile and the config listed, goes into the RFP response as evidence. We run your product the way the buyer will run it: features on, a realistic traffic mix, failures with traffic.
Validation of product claims
Throughput, connections per second, latency, scale and convergence under the stated conditions. Where the measured value lands below the claim, the report says so and shows the setup, so your team can fix the box or the datasheet.
Release regression on an external bench
The same cases per release on CloudLAB, without tying up your own lab. Diff per KPI between builds, 3 business days for a known setup, your engineers watching the run in the browser.
Comparison under one method
Your product and the units you supply for comparison under the same traffic and the same table. Names stay inside the report; nothing is published without your written consent.
System integrators
Proof for the customer before the rollout, on a bench you do not have to build
The sizing risk sits with you: the model and the licence are chosen before the first packet runs on the customer network. We put the proposed design on CloudLAB with the customer config and traffic, and hand back a protocol both sides sign.
Sizing before the order
The proposed model under the customer traffic profile and policy: does it hold the headroom the design promises? One run costs less than a model swap after the purchase order.
Proof of concept without shipping hardware
Hosted DUT: the unit sits in our rack, your engineers and the customer get browser access to the generators, the counters and the console. The customer sees the run, you keep the schedule.
Acceptance protocol the customer signs
Cases, thresholds and results in one document: pass and fail per case, evidence attached. Your project closes on a signed sheet.
Enterprise and banks
The upgrade goes through the change window once. The run happens the week before.
A bank network team has one window on a weekend night and a rollback plan nobody wants to use. We run the new release, the new platform or the new policy on the bench with the production config and the real traffic mix. The go or no-go rests on numbers from the week before, and the report reads for the auditor as well as for the engineer.
Upgrade before production
The target release on the same model with your config: throughput, sessions, failover and the features you rely on, next to the current release in one table
Platform selection
NGFW, core switch pair, Wi-Fi, SD-WAN: 2–3 candidates under your traffic and your policy before the purchase, with the sizing margin shown per candidate
Yearly re-check
The same cases once a year or per major release, so the box that passed at purchase still passes after 3 years of policy growth
Side by side
What each buyer brings, and what each takes back
The bench and the rules are the same. The table shows where the four differ: the moment, the input and the document at the end.
| Buyer | The moment | You bring | You take back | Typical run |
|---|---|---|---|---|
| 01Telecom operator | Tender, delivery, release change | Shortlist, production config, route table, failure list | Comparison table, acceptance report, diff per KPI | 2–4 weeks per gate |
| 02Vendor | Launch, release, RFP | Unit, datasheet claims, target conditions | Independent report usable in RFP responses | 2 weeks, reruns 3 days |
| 03System integrator | Design sign-off, PoC, handover | Design, config, customer traffic profile | Protocol signed with the customer | 2–3 weeks |
| 04Enterprise, bank | Upgrade, purchase, yearly check | Production config, traffic mix, thresholds | Go / no-go with evidence per case | 1–2 weeks |
Timelines are typical for a known device class; the test plan states the dates for your setup
Same rules for everyone
One engagement format, whoever signs the order
Brief by call or email. Test plan and quote in 1–3 business days. The run starts within 2 weeks, with your engineers watching the bench in the browser if they want to. The report lists pass and fail per case with evidence attached, and we walk through it in a meeting. NDA on every project: no client names, no published results without written consent.
- 1–3 days
- from the brief to the test plan and quote
- From 2 weeks
- first packet to the signed report
- 0 names
- published: every project runs under NDA
Equipment is picked for the setup and listed in the report. Tool brands appear in the report, never on this site as a claim.
Where it runs
CloudLAB: 200G+ for L4-7 and security, 1G to 100G for routing and switching, Wi-Fi up to 6
Each buyer gets the same bench and the same four services behind it. The service pages describe the method per test type; this page describes who orders it and why.
Load and performance testing Functional and conformance testing Security and resilience testing Test plan and methodology design
Questions buyers ask
Names, ownership, scope and timelines
Do you publish client names or case studies?
No. Every project runs under NDA. The scenarios on this site are composite: built from projects of the same type with realistic numbers, with no single client behind any of them.
Can the vendor and the buyer both see the same report?
Yes, when both agree in writing. The usual format: the party that orders the run owns the report and decides who reads it. A vendor can order a report and hand it to buyers; a buyer can invite the vendor to watch the run.
Do you test at our site or only in your lab?
Both. The bench is remote by default. For devices that cannot leave your network, a load module (virtual or an appliance) at your site connects out to CloudLAB over HTTPS, with no inbound ports; control and reporting stay in the cloud.
Is this a penetration test?
No. We measure how devices and network services perform and behave under load, policy and failures, including security devices with their features on. Penetration testing of your applications is outside our scope.
How long does a project take and what does it cost?
Test plan and quote in 1–3 business days after the brief. A run takes from 2 weeks; a rerun on a known setup takes 3 business days. Pricing is per project and comes with the test plan; there is no price list.
Which equipment do you use?
Generators and analysers are picked for the setup and listed in the report: L4-7 and security up to 200G+, L2-3 at 1G, 10G and 100G, Wi-Fi up to Wi-Fi 6. Your own tools can sit on the bench next to ours when the comparison needs it.
Send the brief, get the plan
Tell us which of the four you are and what decision the run has to support. Test plan and quote in 1–3 business days.
Send the shortlist
You have the method. Now get the numbers.
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.