Services
TEST4NET tests network and security equipment for vendors, operators, integrators and banks. You ship the box or upload the VM. We write the test plan, run it in CloudLAB on 1G to 100G ports and 200 Gbit/s and more of application traffic, and return a report with every measured value. The test plan and the quote come back within 1–3 business days of the first call.
Who comes to us
The device and the question differ. The way out is the same: an independent test with a written plan, and a report you can hand to procurement, to the board or to the vendor.
Customers and RFPs ask for proof that is not your own slide. We run RFC 2544, RFC 2889 and RFC 9411 benchmarks, conformance and interoperability tests, and you get a third-party report to attach to the tender.
Both candidates go through the same traffic, the same frame sizes and the same failure scenarios in CloudLAB. The comparison table decides the purchase instead of the better sales deck.
The new platform is checked before production: failover time under load, session capacity with your policy, the features you plan to switch on. Problems are fixed with the vendor while the old platform still runs.
How a project runs
Every project has a written test plan before anything is connected. That is the document your manager approves and procurement files.
A 30–60 minute call. You describe the device, the question and the deadline. NDA first if you need one.
Scope of work: tests, traffic profiles, pass criteria, tools, schedule and price. One document, ready for approval.
You ship the box or upload the VM. Your engineers watch the sessions in a browser. Daily notes on what passed and what did not.
Every measured value, pass/fail per test, raw files and configs. A call to walk through the results. A retest after a fix is part of the scope.
A retest after a fix is part of the scope, so the report ends with a pass, not with a list of open items.
What we test
Most projects combine 2 or 3 of them. The test plan says which ones and why.
Throughput, sessions, latency and loss up to and past the rated limit. You learn where the device really stops.
Features against the specification, protocol behaviour against the RFC, with evidence for each item.
Multi-vendor pairs and chains on the bench before they meet in production.
NGFW, IPS and VPN efficacy and performance with threats on the wire. DDoS testing is out of scope.
What to test, how, on which traffic and what counts as a pass. For your own lab or for acceptance tests with a vendor.
A regression suite that runs on every software release of the device, with a report your team reads in 5 minutes.
Hands-on courses for your test and network engineers on real generators and real devices.
Diagnostics and repair of test and network equipment that is out of vendor support.
The bench behind the numbers
Commercial traffic generators and our own, WAN emulators and a Wi-Fi bench share one patching field. Your device gets reserved units, KVM and serial access, or runs as a VM on our virtual capacity.
The report names the tool and the configuration behind every number. We do not base a decision on a free generator, and we never claim a tool we did not use.
Open the CloudLAB portalTypical scenarios
Three composite projects, shown the way the report shows them. The numbers are representative of what we see. Clients are under NDA and are never named.
| Metric | Expected | Measured |
|---|---|---|
| Loss at 64 B, 8 ports | 0 | A 0.02% · B 0 |
| BGP convergence, 1M routes | < 2 s | A 1.1 s · B 3.5 s |
Decision on the table: B for the data-centre edge, A where the route table is large. Both vendors received the same report.
| Metric | Expected | Measured |
|---|---|---|
| Throughput, firewall only | 40 Gbit/s | 31 Gbit/s |
| IPS + app control + TLS on | 40 Gbit/s | 6 Gbit/s |
The vendor published per-feature numbers instead of the single big one, 2 weeks before the launch.
| Metric | Expected | Measured |
|---|---|---|
| Failover, 1M sessions | < 1 s | 1.8 s, 0.7 s after the fix |
| Policy of 4,000 rules | identical | 3 rules differ |
Both findings were fixed with the vendor before the cut-over weekend. Retest included, 10 days in total.
Why TEST4NET
Also taken: cloud infrastructure and services, web portals together with the infrastructure in front of them. Not taken: DDoS and penetration testing.
The test plan and the quote come back within 1–3 business days of the brief. The run starts as soon as the device is in the lab or the VM is uploaded, usually within 1–2 weeks of approval.
For a physical device, yes: it goes into our rack with KVM and serial access, and we return it after the project. Virtual appliances are uploaded to the lab. If the device cannot leave your site, we discuss remote access to your lab during the brief.
The setup and the method, the parameters of every test, tables and charts per frame size or per traffic profile, pass/fail against the criteria from the test plan, raw exports and configs, and a list of findings with severity. The tool behind every number is named.
Per project, from the scope of work: the number of tests, the traffic volume, the devices and the duration. There is no public price list. Projects run from 1 week to several months, and the quote comes with the test plan.
Commercial traffic generators and WAN emulators, and our own traffic generator, which is now in beta. The test plan names the tool for every test before you approve it. We do not rent out equipment.
Yes. CloudLAB sessions open in a browser, so your team sees the generator and the device console live. The NDA is signed before any device details are shared.
One call, then a test plan and a quote within 1–3 business days. A scope of work your manager can approve and procurement can file.
Send the shortlist
Send the shortlist 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.