An Ixia chassis with tested modules gives you ports, software, and licensed features. What turns that into a test system is the plan: which tests run, in what order, with what traffic maps, against what pass criteria, and where the evidence lands. Most labs carry that plan in an operator’s head. It works until the operator changes, the platform changes, or a customer asks to see the procedure.
We write these plans as a deliverable, centered on IxNetwork and IxLoad. Three starting points, one output: an automated test plan that runs unattended on your chassis and produces its own report.
Download the service brochure (PDF, Rev B)
Where we start
From a manual procedure. An operator checklist (connect, send traffic, watch the counters) becomes a numbered sequence of IxNetwork QuickTests: RFC 2544 and RFC 2889 runs with defined frame-size sweeps, search algorithms, trial counts, and per-frame-size pass gates. What an operator used to eyeball becomes a criterion the software enforces, and after launch the run needs no operator at all.
From another vendor’s tester. Plans written for retired or orphaned platforms translate. The example scenario below retires a manual SmartWindow workflow on a Spirent SmartBits SMB-600B; the same mapping applies to plans built for Spirent TestCenter, Xena, and similar systems. The intent of each test case carries over. The execution moves to QuickTests and gains automated binary search, consistent reporting, and exact repeatability.
From a blank sheet. Given a DUT datasheet and the question you need answered, we design the plan: RFC 2544, RFC 2889, and RFC 3918 benchmarking, ITU-T Y.1564 service activation, protocol emulation where the DUT terminates protocols, IxLoad application and load testing where the DUT is stateful, and soak cases where the risk is thermal or long-duration stability.
What a delivered plan contains
The structure below is the same for every DUT, every module family, and every port speed. The sample pages shown through this post all come from one delivered plan, the example scenario further down; only the content changes with your hardware.
- The DUT description and port map: which chassis port connects to which DUT port and why, plus the physical-layer settings (media mode, autonegotiation, flow control) that silently skew results when left at defaults.
- Numbered test cases, each with an objective, method, the exact QuickTest and search algorithm, the traffic map, and proposed pass/fail thresholds flagged for your engineering to ratify against product specs.
- A discovery gate up front: a TC0 that resolves the DUT behaviors the datasheet does not state, before any threshold is frozen.
- The wizard-level execution procedure: the exact IxNetwork steps that configure and launch each test, written so a technician who has never opened IxNetwork can run the suite.
- Automation exports: archived .ixncfg configurations that rerun a test in two clicks, and Tcl ScriptGen exports for scripted nightly or manufacturing regression.
Example scenario: retiring a SmartBits SMB-600B
One delivered engagement, shown as an example scenario. The service itself is generic: any DUT class, any module family, any port speed our platforms host. The device under test in this scenario happens to be a transparent three-port HDBaseT Ethernet extender: no host stack, no management IP, no MAC address of its own. The customer benchmarked it by hand in SmartWindow on a Spirent SmartBits SMB-600B.
The migrated plan treats the device as a black-box forwarding element and rebuilds the work as ten test cases: a short forwarding-behavior discovery gate, then automated RFC 2544 throughput, latency, frame-loss, and back-to-back runs, RFC 2889 one-to-many, many-to-one, and fully-meshed runs matched to the extender’s one-to-two port geometry, flow-control transparency, frame-integrity and MTU-boundary cases, and an overnight soak. Each automated case runs as an IxNetwork QuickTest with binary search and per-frame-size pass gates, and generates its own PDF and CSV report on completion.
The port math moved too: the SmartBits bench offered four test ports in total. The delivered configuration runs eight complete extender systems in parallel per XM2 chassis, twenty-four across the customer’s three-chassis fleet, with every port generating and analyzing at line rate.
Mapped to licenses you already have
Every plan closes with a feature map: each test case tied to the specific licensed feature that executes it, so there is no surprise dependency on software you do not have. The same section records the licensed headroom: capabilities already on the system that the current plan does not exercise, such as asymmetric-performance QuickTests, IEEE 1588v2 timing verification, Y.1564 service activation, and the protocol and application emulation catalog. That headroom is usually where the next plan comes from.
Beyond the plan: remote chassis configuration scripting
The same automation surface the plans run on is scriptable end to end, and we develop against it as part of an engagement. Chassis and port configuration, ownership handling, test launch, and results collection can all be driven remotely through Ixia’s automation interfaces: the Tcl automation layer that every IxOS generation ships, the script exports and automation APIs of IxNetwork and IxLoad, and the REST and Python interfaces available on newer releases. Where an off-the-shelf interface stops short, we build the missing piece: command-line utilities and scheduled jobs developed for your environment, proven on our own fleet before they ship.
In practice this means your test suite does not have to end at the IxNetwork window: nightly regression against a rack of chassis, results filed to a share, and an operator notified only when a pass gate fails.
How this pairs with the bench
We offer this service on Optixia XM, XG12, and XGS chassis running Windows 7, Windows 10, or Native IxOS Linux, IxOS versions 6.7 through 9.15, covering any module family those platforms host, from classic 10/100/1000M line cards through 400GE, and any DUT class you point them at. Plans are written and proven on the same fleet we test and sell from. The hardware side of the same bench runs our module test and diagnosis service, and every module we ship carries the validation report documented here. A test plan is scoped against the exact IxOS, IxNetwork, and IxLoad releases and the license schedule on your system, stated on page one of the plan.
Service tiers
Four ways to take the service, from a written assessment to turnkey automation. The analysis stage is a fixed $300 fee and delivers the Integration Recommendations and Options report, by email and US Mail. Every tier beyond it is an additional-fee engagement, quoted inside that report before any work begins.
How to engage
Send us the DUT datasheet, or a copy of whatever you run today: a manual procedure, a legacy-platform configuration, a spreadsheet, even paper. We will sign a non-disclosure agreement covering any testing information you share with us. For a fixed $300 fee we run the analysis and deliver the Integration Recommendations and Options report, as a PDF by email and a printed copy by US Mail: your assessment, the recommended integration path, the license and port findings, and a fixed quote for each deployment tier. Nothing is built until you approve it.
On approval you receive the deployment package: archived .ixncfg configurations, Tcl regression exports, and a step-by-step runbook your team runs on your own chassis. Packages are delivered for the three environments Ixia labs actually run: Windows 7 hosts pinned to legacy IxOS client generations, Windows 10 hosts on current clients, and Native IxOS Linux on the chassis itself. Remote deployment assistance is available, with our engineers online while your first runs execute. Money-back guarantee: we will work with you to meet your stated goals or you pay nothing. Extended support plans are available for ongoing regression programs.
Contact us for a quote.
Zombie Components LLC · 13177 Foothill Blvd, Sylmar, CA 91342