Skip to content

A test plan the vendor signs and your lab can run

We write the document that decides a tender, an acceptance or your own lab routine: what to test, on which topology and traffic, in what order, and what counts as a pass. Traffic profiles come from your network, pass criteria carry a load level and a duration, every test case names its evidence. The vendor reviews it before the first packet, so the result cannot be argued away afterwards. First draft from 3 business days. You run it in your lab, the vendor runs it in theirs, or we run it in CloudLAB.

Request a plan What the document contains
Acceptance test plan, core switching Structure of a typical document. 6 parts, 11 test cases.
  1. 1 Scope and devices
  2. 2 Topology and bench
  3. 3 Traffic profiles
  4. 4 Test cases and KPIs
  5. 5 Pass criteria
  6. 6 Report and evidence
TC-07 Latency under 70% load, 9000-byte frames p99 ≤ 12 µs for 300 s
Signed before the run Customer Vendor
  • From 3 daysto the first draft
  • 6 partsone document, one scope
  • 1 review roundwith you and the vendor, included
  • 20 yearsin test labs behind every plan
From your network to the traffic profile in the plan
NetFlow, 7 days or a pcap sample Breakdown protocols · frame sizes · peaks Storage 41% HTTPS 27% Video 18% Voice 6% Other 8% Profile in the plan mix in % · sizes · ramp 41%9000 B 27%1400 B 18%1200 B 6%200 B 8%IMIX

Why not the vendor’s plan

Three places where a borrowed test plan loses the tender for you

Most acceptance plans are a vendor template with the customer’s logo on it. They test what the box is good at, on traffic that never ran in your network, against a criterion nobody can fail.

  1. The traffic is not yours

    64-byte frames and a flat IMIX say nothing about a network that carries 9000-byte storage flows and TLS 1.3. We take 7 days of NetFlow or a pcap sample and turn it into the profile the plan uses.

  2. The criterion has no load and no clock

    «Latency under 20 µs» passes on an idle box. «p99 latency under 12 µs at 70% of line rate for 300 s with 9000-byte frames» passes or fails, and the number is in the report either way.

  3. The failure cases are missing

    Link loss with 500,000 BGP routes, an upgrade with traffic, a full log queue: the cases that hurt in production are the ones the template leaves out. We put them in and agree the pass criterion in advance.

Inside the document

Six parts, each with a source and an owner

The plan is one document with six parts. Every part says where its content comes from and who signs it off, so the vendor cannot later call the setup unfair and your team cannot lose a page in e-mail.

PartWhat it containsWhere it comes fromWho signs it off
01Scope and devices Models, firmware, licences, roles in the network, what is out of scope Your tender or device list You
02Topology and bench Wiring, port map, generator ports, management access, who provides what Your network diagram, our bench You and the vendor
03Traffic profiles Mix in percent, frame sizes, sessions, ramp and sustain, attack sets where relevant Your NetFlow or pcap, RFC mixes You
04Test cases and KPIs ID, objective, procedure step by step, the KPIs sampled and how often RFC 2544, 2889, 3511, 9411, Y.1564, TR-398 and your own cases Our engineer
05Pass criteria A number, a load level, a duration and a frame size for every case Your SLA and capacity plan You and the vendor
06Report and evidence Result table template, evidence list per case, retest rules Our report format You

Where a published methodology applies, the plan cites it by section and says what is changed and why. Where none applies, the case is written from scratch and marked as such.

How it is written

Five steps, the vendor at the table before the run

  1. 1

    Brief

    1 call

    The decision the plan has to support, the devices, the deadline, who will run the tests

    Scope and quote in 1 business day

  2. 2

    Inputs

    Day 1

    Tender text, network diagram, device list, a NetFlow export or a pcap sample, your SLA

    Checklist of inputs, one page

  3. 3

    Draft

    Days 1–3

    The six parts, every test case with its pass criterion, traffic profiles built from your data

    First draft from 3 days

  4. 4

    Review

    Days 3–5

    One round with your team and the vendor. Every comment is logged with what changed and what was refused and why.

    Signed version with a change log

  5. 5

    Run

    Your choice

    Your lab runs it, the vendor runs it under your eyes, or we run it in CloudLAB and hand over the report

    Report in the plan’s own template

Typical scenario

Four equal datasheets, one tender, two lines in the plan decide it

A bank buys 40 core switches. Four vendors, four datasheets with the same throughput. The plan has 11 test cases built on the bank’s own traffic: 41% storage flows with 9000-byte frames and a nightly peak. Two cases decide the outcome: latency at 70% load with jumbo frames and a link loss with 500,000 BGP routes. Two of the four candidates fail them, one passes with a note, one passes clean. The bank buys the clean one and keeps the plan as its acceptance routine for every firmware since.

11 cases
written in 4 business days
2 of 4
candidates failed the two cases that mattered
1 plan
reused for every firmware acceptance since

Composite scenario from projects of this type. Numbers are realistic and not from one client.

Result grid, 5 of 11 cases
ABCD
TC-03 Throughput, your mix
TC-07 Latency, 70% load, 9000 B
TC-08 Link loss, 500k BGP routes
TC-10 Upgrade with traffic
TC-11 Log storm

PassPass with a noteFail

One test case

What a test case looks like on the page

Every case has the same card, whoever runs it. An engineer who has never seen the bench can execute it from the card alone, and the vendor can repeat it in their own lab and get the same number.

Four rules for the pass criterion, applied to every case in the plan

A number
Not «acceptable latency» but «p99 ≤ 12 µs». If the SLA has no number yet, we derive one from the capacity plan and mark it as derived.
A load
Every criterion names the load it holds at: percent of line rate, sessions, routes, tunnels. Idle results are recorded but never count.
A clock
Sustain time and sampling interval are in the case. 300 s of sustain and a 2 s sample is the default for performance cases.
An evidence list
What proves the result: generator statistics, device counters, captures, console log. The report is incomplete until all of it is attached.
TC-07 Performance Pass criterion

Latency under 70% load with 9000-byte frames

Objective
Confirm that storage traffic keeps its latency budget on the core switch while the uplinks carry the nightly peak
Traffic
Profile P2 (storage 41%, HTTPS 27%, video 18%, voice 6%, other 8%), 9000-byte frames on the storage share, ramp 60 s, sustain 300 s at 70% of line rate on all 32 ports
KPIs
Latency p50, p99 and max per port pair, frame loss, sampled every 2 s
Pass criterion
p99 ≤ 12 µs and loss 0 on every port pair for the full 300 s. One excursion above 12 µs is a pass with a note; loss is a fail.
Evidence
Generator latency histogram per pair, switch interface counters before and after, a capture of 60 s on two pairs

Who writes it

Written by the engineers who run the bench, not by a sales team

The author of the plan is the engineer who would run it in CloudLAB: 20 years in vendor and operator test labs, RFC 2544, 2889, 3511 and 9411, Y.1564 and TR-398 in daily use. The plan is written for the tools you have, from a commercial generator to TRex and iperf, and says which cases need which tool. If you want us to run it, the bench carries 200 Gbps and more and the report comes in the plan’s own template.

Bench access and capacity Run it as a load and performance test RFC 2544 and 2889 on our bench RFC 9411 for firewalls

Related reading

Questions before the brief

What buyers ask first

What do you need from us to start?

The tender text or the decision the plan supports, a network diagram, the device list with firmware, a NetFlow export or a pcap sample of a typical week, and your SLA or capacity plan if there is one. Missing items are replaced by stated assumptions in the draft.

Can the vendor dispute the plan?

They are meant to, before the run. One review round with the vendor is included. Every comment is logged with what changed or why it was refused, and the signed version carries that log.

Is it written for the tools we already have?

Yes. The plan names the tool class per case: a commercial generator for line-rate and latency cases, TRex or iperf where they are enough, a protocol emulator for routes and tunnels. If a case cannot be run with your tools, the plan says so and offers CloudLAB for that case.

Which standards does it follow?

RFC 2544 and 2889 for switches and routers, RFC 3511 and 9411 for firewalls, ITU-T Y.1564 for Ethernet services, TR-398 for Wi-Fi, each cited by section. Cases the standards do not cover, such as failover with your routing table or an upgrade under load, are written from scratch and marked.

How long does it take?

First draft from 3 business days for one device role, 5 to 10 for a multi-vendor tender with several roles. The review round adds 2 to 3 days depending on the vendor.

Can you run it as well?

Yes, in CloudLAB, from 2 weeks for a full run, or on your site with a load module that connects out to CloudLAB. The report then comes in the template defined in part 6 of the plan.

Send the tender text and a network diagram. The scope and the quote come back in a day.

First draft from 3 business days. No NetFlow yet is fine: the draft starts from an RFC mix and says so.

Request a plan All services

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.